From lei.zhu@huawei.com Mon Nov 1 01:06:09 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FB83A68A8 for ; Mon, 1 Nov 2010 01:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z43KZUIqlzr for ; Mon, 1 Nov 2010 01:06:08 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E3FA93A6824 for ; Mon, 1 Nov 2010 01:06:07 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB700LUL55XKV@szxga04-in.huawei.com> for conex@ietf.org; Mon, 01 Nov 2010 16:05:57 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LB700L1355XL2@szxga04-in.huawei.com> for conex@ietf.org; Mon, 01 Nov 2010 16:05:57 +0800 (CST) Received: from [172.24.1.6] (Forwarded-For: [219.232.25.173]) by szxmc03-in.huawei.com (mshttpd); Mon, 01 Nov 2010 16:05:57 +0800 Date: Mon, 01 Nov 2010 16:05:57 +0800 From: zhulei 41317 To: conex@ietf.org Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal Subject: Re: [conex] additional comment on the use cases drafts X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 08:06:09 -0000 Hi all, An ID was presented at IETF 78th meeting and renewed about two weeks before. http://tools.ietf.org/html/draft-lei-ecn-localised-congestion-notification-01 The revised document for IETF 79th meeting is to reflect the discussions of previous meeting. The use cases are also concluded in the document and are expected to be discussed and accepted in 79th meeting. One use case of those is to introduce the proper indicating approach(es) to notify congestion of local access network. Another one is mentioned previously, and should be also considered in use case document. I might ask time slot at meeting of next week for a 10 minutes presentation. In addition, I also ask folks in mail list to comment on this revision. The revision is uploaded more than 2 weeks ago, then I have no time to ask your comments for some reasons. If you have time in this week, please do it. Thanks! Best regards, Lei Zhu ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email immediately and delete it! ***************************************************************************************** From marcelo@it.uc3m.es Tue Nov 2 04:13:33 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810883A69A9 for ; Tue, 2 Nov 2010 04:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe2+1hDi-mdF for ; Tue, 2 Nov 2010 04:13:32 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 6ABF03A68D2 for ; Tue, 2 Nov 2010 04:13:31 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 0BF04800C4A for ; Tue, 2 Nov 2010 12:13:32 +0100 (CET) Message-ID: <4CCFF25B.6010404@it.uc3m.es> Date: Tue, 02 Nov 2010 12:13:31 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: conex@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17740.006 Subject: [conex] about draft-mathis-conex-abstract-mech-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 11:13:33 -0000 Hi, I read this document and i believe is a good starting point for our deliverable. I have some comments though: Section 1.1. when i read the document, the definitions included in this section were not very meaningful to me. In other words, this section defines a set of conex signals that without proper context are not very meaningful imho. So i believe that this section needs to be moved to later on, when the reader has more idea of what is going on. Moreover, the Credit signal, i don't believe is properly explained anywhere in the document, or at least i haven't been able to find it. I think this needs to be explained in more detail. In particular, I found the text on section 2, point d quite confusing. Section 3.1, the strawman encoding talks about bit 48 in the IPv4 header. Since we are expliclty chartered not to work in v4, i find this a bit kind of looking for trouble. I woudl suggest to remove any reference to IPv4 and simply say : "assume we have a bit in the IP header that we can use for this" I believe it conveys the same idea and imho it will prevent future troubles. In the same section 3.1 It reads: Furthermore this encoding, by itself, does not sufficiently support partial deployment Why not? Section 3.2 seems to assume that the reader is familiar with reecn or will read about reecn. My personal prefernce would be that the doc is self contained, at least w.r.t. to congestion notification. I mean, i would like to see a document that i can read and i can understand conex, without needing to read other congestion exposure protocols. Do you think that would be feasible? I mean it is ok to reference reecn, but i would prefer if this document contians the main ideas that need to be understood to understand conex. My preference would be to explain mre in detail these idea in this section. In section 3.2.1 This last change permits the transport protocol to carry multiple congestion signals per round trip, and greatly simplifies accurate auditing. Why is that? In section 3.3.1 the definition of credit is not clear enough to me. Regards, marcelo From acooper@cdt.org Sat Nov 6 03:11:55 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B453A6938 for ; Sat, 6 Nov 2010 03:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zseQrWiNeXU9 for ; Sat, 6 Nov 2010 03:11:52 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id D4D533A68C4 for ; Sat, 6 Nov 2010 03:11:48 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Sat, 6 Nov 2010 06:11:44 -0400 Message-Id: <4B83D7FC-69B9-4281-9203-2D35DBF906F7@cdt.org> From: Alissa Cooper To: Toby Moncaster In-Reply-To: <000c01cb7741$afa09f30$0ee1dd90$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 6 Nov 2010 18:11:35 +0800 References: <4CC9264F.2080201@it.uc3m.es> <2464076D83FAED4D985BF2622111AAC40F3A7D7270@FHDP1LUMXC7V11.us.one.verizon.com> <000c01cb7741$afa09f30$0ee1dd90$@com> X-Mailer: Apple Mail (2.936) Cc: conex@ietf.org Subject: Re: [conex] additional comment on the use cases drafts X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:11:55 -0000 I may be misreading draft-mcdysan-conex-other-usecases-00.txt, but it seems to use a broader concept of what conex will be signaling than what is described in draft-mathis-conex-abstract-mech-00 (e.g., signaling a measure of burstiness as described in 4.1 in -other- usecases). I like how the -other-usecases draft describes uses of conex information that can be made over a longer time interval, but it seems like there needs to be clarity on what conex is signaling before integrating all the use cases into a single draft. Alissa On Oct 29, 2010, at 4:17 PM, Toby Moncaster wrote: > Seems OK to me too. I'm perfectly happy to try and expand the number > of use > cases, at least to start with. Later on I imagine it will become > clearer > which use cases will really work... > > BTW Dave, I will send some comments on your draft by the start of the > meeting... > > Toby > >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >> Behalf >> Of Mcdysan, David E >> Sent: 28 October 2010 14:03 >> To: marcelo bagnulo braun; conex@ietf.org >> Subject: Re: [conex] additional comment on the use cases drafts >> >> Works for me. >> >> As stated in my draft, the intent was to be complementary to the >> moncaster draft. >> >> Thanks, >> >> Dave >> >>> -----Original Message----- >>> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] >>> On Behalf Of marcelo bagnulo braun >>> Sent: Thursday, October 28, 2010 3:29 AM >>> To: conex@ietf.org >>> Subject: [conex] additional comment on the use cases drafts >>> >>> Now, we stated that we are planning to ask for adoption of WG >>> documents for the abstract mechanism and for the use cases.In >>> the case of the use cases, the situation deserve more >>> clarification. We have two documents: >>> draft-moncaster-conex-concepts-uses and >>> draft-mcdysan-conex-other-usecases-00.txt. >>> draft-moncaster-conex-concepts-uses was discussed in the >>> previous meeting and some changes were requested in order to >>> call for adoption. >>> The plan is to ask the WG if you feel that the changes have >>> been made and the draft is in good shape to be the basis for >>> our deliverable (i.e. >>> we will ask for adoption of this document) >>> draft-mcdysan-conex-other-usecases-00.txt otoh, is a new >>> draft that presents additional use cases. The question that >>> will be asked to the WG is whether you feel that the use >>> cases covered in this draft should be covered and in the case >>> that the answer is affirmative, we will proceed to integrate >>> these new use cases to the other uses cases we already have. >>> >>> Comments? >>> >>> Regards, marcelo (on behalf of the co-chairs) >>> >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >>> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > From acooper@cdt.org Sat Nov 6 03:29:38 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1483A6817 for ; Sat, 6 Nov 2010 03:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sYz64pG0Txn for ; Sat, 6 Nov 2010 03:29:37 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id C75B13A67F6 for ; Sat, 6 Nov 2010 03:29:36 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for conex@ietf.org; Sat, 6 Nov 2010 06:29:48 -0400 Message-Id: From: Alissa Cooper To: conex@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 6 Nov 2010 18:29:38 +0800 X-Mailer: Apple Mail (2.936) Subject: [conex] comments on draft-moncaster-conex-concepts-uses-02 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:29:38 -0000 I have a few small comments on draft-moncaster-conex-concepts-uses-02. Overall I think the split between use cases and mechanism is working well. Section 1: It seems a little odd to have a UK-specific reference (to Ofcom data) about broadband speeds when multi-country data exists (e.g., OECD: http://www.oecd.org/document/54/0,3343,en_2649_34225_38690102_1_1_1_1,00.html) . "Congestion generally results from the interaction of traffic from one network operator's users with traffic from other users." While this is the main focus I think it discounts users self- congesting a bit too much. Maybe something like "Much congestion results..." would be a little more accurate. Section 5.5 Since it's not immediately obvious how conex can be used for QoS, I think this use case could benefit from more explanation. There was some confusion about it which was clarified on the list (http://www.ietf.org/mail-archive/web/conex/current/threads.html#00127 ), but that doesn't seem to have been reflected in the draft. Section 5.6 Seems like this should be named "Congestion Settlements" or something similar. The partial vs. full deployment question is one that may have to be addressed by some subset of use cases, not only this one. Alissa From acooper@cdt.org Sat Nov 6 03:35:23 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC853A6950 for ; Sat, 6 Nov 2010 03:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1KQvIvIg7Py for ; Sat, 6 Nov 2010 03:35:21 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 2BBCC3A6951 for ; Sat, 6 Nov 2010 03:35:20 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for conex@ietf.org; Sat, 6 Nov 2010 06:35:33 -0400 Message-Id: <61AC60DD-4EC8-4229-9E96-E3EA78FDBF6E@cdt.org> From: Alissa Cooper To: conex@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 6 Nov 2010 18:35:19 +0800 X-Mailer: Apple Mail (2.936) Subject: [conex] partial deployment in draft-mathis-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 10:35:23 -0000 In draft-mathis-conex-abstract-mech-00 it says that "the conex signal SHOULD be useful under only a partial deployment." Shouldn't that SHOULD be a MUST based on the charter text? From the charter: "However, the CONEX WG will initially focus on one use case, where the end hosts and the network that contains the destination end host are CONEX-enabled but other networks need not be." Alissa From toby@moncaster.com Sat Nov 6 04:36:46 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439383A686D for ; Sat, 6 Nov 2010 04:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAM-Eog3+sTV for ; Sat, 6 Nov 2010 04:36:45 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 629913A6876 for ; Sat, 6 Nov 2010 04:36:44 -0700 (PDT) Received: from TobysHP (host86-167-110-184.range86-167.btcentralplus.com [86.167.110.184]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MfBqk-1OvUR20a7O-00P8Rn; Sat, 06 Nov 2010 12:36:38 +0100 From: "Toby Moncaster" To: "'Alissa Cooper'" , References: In-Reply-To: Date: Sat, 6 Nov 2010 11:36:38 -0000 Message-ID: <000501cb7da6$e0485130$a0d8f390$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Act9nY7XWWBuWgRLSwGuLaY112JLMwACGHIA Content-Language: en-gb X-Provags-ID: V02:K0:4NnM9hi7BbMHuh8PMvHOEiEf4img4keDEf4zlmq1YIR 6UyWlUisrQPPzDz5cEs4lE34HGKS5rsfggkK0iuQnXv8fSDzIT G0ZDlz5vAy+ULQ6VJ7fqMr2+LgO7rBz8VMWBHzUoZCXMnz1dsL GKRfQUoagUnm7wWt57PTHBJQJtQni+0KIVijr0TgvXL8sWk79S P/tM5IltxMatZbUHIQUUahlHTkgGqzlfFM9osQVIk0= Subject: Re: [conex] comments on draft-moncaster-conex-concepts-uses-02 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 11:36:46 -0000 Hi Alissa, Thanks for taking time to comment on the draft. > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Alissa Cooper > Sent: 06 November 2010 10:30 > To: conex@ietf.org > Subject: [conex] comments on draft-moncaster-conex-concepts-uses-02 > > I have a few small comments on draft-moncaster-conex-concepts-uses-02. > Overall I think the split between use cases and mechanism is working > well. > > Section 1: > It seems a little odd to have a UK-specific reference (to Ofcom data) > about broadband speeds when multi-country data exists (e.g., OECD: > http://www.oecd.org/document/54/0,3343,en_2649_34225_38690102_1_1_1_1,0 > 0.html) > . Thanks, useful reference. OfCom reference is indeed rather too UK-specific > > "Congestion generally results from the interaction of traffic from one > network operator's users with traffic from other users." > While this is the main focus I think it discounts users self- > congesting a bit too much. Maybe something like "Much congestion > results..." would be a little more accurate. Fair point, although in practise once one is beyond the home-gateway there is very little chance that you are the only traffic (in other words whilst you might be fighting yourself for capacity, there are almost certainly other people also fighting for that same capacity). Would "In general, congestion results..." or "Most congestion results..." seem reasonable? > > Section 5.5 > Since it's not immediately obvious how conex can be used for QoS, I > think this use case could benefit from more explanation. There was > some confusion about it which was clarified on the list > (http://www.ietf.org/mail-archive/web/conex/current/threads.html#00127 > ), but that doesn't seem to have been reflected in the draft. This use case is certainly going to get some extensive re-writing. In effect what [Policing Freedom to Use the Internet Resource Pool, Jacquet, Briscoe, Moncaster, 2008] shows is that the user can synthesise something similar to QoS by prioritising their own traffic within a set of bounds imposed by the operator. > > Section 5.6 > Seems like this should be named "Congestion Settlements" or something > similar. The partial vs. full deployment question is one that may have > to be addressed by some subset of use cases, not only this one. Sounds a good name... And partial vs. full deployment is a significant issue for ConEx as a whole (I would expect some of the discussions relating to that to move to the mechanism document). Toby > > Alissa > > > > > > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From toby@moncaster.com Sat Nov 6 04:40:53 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73DD73A687E for ; Sat, 6 Nov 2010 04:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mDtTJrGTq0k for ; Sat, 6 Nov 2010 04:40:49 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id D02513A6883 for ; Sat, 6 Nov 2010 04:40:45 -0700 (PDT) Received: from TobysHP (host86-167-110-184.range86-167.btcentralplus.com [86.167.110.184]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MV2yr-1P2KGc0AcX-00YBED; Sat, 06 Nov 2010 12:40:59 +0100 From: "Toby Moncaster" To: "'Alissa Cooper'" References: <4CC9264F.2080201@it.uc3m.es> <2464076D83FAED4D985BF2622111AAC40F3A7D7270@FHDP1LUMXC7V11.us.one.verizon.com> <000c01cb7741$afa09f30$0ee1dd90$@com> <4B83D7FC-69B9-4281-9203-2D35DBF906F7@cdt.org> In-Reply-To: <4B83D7FC-69B9-4281-9203-2D35DBF906F7@cdt.org> Date: Sat, 6 Nov 2010 11:40:59 -0000 Message-ID: <000601cb7da7$7bd9e8c0$738dba40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: Act9mxJDmiSXgOwaQZ+d07dbU3jbiwAC9a+w Content-Language: en-gb X-Provags-ID: V02:K0:O+apr5eijAIJss4o1gzR67VJ086FTrpYY+A7vQlA3Rc lUBTnG6U2YJlzQ1zSGZ/412gAZrbXIcTwnZfBHHVybVQ9mu0h/ ryVnWU1P3U2EOj0TzBEBD7xyDRZTdPtm9/jH8VW7peS8jftMKW XZSo8wNQSYaUMIDwFPqkISaUpa4oobJsnx5GYts6RM4yIBgTk3 1H1sPOJyNtF0lUaWf0GxWn3o88sMhZRR2DYsccJz1w= Cc: conex@ietf.org Subject: Re: [conex] additional comment on the use cases drafts X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Nov 2010 11:40:53 -0000 Reminds me - I promised to send some comments on this... I will try and get them done before the WG meeting Tuesday, but am also trying to concentrate on other things (like getting a job...) > -----Original Message----- > From: Alissa Cooper [mailto:acooper@cdt.org] > Sent: 06 November 2010 10:12 > To: Toby Moncaster > Cc: 'Mcdysan, David E'; 'marcelo bagnulo braun'; conex@ietf.org > Subject: Re: [conex] additional comment on the use cases drafts > > I may be misreading draft-mcdysan-conex-other-usecases-00.txt, but it > seems to use a broader concept of what conex will be signaling than > what is described in draft-mathis-conex-abstract-mech-00 (e.g., > signaling a measure of burstiness as described in 4.1 in -other- > usecases). I like how the -other-usecases draft describes uses of > conex information that can be made over a longer time interval, but it > seems like there needs to be clarity on what conex is signaling before > integrating all the use cases into a single draft. My initial thoughts on the McDysan draft are that it seems to be expanding the definition of congestion too far. The worry I have is that if we start to look at things like burstiness as a measure of congestion then some of the economics that underpin ConEx might start to break down. Also it is much harder for the network to measure things like burstinesss without the use of quite complex equipment (certainly simple routers couldn't do it). By contrast congestion as measured by competition for space in a queue can be measured in realtime on a packet-by-packet basis... Toby > > Alissa > > On Oct 29, 2010, at 4:17 PM, Toby Moncaster wrote: > > > Seems OK to me too. I'm perfectly happy to try and expand the number > > of use > > cases, at least to start with. Later on I imagine it will become > > clearer > > which use cases will really work... > > > > BTW Dave, I will send some comments on your draft by the start of the > > meeting... > > > > Toby > > > >> -----Original Message----- > >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On > >> Behalf > >> Of Mcdysan, David E > >> Sent: 28 October 2010 14:03 > >> To: marcelo bagnulo braun; conex@ietf.org > >> Subject: Re: [conex] additional comment on the use cases drafts > >> > >> Works for me. > >> > >> As stated in my draft, the intent was to be complementary to the > >> moncaster draft. > >> > >> Thanks, > >> > >> Dave > >> > >>> -----Original Message----- > >>> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] > >>> On Behalf Of marcelo bagnulo braun > >>> Sent: Thursday, October 28, 2010 3:29 AM > >>> To: conex@ietf.org > >>> Subject: [conex] additional comment on the use cases drafts > >>> > >>> Now, we stated that we are planning to ask for adoption of WG > >>> documents for the abstract mechanism and for the use cases.In > >>> the case of the use cases, the situation deserve more > >>> clarification. We have two documents: > >>> draft-moncaster-conex-concepts-uses and > >>> draft-mcdysan-conex-other-usecases-00.txt. > >>> draft-moncaster-conex-concepts-uses was discussed in the > >>> previous meeting and some changes were requested in order to > >>> call for adoption. > >>> The plan is to ask the WG if you feel that the changes have > >>> been made and the draft is in good shape to be the basis for > >>> our deliverable (i.e. > >>> we will ask for adoption of this document) > >>> draft-mcdysan-conex-other-usecases-00.txt otoh, is a new > >>> draft that presents additional use cases. The question that > >>> will be asked to the WG is whether you feel that the use > >>> cases covered in this draft should be covered and in the case > >>> that the answer is affirmative, we will proceed to integrate > >>> these new use cases to the other uses cases we already have. > >>> > >>> Comments? > >>> > >>> Regards, marcelo (on behalf of the co-chairs) > >>> > >>> _______________________________________________ > >>> conex mailing list > >>> conex@ietf.org > >>> https://www.ietf.org/mailman/listinfo/conex > >>> > >> _______________________________________________ > >> conex mailing list > >> conex@ietf.org > >> https://www.ietf.org/mailman/listinfo/conex > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > > From toby@moncaster.com Sun Nov 7 10:40:51 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9AF28C0E0 for ; Sun, 7 Nov 2010 10:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, HELO_EQ_DE=0.35, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN3Kgl9okd32 for ; Sun, 7 Nov 2010 10:40:49 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id 057DB3A68B1 for ; Sun, 7 Nov 2010 10:39:55 -0800 (PST) Received: from TobysHP (host86-167-110-184.range86-167.btcentralplus.com [86.167.110.184]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0LuYSK-1OWvPJ3JNQ-00zr1V; Sun, 07 Nov 2010 19:40:06 +0100 From: "Toby Moncaster" To: "'Mcdysan, David E'" , , "'marcelo bagnulo braun'" , References: <2464076D83FAED4D985BF2622111AAC40F3A33137F@FHDP1LUMXC7V11.us.one.verizon.com> In-Reply-To: <2464076D83FAED4D985BF2622111AAC40F3A33137F@FHDP1LUMXC7V11.us.one.verizon.com> Date: Sun, 7 Nov 2010 18:40:06 -0000 Message-ID: <000701cb7eab$33095c70$991c1550$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActuGCaxW9rcYGnFRLmmBhX9DPAhLgAABKvQBCPLWmA= Content-Language: en-gb X-Provags-ID: V02:K0:ZFoHD7o59vhe3NeFa5XXRGqkSgRcEEA4gJ2zNjlliKy krkI3TMW/ksmR9SYHxdx2zFkdzVp8YEsTukf7wghlMXTtBiDp1 SSsflGqOBGMC1qdVZCq7k/Uh8GVJEq16VlXwAl+80EJmRfBNx5 pytBVpvbUwq4Z4xb1HE92zDsUJdaTVsc1HM24JSuVk2QQV0hE2 lrFBSmi/UX5YMoiOZ4vtUeLNlGNnv7Uju9IQPE3rJ8= Subject: Re: [conex] FW: New Version Notification for draft-mcdysan-conex-other-usecases-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 18:40:51 -0000 Hi David, As promised, here is a quick review of your document. It's a good thing that more people are trying to come up with alternative use cases for ConEx. This simply highlights how powerful a concept congestion exposure is... My top-level comment would be that many of the things you talk about are orthogonal to or supplementary to ConEx. ConEx is a low-level metric that also introduces the concept of using re-feedback for metrics. You seem to be suggesting that re-feedback could be used for other metrics... Your first 3 sections provide a good background to the motivations behind congestion exposure, so I am not going to give comments on them. Jumping to section 4: 4.1 Inequity of heavy versus light users. You seem to be suggesting that there is a need to measure the relative "burstiness" of users. You seem to accept that in the short term the policer proposed in ["Policing Freedom to Use the Internet Resource Pool"; Jacquet, Briscoe, Moncaster; 2008] is able to overcome the inequity between heavy and light users. However I would suggest that such a policer also achieves this same result over longer time scales. Since it is based on a token bucket, a heavy user that is always creating congestion is likely to be constantly running with a less than full bucket. Thus, if congestion increases suddenly (for instance when a light user comes online), the heavy user runs out of credit first and so is throttled. If there isn't sufficient congestion for the heavy user to be running down their bucket then there seems little point in stopping them using the network. To give a (definitely bad) analogy: Just because someone only uses their car at weekends doesn't meant they have a right to take priority over their neighbour that uses their car all day every day. 4.2 Usage Tier/ Volume Feedback. This section seems to be orthogonal to the question of congestion exposure. If I understand you right you are suggesting that by improving the signalling to users (using some form of forward signalling) you are able to apply volume charging/capping more effectively because you allow them to avoid nasty surprises. This is very similar to what seems to be done by many mobile phone companies and indeed does make it more acceptable for users to have variable billing or fixed monthly caps beyond which they are billed. However as I say, this is a separate issue to congestion exposure (see all Bob's stuff about why volume != congestion). 4.3 Feedback on Time of Day, Day of Week Charging. No one is (or should be) claiming that ConEx is a magic bullet that will avoid the need for operators to provision more capacity. What ConEx gives is an ability to better target the upgrades to where they will do the most good. One of the main aims of the policer (mentioned above) is to try and persuade users to shift demand to periods when congestion is lower. Clearly most users would need clever applications to help them do this, but this was one of the core concepts in re-ECN and holds true for ConEx. 4.4 Recharging for Implementing Congestion Pricing. To me this is not strictly a use case for ConEx, rather it is a possible commercial model that might encourage certain content providers to push harder for ConEx to be deployed... Having said that, it is clearly a sensible idea. Hope the comments are useful, and I think it would be sensible if the two use case drafts ended up being combined in some fashion. Perhaps those of you that are in Beijing can have a go at bashing something out? Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mcdysan, David E > Sent: 17 October 2010 17:31 > To: conex@ietf.org; marcelo bagnulo braun; nanditad@google.com > Subject: [conex] FW: New Version Notification for draft-mcdysan-conex- > other-usecases-00 > > > Hi, > > I submitted the following -00 draft today for discussion on the list > and am requesting an agenda slot for the IETF 79 meeting. > > http://www.ietf.org/id/draft-mcdysan-conex-other-usecases-00.txt > > Thanks, > > Dave > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Sunday, October 17, 2010 12:26 PM > To: Mcdysan, David E > Subject: New Version Notification for draft-mcdysan-conex-other- > usecases-00 > > > A new version of I-D, draft-mcdysan-conex-other-usecases-00.txt has > been successfully submitted by Dave McDysan and posted to the IETF > repository. > > Filename: draft-mcdysan-conex-other-usecases > Revision: 00 > Title: Proposed Additional Use Cases for Congestion > Exposure > Creation_date: 2010-10-17 > WG ID: Independent Submission > Number_of_pages: 7 > > Abstract: > This draft proposes some use cases for inclusion in the conex Working > group charter's deliverable for an informational RFC covering use case > description. These use cases are in addition to and/or complement those > described in [UseCases], and focus on forms of congestion exposure that > involve resources other than queues and timeframes other than real- > time. > > > > The IETF Secretariat. > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From rbriscoe@jungle.bt.co.uk Sun Nov 7 19:19:29 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40F063A695C for ; Sun, 7 Nov 2010 19:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXqIa9uUX1GW for ; Sun, 7 Nov 2010 19:19:22 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 2E5E13A6965 for ; Sun, 7 Nov 2010 19:19:22 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 03:19:40 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 03:19:40 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1289186379330; Mon, 8 Nov 2010 03:19:39 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.80.34]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id oA83JWpJ012249; Mon, 8 Nov 2010 03:19:34 GMT Message-Id: <201011080319.oA83JWpJ012249@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Nov 2010 11:19:31 +0800 To: Ingemar Johansson S From: Bob Briscoe In-Reply-To: References: <201010252204.o9PM4fCY002470@bagheera.jungle.bt.co.uk> <201010291213.33125.mkuehle@ikr.uni-stuttgart.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 08 Nov 2010 03:19:40.0376 (UTC) FILETIME=[C7C28D80:01CB7EF3] Cc: "conex@ietf.org" Subject: Re: [conex] comments on draft-mathis-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 03:19:29 -0000 Ingemar, Mirja, You both have a fair point. I shall be talking about why I believe the Credit=20 marking is needed in a presentation in Beijing.=20 Then I intend to write a draft explanation into a=20 posting on the list, as proposed text for the abstract-mech draft. This will allow people to discuss on the list whether they agree it is= needed. Yes, we had some text in=20 draft-briscoe-tsvwg-re-ecn-tcp but I want to try=20 to make the explanation simpler. Bob At 03:21 30/10/2010, Ingemar Johansson S wrote: >Hi > >I agree with Mirja >I would say that this is probably the most=20 >complex part in ConEx, I recall that this was=20 >explained with some detail in the one of the=20 >"Re-ECN for TCP" drafts (don't remember which),=20 >I did not fully get it then so I would really=20 >welcome a thorough explanation of this. > >/Ingemar > > > -----Original Message----- > > From: Mirja K=FChlewind [mailto:mirja.kuehlewind@ikr.uni-stuttgart.de] > > Sent: den 29 oktober 2010 12:14 > > To: conex@ietf.org > > Subject: [conex] comments on draft-mathis-conex-abstract-mech-00 > > > > Hi Matt, Bob, > > > > you introduce a separate signal to send 'credits' but you > > don't really explain why this is needed. Can you give some > > hints about this? > > > > Is this needed for the dropper to ensure that the sender > > declares its congestion honestly or it this mostly helpful to > > get more accurate congestion information in the network? What > > are the security implication here? > > > > Thx, > > Mirja > > > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design =20 From dave.mcdysan@verizon.com Sun Nov 7 21:29:50 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FCF33A6900 for ; Sun, 7 Nov 2010 21:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85fwTwciNFhW for ; Sun, 7 Nov 2010 21:29:49 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 148593A68DA for ; Sun, 7 Nov 2010 21:29:49 -0800 (PST) Received: from irvintrmemf1.verizon.com (irvintrmemf1.verizon.com [138.83.34.101]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id oA85SxcI025300; Mon, 8 Nov 2010 00:29:11 -0500 (EST) X-AuditID: 8a532265-b7b51ae0000052f0-08-4cd78a9e3b46 Received: from smtptpa4.verizon.com ( [138.83.71.177]) by irvintrmemf1.verizon.com (Symantec Brightmail Gateway) with SMTP id AA.5A.21232.E9A87DC4; Sun, 7 Nov 2010 23:29:02 -0600 (CST) Received: from FHDP1LUMXC7HB04.us.one.verizon.com (fhdp1lumxc7hb04.verizon.com [166.68.59.191]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id oA85T1u6019468; Mon, 8 Nov 2010 00:29:01 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Mon, 8 Nov 2010 00:29:01 -0500 From: "Mcdysan, David E" To: Alissa Cooper , Toby Moncaster Date: Mon, 8 Nov 2010 00:25:14 -0500 Thread-Topic: [conex] additional comment on the use cases drafts Thread-Index: Act9mxCxYMigHJd2Q0SF4QRZ2FSp4gBakHnE Message-ID: <2464076D83FAED4D985BF2622111AAC40F95CCF85E@FHDP1LUMXC7V11.us.one.verizon.com> References: <4CC9264F.2080201@it.uc3m.es> <2464076D83FAED4D985BF2622111AAC40F3A7D7270@FHDP1LUMXC7V11.us.one.verizon.com> <000c01cb7741$afa09f30$0ee1dd90$@com>, <4B83D7FC-69B9-4281-9203-2D35DBF906F7@cdt.org> In-Reply-To: <4B83D7FC-69B9-4281-9203-2D35DBF906F7@cdt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] additional comment on the use cases drafts X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 05:29:50 -0000 Hi Alissa, My intent was to try and describe the motivation and objectives, and state = the use cases to see if the working group believes that a particular use ca= se is warranted to meet objectives in a general way. For use cases where th= is is true, then the task would be to define appropriate mechanisms (e.g., = signaling) that would be needed to meet that objective and particular use c= ase. I suggest that if a particular objective and use case is of interest to the= working group then more specific mechanisms could be proposed and discusse= d. I did mention some potential mechanisms (e.g., burstiness) at a high lev= el and these could certainly be expanded. Dave ________________________________________ From: Alissa Cooper [acooper@cdt.org] Sent: Saturday, November 06, 2010 6:11 AM To: Toby Moncaster Cc: Mcdysan, David E; 'marcelo bagnulo braun'; conex@ietf.org Subject: Re: [conex] additional comment on the use cases drafts I may be misreading draft-mcdysan-conex-other-usecases-00.txt, but it seems to use a broader concept of what conex will be signaling than what is described in draft-mathis-conex-abstract-mech-00 (e.g., signaling a measure of burstiness as described in 4.1 in -other- usecases). I like how the -other-usecases draft describes uses of conex information that can be made over a longer time interval, but it seems like there needs to be clarity on what conex is signaling before integrating all the use cases into a single draft. Alissa On Oct 29, 2010, at 4:17 PM, Toby Moncaster wrote: > Seems OK to me too. I'm perfectly happy to try and expand the number > of use > cases, at least to start with. Later on I imagine it will become > clearer > which use cases will really work... > > BTW Dave, I will send some comments on your draft by the start of the > meeting... > > Toby > >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >> Behalf >> Of Mcdysan, David E >> Sent: 28 October 2010 14:03 >> To: marcelo bagnulo braun; conex@ietf.org >> Subject: Re: [conex] additional comment on the use cases drafts >> >> Works for me. >> >> As stated in my draft, the intent was to be complementary to the >> moncaster draft. >> >> Thanks, >> >> Dave >> >>> -----Original Message----- >>> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] >>> On Behalf Of marcelo bagnulo braun >>> Sent: Thursday, October 28, 2010 3:29 AM >>> To: conex@ietf.org >>> Subject: [conex] additional comment on the use cases drafts >>> >>> Now, we stated that we are planning to ask for adoption of WG >>> documents for the abstract mechanism and for the use cases.In >>> the case of the use cases, the situation deserve more >>> clarification. We have two documents: >>> draft-moncaster-conex-concepts-uses and >>> draft-mcdysan-conex-other-usecases-00.txt. >>> draft-moncaster-conex-concepts-uses was discussed in the >>> previous meeting and some changes were requested in order to >>> call for adoption. >>> The plan is to ask the WG if you feel that the changes have >>> been made and the draft is in good shape to be the basis for >>> our deliverable (i.e. >>> we will ask for adoption of this document) >>> draft-mcdysan-conex-other-usecases-00.txt otoh, is a new >>> draft that presents additional use cases. The question that >>> will be asked to the WG is whether you feel that the use >>> cases covered in this draft should be covered and in the case >>> that the answer is affirmative, we will proceed to integrate >>> these new use cases to the other uses cases we already have. >>> >>> Comments? >>> >>> Regards, marcelo (on behalf of the co-chairs) >>> >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >>> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >= From dave.mcdysan@verizon.com Sun Nov 7 21:51:36 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FA7D3A6994 for ; Sun, 7 Nov 2010 21:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnXu-7DojWbT for ; Sun, 7 Nov 2010 21:51:35 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id DA8D23A69B4 for ; Sun, 7 Nov 2010 21:51:32 -0800 (PST) Received: from irvintrmemf1.verizon.com (irvintrmemf1.verizon.com [138.83.34.101]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id oA85pivr028765; Mon, 8 Nov 2010 00:51:45 -0500 (EST) X-AuditID: 8a532265-b7b51ae0000052f0-c4-4cd78ff0db96 Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf1.verizon.com (Symantec Brightmail Gateway) with SMTP id 7B.9A.21232.0FF87DC4; Sun, 7 Nov 2010 23:51:44 -0600 (CST) Received: from FHDP1LUMXC7HB04.us.one.verizon.com (fhdp1lumxc7hb04.verizon.com [166.68.59.191]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id oA85phdR004344; Mon, 8 Nov 2010 00:51:43 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB04.us.one.verizon.com ([2002:a644:3bbf::a644:3bbf]) with mapi; Mon, 8 Nov 2010 00:51:43 -0500 From: "Mcdysan, David E" To: Toby Moncaster , "conex@ietf.org" , "'marcelo bagnulo braun'" , "nanditad@google.com" Date: Mon, 8 Nov 2010 00:51:41 -0500 Thread-Topic: [conex] FW: New Version Notification for draft-mcdysan-conex-other-usecases-00 Thread-Index: ActuGCaxW9rcYGnFRLmmBhX9DPAhLgAABKvQBCPLWmAAF7nJUA== Message-ID: <2464076D83FAED4D985BF2622111AAC40F95CCF85F@FHDP1LUMXC7V11.us.one.verizon.com> References: <2464076D83FAED4D985BF2622111AAC40F3A33137F@FHDP1LUMXC7V11.us.one.verizon.com>, <000701cb7eab$33095c70$991c1550$@com> In-Reply-To: <000701cb7eab$33095c70$991c1550$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [conex] FW: New Version Notification for draft-mcdysan-conex-other-usecases-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 05:51:36 -0000 Hi Toby, Thank you for the comments. A few responses and proposals on how to move forward in line below prefixed= by DM. My Webmail client does not format a response in the usual way. Thanks, Dave ________________________________________ From: Toby Moncaster [toby@moncaster.com] Sent: Sunday, November 07, 2010 1:40 PM To: Mcdysan, David E; conex@ietf.org; 'marcelo bagnulo braun'; nanditad@goo= gle.com Subject: RE: [conex] FW: New Version Notification for draft-mcdysan-conex-o= ther-usecases-00 Hi David, As promised, here is a quick review of your document. It's a good thing tha= t more people are trying to come up with alternative use cases for ConEx. Thi= s simply highlights how powerful a concept congestion exposure is... My top-level comment would be that many of the things you talk about are orthogonal to or supplementary to ConEx. ConEx is a low-level metric that also introduces the concept of using re-feedback for metrics. You seem to b= e suggesting that re-feedback could be used for other metrics... DM- I parse this comment in parentheses using wording from the conex charte= r as follows. Conex is a low-level (IP), re-feedback/metric ("senders info= rm the network about the congestion encountered by previous packets on the= same flow"). Still not sure I understand what you mean by "metric." Your first 3 sections provide a good background to the motivations behind congestion exposure, so I am not going to give comments on them.=20 DM - As mentioned in my response to Alissa, I view this section as a statem= ent of motivation and objectives. IMO, the use cases should strive to meet = as many of these objectives as possible within the bounds of the charter. Jumping to section 4: 4.1 Inequity of heavy versus light users. You seem to be suggesting that there is a need to measure the relative "burstiness" of users. You seem to accept that in the short term the policer proposed in ["Policing Freedom to Use the Internet Resource Pool"; Jacquet, Briscoe, Moncaster; 2008] is able to overcome the inequity between heavy and light users.=20 DM - IMHO, I agree with posts by other operators and comments made in conex= sessions that policing could result in user disssatisfaction. However, it = may be a valid use case for some scenarios and operators. I explicitly chos= e to not mention policing as the type of response to be used since this was= already covered in the moncaster use case draft. However I would suggest that such a policer also achieves this same result over longer time scales. Since it is based on a token bucket, a heavy user that is always creating congestion is likely to be constantly running with a less than ful= l bucket. Thus, if congestion increases suddenly (for instance when a light user comes online), the heavy user runs out of credit first and so is throttled. If there isn't sufficient congestion for the heavy user to be running down their bucket then there seems little point in stopping them using the network.=20 DM - A (deeper) token bucket seems to be a valid mechanism to measure burst= iness. Other mechanisms may be possible in software, not requiring changes = to existing hardware.=20 To give a (definitely bad) analogy: Just because someone only uses their car at weekends doesn't meant they have a right to take priority over their neighbour that uses their car all day every day. 4.2 Usage Tier/ Volume Feedback. This section seems to be orthogonal to the question of congestion exposure. If I understand you right you are suggesting that by improving the signalling to users (using some form of forward signalling) you are able to apply volume charging/capping more effectively because you allow them to avoid nasty surprises. This is very similar to what seems to be done by many mobile phone companies and indeed does make it more acceptable for users to have variable billing or fixed monthly caps beyond which they are billed. However as I say, this is a separate issue to congestion exposure (see all Bob's stuff about why volume !=3D congestion). DM - Here I am viewing the longer term usage tier as a congestible resource= , in which case it is not orthogonal. From the user perspective their expen= ditures are subject to congestion (i.e., overload) and this in fact may be = much more important to many users than congesting a queue. 4.3 Feedback on Time of Day, Day of Week Charging. No one is (or should be= ) claiming that ConEx is a magic bullet that will avoid the need for operator= s to provision more capacity.=20 DM - Why not? What ConEx gives is an ability to better target the upgrades to where they = will do the most good. One of the main aims ofthe policer (mentioned above)= is to try and persuade users to shift demand to periods when congestion is lower.=20 DM - Policing as a form of congestion pricing is a valid mechanism, but I b= elieve it will create increased operational expense in the form of an opera= topr needing to handle and increased level of complaints. Clearly most users would need clever applications to help them do this, but= this was one of the core concepts in re-ECN and holds true for ConEx. DM - Having Conex enable such clever mechanisms is of interest to me. 4.4 Recharging for Implementing Congestion Pricing. To me this is not strictly a use case for ConEx, rather it is a possible commercial model tha= t might encourage certain content providers to push harder for ConEx to be deployed... Having said that, it is clearly a sensible idea. Hope the comments are useful, and I think it would be sensible if the two use case drafts ended up being combined in some fashion. Perhaps those of you that are in Beijing can have a go at bashing something out? DM - Good suggestion, and thanks for your comments. IMO it is not essential= that every operator see a need to implement every use case since the situa= tion differs in a number of factors. Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mcdysan, David E > Sent: 17 October 2010 17:31 > To: conex@ietf.org; marcelo bagnulo braun; nanditad@google.com > Subject: [conex] FW: New Version Notification for draft-mcdysan-conex- > other-usecases-00 > > > Hi, > > I submitted the following -00 draft today for discussion on the list > and am requesting an agenda slot for the IETF 79 meeting. > > http://www.ietf.org/id/draft-mcdysan-conex-other-usecases-00.txt > > Thanks, > > Dave > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Sunday, October 17, 2010 12:26 PM > To: Mcdysan, David E > Subject: New Version Notification for draft-mcdysan-conex-other- > usecases-00 > > > A new version of I-D, draft-mcdysan-conex-other-usecases-00.txt has > been successfully submitted by Dave McDysan and posted to the IETF > repository. > > Filename: draft-mcdysan-conex-other-usecases > Revision: 00 > Title: Proposed Additional Use Cases for Congestion > Exposure > Creation_date: 2010-10-17 > WG ID: Independent Submission > Number_of_pages: 7 > > Abstract: > This draft proposes some use cases for inclusion in the conex Working > group charter's deliverable for an informational RFC covering use case > description. These use cases are in addition to and/or complement those > described in [UseCases], and focus on forms of congestion exposure that > involve resources other than queues and timeframes other than real- > time. > > > > The IETF Secretariat. > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex= From rbriscoe@jungle.bt.co.uk Mon Nov 8 03:35:32 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE4428C14E for ; Mon, 8 Nov 2010 03:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3aAls6oR120 for ; Mon, 8 Nov 2010 03:35:26 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 899A228C152 for ; Mon, 8 Nov 2010 03:35:23 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 11:35:43 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 11:35:42 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1289216141449; Mon, 8 Nov 2010 11:35:41 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.211.240]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id oA8BZamZ014323; Mon, 8 Nov 2010 11:35:38 GMT Message-Id: <201011081135.oA8BZamZ014323@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 08 Nov 2010 19:34:16 +0800 To: suresh.krishnan@ericsson.com, joel.halpern@ericsson.com From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 08 Nov 2010 11:35:42.0989 (UTC) FILETIME=[13A8E3D0:01CB7F39] Cc: ConEx IETF list Subject: [conex] draft-krishnan-6man-header-reserved-bits-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 11:35:32 -0000 Suresh, Joel, Concerning 1/ Firstly, have you had any response from the v6 community on this one? 2/ As well as extra bits, there's a problem of the behaviour of nodes that don't understand the bits (as you've identified in your 6man uniform v6 extension headers draft). The nice thing about the flow-label is most nodes should allow thru anything. 3/ Do you know whether tunnels will copy the flow label to the new outer (both whether they should and whether they actually do)? Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From john@jlc.net Mon Nov 8 07:38:24 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 746083A677D for ; Mon, 8 Nov 2010 07:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VZMk+TuM5Do for ; Mon, 8 Nov 2010 07:38:20 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id E81723A689E for ; Mon, 8 Nov 2010 07:38:18 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6EFD133C3F; Mon, 8 Nov 2010 10:38:40 -0500 (EST) Date: Mon, 8 Nov 2010 10:38:40 -0500 From: John Leslie To: "Mcdysan, David E" Message-ID: <20101108153840.GV82074@verdi> References: <2464076D83FAED4D985BF2622111AAC40F3A33137F@FHDP1LUMXC7V11.us.one.verizon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2464076D83FAED4D985BF2622111AAC40F3A33137F@FHDP1LUMXC7V11.us.one.verizon.com> User-Agent: Mutt/1.4.1i Cc: "conex@ietf.org" Subject: [conex] "Burstiness" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 15:38:24 -0000 Mcdysan, David E wrote: > > http://www.ietf.org/id/draft-mcdysan-conex-other-usecases-00.txt From section 4.1 Inequity of Heavy versus Light Users: ] ] A congestion measure of burstiness (e.g., ratio of peak rate to ] average rate over a longer interval than the tiered bandwidth shaper ] or policer) could be helpful in this use case. In general, a bursty ] packet flow is light (e.g., web surfing) and a non-bursty packet flow ] is heavy (e.g., viewing a lengthy HD video). The destination could ] perform this measure and feed it back to the sender... I'm not sure I correctly follow the context here. I think David is talking about "heavy users" during peak usage: ] ] However, during peak use periods, a heavy user may send at near the ] bandwidth tier while light users may send intermittently. There is a ] need for a means for service providers to equitably assign costs to ] heavy versus light users. I don't think we want to go into the question of "equitably" assigning costs; but there is a valid question of what information we could gather that would assist a provider in that question. I think most of us would agree that if the "heavy user" backs off during congestion, s/he shouldn't be charged "congestion costs" during the period of back-off. Does David think we need to specifically gather to what extent this "heavy user" backs off? (Speaking only for myself, I don't see that need.) In any case, David talks of "burstiness" as ] ] ratio of peak rate to average rate over a longer interval than the ] tiered bandwidth shaper or policer which presumably is a per-flow measurement. I'm curious what David thinks a provider would do with such a per-flow measure. To my provider-centric view, "burstiness" would decay with aggregation; and I'd be concerned only after some aggregation had already occurred. Also, it makes quite a difference (to me) whether we're talking about a point near the sender or near the receiver. Near the receiver, most of the aggregation is long-since done, while near the sender, relatively little has been done. I'm having difficulty seeing what metric could serve both cases... David, presumably, is talking about a _charging_ mechanism (which I guess might charge sender, receiver, or both). While I have no interest in such a charging mechanism myself, I wouldn't want to prohibit it. Maybe it would help me understand if David described one or two examples of such a charging mechanism... Absent such a description, I tend to think of charging sender only, and only based on total volume of congestion-expected marked traffic. In my analysis, any user (heavy or light) that gets out of the way during congested times doesn't deserve to be charged for the congestion avoided. A "heavy" user might or might not be willing to get out of the way. Real-time audio/video would be disinclined to get out of the way -- thus deserving a congestion charge. "Video-on-demand" could get out of the way "briefly", thus deserving a lesser charge. Background downloads could get out of the way for hours on end, thus deserving essentially no congestion charge. But all of these are "heavy" users; and I don't follow how David's "burstiness" measure would help distinguish them. -- John Leslie From rbriscoe@jungle.bt.co.uk Mon Nov 8 09:30:04 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFDC3A69C9 for ; Mon, 8 Nov 2010 09:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n4CBHCCyfb0m for ; Mon, 8 Nov 2010 09:29:57 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id F27A53A698B for ; Mon, 8 Nov 2010 09:29:56 -0800 (PST) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 17:30:17 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 17:30:17 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1289237416261; Mon, 8 Nov 2010 17:30:16 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.211.210]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id oA8HUBvg015792; Mon, 8 Nov 2010 17:30:13 GMT Message-Id: <201011081730.oA8HUBvg015792@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Nov 2010 01:30:02 +0800 To: marcelo bagnulo braun From: Bob Briscoe In-Reply-To: <4CCFF25B.6010404@it.uc3m.es> References: <4CCFF25B.6010404@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 08 Nov 2010 17:30:17.0518 (UTC) FILETIME=[9C4464E0:01CB7F6A] Cc: conex@ietf.org Subject: Re: [conex] about draft-mathis-conex-abstract-mech-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 17:30:04 -0000 Marcelo, Tx for your review - you've pointed out a number of places where we have wrongly assumed too much prior knowledge. A question: altho we don't have a charter item for a security doc, I think it would be useful to have a more detailed treatment of audit and policing. Perhaps that could be a informational report describing experiments with particular designs of security functions, making it clear they are not for standardisation. If we know we are going to do this, it might save putting too much detail in abstract-mech. inline... At 03:13 03/11/2010, marcelo bagnulo braun wrote: >Hi, > >I read this document and i believe is a good starting point for our >deliverable. > >I have some comments though: > >Section 1.1. when i read the document, the definitions included in >this section were not very meaningful to me. In other words, this >section defines a set of conex signals that without proper context >are not very meaningful imho. So i believe that this section needs >to be moved to later on, when the reader has more idea of what is going on. My fault. I persuaded Matt to have terminology here, but you're right; it doesn't work. There will be one or two other items of terminology that will have to go somewhere, e.g. audit function. Perhaps best will be to define terminology as we go through, then have a terminology recap section at the end, for quick reference from other drafts. >Moreover, the Credit signal, i don't believe is properly explained >anywhere in the document, or at least i haven't been able to find >it. I think this needs to be explained in more detail. In >particular, I found the text on section 2, point d quite confusing. Next attempt we will consider putting less at bullet 2d. And, as I've already promised to Mirja/Ingemar, we will add the missing explanation of credit when we talk about the audit function later. >Section 3.1, the strawman encoding talks about bit 48 in the IPv4 >header. Since we are expliclty chartered not to work in v4, i find >this a bit kind of looking for trouble. >I woudl suggest to remove any reference to IPv4 and simply say : >"assume we have a bit in the IP header that we can use for this" I >believe it conveys the same idea and imho it will prevent future troubles. I didn't think the strawman encoding added much. So I wanted to delete it. But I see Matt's point that it leads the reader in gently. If we keep it, we'll take out mention of v4, as you suggest. >In the same section 3.1 It reads: > > Furthermore this > encoding, by itself, does not sufficiently support partial deployment > > >Why not? Yes, this needs explaining better. Partial deployment was bad shorthand for 'loss-based' rather than 'ECN-based ConEx' here. It then refers back to the earlier sentence about needing a distinct codepoint for each. Given you also need a codepoint for neither, you can't get 3 codepoints out of 1 bit. Clearly, we should not have assumed everyone would understand all this by oblique reference using a couple of words. We'll fix. >Section 3.2 seems to assume that the reader is familiar with reecn >or will read about reecn. I've re-read 3.2, and I don't think it assumes or needs re-ECN familiarity. Admittedly 3.2 doesn't describe the re-ECN protocol, but I don't think it leaves the reader wanting or needing to know that. The intention was merely to say re-ECN exists and to give the features of re-ECN we want to avoid, particularly to improve incremental deployability. >My personal prefernce would be that the doc is self contained, at >least w.r.t. to congestion notification. I mean, i would like to see >a document that i can read and i can understand conex, without >needing to read other congestion exposure protocols. Do you think >that would be feasible? I mean it is ok to reference reecn, but i >would prefer if this document contians the main ideas that need to >be understood to understand conex. >My preference would be to explain mre in detail these idea in this section. Self-contained is our intent too. I didn't feel this section compromised that. Perhaps we're too close to re-ECN to be good judges of that tho. I'll see what Matt thinks about the following order instead, which allows the reader to understand a full encoding, before talking about re-ECN. This should help clarify we're only talking about re-ECN to highlight the information it chose to remove (as a compromise to fit the available space): 3.1) Strawman Encoding 3.2) Abstract Encoding 3.3) Re-ECN Encoding 3.4) Encoding Discussion [bring end of S.2 here, from "It is important to note..."] Rationale: Rather than taking them in historical order, it: - starts with the naive idea as a gentle ramp for the tired reader, - then it states the max information the protocol could expose, - then it discusses compromises drawing back from max exposure: - first the compromises re-ECN made (for space reasons), - then ones we might make in the w-g. >In section 3.2.1 > > This last change > permits the transport protocol to carry multiple congestion signals > per round trip, and greatly simplifies accurate auditing. > > >Why is that? We need to spell this out. It's because today's TCP feedback state machine (and derivatives of it) suppresses all but one nack per RTT (Reno's cumulative acks for drop, and the ECE/CWR mechanism for ECN). So if there was >1 congestion indication in an RTT, today's TCP sender could not know, and would re-echo just one. Therefore, without a modified feedback state machine, a TCP sender with the best intentions would not be able to help sometimes showing a shortfall between ConEx and actual congestion, which would be punished by the audit function. >In section 3.3.1 the definition of credit is not clear enough to me. Yup - got that. Altho the most complex part of this doc will be the explanation of credit, I'm happy we should be able to keep the whole doc not much longer than it is now. Thanks again. Bob >Regards, marcelo > > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Mon Nov 8 09:38:35 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE5E23A68F9 for ; Mon, 8 Nov 2010 09:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghpIsbLljg03 for ; Mon, 8 Nov 2010 09:38:29 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id B2D483A6848 for ; Mon, 8 Nov 2010 09:38:28 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 17:38:49 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 17:38:49 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1289237927960; Mon, 8 Nov 2010 17:38:47 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.211.210]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id oA8Hch7o015827; Mon, 8 Nov 2010 17:38:44 GMT Message-Id: <201011081738.oA8Hch7o015827@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Nov 2010 01:38:44 +0800 To: Alissa Cooper From: Bob Briscoe In-Reply-To: <61AC60DD-4EC8-4229-9E96-E3EA78FDBF6E@cdt.org> References: <61AC60DD-4EC8-4229-9E96-E3EA78FDBF6E@cdt.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 08 Nov 2010 17:38:49.0209 (UTC) FILETIME=[CD423E90:01CB7F6B] Cc: conex@ietf.org Subject: Re: [conex] partial deployment in draft-mathis-conex-abstract-mech-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 17:38:36 -0000 Alissa, In an ideal world, all the requirements would be MUSTs, but we know we may have encoding constraints that mean we have to compromise some requirements. We didn't want to tie the w-g down. Bear in mind this doc is aiming to grow up into an RFC that should be timeless. Therefore, it should not just reflect the current charter, but also potential re-chartering. Given we ought to one day think about a v4 encoding too, we might need to allow ourselves more leeway than with v6 (or the difficulty might be the other way round!). Bob At 02:35 07/11/2010, Alissa Cooper wrote: >In draft-mathis-conex-abstract-mech-00 it says that "the conex signal >SHOULD be useful under only a partial deployment." Shouldn't that >SHOULD be a MUST based on the charter text? From the charter: > >"However, the CONEX WG will initially focus on one use case, where the >end hosts and the network that contains the destination end host are >CONEX-enabled but other networks need not be." > >Alissa > > > > > > > > > > > > >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Mon Nov 8 14:45:33 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E880A3A68FF for ; Mon, 8 Nov 2010 14:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWg1EL4gTZeS for ; Mon, 8 Nov 2010 14:45:27 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id CB81C3A68DC for ; Mon, 8 Nov 2010 14:45:26 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 22:45:48 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 22:45:47 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1289256347141; Mon, 8 Nov 2010 22:45:47 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.211.210]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id oA8Mjhmh016638; Mon, 8 Nov 2010 22:45:44 GMT Message-Id: <201011082245.oA8Mjhmh016638@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Nov 2010 06:45:42 +0800 To: "Mcdysan, David E" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 08 Nov 2010 22:45:47.0717 (UTC) FILETIME=[AF8B8750:01CB7F96] Cc: ConEx IETF list Subject: [conex] Additional responses to draft-mcdysan-conex-other-usecases-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 22:45:34 -0000 David, My main review comments were similar to Alissa's and Toby's. So I'll pitch in to their thread where I differ slightly, but otherwise I'm just nodding. But, rather than make that thread too complicated, I've added a few different points here in a separate thread. First, I want to say it was really good to get your angle on this. Thank you. #/ Don't mention congestion pricing? Some of your use-cases might fall foul of the constraint in the ConEx charter that says: "Congestion-based billing is not within the scope of the WG" I was happy to go along with that charter constraint, because I don't think any ISP would want to do congestion-based billing anyway - certainly not at the retail level. But how do you read this charter constraint? I read it as we shouldn't work on mechanisms to actually *do* congestion-based billing. Do you think it's OK to talk about it as a use-case, particularly at the wholesale level between operators? #/ Heavy user = heavy volume, or heavy congestion-volume? Once an operator has visibility of congestion-volume, won't they define a heavy users by congestion-volume, not volume? That's the whole point of the use-case encouraging LEDBAT-like transports. Won't an ISP be willing to allow their users to transfer as much as they want, as long as their transport jumps out the way whenever there's the slightest sign of congestion? Put another way, once you have a metric for the incremental cost of one user's traffic on others, limiting volume irrespective of cost could be construed as arbitrary discrimination against high volume users who are being careful to cost very little. Sure, absent ConEx, volume is a (poor) proxy for congestion-volume. But once we have ConEx, the landscape changes. ==Metrics== #/ Congestion-volume does automatically what the other metrics try to do. I'm not sure whether the text in 4.1 is saying we need more than ConEx or it's saying ConEx should do all this. I've got a lot more to say about the metrics you have suggested, but manyana - I need to get to bed... ==Misconceptions== #/ You've cited me as saying "...it's complex for users to manage their activity to control the price they pay..." I don't think I said that, because I don't really agree. * First, it's enough for users to just do what they want to do, and if their bill gets too high for them, they tend to do less, just like in other walks of life. * Second, I believe minimising congestion can all be delegated to their machine (just as TCP attempts to now), so no problem there. #/ 3rd bullet in 4.2: This talks about feedback from the network being more important if some form of congestion pricing is in force (I guess you include congestion policing in that?) The very subtle but important idea behind re-ECN (and hopefully ConEx) is that the accounting metric is wholly controlled by the sender. The provider makes the sender accountable for the congestion the sender says it expects it will cause, NOT the congestion that actually happened once packets have been through the network. If the sender gets feedback from the receiver about a sudden increase in congestion, it can just stop sending packets, and not send any more ConEx markings either (if it is limited to an allowance, it will not draw down any more). But if the sender wants to continue (as it usually will), it has to be accountable for the congestion it just contributed to by re-echoing that amount of ConEx markings. If it's using something like TCP, of course it will also go slower, so as to avoid the congestion continuing. So, there is full transparency. The network doesn't need to give the source any more feedback about congestion than it already does on the forwaard path (ie by dropping stuff). But the ConEx audit function incentivises the source to get accurate timely e2e feedback from the receiver (which most transports already do, of course). So yes, feedback from the network is important, but no more is needed for ConEx than we already have. ConEx is about adding feedback from source to network, which is where TCP/IP is deficient. #/ Not counting (last para of 4.2) That's an important item to mention. There might be cases where the operator has flunked and needs to tell the user that they will get a congestion rebate or something. I don't think this should be done in real-time (by telling the user "I'm not counting congestion at the mo"), which could lead to congestion-collapse. But, there might need to be a later refill of the customer's allowance, perhaps after a capacity outage, where the operator wants to apologise not punish its users. This generally falls into the category of customer <-> traffic-management-node interface. I don't think it's in ConEx scope to define these standards, but we should certainly add our voice to those wanting to define them (e.g. Dave Oran). More later... Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From dave.mcdysan@verizon.com Mon Nov 8 16:39:29 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4AD3A6927 for ; Mon, 8 Nov 2010 16:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci-6aR5t0rzP for ; Mon, 8 Nov 2010 16:39:28 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 160EB3A687C for ; Mon, 8 Nov 2010 16:39:27 -0800 (PST) Received: from irvintrmemf1.verizon.com (irvintrmemf1.verizon.com [138.83.34.101]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id oA90bZQE005289; Mon, 8 Nov 2010 19:39:29 -0500 (EST) X-AuditID: 8a532265-b7b51ae0000052f0-3c-4cd898312236 Received: from smtptpa4.verizon.com ( [138.83.71.177]) by irvintrmemf1.verizon.com (Symantec Brightmail Gateway) with SMTP id 9F.51.21232.13898DC4; Mon, 8 Nov 2010 18:39:14 -0600 (CST) Received: from FHDP1LUMXC7HB01.us.one.verizon.com (fhdp1lumxc7hb01.verizon.com [166.68.59.188]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id oA90dCZZ004588; Mon, 8 Nov 2010 19:39:13 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB01.us.one.verizon.com ([2002:a644:3bbc::a644:3bbc]) with mapi; Mon, 8 Nov 2010 19:39:13 -0500 From: "Mcdysan, David E" To: John Leslie Date: Mon, 8 Nov 2010 19:39:12 -0500 Thread-Topic: "Burstiness" Thread-Index: Act/WxdGp50ki5/lTWi5Xg38vhTOGAASHPoV Message-ID: <2464076D83FAED4D985BF2622111AAC40F95CCF862@FHDP1LUMXC7V11.us.one.verizon.com> References: <2464076D83FAED4D985BF2622111AAC40F3A33137F@FHDP1LUMXC7V11.us.one.verizon.com>, <20101108153840.GV82074@verdi> In-Reply-To: <20101108153840.GV82074@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] "Burstiness" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 00:39:29 -0000 Hi John, Some responses in line below prefixed by DM. Thanks for the thoughtful questions and comments. Regards, Dave ________________________________________ From: John Leslie [john@jlc.net] Sent: Monday, November 08, 2010 10:38 AM To: Mcdysan, David E Cc: conex@ietf.org Subject: "Burstiness" Mcdysan, David E wrote: > > http://www.ietf.org/id/draft-mcdysan-conex-other-usecases-00.txt From section 4.1 Inequity of Heavy versus Light Users: ] ] A congestion measure of burstiness (e.g., ratio of peak rate to ] average rate over a longer interval than the tiered bandwidth shaper ] or policer) could be helpful in this use case. In general, a bursty ] packet flow is light (e.g., web surfing) and a non-bursty packet flow ] is heavy (e.g., viewing a lengthy HD video). The destination could ] perform this measure and feed it back to the sender... I'm not sure I correctly follow the context here. I think David is talking about "heavy users" during peak usage: DM - Yes, that is what I intended (the following is from the paragraph prio= r to the one above from the draft. ] ] However, during peak use periods, a heavy user may send at near the ] bandwidth tier while light users may send intermittently. There is a ] need for a means for service providers to equitably assign costs to ] heavy versus light users. I don't think we want to go into the question of "equitably" assigning costs; but there is a valid question of what information we could gather that would assist a provider in that question. DM - Agreed. I think most of us would agree that if the "heavy user" backs off during congestion, s/he shouldn't be charged "congestion costs" during the period of back-off. DM - I think what you describe is a specific mechanism, which is already de= scribed in the moncaster use case draft. As I mentioned earlier in response= to Alissa, I tried not to go too much into mechanism since the topic was u= se cases, but let me try now to briefly describe what I had in mind.I was t= hinking that instead of only charging on short term average bandwidth of a = shaper as is done today and results in the 80/20 experience reported by Var= ian that shaping and possibly charging is based upon longer term metrics, s= uch as the burstiness. In the next section 4.2 I mention that usage tier ac= counting partially addresses this issue, but=20 "does not address situation where heavy users send at a high rate, but only for a fraction of the usage measurement interval (e.g., only for a few hours or days during a month)." DM - Also note that "queue congestion" may not actually occur during a peak= period. IMO customers should not experience different behaviors depending = upon the state of capacity provisioned in the network, which could occur wi= th the way that conex is currently defined. Does David think we need to specifically gather to what extent this "heavy user" backs off? (Speaking only for myself, I don't see that need.) DM - No, see above. In any case, David talks of "burstiness" as ] ] ratio of peak rate to average rate over a longer interval than the ] tiered bandwidth shaper or policer which presumably is a per-flow measurement. I'm curious what David thinks a provider would do with such a per-flow measure. DM - See above. To my provider-centric view, "burstiness" would decay with aggregation; and I'd be concerned only after some aggregation had already occurred. DM - Not on a per flow basis. The non-work conserving shaper is the resourc= e that can be congested, not an aggregate interface. I think that congestio= n of an aggregate interface is a different use case than what I have in min= d, and may already be covered in the moncaster draft. Also, it makes quite a difference (to me) whether we're talking about a point near the sender or near the receiver. Near the receiver, most of the aggregation is long-since done, while near the sender, relatively little has been done. I'm having difficulty seeing what metric could serve both cases... DM - Agreed. see above, I think there at least two cases: per flow near rec= eiver and aggregate at other points (e.g., between ISPs). David, presumably, is talking about a _charging_ mechanism (which I guess might charge sender, receiver, or both). While I have no interest in such a charging mechanism myself, I wouldn't want to prohibit it. Maybe it would help me understand if David described one or two examples of such a charging mechanism... DM - Fairf comment. I made a first pass at such a description above.=20 Absent such a description, I tend to think of charging sender only, and only based on total volume of congestion-expected marked traffic. In my analysis, any user (heavy or light) that gets out of the way during congested times doesn't deserve to be charged for the congestion avoided. DM - This is a valid use case, but not what I had in mind. A "heavy" user might or might not be willing to get out of the way. Real-time audio/video would be disinclined to get out of the way -- thus deserving a congestion charge. "Video-on-demand" could get out of the way "briefly", thus deserving a lesser charge. Background downloads could get out of the way for hours on end, thus deserving essentially no congestion charge. But all of these are "heavy" users; and I don't follow how David's "burstiness" measure would help distinguish them. DM - The feedback I had in mind is to senders regarding the congestion expe= rienced by a non-work conserving shaper that in addition to a short term ra= te also has the characteristic of allowed burstiness over a longer-time int= erval. It is congestion of this per user/flow interface that would enable a= form of charging more suited to the heavy/light users reported by Varian a= nd observed on the networks with which I have access to such measurements. -- John Leslie = From dave.mcdysan@verizon.com Mon Nov 8 17:16:24 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60B2F3A68F8 for ; Mon, 8 Nov 2010 17:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmvSALzX2LBr for ; Mon, 8 Nov 2010 17:16:23 -0800 (PST) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by core3.amsl.com (Postfix) with ESMTP id 4B6933A6A10 for ; Mon, 8 Nov 2010 17:16:12 -0800 (PST) Received: from irvintrmemf3.verizon.com (irvintrmemf3.verizon.com [138.83.34.103]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id oA91Fmii023935; Mon, 8 Nov 2010 20:16:24 -0500 (EST) X-AuditID: 8a532267-b7b77ae000001d07-28-4cd8a0df54c4 Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf3.verizon.com (Symantec Mail Security) with SMTP id 12.5A.07431.FD0A8DC4; Mon, 8 Nov 2010 19:16:15 -0600 (CST) Received: from FHDP1LUMXC7HB05.us.one.verizon.com (fhdp1lumxc7hb05.verizon.com [166.68.59.192]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id oA91GEMs022569; Mon, 8 Nov 2010 20:16:15 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB05.us.one.verizon.com ([2002:a644:3bc0::a644:3bc0]) with mapi; Mon, 8 Nov 2010 20:16:14 -0500 From: "Mcdysan, David E" To: Bob Briscoe Date: Mon, 8 Nov 2010 20:16:14 -0500 Thread-Topic: Additional responses to draft-mcdysan-conex-other-usecases-00 Thread-Index: Act/lrcvEpQxwJlpSt6S1XY9ACY29gAD+BiN Message-ID: <2464076D83FAED4D985BF2622111AAC40F95CCF863@FHDP1LUMXC7V11.us.one.verizon.com> References: <201011082245.oA8Mjhmh016638@bagheera.jungle.bt.co.uk> In-Reply-To: <201011082245.oA8Mjhmh016638@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: ConEx IETF list Subject: Re: [conex] Additional responses to draft-mcdysan-conex-other-usecases-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 01:16:24 -0000 Hi Bob, Thanks for the review and comments. Some responses in line below prefixed by DM. Regards, Dave ________________________________________ From: Bob Briscoe [rbriscoe@jungle.bt.co.uk] Sent: Monday, November 08, 2010 5:45 PM To: Mcdysan, David E Cc: ConEx IETF list Subject: Additional responses to draft-mcdysan-conex-other-usecases-00 David, My main review comments were similar to Alissa's and Toby's. So I'll pitch in to their thread where I differ slightly, but otherwise I'm just nodding. But, rather than make that thread too complicated, I've added a few different points here in a separate thread. First, I want to say it was really good to get your angle on this. Thank yo= u. #/ Don't mention congestion pricing? Some of your use-cases might fall foul of the constraint in the ConEx charter that says: "Congestion-based billing is not within the scope of the WG" I was happy to go along with that charter constraint, because I don't think any ISP would want to do congestion-based billing anyway - certainly not at the retail level. DM - I would not want to preclude this use case, and tried to give several = examples in my draft. I viewed a number of the talks in the technical plena= ry as dealing with "congestion pricing" at the retail level (either directl= y to an end user of via recharging). But how do you read this charter constraint? I read it as we shouldn't work on mechanisms to actually *do* congestion-based billing.=20 DM - Good question. I read the charter as that actual protocols and message= exchanges to *do* billing were out of scope, but that usage information wh= ich could be used as inputs to such billing was in scope. Would be good to = clarify this point. Do you think it's OK to talk about it as a use-case, particularly at the wholesale level between operators? DM - As discussed some on the list, I don't think there is consensus that i= nter-operator settlements is something all operators want to do, but I woul= d certainly want to include it (e.g., for at least recharging), as well as = some forms of congestion oriented usage collection at the retail level. #/ Heavy user =3D heavy volume, or heavy congestion-volume? Once an operator has visibility of congestion-volume, won't they define a heavy users by congestion-volume, not volume? That's the whole point of the use-case encouraging LEDBAT-like transports. Won't an ISP be willing to allow their users to transfer as much as they want, as long as their transport jumps out the way whenever there's the slightest sign of congestion? Put another way, once you have a metric for the incremental cost of one user's traffic on others, limiting volume irrespective of cost could be construed as arbitrary discrimination against high volume users who are being careful to cost very little. DM - I think the use case you describe is already well described in the mon= caster draft. I tried to further describe the "burstiness" mechanism that I= had in mind in my response to John Leslie. DM - What I see as an issue with this method is the unpredictability of thi= s as seen from the user perspective. A user could engage in similar behavio= r and in one instance see no congestion but in another see a great deal of = congestion. This arises from an (unachievable expectation) that a fixed ban= dwidth tier is a guarantee to send at that rate for an indefinite period of= time when in fact statistical multiplexing is being used. Sure, absent ConEx, volume is a (poor) proxy for congestion-volume. But once we have ConEx, the landscape changes. =3D=3DMetrics=3D=3D #/ Congestion-volume does automatically what the other metrics try to do. I'm not sure whether the text in 4.1 is saying we need more than ConEx or it's saying ConEx should do all this. I've got a lot more to say about the metrics you have suggested, but manyana - I need to get to bed... DM - Please review my response to John.=20 =3D=3DMisconceptions=3D=3D #/ You've cited me as saying "...it's complex for users to manage their activity to control the price they pay..." I don't think I said that, because I don't really agree. DM - My apologies, I cited Varian and your statement from the Maastricht te= chnical plenary "but unpredictability of congestion billing is unpopular"=20 Can certainly remove your talk as a reference or reword if this text along = these lines is to be included in a wg doc. * First, it's enough for users to just do what they want to do, and if their bill gets too high for them, they tend to do less, just like in other walks of life. DM - That is a possible use case, but the one I had in mind is the one is m= ore like the one that Toby described as helping users avoid "surprises" at the end of the month, as he said tha= t currently some wireless providers use. Here I had in mind the congestible= resource being the monthly usage tier. * Second, I believe minimising congestion can all be delegated to their machine (just as TCP attempts to now), so no problem there. #/ 3rd bullet in 4.2: This talks about feedback from the network being more important if some form of congestion pricing is in force (I guess you include congestion policing in that?) DM - I think policing is a use case already covered in the moncaster draft.= =20 DM - If policing is a form of pricing, then the charter issue of billing yo= u mentioned earlier may be relevant here. I viewed "policing" as a form of = traffic management as stated in the wg charter. The classification of polic= ing is an area I think the wg should discuss/agree. I view policing as more= of a reaction in the event that other mechanisms have not worked and not a= s a usual mode of operation, it can create unpredictability and potentially= cause user complaints as voice by others on the list and in the Maastricht= plenary. The very subtle but important idea behind re-ECN (and hopefully ConEx) is that the accounting metric is wholly controlled by the sender. The provider makes the sender accountable for the congestion the sender says it expects it will cause, NOT the congestion that actually happened once packets have been through the network. If the sender gets feedback from the receiver about a sudden increase in congestion, it can just stop sending packets, and not send any more ConEx markings either (if it is limited to an allowance, it will not draw down any more). But if the sender wants to continue (as it usually will), it has to be accountable for the congestion it just contributed to by re-echoing that amount of ConEx markings. If it's using something like TCP, of course it will also go slower, so as to avoid the congestion continuing. So, there is full transparency. The network doesn't need to give the source any more feedback about congestion than it already does on the forwaard path (ie by dropping stuff). But the ConEx audit function incentivises the source to get accurate timely e2e feedback from the receiver (which most transports already do, of course). DM - Thanks for the summary. I think that I understand the use case that is= the focus of the moncaster draft as congestion occurring in a work conserv= ing scheduler at queues at various points in the network. The principal ide= a in my draft is that there are other congestible resource use cases for wh= ich feedback can be useful, a non-work conserving user-facing shaper, a lon= g time period (e.g., monthly) usage counting tier, historical (as modulated= by actual congestion using a method you summarized above) utilization for = time of day/week, and recharging indications to a sender. So yes, feedback from the network is important, but no more is needed for ConEx than we already have. ConEx is about adding feedback from source to network, which is where TCP/IP is deficient. #/ Not counting (last para of 4.2) That's an important item to mention. There might be cases where the operator has flunked and needs to tell the user that they will get a congestion rebate or something. I don't think this should be done in real-time (by telling the user "I'm not counting congestion at the mo"), which could lead to congestion-collapse. But, there might need to be a later refill of the customer's allowance, perhaps after a capacity outage, where the operator wants to apologise not punish its users= . This generally falls into the category of customer <-> traffic-management-node interface. I don't think it's in ConEx scope to define these standards, but we should certainly add our voice to those wanting to define them (e.g. Dave Oran). DM - Good customer service is always desirable, and I think such a means is= worthwhile. Would be interested in hearing more about this. More later... Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design= From john@jlc.net Mon Nov 8 17:26:52 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B9F328C0F9 for ; Mon, 8 Nov 2010 17:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.979 X-Spam-Level: X-Spam-Status: No, score=-105.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luHlD3+w5OPx for ; Mon, 8 Nov 2010 17:26:51 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id BF0B93A68F8 for ; Mon, 8 Nov 2010 17:26:50 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 6E94933C27; Mon, 8 Nov 2010 20:27:13 -0500 (EST) Date: Mon, 8 Nov 2010 20:27:13 -0500 From: John Leslie To: "Mcdysan, David E" Message-ID: <20101109012713.GZ82074@verdi> References: <20101108153840.GV82074@verdi> <2464076D83FAED4D985BF2622111AAC40F95CCF862@FHDP1LUMXC7V11.us.one.verizon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2464076D83FAED4D985BF2622111AAC40F95CCF862@FHDP1LUMXC7V11.us.one.verizon.com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] "Burstiness" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 01:26:52 -0000 (Hopefully I'm picking out the right sections of David's response...) Mcdysan, David E wrote: > [John Leslie wrote:] > >> I think most of us would agree that if the "heavy user" backs off >> during congestion, s/he shouldn't be charged "congestion costs" during >> the period of back-off. > > DM - I think what you describe is a specific mechanism, which is already > described in the moncaster use case draft. I was not intending to describe a mechanism... > As I mentioned earlier in response to Alissa, I tried not to go too much > into mechanism since the topic was use cases, but let me try now to > briefly describe what I had in mind. I was thinking that instead of only > charging on short term average bandwidth of a shaper as is done today > and results in the 80/20 experience reported by Varian that shaping and > possibly charging is based upon longer term metrics, such as the > burstiness. In the next section 4.2 I mention that usage tier accounting > partially addresses this issue, but > > "does not address situation where heavy users send at a high rate, > but only for a fraction of the usage measurement interval (e.g., > only for a few hours or days during a month)." Do I understand that David intends this to change the mechanism for charging _receivers_? > DM - Also note that "queue congestion" may not actually occur during a > peak period. IMO customers should not experience different behaviors > depending upon the state of capacity provisioned in the network, which > could occur with the way that conex is currently defined. I must be misunderstanding: how can users _avoid_ a different experience during a period of significant congestion? >> To my provider-centric view, "burstiness" would decay with aggregation; >> and I'd be concerned only after some aggregation had already occurred. > > DM - Not on a per flow basis. The non-work conserving shaper is the > resource that can be congested, not an aggregate interface. A reference to "non-work conserving shaper" would help, I think. >> Also, it makes quite a difference (to me) whether we're talking about >> a point near the sender or near the receiver. Near the receiver, most >> of the aggregation is long-since done, while near the sender, relatively >> little has been done. I'm having difficulty seeing what metric could >> serve both cases... > > DM - Agreed. see above, I think there at least two cases: per flow near > receiver and aggregate at other points (e.g., between ISPs). (Hopefully I interpret this correctly: that David is thinking about near-the-receiver and "charging" the receiver.) >> A "heavy" user might or might not be willing to get out of the way. >> Real-time audio/video would be disinclined to get out of the way -- >> thus deserving a congestion charge. "Video-on-demand" could get out of >> the way "briefly", thus deserving a lesser charge. Background downloads >> could get out of the way for hours on end, thus deserving essentially >> no congestion charge. But all of these are "heavy" users; and I don't >> follow how David's "burstiness" measure would help distinguish them. > > DM - The feedback I had in mind is to senders regarding the congestion > experienced by a non-work conserving shaper that in addition to a short > term rate also has the characteristic of allowed burstiness over a > longer-time interval. I'm guessing here -- that David's "non-work conserving shaper" is dropping some packets or otherwise marking as congestion some traffic which isn't actual queue congestion. Please correct me if I'm guessing wrong... > It is congestion of this per user/flow interface that would enable a > form of charging more suited to the heavy/light users reported by > Varian and observed on the networks with which I have access to such > measurements. What "charging" is "suitable" is not in-scope here. However, (if I'm guessing correctly) "congestion" which isn't actual queue-based congestion is probably still "congestion" which may deserve to be made visible throughout the path under a ConEx protocol. A few questions come to mind: - is there some action to be taken by any point other than receiver and sender? - is there an intent to collect and correlate this information elsewhere? - does David have in mind some specific metric useful under a different business model? -- John Leslie From ingemar.s.johansson@ericsson.com Mon Nov 8 18:43:38 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEFC3A6941 for ; Mon, 8 Nov 2010 18:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hH4tUUXu2Pd for ; Mon, 8 Nov 2010 18:43:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 33C9C28C198 for ; Mon, 8 Nov 2010 18:43:05 -0800 (PST) X-AuditID: c1b4fb39-b7b54ae000003464-53-4cd8b53ca1c6 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9A.BC.13412.C35B8DC4; Tue, 9 Nov 2010 03:43:08 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 9 Nov 2010 03:43:08 +0100 From: Ingemar Johansson S To: Bob Briscoe , marcelo bagnulo braun Date: Tue, 9 Nov 2010 03:42:47 +0100 Thread-Topic: [conex] about draft-mathis-conex-abstract-mech-00.txt Thread-Index: Act/f5fXfU4YdFMHTPCmGoVN+JsQYwANbjVQ Message-ID: References: <4CCFF25B.6010404@it.uc3m.es> <201011081730.oA8HUBvg015792@bagheera.jungle.bt.co.uk> In-Reply-To: <201011081730.oA8HUBvg015792@bagheera.jungle.bt.co.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] about draft-mathis-conex-abstract-mech-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 02:43:38 -0000 Hi Just a comment on the mention of re-ECN and bit 48 in IPv4. I agree that it= may be asking for trouble. Still it does well as an educational example so= I have nothing against keeping it in the abstract mechanism draft for inst= ance as a appendix. You may add a proper disclaimer in the appendix to be o= n the safe side. For many people (such as yours truly) a "real example" mak= es it a lot easier to understand the more abstract part, bits are sometimes= easier to comprehend than abstact codepoints.=20 Most of the conex stuff is fairly easy to understand, but there are things = such as the initial credit marking that may benefit from a real example. I am not that convinced about the need for a strawman encoding section. I w= ould belive that it should be sufficient with the abstract encoding and in = an appendix a description of how the abstract mechanism is conflated to Re-= ECN. I guess the final ConEx solution is described in a separate document ? my 5 RMB /Ingemar > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 > Sent: den 9 november 2010 01:30 > To: marcelo bagnulo braun > Cc: conex@ietf.org > Subject: Re: [conex] about draft-mathis-conex-abstract-mech-00.txt >=20 > Marcelo, >=20 > Tx for your review - you've pointed out a number of places=20 > where we have wrongly assumed too much prior knowledge. >=20 > A question: altho we don't have a charter item for a security=20 > doc, I think it would be useful to have a more detailed=20 > treatment of audit and policing. Perhaps that could be a=20 > informational report describing experiments with particular=20 > designs of security functions, making it clear they are not=20 > for standardisation. If we know we are going to do this, it=20 > might save putting too much detail in abstract-mech. >=20 > inline... >=20 > At 03:13 03/11/2010, marcelo bagnulo braun wrote: > >Hi, > > > >I read this document and i believe is a good starting point for our=20 > >deliverable. > > > >I have some comments though: > > > >Section 1.1. when i read the document, the definitions=20 > included in this=20 > >section were not very meaningful to me. In other words, this section=20 > >defines a set of conex signals that without proper context=20 > are not very=20 > >meaningful imho. So i believe that this section needs to be moved to=20 > >later on, when the reader has more idea of what is going on. >=20 > My fault. I persuaded Matt to have terminology here, but=20 > you're right; it doesn't work. >=20 > There will be one or two other items of terminology that will=20 > have to go somewhere, e.g. audit function. Perhaps best will=20 > be to define terminology as we go through, then have a=20 > terminology recap section at the end, for quick reference=20 > from other drafts. >=20 >=20 > >Moreover, the Credit signal, i don't believe is properly explained=20 > >anywhere in the document, or at least i haven't been able to=20 > find it. I=20 > >think this needs to be explained in more detail. In=20 > particular, I found=20 > >the text on section 2, point d quite confusing. >=20 > Next attempt we will consider putting less at bullet 2d. >=20 > And, as I've already promised to Mirja/Ingemar, we will add=20 > the missing explanation of credit when we talk about the=20 > audit function later. >=20 >=20 >=20 > >Section 3.1, the strawman encoding talks about bit 48 in the IPv4=20 > >header. Since we are expliclty chartered not to work in v4, i find=20 > >this a bit kind of looking for trouble. > >I woudl suggest to remove any reference to IPv4 and simply say :=20 > >"assume we have a bit in the IP header that we can use for this" I=20 > >believe it conveys the same idea and imho it will prevent=20 > future troubles. >=20 > I didn't think the strawman encoding added much. So I wanted to=20 > delete it. But I see Matt's point that it leads the reader in gently. >=20 > If we keep it, we'll take out mention of v4, as you suggest. >=20 >=20 > >In the same section 3.1 It reads: > > > > Furthermore this > > encoding, by itself, does not sufficiently support=20 > partial deployment > > > > > >Why not? >=20 > Yes, this needs explaining better. Partial deployment was bad=20 > shorthand for 'loss-based' rather than 'ECN-based ConEx' here. It=20 > then refers back to the earlier sentence about needing a distinct=20 > codepoint for each. Given you also need a codepoint for neither, you=20 > can't get 3 codepoints out of 1 bit. >=20 > Clearly, we should not have assumed everyone would understand all=20 > this by oblique reference using a couple of words. We'll fix. >=20 >=20 > >Section 3.2 seems to assume that the reader is familiar with reecn=20 > >or will read about reecn. >=20 > I've re-read 3.2, and I don't think it assumes or needs re-ECN=20 > familiarity. Admittedly 3.2 doesn't describe the re-ECN protocol, but=20 > I don't think it leaves the reader wanting or needing to know that.=20 > The intention was merely to say re-ECN exists and to give the=20 > features of re-ECN we want to avoid, particularly to improve=20 > incremental deployability. >=20 > >My personal prefernce would be that the doc is self contained, at=20 > >least w.r.t. to congestion notification. I mean, i would like to see=20 > >a document that i can read and i can understand conex, without=20 > >needing to read other congestion exposure protocols. Do you think=20 > >that would be feasible? I mean it is ok to reference reecn, but i=20 > >would prefer if this document contians the main ideas that need to=20 > >be understood to understand conex. > >My preference would be to explain mre in detail these idea=20 > in this section. >=20 > Self-contained is our intent too. I didn't feel this section=20 > compromised that. Perhaps we're too close to re-ECN to be good judges=20 > of that tho. >=20 > I'll see what Matt thinks about the following order instead, which=20 > allows the reader to understand a full encoding, before talking about=20 > re-ECN. This should help clarify we're only talking about re-ECN to=20 > highlight the information it chose to remove (as a compromise to fit=20 > the available space): > 3.1) Strawman Encoding > 3.2) Abstract Encoding > 3.3) Re-ECN Encoding > 3.4) Encoding Discussion [bring end of S.2 here, from "It is=20 > important to note..."] >=20 > Rationale: Rather than taking them in historical order, it: > - starts with the naive idea as a gentle ramp for the tired reader, > - then it states the max information the protocol could expose, > - then it discusses compromises drawing back from max exposure: > - first the compromises re-ECN made (for space reasons), > - then ones we might make in the w-g. >=20 > >In section 3.2.1 > > > > This last change > > permits the transport protocol to carry multiple=20 > congestion signals > > per round trip, and greatly simplifies accurate auditing. > > > > > >Why is that? >=20 > We need to spell this out. >=20 > It's because today's TCP feedback state machine (and derivatives of=20 > it) suppresses all but one nack per RTT (Reno's cumulative acks for=20 > drop, and the ECE/CWR mechanism for ECN). So if there was >1=20 > congestion indication in an RTT, today's TCP sender could not know,=20 > and would re-echo just one. >=20 > Therefore, without a modified feedback state machine, a TCP sender=20 > with the best intentions would not be able to help sometimes showing=20 > a shortfall between ConEx and actual congestion, which would be=20 > punished by the audit function. >=20 >=20 > >In section 3.3.1 the definition of credit is not clear enough to me. >=20 > Yup - got that. >=20 > Altho the most complex part of this doc will be the explanation of=20 > credit, I'm happy we should be able to keep the whole doc not much=20 > longer than it is now. >=20 >=20 > Thanks again. >=20 >=20 > Bob >=20 >=20 > >Regards, marcelo > > > > > > > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 >=20 > = From ingemar.s.johansson@ericsson.com Mon Nov 8 19:35:00 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3D73A68EB; Mon, 8 Nov 2010 19:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p7TqkNt-pV7; Mon, 8 Nov 2010 19:34:59 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E26C128C1B8; Mon, 8 Nov 2010 19:34:57 -0800 (PST) X-AuditID: c1b4fb39-b7b54ae000003464-fd-4cd8c178c415 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 25.7F.13412.871C8DC4; Tue, 9 Nov 2010 04:35:20 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 9 Nov 2010 04:35:20 +0100 From: Ingemar Johansson S To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" , Qin Wu , "dispatch@ietf.org" Date: Tue, 9 Nov 2010 04:35:03 +0100 Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: Act/YysCX7CwpgwoTOi2u5WUtY8rLwAWmcIA Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: httpstreaming , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 03:35:00 -0000 Hi I have skimmed through the pdf, thanks for posting this. My immediate react= ion is that this machanism is trying to react to indicators of congestion i= n various ways.=20 An alternative would actually be ConEx (http://tools.ietf.org/wg/conex/char= ters). With ConEx enabled flows the re-feedback information can be used by = both operator and user to verify that a SLA is met. For instance, if a user is promised a bandwith of 200kbps for his gaming ex= perience and still experience a high congetsion volume, this would be clear= ly visible for the operator (as well as the user). I don't believe that Con= Ex has outlined this particular use case but I would say that it should be = doable. ConEx has the benefit that it does not add much extra overhead, there are o= f course issues with ConEx (as with any other new technology) Regads /Ingemar =20 =20 > -----Original Message----- > From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)=20 > [mailto:jose_javier.garcia_aranda@alcatel-lucent.com]=20 > Sent: den 9 november 2010 00:33 > To: Qin Wu; dispatch@ietf.org > Cc: httpstreaming > Subject: Re: [httpstreaming] [dispatch] Q-HTTP >=20 > Hi Qin and all, >=20 > Now the Q-HTTP draft is accesible at=20 >=20 > http://www.ietf.org/id/draft-aranda-dispatch-qhttp-00.txt >=20 > In addition, i have attached in this email a FAQ document for=20 > easier understanding of the protocol. This document clarifies=20 > the philosophy and shows different alternatives for the implementation >=20 > Regards and thanks >=20 > - Jose javier >=20 >=20 > -----Mensaje original----- > De: Qin Wu [mailto:sunseawq@huawei.com] Enviado el: lunes, 08=20 > de noviembre de 2010 15:35 > Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); dispatch@ietf.org > CC: httpstreaming > Asunto: Re: [dispatch] Q-HTTP >=20 > Hi, Joes Javier: > Your bring a quite interesting draft. We have a Bar BOF on=20 > HTTP streaming on Wednesday evening, Emenrald room, which=20 > aims at building new area and working out appropriate=20 > working scope to offer more efficient transport and better=20 > QoE. One of key issues we are ready to address is QOE=20 > improvement. If you are interested, please join our discussion. > Also you can track the following link for our meeting agenda,=20 > location and time: > http://www.ietf.org/mail-archive/web/httpstreaming/current/mai > llist.html >=20 > Regards! > -Qin > ----- Original Message ----- > From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)"=20 > > To: > Sent: Monday, November 08, 2010 4:14 PM > Subject: [dispatch] Q-HTTP >=20 >=20 >=20 > Hi experts,=20 >=20 > We are a group of researchers which have written a draft=20 > about QoS measurements & reactions. We believe the=20 > standardization of this topic could benefit internet=20 > community in the coming years, for example for virtualization=20 > of videogames through intenet. We would like to receive=20 > comments and some feedback and also oppinions about the=20 > target area, because we believe that the draft fits into=20 > Real-time App and infrastructure Area scope, but currently=20 > the draft is in "looking for an area" state >=20 > The draft describes Q-HTTP (Quality HTTP) , which is an=20 > application level protocol based on HTTP and SDP associated=20 > to a new specific uri "httpq://..." intended for carrying out=20 > quality negotiation and quality measurement between two=20 > parties. The final goal of this process is to verify that a=20 > certain application which depends on bandwidth, latency,=20 > jitter parameters, will work under current network=20 > conditions. Our idea tackles the fact that real-time services=20 > (virtualization, on line gaming, video, voice) nowadays are=20 > increasing and that in an internet (or WAN) environment=20 > propagation conditions may change with time for our=20 > connection; what works for most applications may not work for=20 > real-time ones and they should have a standard way of=20 > negotiating and verifying their requirements. Q-HTTP also=20 > provides a mechanism of account/alerting when required=20 > constraints are not met after the measurement is carried out. > =20 > Implementation details on the actions to be triggered upon=20 > reception/detection of QoS alerts exchanged by the protocol=20 > are out of scope of this draft, it is application dependant=20 > (e.g. increase quality, reduce bit-rate) or even network=20 > dependant (e.g. change connection's quality profile). >=20 > Comments? Thanks >=20 > - Jose Javier >=20 >=20 >=20 > -------------------------------------------------------------- > ------------------ >=20 >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > = From ingemar.s.johansson@ericsson.com Tue Nov 9 05:20:56 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136AD3A6883; Tue, 9 Nov 2010 05:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNigpIQmdeAL; Tue, 9 Nov 2010 05:20:53 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 361403A680C; Tue, 9 Nov 2010 05:20:51 -0800 (PST) X-AuditID: c1b4fb3d-b7b28ae00000135b-a4-4cd94acb2d97 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2B.2F.04955.BCA49DC4; Tue, 9 Nov 2010 14:21:15 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 9 Nov 2010 14:21:15 +0100 From: Ingemar Johansson S To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" , Qin Wu , "dispatch@ietf.org" Date: Tue, 9 Nov 2010 14:20:51 +0100 Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: Act/YysCX7CwpgwoTOi2u5WUtY8rLwAWmcIAAA0pyyAABxJX4A== Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: httpstreaming , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 13:20:56 -0000 Hi I see ConEx as both a stick and carrot. The "stick" part because it makes it possible or an operator to make sure t= hat individual users (or groups of users) don't exceed their allowed contri= bution to congestion (a.k.a congestion volume).=20 The "carrot" part is a consequence of the "stick" part, excessive congestio= n can be avoided in the networks and this means that users runs a much lowe= r risk of experiencing high delay. Sure you may not get the exact delay you ask for. Possibly ConEx can allow = for a lightweight QoS at its best (for instance users pay extra for an extr= a congestion volume allowance) but perhaps a lightweight QoS is good enough= ? And... I am not convinced that full-fledged QoS gives you the delay you ask= for, perhaps on longer timescales this is true.=20 I am not pretending that ConEx will solve any problem in the world, there a= re definitely issues with ConEx and likely some data collection is needed b= efore congestion volume policers and incentive droppers can be tuned in for= a good performance, and in addition the endpoints need to be ConEx enabled= . =20 Regards Ingemar > -----Original Message----- > From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)=20 > [mailto:jose_javier.garcia_aranda@alcatel-lucent.com]=20 > Sent: den 9 november 2010 18:17 > To: Ingemar Johansson S; Qin Wu; dispatch@ietf.org > Cc: httpstreaming; conex@ietf.org > Subject: RE: [httpstreaming] [dispatch] Q-HTTP >=20 > Hi Ingemar >=20 > Congestion control mechanisms and exposure give operators the=20 > way to avoid problems in their networks and also reward users=20 > which does not impact on others, but does not cover the need=20 > for a quality in terms of latency and jitter, but only packet loss. >=20 > The scenario in which a particular user is paying to a=20 > content provider to ( for example) play a virtualized game,=20 > and the content provider pays to the operator in order to be=20 > possible a QoS on demand (during few minutes) for the flows=20 > from server to this particular user is the goal of Q-HTTP and=20 > although congestion must be measured, the rest of quality=20 > parameters are also important and of course the reaction time=20 > of the protocol is a key factor. >=20 > In this scenario probably this particular user is=20 > contributing to the congestion of others but should not be=20 > penalized. Conex as a form of fifferential QoS could serve=20 > this goal, but needs the help of "something like Q-HTTP" to=20 > achieve the measurements. Don't you agree? >=20 > In a philosophy perspective, we need these pieces:=20 > 1) a network with differential QoS capability (=20 > diffserv, traffic engineering, PCE, traffic mode at access node, etc) > 2) a unified measurement procedure capable to react ( Q-HTTP ?) > 3) something to match the reactions with the QoS=20 > capability of the network ( CONEX ?) >=20 > Apart from this, in terms of overhead, Q-HTTP only uses a few=20 > Kbps, and it is configurable ( more responsiveness implies=20 > more kbps) but for example in our implementation, 15kbps is=20 > quite good for measure downstream and 1kbps for measure=20 > upstream. The responsiveness is defined at the first stage of=20 > the protocol, so can be whatever content provider wants,=20 > depending on the type of content. > =20 > - Jose Javier >=20 >=20 > -----Mensaje original----- > De: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Enviado el: martes, 09 de noviembre de 2010 4:35 > Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Qin Wu;=20 > dispatch@ietf.org > CC: httpstreaming; conex@ietf.org > Asunto: RE: [httpstreaming] [dispatch] Q-HTTP >=20 > Hi >=20 > I have skimmed through the pdf, thanks for posting this. My=20 > immediate reaction is that this machanism is trying to react=20 > to indicators of congestion in various ways.=20 >=20 > An alternative would actually be ConEx=20 > (http://tools.ietf.org/wg/conex/charters). With ConEx enabled=20 > flows the re-feedback information can be used by both=20 > operator and user to verify that a SLA is met. > For instance, if a user is promised a bandwith of 200kbps for=20 > his gaming experience and still experience a high congetsion=20 > volume, this would be clearly visible for the operator (as=20 > well as the user). I don't believe that ConEx has outlined=20 > this particular use case but I would say that it should be doable. > ConEx has the benefit that it does not add much extra=20 > overhead, there are of course issues with ConEx (as with any=20 > other new technology) >=20 > Regads > /Ingemar >=20 > =20 >=20 > =20 >=20 > > -----Original Message----- > > From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)=20 > > [mailto:jose_javier.garcia_aranda@alcatel-lucent.com] > > Sent: den 9 november 2010 00:33 > > To: Qin Wu; dispatch@ietf.org > > Cc: httpstreaming > > Subject: Re: [httpstreaming] [dispatch] Q-HTTP > >=20 > > Hi Qin and all, > >=20 > > Now the Q-HTTP draft is accesible at > >=20 > > http://www.ietf.org/id/draft-aranda-dispatch-qhttp-00.txt > >=20 > > In addition, i have attached in this email a FAQ document=20 > for easier=20 > > understanding of the protocol. This document clarifies the=20 > philosophy=20 > > and shows different alternatives for the implementation > >=20 > > Regards and thanks > >=20 > > - Jose javier > >=20 > >=20 > > -----Mensaje original----- > > De: Qin Wu [mailto:sunseawq@huawei.com] Enviado el: lunes, 08 de=20 > > noviembre de 2010 15:35 > > Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); dispatch@ietf.org > > CC: httpstreaming > > Asunto: Re: [dispatch] Q-HTTP > >=20 > > Hi, Joes Javier: > > Your bring a quite interesting draft. We have a Bar BOF on HTTP=20 > > streaming on Wednesday evening, Emenrald room, which aims=20 > at building=20 > > new area and working out appropriate working scope to offer more=20 > > efficient transport and better QoE. One of key issues we=20 > are ready to=20 > > address is QOE improvement. If you are interested, please join our=20 > > discussion. > > Also you can track the following link for our meeting=20 > agenda, location=20 > > and time: > > http://www.ietf.org/mail-archive/web/httpstreaming/current/mai > > llist.html > >=20 > > Regards! > > -Qin > > ----- Original Message ----- > > From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)"=20 > > > > To: > > Sent: Monday, November 08, 2010 4:14 PM > > Subject: [dispatch] Q-HTTP > >=20 > >=20 > >=20 > > Hi experts, > >=20 > > We are a group of researchers which have written a draft about QoS=20 > > measurements & reactions. We believe the standardization of=20 > this topic=20 > > could benefit internet community in the coming years, for=20 > example for=20 > > virtualization of videogames through intenet. We would like=20 > to receive=20 > > comments and some feedback and also oppinions about the=20 > target area,=20 > > because we believe that the draft fits into Real-time App and=20 > > infrastructure Area scope, but currently the draft is in=20 > "looking for=20 > > an area" state > >=20 > > The draft describes Q-HTTP (Quality HTTP) , which is an=20 > application=20 > > level protocol based on HTTP and SDP associated to a new=20 > specific uri=20 > > "httpq://..." intended for carrying out quality negotiation and=20 > > quality measurement between two parties. The final goal of this=20 > > process is to verify that a certain application which depends on=20 > > bandwidth, latency, jitter parameters, will work under=20 > current network=20 > > conditions. Our idea tackles the fact that real-time services=20 > > (virtualization, on line gaming, video, voice) nowadays are=20 > increasing=20 > > and that in an internet (or WAN) environment propagation conditions=20 > > may change with time for our connection; what works for most=20 > > applications may not work for real-time ones and they should have a=20 > > standard way of negotiating and verifying their=20 > requirements. Q-HTTP=20 > > also provides a mechanism of account/alerting when required=20 > > constraints are not met after the measurement is carried out. > > =20 > > Implementation details on the actions to be triggered upon=20 > > reception/detection of QoS alerts exchanged by the protocol=20 > are out of=20 > > scope of this draft, it is application dependant (e.g. increase=20 > > quality, reduce bit-rate) or even network dependant (e.g. change=20 > > connection's quality profile). > >=20 > > Comments? Thanks > >=20 > > - Jose Javier > >=20 > >=20 > >=20 > > -------------------------------------------------------------- > > ------------------ > >=20 > >=20 > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > = From lars.eggert@nokia.com Tue Nov 9 18:02:09 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6913A6910; Tue, 9 Nov 2010 18:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKUeUmqAZm6L; Tue, 9 Nov 2010 18:02:08 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by core3.amsl.com (Postfix) with ESMTP id 5590A3A68F8; Tue, 9 Nov 2010 18:02:08 -0800 (PST) Received: from mail.fit.nokia.com (esdhcp030222.research.nokia.com [172.21.30.222]) by mgw-sa02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id oAA22NSR019804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2010 04:02:24 +0200 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.96.4 at fit.nokia.com Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-60--337802050; protocol="application/pkcs7-signature"; micalg=sha1 From: Lars Eggert In-Reply-To: Date: Wed, 10 Nov 2010 10:02:06 +0800 Message-Id: <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: David Singer X-Mailer: Apple Mail (2.1081) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (mail.fit.nokia.com); Wed, 10 Nov 2010 04:02:13 +0200 (EET) X-Nokia-AV: Clean Cc: Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , httpstreaming , "dispatch@ietf.org" , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 02:02:09 -0000 --Apple-Mail-60--337802050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-11-9, at 18:31, David Singer wrote: > It is that there are two ways to solve a real-time bandwidth need. = One is to reserve bandwidth, manage QoS and so on; one gets protocols = and systems like diffserv, ATM, and so on. The other is simply to have = 'too much' of the resource. Though it feels wrong, the latter often = ends up being the cheaper and easier solution. So, for example, voice = over IP is getting used quite a lot, and to good effect, on the internet = today not because we have successfully deployed any bandwidth = reservation or QoS management protocols and systems, but because the = available bandwidth is, for the most part, greatly in excess of what is = needed, and the systems can adapt in real-time to what they get (rather = than asking for what they want). The same is true for multimedia = delivery; the complexity of RTP + TCP friendliness + QoS management is = not worth it compared to having adaptable end-systems and overall more = bandwidth than needed. Fully agreed.=20 Folks who like pictures can take a look at = https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much the = same argument. Lars= --Apple-Mail-60--337802050 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMRjCCBVAw ggQ4oAMCAQICEGxdPUZzCwUJ8KBiJwH+bYgwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMDEwMTUwMDAwMDBaFw0x MTEwMTUyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9r aWEuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwolKEyOz/NQZJJlw0x9XBS9W wCmabdY1fXpbWSdcaJiEWhQpRzSIC/pgIwCgaUW9g3JsWioXCawyjUVeg8xR42sR690f4z+OPAUm 3jokZxsuRaGX6fuPkPQomYAGz7htUHws/8FZIU+4dciETQf4vF5ptitJ+QZCVRCTLqisj6mG/kG4 65Op3G5/YZF9F/a390LdhuRP6vdY2Y+dqm8LDa0zmENPpoE98u1pIZGqCcnskN/nNBtEPd+a4lNh ZSGnPuL4XCUSJYR9NB7FAYBvi5N7LSWHR3fspwa5EgpXynJcsLzaLA0iGfjFOBYFxul/07edmyw4 FIXuCIkaMDUfEwIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDov L2luZGMxZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3Js MA0GCSqGSIb3DQEBBQUAA4IBAQAlSTzUKqa3ZouKWFQfIJ+4l/KsztPnY4Onwzt8lqAmeiFPqOmf kLTXbXDKtC6caFadNtyHpnsmQFFKXwhe5Z9/AaVSwryu6F9992DzYLp3j8PE0DSU0wmpUXUtp+rz TFqJRkzB8RCBoq/TPBmkMPr68qB0TkU3dbYiVIvscOt1MRkdHiwG4wKQLyCf8XRRWqmMY6lbun7g kiEWiris5StGKRvE5+e1SrcdnoZxIKQFF7Etr+4ftClrsDQWX9nRCEjYcmz4y/deq+HU8ylBaKZE 0ZJmcnYlAaD50OYWi0ckGDnKYyeMUEtCZJSV0otm2LqyIUAu9WPv/GNHt2ntjnUaMIIG7jCCBdag AwIBAgIQcRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6Zvg SU6Lb9UB0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHs EnMhjfXcMM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO 4YM/d/mZ//6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSy riMGZSalJ1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCC ArUwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20w EgYDVR0TAQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWdu LmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgw VhYJaW1hZ2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDov L2xvZ28udmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQ cml2YXRlTGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYD VR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4x HzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlT aWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENs YXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaE VIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlM JBq6WaSHO3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKv YLMVirOVnDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDR yxTWcVibvtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy +kgOZY5JyNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/ wYIxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMu MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBO b3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2Ny aWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTExMDAyMDIwN1owIwYJKoZIhvcNAQkE MRYEFOmeaxZCsRX8gYGEoaiM9a/CNtKaMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20v cnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlT aWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEGxdPUZzCwUJ8KBiJwH+ bYgwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJt cyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQSAtIEczAhBsXT1GcwsFCfCgYicB/m2IMA0GCSqGSIb3DQEBAQUABIIB AJevsVi6WcHsaNdZa1Dl/khFYMOswGQqvSa3ENBU63ua+8TwaD7hTHF8eN14ZGxhLOYBSsuVIsXL uINakNHXMqQryZ9C8Qq8enCAZD62K4k8zrXRNnWHcqy7CKXSZ67yT04yd3juFkoZpSN6+p5cFovx PEKnhPj7um6hyBEFvJKwFR84Td7cE26H3qB3gLOewaCOL+O3Vr/T5iU3Qxvx7oa7dy2xfMgT4293 TTtmCHCZ5Nc2bCTstdJly8DeyVqW6Ii9g+2Q9e6tXk6ZOFQ874s849UsGm+YN8BqScPes9FApLww 6cEW6mG4KKYPpk6TH3bX6K+mbz7QY5vRZ3nzricAAAAAAAA= --Apple-Mail-60--337802050-- From dave.mcdysan@verizon.com Tue Nov 9 18:16:35 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27DFC3A6A3B for ; Tue, 9 Nov 2010 18:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymLNiuUzsXny for ; Tue, 9 Nov 2010 18:16:34 -0800 (PST) Received: from tpamail4.verizon.com (tpamail4.verizon.com [192.76.82.161]) by core3.amsl.com (Postfix) with ESMTP id CE1FD3A6932 for ; Tue, 9 Nov 2010 18:16:33 -0800 (PST) Received: from tpaintrmemf3.verizon.com (tpaintrmemf3.verizon.com [138.83.67.58]) by tpamail4.verizon.com (8.13.6/8.13.3) with ESMTP id oAA2Bedt020058; Tue, 9 Nov 2010 21:11:45 -0500 (EST) X-AuditID: 8a53433a-b7bacae000002c91-2f-4cda0095791b Received: from smtptpa4.verizon.com ( [138.83.71.177]) by tpaintrmemf3.verizon.com (EMF) with SMTP id 97.C1.11409.5900ADC4; Tue, 9 Nov 2010 21:16:53 -0500 (EST) Received: from FHDP1LUMXC7HB03.us.one.verizon.com (fhdp1lumxc7hb03.verizon.com [166.68.59.190]) by smtptpa4.verizon.com (8.13.3/8.13.3) with ESMTP id oAA2GqIL013799; Tue, 9 Nov 2010 21:16:52 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB03.us.one.verizon.com ([2002:a644:3bbe::a644:3bbe]) with mapi; Tue, 9 Nov 2010 21:16:52 -0500 From: "Mcdysan, David E" To: John Leslie Date: Tue, 9 Nov 2010 21:16:51 -0500 Thread-Topic: "Burstiness" Thread-Index: Act/rUPyB4jgGBFkT7q9OP9U2WFw1QAzffeN Message-ID: <2464076D83FAED4D985BF2622111AAC40F95CCF86B@FHDP1LUMXC7V11.us.one.verizon.com> References: <20101108153840.GV82074@verdi> <2464076D83FAED4D985BF2622111AAC40F95CCF862@FHDP1LUMXC7V11.us.one.verizon.com>, <20101109012713.GZ82074@verdi> In-Reply-To: <20101109012713.GZ82074@verdi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] "Burstiness" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 02:16:35 -0000 Hi JOhn, Some responses in line below prefixed by DM. Dave ________________________________________ From: John Leslie [john@jlc.net] Sent: Monday, November 08, 2010 8:27 PM To: Mcdysan, David E Cc: conex@ietf.org Subject: Re: "Burstiness" (Hopefully I'm picking out the right sections of David's response...) Mcdysan, David E wrote: > [John Leslie wrote:] > >> I think most of us would agree that if the "heavy user" backs off >> during congestion, s/he shouldn't be charged "congestion costs" during >> the period of back-off. > > DM - I think what you describe is a specific mechanism, which is already > described in the moncaster use case draft. I was not intending to describe a mechanism... > As I mentioned earlier in response to Alissa, I tried not to go too much > into mechanism since the topic was use cases, but let me try now to > briefly describe what I had in mind. I was thinking that instead of only > charging on short term average bandwidth of a shaper as is done today > and results in the 80/20 experience reported by Varian that shaping and > possibly charging is based upon longer term metrics, such as the > burstiness. In the next section 4.2 I mention that usage tier accounting > partially addresses this issue, but > > "does not address situation where heavy users send at a high rate, > but only for a fraction of the usage measurement interval (e.g., > only for a few hours or days during a month)." Do I understand that David intends this to change the mechanism for charging _receivers_? DM - More specifically, as described in the draft as a measure of congestio= n that could be used for charging (or policing). > DM - Also note that "queue congestion" may not actually occur during a > peak period. IMO customers should not experience different behaviors > depending upon the state of capacity provisioned in the network, which > could occur with the way that conex is currently defined. I must be misunderstanding: how can users _avoid_ a different experience during a period of significant congestion? DM - As I understand the current conex use case, if the provisioned capacit= y >> offered load then congestion (i.e., Pr[drop or ECN marking]) is small = and any congestion action (e.g., policing, pricing) will also be small. If = the offered load approaches provisioned capacity then the congestion is lar= ger and congestion action will be larger. Hence, a user sending the same tr= affic at different points in time will experience different behaviors. As m= entioned by others in meetings and on the list, a typical provider practice= is to provision capacity such that congestion is small. >> To my provider-centric view, "burstiness" would decay with aggregation; >> and I'd be concerned only after some aggregation had already occurred. > > DM - Not on a per flow basis. The non-work conserving shaper is the > resource that can be congested, not an aggregate interface. A reference to "non-work conserving shaper" would help, I think. DM - I had thought of adding a reference to BBF (formerly DSL Forum) TR-059= , but thought this was a specific mechanism. Reading the -02 moncaster draf= t, there is less mechanism than -01 but there is still a fair amount that a= ssumes a specific mechanism. After having written this draft I have a bette= r appreciation for the difficulty involved with separating these concepts. >> Also, it makes quite a difference (to me) whether we're talking about >> a point near the sender or near the receiver. Near the receiver, most >> of the aggregation is long-since done, while near the sender, relatively >> little has been done. I'm having difficulty seeing what metric could >> serve both cases... > > DM - Agreed. see above, I think there at least two cases: per flow near > receiver and aggregate at other points (e.g., between ISPs). (Hopefully I interpret this correctly: that David is thinking about near-the-receiver and "charging" the receiver.) DM - In the "heavy/light user inequity use case, yes. In the recharging use= case, it would be a third party (e.g., the sender). >> A "heavy" user might or might not be willing to get out of the way. >> Real-time audio/video would be disinclined to get out of the way -- >> thus deserving a congestion charge. "Video-on-demand" could get out of >> the way "briefly", thus deserving a lesser charge. Background downloads >> could get out of the way for hours on end, thus deserving essentially >> no congestion charge. But all of these are "heavy" users; and I don't >> follow how David's "burstiness" measure would help distinguish them. > > DM - The feedback I had in mind is to senders regarding the congestion > experienced by a non-work conserving shaper that in addition to a short > term rate also has the characteristic of allowed burstiness over a > longer-time interval. I'm guessing here -- that David's "non-work conserving shaper" is dropping some packets or otherwise marking as congestion some traffic which isn't actual queue congestion. Please correct me if I'm guessing wrong... DM - What I had in mind is providing feed forward (and feedback) on a longe= r time scale than per packet. IMO, a longer term view makes an experimental= protocol implementable in software versus a per packet method which probab= ly requires hardware or microcode changes.=20 > It is congestion of this per user/flow interface that would enable a > form of charging more suited to the heavy/light users reported by > Varian and observed on the networks with which I have access to such > measurements. What "charging" is "suitable" is not in-scope here. DM - I suggest that we need to agree as a wg and get AD consensus as to wha= t the charter statement means by excluding "billing." The moncaster -02 use= case draft mentions charging, payment, and econmics in many places and we = should apply the charter interpretation consistently. However, (if I'm guessing correctly) "congestion" which isn't actual queue-based congestion is probably still "congestion" which may deserve to be made visible throughout the path under a ConEx protocol. DM - Yes! That is what I had in mind. A few questions come to mind: - is there some action to be taken by any point other than receiver and sender? - is there an intent to collect and correlate this information elsewhere? - does David have in mind some specific metric useful under a different business model? DM - I have some ideas on these, but I think they seem more like mechanism.= As I stated in response to Alissa, if the wg finds (some aspects) of the p= roposed use cases interesting then I (inviting any others willing and havin= g time to work on this) to draft out some abstract mechanisms. -- John Leslie = From carlberg@g11.org.uk Tue Nov 9 18:24:35 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B43D3A6902; Tue, 9 Nov 2010 18:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZEnfLWwqYZX; Tue, 9 Nov 2010 18:24:33 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id E75A33A684C; Tue, 9 Nov 2010 18:24:32 -0800 (PST) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:51905 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1PG0Ml-0003bF-3l; Wed, 10 Nov 2010 02:24:51 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> Date: Tue, 9 Nov 2010 21:24:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7AB4E81D-48F9-4E7B-B6F4-CFFBB4C452F1@g11.org.uk> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> To: Lars Eggert X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , David Singer Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 02:24:35 -0000 I would agree with Dave Singer's points below, but with significant = qualifiers. VoIP is being used more and more because significant = pockets of acceptable quality can be found, but these are subject to = location, and at times, time of day usage (eg, my use of Skype versus = POTS varies depending on where I make my calls to Chile). And as you = get closer to the last mile (wireless and the backhaul in particular), = economics do play more of a factor in how much reliance = over-provisioning can solve all problems. -ken ps, I'm only on conex mailing list, so this will probably bounce on = dispatch and httpstreaming On Nov 9, 2010, at 9:02 PM, Lars Eggert wrote: > On 2010-11-9, at 18:31, David Singer wrote: >> It is that there are two ways to solve a real-time bandwidth need. = One is to reserve bandwidth, manage QoS and so on; one gets protocols = and systems like diffserv, ATM, and so on. The other is simply to have = 'too much' of the resource. Though it feels wrong, the latter often = ends up being the cheaper and easier solution. So, for example, voice = over IP is getting used quite a lot, and to good effect, on the internet = today not because we have successfully deployed any bandwidth = reservation or QoS management protocols and systems, but because the = available bandwidth is, for the most part, greatly in excess of what is = needed, and the systems can adapt in real-time to what they get (rather = than asking for what they want). The same is true for multimedia = delivery; the complexity of RTP + TCP friendliness + QoS management is = not worth it compared to having adaptable end-systems and overall more = bandwidth than needed. >=20 > Fully agreed.=20 >=20 > Folks who like pictures can take a look at = https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much the = same argument. >=20 > Lars_______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From dave.mcdysan@verizon.com Tue Nov 9 18:34:19 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84F503A63C9 for ; Tue, 9 Nov 2010 18:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXJEenlunFZr for ; Tue, 9 Nov 2010 18:34:18 -0800 (PST) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by core3.amsl.com (Postfix) with ESMTP id 7EBDB3A635F for ; Tue, 9 Nov 2010 18:34:18 -0800 (PST) Received: from irvintrmemf1.verizon.com (irvintrmemf1.verizon.com [138.83.34.101]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id oAA2YZU6021749 for ; Tue, 9 Nov 2010 21:34:36 -0500 (EST) X-AuditID: 8a532265-b7baeae00000194c-b7-4cda04bb689d Received: from smtptpa3.verizon.com ( [138.83.71.176]) by irvintrmemf1.verizon.com (Symantec Brightmail Gateway) with SMTP id 9D.32.06476.BB40ADC4; Tue, 9 Nov 2010 20:34:35 -0600 (CST) Received: from FHDP1LUMXC7HB02.us.one.verizon.com (fhdp1lumxc7hb02.verizon.com [166.68.59.189]) by smtptpa3.verizon.com (8.13.3/8.13.3) with ESMTP id oAA2YYc8009224; Tue, 9 Nov 2010 21:34:34 -0500 (EST) Received: from fhdp1lumxc7v11.us.one.verizon.com ([fe80::4c3d:3366:54ab:8118]) by FHDP1LUMXC7HB02.us.one.verizon.com ([2002:a644:3bbd::a644:3bbd]) with mapi; Tue, 9 Nov 2010 21:34:34 -0500 From: "Mcdysan, David E" To: Lars Eggert , David Singer Date: Tue, 9 Nov 2010 21:34:33 -0500 Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuAe2a3CyErCb4sQgG6KW17+mum5gAAozUL Message-ID: <2464076D83FAED4D985BF2622111AAC40F95CCF86C@FHDP1LUMXC7V11.us.one.verizon.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> , <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> In-Reply-To: <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , httpstreaming , "dispatch@ietf.org" , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 02:34:19 -0000 Lars, Thanks for sharing this post and reference. I try to make a similar point in section 4.3 of http://tools.ietf.org/id/dr= aft-mcdysan-conex-other-usecases-00.txt Some operators provision sufficient capacity at bottleneck points and/or ma= ke productive use of restoration capacity so that congestion rarely occurs.= A much larger potential benefit than that offered by short term congestion= control occurs if a means to motivate time shifting of traffic to off-peak= periods can be developed. Thanks, Dave ________________________________________ From: conex-bounces@ietf.org [conex-bounces@ietf.org] On Behalf Of Lars Egg= ert [lars.eggert@nokia.com] Sent: Tuesday, November 09, 2010 9:02 PM To: David Singer Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); httpstre= aming; dispatch@ietf.org; conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP On 2010-11-9, at 18:31, David Singer wrote: > It is that there are two ways to solve a real-time bandwidth need. One i= s to reserve bandwidth, manage QoS and so on; one gets protocols and syste= ms like diffserv, ATM, and so on. The other is simply to have 'too much' o= f the resource. Though it feels wrong, the latter often ends up being the = cheaper and easier solution. So, for example, voice over IP is getting use= d quite a lot, and to good effect, on the internet today not because we hav= e successfully deployed any bandwidth reservation or QoS management protoco= ls and systems, but because the available bandwidth is, for the most part, = greatly in excess of what is needed, and the systems can adapt in real-time= to what they get (rather than asking for what they want). The same is tru= e for multimedia delivery; the complexity of RTP + TCP friendliness + QoS = management is not worth it compared to having adaptable end-systems and ove= rall more bandwidth than needed. Fully agreed. Folks who like pictures can take a look at https://fit.nokia.com/lars/talks= /2008-mit-cfp.pdf, which gives much the same argument. Lars= From suresh.krishnan@ericsson.com Tue Nov 9 21:56:38 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94763A68A2 for ; Tue, 9 Nov 2010 21:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsQYALLbfejj for ; Tue, 9 Nov 2010 21:56:38 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 0CE9C3A6813 for ; Tue, 9 Nov 2010 21:56:37 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oAA6KJxb009245; Wed, 10 Nov 2010 00:20:21 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.63]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 10 Nov 2010 00:56:57 -0500 From: Suresh Krishnan To: Bob Briscoe , Joel Halpern Date: Wed, 10 Nov 2010 00:56:54 -0500 Thread-Topic: draft-krishnan-6man-header-reserved-bits-00 Thread-Index: Act/ORaFf7XA4YpEQISdA/5cIVGK6QBYYdNA Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC150E751F815@EUSAACMS0703.eamcs.ericsson.se> References: <201011081135.oA8BZamZ014323@bagheera.jungle.bt.co.uk> In-Reply-To: <201011081135.oA8BZamZ014323@bagheera.jungle.bt.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ConEx IETF list Subject: Re: [conex] draft-krishnan-6man-header-reserved-bits-00 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 05:56:39 -0000 Hi Bob, > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 > Sent: Monday, November 08, 2010 7:34 PM > To: Suresh Krishnan; Joel Halpern > Cc: ConEx IETF list > Subject: draft-krishnan-6man-header-reserved-bits-00 >=20 > Suresh, Joel, >=20 > Concerning >=20 > 1/ Firstly, have you had any response from the v6 community=20 > on this one? Yes, and it has not been very positive. The issue seems to be minimizing ch= anges to the flow label field. There have been some backward compatibility = concerns brought up, but I do not think they hold water. >=20 > 2/ As well as extra bits, there's a problem of the behaviour=20 > of nodes that don't understand the bits (as you've identified=20 > in your 6man uniform v6 extension headers draft). The nice=20 > thing about the flow-label is most nodes should allow thru anything. Exactly. >=20 > 3/ Do you know whether tunnels will copy the flow label to=20 > the new outer (both whether they should and whether they actually do)? Neither :-). All the instances of IPv6 tunneling that I have implemented/se= en will not copy the flow label. The default behavior would be to set the f= low label to 0. That said, there are some efforts to use the flow label for= ECMP load balancing. One such effort draft-carpenter-flow-ecmp-03 mandates= tunnel ingress points to set the flow label to a pseudo-random value. Thanks Suresh= From kathy@iridescentnetworks.com Tue Nov 9 19:00:55 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 238F43A67F6 for ; Tue, 9 Nov 2010 19:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti4PqhmajGOR for ; Tue, 9 Nov 2010 19:00:54 -0800 (PST) Received: from nm10-vm0.bullet.mail.ac4.yahoo.com (nm10-vm0.bullet.mail.ac4.yahoo.com [98.139.53.194]) by core3.amsl.com (Postfix) with SMTP id C590B28C0DE for ; Tue, 9 Nov 2010 19:00:53 -0800 (PST) Received: from [98.139.52.189] by nm10.bullet.mail.ac4.yahoo.com with NNFMP; 10 Nov 2010 03:01:16 -0000 Received: from [98.139.52.146] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 10 Nov 2010 03:01:16 -0000 Received: from [127.0.0.1] by omp1029.mail.ac4.yahoo.com with NNFMP; 10 Nov 2010 03:01:16 -0000 X-Yahoo-Newman-Id: 864779.69368.bm@omp1029.mail.ac4.yahoo.com Received: (qmail 84112 invoked from network); 10 Nov 2010 03:01:16 -0000 Received: from IridescentKathy (kathy@66.116.112.8 with login) by smtp115.biz.mail.re2.yahoo.com with SMTP; 09 Nov 2010 19:01:16 -0800 PST X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL X-YMail-OSG: oZrOoFMVM1lJgKK0X4SlQ5F7z5EeN.7YqynO9Gvz1MV98.C j7QDsP9rKE6ctt..8y6asYoDZUwcmLaKvrZ6gskBfe8h.lj3JN7YfcBpoW8b OI_lO5m4ly_eiSSyon74FYyFYvA7Y6AHjDKZKn0RoYNOCJRA_aqi0qlxLFqb TVJrVsh7.QJLVbAflAVlrc5J2UGKn60gIR7CFi8Xqs1wprLVGw_tudbQflLi oCLjHZqfB0TkehA-- X-Yahoo-Newman-Property: ymail-3 From: "Kathy McEwen" To: "'Lars Eggert'" , "'David Singer'" References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> In-Reply-To: <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> Date: Tue, 9 Nov 2010 21:01:18 -0600 Message-ID: <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVmQZqk6YOb/SFfEdornYnDlU03gJY4s1cAdIdk84CEDYYNwKAUfLvAj1dw08DDxb7lpJlkvQg Content-Language: en-us X-Mailman-Approved-At: Tue, 09 Nov 2010 22:08:06 -0800 Cc: 'Ingemar Johansson S' , "'GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)'" , 'httpstreaming' , dispatch@ietf.org, conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 03:00:55 -0000 One problem with the voice analogy is that the sheer volume of data traversing the web today is not driven by voice...it's video...and it's not even a fraction of the viewing that folks are doing of broadcast content. A solution that depends on "simply" having too much bandwidth, is that someone is paying for it. Eventually it hits someone's pocket books....and if there isn't sufficient revenue to cover the costs, the too much does degrade. Today the mass media is consumed via cheap broadcast technologies... why shouldn't the web (fixed and mobile) be as cheap AND as good?? -----Original Message----- From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] On Behalf Of Lars Eggert Sent: Tuesday, November 09, 2010 8:02 PM To: David Singer Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); httpstreaming; dispatch@ietf.org; conex@ietf.org Subject: Re: [httpstreaming] [dispatch] Q-HTTP On 2010-11-9, at 18:31, David Singer wrote: > It is that there are two ways to solve a real-time bandwidth need. One is to reserve bandwidth, manage QoS and so on; one gets protocols and systems like diffserv, ATM, and so on. The other is simply to have 'too much' of the resource. Though it feels wrong, the latter often ends up being the cheaper and easier solution. So, for example, voice over IP is getting used quite a lot, and to good effect, on the internet today not because we have successfully deployed any bandwidth reservation or QoS management protocols and systems, but because the available bandwidth is, for the most part, greatly in excess of what is needed, and the systems can adapt in real-time to what they get (rather than asking for what they want). The same is true for multimedia delivery; the complexity of RTP + TCP friendliness + QoS management is not worth it compared to having adaptable end-systems and overall more bandwidth than needed. Fully agreed. Folks who like pictures can take a look at https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much the same argument. Lars From jose_javier.garcia_aranda@alcatel-lucent.com Tue Nov 9 02:17:07 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A371028C18A; Tue, 9 Nov 2010 02:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.191 X-Spam-Level: X-Spam-Status: No, score=-5.191 tagged_above=-999 required=5 tests=[AWL=1.058, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfMfiYGpeMSA; Tue, 9 Nov 2010 02:17:06 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id E9FFD3A6946; Tue, 9 Nov 2010 02:17:05 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oA9AHNgr027255 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 9 Nov 2010 11:17:23 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 9 Nov 2010 11:17:23 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: Ingemar Johansson S , Qin Wu , "dispatch@ietf.org" Date: Tue, 9 Nov 2010 11:17:21 +0100 Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: Act/YysCX7CwpgwoTOi2u5WUtY8rLwAWmcIAAA0pyyA= Message-ID: <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Tue, 09 Nov 2010 22:08:10 -0800 Cc: httpstreaming , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 10:17:07 -0000 Hi Ingemar Congestion control mechanisms and exposure give operators the way to avoid = problems in their networks and also reward users which does not impact on o= thers, but does not cover the need for a quality in terms of latency and ji= tter, but only packet loss. The scenario in which a particular user is paying to a content provider to = ( for example) play a virtualized game, and the content provider pays to th= e operator in order to be possible a QoS on demand (during few minutes) for= the flows from server to this particular user is the goal of Q-HTTP and al= though congestion must be measured, the rest of quality parameters are also= important and of course the reaction time of the protocol is a key factor. In this scenario probably this particular user is contributing to the conge= stion of others but should not be penalized. Conex as a form of fifferentia= l QoS could serve this goal, but needs the help of "something like Q-HTTP" = to achieve the measurements. Don't you agree? In a philosophy perspective, we need these pieces:=20 1) a network with differential QoS capability ( diffserv, traffic en= gineering, PCE, traffic mode at access node, etc) 2) a unified measurement procedure capable to react ( Q-HTTP ?) 3) something to match the reactions with the QoS capability of the net= work ( CONEX ?) Apart from this, in terms of overhead, Q-HTTP only uses a few Kbps, and it = is configurable ( more responsiveness implies more kbps) but for example in= our implementation, 15kbps is quite good for measure downstream and 1kbps = for measure upstream. The responsiveness is defined at the first stage of t= he protocol, so can be whatever content provider wants, depending on the ty= pe of content. =20 - Jose Javier -----Mensaje original----- De: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com]=20 Enviado el: martes, 09 de noviembre de 2010 4:35 Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Qin Wu; dispatch@ietf.org CC: httpstreaming; conex@ietf.org Asunto: RE: [httpstreaming] [dispatch] Q-HTTP Hi I have skimmed through the pdf, thanks for posting this. My immediate react= ion is that this machanism is trying to react to indicators of congestion i= n various ways.=20 An alternative would actually be ConEx (http://tools.ietf.org/wg/conex/char= ters). With ConEx enabled flows the re-feedback information can be used by = both operator and user to verify that a SLA is met. For instance, if a user is promised a bandwith of 200kbps for his gaming ex= perience and still experience a high congetsion volume, this would be clear= ly visible for the operator (as well as the user). I don't believe that Con= Ex has outlined this particular use case but I would say that it should be = doable. ConEx has the benefit that it does not add much extra overhead, there are o= f course issues with ConEx (as with any other new technology) Regads /Ingemar =20 =20 > -----Original Message----- > From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)=20 > [mailto:jose_javier.garcia_aranda@alcatel-lucent.com] > Sent: den 9 november 2010 00:33 > To: Qin Wu; dispatch@ietf.org > Cc: httpstreaming > Subject: Re: [httpstreaming] [dispatch] Q-HTTP >=20 > Hi Qin and all, >=20 > Now the Q-HTTP draft is accesible at >=20 > http://www.ietf.org/id/draft-aranda-dispatch-qhttp-00.txt >=20 > In addition, i have attached in this email a FAQ document for easier=20 > understanding of the protocol. This document clarifies the philosophy=20 > and shows different alternatives for the implementation >=20 > Regards and thanks >=20 > - Jose javier >=20 >=20 > -----Mensaje original----- > De: Qin Wu [mailto:sunseawq@huawei.com] Enviado el: lunes, 08 de=20 > noviembre de 2010 15:35 > Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); dispatch@ietf.org > CC: httpstreaming > Asunto: Re: [dispatch] Q-HTTP >=20 > Hi, Joes Javier: > Your bring a quite interesting draft. We have a Bar BOF on HTTP=20 > streaming on Wednesday evening, Emenrald room, which aims at building=20 > new area and working out appropriate working scope to offer more=20 > efficient transport and better QoE. One of key issues we are ready to=20 > address is QOE improvement. If you are interested, please join our=20 > discussion. > Also you can track the following link for our meeting agenda, location=20 > and time: > http://www.ietf.org/mail-archive/web/httpstreaming/current/mai > llist.html >=20 > Regards! > -Qin > ----- Original Message ----- > From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)"=20 > > To: > Sent: Monday, November 08, 2010 4:14 PM > Subject: [dispatch] Q-HTTP >=20 >=20 >=20 > Hi experts, >=20 > We are a group of researchers which have written a draft about QoS=20 > measurements & reactions. We believe the standardization of this topic=20 > could benefit internet community in the coming years, for example for=20 > virtualization of videogames through intenet. We would like to receive=20 > comments and some feedback and also oppinions about the target area,=20 > because we believe that the draft fits into Real-time App and=20 > infrastructure Area scope, but currently the draft is in "looking for=20 > an area" state >=20 > The draft describes Q-HTTP (Quality HTTP) , which is an application=20 > level protocol based on HTTP and SDP associated to a new specific uri=20 > "httpq://..." intended for carrying out quality negotiation and=20 > quality measurement between two parties. The final goal of this=20 > process is to verify that a certain application which depends on=20 > bandwidth, latency, jitter parameters, will work under current network=20 > conditions. Our idea tackles the fact that real-time services=20 > (virtualization, on line gaming, video, voice) nowadays are increasing=20 > and that in an internet (or WAN) environment propagation conditions=20 > may change with time for our connection; what works for most=20 > applications may not work for real-time ones and they should have a=20 > standard way of negotiating and verifying their requirements. Q-HTTP=20 > also provides a mechanism of account/alerting when required=20 > constraints are not met after the measurement is carried out. > =20 > Implementation details on the actions to be triggered upon=20 > reception/detection of QoS alerts exchanged by the protocol are out of=20 > scope of this draft, it is application dependant (e.g. increase=20 > quality, reduce bit-rate) or even network dependant (e.g. change=20 > connection's quality profile). >=20 > Comments? Thanks >=20 > - Jose Javier >=20 >=20 >=20 > -------------------------------------------------------------- > ------------------ >=20 >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > = From singer@apple.com Tue Nov 9 02:30:53 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A213A6946; Tue, 9 Nov 2010 02:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ahm7nC6WUrFA; Tue, 9 Nov 2010 02:30:47 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id F21143A6849; Tue, 9 Nov 2010 02:30:44 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 8A916BB93DEC; Tue, 9 Nov 2010 02:31:07 -0800 (PST) X-AuditID: 1180711d-b7c86ae000000247-e8-4cd922e69d1f Received: from [17.72.145.128] (Unknown_Domain [17.72.145.128]) by relay13.apple.com (Apple SCV relay) with SMTP id 38.DD.00583.7E229DC4; Tue, 9 Nov 2010 02:31:07 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Singer In-Reply-To: <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Tue, 9 Nov 2010 11:31:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 09 Nov 2010 22:08:11 -0800 Cc: Ingemar Johansson S , httpstreaming , dispatch@ietf.org, Qin Wu , conex@ietf.org Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 10:30:53 -0000 There is a bitter lesson I have learned over the years to do with QoS = reservation. It is that there are two ways to solve a real-time bandwidth need. One = is to reserve bandwidth, manage QoS and so on; one gets protocols and = systems like diffserv, ATM, and so on. The other is simply to have 'too = much' of the resource. Though it feels wrong, the latter often ends up = being the cheaper and easier solution. So, for example, voice over IP = is getting used quite a lot, and to good effect, on the internet today = not because we have successfully deployed any bandwidth reservation or = QoS management protocols and systems, but because the available = bandwidth is, for the most part, greatly in excess of what is needed, = and the systems can adapt in real-time to what they get (rather than = asking for what they want). The same is true for multimedia delivery; = the complexity of RTP + TCP friendliness + QoS management is not worth = it compared to having adaptable end-systems and overall more bandwidth = than needed. (I worked on real-time scheduling systems as well, and the same applies; = it's cheaper to have a processor which is much faster than needed, with = a normal scheduler, than to have a just-enough processor with a = real-time scheduler). I know, it 'feels' wrong. David Singer Multimedia and Software Standards, Apple Inc. From gunnar.heikkila@ericsson.com Tue Nov 9 03:37:10 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01D693A6800; Tue, 9 Nov 2010 03:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgYgrUEioHkJ; Tue, 9 Nov 2010 03:37:08 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 337CF3A672F; Tue, 9 Nov 2010 03:37:07 -0800 (PST) X-AuditID: c1b4fb3d-b7b28ae00000135b-78-4cd9327b6373 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 00.20.04955.B7239DC4; Tue, 9 Nov 2010 12:37:31 +0100 (CET) Received: from ESESSCMS0364.eemea.ericsson.se ([169.254.2.79]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 9 Nov 2010 12:37:29 +0100 From: =?iso-8859-1?Q?Gunnar_Heikkil=E4?= To: David Singer , "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" Date: Tue, 9 Nov 2010 12:37:28 +0100 Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: Act/+UPK/Ozu19IeQJie7DeY9Z/jewAAE0gw Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 09 Nov 2010 22:08:10 -0800 Cc: Ingemar Johansson S , httpstreaming , "dispatch@ietf.org" , =?iso-8859-1?Q?Gunnar_Heikkil=E4?= , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 11:37:10 -0000 Hi David, Jose Javier, for cellular networks (for instance a PC using a mobile broadband dongle) o= ver-provisioning is really expensive and you have to do something smarter. = But I am not sure that the Q-HTTP concept is the way forward since it is ba= sed on injecting test traffic into the system.=20 Typically the wireless conditions can change rather fast (especially if the= user is moving, say sitting on a train), so the "reaction time" based on t= he test traffic is most likley too long. The other problem is that the test= traffic adds additional data into an already heavily loaded wireless netwo= rk, which might not be easy to defend when selling this concept to the cell= ular operators. But there is sure a need for good ways to handle the underlying problem you= describe. Best regards Gunnnar Heikkil=E4 -----Original Message----- From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org= ] On Behalf Of David Singer Sent: ti 9 november 2010 11:31 To: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) Cc: Ingemar Johansson S; httpstreaming; dispatch@ietf.org; conex@ietf.org Subject: Re: [httpstreaming] [dispatch] Q-HTTP There is a bitter lesson I have learned over the years to do with QoS reser= vation. It is that there are two ways to solve a real-time bandwidth need. One is = to reserve bandwidth, manage QoS and so on; one gets protocols and systems= like diffserv, ATM, and so on. The other is simply to have 'too much' of = the resource. Though it feels wrong, the latter often ends up being the ch= eaper and easier solution. So, for example, voice over IP is getting used = quite a lot, and to good effect, on the internet today not because we have = successfully deployed any bandwidth reservation or QoS management protocols= and systems, but because the available bandwidth is, for the most part, gr= eatly in excess of what is needed, and the systems can adapt in real-time t= o what they get (rather than asking for what they want). The same is true = for multimedia delivery; the complexity of RTP + TCP friendliness + QoS ma= nagement is not worth it compared to having adaptable end-systems and overa= ll more bandwidth than needed. (I worked on real-time scheduling systems as well, and the same applies; i= t's cheaper to have a processor which is much faster than needed, with a no= rmal scheduler, than to have a just-enough processor with a real-time sched= uler). I know, it 'feels' wrong. David Singer Multimedia and Software Standards, Apple Inc. _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming From singer@apple.com Tue Nov 9 03:45:57 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EF503A686A; Tue, 9 Nov 2010 03:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe-j6D8dn0OI; Tue, 9 Nov 2010 03:45:56 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 15C4B3A6886; Tue, 9 Nov 2010 03:45:56 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out3.apple.com (Postfix) with ESMTP id 445B2B5D24E7; Tue, 9 Nov 2010 03:46:20 -0800 (PST) X-AuditID: 11807134-b7c05ae000002d5d-f8-4cd9347e0bbf Received: from [17.72.145.128] (Unknown_Domain [17.72.145.128]) by relay14.apple.com (Apple SCV relay) with SMTP id 18.A0.11613.08439DC4; Tue, 9 Nov 2010 03:46:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: David Singer In-Reply-To: Date: Tue, 9 Nov 2010 12:46:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: =?iso-8859-1?Q?Gunnar_Heikkil=E4?= X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 09 Nov 2010 22:08:12 -0800 Cc: Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , httpstreaming , "dispatch@ietf.org" , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 11:45:57 -0000 On Nov 9, 2010, at 12:37 , Gunnar Heikkil=E4 wrote: > Hi David, Jose Javier, >=20 > for cellular networks (for instance a PC using a mobile broadband = dongle) over-provisioning is really expensive and you have to do = something smarter. But I am not sure that the Q-HTTP concept is the way = forward since it is based on injecting test traffic into the system.=20 Right, but there is a choice of what the 'smarter' is. (A) do some kind = of QoS reservation (bandwidth reservation, maximum loss guarantee etc.) = and then trust it; or (B) measure and adapt to what you're getting. In case (A) if you are going to be resilient you should implement (B), = so that if the reservation 'fails' you don't fail in turn. So you = implement (B) anyway, and now the question is whether a new, special = protocol for (A) is worth the trouble. One huge downside is that it = moves you away from generic servers, caches, proxies, CDNs and other = existing network infrastructure. In wireless, mobile, networks, it's hard to guarantee that the user = won't move to the edge of a cell, or into a crowded cell where the = reservation cannot be maintained, and so on. Conversely, the 'cost' or = availability of a reservation may well depend on the degree of = competition. David Singer Multimedia and Software Standards, Apple Inc. From gunnar.heikkila@ericsson.com Tue Nov 9 04:04:48 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 893AC3A68A6; Tue, 9 Nov 2010 04:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 564ok6jggbEb; Tue, 9 Nov 2010 04:04:35 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 601B53A686E; Tue, 9 Nov 2010 04:04:34 -0800 (PST) X-AuditID: c1b4fb39-b7b54ae000003464-10-4cd938e9ae5c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.01.13412.9E839DC4; Tue, 9 Nov 2010 13:04:57 +0100 (CET) Received: from ESESSCMS0364.eemea.ericsson.se ([169.254.2.79]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 9 Nov 2010 13:04:56 +0100 From: =?iso-8859-1?Q?Gunnar_Heikkil=E4?= To: David Singer Date: Tue, 9 Nov 2010 13:04:56 +0100 Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuAA72D1Oi/URn8T+SNPTHrIZ1PXQAAXG6Q Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Tue, 09 Nov 2010 22:08:11 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , =?iso-8859-1?Q?Gunnar_Heikkil=E4?= Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 12:04:49 -0000 Hi David, basically I agree with your view. My main point is that using extra traffic= to solve bandwidth limitations has some built-in problems. Best would be i= f all applications could be made elastic and adapt to whatever problem they= experience (like for AMR codec daptation etc.)... Gunnar Heikkil=E4 Ericsson Research=20 -----Original Message----- From: David Singer [mailto:singer@apple.com]=20 Sent: ti 9 november 2010 12:46 To: Gunnar Heikkil=E4 Cc: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Ingemar Johansson S; httpstre= aming; dispatch@ietf.org; conex@ietf.org Subject: Re: [httpstreaming] [dispatch] Q-HTTP On Nov 9, 2010, at 12:37 , Gunnar Heikkil=E4 wrote: > Hi David, Jose Javier, >=20 > for cellular networks (for instance a PC using a mobile broadband dongle)= over-provisioning is really expensive and you have to do something smarter= . But I am not sure that the Q-HTTP concept is the way forward since it is = based on injecting test traffic into the system.=20 Right, but there is a choice of what the 'smarter' is. (A) do some kind of= QoS reservation (bandwidth reservation, maximum loss guarantee etc.) and t= hen trust it; or (B) measure and adapt to what you're getting. In case (A) if you are going to be resilient you should implement (B), so t= hat if the reservation 'fails' you don't fail in turn. So you implement (B)= anyway, and now the question is whether a new, special protocol for (A) is= worth the trouble. One huge downside is that it moves you away from gener= ic servers, caches, proxies, CDNs and other existing network infrastructure= . In wireless, mobile, networks, it's hard to guarantee that the user won't m= ove to the edge of a cell, or into a crowded cell where the reservation can= not be maintained, and so on. Conversely, the 'cost' or availability of a = reservation may well depend on the degree of competition. David Singer Multimedia and Software Standards, Apple Inc. From hmmr@cisco.com Tue Nov 9 07:37:20 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F8D3A683A; Tue, 9 Nov 2010 07:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+XcZ+7-nZn6; Tue, 9 Nov 2010 07:37:18 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 43DE63A688F; Tue, 9 Nov 2010 07:37:18 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALf42EytJV2Y/2dsb2JhbACiInGjbptlhUoEhFmJDw X-IronPort-AV: E=Sophos;i="4.59,174,1288569600"; d="scan'208";a="180222798" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2010 15:37:42 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id oA9Fbg3B030397; Tue, 9 Nov 2010 15:37:42 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 09:37:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Nov 2010 09:37:40 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] [httpstreaming] Q-HTTP Thread-Index: Act/+UlpMMdCwOPNTv+dYC+XcynYvwAKevGw References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com><3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> From: "Mike Hammer (hmmr)" To: "David Singer" , "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" X-OriginalArrivalTime: 09 Nov 2010 15:37:42.0274 (UTC) FILETIME=[0C3DB620:01CB8024] X-Mailman-Approved-At: Tue, 09 Nov 2010 22:08:10 -0800 Cc: Ingemar Johansson S , httpstreaming , dispatch@ietf.org, conex@ietf.org Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 15:37:21 -0000 David, Video has much more volume and burstiness than VoIP, so not sure that analogy will hold. If you cannot be sure to have at least 50% non-latency-sensitive traffic, and maybe more like 70%, then you will not be over-provisioned enough to have the slack available. And if video is the lion's share of the traffic, then you better hope that most of that is non-interactive. Else, you need some type of CAC to ensure live video doesn't get disrupted. Separate question. Took a quick read and it seems this Q-HTTP is a separate flow rather than embedded attributes in the flow it is attempting to help. What if there is more than one flow involved? And how do you keep each control and app associated? Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of David Singer Sent: Tuesday, November 09, 2010 5:31 AM To: GARCIA ARANDA,JOSE JAVIER (JOSE JAVIER) Cc: Ingemar Johansson S; httpstreaming; dispatch@ietf.org; conex@ietf.org Subject: Re: [dispatch] [httpstreaming] Q-HTTP There is a bitter lesson I have learned over the years to do with QoS reservation. It is that there are two ways to solve a real-time bandwidth need. One is to reserve bandwidth, manage QoS and so on; one gets protocols and systems like diffserv, ATM, and so on. The other is simply to have 'too much' of the resource. Though it feels wrong, the latter often ends up being the cheaper and easier solution. So, for example, voice over IP is getting used quite a lot, and to good effect, on the internet today not because we have successfully deployed any bandwidth reservation or QoS management protocols and systems, but because the available bandwidth is, for the most part, greatly in excess of what is needed, and the systems can adapt in real-time to what they get (rather than asking for what they want). The same is true for multimedia delivery; the complexity of RTP + TCP friendliness + QoS management is not worth it compared to having adaptable end-systems and overall more bandwidth than needed. (I worked on real-time scheduling systems as well, and the same applies; it's cheaper to have a processor which is much faster than needed, with a normal scheduler, than to have a just-enough processor with a real-time scheduler). I know, it 'feels' wrong. David Singer Multimedia and Software Standards, Apple Inc. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From jose_javier.garcia_aranda@alcatel-lucent.com Tue Nov 9 09:27:26 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B017F28C12B; Tue, 9 Nov 2010 09:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.244 X-Spam-Level: X-Spam-Status: No, score=-5.244 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-qqJZhc9dzV; Tue, 9 Nov 2010 09:27:25 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 553DF3A6A11; Tue, 9 Nov 2010 09:27:25 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oA9HRbJG007409 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 9 Nov 2010 18:27:37 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 9 Nov 2010 18:27:37 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: "Mike Hammer (hmmr)" , David Singer Date: Tue, 9 Nov 2010 18:27:36 +0100 Thread-Topic: [dispatch] [httpstreaming] Q-HTTP Thread-Index: Act/+UlpMMdCwOPNTv+dYC+XcynYvwAKevGwAAOEgIA= Message-ID: <3349FECF788C984BB34176D70A51782F16877366@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com><3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Tue, 09 Nov 2010 22:08:10 -0800 Cc: Ingemar Johansson S , httpstreaming , "dispatch@ietf.org" , "conex@ietf.org" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 17:27:26 -0000 Hi Mike and all Q-HTTP uses a separate control flow for measurements, as you mention, and t= he application could have N flows.=20 When Q-HTTP monitor the quality, it monitors at the "QoS level" of the appl= ication flows and alert if constraints are being violated. If the application has other "non quality" flows, these are not in the scop= e of Q-HTTP. Q-HTTP is designed to monitor a set of flows simultaneously (in forward and= reverse directions) with different constraints and sensitiveness in each d= irection. The flows are grouped by constraints, so the same Q-HTTP control = flow monitor two sets of flows at the same time: - a set of downstream flows with the same constraints - a set of upstream flows with the same constraints ( different from downst= ream constraints) The constraints in the same Q-HTTP control flow are defined for up and down= sepparately, so the same control flow can have different constraints for u= p and down, and also different responsiveness (different kbps usage by the = control flow in up and down) The underlaying idea is to allow monitor the quality of any application dat= a protocol used ( simple data over UDP or TCP, ftp, rtp, http, propietary, = etc etc), in order to be able to provide a universal measurement/alerting m= echanism for any communication at application level. And...when the alert is raised, what to do? Well, there are a lot of option= s, for example reduce bitrate of app data flows, or limit the functionalies= of the application, or the server can invoke a operator QoS service asking= for more quality, or invoke a multi-operator entity which acts over the po= licy servers of the different operators, or also the network itself could b= e Q-HTTP aware and react by itself when an alert is raised... All these pos= sibilities are open, and not defined in the draft, but all of them are poss= ibilities =20 - Jose Javier -----Mensaje original----- De: Mike Hammer (hmmr) [mailto:hmmr@cisco.com]=20 Enviado el: martes, 09 de noviembre de 2010 16:38 Para: David Singer; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) CC: Ingemar Johansson S; httpstreaming; dispatch@ietf.org; conex@ietf.org Asunto: RE: [dispatch] [httpstreaming] Q-HTTP David, Video has much more volume and burstiness than VoIP, so not sure that analo= gy will hold. If you cannot be sure to have at least 50% non-latency-sensi= tive traffic, and maybe more like 70%, then you will not be over-provisione= d enough to have the slack available. And if video is the lion's share of = the traffic, then you better hope that most of that is non-interactive. El= se, you need some type of CAC to ensure live video doesn't get disrupted. Separate question. Took a quick read and it seems this Q-HTTP is a separat= e flow rather than embedded attributes in the flow it is attempting to help= . What if there is more than one flow involved? And how do you keep each = control and app associated? Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of David Singer Sent: Tuesday, November 09, 2010 5:31 AM To: GARCIA ARANDA,JOSE JAVIER (JOSE JAVIER) Cc: Ingemar Johansson S; httpstreaming; dispatch@ietf.org; conex@ietf.org Subject: Re: [dispatch] [httpstreaming] Q-HTTP There is a bitter lesson I have learned over the years to do with QoS reser= vation. It is that there are two ways to solve a real-time bandwidth need. One is = to reserve bandwidth, manage QoS and so on; one gets protocols and systems= like diffserv, ATM, and so on. The other is simply to have 'too much' of = the resource. Though it feels wrong, the latter often ends up being the ch= eaper and easier solution. So, for example, voice over IP is getting used = quite a lot, and to good effect, on the internet today not because we have = successfully deployed any bandwidth reservation or QoS management protocols= and systems, but because the available bandwidth is, for the most part, gr= eatly in excess of what is needed, and the systems can adapt in real-time t= o what they get (rather than asking for what they want). The same is true = for multimedia delivery; the complexity of RTP + TCP friendliness + QoS man= agement is not worth it compared to having adaptable end-systems and overal= l more bandwidth than needed. (I worked on real-time scheduling systems as well, and the same applies; it= 's cheaper to have a processor which is much faster than needed, with a nor= mal scheduler, than to have a just-enough processor with a real-time schedu= ler). I know, it 'feels' wrong. David Singer Multimedia and Software Standards, Apple Inc. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From henry.sinnreich@gmail.com Tue Nov 9 15:22:27 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA003A6800; Tue, 9 Nov 2010 15:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqkbJQiV2XfB; Tue, 9 Nov 2010 15:22:26 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 27B683A696C; Tue, 9 Nov 2010 15:22:26 -0800 (PST) Received: by ywp6 with SMTP id 6so9300ywp.31 for ; Tue, 09 Nov 2010 15:22:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=uy+WusBQgIN+l/bLqN/ccGaINLOM3taklGWAzVgSVbw=; b=rhAJaGTz1e5TyYwy51Zhad5evu4KdUo/UnfQQOkQ/Y2hegK+8wdJdl7w2fDBrYufbZ N2oYUc2Yr6niCABZtMDd9PkBcmW5XELgbyD6zHzGUhfr0eke6xFZzFU0m56sOiW8tYVK /4v75VXd1xDMbiy5t96FilRrg9CxLGnjCWpVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=K1XQlOAd2hyvN6ti7Acro0FKq0Ov0XGcdlj2s3I9FXxpd66jNmGNxgWgPtvs5ac1FK cdBuEkJgOXXOG2kGVCylY/hK5Jz2UKO0Xn21j+i4MqM+h7iynj7hfJVHFM9CKvUjhPxu ijQzmtcX9IWDXQfsy/l3ikgYr9bj1D1fwnBkg= Received: by 10.90.29.19 with SMTP id c19mr7737005agc.209.1289344970374; Tue, 09 Nov 2010 15:22:50 -0800 (PST) Received: from [192.168.0.34] (cpe-76-184-225-216.tx.res.rr.com [76.184.225.216]) by mx.google.com with ESMTPS id 13sm1833117anq.10.2010.11.09.15.22.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Nov 2010 15:22:48 -0800 (PST) User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Tue, 09 Nov 2010 17:22:44 -0600 From: Henry Sinnreich To: David Singer , "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" Message-ID: Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuAZQL3xpa4JwEh2ESdfOwbd/mLbg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Tue, 09 Nov 2010 22:08:08 -0800 Cc: Ingemar Johansson S , httpstreaming , dispatch@ietf.org, conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 23:22:27 -0000 +1 Fully agree. Thanks, Henry On 11/9/10 4:31 AM, "David Singer" wrote: > There is a bitter lesson I have learned over the years to do with QoS > reservation. > > It is that there are two ways to solve a real-time bandwidth need. One is to > reserve bandwidth, manage QoS and so on; one gets protocols and systems like > diffserv, ATM, and so on. The other is simply to have 'too much' of the > resource. Though it feels wrong, the latter often ends up being the cheaper > and easier solution. So, for example, voice over IP is getting used quite a > lot, and to good effect, on the internet today not because we have > successfully deployed any bandwidth reservation or QoS management protocols > and systems, but because the available bandwidth is, for the most part, > greatly in excess of what is needed, and the systems can adapt in real-time to > what they get (rather than asking for what they want). The same is true for > multimedia delivery; the complexity of RTP + TCP friendliness + QoS > management is not worth it compared to having adaptable end-systems and > overall more bandwidth than needed. > > (I worked on real-time scheduling systems as well, and the same applies; it's > cheaper to have a processor which is much faster than needed, with a normal > scheduler, than to have a just-enough processor with a real-time scheduler). > > I know, it 'feels' wrong. > > David Singer > Multimedia and Software Standards, Apple Inc. > > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming From watsonm@netflix.com Tue Nov 9 20:18:53 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21BDE3A67AB; Tue, 9 Nov 2010 20:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvADFF2C1fDN; Tue, 9 Nov 2010 20:18:52 -0800 (PST) Received: from mx1.netflix.com (mx1.netflix.com [208.75.77.144]) by core3.amsl.com (Postfix) with ESMTP id 369613A684F; Tue, 9 Nov 2010 20:18:52 -0800 (PST) Received: from ExchFE102.netflix.com (exchfe102.netflix.com [10.64.32.102]) by mx1.netflix.com (8.12.11.20060308/8.12.11) with ESMTP id oAA4JCGH017730; Tue, 9 Nov 2010 20:19:12 -0800 Received: from EXCHMBX103.netflix.com ([fe80::c8e2:ac0e:d177:53c6]) by ExchFE102.netflix.com ([fe80::416e:22e0:ebdf:14b0%14]) with mapi; Tue, 9 Nov 2010 20:19:11 -0800 From: Mark Watson To: Kathy McEwen Date: Tue, 9 Nov 2010 20:19:10 -0800 Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuAjmy2DbYTXxLsQwO+PWlAAVcPSg== Message-ID: <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> In-Reply-To: <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 09 Nov 2010 22:08:10 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , David Singer Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 04:18:53 -0000 Sent from my iPad On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" w= rote: > One problem with the voice analogy is that the sheer volume of data > traversing the web today is not driven by voice...it's video...and it's n= ot > even a fraction of the viewing that folks are doing of broadcast content.= A > solution that depends on "simply" having too much bandwidth, is that some= one > is paying for it. Eventually it hits someone's pocket books....and if th= ere > isn't sufficient revenue to cover the costs, the too much does degrade. > Today the mass media is consumed via cheap broadcast technologies... why > shouldn't the web (fixed and mobile) be as cheap AND as good?? =20 >=20 It should, the question is what is the cheapest way to do it. QoS is expens= ive too. I tend to agree with the thesis below that history is telling us t= hat avoiding scarcity in the first place is cheaper than rationing here. ...Mark > -----Original Message----- > From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.o= rg] > On Behalf Of Lars Eggert > Sent: Tuesday, November 09, 2010 8:02 PM > To: David Singer > Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); > httpstreaming; dispatch@ietf.org; conex@ietf.org > Subject: Re: [httpstreaming] [dispatch] Q-HTTP >=20 > On 2010-11-9, at 18:31, David Singer wrote: >> It is that there are two ways to solve a real-time bandwidth need. One = is > to reserve bandwidth, manage QoS and so on; one gets protocols and syste= ms > like diffserv, ATM, and so on. The other is simply to have 'too much' of > the resource. Though it feels wrong, the latter often ends up being the > cheaper and easier solution. So, for example, voice over IP is getting u= sed > quite a lot, and to good effect, on the internet today not because we hav= e > successfully deployed any bandwidth reservation or QoS management protoco= ls > and systems, but because the available bandwidth is, for the most part, > greatly in excess of what is needed, and the systems can adapt in real-ti= me > to what they get (rather than asking for what they want). The same is tr= ue > for multimedia delivery; the complexity of RTP + TCP friendliness + QoS > management is not worth it compared to having adaptable end-systems and > overall more bandwidth than needed. >=20 > Fully agreed.=20 >=20 > Folks who like pictures can take a look at > https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much the s= ame > argument. >=20 > Lars >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From roland.bless@kit.edu Wed Nov 10 00:11:29 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA53C3A6A28; Wed, 10 Nov 2010 00:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVIsrtCTnOgy; Wed, 10 Nov 2010 00:11:26 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id A8B133A6A17; Wed, 10 Nov 2010 00:11:25 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PG5mF-0000yX-E6; Wed, 10 Nov 2010 09:11:37 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1PG5mF-0004ta-9w; Wed, 10 Nov 2010 09:11:31 +0100 Received: from vorta.tm.uka.de (i72vorta.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 3D4CD2FC046; Wed, 10 Nov 2010 09:11:31 +0100 (CET) Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.uka.de (Postfix) with ESMTPS id 1C9D7282; Wed, 10 Nov 2010 09:11:31 +0100 (CET) Message-ID: <4CDA53B2.9000209@kit.edu> Date: Wed, 10 Nov 2010 09:11:30 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: David Singer References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1289376697.411569000 Cc: dispatch@ietf.org, Qin Wu , httpstreaming , conex@ietf.org, Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 08:11:29 -0000 Hi David, On 09.11.2010 11:31, David Singer wrote: > It is that there are two ways to solve a real-time bandwidth need. > One is to reserve bandwidth, manage QoS and so on; one gets > protocols and systems like diffserv, ATM, and so on. The other is > simply to have 'too much' of the resource. Though it feels wrong, QoS mechanisms are usually only necessary if you've got some kind of resource shortage. They try to manage the resource scarcity in some way then. So having "too much of a resource" seems to imply that we actually don't need any QoS support. The basic problem is that even if you over-provision you'll depend on the traffic distribution (i.e. the traffic matrix). For instance, if you've got 10x100Mbit/s links aggregated to a 1 Gbit/s "upstream" link, you usually have no problem of transmitting traffic towards the larger link. In the other direction though, it depends heavily on the incoming traffic distribution. So if the 1 Gbit/s link transmits 200 Mbit/s towards a single 100Mbit/s link over a longer period, you'll get dropped packets. Denial-of-Service attacks can achieve this effect intentionally. It's no problem using my PC and trying to flood several DSL subscriber lines, or using 10 PCs at our campus site and trying to flood some link with the aggregated bandwidth of ~ 10 Gbit/s. Your real-time traffic will definitely suffer then... I fear that the bandwidth demand will increase a lot due to HD streaming etc. and that we need some kind of active QoS management at the edge or access networks at least. > the latter often ends up being the cheaper and easier solution. So, Yes, but not a really reliable solution and it works only as long as the fair/whatever resource share is enough to provide the minimum acceptable quality. > The same is true for multimedia delivery; the complexity of RTP + > TCP friendliness + QoS management is not worth it compared to having > adaptable end-systems and overall more bandwidth than needed. I agree that having adaptable applications is a good idea anyway and that QoS management adds a lot of complexity (and also complexity at SLA level). > (I worked on real-time scheduling systems as well, and the same > applies; it's cheaper to have a processor which is much faster than > needed, with a normal scheduler, than to have a just-enough processor > with a real-time scheduler). > I know, it 'feels' wrong. I think it's fine as long as everything behaves somehow friendly, i.e., in the absence of DoS flooding attacks... Regards, Roland From ingemar.s.johansson@ericsson.com Wed Nov 10 00:14:19 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C543A67AD; Wed, 10 Nov 2010 00:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77gQ6PhRvoMs; Wed, 10 Nov 2010 00:14:17 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9564B3A69E0; Wed, 10 Nov 2010 00:14:16 -0800 (PST) X-AuditID: c1b4fb3d-b7b28ae00000135b-46-4cda5472e621 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A4.16.04955.2745ADC4; Wed, 10 Nov 2010 09:14:42 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 10 Nov 2010 09:14:41 +0100 From: Ingemar Johansson S To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" , Mark Watson , Kathy McEwen Date: Wed, 10 Nov 2010 09:14:39 +0100 Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuAjmy2DbYTXxLsQwO+PWlAAVcPSgAGMA9gAAHATYA= Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F1687741D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <3349FECF788C984BB34176D70A51782F1687741D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: httpstreaming , "dispatch@ietf.org" , David Singer , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 08:14:19 -0000 Hi I see congestion and delay as two sides of the same coin. I believe that so= me of the good to do's in Lars slides mentioned the use of AQM and avoid lo= ng buffers. This of course assumes that applications are responsive to cong= etsion signals (packet drops, ECN..) within a few RTTs. If that holds true = then the aggregate traffic in a bottleneck will not load the network beyond= the point where delay gets high (or packet losses increases daramatically) /Ingemar =20 > -----Original Message----- > From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)=20 > [mailto:jose_javier.garcia_aranda@alcatel-lucent.com]=20 > Sent: den 10 november 2010 15:25 > To: Mark Watson; Kathy McEwen > Cc: Lars Eggert; David Singer; Ingemar Johansson S;=20 > httpstreaming; dispatch@ietf.org; conex@ietf.org > Subject: RE: [httpstreaming] [dispatch] Q-HTTP >=20 > =20 > Adaptable non-interactive video delivery is suitable for=20 > congestion problems, but what about latency? > It is no possible to adapt to a large latency reducing video=20 > resolution. >=20 > I refer to the "interactive video" scenario, for example a=20 > virtualized videogame. > Video must be delivered to the final user quickly and final=20 > user press action controls which change the video in=20 > real-time. If final user wants to play to "Street fighter" in=20 > a videoconsole located in the cloud, it is needed a mechanism=20 > for Measuring and adjust latency, in both directions. >=20 > Even with overall more bandwidth than needed, the problem persists. >=20 > - Jose Javier >=20 >=20 > -----Mensaje original----- > De: Mark Watson [mailto:watsonm@netflix.com] Enviado el:=20 > mi=E9rcoles, 10 de noviembre de 2010 5:19 > Para: Kathy McEwen > CC: Lars Eggert; David Singer; Ingemar Johansson S; GARCIA=20 > ARANDA, JOSE JAVIER (JOSE JAVIER); httpstreaming;=20 > dispatch@ietf.org; conex@ietf.org > Asunto: Re: [httpstreaming] [dispatch] Q-HTTP >=20 >=20 >=20 > Sent from my iPad >=20 > On Nov 9, 2010, at 7:01 PM, "Kathy McEwen"=20 > wrote: >=20 > > One problem with the voice analogy is that the sheer volume of data=20 > > traversing the web today is not driven by voice...it's video...and=20 > > it's not even a fraction of the viewing that folks are doing of=20 > > broadcast content. A solution that depends on "simply" having too=20 > > much bandwidth, is that someone is paying for it. =20 > Eventually it hits=20 > > someone's pocket books....and if there isn't sufficient=20 > revenue to cover the costs, the too much does degrade. > > Today the mass media is consumed via cheap broadcast=20 > technologies...=20 > > why shouldn't the web (fixed and mobile) be as cheap AND as good?? > >=20 >=20 > It should, the question is what is the cheapest way to do it.=20 > QoS is expensive too. I tend to agree with the thesis below=20 > that history is telling us that avoiding scarcity in the=20 > first place is cheaper than rationing here. >=20 > ...Mark >=20 > > -----Original Message----- > > From: httpstreaming-bounces@ietf.org=20 > > [mailto:httpstreaming-bounces@ietf.org] > > On Behalf Of Lars Eggert > > Sent: Tuesday, November 09, 2010 8:02 PM > > To: David Singer > > Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER);=20 > > httpstreaming; dispatch@ietf.org; conex@ietf.org > > Subject: Re: [httpstreaming] [dispatch] Q-HTTP > >=20 > > On 2010-11-9, at 18:31, David Singer wrote: > >> It is that there are two ways to solve a real-time=20 > bandwidth need. =20 > >> One is > > to reserve bandwidth, manage QoS and so on; one gets protocols and=20 > > systems like diffserv, ATM, and so on. The other is simply to have=20 > > 'too much' of the resource. Though it feels wrong, the=20 > latter often=20 > > ends up being the cheaper and easier solution. So, for=20 > example, voice=20 > > over IP is getting used quite a lot, and to good effect, on the=20 > > internet today not because we have successfully deployed=20 > any bandwidth=20 > > reservation or QoS management protocols and systems, but=20 > because the=20 > > available bandwidth is, for the most part, greatly in=20 > excess of what=20 > > is needed, and the systems can adapt in real-time to what they get=20 > > (rather than asking for what they want). The same is true for=20 > > multimedia delivery; the complexity of RTP + TCP=20 > friendliness + QoS=20 > > management is not worth it compared to having adaptable=20 > end-systems and overall more bandwidth than needed. > >=20 > > Fully agreed.=20 > >=20 > > Folks who like pictures can take a look at=20 > > https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much=20 > > the same argument. > >=20 > > Lars > >=20 > > _______________________________________________ > > httpstreaming mailing list > > httpstreaming@ietf.org > > https://www.ietf.org/mailman/listinfo/httpstreaming > >=20 > = From Dirk.Kutscher@neclab.eu Wed Nov 10 03:01:08 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467673A6A17; Wed, 10 Nov 2010 03:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3LblCEqT2WG; Wed, 10 Nov 2010 03:01:01 -0800 (PST) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id E84E73A6807; Wed, 10 Nov 2010 03:01:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id DE2172C0001AF; Wed, 10 Nov 2010 12:01:26 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office.hd) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD3gzcJL8QIc; Wed, 10 Nov 2010 12:01:26 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by smtp0.neclab.eu (Postfix) with ESMTP id 7D6202C0001AD; Wed, 10 Nov 2010 12:00:46 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.113]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0255.000; Wed, 10 Nov 2010 12:00:46 +0100 From: Dirk Kutscher To: Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" , Mark Watson , Kathy McEwen Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: AQHLf/lMwDWr4cdm7Eq5Argy8aUiaZNp5dYAgAAQigCAABXCAIAAM/KAgAAN2YCAACcW0A== Date: Wed, 10 Nov 2010 11:00:45 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F52495D39A2@PALLENE.office.hd> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F1687741D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.207] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: httpstreaming , "dispatch@ietf.org" , David Singer , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 11:01:08 -0000 Hi, Agree to Ingemar's view -- congestion and queuing delay are closely related= . The "QoS by over-provisioning" argument is however only half-true, becaus= e there are networking domains, such as wireless mobile (as already mention= ed here), where capacity demand is dynamic, resources are assigned dynamica= lly, depending on different factors, and some capacity scarcity can still b= e expected even in future networks. But independent of that, for the virtualized video game, I don't think you = are actually interested in measuring/adjusting latency as long as there are= AQM *and* good enough incentives for other applications to yield to your i= mportant, bursty video game traffic within a few RTTs. Such incentives for adapting your sending behavior can apply to both transp= ort and application layer behavior, i.e., congestion indication would trigg= er codec/format parameter switching. There are interesting questions on the= time scale of such adaptations, i.e., in relation to transport layer respo= nse to congestion. Best regards, Dirk > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Ingemar Johansson S > Sent: Wednesday, November 10, 2010 9:15 AM > To: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Mark Watson; Kathy McEwen > Cc: httpstreaming; dispatch@ietf.org; David Singer; conex@ietf.org > Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP >=20 > Hi >=20 > I see congestion and delay as two sides of the same coin. I believe > that some of the good to do's in Lars slides mentioned the use of AQM > and avoid long buffers. This of course assumes that applications are > responsive to congetsion signals (packet drops, ECN..) within a few > RTTs. If that holds true then the aggregate traffic in a bottleneck > will not load the network beyond the point where delay gets high (or > packet losses increases daramatically) >=20 > /Ingemar >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) > > [mailto:jose_javier.garcia_aranda@alcatel-lucent.com] > > Sent: den 10 november 2010 15:25 > > To: Mark Watson; Kathy McEwen > > Cc: Lars Eggert; David Singer; Ingemar Johansson S; > > httpstreaming; dispatch@ietf.org; conex@ietf.org > > Subject: RE: [httpstreaming] [dispatch] Q-HTTP > > > > > > Adaptable non-interactive video delivery is suitable for > > congestion problems, but what about latency? > > It is no possible to adapt to a large latency reducing video > > resolution. > > > > I refer to the "interactive video" scenario, for example a > > virtualized videogame. > > Video must be delivered to the final user quickly and final > > user press action controls which change the video in > > real-time. If final user wants to play to "Street fighter" in > > a videoconsole located in the cloud, it is needed a mechanism > > for Measuring and adjust latency, in both directions. > > > > Even with overall more bandwidth than needed, the problem persists. > > > > - Jose Javier > > > > > > -----Mensaje original----- > > De: Mark Watson [mailto:watsonm@netflix.com] Enviado el: > > mi=E9rcoles, 10 de noviembre de 2010 5:19 > > Para: Kathy McEwen > > CC: Lars Eggert; David Singer; Ingemar Johansson S; GARCIA > > ARANDA, JOSE JAVIER (JOSE JAVIER); httpstreaming; > > dispatch@ietf.org; conex@ietf.org > > Asunto: Re: [httpstreaming] [dispatch] Q-HTTP > > > > > > > > Sent from my iPad > > > > On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" > > wrote: > > > > > One problem with the voice analogy is that the sheer volume of data > > > traversing the web today is not driven by voice...it's video...and > > > it's not even a fraction of the viewing that folks are doing of > > > broadcast content. A solution that depends on "simply" having too > > > much bandwidth, is that someone is paying for it. > > Eventually it hits > > > someone's pocket books....and if there isn't sufficient > > revenue to cover the costs, the too much does degrade. > > > Today the mass media is consumed via cheap broadcast > > technologies... > > > why shouldn't the web (fixed and mobile) be as cheap AND as good?? > > > > > > > It should, the question is what is the cheapest way to do it. > > QoS is expensive too. I tend to agree with the thesis below > > that history is telling us that avoiding scarcity in the > > first place is cheaper than rationing here. > > > > ...Mark > > > > > -----Original Message----- > > > From: httpstreaming-bounces@ietf.org > > > [mailto:httpstreaming-bounces@ietf.org] > > > On Behalf Of Lars Eggert > > > Sent: Tuesday, November 09, 2010 8:02 PM > > > To: David Singer > > > Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); > > > httpstreaming; dispatch@ietf.org; conex@ietf.org > > > Subject: Re: [httpstreaming] [dispatch] Q-HTTP > > > > > > On 2010-11-9, at 18:31, David Singer wrote: > > >> It is that there are two ways to solve a real-time > > bandwidth need. > > >> One is > > > to reserve bandwidth, manage QoS and so on; one gets protocols and > > > systems like diffserv, ATM, and so on. The other is simply to have > > > 'too much' of the resource. Though it feels wrong, the > > latter often > > > ends up being the cheaper and easier solution. So, for > > example, voice > > > over IP is getting used quite a lot, and to good effect, on the > > > internet today not because we have successfully deployed > > any bandwidth > > > reservation or QoS management protocols and systems, but > > because the > > > available bandwidth is, for the most part, greatly in > > excess of what > > > is needed, and the systems can adapt in real-time to what they get > > > (rather than asking for what they want). The same is true for > > > multimedia delivery; the complexity of RTP + TCP > > friendliness + QoS > > > management is not worth it compared to having adaptable > > end-systems and overall more bandwidth than needed. > > > > > > Fully agreed. > > > > > > Folks who like pictures can take a look at > > > https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much > > > the same argument. > > > > > > Lars > > > > > > _______________________________________________ > > > httpstreaming mailing list > > > httpstreaming@ietf.org > > > https://www.ietf.org/mailman/listinfo/httpstreaming > > > > > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From jose_javier.garcia_aranda@alcatel-lucent.com Tue Nov 9 23:25:40 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04AB33A6A3B; Tue, 9 Nov 2010 23:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.682 X-Spam-Level: X-Spam-Status: No, score=-5.682 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zrA5gwSfROV; Tue, 9 Nov 2010 23:25:38 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 07CDA3A6A40; Tue, 9 Nov 2010 23:24:47 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAA7P7ZO010933 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Nov 2010 08:25:07 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 10 Nov 2010 08:25:07 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: Mark Watson , Kathy McEwen Date: Wed, 10 Nov 2010 08:25:05 +0100 Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuAjmy2DbYTXxLsQwO+PWlAAVcPSgAGMA9g Message-ID: <3349FECF788C984BB34176D70A51782F1687741D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> In-Reply-To: <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 X-Mailman-Approved-At: Wed, 10 Nov 2010 10:44:54 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , David Singer Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 07:25:40 -0000 =20 Adaptable non-interactive video delivery is suitable for congestion problem= s, but what about latency? It is no possible to adapt to a large latency reducing video resolution. I refer to the "interactive video" scenario, for example a virtualized vide= ogame. Video must be delivered to the final user quickly and final user press=20 action controls which change the video in real-time. If final user wants to= play to "Street fighter" in a videoconsole located in the cloud, it is needed a mec= hanism for Measuring and adjust latency, in both directions. Even with overall more bandwidth than needed, the problem persists. - Jose Javier -----Mensaje original----- De: Mark Watson [mailto:watsonm@netflix.com]=20 Enviado el: mi=E9rcoles, 10 de noviembre de 2010 5:19 Para: Kathy McEwen CC: Lars Eggert; David Singer; Ingemar Johansson S; GARCIA ARANDA, JOSE JAV= IER (JOSE JAVIER); httpstreaming; dispatch@ietf.org; conex@ietf.org Asunto: Re: [httpstreaming] [dispatch] Q-HTTP Sent from my iPad On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" w= rote: > One problem with the voice analogy is that the sheer volume of data=20 > traversing the web today is not driven by voice...it's video...and=20 > it's not even a fraction of the viewing that folks are doing of=20 > broadcast content. A solution that depends on "simply" having too=20 > much bandwidth, is that someone is paying for it. Eventually it hits=20 > someone's pocket books....and if there isn't sufficient revenue to cover = the costs, the too much does degrade. > Today the mass media is consumed via cheap broadcast technologies...=20 > why shouldn't the web (fixed and mobile) be as cheap AND as good?? >=20 It should, the question is what is the cheapest way to do it. QoS is expens= ive too. I tend to agree with the thesis below that history is telling us t= hat avoiding scarcity in the first place is cheaper than rationing here. ...Mark > -----Original Message----- > From: httpstreaming-bounces@ietf.org=20 > [mailto:httpstreaming-bounces@ietf.org] > On Behalf Of Lars Eggert > Sent: Tuesday, November 09, 2010 8:02 PM > To: David Singer > Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER);=20 > httpstreaming; dispatch@ietf.org; conex@ietf.org > Subject: Re: [httpstreaming] [dispatch] Q-HTTP >=20 > On 2010-11-9, at 18:31, David Singer wrote: >> It is that there are two ways to solve a real-time bandwidth need. =20 >> One is > to reserve bandwidth, manage QoS and so on; one gets protocols and=20 > systems like diffserv, ATM, and so on. The other is simply to have=20 > 'too much' of the resource. Though it feels wrong, the latter often=20 > ends up being the cheaper and easier solution. So, for example, voice=20 > over IP is getting used quite a lot, and to good effect, on the=20 > internet today not because we have successfully deployed any bandwidth=20 > reservation or QoS management protocols and systems, but because the=20 > available bandwidth is, for the most part, greatly in excess of what=20 > is needed, and the systems can adapt in real-time to what they get=20 > (rather than asking for what they want). The same is true for=20 > multimedia delivery; the complexity of RTP + TCP friendliness + QoS=20 > management is not worth it compared to having adaptable end-systems and o= verall more bandwidth than needed. >=20 > Fully agreed.=20 >=20 > Folks who like pictures can take a look at=20 > https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much=20 > the same argument. >=20 > Lars >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From singer@apple.com Wed Nov 10 05:01:29 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14CEA3A68CD; Wed, 10 Nov 2010 05:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z11NS5vIDG99; Wed, 10 Nov 2010 05:01:21 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 4922A3A689B; Wed, 10 Nov 2010 05:01:20 -0800 (PST) Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 239D3BBE7199; Wed, 10 Nov 2010 05:01:44 -0800 (PST) X-AuditID: 11807137-b7bf7ae000000f05-35-4cda97b50e2a Received: from [17.72.145.142] (Unknown_Domain [17.72.145.142]) by relay16.apple.com (Apple SCV relay) with SMTP id 59.EA.03845.6B79ADC4; Wed, 10 Nov 2010 05:01:44 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Singer In-Reply-To: <4CDA53B2.9000209@kit.edu> Date: Wed, 10 Nov 2010 14:01:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <57CDBEC2-8424-4A16-95B5-2006FC9C4F9C@apple.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4CDA53B2.9000209@kit.edu> To: Roland Bless X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 10 Nov 2010 10:44:54 -0800 Cc: dispatch@ietf.org, Qin Wu , httpstreaming , conex@ietf.org, Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 13:01:29 -0000 Hi Roland, On Nov 10, 2010, at 9:11 , Roland Bless wrote: > Hi David, >=20 > On 09.11.2010 11:31, David Singer wrote: >=20 >> It is that there are two ways to solve a real-time bandwidth need. >> One is to reserve bandwidth, manage QoS and so on; one gets >> protocols and systems like diffserv, ATM, and so on. The other is >> simply to have 'too much' of the resource. Though it feels wrong, >=20 > QoS mechanisms are usually only necessary if you've got some kind of > resource shortage. They try to manage the resource scarcity in some > way then. So having "too much of a resource" seems to imply that we > actually don't need any QoS support. >=20 I think this raises a question that happens at a service provider. = Imagine I observe that my networks are getting more busy, and decide to = invest some more in them. Do I (a) deploy a QoS management = infrastructure or (b) use those same funds to pay for capacity upgrades? = I think that most operators end up choosing (b) as it 'lifts all = boats', whereas they are not confident that anyone will use (a) in the = near future, and they know it won't benefit everyone (and in fact, will = be to the detriment of some users who don't use it, and were previously = doing 'fair competition' for bandwidth and now are 'second class' behind = those with reserved bandwidth). David Singer Multimedia and Software Standards, Apple Inc. From tom.van_caenegem@alcatel-lucent.com Wed Nov 10 05:26:57 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F8C3A68ED; Wed, 10 Nov 2010 05:26:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.537 X-Spam-Level: X-Spam-Status: No, score=-5.537 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uim0FUsHwzG6; Wed, 10 Nov 2010 05:26:56 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 772F83A6909; Wed, 10 Nov 2010 05:26:56 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAADRGXe006639 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Nov 2010 14:27:17 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.43]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 10 Nov 2010 14:27:16 +0100 From: "Van Caenegem, Tom (Tom)" To: David Singer , Roland Bless Date: Wed, 10 Nov 2010 14:27:15 +0100 Thread-Topic: [httpstreaming] [conex] [dispatch] Q-HTTP Thread-Index: AcuA15ARlYYFRIX4QHy509JeQKp3VgAASpwg Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <4CDA53B2.9000209@kit.edu> <57CDBEC2-8424-4A16-95B5-2006FC9C4F9C@apple.com> In-Reply-To: <57CDBEC2-8424-4A16-95B5-2006FC9C4F9C@apple.com> Accept-Language: nl-NL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nl-NL, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Wed, 10 Nov 2010 10:44:54 -0800 Cc: "dispatch@ietf.org" , Ingemar, httpstreaming , "conex@ietf.org" , Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 13:26:57 -0000 Hi David, In the end, SPs are driven by costs and revenus. Does option (a) represent = the same cost as (b)? (I do not know..) -How will the investment be paid back in case of (a).. Raising subscriptio= n fees for everyone? Will that not lead to enhanced subscriber churn? Is ne= t revenu then positive for the SP? -How will the investment be paid back in case of (b)... Those subscribers t= hat want 1st class service will be willing to pay extra for it. Other that = won't, will probably sense they get a smaller piece of the bandwidth pie, a= nd may decide to change SP. What is net revenu here? My impression is that it is not immediately clear whether (a) or (b) or any= mix of (a) and (b) is the best strategy for a SP. Regards Tom=20 -----Original Message----- From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org= ] On Behalf Of David Singer Sent: woensdag 10 november 2010 14:02 To: Roland Bless Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; = GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) Subject: Re: [httpstreaming] [conex] [dispatch] Q-HTTP Hi Roland, On Nov 10, 2010, at 9:11 , Roland Bless wrote: > Hi David, >=20 > On 09.11.2010 11:31, David Singer wrote: >=20 >> It is that there are two ways to solve a real-time bandwidth need. >> One is to reserve bandwidth, manage QoS and so on; one gets=20 >> protocols and systems like diffserv, ATM, and so on. The other is=20 >> simply to have 'too much' of the resource. Though it feels wrong, >=20 > QoS mechanisms are usually only necessary if you've got some kind of=20 > resource shortage. They try to manage the resource scarcity in some=20 > way then. So having "too much of a resource" seems to imply that we=20 > actually don't need any QoS support. >=20 I think this raises a question that happens at a service provider. Imagine= I observe that my networks are getting more busy, and decide to invest som= e more in them. Do I (a) deploy a QoS management infrastructure or (b) use= those same funds to pay for capacity upgrades? I think that most operator= s end up choosing (b) as it 'lifts all boats', whereas they are not confide= nt that anyone will use (a) in the near future, and they know it won't bene= fit everyone (and in fact, will be to the detriment of some users who don't= use it, and were previously doing 'fair competition' for bandwidth and now= are 'second class' behind those with reserved bandwidth). David Singer Multimedia and Software Standards, Apple Inc. _______________________________________________ httpstreaming mailing list httpstreaming@ietf.org https://www.ietf.org/mailman/listinfo/httpstreaming From hmmr@cisco.com Wed Nov 10 07:04:37 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A928A3A69DE; Wed, 10 Nov 2010 07:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AglCFVVZUJv9; Wed, 10 Nov 2010 07:04:36 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2FEBD3A6851; Wed, 10 Nov 2010 07:04:36 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC9D2kytJXG8/2dsb2JhbACiNXGiQJsshUoEhFqJDw X-IronPort-AV: E=Sophos;i="4.59,178,1288569600"; d="scan'208";a="180623895" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rtp-iport-2.cisco.com with ESMTP; 10 Nov 2010 15:05:02 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id oAAF52sh004094; Wed, 10 Nov 2010 15:05:02 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 09:05:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 09:05:01 -0600 Message-ID: In-Reply-To: <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] [httpstreaming] Q-HTTP Thread-Index: AcuAjmy2DbYTXxLsQwO+PWlAAVcPSgAWTnVg References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com><3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com><01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> From: "Mike Hammer (hmmr)" To: "Mark Watson" , "Kathy McEwen" X-OriginalArrivalTime: 10 Nov 2010 15:05:02.0541 (UTC) FILETIME=[A68FEFD0:01CB80E8] X-Mailman-Approved-At: Wed, 10 Nov 2010 10:44:54 -0800 Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Ingemar Johansson S , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 15:04:37 -0000 Nice theory. Until it gets down to who is going to pay for the over-provisioning. Is the ARPU going to go up? Are content distributors willing to pay more to send that data? Also, note how the volume of traffic always seems to expand to fill the BW available. Mike -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mark Watson Sent: Tuesday, November 09, 2010 11:19 PM To: Kathy McEwen Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) Subject: Re: [dispatch] [httpstreaming] Q-HTTP Sent from my iPad On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" wrote: > One problem with the voice analogy is that the sheer volume of data > traversing the web today is not driven by voice...it's video...and it's not > even a fraction of the viewing that folks are doing of broadcast content. A > solution that depends on "simply" having too much bandwidth, is that someone > is paying for it. Eventually it hits someone's pocket books....and if there > isn't sufficient revenue to cover the costs, the too much does degrade. > Today the mass media is consumed via cheap broadcast technologies... why > shouldn't the web (fixed and mobile) be as cheap AND as good?? =20 >=20 It should, the question is what is the cheapest way to do it. QoS is expensive too. I tend to agree with the thesis below that history is telling us that avoiding scarcity in the first place is cheaper than rationing here. ...Mark > -----Original Message----- > From: httpstreaming-bounces@ietf.org [mailto:httpstreaming-bounces@ietf.org] > On Behalf Of Lars Eggert > Sent: Tuesday, November 09, 2010 8:02 PM > To: David Singer > Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); > httpstreaming; dispatch@ietf.org; conex@ietf.org > Subject: Re: [httpstreaming] [dispatch] Q-HTTP >=20 > On 2010-11-9, at 18:31, David Singer wrote: >> It is that there are two ways to solve a real-time bandwidth need. One is > to reserve bandwidth, manage QoS and so on; one gets protocols and systems > like diffserv, ATM, and so on. The other is simply to have 'too much' of > the resource. Though it feels wrong, the latter often ends up being the > cheaper and easier solution. So, for example, voice over IP is getting used > quite a lot, and to good effect, on the internet today not because we have > successfully deployed any bandwidth reservation or QoS management protocols > and systems, but because the available bandwidth is, for the most part, > greatly in excess of what is needed, and the systems can adapt in real-time > to what they get (rather than asking for what they want). The same is true > for multimedia delivery; the complexity of RTP + TCP friendliness + QoS > management is not worth it compared to having adaptable end-systems and > overall more bandwidth than needed. >=20 > Fully agreed.=20 >=20 > Folks who like pictures can take a look at > https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much the same > argument. >=20 > Lars >=20 > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From singer@apple.com Wed Nov 10 07:24:51 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC0E3A69F6; Wed, 10 Nov 2010 07:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hf1iRR79eeCy; Wed, 10 Nov 2010 07:24:50 -0800 (PST) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 85C0E3A696B; Wed, 10 Nov 2010 07:24:50 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id D8808B62733F; Wed, 10 Nov 2010 07:25:17 -0800 (PST) X-AuditID: 11807136-b7b3aae0000033cc-94-4cdab946272b Received: from [17.72.145.142] (Unknown_Domain [17.72.145.142]) by relay15.apple.com (Apple SCV relay) with SMTP id 9E.93.13260.B49BADC4; Wed, 10 Nov 2010 07:25:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Singer In-Reply-To: Date: Wed, 10 Nov 2010 16:24:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> To: "Mike Hammer (hmmr)" X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 10 Nov 2010 10:44:54 -0800 Cc: dispatch@ietf.org, Kathy McEwen , httpstreaming , conex@ietf.org, Ingemar Johansson S , Mark Watson , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 15:24:51 -0000 On Nov 10, 2010, at 16:05 , Mike Hammer (hmmr) wrote: > Nice theory. Until it gets down to who is going to pay for the > over-provisioning. Well, it's a nice theory until someone asks who is going to (a) pay for = the QoS management infrastructure and (b) pay for the QoS managed = traffic. >=20 > Is the ARPU going to go up? Are content distributors willing to pay > more to send that data? >=20 > Also, note how the volume of traffic always seems to expand to fill = the > BW available. >=20 > Mike >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mark Watson > Sent: Tuesday, November 09, 2010 11:19 PM > To: Kathy McEwen > Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar = Johansson > S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) > Subject: Re: [dispatch] [httpstreaming] Q-HTTP >=20 >=20 >=20 > Sent from my iPad >=20 > On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" > wrote: >=20 >> One problem with the voice analogy is that the sheer volume of data >> traversing the web today is not driven by voice...it's video...and > it's not >> even a fraction of the viewing that folks are doing of broadcast > content. A >> solution that depends on "simply" having too much bandwidth, is that > someone >> is paying for it. Eventually it hits someone's pocket books....and = if > there >> isn't sufficient revenue to cover the costs, the too much does > degrade. >> Today the mass media is consumed via cheap broadcast technologies... > why >> shouldn't the web (fixed and mobile) be as cheap AND as good?? =20 >>=20 >=20 > It should, the question is what is the cheapest way to do it. QoS is > expensive too. I tend to agree with the thesis below that history is > telling us that avoiding scarcity in the first place is cheaper than > rationing here. >=20 > ...Mark >=20 >> -----Original Message----- >> From: httpstreaming-bounces@ietf.org > [mailto:httpstreaming-bounces@ietf.org] >> On Behalf Of Lars Eggert >> Sent: Tuesday, November 09, 2010 8:02 PM >> To: David Singer >> Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); >> httpstreaming; dispatch@ietf.org; conex@ietf.org >> Subject: Re: [httpstreaming] [dispatch] Q-HTTP >>=20 >> On 2010-11-9, at 18:31, David Singer wrote: >>> It is that there are two ways to solve a real-time bandwidth need. > One is >> to reserve bandwidth, manage QoS and so on; one gets protocols and > systems >> like diffserv, ATM, and so on. The other is simply to have 'too = much' > of >> the resource. Though it feels wrong, the latter often ends up being > the >> cheaper and easier solution. So, for example, voice over IP is > getting used >> quite a lot, and to good effect, on the internet today not because we > have >> successfully deployed any bandwidth reservation or QoS management > protocols >> and systems, but because the available bandwidth is, for the most > part, >> greatly in excess of what is needed, and the systems can adapt in > real-time >> to what they get (rather than asking for what they want). The same = is > true >> for multimedia delivery; the complexity of RTP + TCP friendliness + > QoS >> management is not worth it compared to having adaptable end-systems > and >> overall more bandwidth than needed. >>=20 >> Fully agreed.=20 >>=20 >> Folks who like pictures can take a look at >> https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much > the same >> argument. >>=20 >> Lars >>=20 >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch David Singer Multimedia and Software Standards, Apple Inc. From hmmr@cisco.com Wed Nov 10 08:07:03 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B4028C0D8; Wed, 10 Nov 2010 08:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNkCyWoTEQgo; Wed, 10 Nov 2010 08:07:02 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B738B3A6A49; Wed, 10 Nov 2010 08:07:01 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD9R2kytJXG//2dsb2JhbACiNXGiX5sxhUoEhFqJDw X-IronPort-AV: E=Sophos;i="4.59,178,1288569600"; d="scan'208";a="180663741" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-2.cisco.com with ESMTP; 10 Nov 2010 16:07:28 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id oAAG7S9U010925; Wed, 10 Nov 2010 16:07:28 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 10:07:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 10:07:26 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] [httpstreaming] Q-HTTP Thread-Index: AcuA635tZrZtFBYVRyKsZzNajgoYqQAA6wfQ References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> From: "Mike Hammer (hmmr)" To: "David Singer" X-OriginalArrivalTime: 10 Nov 2010 16:07:28.0382 (UTC) FILETIME=[5F41E9E0:01CB80F1] X-Mailman-Approved-At: Wed, 10 Nov 2010 10:44:54 -0800 Cc: dispatch@ietf.org, Kathy McEwen , httpstreaming , conex@ietf.org, Ingemar Johansson S , Mark Watson , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 16:07:04 -0000 My problem is that the alternative solution proposes that: 1) Users will police themselves and degrade their experience for the good of the Internet, and 2) Somehow high-BW bursty applications will become non-bursty. 3) The people that build and operate the networks will double (quadruple?) their investments for no additional return out of the goodness of their hearts. Somehow this reminds me of Gates prognostication that 640K was all the memory that a PC would ever need. I'm sympathetic with having a simple answer, but I just haven't seen that happen in the last 30 years. Don't forget that for some time we have had QoS managed and paid for. =20 The burden of proof then lies in proving the new economic model works. Good luck. I will be the first to congratulate you if you do. Cheers, Mike -----Original Message----- From: David Singer [mailto:singer@apple.com]=20 Sent: Wednesday, November 10, 2010 10:25 AM To: Mike Hammer (hmmr) Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) Subject: Re: [dispatch] [httpstreaming] Q-HTTP On Nov 10, 2010, at 16:05 , Mike Hammer (hmmr) wrote: > Nice theory. Until it gets down to who is going to pay for the > over-provisioning. Well, it's a nice theory until someone asks who is going to (a) pay for the QoS management infrastructure and (b) pay for the QoS managed traffic. >=20 > Is the ARPU going to go up? Are content distributors willing to pay > more to send that data? >=20 > Also, note how the volume of traffic always seems to expand to fill the > BW available. >=20 > Mike >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mark Watson > Sent: Tuesday, November 09, 2010 11:19 PM > To: Kathy McEwen > Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson > S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) > Subject: Re: [dispatch] [httpstreaming] Q-HTTP >=20 >=20 >=20 > Sent from my iPad >=20 > On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" > wrote: >=20 >> One problem with the voice analogy is that the sheer volume of data >> traversing the web today is not driven by voice...it's video...and > it's not >> even a fraction of the viewing that folks are doing of broadcast > content. A >> solution that depends on "simply" having too much bandwidth, is that > someone >> is paying for it. Eventually it hits someone's pocket books....and if > there >> isn't sufficient revenue to cover the costs, the too much does > degrade. >> Today the mass media is consumed via cheap broadcast technologies... > why >> shouldn't the web (fixed and mobile) be as cheap AND as good?? =20 >>=20 >=20 > It should, the question is what is the cheapest way to do it. QoS is > expensive too. I tend to agree with the thesis below that history is > telling us that avoiding scarcity in the first place is cheaper than > rationing here. >=20 > ...Mark >=20 >> -----Original Message----- >> From: httpstreaming-bounces@ietf.org > [mailto:httpstreaming-bounces@ietf.org] >> On Behalf Of Lars Eggert >> Sent: Tuesday, November 09, 2010 8:02 PM >> To: David Singer >> Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); >> httpstreaming; dispatch@ietf.org; conex@ietf.org >> Subject: Re: [httpstreaming] [dispatch] Q-HTTP >>=20 >> On 2010-11-9, at 18:31, David Singer wrote: >>> It is that there are two ways to solve a real-time bandwidth need. > One is >> to reserve bandwidth, manage QoS and so on; one gets protocols and > systems >> like diffserv, ATM, and so on. The other is simply to have 'too much' > of >> the resource. Though it feels wrong, the latter often ends up being > the >> cheaper and easier solution. So, for example, voice over IP is > getting used >> quite a lot, and to good effect, on the internet today not because we > have >> successfully deployed any bandwidth reservation or QoS management > protocols >> and systems, but because the available bandwidth is, for the most > part, >> greatly in excess of what is needed, and the systems can adapt in > real-time >> to what they get (rather than asking for what they want). The same is > true >> for multimedia delivery; the complexity of RTP + TCP friendliness + > QoS >> management is not worth it compared to having adaptable end-systems > and >> overall more bandwidth than needed. >>=20 >> Fully agreed.=20 >>=20 >> Folks who like pictures can take a look at >> https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much > the same >> argument. >>=20 >> Lars >>=20 >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch David Singer Multimedia and Software Standards, Apple Inc. From singer@apple.com Wed Nov 10 08:27:22 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E100C28C0F9; Wed, 10 Nov 2010 08:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAh1T3RbwLnX; Wed, 10 Nov 2010 08:27:21 -0800 (PST) Received: from mail-out3.apple.com (mail-out.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 7566428C0F7; Wed, 10 Nov 2010 08:27:21 -0800 (PST) Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 13DEBB62C04A; Wed, 10 Nov 2010 08:27:49 -0800 (PST) X-AuditID: 11807136-b7b3aae0000033cc-c5-4cdac7eb17b2 Received: from [17.72.145.142] (Unknown_Domain [17.72.145.142]) by relay15.apple.com (Apple SCV relay) with SMTP id 9A.B1.13260.DE7CADC4; Wed, 10 Nov 2010 08:27:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Singer In-Reply-To: Date: Wed, 10 Nov 2010 17:27:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9426E357-5BCF-4D14-8FF2-867AE0BB77E5@apple.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> To: "Mike Hammer (hmmr)" X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 10 Nov 2010 10:44:54 -0800 Cc: dispatch@ietf.org, Kathy McEwen , httpstreaming , conex@ietf.org, Ingemar Johansson S , Mark Watson , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 16:27:23 -0000 Mike I'm not sure what you consider to be the primary model and what is the = alternative. Just in case we don't understand each other, I'll lay out = where I think we are. At the moment, we don't have QoS management, and HTTP streaming uses = HTTP, which rests on TCP. Applications don't "degrade themselves", they = get degraded when contention happens, as a result of TCP's flow = management, and have to cope. It's a 'fair' system in that respect = (especially when contrasted with RTP blast-and-hope). In a QoS-managed scenario, something 'allows' me to indicate that a flow = 'deserves' or 'needs' a certain QoS, including bandwidth, and then (if = granted) I become immune to cross-traffic. =20 For example, if all flows are equal, and initially there were 5 of which = 2 are QoS managed, and they request only 10% of the resource, we're in = great shape; they get 20% and the 3 remaining share the remainder 60%, = for 20% each. But now 7 new flows come along, not QoS managed, so there = are now 10 flows sharing that 60% for only 6% each, while the = QoS-managed ones get 10% -- no longer fair. If there isn't some = disincentive to QoS-book bandwidth (like having to pay) we'll all set up = the biggest channels we can. If we *do* have to pay, the complexity of = the QoS management is now increased -- not only handling the technical = booking and reservation, segregation of packet flows, and so on, but it = has a billing infrastructure too. Then, in the case of QoS management, the service is probably only as = strong as its weakest link. Some QoS management protocols either set up = an end-to-end QoS-managed flow (across potentially multiple providers) = or they fail. This doesn't allow for easy service introduction. = Alternatively, they manage only some of the links, and then the = QoS-booking becomes rather weak if the unmanaged link is the bottleneck. Then there is the question of who sets up and who pays. Imagine I (in = california) try to watch a BBC video (from the UK). It's me that needs = to pay, but the BBC that needs to indicate to the service what pipe and = QoS are needed to deliver their content. Then all the business between = me and them need to work out if they can do that QoS, and at what cost; = someone needs to ask me if I am willing to pay, and if I agree, tell the = BBC to setup the pipe, and off we go. Contrast this with today where = the BBC is careful not to use too much of its outbound pipe for one = customer, and I buy the pipe I want, and each organization in the middle = sells 'uplink' bandwidth. That's a 'static' business arrangement. On Nov 10, 2010, at 17:07 , Mike Hammer (hmmr) wrote: > My problem is that the alternative solution proposes that: >=20 > 1) Users will police themselves and degrade their experience for the > good of the Internet, and > 2) Somehow high-BW bursty applications will become non-bursty. > 3) The people that build and operate the networks will double > (quadruple?) their investments for no additional return out of the > goodness of their hearts. >=20 > Somehow this reminds me of Gates prognostication that 640K was all the > memory that a PC would ever need. >=20 > I'm sympathetic with having a simple answer, but I just haven't seen > that happen in the last 30 years. >=20 > Don't forget that for some time we have had QoS managed and paid for. =20= > The burden of proof then lies in proving the new economic model works. > Good luck. I will be the first to congratulate you if you do. >=20 > Cheers, > Mike >=20 >=20 > -----Original Message----- > From: David Singer [mailto:singer@apple.com]=20 > Sent: Wednesday, November 10, 2010 10:25 AM > To: Mike Hammer (hmmr) > Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming; > conex@ietf.org; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA, > JOSEJAVIER (JOSE JAVIER) > Subject: Re: [dispatch] [httpstreaming] Q-HTTP >=20 >=20 > On Nov 10, 2010, at 16:05 , Mike Hammer (hmmr) wrote: >=20 >> Nice theory. Until it gets down to who is going to pay for the >> over-provisioning. >=20 > Well, it's a nice theory until someone asks who is going to (a) pay = for > the QoS management infrastructure and (b) pay for the QoS managed > traffic. >=20 >>=20 >> Is the ARPU going to go up? Are content distributors willing to pay >> more to send that data? >>=20 >> Also, note how the volume of traffic always seems to expand to fill > the >> BW available. >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Mark Watson >> Sent: Tuesday, November 09, 2010 11:19 PM >> To: Kathy McEwen >> Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar > Johansson >> S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) >> Subject: Re: [dispatch] [httpstreaming] Q-HTTP >>=20 >>=20 >>=20 >> Sent from my iPad >>=20 >> On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" >> wrote: >>=20 >>> One problem with the voice analogy is that the sheer volume of data >>> traversing the web today is not driven by voice...it's video...and >> it's not >>> even a fraction of the viewing that folks are doing of broadcast >> content. A >>> solution that depends on "simply" having too much bandwidth, is that >> someone >>> is paying for it. Eventually it hits someone's pocket books....and > if >> there >>> isn't sufficient revenue to cover the costs, the too much does >> degrade. >>> Today the mass media is consumed via cheap broadcast technologies... >> why >>> shouldn't the web (fixed and mobile) be as cheap AND as good?? =20 >>>=20 >>=20 >> It should, the question is what is the cheapest way to do it. QoS is >> expensive too. I tend to agree with the thesis below that history is >> telling us that avoiding scarcity in the first place is cheaper than >> rationing here. >>=20 >> ...Mark >>=20 >>> -----Original Message----- >>> From: httpstreaming-bounces@ietf.org >> [mailto:httpstreaming-bounces@ietf.org] >>> On Behalf Of Lars Eggert >>> Sent: Tuesday, November 09, 2010 8:02 PM >>> To: David Singer >>> Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); >>> httpstreaming; dispatch@ietf.org; conex@ietf.org >>> Subject: Re: [httpstreaming] [dispatch] Q-HTTP >>>=20 >>> On 2010-11-9, at 18:31, David Singer wrote: >>>> It is that there are two ways to solve a real-time bandwidth need. >> One is >>> to reserve bandwidth, manage QoS and so on; one gets protocols and >> systems >>> like diffserv, ATM, and so on. The other is simply to have 'too > much' >> of >>> the resource. Though it feels wrong, the latter often ends up being >> the >>> cheaper and easier solution. So, for example, voice over IP is >> getting used >>> quite a lot, and to good effect, on the internet today not because = we >> have >>> successfully deployed any bandwidth reservation or QoS management >> protocols >>> and systems, but because the available bandwidth is, for the most >> part, >>> greatly in excess of what is needed, and the systems can adapt in >> real-time >>> to what they get (rather than asking for what they want). The same > is >> true >>> for multimedia delivery; the complexity of RTP + TCP friendliness + >> QoS >>> management is not worth it compared to having adaptable end-systems >> and >>> overall more bandwidth than needed. >>>=20 >>> Fully agreed.=20 >>>=20 >>> Folks who like pictures can take a look at >>> https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much >> the same >>> argument. >>>=20 >>> Lars >>>=20 >>> _______________________________________________ >>> httpstreaming mailing list >>> httpstreaming@ietf.org >>> https://www.ietf.org/mailman/listinfo/httpstreaming >>>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 David Singer Multimedia and Software Standards, Apple Inc. From luismi.diaz@alcatel-lucent.com Wed Nov 10 09:14:05 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825563A68FC; Wed, 10 Nov 2010 09:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSoXPkfPDlKn; Wed, 10 Nov 2010 09:14:03 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 56CF83A67B2; Wed, 10 Nov 2010 09:14:02 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAAHDtqt022396 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 10 Nov 2010 18:13:58 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 10 Nov 2010 18:13:55 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: David Singer , "Mike Hammer (hmmr)" Date: Wed, 10 Nov 2010 18:13:54 +0100 Thread-Topic: [dispatch] [httpstreaming] Q-HTTP Thread-Index: AcuA9FtOx2dWVsEcToaVcHKnRWJf+AABBl0w Message-ID: <3349FECF788C984BB34176D70A51782F1687791E@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <9426E357-5BCF-4D14-8FF2-867AE0BB77E5@apple.com> In-Reply-To: <9426E357-5BCF-4D14-8FF2-867AE0BB77E5@apple.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Wed, 10 Nov 2010 10:44:54 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , Kathy McEwen , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 17:15:43 -0000 Hi, Just my 2 cents on this... At the moment, some services are just not flying because of this "fairn= ess" on Internet...My personal opinion is that this is going to end (just h= ear the loud voices of Network operators like Telefonica claiming that Goog= le needs to pay them for the service they provide). With this in mind, we m= ust assume that the end-customer will pay for such "new-age" services (Goog= le VoD, Online Gaming, Virtualized Gaming or something we cant even think a= bout) to the service provider (Google, Game provider...). This service prov= ider will pay network operator to provide the service to the end user with = a minimum quality of experience (this is inline with network operators thou= ghts). Thus, Tier-1 providers will need to evolve their model from a "per-b= it" schema to a "per-bit-per-QoS" one. With all this in mind, we need the t= ools to: - Provide the flow requirements. Not all the services require the same para= meters from the network - A way to measure those parameters e2e. - A way to "cry for help" if those parameters are below (or critically clos= e) the limits - A way to account for this. You ask for QoS, you pay for that. Once we for= get fairness, we forget the flat-rate and change it to "pay for experience"= . Q-HTTP tries to answer this questions. We know this is not simple as in= volves many other actions (billing, modifying network QoS, multi-tier agree= ments, etc) but lets start work it out now :). Saludos, Luismi -----Mensaje original----- De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre = de David Singer Enviado el: mi=E9rcoles, 10 de noviembre de 2010 17:27 Para: Mike Hammer (hmmr) CC: dispatch@ietf.org; Kathy McEwen; httpstreaming; conex@ietf.org; Ingemar= Johansson S; Lars Eggert; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) Asunto: Re: [dispatch] [httpstreaming] Q-HTTP Mike I'm not sure what you consider to be the primary model and what is the alte= rnative. Just in case we don't understand each other, I'll lay out where I= think we are. At the moment, we don't have QoS management, and HTTP streaming uses HTTP, = which rests on TCP. Applications don't "degrade themselves", they get degr= aded when contention happens, as a result of TCP's flow management, and hav= e to cope. It's a 'fair' system in that respect (especially when contraste= d with RTP blast-and-hope). In a QoS-managed scenario, something 'allows' me to indicate that a flow 'd= eserves' or 'needs' a certain QoS, including bandwidth, and then (if grante= d) I become immune to cross-traffic. =20 For example, if all flows are equal, and initially there were 5 of which 2 = are QoS managed, and they request only 10% of the resource, we're in great = shape; they get 20% and the 3 remaining share the remainder 60%, for 20% e= ach. But now 7 new flows come along, not QoS managed, so there are now 10 = flows sharing that 60% for only 6% each, while the QoS-managed ones get 10%= -- no longer fair. If there isn't some disincentive to QoS-book bandwidth= (like having to pay) we'll all set up the biggest channels we can. If we = *do* have to pay, the complexity of the QoS management is now increased -- = not only handling the technical booking and reservation, segregation of pac= ket flows, and so on, but it has a billing infrastructure too. Then, in the case of QoS management, the service is probably only as strong= as its weakest link. Some QoS management protocols either set up an end-t= o-end QoS-managed flow (across potentially multiple providers) or they fail= . This doesn't allow for easy service introduction. Alternatively, they m= anage only some of the links, and then the QoS-booking becomes rather weak = if the unmanaged link is the bottleneck. Then there is the question of who sets up and who pays. Imagine I (in cali= fornia) try to watch a BBC video (from the UK). It's me that needs to pay,= but the BBC that needs to indicate to the service what pipe and QoS are ne= eded to deliver their content. Then all the business between me and them n= eed to work out if they can do that QoS, and at what cost; someone needs to= ask me if I am willing to pay, and if I agree, tell the BBC to setup the p= ipe, and off we go. Contrast this with today where the BBC is careful not = to use too much of its outbound pipe for one customer, and I buy the pipe I= want, and each organization in the middle sells 'uplink' bandwidth. That'= s a 'static' business arrangement. On Nov 10, 2010, at 17:07 , Mike Hammer (hmmr) wrote: > My problem is that the alternative solution proposes that: >=20 > 1) Users will police themselves and degrade their experience for the=20 > good of the Internet, and > 2) Somehow high-BW bursty applications will become non-bursty. > 3) The people that build and operate the networks will double > (quadruple?) their investments for no additional return out of the=20 > goodness of their hearts. >=20 > Somehow this reminds me of Gates prognostication that 640K was all the=20 > memory that a PC would ever need. >=20 > I'm sympathetic with having a simple answer, but I just haven't seen=20 > that happen in the last 30 years. >=20 > Don't forget that for some time we have had QoS managed and paid for. =20 > The burden of proof then lies in proving the new economic model works. > Good luck. I will be the first to congratulate you if you do. >=20 > Cheers, > Mike >=20 >=20 > -----Original Message----- > From: David Singer [mailto:singer@apple.com] > Sent: Wednesday, November 10, 2010 10:25 AM > To: Mike Hammer (hmmr) > Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming;=20 > conex@ietf.org; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA,=20 > JOSEJAVIER (JOSE JAVIER) > Subject: Re: [dispatch] [httpstreaming] Q-HTTP >=20 >=20 > On Nov 10, 2010, at 16:05 , Mike Hammer (hmmr) wrote: >=20 >> Nice theory. Until it gets down to who is going to pay for the=20 >> over-provisioning. >=20 > Well, it's a nice theory until someone asks who is going to (a) pay=20 > for the QoS management infrastructure and (b) pay for the QoS managed=20 > traffic. >=20 >>=20 >> Is the ARPU going to go up? Are content distributors willing to pay=20 >> more to send that data? >>=20 >> Also, note how the volume of traffic always seems to expand to fill > the >> BW available. >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 >> Behalf Of Mark Watson >> Sent: Tuesday, November 09, 2010 11:19 PM >> To: Kathy McEwen >> Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar > Johansson >> S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) >> Subject: Re: [dispatch] [httpstreaming] Q-HTTP >>=20 >>=20 >>=20 >> Sent from my iPad >>=20 >> On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" >> wrote: >>=20 >>> One problem with the voice analogy is that the sheer volume of data=20 >>> traversing the web today is not driven by voice...it's video...and >> it's not >>> even a fraction of the viewing that folks are doing of broadcast >> content. A >>> solution that depends on "simply" having too much bandwidth, is that >> someone >>> is paying for it. Eventually it hits someone's pocket books....and > if >> there >>> isn't sufficient revenue to cover the costs, the too much does >> degrade. >>> Today the mass media is consumed via cheap broadcast technologies... >> why >>> shouldn't the web (fixed and mobile) be as cheap AND as good?? =20 >>>=20 >>=20 >> It should, the question is what is the cheapest way to do it. QoS is=20 >> expensive too. I tend to agree with the thesis below that history is=20 >> telling us that avoiding scarcity in the first place is cheaper than=20 >> rationing here. >>=20 >> ...Mark >>=20 >>> -----Original Message----- >>> From: httpstreaming-bounces@ietf.org >> [mailto:httpstreaming-bounces@ietf.org] >>> On Behalf Of Lars Eggert >>> Sent: Tuesday, November 09, 2010 8:02 PM >>> To: David Singer >>> Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER);=20 >>> httpstreaming; dispatch@ietf.org; conex@ietf.org >>> Subject: Re: [httpstreaming] [dispatch] Q-HTTP >>>=20 >>> On 2010-11-9, at 18:31, David Singer wrote: >>>> It is that there are two ways to solve a real-time bandwidth need. >> One is >>> to reserve bandwidth, manage QoS and so on; one gets protocols and >> systems >>> like diffserv, ATM, and so on. The other is simply to have 'too > much' >> of >>> the resource. Though it feels wrong, the latter often ends up being >> the >>> cheaper and easier solution. So, for example, voice over IP is >> getting used >>> quite a lot, and to good effect, on the internet today not because=20 >>> we >> have >>> successfully deployed any bandwidth reservation or QoS management >> protocols >>> and systems, but because the available bandwidth is, for the most >> part, >>> greatly in excess of what is needed, and the systems can adapt in >> real-time >>> to what they get (rather than asking for what they want). The same > is >> true >>> for multimedia delivery; the complexity of RTP + TCP friendliness + >> QoS >>> management is not worth it compared to having adaptable end-systems >> and >>> overall more bandwidth than needed. >>>=20 >>> Fully agreed.=20 >>>=20 >>> Folks who like pictures can take a look at=20 >>> https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much >> the same >>> argument. >>>=20 >>> Lars >>>=20 >>> _______________________________________________ >>> httpstreaming mailing list >>> httpstreaming@ietf.org >>> https://www.ietf.org/mailman/listinfo/httpstreaming >>>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 David Singer Multimedia and Software Standards, Apple Inc. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From hmmr@cisco.com Wed Nov 10 10:26:31 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFB33A6981; Wed, 10 Nov 2010 10:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC71tEe0J7NY; Wed, 10 Nov 2010 10:26:30 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8F9903A68F9; Wed, 10 Nov 2010 10:26:28 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADtz2kytJXG//2dsb2JhbACiL3GjO5s6hUoEhFqJDw X-IronPort-AV: E=Sophos;i="4.59,179,1288569600"; d="scan'208";a="180506550" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-1.cisco.com with ESMTP; 10 Nov 2010 18:26:49 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id oAAIQmlO012894; Wed, 10 Nov 2010 18:26:48 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Nov 2010 12:26:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2010 12:26:47 -0600 Message-ID: In-Reply-To: <9426E357-5BCF-4D14-8FF2-867AE0BB77E5@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] [httpstreaming] Q-HTTP Thread-Index: AcuA9FJM1foyjOf7Q1GQ9W8UvC13+gADsd7Q References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <9426E357-5BCF-4D14-8FF2-867AE0BB77E5@apple.com> From: "Mike Hammer (hmmr)" To: "David Singer" X-OriginalArrivalTime: 10 Nov 2010 18:26:49.0194 (UTC) FILETIME=[D6B094A0:01CB8104] X-Mailman-Approved-At: Wed, 10 Nov 2010 10:44:54 -0800 Cc: dispatch@ietf.org, Kathy McEwen , httpstreaming , conex@ietf.org, Ingemar Johansson S , Mark Watson , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 18:26:31 -0000 David, It is possible we have different usage scenarios in mind and could be talking past one another. There are lots of variables. Is this unicast, multicast, broadcast, full-duplex, interactive, mixtures of high and low BW, latency-sensitive and not, very bursty and not, where the sources of content are, how many sources, P2P or not, etc. And all of these dynamically interact on the network. Some subset of applications may be able to play nicely on a BE network. But, I am just being cautions to not extrapolate that to all applications. In some cases, the QoS may be worth the management and cost proportional to its usage. So, maybe this is just an issue of scoping the application of the solution to the subset of traffic known to behave well. Mike -----Original Message----- From: David Singer [mailto:singer@apple.com]=20 Sent: Wednesday, November 10, 2010 11:27 AM To: Mike Hammer (hmmr) Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) Subject: Re: [dispatch] [httpstreaming] Q-HTTP Mike I'm not sure what you consider to be the primary model and what is the alternative. Just in case we don't understand each other, I'll lay out where I think we are. At the moment, we don't have QoS management, and HTTP streaming uses HTTP, which rests on TCP. Applications don't "degrade themselves", they get degraded when contention happens, as a result of TCP's flow management, and have to cope. It's a 'fair' system in that respect (especially when contrasted with RTP blast-and-hope). In a QoS-managed scenario, something 'allows' me to indicate that a flow 'deserves' or 'needs' a certain QoS, including bandwidth, and then (if granted) I become immune to cross-traffic. =20 For example, if all flows are equal, and initially there were 5 of which 2 are QoS managed, and they request only 10% of the resource, we're in great shape; they get 20% and the 3 remaining share the remainder 60%, for 20% each. But now 7 new flows come along, not QoS managed, so there are now 10 flows sharing that 60% for only 6% each, while the QoS-managed ones get 10% -- no longer fair. If there isn't some disincentive to QoS-book bandwidth (like having to pay) we'll all set up the biggest channels we can. If we *do* have to pay, the complexity of the QoS management is now increased -- not only handling the technical booking and reservation, segregation of packet flows, and so on, but it has a billing infrastructure too. Then, in the case of QoS management, the service is probably only as strong as its weakest link. Some QoS management protocols either set up an end-to-end QoS-managed flow (across potentially multiple providers) or they fail. This doesn't allow for easy service introduction. Alternatively, they manage only some of the links, and then the QoS-booking becomes rather weak if the unmanaged link is the bottleneck. Then there is the question of who sets up and who pays. Imagine I (in california) try to watch a BBC video (from the UK). It's me that needs to pay, but the BBC that needs to indicate to the service what pipe and QoS are needed to deliver their content. Then all the business between me and them need to work out if they can do that QoS, and at what cost; someone needs to ask me if I am willing to pay, and if I agree, tell the BBC to setup the pipe, and off we go. Contrast this with today where the BBC is careful not to use too much of its outbound pipe for one customer, and I buy the pipe I want, and each organization in the middle sells 'uplink' bandwidth. That's a 'static' business arrangement. On Nov 10, 2010, at 17:07 , Mike Hammer (hmmr) wrote: > My problem is that the alternative solution proposes that: >=20 > 1) Users will police themselves and degrade their experience for the > good of the Internet, and > 2) Somehow high-BW bursty applications will become non-bursty. > 3) The people that build and operate the networks will double > (quadruple?) their investments for no additional return out of the > goodness of their hearts. >=20 > Somehow this reminds me of Gates prognostication that 640K was all the > memory that a PC would ever need. >=20 > I'm sympathetic with having a simple answer, but I just haven't seen > that happen in the last 30 years. >=20 > Don't forget that for some time we have had QoS managed and paid for. > The burden of proof then lies in proving the new economic model works. > Good luck. I will be the first to congratulate you if you do. >=20 > Cheers, > Mike >=20 >=20 > -----Original Message----- > From: David Singer [mailto:singer@apple.com]=20 > Sent: Wednesday, November 10, 2010 10:25 AM > To: Mike Hammer (hmmr) > Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming; > conex@ietf.org; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA, > JOSEJAVIER (JOSE JAVIER) > Subject: Re: [dispatch] [httpstreaming] Q-HTTP >=20 >=20 > On Nov 10, 2010, at 16:05 , Mike Hammer (hmmr) wrote: >=20 >> Nice theory. Until it gets down to who is going to pay for the >> over-provisioning. >=20 > Well, it's a nice theory until someone asks who is going to (a) pay for > the QoS management infrastructure and (b) pay for the QoS managed > traffic. >=20 >>=20 >> Is the ARPU going to go up? Are content distributors willing to pay >> more to send that data? >>=20 >> Also, note how the volume of traffic always seems to expand to fill > the >> BW available. >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Mark Watson >> Sent: Tuesday, November 09, 2010 11:19 PM >> To: Kathy McEwen >> Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar > Johansson >> S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) >> Subject: Re: [dispatch] [httpstreaming] Q-HTTP >>=20 >>=20 >>=20 >> Sent from my iPad >>=20 >> On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" >> wrote: >>=20 >>> One problem with the voice analogy is that the sheer volume of data >>> traversing the web today is not driven by voice...it's video...and >> it's not >>> even a fraction of the viewing that folks are doing of broadcast >> content. A >>> solution that depends on "simply" having too much bandwidth, is that >> someone >>> is paying for it. Eventually it hits someone's pocket books....and > if >> there >>> isn't sufficient revenue to cover the costs, the too much does >> degrade. >>> Today the mass media is consumed via cheap broadcast technologies... >> why >>> shouldn't the web (fixed and mobile) be as cheap AND as good?? =20 >>>=20 >>=20 >> It should, the question is what is the cheapest way to do it. QoS is >> expensive too. I tend to agree with the thesis below that history is >> telling us that avoiding scarcity in the first place is cheaper than >> rationing here. >>=20 >> ...Mark >>=20 >>> -----Original Message----- >>> From: httpstreaming-bounces@ietf.org >> [mailto:httpstreaming-bounces@ietf.org] >>> On Behalf Of Lars Eggert >>> Sent: Tuesday, November 09, 2010 8:02 PM >>> To: David Singer >>> Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); >>> httpstreaming; dispatch@ietf.org; conex@ietf.org >>> Subject: Re: [httpstreaming] [dispatch] Q-HTTP >>>=20 >>> On 2010-11-9, at 18:31, David Singer wrote: >>>> It is that there are two ways to solve a real-time bandwidth need. >> One is >>> to reserve bandwidth, manage QoS and so on; one gets protocols and >> systems >>> like diffserv, ATM, and so on. The other is simply to have 'too > much' >> of >>> the resource. Though it feels wrong, the latter often ends up being >> the >>> cheaper and easier solution. So, for example, voice over IP is >> getting used >>> quite a lot, and to good effect, on the internet today not because we >> have >>> successfully deployed any bandwidth reservation or QoS management >> protocols >>> and systems, but because the available bandwidth is, for the most >> part, >>> greatly in excess of what is needed, and the systems can adapt in >> real-time >>> to what they get (rather than asking for what they want). The same > is >> true >>> for multimedia delivery; the complexity of RTP + TCP friendliness + >> QoS >>> management is not worth it compared to having adaptable end-systems >> and >>> overall more bandwidth than needed. >>>=20 >>> Fully agreed.=20 >>>=20 >>> Folks who like pictures can take a look at >>> https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much >> the same >>> argument. >>>=20 >>> Lars >>>=20 >>> _______________________________________________ >>> httpstreaming mailing list >>> httpstreaming@ietf.org >>> https://www.ietf.org/mailman/listinfo/httpstreaming >>>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 David Singer Multimedia and Software Standards, Apple Inc. From kathy@iridescentnetworks.com Wed Nov 10 10:43:21 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCAAD3A6853 for ; Wed, 10 Nov 2010 10:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDaDBwx8o35S for ; Wed, 10 Nov 2010 10:43:21 -0800 (PST) Received: from smtp104-mob.biz.mail.ac4.yahoo.com (smtp104-mob.biz.mail.ac4.yahoo.com [76.13.13.225]) by core3.amsl.com (Postfix) with SMTP id 571CD3A682F for ; Wed, 10 Nov 2010 10:43:21 -0800 (PST) Received: (qmail 66498 invoked from network); 10 Nov 2010 18:37:06 -0000 Received: from [10.9.85.23] (kathy@166.205.10.104 with xymcookie) by smtp104-mob.biz.mail.ac4.yahoo.com with SMTP; 10 Nov 2010 10:37:05 -0800 PST X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL X-YMail-OSG: tgF0cd8VM1mesochfWMlypN4ueiIzosLdb4VCg5CWjQXmXC dUsBcwDRc7XY_hY5yG9VPRwIbv0zhtudmzpfCh.S8UKq2RlVeUvckG4Ps2BW PCLn_4NApipRdSoQm34Y1LoA_bL2zdAPXPD0ldja4ApLJcx38zCruXLpaqVu nY7ZNBpZcgwuIHBl8Sa6moAUv1yH51xE4D.Igmkbqe7Rv3alDsFasAbQacad esJEGXj00UR0ZIJjU0ECpdZ5UNSFHIX3MypjHuK90ADtY0Lea9V_T1AoE1_A - X-Yahoo-Newman-Property: ymail-3 References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <9426E357-5BCF-4D14-8FF2-867AE0BB77E5@apple.com> Mime-Version: 1.0 (iPhone Mail 8B117) In-Reply-To: X-Apple-Yahoo-Original-Message-Folder: Inbox Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (8B117) From: Kathy McEwen X-Apple-Yahoo-Replied-Msgid: 1_723252_ALbHjkQAAKeCTNrj7whN4U94BfA Date: Wed, 10 Nov 2010 10:36:09 -0800 To: "Mike Hammer \(hmmr\)" X-Mailman-Approved-At: Wed, 10 Nov 2010 10:44:54 -0800 Cc: "" , httpstreaming , "" , Ingemar Johansson S , Mark Watson , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" , David Singer Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 18:43:21 -0000 A scope that limits applications to only those that behave well seems extrem= ely limiting. What would you categorize as well behaved and naughty?=20 Me, I tend to go for the naughty... Sent from my iPhone On Nov 10, 2010, at 10:26 AM, "Mike Hammer (hmmr)" wrote: > David, >=20 > It is possible we have different usage scenarios in mind and could be > talking past one another. There are lots of variables. Is this > unicast, multicast, broadcast, full-duplex, interactive, mixtures of > high and low BW, latency-sensitive and not, very bursty and not, where > the sources of content are, how many sources, P2P or not, etc. And all > of these dynamically interact on the network. Some subset of > applications may be able to play nicely on a BE network. But, I am just > being cautions to not extrapolate that to all applications. In some > cases, the QoS may be worth the management and cost proportional to its > usage. So, maybe this is just an issue of scoping the application of > the solution to the subset of traffic known to behave well. >=20 > Mike >=20 >=20 > -----Original Message----- > From: David Singer [mailto:singer@apple.com]=20 > Sent: Wednesday, November 10, 2010 11:27 AM > To: Mike Hammer (hmmr) > Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming; > conex@ietf.org; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA, > JOSEJAVIER (JOSE JAVIER) > Subject: Re: [dispatch] [httpstreaming] Q-HTTP >=20 > Mike >=20 > I'm not sure what you consider to be the primary model and what is the > alternative. Just in case we don't understand each other, I'll lay out > where I think we are. >=20 > At the moment, we don't have QoS management, and HTTP streaming uses > HTTP, which rests on TCP. Applications don't "degrade themselves", they > get degraded when contention happens, as a result of TCP's flow > management, and have to cope. It's a 'fair' system in that respect > (especially when contrasted with RTP blast-and-hope). >=20 > In a QoS-managed scenario, something 'allows' me to indicate that a flow > 'deserves' or 'needs' a certain QoS, including bandwidth, and then (if > granted) I become immune to cross-traffic. =20 >=20 > For example, if all flows are equal, and initially there were 5 of which > 2 are QoS managed, and they request only 10% of the resource, we're in > great shape; they get 20% and the 3 remaining share the remainder 60%, > for 20% each. But now 7 new flows come along, not QoS managed, so there > are now 10 flows sharing that 60% for only 6% each, while the > QoS-managed ones get 10% -- no longer fair. If there isn't some > disincentive to QoS-book bandwidth (like having to pay) we'll all set up > the biggest channels we can. If we *do* have to pay, the complexity of > the QoS management is now increased -- not only handling the technical > booking and reservation, segregation of packet flows, and so on, but it > has a billing infrastructure too. >=20 > Then, in the case of QoS management, the service is probably only as > strong as its weakest link. Some QoS management protocols either set up > an end-to-end QoS-managed flow (across potentially multiple providers) > or they fail. This doesn't allow for easy service introduction. > Alternatively, they manage only some of the links, and then the > QoS-booking becomes rather weak if the unmanaged link is the bottleneck. >=20 > Then there is the question of who sets up and who pays. Imagine I (in > california) try to watch a BBC video (from the UK). It's me that needs > to pay, but the BBC that needs to indicate to the service what pipe and > QoS are needed to deliver their content. Then all the business between > me and them need to work out if they can do that QoS, and at what cost; > someone needs to ask me if I am willing to pay, and if I agree, tell the > BBC to setup the pipe, and off we go. Contrast this with today where > the BBC is careful not to use too much of its outbound pipe for one > customer, and I buy the pipe I want, and each organization in the middle > sells 'uplink' bandwidth. That's a 'static' business arrangement. >=20 > On Nov 10, 2010, at 17:07 , Mike Hammer (hmmr) wrote: >=20 >> My problem is that the alternative solution proposes that: >>=20 >> 1) Users will police themselves and degrade their experience for the >> good of the Internet, and >> 2) Somehow high-BW bursty applications will become non-bursty. >> 3) The people that build and operate the networks will double >> (quadruple?) their investments for no additional return out of the >> goodness of their hearts. >>=20 >> Somehow this reminds me of Gates prognostication that 640K was all the >> memory that a PC would ever need. >>=20 >> I'm sympathetic with having a simple answer, but I just haven't seen >> that happen in the last 30 years. >>=20 >> Don't forget that for some time we have had QoS managed and paid for. >=20 >> The burden of proof then lies in proving the new economic model works. >> Good luck. I will be the first to congratulate you if you do. >>=20 >> Cheers, >> Mike >>=20 >>=20 >> -----Original Message----- >> From: David Singer [mailto:singer@apple.com]=20 >> Sent: Wednesday, November 10, 2010 10:25 AM >> To: Mike Hammer (hmmr) >> Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming; >> conex@ietf.org; Ingemar Johansson S; Lars Eggert; GARCIA ARANDA, >> JOSEJAVIER (JOSE JAVIER) >> Subject: Re: [dispatch] [httpstreaming] Q-HTTP >>=20 >>=20 >> On Nov 10, 2010, at 16:05 , Mike Hammer (hmmr) wrote: >>=20 >>> Nice theory. Until it gets down to who is going to pay for the >>> over-provisioning. >>=20 >> Well, it's a nice theory until someone asks who is going to (a) pay > for >> the QoS management infrastructure and (b) pay for the QoS managed >> traffic. >>=20 >>>=20 >>> Is the ARPU going to go up? Are content distributors willing to pay >>> more to send that data? >>>=20 >>> Also, note how the volume of traffic always seems to expand to fill >> the >>> BW available. >>>=20 >>> Mike >>>=20 >>>=20 >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Mark Watson >>> Sent: Tuesday, November 09, 2010 11:19 PM >>> To: Kathy McEwen >>> Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar >> Johansson >>> S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) >>> Subject: Re: [dispatch] [httpstreaming] Q-HTTP >>>=20 >>>=20 >>>=20 >>> Sent from my iPad >>>=20 >>> On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" >>> wrote: >>>=20 >>>> One problem with the voice analogy is that the sheer volume of data >>>> traversing the web today is not driven by voice...it's video...and >>> it's not >>>> even a fraction of the viewing that folks are doing of broadcast >>> content. A >>>> solution that depends on "simply" having too much bandwidth, is that >>> someone >>>> is paying for it. Eventually it hits someone's pocket books....and >> if >>> there >>>> isn't sufficient revenue to cover the costs, the too much does >>> degrade. >>>> Today the mass media is consumed via cheap broadcast technologies... >>> why >>>> shouldn't the web (fixed and mobile) be as cheap AND as good?? =20 >>>>=20 >>>=20 >>> It should, the question is what is the cheapest way to do it. QoS is >>> expensive too. I tend to agree with the thesis below that history is >>> telling us that avoiding scarcity in the first place is cheaper than >>> rationing here. >>>=20 >>> ...Mark >>>=20 >>>> -----Original Message----- >>>> From: httpstreaming-bounces@ietf.org >>> [mailto:httpstreaming-bounces@ietf.org] >>>> On Behalf Of Lars Eggert >>>> Sent: Tuesday, November 09, 2010 8:02 PM >>>> To: David Singer >>>> Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); >>>> httpstreaming; dispatch@ietf.org; conex@ietf.org >>>> Subject: Re: [httpstreaming] [dispatch] Q-HTTP >>>>=20 >>>> On 2010-11-9, at 18:31, David Singer wrote: >>>>> It is that there are two ways to solve a real-time bandwidth need. >>> One is >>>> to reserve bandwidth, manage QoS and so on; one gets protocols and >>> systems >>>> like diffserv, ATM, and so on. The other is simply to have 'too >> much' >>> of >>>> the resource. Though it feels wrong, the latter often ends up being >>> the >>>> cheaper and easier solution. So, for example, voice over IP is >>> getting used >>>> quite a lot, and to good effect, on the internet today not because > we >>> have >>>> successfully deployed any bandwidth reservation or QoS management >>> protocols >>>> and systems, but because the available bandwidth is, for the most >>> part, >>>> greatly in excess of what is needed, and the systems can adapt in >>> real-time >>>> to what they get (rather than asking for what they want). The same >> is >>> true >>>> for multimedia delivery; the complexity of RTP + TCP friendliness + >>> QoS >>>> management is not worth it compared to having adaptable end-systems >>> and >>>> overall more bandwidth than needed. >>>>=20 >>>> Fully agreed.=20 >>>>=20 >>>> Folks who like pictures can take a look at >>>> https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much >>> the same >>>> argument. >>>>=20 >>>> Lars >>>>=20 >>>> _______________________________________________ >>>> httpstreaming mailing list >>>> httpstreaming@ietf.org >>>> https://www.ietf.org/mailman/listinfo/httpstreaming >>>>=20 >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >> David Singer >> Multimedia and Software Standards, Apple Inc. >>=20 >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 From john@jlc.net Wed Nov 10 13:32:31 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E8213A69BC for ; Wed, 10 Nov 2010 13:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.041 X-Spam-Level: X-Spam-Status: No, score=-106.041 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OikKgvx71s4C for ; Wed, 10 Nov 2010 13:32:30 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id 6E49F3A692A for ; Wed, 10 Nov 2010 13:32:29 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 5AF1333C73; Wed, 10 Nov 2010 16:32:57 -0500 (EST) Date: Wed, 10 Nov 2010 16:32:57 -0500 From: John Leslie To: "Mcdysan, David E" Message-ID: <20101110213257.GA53213@verdi> References: <20101108153840.GV82074@verdi> <2464076D83FAED4D985BF2622111AAC40F95CCF86B@FHDP1LUMXC7V11.us.one.verizon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2464076D83FAED4D985BF2622111AAC40F95CCF86B@FHDP1LUMXC7V11.us.one.verizon.com> User-Agent: Mutt/1.4.1i Cc: conex@ietf.org Subject: Re: [conex] "Burstiness" X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 21:32:31 -0000 Mcdysan, David E wrote: > >> DM - Also note that "queue congestion" may not actually occur during a >> peak period. IMO customers should not experience different behaviors >> depending upon the state of capacity provisioned in the network, which >> could occur with the way that conex is currently defined. > > I must be misunderstanding: how can users _avoid_ a different experience > during a period of significant congestion? > > DM - As I understand the current conex use case, if the provisioned > capacity >> offered load then congestion (i.e., Pr[drop or ECN marking]) > is small and any congestion action (e.g., policing, pricing) will also > be small. Hopefully zero... > If the offered load approaches provisioned capacity then the congestion > is larger and congestion action will be larger. Hence, a user sending > the same traffic at different points in time will experience different > behaviors. Yes. (with or without ConEx...) > As mentioned by others in meetings and on the list, a typical provider > practice is to provision capacity such that congestion is small. Again, hopefully zero in the "normal" case. >>> To my provider-centric view, "burstiness" would decay with aggregation; >>> and I'd be concerned only after some aggregation had already occurred. >> >> DM - Not on a per flow basis. The non-work conserving shaper is the >> resource that can be congested, not an aggregate interface. > > A reference to "non-work conserving shaper" would help, I think. > > DM - I had thought of adding a reference to BBF (formerly DSL Forum) > TR-059, (48 pages) > but thought this was a specific mechanism. (I don't find "conserving shaper" in there, and the two mentions of "shaper" don't seem helpful.) > Reading the -02 moncaster draft, there is less mechanism than -01 but > there is still a fair amount that assumes a specific mechanism. After > having written this draft I have a better appreciation for the difficulty > involved with separating these concepts. Thank you! >>> Also, it makes quite a difference (to me) whether we're talking about >>> a point near the sender or near the receiver. Near the receiver, most >>> of the aggregation is long-since done, while near the sender, relatively >>> little has been done. I'm having difficulty seeing what metric could >>> serve both cases... >> >> DM - Agreed. see above, I think there at least two cases: per flow near >> receiver and aggregate at other points (e.g., between ISPs). > > (Hopefully I interpret this correctly: that David is thinking about > near-the-receiver and "charging" the receiver.) > > DM - In the "heavy/light user inequity use case, yes. In the recharging > use case, it would be a third party (e.g., the sender). I don't mean to exclude "sender-pays" -- I'm trying to understand the use case(s) you're proposing. (I really have read the draft several times, including another full reading before replying to this...) >> DM - The feedback I had in mind is to senders regarding the congestion >> experienced by a non-work conserving shaper that in addition to a short >> term rate also has the characteristic of allowed burstiness over a >> longer-time interval. > > I'm guessing here -- that David's "non-work conserving shaper" is > dropping some packets or otherwise marking as congestion some traffic > which isn't actual queue congestion. Please correct me if I'm guessing > wrong... > > DM - What I had in mind is providing feed forward (and feedback) on a > longer time scale than per packet. This strikes me as a funny thing to ask for at the IP layer... > IMO, a longer term view makes an experimental protocol implementable > in software versus a per packet method which probably requires hardware > or microcode changes. My own view is that initially deployment will only be at specific boundaries, and can be done by a dead-stupid device which only forwards packets from a known interface to another known interface, never waiting for the whole packet before forwarding. The processing needed could easily be done in software under these circumstances. At OC-48 this is trivial; at OC-192 (roughly 10-gig ethernet) I believe it's still cheap enough. >> It is congestion of this per user/flow interface that would enable a >> form of charging more suited to the heavy/light users reported by >> Varian and observed on the networks with which I have access to such >> measurements. I'm failing to understand why anything beyond aggregating from per- packet information (using a device running in the end-user's timezone) would help at all. In particular, I think the end-user (being charged for packets received) is in a far better position to judge his/her priorities than a sender perhaps 12 timezones away; and is in far better control (by limiting ACKs) than a sender which has little incentive to implement each provider's (changing) pricing rules. > A few questions come to mind: > > - is there some action to be taken by any point other than receiver and > sender? > > - is there an intent to collect and correlate this information elsewhere? > > - does David have in mind some specific metric useful under a different > business model? > > DM - I have some ideas on these, but I think they seem more like > mechanism. As of today, draft-moncaster is still an individual draft; and I feel an obligation not to promise something I don't understand and can't imagine a way to deliver. I don't require settling on a "final" mechanism (nor do I object in principle to gathering information we don't yet know how to use), but absent some kind of answers to questions like these, I'm not prepared to add David's use-cases before this becomes a WG draft. (Of course, if the WG has consensus to add them _when_ this becomes a WG draft, I'm willing to help edit them in...) > As I stated in response to Alissa, if the wg finds (some aspects) of > the proposed use cases interesting then I (inviting any others willing > and having time to work on this) to draft out some abstract mechanisms. Hopefully, the WG can discuss that this morning. -- John Leslie From swmike@swm.pp.se Wed Nov 10 14:08:00 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8941D3A63CB; Wed, 10 Nov 2010 14:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id onQ7sUdQXZWA; Wed, 10 Nov 2010 14:07:59 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 823E13A6358; Wed, 10 Nov 2010 14:07:59 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 722079C; Wed, 10 Nov 2010 23:08:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6F6859A; Wed, 10 Nov 2010 23:08:25 +0100 (CET) Date: Wed, 10 Nov 2010 23:08:25 +0100 (CET) From: Mikael Abrahamsson To: "Mike Hammer (hmmr)" In-Reply-To: Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Ingemar Johansson S , Kathy McEwen , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" , Mark Watson , David Singer Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 22:08:00 -0000 On Wed, 10 Nov 2010, Mike Hammer (hmmr) wrote: > 3) The people that build and operate the networks will double > (quadruple?) their investments for no additional return out of the > goodness of their hearts. No, they're going to do it because if they don't give the customers what they promised, their customers are going to leave. This is if there is a functional market and customers actually have a choice of providers. I realise this is not the case in parts of the world, but that doesn't mean we should solve that by technical means, that's a political and regulatory problem, it doesn't have any technical solution. Let's not forget that if you're congesting your core and distribution, you're not delivering what your customers have purchased. Period. Everything else is just smoke and mirrors. Congestion is acceptable on the customer access, it's not acceptable in the core. That means that any flows/pakets that should yield, are within a single customer domain, and thus in the customers own interest. -- Mikael Abrahamsson email: swmike@swm.pp.se From john@jlc.net Wed Nov 10 17:06:23 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD973A6872 for ; Wed, 10 Nov 2010 17:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.217 X-Spam-Level: X-Spam-Status: No, score=-106.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNopmdA8QDaL for ; Wed, 10 Nov 2010 17:06:22 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id A363A3A6870 for ; Wed, 10 Nov 2010 17:06:22 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 842D233C5A; Wed, 10 Nov 2010 20:06:51 -0500 (EST) Date: Wed, 10 Nov 2010 20:06:51 -0500 From: John Leslie To: conex@ietf.org Message-ID: <20101111010651.GB66928@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: [conex] Session Audio X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 01:06:23 -0000 ... is so quiet as to be useless. Please fix!!! -- John Leslie From swmike@swm.pp.se Thu Nov 11 07:31:43 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9AA23A6970; Thu, 11 Nov 2010 07:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mWIsQvD9oXN; Thu, 11 Nov 2010 07:31:40 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id C549B3A683F; Thu, 11 Nov 2010 07:31:39 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9EB599C; Thu, 11 Nov 2010 16:32:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9C4419A; Thu, 11 Nov 2010 16:32:08 +0100 (CET) Date: Thu, 11 Nov 2010 16:32:08 +0100 (CET) From: Mikael Abrahamsson To: "Mike Hammer (hmmr)" In-Reply-To: Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Ingemar Johansson S , Kathy McEwen , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" , Mark Watson , David Singer Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 15:31:43 -0000 On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote: > So, you are assuming that the alternative provider is not subject to the > same economic constraints as the provider you are jumping from? If that > were such an easy thing to do, you would see many more players on the > field, and fewer commentators in the stands. In my market there are lots of players and they all have possibility to reach end users because there are "neutral" L1 providers to rent fiber/copper from. Competition works, and it stops aggregation congestion. > Agree, that the core should not be getting congested, but this problem > gets worse progressively as you approach the customer edge. And the > costs to overprovision the edge go up correspondingly. The last mile is > the most expensive. The customer unique connection is ok to congest, it's running at the speed the customer is paying for. It's everything up from that that should "never" be congested, because then you're not giving the customer what they're paying for. It's a breach of contract, pure and simple. You're free to statistically overbook your aggregation up to the point where it's extremely rarely congesting. Would you accept a telephony network that gave you no dialtone half of the time you tried? I don't get it. Why would ISPs get away with not delivering what they have sold and why should we help them do this? What the IETF and everybody should focus on is SHOWING to the end users that there is congestion occuring, so they have a tool to give their consumer protection agency this informaiton to demand to cancel their contract because their ISP is not delivering on its promise. This works in all other markets, there false advertising is not tolerated, why should it be in the ISP market? If you're buying 100 megabit/s of residential bw you should be able to use this speed at least 99% of the time, otherwise your ISP is overselling the resource and you're not getting what you have bought. If the ISP has gigabit aggregation it's most likely that they can get away with 1000 users or more on this gige at this speed, but they will not get away with it by doing 200 meg aggregation. People talk about "fair". Fair business practice is to deliver what you've sold. Fair is to treat every customers traffic equally, to deliver the packets they want delivered. That is the job of the ISP. It's not to mistreat some traffic or discriminate. If anything, THAT is the unfair part. > > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Wednesday, November 10, 2010 5:08 PM > To: Mike Hammer (hmmr) > Cc: David Singer; dispatch@ietf.org; Kathy McEwen; httpstreaming; > conex@ietf.org; Ingemar Johansson S; Mark Watson; GARCIA ARANDA, > JOSEJAVIER (JOSE JAVIER) > Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP > > On Wed, 10 Nov 2010, Mike Hammer (hmmr) wrote: > >> 3) The people that build and operate the networks will double >> (quadruple?) their investments for no additional return out of the >> goodness of their hearts. > > No, they're going to do it because if they don't give the customers what > > they promised, their customers are going to leave. This is if there is a > > functional market and customers actually have a choice of providers. I > realise this is not the case in parts of the world, but that doesn't > mean > we should solve that by technical means, that's a political and > regulatory > problem, it doesn't have any technical solution. > > Let's not forget that if you're congesting your core and distribution, > you're not delivering what your customers have purchased. Period. > > Everything else is just smoke and mirrors. > > Congestion is acceptable on the customer access, it's not acceptable in > the core. That means that any flows/pakets that should yield, are within > a > single customer domain, and thus in the customers own interest. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > -- Mikael Abrahamsson email: swmike@swm.pp.se From jose_javier.garcia_aranda@alcatel-lucent.com Wed Nov 10 22:55:09 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED3D3A68B9; Wed, 10 Nov 2010 22:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.745 X-Spam-Level: X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUUDpFSdMJom; Wed, 10 Nov 2010 22:55:05 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id E034A3A69C8; Wed, 10 Nov 2010 22:54:44 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAB6t3BH029506 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 11 Nov 2010 07:55:03 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 11 Nov 2010 07:55:03 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" Date: Thu, 11 Nov 2010 07:55:01 +0100 Thread-Topic: [conex] [dispatch] [httpstreaming] Q-HTTP Thread-Index: AcuBI9H89oeASx/0Tda40uG+tV0XGgAR2aVA Message-ID: <3349FECF788C984BB34176D70A51782F16877A37@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> In-Reply-To: Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Thu, 11 Nov 2010 08:06:59 -0800 Cc: Mikael, "pkyzivat@cisco.com" , Ingemar Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , Mark Watson , David Singer Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 06:55:09 -0000 I fully agree with Paul Kyzivat and Luis miguel, in summary: - the contractual obligations of operators are very "light" "up to NNN bps"= . - these "light" obligations allow a low flat fee but not allow quality serv= ices - "new age services" needs QoS, and final user will pay for that service to= the content provider - content provider will pay network operator to provide the service to the = end user with a minimum quality of experience - Tier-1 providers will need to evolve their model from a "per-bit" schema = to a "per-bit-per-QoS" one As Luis Miguel said, we need the tools (Q-HTTP can be) to: - Provide the flow requirements. Not all the services require the same para= meters from the network - A way to measure those parameters e2e. - A way to "cry for help" if those parameters are below (or critically clos= e) the limits - A way to account for this. Content provider ask for QoS, and would pay fo= r that.=20 Other scenarios in which the final user pays for QoS are possible, but in g= eneral terms, i believe that Content provider is who is going to pay for th= at, not final user, which pays the "flat fee" for a best-effort internet ac= cess -Jose Javier=20 From swmike@swm.pp.se Thu Nov 11 00:00:35 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D622B3A67F3; Thu, 11 Nov 2010 00:00:35 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace: To: ...se_javier.garcia_aranda@alcatel-lucent.com>\n \n X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe8yI21skWTg; Thu, 11 Nov 2010 00:00:35 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id C31B33A67F9; Thu, 11 Nov 2010 00:00:34 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 640539C; Thu, 11 Nov 2010 09:01:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 61CDA9A; Thu, 11 Nov 2010 09:01:03 +0100 (CET) Date: Thu, 11 Nov 2010 09:01:03 +0100 (CET) From: Mikael Abrahamsson To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" In-Reply-To: <3349FECF788C984BB34176D70A51782F16877A37@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877A37@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 11 Nov 2010 08:06:59 -0800 Cc: "dispatch@ietf.org" , "pkyzivat@cisco.com" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , Mark Watson , David Singer Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 08:00:35 -0000 On Thu, 11 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: > I fully agree with Paul Kyzivat and Luis miguel, in summary: > > - the contractual obligations of operators are very "light" "up to NNN bps". In my market the consumer rights entity has worked with ISPs and gotten rid of that. It's not "between X and Y megabit/s as per this test-tool". If the ISP doesn't provide this, the customer has the right to cancel the contract. > - these "light" obligations allow a low flat fee but not allow quality services We have lower flat fees that in most markets, this is due to actual competition in the market. We also generally don't have any congestion in the ISP network, only on access. > - "new age services" needs QoS, and final user will pay for that service to the content provider > - content provider will pay network operator to provide the service to the end user with a minimum quality of experience > - Tier-1 providers will need to evolve their model from a "per-bit" schema to a "per-bit-per-QoS" one I strongly disagree. The Internet was successful because of "bill and keep". Let's not kill what has been a huge success. -- Mikael Abrahamsson email: swmike@swm.pp.se From luismi.diaz@alcatel-lucent.com Thu Nov 11 02:28:39 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA3E3A6929; Thu, 11 Nov 2010 02:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtYWPoV4Rcip; Thu, 11 Nov 2010 02:28:38 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 6A1F73A683A; Thu, 11 Nov 2010 02:28:38 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oABASu6P027123 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 11 Nov 2010 11:29:03 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 11 Nov 2010 11:29:00 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: Mikael Abrahamsson , "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" Date: Thu, 11 Nov 2010 11:28:58 +0100 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuBhhNkF+3U5kbFSBCAYGgNZwUMjAABD0cQ Message-ID: <3349FECF788C984BB34176D70A51782F16877BB6@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877A37@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Thu, 11 Nov 2010 08:06:59 -0800 Cc: "dispatch@ietf.org" , Ingemar, httpstreaming , "conex@ietf.org" , Johansson S , Kathy McEwen Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:28:39 -0000 In line....=20 Saludos, Luismi -----Mensaje original----- De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre = de Mikael Abrahamsson Enviado el: jueves, 11 de noviembre de 2010 9:01 Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; = Kathy McEwen Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP On Thu, 11 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: > I fully agree with Paul Kyzivat and Luis miguel, in summary: > > - the contractual obligations of operators are very "light" "up to NNN bp= s". In my market the consumer rights entity has worked with ISPs and gotten rid= of that. It's not "between X and Y megabit/s as per this test-tool".=20 If the ISP doesn't provide this, the customer has the right to cancel the c= ontract. [[Luismi]]: You are very lucky :). This is not the standard in most part of= the world. > - these "light" obligations allow a low flat fee but not allow quality=20 > services We have lower flat fees that in most markets, this is due to actual competi= tion in the market. We also generally don't have any congestion in the ISP = network, only on access. [[Luismi]]: Congestion on access is also a big problem. Q-HTTP provides end= -to-end checking of compliance of SLA, and if network is violating that (no= matter where) Q-HTTP will inform "someone" of the violation. After that, s= everal options are possible (for instance, ACP can recode video to a lower = bit-rate in order to fit in) and that specific flow can get higher priority= (only on access or in the whole network) to avoid congestion. We are not t= aking about HOW we can do that, first of all we need the tools to detect WH= EN we need to do the magic.... > - "new age services" needs QoS, and final user will pay for that=20 > service to the content provider > - content provider will pay network operator to provide the service to=20 > the end user with a minimum quality of experience > - Tier-1 providers will need to evolve their model from a "per-bit"=20 > schema to a "per-bit-per-QoS" one I strongly disagree. The Internet was successful because of "bill and keep"= . Let's not kill what has been a huge success. [[Luismi]]: We are not killing, we are evolving. Bill and keep was nice whe= n network usage was fair, since the only services available where much alik= e. Today, comparing emailing or web surfing with video on demand or online = gaming (and beyond, with virtualized services) is not fair anymore, so we n= eed to evolve Internet to a non-fair world. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From toby@moncaster.com Thu Nov 11 02:52:23 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C20C23A69E5; Thu, 11 Nov 2010 02:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lj3rxQKXCQg4; Thu, 11 Nov 2010 02:52:23 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by core3.amsl.com (Postfix) with ESMTP id A57D13A69E0; Thu, 11 Nov 2010 02:52:22 -0800 (PST) Received: from TobysHP (host86-149-152-36.range86-149.btcentralplus.com [86.149.152.36]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MbcUz-1OzeqD0ECb-00J3Al; Thu, 11 Nov 2010 11:52:42 +0100 From: "Toby Moncaster" To: "'Mikael Abrahamsson'" , "'Mike Hammer \(hmmr\)'" References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> In-Reply-To: Date: Thu, 11 Nov 2010 10:52:40 -0000 Message-ID: <000e01cb818e$9143a620$b3caf260$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcuBI9BggzgdP3kOSEmXznmmeCzObQAafROA Content-Language: en-gb X-Provags-ID: V02:K0:waOPBejaS5FKNMxd5FZVbww8oZ2B6R4AhAwaR3PmCMD hjvJrsxRyizoho82gA6vuE8TkM6cZxPpS7X8zaagi70B3R1IO5 z4mFfwT5LZiV6t8UtosrOBKrJe1joJW/AKKWiiVolbWRgU5x5X 4J46UGPwcziI9E2RE/0F/ZAYNH3glIihu1jk7kOLh7nYYm8xGN FDvRtACyPFZzNgU7efOIqDfZ3k6SkPo3qvtoSnh+bc= X-Mailman-Approved-At: Thu, 11 Nov 2010 08:06:59 -0800 Cc: dispatch@ietf.org, 'httpstreaming' , conex@ietf.org, 'Ingemar Johansson S' , 'Kathy McEwen' , "'GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)'" , 'Mark Watson' , 'David Singer' Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:52:23 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mikael Abrahamsson > Sent: 10 November 2010 22:08 > To: Mike Hammer (hmmr) > Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson > S; Kathy McEwen; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER); Mark Watson; > David Singer > Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP > > On Wed, 10 Nov 2010, Mike Hammer (hmmr) wrote: > > > 3) The people that build and operate the networks will double > > (quadruple?) their investments for no additional return out of the > > goodness of their hearts. > > No, they're going to do it because if they don't give the customers > what > they promised, their customers are going to leave. And what about if the customer signed up to a 12 months contract? >This is if there is > a > functional market and customers actually have a choice of providers. I > realise this is not the case in parts of the world, but that doesn't > mean > we should solve that by technical means, that's a political and > regulatory > problem, it doesn't have any technical solution. It is really hard to ignore the lack of proper competition. In the ideal world there would be a perfect market, a large selection of providers, no artificial barriers to changing provider and all users would behave in a perfect rational economic manner. Then price would be driven down towards cost and providers would have to invest in upgrade capacity. > > Let's not forget that if you're congesting your core and distribution, > you're not delivering what your customers have purchased. Period. But let's also not forget that TCP is designed to fill available BW, and versions such as CUBIC are getting pretty good at that. Given the rapid increase in access speed, the required level of over-provisioning in the core is going to become ridiculous. > > Everything else is just smoke and mirrors. > > Congestion is acceptable on the customer access, it's not acceptable in > the core. That means that any flows/pakets that should yield, are > within a > single customer domain, and thus in the customers own interest. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From hmmr@cisco.com Thu Nov 11 06:50:18 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD923A694E; Thu, 11 Nov 2010 06:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8CS-WpS8hE4; Thu, 11 Nov 2010 06:50:15 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id ECE1C3A683F; Thu, 11 Nov 2010 06:50:14 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGaR20ytJV2a/2dsb2JhbACiRXGlE5tVhUoEhFpViDo X-IronPort-AV: E=Sophos;i="4.59,183,1288569600"; d="scan'208";a="181027737" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2010 14:50:43 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oABEohTD027003; Thu, 11 Nov 2010 14:50:43 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 08:50:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 08:50:41 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] [dispatch] [httpstreaming] Q-HTTP Thread-Index: AcuBI+dkr0pBqGOQQEOJDZRUQMtQPQAivhGw References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> From: "Mike Hammer (hmmr)" To: "Mikael Abrahamsson" X-OriginalArrivalTime: 11 Nov 2010 14:50:43.0781 (UTC) FILETIME=[D11D4F50:01CB81AF] X-Mailman-Approved-At: Thu, 11 Nov 2010 08:06:59 -0800 Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Ingemar Johansson S , Kathy McEwen , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" , Mark Watson , David Singer Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 14:50:18 -0000 Mikael, So, you are assuming that the alternative provider is not subject to the same economic constraints as the provider you are jumping from? If that were such an easy thing to do, you would see many more players on the field, and fewer commentators in the stands. Agree, that the core should not be getting congested, but this problem gets worse progressively as you approach the customer edge. And the costs to overprovision the edge go up correspondingly. The last mile is the most expensive. Mike -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Wednesday, November 10, 2010 5:08 PM To: Mike Hammer (hmmr) Cc: David Singer; dispatch@ietf.org; Kathy McEwen; httpstreaming; conex@ietf.org; Ingemar Johansson S; Mark Watson; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP On Wed, 10 Nov 2010, Mike Hammer (hmmr) wrote: > 3) The people that build and operate the networks will double=20 > (quadruple?) their investments for no additional return out of the=20 > goodness of their hearts. No, they're going to do it because if they don't give the customers what they promised, their customers are going to leave. This is if there is a functional market and customers actually have a choice of providers. I=20 realise this is not the case in parts of the world, but that doesn't mean=20 we should solve that by technical means, that's a political and regulatory=20 problem, it doesn't have any technical solution. Let's not forget that if you're congesting your core and distribution,=20 you're not delivering what your customers have purchased. Period. Everything else is just smoke and mirrors. Congestion is acceptable on the customer access, it's not acceptable in=20 the core. That means that any flows/pakets that should yield, are within a=20 single customer domain, and thus in the customers own interest. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Nov 11 09:15:03 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C578F3A6A7C; Thu, 11 Nov 2010 09:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.566 X-Spam-Level: X-Spam-Status: No, score=-3.566 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELVhgI+sPs5G; Thu, 11 Nov 2010 09:15:02 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 35E783A6A7F; Thu, 11 Nov 2010 09:15:02 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 34FE69C; Thu, 11 Nov 2010 18:15:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3368B9A; Thu, 11 Nov 2010 18:15:30 +0100 (CET) Date: Thu, 11 Nov 2010 18:15:30 +0100 (CET) From: Mikael Abrahamsson To: "Mike Hammer (hmmr)" In-Reply-To: Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Ingemar Johansson S , Kathy McEwen , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" , Mark Watson , David Singer Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 17:15:03 -0000 On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote: > I think the crux of our disagreement here is the difference between what > it takes to be an ISP and what it takes to be an access provider. The > economics are different. Apples and oranges. Saying it works for > oranges means it makes sense for apples is a non-sequitor. For me an ISP is one who runs active equipment, L2 and up. Sometimes ISPs own L1 as well. What do you mean by it? > > It is nice that you have a regulated monopoly of L1 in your market, but It's not a monopoly. Well, the copper is mostly, but the fiber isn't. > However, comparing blocking (dial-tone means nothing, busy signal does) > of QoS guaranteed telephone links with non-QoS based congestion is > self-contradictory. You are in essence saying that on the one hand > providers should not have the tools to provide QoS guarantees and on the > other hand slapping them for not being able to provide a QoS guarantee. > Now how fair is that? I don't want QoS guarantees, I want *all* my packets delivered, expediently, regardless if my neighbour is filling up his pipe or not. I have paid for it, and I want it DELIVERED. The postal office doesn't get to choose which of my letters it's ok to delay or throw away, they should just deliver them. Same with my ISP. > I would not be so quick to deride the advertizing as false as not very > clear, but I do think there could be better education of the public. > (Have you never tried to explain this to a non-techie and watched their > eyes glaze over?) That's why the IETF should work on tools to show this to people, not give ISPs tools to screw their customers. > As for treating traffic equally, you apparently don't care much about > real-time interactive applications. That is your choice. But, please > don't impose that on everyone. I am fine with packet prioritization within my access line. I have AQM on my own access line, because it makes my access line perform better for my packet mix (prioritizes my VoIP and ssh before my data heavy TCP sessions). The problem I'm having here is that most talk is not about how to make the customers access line behave better for the customer, it's to have certain customers traffic be lower prioritized in the distribution and core, so ISPs can oversubscribe more without customers being able to notice too much. I resent that. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Nov 11 09:52:40 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E8E3A68A0; Thu, 11 Nov 2010 09:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz1TUbCWTAHH; Thu, 11 Nov 2010 09:52:39 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id C13B43A67B2; Thu, 11 Nov 2010 09:52:38 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1ACF19C; Thu, 11 Nov 2010 18:53:07 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 187DC9A; Thu, 11 Nov 2010 18:53:07 +0100 (CET) Date: Thu, 11 Nov 2010 18:53:07 +0100 (CET) From: Mikael Abrahamsson To: David Singer In-Reply-To: <4EA88DB4-93EC-4094-B51F-519BEDF19CCB@apple.com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <4EA88DB4-93EC-4094-B51F-519BEDF19CCB@apple.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Ingemar Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" , Mark Watson Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 17:52:40 -0000 On Thu, 11 Nov 2010, David Singer wrote: > It's interesting you say this in the context of real-time media, because > I believe a network can give time guarantees ("any packet I deliver on > this will be delivered within x ms") or delivery guarantees ("all > packets will eventually be delivered") but it's hard (impossible, maybe) > to do both. Are we talking 100.000% or 99.5% ? With cheap residential broadband, I want the norm to be that the ISP is not congesting their core/distribution. I don't want formal guarantees, I just want the normal mode to be that I can use my full access bandwidth, regardless of what application I'm running. With flash events, both telephony and packet networks can't handle peak load, but this doesn't happen every day, it's "few times per year" events. > Personally, I want my fair share of the shared 'roads' no matter how > many others are sharing them, and I expect the 'last mile' personal link > to have (at least) the capacity that was sold to me. And what is "fair"? I want my access link to be the limiting factor, not my ISP distribution/core/peering links. I was sold X megabit/s "Internet Access". I want that. I don't want "X megabit/s Internet Access unless it's that time of day when most people want to use the Internet, then you get much less but we won't state how much less, and oh by the way, you'll get different amount depending on what L3/L4 information you provide to us in your packets". Let's work on empowering the users so they can understand when their internet supplier is not giving them what they paid for. The users need tools, the ISP doesn't. The ISP can look at their mrtg graphs showing octets in and out, and if the 5 minute average utilization of their link is over ~75-85% or so, they're most likely not doing their job right. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Nov 11 10:55:39 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4A13A68A0; Thu, 11 Nov 2010 10:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqXT51k-dkbr; Thu, 11 Nov 2010 10:55:38 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 673863A67E6; Thu, 11 Nov 2010 10:55:38 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 59D3B9C; Thu, 11 Nov 2010 19:56:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 56BA59A; Thu, 11 Nov 2010 19:56:05 +0100 (CET) Date: Thu, 11 Nov 2010 19:56:05 +0100 (CET) From: Mikael Abrahamsson To: Kathy McEwen In-Reply-To: <001801cb81c9$9833c3d0$c89b4b70$@iridescentnetworks.com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <001801cb81c9$9833c3d0$c89b4b70$@iridescentnetworks.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: dispatch@ietf.org, 'httpstreaming' , conex@ietf.org, 'Ingemar Johansson S' , 'Mark Watson' , "'Mike Hammer \(hmmr\)'" , "'GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)'" , 'David Singer' Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 18:55:39 -0000 On Thu, 11 Nov 2010, Kathy McEwen wrote: > deploying additional capacity at the problem indefinitely. Policy management > is emerging as a potential tool to get more capacity out of installed > networks. Network policies are rules that are defined by the service How would policy management get more *capacity* out of installed networks? The only thing it can do is to perhaps increase the customer interactive experience of the network, but it doesn't increase capacity. No matter how much you squeeze a dry stone, it's still dry. A network that is full is full, regardless how you prioritize traffic. Also, I don't agree at all with the world reality the text describes. it might the writers reality, but it's not mine. I'd rather build out more capacity with cheap fast simple equipment that moves packets without much intelligence, than to have more expensive complicated equipment that is slower but has more intelligence to "optimize" things. 10GE pricing is dropping each year, we have 100G(E) around the corner, networks can be built out, we have the technology. Best effort is fine if ISPs actually make it *best* effort, and not mediocre or half-baked effort. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Nov 11 11:01:14 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD4D3A67E6; Thu, 11 Nov 2010 11:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5jNgH0QHr-A; Thu, 11 Nov 2010 11:01:13 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 4E5DD3A69C2; Thu, 11 Nov 2010 11:01:13 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 37F499C; Thu, 11 Nov 2010 20:01:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3623B9A; Thu, 11 Nov 2010 20:01:43 +0100 (CET) Date: Thu, 11 Nov 2010 20:01:43 +0100 (CET) From: Mikael Abrahamsson To: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" In-Reply-To: <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 19:01:14 -0000 On Thu, 11 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote: > Just a different approach. Think in a traffic jam. I know it would be > nice to live in a wonderful world with no jams, but they happen. Know > compare you, going back home from work, and an ambulance with someone > dying inside. Everybody gets away to let ambulance drive first. And > that's OK. When there is a traffic jam due to an accident it's ok. Where there is LA style traffic jams 12 hours of the day, that's not ok. > Now think on Internet. You are playing a Real-Time game and your > neighbours are just downloading files. They can afford some amount of > traffic loss (+delay/jitter) since TCP retransmisions will do the trick > (just will take a little longer to get the job done) while you cannot > afford losing (+delaying/jitterin) your traffic because if it happens, > your opponent will blow you away from the arena. That's the point, all > traffic flows are NOT the same and need different SLAs. It would help the customer to get different treatment of his/her flows on the access. It would help the ISP and not the customer to do the same in the distribution/core. Who do we want to help? Is it the end user or is it the ISP? In the discussions in CONEX I mostly see people wanting to help the ISP, not the end user. > - Enables network operators to generate more revenue for > "over-requirements". I dont think real-time was in mind whe Internet was > created and we need to provide ISPs with new tools like this. "over-requirement" as in "I want to actually get what you promised to deliver to me"? I don't buy it. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Thu Nov 11 12:43:57 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A763A682F; Thu, 11 Nov 2010 12:43:57 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace: To: ...se_javier.garcia_aranda@alcatel-lucent.com>\n \n X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMQFihLUkJ-a; Thu, 11 Nov 2010 12:43:56 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 6ABC33A6852; Thu, 11 Nov 2010 12:43:54 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 3EC719F; Thu, 11 Nov 2010 21:44:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3C4EA9A; Thu, 11 Nov 2010 21:44:24 +0100 (CET) Date: Thu, 11 Nov 2010 21:44:24 +0100 (CET) From: Mikael Abrahamsson To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" In-Reply-To: <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 20:43:57 -0000 On Thu, 11 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: > Service providers are worried about ARPU. It is decreasing becasue the > "exaflood" phenomenon. The exponential traffic can not be sustained by > the network, with incremental increases in bandwidth. I don't get it. Are you saying that because there is more traffic, the user is paying less money per month? Yes, profit per customer might be down, but why should traffic volume decrease revenue? > These ISP capabilities can be priced to developers/content providers, increasing > ISP revenues. Capabilities such as location, presence, billing, security, QoS.... I agree that an ISP can be a micropayment provider and also provice some location information. > One of the most important is QoS. If developers can not find profitable > business Models, innovation is compromised. QoS means a mix of traffic > engineering + priorization + etc Packet prioritization is only of value when the network is full. QoS is only of interest when BE works badly. > Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP) to enable virtualization of games > (like www.onlive.com, but using the network instead locating servers at last mille) I don't get this either. You can't play an FPS with tens of milliseconds of network delay, so you need to locate servers close to the customers to keep latency low, plus you also don't want the access latency to eat up your latency budget so ADSL and cable goes out the window anyway, the only thing left is the sub-millisecond latency of ETTH. Btw, I think Q-HTTP is a horrible idea. It seems require a lot of state in the network. State is expensive. What happened to KISS principle? -- Mikael Abrahamsson email: swmike@swm.pp.se From toby@moncaster.com Thu Nov 11 12:44:07 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E5053A6A26; Thu, 11 Nov 2010 12:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl7EmP2ipMbf; Thu, 11 Nov 2010 12:44:06 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 27F663A682F; Thu, 11 Nov 2010 12:44:06 -0800 (PST) Received: from TobysHP (host86-149-152-36.range86-149.btcentralplus.com [86.149.152.36]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MAidD-1PO73I2d6h-00Bl72; Thu, 11 Nov 2010 21:44:36 +0100 From: "Toby Moncaster" To: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Date: Thu, 11 Nov 2010 20:44:36 -0000 Message-ID: <002a01cb81e1$40e58740$c2b095c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcuB0uVHZzrj+JIgQaK7yQuY6NMMfQADQk1w Content-Language: en-gb X-Provags-ID: V02:K0:Q/XRwnfTwdrg9W3uRv6B2Qnrrnxq4aBlrW1yTxkGj9f zKNLM5jp+LyXlrho6ypJW2kQCvlZgn0MFqv2iiz1ToJEDjl2ba O9qMcHxicfe71thO0/SL6xLjosIXVB344wpEr7vF9aP6nOSbzh Gc7yci/QmUiQKBC/0j4bVuB/wVd9cT2o5EVr8g0wKL3C+ttx5C MCwrqHKjO61+uCfPz5MuZBormO4wxuucCH07YgUGJ8= Cc: 'httpstreaming' , dispatch@ietf.org Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 20:44:07 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mikael Abrahamsson > Sent: 11 November 2010 19:02 > To: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) > Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson > S; Kathy McEwen; Mike Hammer (hmmr); GARCIA ARANDA, JOSE JAVIER (JOSE > JAVIER) > Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP > > > > - Enables network operators to generate more revenue for > > "over-requirements". I dont think real-time was in mind whe Internet > was > > created and we need to provide ISPs with new tools like this. > > "over-requirement" as in "I want to actually get what you promised to > deliver to me"? > > I don't buy it. Mikael - I think you already put your finger on the problem when you pointed out that in your country ISPs are obliged to only promise customers what they can reasonably deliver. In most of the world ISPs are still marketing "Up to 8 Mbps" or "Up to 20Mbps" for services that at peak, for ~10% of customers can manage ~6.5Mbps and 18Mbps respectively, with most customers getting half that, and where the backhaul capacity is 10s of kbps per user (contention ratios of ~100 to 1). What has gone wrong for ISP business models is that the world has changed, with streaming and interactive services overtaking bulk transfer and web browsing. ConEx may at times appear to be operator centric, but in many places it is the customers that are suffering because ISPs are forced to use pretty crude mechanisms to try and control the small percentage of heavy users. Clearly everyone must benefit if background bulk data transfers move to something like LEDBAT? But currently the operators treat that just the same as any other P2P traffic so no-one benefits. There is also the issue of fair allocation of upgrades. Obviously if an ISP spends a lot of money on increasing their backhaul then this money has to come from the customers. However as things stand the 20% of customers grabbing 80% of the network will also grab 80% of this increased capacity, so they are being even more heavily cross-subsidised. Clearly cross-subsidy is always going to happen to an extent so long as you have flat fees for access (even if you put in tiered fees, there is still cross-subsidy). But this should not be excessive else customers suffer. Toby > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Thu Nov 11 12:57:10 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC283A6993; Thu, 11 Nov 2010 12:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZFc6biwVIKG; Thu, 11 Nov 2010 12:57:09 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 5B6853A697D; Thu, 11 Nov 2010 12:57:09 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8B98D9C; Thu, 11 Nov 2010 21:57:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 879F09A; Thu, 11 Nov 2010 21:57:39 +0100 (CET) Date: Thu, 11 Nov 2010 21:57:39 +0100 (CET) From: Mikael Abrahamsson To: Toby Moncaster In-Reply-To: <002a01cb81e1$40e58740$c2b095c0$@com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <002a01cb81e1$40e58740$c2b095c0$@com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 'httpstreaming' , dispatch@ietf.org, conex@ietf.org Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 20:57:10 -0000 On Thu, 11 Nov 2010, Toby Moncaster wrote: > What has gone wrong for ISP business models is that the world has > changed, with streaming and interactive services overtaking bulk > transfer and web browsing. ConEx may at times appear to be operator > centric, but in many places it is the customers that are suffering > because ISPs are forced to use pretty crude mechanisms to try and > control the small percentage of heavy users. Clearly everyone must > benefit if background bulk data transfers move to something like LEDBAT? No, it's only the ISP that benefits. How do you move users to LEDBAT, what's the incentive for any user to move their traffic there? To give them an incentive, you must get off the flat fee model and start to cap monthly traffic that is not LEDBAT. So if you're getting off the flat fee model, why not start charging users per usage or have a monthly cap with tokens to raise the cap or buy additional "credits"? It's non-discrimatory, and it's completely transparent as to what is going on. No secret in-the-black-box mistreatment or prioritization based on L4 information. > There is also the issue of fair allocation of upgrades. Obviously if an > ISP spends a lot of money on increasing their backhaul then this money > has to come from the customers. However as things stand the 20% of > customers grabbing 80% of the network will also grab 80% of this > increased capacity, so they are being even more heavily > cross-subsidised. Clearly cross-subsidy is always going to happen to an > extent so long as you have flat fees for access (even if you put in > tiered fees, there is still cross-subsidy). But this should not be > excessive else customers suffer. With global transit prices in the few dollars per megabit/month, the actual bandwidth cost per user even if they averaged 1 megabit/s/user at peak, is still not a major cost for the service which usually is in the several tens of dollars per month. I don't buy any of the arguments I've seen in the discussion, they're not new, and they're not technical or economical, they're purely political and regulatory when you boil it down to the actual reasons for how things are what they are. -- Mikael Abrahamsson email: swmike@swm.pp.se From ingemar.s.johansson@ericsson.com Thu Nov 11 17:29:05 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C49A3A68B6 for ; Thu, 11 Nov 2010 17:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OymaeJIQ7TTG for ; Thu, 11 Nov 2010 17:29:03 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5BBD03A67EE for ; Thu, 11 Nov 2010 17:29:02 -0800 (PST) X-AuditID: c1b4fb39-b7b54ae000003464-27-4cdc987cd200 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DC.91.13412.C789CDC4; Fri, 12 Nov 2010 02:29:32 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 12 Nov 2010 02:29:32 +0100 From: Ingemar Johansson S To: "conex@ietf.org" Date: Fri, 12 Nov 2010 02:29:08 +0100 Thread-Topic: Abstract marking and encoding in IPv6 Thread-Index: AcuCCQDMT/eR+KmUQ+GE4yOvlcAkyA== Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 01:29:06 -0000 Hi Given yesterdays presentation on the abtract encoding mechanism and the IPv= 6 encoding options my findings are: + Encoding in IPv6: To me it seems like the only way to make ConEx commerci= ally attactive is to use some of the bits from the flow label field. It was= to me pretty clear that extension headers (including the hop-by-hop option= s header) are not very useful in this context and it was also explained (Ri= ch Woundy) that the latter are not even useful for experimentation (my inte= rpretation). So what is required here is to convince 6man (and others) that= ConEx is a good use case for N bits in the flow label field reserved for C= onEx. + Encoding of abstract mechanism: Now that I (believe I) understand the gre= en marking (and the necessity of it) it is to me quite obvious that 5 codep= oints are needed, thus 3 bits are needed, this leaves 1 unused codepoint wa= iting for an interesting use case... =20 /Ingemar =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 INGEMAR JOHANSSON M.Sc.=20 Senior Research Engineer=20 Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com=20 Visit http://labs.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 From carlberg@g11.org.uk Thu Nov 11 18:19:30 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C07BE3A6901 for ; Thu, 11 Nov 2010 18:19:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqima3yINPTj for ; Thu, 11 Nov 2010 18:19:30 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id D73B33A6860 for ; Thu, 11 Nov 2010 18:19:29 -0800 (PST) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:51649 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1PGjF7-0005XH-8P; Fri, 12 Nov 2010 02:19:57 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: Date: Thu, 11 Nov 2010 21:19:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <944971A7-1B75-47F1-BA1D-393644CF1954@g11.org.uk> References: To: Ingemar Johansson S X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 02:19:30 -0000 Ingemar, > + Encoding in IPv6: To me it seems like the only way to make ConEx = commercially attactive is to use some of the bits from the flow label = field. It was to me pretty clear that extension headers (including the = hop-by-hop options header) are not very useful in this context and it = was also explained (Rich Woundy) that the latter are not even useful for = experimentation (my interpretation). So what is required here is to = convince 6man (and others) that ConEx is a good use case for N bits in = the flow label field reserved for ConEx. given the constraints that CONEX is only producing experimental work, my = feeling is that the odds are way against having 4 bits taken away from = the flow label field for CONEX. It would probably be best if the = author/chairs could get the pulse of such a proposal from the 6man = chairs, asap. and from that, one could decide which direction to = pursue. -ken From marcelo@it.uc3m.es Thu Nov 11 18:22:55 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39AFC3A6860 for ; Thu, 11 Nov 2010 18:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cge939Dy27Sv for ; Thu, 11 Nov 2010 18:22:51 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 435F73A67F7 for ; Thu, 11 Nov 2010 18:22:51 -0800 (PST) X-uc3m-safe: yes Received: from dhcp-7618.meeting.ietf.org (dhcp-7618.meeting.ietf.org [130.129.118.24]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id EC835704B4A for ; Fri, 12 Nov 2010 03:23:20 +0100 (CET) Message-ID: <4CDCA513.6030808@it.uc3m.es> Date: Fri, 12 Nov 2010 03:23:15 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: conex@ietf.org References: <944971A7-1B75-47F1-BA1D-393644CF1954@g11.org.uk> In-Reply-To: <944971A7-1B75-47F1-BA1D-393644CF1954@g11.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17760.003 Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 02:22:55 -0000 I would pose then the question: if you could only get 1 bit, what could you do? Regards, marcelo El 12/11/10 3:19, ken carlberg escribió: > Ingemar, > >> + Encoding in IPv6: To me it seems like the only way to make ConEx commercially attactive is to use some of the bits from the flow label field. It was to me pretty clear that extension headers (including the hop-by-hop options header) are not very useful in this context and it was also explained (Rich Woundy) that the latter are not even useful for experimentation (my interpretation). So what is required here is to convince 6man (and others) that ConEx is a good use case for N bits in the flow label field reserved for ConEx. > given the constraints that CONEX is only producing experimental work, my feeling is that the odds are way against having 4 bits taken away from the flow label field for CONEX. It would probably be best if the author/chairs could get the pulse of such a proposal from the 6man chairs, asap. and from that, one could decide which direction to pursue. > > -ken > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > From richard_woundy@cable.comcast.com Thu Nov 11 19:30:23 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6417D28C15F for ; Thu, 11 Nov 2010 19:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8SF-Jz4HIA9 for ; Thu, 11 Nov 2010 19:30:18 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 762B728C0E8 for ; Thu, 11 Nov 2010 19:30:18 -0800 (PST) Received: from ([24.40.55.41]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.104739478; Thu, 11 Nov 2010 22:30:46 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0255.000; Thu, 11 Nov 2010 22:30:45 -0500 From: "Woundy, Richard" To: Ingemar Johansson S , "conex@ietf.org" Thread-Topic: Abstract marking and encoding in IPv6 Thread-Index: AcuCCQDMT/eR+KmUQ+GE4yOvlcAkyAAD0XuQ Date: Fri, 12 Nov 2010 03:30:44 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1030ECD@PACDCEXMB05.cable.comcast.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.248.106] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 03:30:23 -0000 > It was to me pretty clear that extension headers (including the hop-by-ho= p options header) are not very useful in this context and it was also expla= ined (Rich Woundy) that the latter are not even useful for experimentation = (my interpretation). This might be a good time to clarify my comments. First, the context of my comments (not useful for experimentation) was focu= sed on experiments across the Internet, not on lab experiments where I am s= ure any approach will work. Second, some folks behind me at the mike during the Conex session asserted = that the "slow path" through some commercial routers could be 1000 times sl= ower than the usual "fast path", maybe even 100,000 times slower. Personall= y I didn't quote a performance difference but I have seen huge discrepancie= s between the slow and fast paths on some commercial routers. This affects = the capacity available for the experimental traffic. Third, there was something I forgot to mention at the mike, which is a big = deal. Oftentimes, forwarding traffic through the router's slow path implies= sending packets to the main router CPU for processing. The main router CPU= is also performing other key activities, particularly exchanging routing p= rotocol messages, updating the RIB and FIB, supporting network management q= ueries, generating statistics, etc. So if there is a significant amount of = experimental traffic, it *might* impact the functioning of the router itsel= f, depending on the relative priority of the experimental traffic and each = of these activities. -- Rich -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of I= ngemar Johansson S Sent: Friday, November 12, 2010 9:29 AM To: conex@ietf.org Subject: [conex] Abstract marking and encoding in IPv6 Hi Given yesterdays presentation on the abtract encoding mechanism and the IPv= 6 encoding options my findings are: + Encoding in IPv6: To me it seems like the only way to make ConEx commerci= ally attactive is to use some of the bits from the flow label field. It was= to me pretty clear that extension headers (including the hop-by-hop option= s header) are not very useful in this context and it was also explained (Ri= ch Woundy) that the latter are not even useful for experimentation (my inte= rpretation). So what is required here is to convince 6man (and others) that= ConEx is a good use case for N bits in the flow label field reserved for C= onEx. + Encoding of abstract mechanism: Now that I (believe I) understand the gre= en marking (and the necessity of it) it is to me quite obvious that 5 codep= oints are needed, thus 3 bits are needed, this leaves 1 unused codepoint wa= iting for an interesting use case... =20 /Ingemar =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 INGEMAR JOHANSSON M.Sc.=20 Senior Research Engineer=20 Ericsson AB Multimedia Technologies Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com=20 Visit http://labs.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 _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Thu Nov 11 19:54:47 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF9A3A6917; Thu, 11 Nov 2010 19:54:47 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Improper folded header field made up entirely of whitespace: To: ...se_javier.garcia_aranda@alcatel-lucent.com>\n \n X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDSHdo6mgd98; Thu, 11 Nov 2010 19:54:46 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id EC0103A67D0; Thu, 11 Nov 2010 19:54:45 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B871E9C; Fri, 12 Nov 2010 04:55:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B5D279A; Fri, 12 Nov 2010 04:55:15 +0100 (CET) Date: Fri, 12 Nov 2010 04:55:15 +0100 (CET) From: Mikael Abrahamsson To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" In-Reply-To: <3349FECF788C984BB34176D70A51782F16877F9C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F9C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 03:54:47 -0000 On Fri, 12 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: > Since several years ago, ARPU is frozen and even it has been reduced a > little. But traffic grows each year, and as you say, profit goes down. I > have check ARPU from Spanish operators and they are reduced Yes, but the ARPU doesn't go down because traffic increases, it goes down due to competition and increased market penetration. > Each year, a little, but the investments in network must increase to support the traffic growing. Yes. That means profit is down. > Priorization reduce queue times, with network full or not. For example, > IPTV services offered by operators uses priorization. But do not reduce > QoS to priorization. There are more operations involved in QoS. Prioritization on the access line is good. Prioritization done because you want to flatline your distribution/core at peak times is bad. > online gaming, in which latencies sometimes makes not possible to play > against users located in other countries, and in that case constraints > are not very restricted , however without QoS, they are impossible to > achieve today. With hot potato routing, high latency to other countries depend on either bad network design or physical constraints when it comes to speed of light in fiber. QoS can't solve neither. > Hard-core gamers have a high willingness to pay for virtualized games, > but today content providers can not offer virtualized games because > there is not QoS on demand in Internet. Hard-core gamers won't accept 50ms of keypress/action delay. > Have you read the draft? I promise you that Q-HTTP perhaps has an > horrible name, but it is KISS, for sure. It is application level, and > Q-HTTP alerts can be used for a lot of possibilities from adapting > mechanisms ( reduce bitrate or functionalities) to priorization , > reservation, or whatever. It is not said what to do with the alerts in > the draft. It is only a powerful tool. I started reading the draft but fell ill after reading it a while. It seems to do a lot of testing. We don't need more testing, we need performance information for existing traffic, not more test traffic. And yes, Q-HTTP is HORRRIBLE name. And no, it's not KISS. Just the size of the draft and the number of sections says it's not KISS. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Fri Nov 12 01:40:22 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1FBE3A6B16; Fri, 12 Nov 2010 01:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-L85U0nSg9y; Fri, 12 Nov 2010 01:40:22 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id ACDEF3A6B12; Fri, 12 Nov 2010 01:40:20 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DA02B9C; Fri, 12 Nov 2010 10:40:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D87529A; Fri, 12 Nov 2010 10:40:51 +0100 (CET) Date: Fri, 12 Nov 2010 10:40:51 +0100 (CET) From: Mikael Abrahamsson To: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" In-Reply-To: <3349FECF788C984BB34176D70A51782F168780B4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F9C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168780B4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , httpstreaming , Kathy McEwen , "conex@ietf.org" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 09:40:23 -0000 On Fri, 12 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote: > And testing is just a MUST. We need to know what is going wrong for THAT > flow, because not all the applications/flows have the same requirements. No, testing is not a MUST. If you need to know what is going on with THAT flow, then you make sure you have insight into what THAT flow is experiencing, you don't inject more traffic. Your time would be much better spent developing an API into the client IP stack to give insight into what TCP/RTP is actually experiencing (timestamping used to deduce jitter etc) than to create *more* traffic when facing adverse conditions. And since you say "flow". I run *routers*. Routers act on a per-packet basis. They don't act on flows. They act on precedence/dscp values in each packet and queue according to policy if it exists, otherwise it does FIFO. I hate testing. I'd much rather have insight into real traffic than creating test traffic. Test traffic can look fine where the real traffic is not. It's just amazing that we're sitting here some 30 years after TCP was invented and still have no tools for users to see what TCP is doing, short of dumping the packets on their interface and running wireshark on it. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Fri Nov 12 01:42:34 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C45A3A6B1A; Fri, 12 Nov 2010 01:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0v2Ff-KYck+g; Fri, 12 Nov 2010 01:42:33 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 380B93A6B11; Fri, 12 Nov 2010 01:42:33 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DCA149C; Fri, 12 Nov 2010 10:43:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D98A09A; Fri, 12 Nov 2010 10:43:04 +0100 (CET) Date: Fri, 12 Nov 2010 10:43:04 +0100 (CET) From: Mikael Abrahamsson To: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" In-Reply-To: <3349FECF788C984BB34176D70A51782F1687808C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1687808C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 09:42:34 -0000 On Fri, 12 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote: > Then, why on earth ALL ISPs are using QoS in THEIR networks to guarantee > their own VoIP and Broadcast TV services to their customers??? All ISPs aren't doing this. I've worked for at least two who has VoIP services without it. Skype has no such requirement. > QoS is ALWAYS a MUST for ISPs to ensure real-time services at any > moment. Q-HTTP is trying to open up that window to other third parties. No, it's not a MUST. It's nice to have and increases network tolerance, but I've worked for ISPs that used overprovisioning and cheap equipment that just got the job done, and this was cheaper than buying the more expensive equipment that had a lot of intelligence in it. Using QoS is ONE way of doing it, it's not the only one. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Fri Nov 12 01:55:45 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C71603A69BF; Fri, 12 Nov 2010 01:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doBvVMGweA6G; Fri, 12 Nov 2010 01:55:44 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 6296E3A68EC; Fri, 12 Nov 2010 01:55:44 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1CAFE9C; Fri, 12 Nov 2010 10:56:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1A99D9A; Fri, 12 Nov 2010 10:56:16 +0100 (CET) Date: Fri, 12 Nov 2010 10:56:16 +0100 (CET) From: Mikael Abrahamsson To: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" In-Reply-To: <3349FECF788C984BB34176D70A51782F16878047@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16878047@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ingemar Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , httpstreaming , Kathy McEwen , "conex@ietf.org" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 09:55:45 -0000 On Fri, 12 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote: > [[Luismi]]: There is one only real thing we can trust in: ISP is there > because of PROFIT. If there is no profit there will be no investment at Unfortunately there is no upper bound to the amount of profit to be made, so profit doesn't mean more network investment, it just means more profit. I thought that was obvious by now? > helping ISPs to do MORE with the same money, and that will benefit > users. If the network is full, it's full. Discriminating certain applications doesn't mean you're doing more, it's just that you're doing different things with the same bw. It's not more. > With Q-HTTP we are also providing the tools to users to "audit" > what they are paying for. Users will pay extra money for superb services > (we are doing that right now when you pay a World of Warcraft or OnLive > subscription) and part of that money will end-up on the ISP. Sharing > profit between all the players is definetively a good thing IMHO. Have you seen the roaming prices for mobile data? That's what you get when you abandon the bill-and-keep model. > [[Luismi]]: The problem is that ISPs promises are just vague. Up to X > Mbps, with no delay/jitter guarantees is just fine for a lot of > applications. It is just not enough for real-time. Besides, a few > seconds congestion (for instance, a fiber goes down and all traffic > re-routes by another path that becomes 1.5 to 1 congested) will produce > a slow down in "standard" service and a complete melt-down in real-time. > THAT's what we want to protect. Real-Time application will obtain higher > priority during congestion (thus slowing down even more the standard > services) and EVERYTHING will be saved. Standard services will survive > with a period of "half-speed" and Real-Time will survive unaffected. No, the real time service will be saved by sacrificing the other services. That's not EVERYTHING. Also, I don't see why we need Q-HTTP to do this? This can be done today with existing features. The only upside I see with Q-HTTP is quality reporting, but it needs to be done in a different way. > [[Luismi]]: Then there are a lot of services that never will fly out on > Internet. Take a look on OnLive service. They provide virtualized gaming > (play XBOX games on your TV without the console, just with a small > set-top-box that receives video and sends keys pressed on the pad) by > just bypassing the network and installing PoPs just half mile away from > your home. That is not economically optimized as you can imagine thus > they are translating that into a very expensive service. Just because > network does not provide what they need. With QoS, they can offer a > centralized service, with really cheaper deployment, lower the service > fee to users (win), making more profit (win) and paying a % of that to > ISP (win). If we like win-win, you must love this win-win-win (and even > better, ISP will re-invest part of that profit on network). They can get QoS without Q-HTTP. They just need to make a deal with the ISP. Oh wait, they can't because of Net Neutrality restrictions. Also, how do you plan to handle traffic in the outgoing direction from the consumer, normally CPEs don't have AQM, so if the customer is uploading photos at the same time as someone else in the household plays this game, you're bust anyway. -- Mikael Abrahamsson email: swmike@swm.pp.se From roland.bless@kit.edu Fri Nov 12 03:47:50 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60A03A6A59 for ; Fri, 12 Nov 2010 03:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqFrNM0Ej1CK for ; Fri, 12 Nov 2010 03:47:50 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id C387D3A6A1D for ; Fri, 12 Nov 2010 03:47:49 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PGs74-000354-DM; Fri, 12 Nov 2010 12:48:20 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1PGs74-0003qI-87; Fri, 12 Nov 2010 12:48:14 +0100 Received: from vorta.tm.uka.de (roland.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2E53C2FC046; Fri, 12 Nov 2010 12:48:14 +0100 (CET) Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.uka.de (Postfix) with ESMTPS id F2ADC252; Fri, 12 Nov 2010 12:48:13 +0100 (CET) Message-ID: <4CDD297D.9030204@kit.edu> Date: Fri, 12 Nov 2010 12:48:13 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Ingemar Johansson S References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1289562500.500917000 Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 11:47:50 -0000 Hi, On 12.11.2010 02:29, Ingemar Johansson S wrote: > + Encoding in IPv6: To me it seems like the only way to make ConEx > commercially attactive is to use some of the bits from the flow label > field. It was to me pretty clear that extension headers (including > the hop-by-hop options header) are not very useful in this context > and it was also explained (Rich Woundy) that the latter are not even > useful for experimentation (my interpretation). So what is required > here is to convince 6man (and others) that ConEx is a good use case > for N bits in the flow label field reserved for ConEx. It's not totally clear to me why extension headers aren't the right approach: the main obstacle seems to be that broken implementations punt the packet to the slow path as soon as there is a hop-by-hop option present. For a CONEX supporting router you could implement that new conex h-b-h option in the fast path, and old ones should ignore the unknown option and leave the packet in the fast path. IMHO it's better to get that fixed asap since otherwise the h-b-h extension headers aren't very useful. Thus, the natural choice would be to use the foreseen IPv6 extension mechanism. Regards, Roland From rbriscoe@jungle.bt.co.uk Fri Nov 12 07:49:43 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942E33A69D1 for ; Fri, 12 Nov 2010 07:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.419 X-Spam-Level: X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo38-lVG2DQR for ; Fri, 12 Nov 2010 07:49:37 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7A7803A696A for ; Fri, 12 Nov 2010 07:49:36 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Nov 2010 15:50:07 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Nov 2010 15:50:05 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1289577005195; Fri, 12 Nov 2010 15:50:05 +0000 Received: from MUT.jungle.bt.co.uk ([10.142.81.110]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id oACFo3FI005675; Fri, 12 Nov 2010 15:50:04 GMT Message-Id: <201011121550.oACFo3FI005675@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 12 Nov 2010 15:50:05 +0000 To: "Woundy, Richard" , Ingemar Johansson S From: Bob Briscoe In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1030ECD@PACDCEXMB05.cable.c omcast.com> References: <1CA25301D2219F40B3AA37201F0EACD1030ECD@PACDCEXMB05.cable.comcast.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 12 Nov 2010 15:50:05.0886 (UTC) FILETIME=[46B525E0:01CB8281] Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 15:49:43 -0000 Rich, Ingemar, I like Marcelo's idea of an interim session on encoding (presumably by= audio). Beyond the 3 techniques in Suresh's presentation,=20 there are two other possibilities I can think of: 4) (proposed by Lars) use bits in an existing v6 hop-by-hop options header 5) use GUT 4) The idea here is that the IPv6 main header is=20 not the only header that today's v6 routers=20 already support that might offer some space. For=20 instance there might be a possibility to=20 re-purpose the IPv6 fragmentation header (I chose=20 this particularly, because we might be able to=20 repeat the same trick in the fragmentation fields=20 of the IPv4 header). There might be ideas for=20 using other existing v6 hop-by-hop headers too. 5) Here's an intro to why GUT could be a=20 principled alternative, which I recently sent=20 offlist to the authors of : >GUT was originally designed for tunnelling new=20 >transport layer protocols. But in a change=20 >between -01 and -02 we took the insight from Rob=20 >Hancock that any router with IP header extension=20 >code will know where to look, so it's=20 >unnecessary to have routers that don't know=20 >about new extensions checking through a string=20 >of extensions looking for stuff they don't have code for. > >Instead, we hid IP extension headers behind a=20 >UDP header. Packets then go through NATs,=20 >firewalls and any assorted meddleboxes and muddleboxes. > >And you don't get punted to the slow path. > >Although it doesn't look principled, it depends=20 >how you look at it - see Tng (transport next-gen). > >We still need to define the principles for how=20 >it interacts with IPsec etc. So I'm not saying=20 >it's completely thought through. But it works. There's been some conversation on GUT between us=20 since, that we ought to summarise to the ConEx list once it has finished. Bob At 03:30 12/11/2010, Woundy, Richard wrote: > > It was to me pretty clear that extension=20 > headers (including the hop-by-hop options=20 > header) are not very useful in this context and=20 > it was also explained (Rich Woundy) that the=20 > latter are not even useful for experimentation (my interpretation). > >This might be a good time to clarify my comments. > >First, the context of my comments (not useful=20 >for experimentation) was focused on experiments=20 >across the Internet, not on lab experiments=20 >where I am sure any approach will work. > >Second, some folks behind me at the mike during=20 >the Conex session asserted that the "slow path"=20 >through some commercial routers could be 1000=20 >times slower than the usual "fast path", maybe=20 >even 100,000 times slower. Personally I didn't=20 >quote a performance difference but I have seen=20 >huge discrepancies between the slow and fast=20 >paths on some commercial routers. This affects=20 >the capacity available for the experimental traffic. > >Third, there was something I forgot to mention=20 >at the mike, which is a big deal. Oftentimes,=20 >forwarding traffic through the router's slow=20 >path implies sending packets to the main router=20 >CPU for processing. The main router CPU is also=20 >performing other key activities, particularly=20 >exchanging routing protocol messages, updating=20 >the RIB and FIB, supporting network management=20 >queries, generating statistics, etc. So if there=20 >is a significant amount of experimental traffic,=20 >it *might* impact the functioning of the router=20 >itself, depending on the relative priority of=20 >the experimental traffic and each of these activities. > >-- Rich > >-----Original Message----- >From: conex-bounces@ietf.org=20 >[mailto:conex-bounces@ietf.org] On Behalf Of Ingemar Johansson S >Sent: Friday, November 12, 2010 9:29 AM >To: conex@ietf.org >Subject: [conex] Abstract marking and encoding in IPv6 > >Hi > >Given yesterdays presentation on the abtract=20 >encoding mechanism and the IPv6 encoding options my findings are: > >+ Encoding in IPv6: To me it seems like the only=20 >way to make ConEx commercially attactive is to=20 >use some of the bits from the flow label field.=20 >It was to me pretty clear that extension headers=20 >(including the hop-by-hop options header) are=20 >not very useful in this context and it was also=20 >explained (Rich Woundy) that the latter are not=20 >even useful for experimentation (my=20 >interpretation). So what is required here is to=20 >convince 6man (and others) that ConEx is a good=20 >use case for N bits in the flow label field reserved for ConEx. > >+ Encoding of abstract mechanism: Now that I=20 >(believe I) understand the green marking (and=20 >the necessity of it) it is to me quite obvious=20 >that 5 codepoints are needed, thus 3 bits are=20 >needed, this leaves 1 unused codepoint waiting=20 >for an interesting use case... > >/Ingemar > >=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 >INGEMAR JOHANSSON M.Sc. >Senior Research Engineer > >Ericsson AB >Multimedia Technologies >Labratoriegr=E4nd 11 >971 28, Lule=E5, Sweden >Phone +46-1071 43042 >SMS/MMS +46-73 078 3289 >ingemar.s.johansson@ericsson.com >www.ericsson.com >Visit http://labs.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 >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex >_______________________________________________ >conex mailing list >conex@ietf.org >https://www.ietf.org/mailman/listinfo/conex ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 From marcelo@it.uc3m.es Sat Nov 13 22:35:20 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BFE13A6A73 for ; Sat, 13 Nov 2010 22:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.413 X-Spam-Level: X-Spam-Status: No, score=-106.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQQSMMAxl5bo for ; Sat, 13 Nov 2010 22:35:11 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 6C8563A6B67 for ; Sat, 13 Nov 2010 22:35:09 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (243.30.18.95.dynamic.jazztel.es [95.18.30.243]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 1F465BD7489 for ; Sun, 14 Nov 2010 07:35:45 +0100 (CET) Message-ID: <4CDF8340.9090104@it.uc3m.es> Date: Sun, 14 Nov 2010 07:35:44 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: conex@ietf.org References: <1CA25301D2219F40B3AA37201F0EACD1030ECD@PACDCEXMB05.cable.comcast.com> <201011121550.oACFo3FI005675@bagheera.jungle.bt.co.uk> In-Reply-To: <201011121550.oACFo3FI005675@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17766.003 Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2010 06:35:20 -0000 El 12/11/10 16:50, Bob Briscoe escribió: > Rich, Ingemar, > > I like Marcelo's idea of an interim session on encoding (presumably by > audio). yes, the idea was to make a virtual interim meeting focussed in the encoding (but not limited to it) i think we could try to arrange that for the last week of january. I will talk with my co chair and ADs and come back to you on this. Regards, marcelo > > Beyond the 3 techniques in Suresh's presentation, there are two other > possibilities I can think of: > 4) (proposed by Lars) use bits in an existing v6 hop-by-hop options > header > 5) use GUT > > 4) The idea here is that the IPv6 main header is not the only header > that today's v6 routers already support that might offer some space. > For instance there might be a possibility to re-purpose the IPv6 > fragmentation header (I chose this particularly, because we might be > able to repeat the same trick in the fragmentation fields of the IPv4 > header). There might be ideas for using other existing v6 hop-by-hop > headers too. > > 5) Here's an intro to why GUT could be a principled alternative, which > I recently sent offlist to the authors of : > >> GUT was originally designed for tunnelling new transport layer >> protocols. But in a change between -01 and -02 we took the insight >> from Rob Hancock that any router with IP header extension code will >> know where to look, so it's unnecessary to have routers that don't >> know about new extensions checking through a string of extensions >> looking for stuff they don't have code for. >> >> Instead, we hid IP extension headers behind a UDP header. Packets >> then go through NATs, firewalls and any assorted meddleboxes and >> muddleboxes. >> >> And you don't get punted to the slow path. >> >> Although it doesn't look principled, it depends how you look at it - >> see Tng (transport next-gen). >> >> We still need to define the principles for how it interacts with >> IPsec etc. So I'm not saying it's completely thought through. But it >> works. > > There's been some conversation on GUT between us since, that we ought > to summarise to the ConEx list once it has finished. > > > Bob > > At 03:30 12/11/2010, Woundy, Richard wrote: >> > It was to me pretty clear that extension headers (including the >> hop-by-hop options header) are not very useful in this context and it >> was also explained (Rich Woundy) that the latter are not even useful >> for experimentation (my interpretation). >> >> This might be a good time to clarify my comments. >> >> First, the context of my comments (not useful for experimentation) >> was focused on experiments across the Internet, not on lab >> experiments where I am sure any approach will work. >> >> Second, some folks behind me at the mike during the Conex session >> asserted that the "slow path" through some commercial routers could >> be 1000 times slower than the usual "fast path", maybe even 100,000 >> times slower. Personally I didn't quote a performance difference but >> I have seen huge discrepancies between the slow and fast paths on >> some commercial routers. This affects the capacity available for the >> experimental traffic. >> >> Third, there was something I forgot to mention at the mike, which is >> a big deal. Oftentimes, forwarding traffic through the router's slow >> path implies sending packets to the main router CPU for processing. >> The main router CPU is also performing other key activities, >> particularly exchanging routing protocol messages, updating the RIB >> and FIB, supporting network management queries, generating >> statistics, etc. So if there is a significant amount of experimental >> traffic, it *might* impact the functioning of the router itself, >> depending on the relative priority of the experimental traffic and >> each of these activities. >> >> -- Rich >> >> -----Original Message----- >> From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On >> Behalf Of Ingemar Johansson S >> Sent: Friday, November 12, 2010 9:29 AM >> To: conex@ietf.org >> Subject: [conex] Abstract marking and encoding in IPv6 >> >> Hi >> >> Given yesterdays presentation on the abtract encoding mechanism and >> the IPv6 encoding options my findings are: >> >> + Encoding in IPv6: To me it seems like the only way to make ConEx >> commercially attactive is to use some of the bits from the flow label >> field. It was to me pretty clear that extension headers (including >> the hop-by-hop options header) are not very useful in this context >> and it was also explained (Rich Woundy) that the latter are not even >> useful for experimentation (my interpretation). So what is required >> here is to convince 6man (and others) that ConEx is a good use case >> for N bits in the flow label field reserved for ConEx. >> >> + Encoding of abstract mechanism: Now that I (believe I) understand >> the green marking (and the necessity of it) it is to me quite obvious >> that 5 codepoints are needed, thus 3 bits are needed, this leaves 1 >> unused codepoint waiting for an interesting use case... >> >> /Ingemar >> >> ================================= >> INGEMAR JOHANSSON M.Sc. >> Senior Research Engineer >> >> Ericsson AB >> Multimedia Technologies >> Labratoriegränd 11 >> 971 28, Luleå, Sweden >> Phone +46-1071 43042 >> SMS/MMS +46-73 078 3289 >> ingemar.s.johansson@ericsson.com >> www.ericsson.com >> Visit http://labs.ericsson.com ! >> ================================= >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > From marcelo@it.uc3m.es Sun Nov 14 00:22:48 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112053A68E9 for ; Sun, 14 Nov 2010 00:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.45 X-Spam-Level: X-Spam-Status: No, score=-106.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqar6IJeX3BK for ; Sun, 14 Nov 2010 00:22:41 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 1B4B63A6AB0 for ; Sun, 14 Nov 2010 00:22:40 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (243.30.18.95.dynamic.jazztel.es [95.18.30.243]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 030D7BF4ED5 for ; Sun, 14 Nov 2010 09:23:17 +0100 (CET) Message-ID: <4CDF9C74.7090600@it.uc3m.es> Date: Sun, 14 Nov 2010 09:23:16 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: conex@ietf.org References: <944971A7-1B75-47F1-BA1D-393644CF1954@g11.org.uk> <4CDCA513.6030808@it.uc3m.es> In-Reply-To: <4CDCA513.6030808@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17766.003 Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2010 08:22:48 -0000 fwiw, this was a serious question. I mean, in v4 afaiu, we would only get one bit and we could make it work. I would like to understand how much can we do with one bit. I don't belive we could ask for 4 bits in the flow label, and asking for 1 bit for conex seems much more reasonable to me. El 12/11/10 3:23, marcelo bagnulo braun escribió: > I would pose then the question: if you could only get 1 bit, what > could you do? > > Regards, marcelo > > > > El 12/11/10 3:19, ken carlberg escribió: >> Ingemar, >> >>> + Encoding in IPv6: To me it seems like the only way to make ConEx >>> commercially attactive is to use some of the bits from the flow >>> label field. It was to me pretty clear that extension headers >>> (including the hop-by-hop options header) are not very useful in >>> this context and it was also explained (Rich Woundy) that the latter >>> are not even useful for experimentation (my interpretation). So what >>> is required here is to convince 6man (and others) that ConEx is a >>> good use case for N bits in the flow label field reserved for ConEx. >> given the constraints that CONEX is only producing experimental work, >> my feeling is that the odds are way against having 4 bits taken away >> from the flow label field for CONEX. It would probably be best if >> the author/chairs could get the pulse of such a proposal from the >> 6man chairs, asap. and from that, one could decide which direction >> to pursue. >> >> -ken >> >> _______________________________________________ >> conex mailing list >> conex@ietf.org >> https://www.ietf.org/mailman/listinfo/conex >> > > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex > From toby@moncaster.com Sun Nov 14 07:56:11 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18733A6938 for ; Sun, 14 Nov 2010 07:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNLAFowGMq9F for ; Sun, 14 Nov 2010 07:56:05 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id F1B473A6B8C for ; Sun, 14 Nov 2010 07:56:04 -0800 (PST) Received: from TobysHP (host86-149-152-36.range86-149.btcentralplus.com [86.149.152.36]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MWxr2-1OwsQQ0rAq-00WFn1; Sun, 14 Nov 2010 16:56:42 +0100 From: "Toby Moncaster" To: "'marcelo bagnulo braun'" , References: <944971A7-1B75-47F1-BA1D-393644CF1954@g11.org.uk> <4CDCA513.6030808@it.uc3m.es> <4CDF9C74.7090600@it.uc3m.es> In-Reply-To: <4CDF9C74.7090600@it.uc3m.es> Date: Sun, 14 Nov 2010 15:56:42 -0000 Message-ID: <000301cb8414$8856e6c0$9904b440$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcuD1TdYiTldDsmHSO2LAdE63G8CugAPtvjQ Content-Language: en-gb X-Provags-ID: V02:K0:ofyDJvcQiCLmxy14KtC5kajo18v62YTRlKvmfrDvyb0 LYtFWRLz3ORsJy4L8BfAQ4Vaq8yJVd2heekpU/XLqyN6/ok/Sv wKMi/5e8OizpVWM/Y3d7GtdQDtCEjZPccrqvm4z5JLqCU7ikVv 8FZjjcpnkXaglsUt3fT/6yLx3I5LiiOZKoqRpXvbQGce7M+VqK vzbua1xtOIYq3DVCFVXLI2d0Xgrx6BP3GQpbDBZ59s= Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2010 15:56:12 -0000 This sounds a sensible suggestion. I think the aim of an interim meeting should be to address two questions: 1) What is the minimum number of (new) bits required for the ConEx = abstract mechanism in Matt's and Bob's draft? 2) What is the maximum functionality we can get with just 1 new bit? Obviously it would be really nice to think the two answers are = effectively the same (in other words 1 additional bit is enough to implement the = whole mechanism).=20 Toby > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of marcelo bagnulo braun > Sent: 14 November 2010 08:23 > To: conex@ietf.org > Subject: Re: [conex] Abstract marking and encoding in IPv6 >=20 > fwiw, this was a serious question. I mean, in v4 afaiu, we would only > get one bit and we could make it work. I would like to understand how > much can we do with one bit. I don't belive we could ask for 4 bits in > the flow label, and asking for 1 bit for conex seems much more > reasonable to me. >=20 >=20 >=20 > El 12/11/10 3:23, marcelo bagnulo braun escribi=F3: > > I would pose then the question: if you could only get 1 bit, what > > could you do? > > > > Regards, marcelo > > > > > > > > El 12/11/10 3:19, ken carlberg escribi=F3: > >> Ingemar, > >> > >>> + Encoding in IPv6: To me it seems like the only way to make ConEx > >>> commercially attactive is to use some of the bits from the flow > >>> label field. It was to me pretty clear that extension headers > >>> (including the hop-by-hop options header) are not very useful in > >>> this context and it was also explained (Rich Woundy) that the > latter > >>> are not even useful for experimentation (my interpretation). So > what > >>> is required here is to convince 6man (and others) that ConEx is a > >>> good use case for N bits in the flow label field reserved for > ConEx. > >> given the constraints that CONEX is only producing experimental > work, > >> my feeling is that the odds are way against having 4 bits taken = away > >> from the flow label field for CONEX. It would probably be best if > >> the author/chairs could get the pulse of such a proposal from the > >> 6man chairs, asap. and from that, one could decide which direction > >> to pursue. > >> > >> -ken > >> > >> _______________________________________________ > >> conex mailing list > >> conex@ietf.org > >> https://www.ietf.org/mailman/listinfo/conex > >> > > > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex > > >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From prvs=59356E9B4C=Kevin.Mason@telecom.co.nz Sun Nov 14 20:23:50 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38C53A63CB; Sun, 14 Nov 2010 20:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VBMWmguSLcR; Sun, 14 Nov 2010 20:23:43 -0800 (PST) Received: from mgate1.telecom.co.nz (envoy-out.telecom.co.nz [146.171.15.100]) by core3.amsl.com (Postfix) with ESMTP id CCE963A693A; Sun, 14 Nov 2010 20:23:42 -0800 (PST) Received: from mgate6.telecom.co.nz (unknown [146.171.1.21]) by mgate1.telecom.co.nz (Postfix) with ESMTP id 1A0C57B4AB4; Mon, 15 Nov 2010 17:24:21 +1300 (NZDT) X-WSS-ID: 0LBWS8J-09-2OV-02 X-M-MSG: Received: from hp2847.telecom.tcnz.net (hp2847.telecom.tcnz.net [146.171.228.249]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mgate6.telecom.co.nz (Postfix) with ESMTP id 1537D5DAD5CC; Mon, 15 Nov 2010 17:24:19 +1300 (NZDT) Received: from hp3120.telecom.tcnz.net (146.171.212.205) by hp2847.telecom.tcnz.net (146.171.228.249) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 15 Nov 2010 17:24:20 +1300 Received: from WNEXMBX01.telecom.tcnz.net ([146.171.212.201]) by hp3120.telecom.tcnz.net ([146.171.212.205]) with mapi; Mon, 15 Nov 2010 17:24:20 +1300 From: Kevin Mason To: "conex@ietf.org" Date: Mon, 15 Nov 2010 17:24:19 +1300 Thread-Topic: [conex] [dispatch] [httpstreaming] Q-HTTP Thread-Index: AcuB0uVHZzrj+JIgQaK7yQuY6NMMfQADQk1wAJeuE9A= Message-ID: <9BC62293D3D9534AACB0FEC5F2DE51B20130E801@WNEXMBX01.telecom.tcnz.net> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <002a01cb81e1$40e58740$c2b095c0$@com> In-Reply-To: <002a01cb81e1$40e58740$c2b095c0$@com> Accept-Language: en-US, en-NZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-NZ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'httpstreaming' , "dispatch@ietf.org" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 04:23:50 -0000 I think much of this discussion is missing the root issue. For any communication there is a source and sink. If the communication need= s to pass information in both directions (other then underlying flow manage= ment) then each end becomes both a source and a sink.=20 The path used for this communication is whatever is available. An ISP can i= nfluence where the source of anything a sink wish's to receive is, but comm= ercial and regulatory models can impact beyond what an ISP can control. As a very general rule, distance costs. There are exceptions but the longer= the path generally the higher the cost. As an ISP on the opposite of the w= orld to the majority of the English speaking populations this is more appar= ent to us that others! To suggest that the global industry should or even could ensure that no con= gestion ever occurs between any source and any sink (i.e. the "core") is a = little unrealistic. The probability of congestion on any path is never zero= , regardless of how over provisioned it is. A forwarding link is always 100= % utilised while it is forwarding a packet, so irrespective of the speed of= the link and frequency of arrival of packets for onward transmission, if a= nother packet arrives while the previous one is being sent then it has to w= ait. So how long does it have to wait before the link is considered "conges= ted". How long a packet might have to wait is determined by the ISP in its queue = management and cpacity management at any forwarding point. However the ISP = has no idea what the role of that packet is in the application the source a= nd sink are exchanging data for, only the users do. So the issue re congestion is not if congestion occurs, but how frequency, = and how much delay (or loss) can each application tolerate before its value= or utility to the source and sink diminishes. Telephony (and ATM) has a re= servation mechanism built in, but there is still an "engineered" probabilit= y that congestion occurs and the reservation cannot be made. So sources and sinks between them have options.=20 One option discussed in this thread at length is that the application is, o= r could be, in some way elastic. But even this elasticity does not always c= ome for free, the application has to build that in (clever codecs have roya= lties, as does processing power for user equipment to do any required compu= tation at an acceptable rate), and the users may have to be willing to forg= o some of the potential richness of their application when path bottlenecks= occur. If this is acceptable, application elasticity can be effective in c= reating a more acceptable outcome more often for the total population of so= urces and sink combinations.=20 Elasticity is not just a function of the application, albeit some applicati= ons tend to lend themselves to elastic behaviour more than others, but elas= ticity is more a function of what the source and sink are doing at the time= , and is in part determined by what incentives service provider's put in pl= ace to encourage users to implement and/or enable elasticity in application= behaviour. As has already been mentioned, the threshold when path conditio= ns reach a point that begins to degrade the experience, regardless of appli= cation elasticity, is very low for some uses (e.g. FPS games). The bandwidth for "acceptable" human speech conversation (telephony) is bec= oming trivial in relation to bandwidth required for other uses (e.g. HD vid= eo). So if any degree of fairness exists on paths, the probability that an = acceptable path will exist for the duration of any source and sink speech p= ath combination is getting higher by the day. So value for any differential= mechanism for improving speech path performance probability (reservations,= prioritisation) is rapidly diminishing except on paths where bandwidth rem= ains expensive (e.g. wireless access) because of the scarcity of radio spec= trum. ISPs have a common problem, like any transport provider, in managing incent= ives (financial or market imposed) to discourage undue concentration of pop= ular sources, and/or concentration of popular sinks, and to manage the bala= nce between an individual's appetite to consume resources when it is most c= onvenient to them (and therefore a high probability it is the most convenie= nt time for the majority of other like users), verses modifying their behav= iour (e.g. reducing consumption rate or shifting their consumption to perio= ds of lower utilisation). Zero congestion can never be achieved. But the pr= obability might remain very very low in most cases if providing excess capa= city remains more efficient on the majority of paths rather than managing f= air sharing of the resources. [art of the challenge is to give realistic ex= pectation on what sources and sinks can reasonably expect using language th= ey can understand. So tools like LEDBAT, the proposed Q-HTTP, ECN, are all mechanisms to enabl= e individuals (or their applications on their behalf) to identify when the = path transfer function may be falling below a desired threshold for the pre= ferred mode of application operation, and therefore enable users to change = their behaviour if they are willing to (or to hope other users will change = their behaviour first and leave space for them!). But there is little or no= reward for this concession, so many will continue to just complain. These = mechanisms do not inherently provide the provider with information that wou= ld enable the provider to intervene and referee who gets what if its consid= ered to be getting too unfair.=20 CONEX on the other hand is trying, as I understand it, to provide real time= information to providers that would better enable providers to referee who= get what if user (or upstream providers as the agent for upstream sources)= on their own do not all play fairly, if providers choose to use the inform= ation in this way. Cheers Kevin Mason > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of > Toby Moncaster > Sent: Friday, 12 November 2010 9:45 a.m. > To: conex@ietf.org > Cc: 'httpstreaming'; dispatch@ietf.org > Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP >=20 > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > > Of Mikael Abrahamsson > > Sent: 11 November 2010 19:02 > > To: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) > > Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson > > S; Kathy McEwen; Mike Hammer (hmmr); GARCIA ARANDA, JOSE JAVIER (JOSE > > JAVIER) > > Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP > > > > > > > - Enables network operators to generate more revenue for > > > "over-requirements". I dont think real-time was in mind whe Internet > > was > > > created and we need to provide ISPs with new tools like this. > > > > "over-requirement" as in "I want to actually get what you promised to > > deliver to me"? > > > > I don't buy it. >=20 > Mikael - I think you already put your finger on the problem when you > pointed > out that in your country ISPs are obliged to only promise customers what > they can reasonably deliver. In most of the world ISPs are still marketin= g > "Up to 8 Mbps" or "Up to 20Mbps" for services that at peak, for ~10% of > customers can manage ~6.5Mbps and 18Mbps respectively, with most customer= s > getting half that, and where the backhaul capacity is 10s of kbps per use= r > (contention ratios of ~100 to 1). >=20 > What has gone wrong for ISP business models is that the world has changed= , > with streaming and interactive services overtaking bulk transfer and web > browsing. ConEx may at times appear to be operator centric, but in many > places it is the customers that are suffering because ISPs are forced to > use > pretty crude mechanisms to try and control the small percentage of heavy > users. Clearly everyone must benefit if background bulk data transfers > move > to something like LEDBAT? But currently the operators treat that just the > same as any other P2P traffic so no-one benefits. >=20 > There is also the issue of fair allocation of upgrades. Obviously if an > ISP > spends a lot of money on increasing their backhaul then this money has to > come from the customers. However as things stand the 20% of customers > grabbing 80% of the network will also grab 80% of this increased capacity= , > so they are being even more heavily cross-subsidised. Clearly cross- > subsidy > is always going to happen to an extent so long as you have flat fees for > access (even if you put in tiered fees, there is still cross-subsidy). Bu= t > this should not be excessive else customers suffer. >=20 > Toby >=20 > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From ingemar.s.johansson@ericsson.com Mon Nov 15 05:20:24 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D904E3A6C96 for ; Mon, 15 Nov 2010 05:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGT09Gf8r0fW for ; Mon, 15 Nov 2010 05:20:23 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 74BD33A6BE1 for ; Mon, 15 Nov 2010 05:20:23 -0800 (PST) X-AuditID: c1b4fb3d-b7b28ae00000135b-bc-4ce133bd114d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 83.D8.04955.DB331EC4; Mon, 15 Nov 2010 14:21:02 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 15 Nov 2010 14:21:01 +0100 From: Ingemar Johansson S To: Roland Bless Date: Mon, 15 Nov 2010 14:21:00 +0100 Thread-Topic: [conex] Abstract marking and encoding in IPv6 Thread-Index: AcuCX4Mc2uXWhAK6RKuz6rYMJZ8XPwCZgRpw Message-ID: References: <4CDD297D.9030204@kit.edu> In-Reply-To: <4CDD297D.9030204@kit.edu> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 13:20:25 -0000 Hi I admit that I may not get the whole picture why packets with hop-by-hop he= aders are punted to the slow path but I am not sure that it is a broken beh= avior especially as as the additional complexity caused by the extension he= ader is impossible to see just by looking at the 3MSBs. So I am not really = sure that you can solve this problem but I will have to leave this to the e= xperts in this area to determine Even if the "general punt to slow path" problem is solved, it is likely tha= t ConEx enabled routers will have to put ConEx packets in the slow path and= this I believe limits the use of ConEx policing to relatively low bitrate = interfaces, perhaps this is no problem if the core is overprovisioned, I do= n't know. ConEx marking is special in the sense that the complexity of the ConEx mark= ing can be made very low. If we put the MPLS issue (another problem) aside = one can implement a very cheap policer in a high-speed interface just by co= unting the average ConEx rate (=3Ddon't care about the packet size). This o= f course means that a ConEx enabled routher does not need to do too much lo= okup in each packet. Use of bits from the flow label field can make this po= ssible. Other encodings like extension headers and GUT can be more problema= tic in this respect. Regards Ingemar > -----Original Message----- > From: Roland Bless [mailto:roland.bless@kit.edu]=20 > Sent: den 12 november 2010 12:48 > To: Ingemar Johansson S > Cc: conex@ietf.org > Subject: Re: [conex] Abstract marking and encoding in IPv6 >=20 > Hi, >=20 > On 12.11.2010 02:29, Ingemar Johansson S wrote: > > + Encoding in IPv6: To me it seems like the only way to make ConEx > > commercially attactive is to use some of the bits from the=20 > flow label=20 > > field. It was to me pretty clear that extension headers=20 > (including the=20 > > hop-by-hop options header) are not very useful in this=20 > context and it=20 > > was also explained (Rich Woundy) that the latter are not=20 > even useful=20 > > for experimentation (my interpretation). So what is=20 > required here is=20 > > to convince 6man (and others) that ConEx is a good use case=20 > for N bits=20 > > in the flow label field reserved for ConEx. >=20 > It's not totally clear to me why extension headers aren't the right > approach: the main obstacle seems to be that broken=20 > implementations punt the packet to the slow path as soon as=20 > there is a hop-by-hop option present. For a CONEX supporting=20 > router you could implement that new conex h-b-h option in the=20 > fast path, and old ones should ignore the unknown option and=20 > leave the packet in the fast path. IMHO it's better to get=20 > that fixed asap since otherwise the h-b-h extension headers=20 > aren't very useful. Thus, the natural choice would be to use=20 > the foreseen IPv6 extension mechanism. >=20 > Regards, > Roland > = From ingemar.s.johansson@ericsson.com Mon Nov 15 05:36:38 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B297528C104 for ; Mon, 15 Nov 2010 05:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrvLd8W05S4W for ; Mon, 15 Nov 2010 05:36:31 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 428683A6CA6 for ; Mon, 15 Nov 2010 05:36:30 -0800 (PST) X-AuditID: c1b4fb3d-b7b28ae00000135b-47-4ce13786419c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D0.FA.04955.68731EC4; Mon, 15 Nov 2010 14:37:10 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 15 Nov 2010 14:37:10 +0100 From: Ingemar Johansson S To: Toby Moncaster , 'marcelo bagnulo braun' , "conex@ietf.org" Date: Mon, 15 Nov 2010 14:37:09 +0100 Thread-Topic: [conex] Abstract marking and encoding in IPv6 Thread-Index: AcuENq3yW+ipcGQ3TiWyYIaGSN4zVgAkZL+A Message-ID: References: <944971A7-1B75-47F1-BA1D-393644CF1954@g11.org.uk> <4CDCA513.6030808@it.uc3m.es> <4CDF9C74.7090600@it.uc3m.es> <000301cb8414$8856e6c0$9904b440$@com> In-Reply-To: <000301cb8414$8856e6c0$9904b440$@com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 13:36:38 -0000 Hi If we consider the idea to use bits from the flow label field I am not sure= that 1 or 3 bits makes much of a difference as I suspect that much of the = possible resistance will be along the lines "why allocate bits for an exper= iment?". But of course the equation objection =3D f(bits)=20 probably applies. That said, what I really believe tilts the whole thing towards is support i= s. A) ConEx helps operators to do things not otherwise possible, meaning opera= tors want to buy it. B) Vendors are willing to implement it I would be interested to participate in an interim meeting. I guess one can= do tricks with non-TCP applications to limit the need for green markings (= such as more frequent RTCP reports in the beginning of an RTP-session). /Ingemar =20 > -----Original Message----- > From: Toby Moncaster [mailto:toby@moncaster.com]=20 > Sent: den 14 november 2010 16:57 > To: 'marcelo bagnulo braun'; conex@ietf.org > Subject: Re: [conex] Abstract marking and encoding in IPv6 >=20 > This sounds a sensible suggestion. I think the aim of an=20 > interim meeting should be to address two questions: >=20 > 1) What is the minimum number of (new) bits required for the=20 > ConEx abstract mechanism in Matt's and Bob's draft? >=20 > 2) What is the maximum functionality we can get with just 1 new bit? >=20 > Obviously it would be really nice to think the two answers=20 > are effectively the same (in other words 1 additional bit is=20 > enough to implement the whole mechanism).=20 >=20 > Toby >=20 >=20 > > -----Original Message----- > > From: conex-bounces@ietf.org=20 > [mailto:conex-bounces@ietf.org] On Behalf=20 > > Of marcelo bagnulo braun > > Sent: 14 November 2010 08:23 > > To: conex@ietf.org > > Subject: Re: [conex] Abstract marking and encoding in IPv6 > >=20 > > fwiw, this was a serious question. I mean, in v4 afaiu, we=20 > would only=20 > > get one bit and we could make it work. I would like to=20 > understand how=20 > > much can we do with one bit. I don't belive we could ask=20 > for 4 bits in=20 > > the flow label, and asking for 1 bit for conex seems much more=20 > > reasonable to me. > >=20 > >=20 > >=20 > > El 12/11/10 3:23, marcelo bagnulo braun escribi=F3: > > > I would pose then the question: if you could only get 1 bit, what=20 > > > could you do? > > > > > > Regards, marcelo > > > > > > > > > > > > El 12/11/10 3:19, ken carlberg escribi=F3: > > >> Ingemar, > > >> > > >>> + Encoding in IPv6: To me it seems like the only way to=20 > make ConEx > > >>> commercially attactive is to use some of the bits from the flow=20 > > >>> label field. It was to me pretty clear that extension headers=20 > > >>> (including the hop-by-hop options header) are not very=20 > useful in=20 > > >>> this context and it was also explained (Rich Woundy) that the > > latter > > >>> are not even useful for experimentation (my interpretation). So > > what > > >>> is required here is to convince 6man (and others) that=20 > ConEx is a=20 > > >>> good use case for N bits in the flow label field reserved for > > ConEx. > > >> given the constraints that CONEX is only producing experimental > > work, > > >> my feeling is that the odds are way against having 4 bits taken=20 > > >> away from the flow label field for CONEX. It would probably be=20 > > >> best if the author/chairs could get the pulse of such a proposal=20 > > >> from the 6man chairs, asap. and from that, one could=20 > decide which=20 > > >> direction to pursue. > > >> > > >> -ken > > >> > > >> _______________________________________________ > > >> conex mailing list > > >> conex@ietf.org > > >> https://www.ietf.org/mailman/listinfo/conex > > >> > > > > > > _______________________________________________ > > > conex mailing list > > > conex@ietf.org > > > https://www.ietf.org/mailman/listinfo/conex > > > > >=20 > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex >=20 >=20 > = From ingemar.s.johansson@ericsson.com Mon Nov 15 06:19:59 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 449EA3A6A2E for ; Mon, 15 Nov 2010 06:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EdGmQyf02UV for ; Mon, 15 Nov 2010 06:19:52 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 31BAA3A68D4 for ; Mon, 15 Nov 2010 06:19:51 -0800 (PST) X-AuditID: c1b4fb39-b7b54ae000003464-96-4ce141b0d996 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.05.13412.0B141EC4; Mon, 15 Nov 2010 15:20:32 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.86]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 15 Nov 2010 15:20:32 +0100 From: Ingemar Johansson S To: Bob Briscoe , "Woundy, Richard" Date: Mon, 15 Nov 2010 15:20:31 +0100 Thread-Topic: [conex] Abstract marking and encoding in IPv6 Thread-Index: AcuCgUfIxisfLin9ThujTzpvbMt7eQCTg6vA Message-ID: References: <1CA25301D2219F40B3AA37201F0EACD1030ECD@PACDCEXMB05.cable.comcast.com> <201011121550.oACFo3FI005675@bagheera.jungle.bt.co.uk> In-Reply-To: <201011121550.oACFo3FI005675@bagheera.jungle.bt.co.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 14:19:59 -0000 Hi The possible issue I see with GUT is that endpoints need to be upgraded to = understand GUT, of course any endpoint needs to be upgraded anyway to under= stand ConEx so this is probably not an valid issue.=20 The second issue is the additional packet overhead caused but GUT. I admit = that you have an additional overhead (8 bytes?) with IPv6 hop-by-hop option= s but this overhead is bigger.=20 But.. sure, it may perhaps be the best alternative at least for experimenta= l use. /Ingemar > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk]=20 > Sent: den 12 november 2010 16:50 > To: Woundy, Richard; Ingemar Johansson S > Cc: conex@ietf.org > Subject: Re: [conex] Abstract marking and encoding in IPv6 >=20 > Rich, Ingemar, >=20 > I like Marcelo's idea of an interim session on encoding=20 > (presumably by audio). >=20 > Beyond the 3 techniques in Suresh's presentation, there are=20 > two other possibilities I can think of: > 4) (proposed by Lars) use bits in an existing v6 hop-by-hop=20 > options header > 5) use GUT >=20 > 4) The idea here is that the IPv6 main header is not the only=20 > header that today's v6 routers already support that might=20 > offer some space. For instance there might be a possibility=20 > to re-purpose the IPv6 fragmentation header (I chose this=20 > particularly, because we might be able to repeat the same=20 > trick in the fragmentation fields of the IPv4 header). There=20 > might be ideas for using other existing v6 hop-by-hop headers too. >=20 > 5) Here's an intro to why GUT could be a principled=20 > alternative, which I recently sent offlist to the authors of=20 > : >=20 > >GUT was originally designed for tunnelling new transport layer=20 > >protocols. But in a change between -01 and -02 we took the=20 > insight from=20 > >Rob Hancock that any router with IP header extension code will know=20 > >where to look, so it's unnecessary to have routers that don't know=20 > >about new extensions checking through a string of extensions looking=20 > >for stuff they don't have code for. > > > >Instead, we hid IP extension headers behind a UDP header.=20 > Packets then=20 > >go through NATs, firewalls and any assorted meddleboxes and=20 > >muddleboxes. > > > >And you don't get punted to the slow path. > > > >Although it doesn't look principled, it depends how you look at it -=20 > >see Tng (transport next-gen). > > > >We still need to define the principles for how it interacts=20 > with IPsec=20 > >etc. So I'm not saying it's completely thought through. But it works. >=20 > There's been some conversation on GUT between us since, that=20 > we ought to summarise to the ConEx list once it has finished. >=20 >=20 > Bob >=20 > At 03:30 12/11/2010, Woundy, Richard wrote: > > > It was to me pretty clear that extension=20 > > headers (including the hop-by-hop options=20 > > header) are not very useful in this context and=20 > > it was also explained (Rich Woundy) that the=20 > > latter are not even useful for experimentation (my interpretation). > > > >This might be a good time to clarify my comments. > > > >First, the context of my comments (not useful=20 > >for experimentation) was focused on experiments=20 > >across the Internet, not on lab experiments=20 > >where I am sure any approach will work. > > > >Second, some folks behind me at the mike during=20 > >the Conex session asserted that the "slow path"=20 > >through some commercial routers could be 1000=20 > >times slower than the usual "fast path", maybe=20 > >even 100,000 times slower. Personally I didn't=20 > >quote a performance difference but I have seen=20 > >huge discrepancies between the slow and fast=20 > >paths on some commercial routers. This affects=20 > >the capacity available for the experimental traffic. > > > >Third, there was something I forgot to mention=20 > >at the mike, which is a big deal. Oftentimes,=20 > >forwarding traffic through the router's slow=20 > >path implies sending packets to the main router=20 > >CPU for processing. The main router CPU is also=20 > >performing other key activities, particularly=20 > >exchanging routing protocol messages, updating=20 > >the RIB and FIB, supporting network management=20 > >queries, generating statistics, etc. So if there=20 > >is a significant amount of experimental traffic,=20 > >it *might* impact the functioning of the router=20 > >itself, depending on the relative priority of=20 > >the experimental traffic and each of these activities. > > > >-- Rich > > > >-----Original Message----- > >From: conex-bounces@ietf.org=20 > >[mailto:conex-bounces@ietf.org] On Behalf Of Ingemar Johansson S > >Sent: Friday, November 12, 2010 9:29 AM > >To: conex@ietf.org > >Subject: [conex] Abstract marking and encoding in IPv6 > > > >Hi > > > >Given yesterdays presentation on the abtract=20 > >encoding mechanism and the IPv6 encoding options my findings are: > > > >+ Encoding in IPv6: To me it seems like the only=20 > >way to make ConEx commercially attactive is to=20 > >use some of the bits from the flow label field.=20 > >It was to me pretty clear that extension headers=20 > >(including the hop-by-hop options header) are=20 > >not very useful in this context and it was also=20 > >explained (Rich Woundy) that the latter are not=20 > >even useful for experimentation (my=20 > >interpretation). So what is required here is to=20 > >convince 6man (and others) that ConEx is a good=20 > >use case for N bits in the flow label field reserved for ConEx. > > > >+ Encoding of abstract mechanism: Now that I=20 > >(believe I) understand the green marking (and=20 > >the necessity of it) it is to me quite obvious=20 > >that 5 codepoints are needed, thus 3 bits are=20 > >needed, this leaves 1 unused codepoint waiting=20 > >for an interesting use case... > > > >/Ingemar > > > >=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 > >INGEMAR JOHANSSON M.Sc. > >Senior Research Engineer > > > >Ericsson AB > >Multimedia Technologies > >Labratoriegr=E4nd 11 > >971 28, Lule=E5, Sweden > >Phone +46-1071 43042 > >SMS/MMS +46-73 078 3289 > >ingemar.s.johansson@ericsson.com > >www.ericsson.com > >Visit http://labs.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 > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex > >_______________________________________________ > >conex mailing list > >conex@ietf.org > >https://www.ietf.org/mailman/listinfo/conex >=20 > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design=20 >=20 > = From carlberg@g11.org.uk Mon Nov 15 06:22:00 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6C813A6A70 for ; Mon, 15 Nov 2010 06:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5cdIzp6oQz7 for ; Mon, 15 Nov 2010 06:21:53 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 4B22C28C126 for ; Mon, 15 Nov 2010 06:21:53 -0800 (PST) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:58214 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1PHzwt-0000h4-8I; Mon, 15 Nov 2010 14:22:23 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: ken carlberg In-Reply-To: Date: Mon, 15 Nov 2010 09:22:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <944971A7-1B75-47F1-BA1D-393644CF1954@g11.org.uk> <4CDCA513.6030808@it.uc3m.es> <4CDF9C74.7090600@it.uc3m.es> <000301cb8414$8856e6c0$9904b440$@com> To: Ingemar Johansson S X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 14:22:00 -0000 Hi Ingemar, at the meeting, there was a speaker who brought up the suggestion of = taking out 4 bits from the 20 bit field for "other use", and _retaining_ = 16 bits for a smaller flow-ID. So if that's the case, I think its being = very optimistic for any group (CONEX or anyone else) to immediate make a = claim for 3 of those 4 bits. =20 I too like Marcelo's suggesting of just focusing on 1 bit, since that = was the original intent concerning IP4 during the BoF discussions cheers, -ken On Nov 15, 2010, at 8:37 AM, Ingemar Johansson S wrote: > Hi >=20 > If we consider the idea to use bits from the flow label field I am not = sure that 1 or 3 bits makes much of a difference as I suspect that much = of the possible resistance will be along the lines "why allocate bits = for an experiment?". But of course the equation > objection =3D f(bits)=20 > probably applies. > That said, what I really believe tilts the whole thing towards is = support is. > A) ConEx helps operators to do things not otherwise possible, meaning = operators want to buy it. > B) Vendors are willing to implement it >=20 > I would be interested to participate in an interim meeting. I guess = one can do tricks with non-TCP applications to limit the need for green = markings (such as more frequent RTCP reports in the beginning of an = RTP-session). >=20 > /Ingemar >=20 >=20 >> -----Original Message----- >> From: Toby Moncaster [mailto:toby@moncaster.com]=20 >> Sent: den 14 november 2010 16:57 >> To: 'marcelo bagnulo braun'; conex@ietf.org >> Subject: Re: [conex] Abstract marking and encoding in IPv6 >>=20 >> This sounds a sensible suggestion. I think the aim of an=20 >> interim meeting should be to address two questions: >>=20 >> 1) What is the minimum number of (new) bits required for the=20 >> ConEx abstract mechanism in Matt's and Bob's draft? >>=20 >> 2) What is the maximum functionality we can get with just 1 new bit? >>=20 >> Obviously it would be really nice to think the two answers=20 >> are effectively the same (in other words 1 additional bit is=20 >> enough to implement the whole mechanism).=20 >>=20 >> Toby >>=20 >>=20 >>> -----Original Message----- >>> From: conex-bounces@ietf.org=20 >> [mailto:conex-bounces@ietf.org] On Behalf=20 >>> Of marcelo bagnulo braun >>> Sent: 14 November 2010 08:23 >>> To: conex@ietf.org >>> Subject: Re: [conex] Abstract marking and encoding in IPv6 >>>=20 >>> fwiw, this was a serious question. I mean, in v4 afaiu, we=20 >> would only=20 >>> get one bit and we could make it work. I would like to=20 >> understand how=20 >>> much can we do with one bit. I don't belive we could ask=20 >> for 4 bits in=20 >>> the flow label, and asking for 1 bit for conex seems much more=20 >>> reasonable to me. >>>=20 >>>=20 >>>=20 >>> El 12/11/10 3:23, marcelo bagnulo braun escribi=F3: >>>> I would pose then the question: if you could only get 1 bit, what=20= >>>> could you do? >>>>=20 >>>> Regards, marcelo >>>>=20 >>>>=20 >>>>=20 >>>> El 12/11/10 3:19, ken carlberg escribi=F3: >>>>> Ingemar, >>>>>=20 >>>>>> + Encoding in IPv6: To me it seems like the only way to=20 >> make ConEx >>>>>> commercially attactive is to use some of the bits from the flow=20= >>>>>> label field. It was to me pretty clear that extension headers=20 >>>>>> (including the hop-by-hop options header) are not very=20 >> useful in=20 >>>>>> this context and it was also explained (Rich Woundy) that the >>> latter >>>>>> are not even useful for experimentation (my interpretation). So >>> what >>>>>> is required here is to convince 6man (and others) that=20 >> ConEx is a=20 >>>>>> good use case for N bits in the flow label field reserved for >>> ConEx. >>>>> given the constraints that CONEX is only producing experimental >>> work, >>>>> my feeling is that the odds are way against having 4 bits taken=20 >>>>> away from the flow label field for CONEX. It would probably be=20 >>>>> best if the author/chairs could get the pulse of such a proposal=20= >>>>> from the 6man chairs, asap. and from that, one could=20 >> decide which=20 >>>>> direction to pursue. >>>>>=20 >>>>> -ken >>>>>=20 >>>>> _______________________________________________ >>>>> conex mailing list >>>>> conex@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/conex >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> conex mailing list >>>> conex@ietf.org >>>> https://www.ietf.org/mailman/listinfo/conex >>>>=20 >>>=20 >>> _______________________________________________ >>> conex mailing list >>> conex@ietf.org >>> https://www.ietf.org/mailman/listinfo/conex >>=20 >>=20 >>=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From roland.bless@kit.edu Mon Nov 15 13:54:58 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D40C28C127 for ; Mon, 15 Nov 2010 13:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W1GrtpaEdyl2 for ; Mon, 15 Nov 2010 13:54:56 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 28DDC3A6C4C for ; Mon, 15 Nov 2010 13:54:53 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PI71L-0008EF-Qb; Mon, 15 Nov 2010 22:55:34 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1PI71L-0003d4-Ki; Mon, 15 Nov 2010 22:55:27 +0100 Received: from vorta.tm.uka.de (roland.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7D59B2FC047; Mon, 15 Nov 2010 22:55:27 +0100 (CET) Received: from [IPv6:::1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTPS id 3B60A2A4F; Mon, 15 Nov 2010 22:55:27 +0100 (CET) Message-ID: <4CE1AC4E.5040805@kit.edu> Date: Mon, 15 Nov 2010 22:55:26 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0 MIME-Version: 1.0 To: Ingemar Johansson S References: <4CDD297D.9030204@kit.edu> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1289858134.169754000 Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 21:54:58 -0000 Hi, On 15.11.2010 14:21, Ingemar Johansson S wrote: > I admit that I may not get the whole picture why packets with > hop-by-hop headers are punted to the slow path but I am not sure that > it is a broken behavior especially as as the additional complexity > caused by the extension header is impossible to see just by looking > at the 3MSBs. So I am not really sure that you can solve this problem > but I will have to leave this to the experts in this area to > determine I'm not a hardware expert either, but I think that it should be possible to have a simple multifield match for an extension header in the fast path. I didn't state that looking at the 3MSB (I assume you mean bits here) is sufficient. You have to check the next header field value + the option type. If option type is "conex" then you may set the appropriate value in the option. I think that this can be easily done in the fast path since multifield classifiers and token bucket policers can be realized there, too. > Even if the "general punt to slow path" problem is solved, it is > likely that ConEx enabled routers will have to put ConEx packets in > the slow path and this I believe limits the use of ConEx policing to I don't think that slow path processing will be necessary. > relatively low bitrate interfaces, perhaps this is no problem if the > core is overprovisioned, I don't know. > ConEx marking is special in the sense that the complexity of the > ConEx marking can be made very low. If we put the MPLS issue (another > problem) aside one can implement a very cheap policer in a high-speed > interface just by counting the average ConEx rate (=don't care about > the packet size). This of course means that a ConEx enabled routher > does not need to do too much lookup in each packet. Use of bits from > the flow label field can make this possible. Other encodings like > extension headers and GUT can be more problematic in this respect. I doubt that looking for a conex extension header is a very costly task... Regards Roland > Regards Ingemar > >> -----Original Message----- From: Roland Bless >> [mailto:roland.bless@kit.edu] Sent: den 12 november 2010 12:48 To: >> Ingemar Johansson S Cc: conex@ietf.org Subject: Re: [conex] >> Abstract marking and encoding in IPv6 >> >> Hi, >> >> On 12.11.2010 02:29, Ingemar Johansson S wrote: >>> + Encoding in IPv6: To me it seems like the only way to make >>> ConEx commercially attactive is to use some of the bits from the >>> >> flow label >>> field. It was to me pretty clear that extension headers >> (including the >>> hop-by-hop options header) are not very useful in this >> context and it >>> was also explained (Rich Woundy) that the latter are not >> even useful >>> for experimentation (my interpretation). So what is >> required here is >>> to convince 6man (and others) that ConEx is a good use case >> for N bits >>> in the flow label field reserved for ConEx. >> >> It's not totally clear to me why extension headers aren't the >> right approach: the main obstacle seems to be that broken >> implementations punt the packet to the slow path as soon as there >> is a hop-by-hop option present. For a CONEX supporting router you >> could implement that new conex h-b-h option in the fast path, and >> old ones should ignore the unknown option and leave the packet in >> the fast path. IMHO it's better to get that fixed asap since >> otherwise the h-b-h extension headers aren't very useful. Thus, the >> natural choice would be to use the foreseen IPv6 extension >> mechanism. >> >> Regards, Roland From ingemar.s.johansson@ericsson.com Tue Nov 16 00:19:08 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27E173A69CE for ; Tue, 16 Nov 2010 00:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkxozFdTdNfi for ; Tue, 16 Nov 2010 00:19:06 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4A7E83A6BDA for ; Tue, 16 Nov 2010 00:19:06 -0800 (PST) X-AuditID: c1b4fb39-b7b54ae000003464-10-4ce23ea49a07 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FA.98.13412.4AE32EC4; Tue, 16 Nov 2010 09:19:48 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.174]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 16 Nov 2010 09:19:48 +0100 From: Ingemar Johansson S To: ken carlberg Date: Tue, 16 Nov 2010 09:19:47 +0100 Thread-Topic: [conex] Abstract marking and encoding in IPv6 Thread-Index: AcuE0IyHr1IYdbdqT3G38YZKpHta1wAlTcWg Message-ID: References: <944971A7-1B75-47F1-BA1D-393644CF1954@g11.org.uk> <4CDCA513.6030808@it.uc3m.es> <4CDF9C74.7090600@it.uc3m.es> <000301cb8414$8856e6c0$9904b440$@com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 08:19:08 -0000 Hi It is possible that you are right that 1 bit is the absolute pain limit. Perhaps it is a good idea to discuss what kind of funtionality is possible = with=20 a) 3 bits b) 2 bits c) 1 bit=20 a) is already given by the abstract marking draft. /Ingeamr > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk]=20 > Sent: den 15 november 2010 15:22 > To: Ingemar Johansson S > Cc: Toby Moncaster; 'marcelo bagnulo braun'; conex@ietf.org > Subject: Re: [conex] Abstract marking and encoding in IPv6 >=20 > Hi Ingemar, >=20 > at the meeting, there was a speaker who brought up the=20 > suggestion of taking out 4 bits from the 20 bit field for=20 > "other use", and _retaining_ 16 bits for a smaller flow-ID. =20 > So if that's the case, I think its being very optimistic for=20 > any group (CONEX or anyone else) to immediate make a claim=20 > for 3 of those 4 bits. =20 >=20 > I too like Marcelo's suggesting of just focusing on 1 bit,=20 > since that was the original intent concerning IP4 during the=20 > BoF discussions >=20 > cheers, >=20 > -ken >=20 >=20 > On Nov 15, 2010, at 8:37 AM, Ingemar Johansson S wrote: >=20 > > Hi > >=20 > > If we consider the idea to use bits from the flow label=20 > field I am not=20 > > sure that 1 or 3 bits makes much of a difference as I suspect that=20 > > much of the possible resistance will be along the lines=20 > "why allocate bits for an experiment?". But of course the=20 > equation objection =3D f(bits) probably applies. > > That said, what I really believe tilts the whole thing=20 > towards is support is. > > A) ConEx helps operators to do things not otherwise=20 > possible, meaning operators want to buy it. > > B) Vendors are willing to implement it > >=20 > > I would be interested to participate in an interim meeting.=20 > I guess one can do tricks with non-TCP applications to limit=20 > the need for green markings (such as more frequent RTCP=20 > reports in the beginning of an RTP-session). > >=20 > > /Ingemar > >=20 > >=20 > >> -----Original Message----- > >> From: Toby Moncaster [mailto:toby@moncaster.com] > >> Sent: den 14 november 2010 16:57 > >> To: 'marcelo bagnulo braun'; conex@ietf.org > >> Subject: Re: [conex] Abstract marking and encoding in IPv6 > >>=20 > >> This sounds a sensible suggestion. I think the aim of an interim=20 > >> meeting should be to address two questions: > >>=20 > >> 1) What is the minimum number of (new) bits required for the ConEx=20 > >> abstract mechanism in Matt's and Bob's draft? > >>=20 > >> 2) What is the maximum functionality we can get with just=20 > 1 new bit? > >>=20 > >> Obviously it would be really nice to think the two answers are=20 > >> effectively the same (in other words 1 additional bit is enough to=20 > >> implement the whole mechanism). > >>=20 > >> Toby > >>=20 > >>=20 > >>> -----Original Message----- > >>> From: conex-bounces@ietf.org > >> [mailto:conex-bounces@ietf.org] On Behalf > >>> Of marcelo bagnulo braun > >>> Sent: 14 November 2010 08:23 > >>> To: conex@ietf.org > >>> Subject: Re: [conex] Abstract marking and encoding in IPv6 > >>>=20 > >>> fwiw, this was a serious question. I mean, in v4 afaiu, we > >> would only > >>> get one bit and we could make it work. I would like to > >> understand how > >>> much can we do with one bit. I don't belive we could ask > >> for 4 bits in > >>> the flow label, and asking for 1 bit for conex seems much more=20 > >>> reasonable to me. > >>>=20 > >>>=20 > >>>=20 > >>> El 12/11/10 3:23, marcelo bagnulo braun escribi=F3: > >>>> I would pose then the question: if you could only get 1=20 > bit, what=20 > >>>> could you do? > >>>>=20 > >>>> Regards, marcelo > >>>>=20 > >>>>=20 > >>>>=20 > >>>> El 12/11/10 3:19, ken carlberg escribi=F3: > >>>>> Ingemar, > >>>>>=20 > >>>>>> + Encoding in IPv6: To me it seems like the only way to > >> make ConEx > >>>>>> commercially attactive is to use some of the bits from=20 > the flow=20 > >>>>>> label field. It was to me pretty clear that extension headers=20 > >>>>>> (including the hop-by-hop options header) are not very > >> useful in > >>>>>> this context and it was also explained (Rich Woundy) that the > >>> latter > >>>>>> are not even useful for experimentation (my interpretation). So > >>> what > >>>>>> is required here is to convince 6man (and others) that > >> ConEx is a > >>>>>> good use case for N bits in the flow label field reserved for > >>> ConEx. > >>>>> given the constraints that CONEX is only producing experimental > >>> work, > >>>>> my feeling is that the odds are way against having 4 bits taken=20 > >>>>> away from the flow label field for CONEX. It would probably be=20 > >>>>> best if the author/chairs could get the pulse of such a=20 > proposal=20 > >>>>> from the 6man chairs, asap. and from that, one could > >> decide which > >>>>> direction to pursue. > >>>>>=20 > >>>>> -ken > >>>>>=20 > >>>>> _______________________________________________ > >>>>> conex mailing list > >>>>> conex@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/conex > >>>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> conex mailing list > >>>> conex@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/conex > >>>>=20 > >>>=20 > >>> _______________________________________________ > >>> conex mailing list > >>> conex@ietf.org > >>> https://www.ietf.org/mailman/listinfo/conex > >>=20 > >>=20 > >>=20 > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex >=20 > = From slblake@petri-meat.com Tue Nov 16 07:33:46 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3B0D3A6C9E for ; Tue, 16 Nov 2010 07:33:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E84QuZwU0cTB for ; Tue, 16 Nov 2010 07:33:45 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id AD1553A6A17 for ; Tue, 16 Nov 2010 07:33:45 -0800 (PST) Received: from cpe-174-097-227-047.nc.res.rr.com ([174.97.227.47]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1PINY6-0006jZ-BB; Tue, 16 Nov 2010 10:34:22 -0500 From: Steven Blake To: Roland Bless In-Reply-To: <4CE1AC4E.5040805@kit.edu> References: <4CDD297D.9030204@kit.edu> <4CE1AC4E.5040805@kit.edu> Content-Type: text/plain; charset="UTF-8" Date: Tue, 16 Nov 2010 10:34:25 -0500 Message-ID: <1289921665.6883.13.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: Ingemar Johansson S , "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 15:33:46 -0000 On Mon, 2010-11-15 at 22:55 +0100, Roland Bless wrote: > Hi, > > On 15.11.2010 14:21, Ingemar Johansson S wrote: > > I admit that I may not get the whole picture why packets with > > hop-by-hop headers are punted to the slow path but I am not sure that > > it is a broken behavior especially as as the additional complexity > > caused by the extension header is impossible to see just by looking > > at the 3MSBs. So I am not really sure that you can solve this problem > > but I will have to leave this to the experts in this area to > > determine > > I'm not a hardware expert either, but I think that it should be possible > to have a simple multifield match for an extension header in the fast > path. I didn't state that looking at the 3MSB (I assume you mean bits > here) is sufficient. You have to check the next header field value > + the option type. If option type is "conex" then you may set the > appropriate value in the option. I think that this can be easily > done in the fast path since multifield classifiers and token bucket > policers can be realized there, too. > > > Even if the "general punt to slow path" problem is solved, it is > > likely that ConEx enabled routers will have to put ConEx packets in > > the slow path and this I believe limits the use of ConEx policing to > > I don't think that slow path processing will be necessary. > > > relatively low bitrate interfaces, perhaps this is no problem if the > > core is overprovisioned, I don't know. > > > ConEx marking is special in the sense that the complexity of the > > ConEx marking can be made very low. If we put the MPLS issue (another > > problem) aside one can implement a very cheap policer in a high-speed > > interface just by counting the average ConEx rate (=don't care about > > the packet size). This of course means that a ConEx enabled routher > > does not need to do too much lookup in each packet. Use of bits from > > the flow label field can make this possible. Other encodings like > > extension headers and GUT can be more problematic in this respect. > > I doubt that looking for a conex extension header is a very costly task... Adding functionality to fast-path forwarding adds cost (extra memory/TCAM accesses; extra code in firmware memory). Some (but not all) fast-path implementations are non-programmable. Don't underestimate the reluctance of vendors to add additional functionality to fast-path forwarding. Regards, // Steve From tme@americafree.tv Tue Nov 16 08:42:27 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1294D3A6CC3; Tue, 16 Nov 2010 08:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.367 X-Spam-Level: X-Spam-Status: No, score=-101.367 tagged_above=-999 required=5 tests=[AWL=1.232, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU--pWx19zhI; Tue, 16 Nov 2010 08:42:26 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C026B3A6CAF; Tue, 16 Nov 2010 08:42:25 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 51A0993D45C3; Tue, 16 Nov 2010 11:43:09 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: Date: Tue, 16 Nov 2010 11:43:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com><3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com><01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> To: "Mike Hammer (hmmr)" X-Mailer: Apple Mail (2.1081) Cc: dispatch@ietf.org, Kathy McEwen , httpstreaming , conex@ietf.org, Ingemar Johansson S , Mark Watson , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 16:42:27 -0000 On Nov 10, 2010, at 10:05 AM, Mike Hammer (hmmr) wrote: > Nice theory. Until it gets down to who is going to pay for the > over-provisioning. It is a mistake to call it over-provisioning. (Anything needed for = proper performance I would call proper provisioning.) And, of course, = the customers pay for it. (It is interesting that no one ever seems to ask = who pays for QOS.) It is a question of where is it better to put resources, and I think = that there is a long history to show that in many (not all) situations = it is better to put resources in provisioning than in QOS.=20 I also think that a modest amount of FEC would go a long way to address = concerns about real-time traffic, and I surprised that this is not already used routinely.=20 Regards Marshall=20 >=20 > Is the ARPU going to go up? Are content distributors willing to pay > more to send that data? >=20 > Also, note how the volume of traffic always seems to expand to fill = the > BW available. >=20 > Mike >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mark Watson > Sent: Tuesday, November 09, 2010 11:19 PM > To: Kathy McEwen > Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar = Johansson > S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) > Subject: Re: [dispatch] [httpstreaming] Q-HTTP >=20 >=20 >=20 > Sent from my iPad >=20 > On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" > wrote: >=20 >> One problem with the voice analogy is that the sheer volume of data >> traversing the web today is not driven by voice...it's video...and > it's not >> even a fraction of the viewing that folks are doing of broadcast > content. A >> solution that depends on "simply" having too much bandwidth, is that > someone >> is paying for it. Eventually it hits someone's pocket books....and = if > there >> isn't sufficient revenue to cover the costs, the too much does > degrade. >> Today the mass media is consumed via cheap broadcast technologies... > why >> shouldn't the web (fixed and mobile) be as cheap AND as good?? =20 >>=20 >=20 > It should, the question is what is the cheapest way to do it. QoS is > expensive too. I tend to agree with the thesis below that history is > telling us that avoiding scarcity in the first place is cheaper than > rationing here. >=20 > ...Mark >=20 >> -----Original Message----- >> From: httpstreaming-bounces@ietf.org > [mailto:httpstreaming-bounces@ietf.org] >> On Behalf Of Lars Eggert >> Sent: Tuesday, November 09, 2010 8:02 PM >> To: David Singer >> Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); >> httpstreaming; dispatch@ietf.org; conex@ietf.org >> Subject: Re: [httpstreaming] [dispatch] Q-HTTP >>=20 >> On 2010-11-9, at 18:31, David Singer wrote: >>> It is that there are two ways to solve a real-time bandwidth need. > One is >> to reserve bandwidth, manage QoS and so on; one gets protocols and > systems >> like diffserv, ATM, and so on. The other is simply to have 'too = much' > of >> the resource. Though it feels wrong, the latter often ends up being > the >> cheaper and easier solution. So, for example, voice over IP is > getting used >> quite a lot, and to good effect, on the internet today not because we > have >> successfully deployed any bandwidth reservation or QoS management > protocols >> and systems, but because the available bandwidth is, for the most > part, >> greatly in excess of what is needed, and the systems can adapt in > real-time >> to what they get (rather than asking for what they want). The same = is > true >> for multimedia delivery; the complexity of RTP + TCP friendliness + > QoS >> management is not worth it compared to having adaptable end-systems > and >> overall more bandwidth than needed. >>=20 >> Fully agreed.=20 >>=20 >> Folks who like pictures can take a look at >> https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much > the same >> argument. >>=20 >> Lars >>=20 >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From tme@americafree.tv Tue Nov 16 08:49:57 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962D93A6D0B; Tue, 16 Nov 2010 08:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg0JkQd79wV1; Tue, 16 Nov 2010 08:49:56 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 0C26B3A6D81; Tue, 16 Nov 2010 08:49:56 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 9FB8A93D48A0; Tue, 16 Nov 2010 11:50:39 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <3349FECF788C984BB34176D70A51782F1687808C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Tue, 16 Nov 2010 11:50:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7C3A8DA4-18F3-4AA4-A2F4-325FC2D817DA@americafree.tv> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1687808C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" X-Mailer: Apple Mail (2.1081) Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 16:49:57 -0000 On Nov 12, 2010, at 4:12 AM, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) = wrote: >=20 > You said: >=20 > "Packet prioritization is only of value when the network is full. QoS = is only of interest when BE works badly." >=20 > Then, why on earth ALL ISPs are using QoS in THEIR networks to = guarantee their own VoIP and Broadcast TV services to their customers??? >=20 > QoS is ALWAYS a MUST for ISPs to ensure real-time services at any = moment. Q-HTTP is trying to open up that window to other third parties. >=20 I have three personal / office ISP accounts for Internet access. If any = are offering QOS as a service, they sure haven't told me. (One, the cable company, does do a "walled garden" type solution for IPTV, but I = don't think that that is the type of QOS you are talking about.) =20 Regards Marshall > And about "network state", there are different solutions to implement = this, one includes network state, BUT IT IS NOT THE ONLY ONE. Indeed we = tested one alternative in our lab with actual equipment.... >=20 > Saludos, > Luismi >=20 > -----Mensaje original----- > De: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 > Enviado el: jueves, 11 de noviembre de 2010 21:44 > Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) > CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Mike Hammer = (hmmr); Ingemar Johansson S; Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL = (LUIS MIGUEL) > Asunto: RE: [dispatch] [conex] [httpstreaming] Q-HTTP >=20 > On Thu, 11 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: >=20 >> Service providers are worried about ARPU. It is decreasing becasue = the=20 >> "exaflood" phenomenon. The exponential traffic can not be sustained = by=20 >> the network, with incremental increases in bandwidth. >=20 > I don't get it. Are you saying that because there is more traffic, the = user is paying less money per month? Yes, profit per customer might be = down, but why should traffic volume decrease revenue? >=20 >> These ISP capabilities can be priced to developers/content providers,=20= >> increasing ISP revenues. Capabilities such as location, presence, = billing, security, QoS.... >=20 > I agree that an ISP can be a micropayment provider and also provice = some location information. >=20 >> One of the most important is QoS. If developers can not find=20 >> profitable business Models, innovation is compromised. QoS means a = mix=20 >> of traffic engineering + priorization + etc >=20 > Packet prioritization is only of value when the network is full. QoS = is only of interest when BE works badly. >=20 >> Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP) = to=20 >> enable virtualization of games (like www.onlive.com, but using the=20 >> network instead locating servers at last mille) >=20 > I don't get this either. You can't play an FPS with tens of = milliseconds of network delay, so you need to locate servers close to = the customers to keep latency low, plus you also don't want the access = latency to eat up your latency budget so ADSL and cable goes out the = window anyway, the only thing left is the sub-millisecond latency of = ETTH. >=20 > Btw, I think Q-HTTP is a horrible idea. It seems require a lot of = state in the network. State is expensive. What happened to KISS = principle? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From swmike@swm.pp.se Tue Nov 16 13:52:49 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E573A6808; Tue, 16 Nov 2010 13:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZvokYOgUq2p; Tue, 16 Nov 2010 13:52:49 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 728233A6807; Tue, 16 Nov 2010 13:52:47 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 778EC9C; Tue, 16 Nov 2010 22:53:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 75CD89A; Tue, 16 Nov 2010 22:53:30 +0100 (CET) Date: Tue, 16 Nov 2010 22:53:30 +0100 (CET) From: Mikael Abrahamsson To: Ben Niven-Jenkins In-Reply-To: Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Ingemar Johansson S , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 21:52:49 -0000 On Tue, 16 Nov 2010, Ben Niven-Jenkins wrote: > Your sentence above seems to ignore the backhaul? Which is strange as > the backhaul is a significant proportion of the overall cost and larger > than the cost of the core itself. I don't know what you mean by backhaul, but I guess it's the "distribution" I'm talking about. And it's my firm belief that "backhaul" should "never" be congested. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Tue Nov 16 13:55:23 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 868053A680A; Tue, 16 Nov 2010 13:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3e8l4CCMImb; Tue, 16 Nov 2010 13:55:22 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 9BE903A6807; Tue, 16 Nov 2010 13:55:22 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 54D6E9F; Tue, 16 Nov 2010 22:56:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 51AB99E; Tue, 16 Nov 2010 22:56:06 +0100 (CET) Date: Tue, 16 Nov 2010 22:56:06 +0100 (CET) From: Mikael Abrahamsson To: Ben Niven-Jenkins In-Reply-To: <6631D123-D319-4CF6-B299-FD8CFD17EB0B@niven-jenkins.co.uk> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <002a01cb81e1$40e58740$c2b095c0$@com> <6631D123-D319-4CF6-B299-FD8CFD17EB0B@niven-jenkins.co.uk> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: httpstreaming , conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 21:55:23 -0000 On Tue, 16 Nov 2010, Ben Niven-Jenkins wrote: > Please cite evidence to support this assertion. Are you for real? You're free to say what you want, but I have to "cite evidence"? > At least for the ISPs I have worked with & for the margins are pretty > thin and while Transit/Peering costs are not the largest cost they are > not insignificant. We saw large scale "streaming events", e.g. day long > sports event broadcast on the Internet, had significant (localised) > impact to the Transit costs and if they were permanent (e.g. your > average 1 Mbps / user at peak time) they would have made a significant > impact to the bottom-line. Well then, your experience differs from mine. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Tue Nov 16 13:57:25 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E8B13A680A; Tue, 16 Nov 2010 13:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTlksep2tb06; Tue, 16 Nov 2010 13:57:24 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 82B913A6807; Tue, 16 Nov 2010 13:57:24 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 373A69E; Tue, 16 Nov 2010 22:58:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 35E899A; Tue, 16 Nov 2010 22:58:08 +0100 (CET) Date: Tue, 16 Nov 2010 22:58:08 +0100 (CET) From: Mikael Abrahamsson To: Benjamin Niven-Jenkins In-Reply-To: Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F 16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <663377F3-630B-428F-92CC-775CC63B816B@apple.com> <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: httpstreaming , David Singer , conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 21:57:25 -0000 On Tue, 16 Nov 2010, Benjamin Niven-Jenkins wrote: > Each "subscriber" gets a "fair" allocation of bandwidth but they (or > their ISP via their service bundle) choose how to prioritise packets > within their allocation. The only "fair" allocation is the speed that was sold to the customer. > Everyone's a winner :-) The ISP is the winner because they get away with delivering less than what they promised the customer. The customers are being screwed, they're not winners. -- Mikael Abrahamsson email: swmike@swm.pp.se From ingemar.s.johansson@ericsson.com Tue Nov 16 22:53:03 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C22E3A688E for ; Tue, 16 Nov 2010 22:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.513 X-Spam-Level: X-Spam-Status: No, score=-6.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8xduLApOKta for ; Tue, 16 Nov 2010 22:53:02 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0D3CA3A680C for ; Tue, 16 Nov 2010 22:52:58 -0800 (PST) X-AuditID: c1b4fb39-b7cabae000005002-ed-4ce37bf60d0a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BF.F5.20482.6FB73EC4; Wed, 17 Nov 2010 07:53:43 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.174]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 17 Nov 2010 07:53:42 +0100 From: Ingemar Johansson S To: Steven Blake , Roland Bless Date: Wed, 17 Nov 2010 07:53:41 +0100 Thread-Topic: [conex] Abstract marking and encoding in IPv6 Thread-Index: AcuFo8Nmf3MgVZGbTHynk9iQZ62zNAAfy6Jg Message-ID: References: <4CDD297D.9030204@kit.edu> <4CE1AC4E.5040805@kit.edu> <1289921665.6883.13.camel@tachyon> In-Reply-To: <1289921665.6883.13.camel@tachyon> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 06:53:03 -0000 Thanks for dropping by Steven.=20 Can anyone point to a "101 fastpath vs. slowpath" article that tries to exl= ain with some more detail the issues with fast and slowpath processing ?. M= y personal knowledge is limited to the a book "Network routing" by Mehdi an= d Ramasamy but it does not provide too much details on this subject.=20 /Ingemar > -----Original Message----- > From: Steven Blake [mailto:slblake@petri-meat.com]=20 > Sent: den 16 november 2010 16:34 > To: Roland Bless > Cc: Ingemar Johansson S; conex@ietf.org > Subject: Re: [conex] Abstract marking and encoding in IPv6 >=20 > On Mon, 2010-11-15 at 22:55 +0100, Roland Bless wrote: >=20 > > Hi, > >=20 > > On 15.11.2010 14:21, Ingemar Johansson S wrote: > > > I admit that I may not get the whole picture why packets with=20 > > > hop-by-hop headers are punted to the slow path but I am not sure=20 > > > that it is a broken behavior especially as as the additional=20 > > > complexity caused by the extension header is impossible=20 > to see just=20 > > > by looking at the 3MSBs. So I am not really sure that you=20 > can solve=20 > > > this problem but I will have to leave this to the experts in this=20 > > > area to determine > >=20 > > I'm not a hardware expert either, but I think that it should be=20 > > possible to have a simple multifield match for an extension=20 > header in=20 > > the fast path. I didn't state that looking at the 3MSB (I=20 > assume you=20 > > mean bits > > here) is sufficient. You have to check the next header field value > > + the option type. If option type is "conex" then you may set the > > appropriate value in the option. I think that this can be=20 > easily done=20 > > in the fast path since multifield classifiers and token bucket=20 > > policers can be realized there, too. > >=20 > > > Even if the "general punt to slow path" problem is solved, it is=20 > > > likely that ConEx enabled routers will have to put ConEx=20 > packets in=20 > > > the slow path and this I believe limits the use of ConEx=20 > policing to > >=20 > > I don't think that slow path processing will be necessary. > >=20 > > > relatively low bitrate interfaces, perhaps this is no=20 > problem if the=20 > > > core is overprovisioned, I don't know. > >=20 > > > ConEx marking is special in the sense that the complexity of the > > > ConEx marking can be made very low. If we put the MPLS issue=20 > > > (another > > > problem) aside one can implement a very cheap policer in a=20 > > > high-speed interface just by counting the average ConEx=20 > rate (=3Ddon't=20 > > > care about the packet size). This of course means that a ConEx=20 > > > enabled routher does not need to do too much lookup in=20 > each packet.=20 > > > Use of bits from the flow label field can make this=20 > possible. Other=20 > > > encodings like extension headers and GUT can be more=20 > problematic in this respect. > >=20 > > I doubt that looking for a conex extension header is a very=20 > costly task... >=20 > Adding functionality to fast-path forwarding adds cost (extra=20 > memory/TCAM accesses; extra code in firmware memory). Some (but not > all) fast-path implementations are non-programmable. Don't=20 > underestimate the reluctance of vendors to add additional=20 > functionality to fast-path forwarding. >=20 >=20 > Regards, >=20 > // Steve >=20 > = From swmike@swm.pp.se Tue Nov 16 23:56:26 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97C43A6897; Tue, 16 Nov 2010 23:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzHMDZ3VYkJY; Tue, 16 Nov 2010 23:56:26 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id F055B3A680C; Tue, 16 Nov 2010 23:56:25 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id A5DDC9C; Wed, 17 Nov 2010 08:57:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id A35359A; Wed, 17 Nov 2010 08:57:09 +0100 (CET) Date: Wed, 17 Nov 2010 08:57:09 +0100 (CET) From: Mikael Abrahamsson To: Benjamin Niven-Jenkins In-Reply-To: <297EBB41-64BA-4ED7-9D9A-F074D6B7E5F9@niven-jenkins.co.uk> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <002a01cb81e1$40e58740$c2b095c0$@com> <6631D123-D319-4CF6-B299-FD8CFD17EB0B@niven-jenkins.co.uk> <297EBB41-64BA-4ED7-9D9A-F074D6B7E5F9@niven-jenkins.co.uk> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: httpstreaming , conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 07:56:27 -0000 On Wed, 17 Nov 2010, Benjamin Niven-Jenkins wrote: > My point was that if you look at global transit prices they are > typically a few dollars a Mbps in the west. That pricing is not > universal across the globe. That is true, but the reason for transit prices being high is usually a political problem, not a technical one. No matter of talk about how nice QoS is hides the fact that if you're congesting anything else than the customer port, you're not giving the customer what he or she purchased. Also, the Internet became successful because it adhered to "keep it simple stupid" principle. The suggestions I've seen so far here is anything but simple and usually involves quite intrusive changes in equipment and business models. I totally fail to see how making the network and payment models more complicated will make the network better. Money (capex and opex) should be spent on upgrading capacity and keeping the network simple, not trying to make the impact of too little capacity less noticable. The network that has constrained access bandwidth (for instance mobile networks) already have advanced per-user queuing that assures "fair access" to the media. I would imagine cable networks have the same. I see little reason to implement support for this in end-hosts, end-hosts should be greedy because that's how things work in real life. End-hosts are under the control of the end-user and thus can't be trusted to do "the right thing" when it comes to "fairness". So anyone who wants to underprovision their network need to make sure they have 3GPP style bearer and scheduling concept working in their network to handle how resources are handled, we don't need new mechanisms for this, it's already been available for 10 years. -- Mikael Abrahamsson email: swmike@swm.pp.se From roland.bless@kit.edu Wed Nov 17 00:45:35 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F433A68CE for ; Wed, 17 Nov 2010 00:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7xtf304zbGN for ; Wed, 17 Nov 2010 00:45:34 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 19D403A68B9 for ; Wed, 17 Nov 2010 00:45:33 -0800 (PST) Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps port 25 id 1PIdeU-0004uX-Nj; Wed, 17 Nov 2010 09:46:16 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps port 25 id 1PIdeU-00025s-IT; Wed, 17 Nov 2010 09:46:02 +0100 Received: from vorta.tm.uka.de (roland.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 71DF42FC047; Wed, 17 Nov 2010 09:46:02 +0100 (CET) Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.uka.de (Postfix) with ESMTPS id 5191F341; Wed, 17 Nov 2010 09:46:02 +0100 (CET) Message-ID: <4CE3964A.7000407@kit.edu> Date: Wed, 17 Nov 2010 09:46:02 +0100 From: Roland Bless Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Thunderbird/3.0.10 MIME-Version: 1.0 To: Steven Blake References: <4CDD297D.9030204@kit.edu> <4CE1AC4E.5040805@kit.edu> <1289921665.6883.13.camel@tachyon> In-Reply-To: <1289921665.6883.13.camel@tachyon> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de) X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1289983576.586385000 Cc: Ingemar Johansson S , "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 08:45:35 -0000 Hi Steve, On 16.11.2010 16:34, Steven Blake wrote: > Adding functionality to fast-path forwarding adds cost (extra > memory/TCAM accesses; extra code in firmware memory). Some (but not > all) fast-path implementations are non-programmable. Don't > underestimate the reluctance of vendors to add additional functionality > to fast-path forwarding. I think it's pretty obvious that adding functions (such as conex processing) to the fast path creates cost - even this special flow label hack + conex processing code will create cost. My original point was that some _basic_ header extension processing code should be down in the fast path (like forwarding of non-supported or non-interesting hop-by-hop options) while more complex processing can be surely up in the slow path. So it's better to put some basic header extension processing support into the ASIC before we run into the same trap next time over and over again... Regards, Roland From slblake@petri-meat.com Wed Nov 17 07:21:35 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1506C3A6904 for ; Wed, 17 Nov 2010 07:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iQKb582TDbX for ; Wed, 17 Nov 2010 07:21:34 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 227403A68C3 for ; Wed, 17 Nov 2010 07:21:34 -0800 (PST) Received: from cpe-174-097-227-047.nc.res.rr.com ([174.97.227.47]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1PIjpt-0000kx-Hg; Wed, 17 Nov 2010 10:22:13 -0500 From: Steven Blake To: Ingemar Johansson S In-Reply-To: References: <4CDD297D.9030204@kit.edu> <4CE1AC4E.5040805@kit.edu> <1289921665.6883.13.camel@tachyon> Content-Type: text/plain; charset="UTF-8" Date: Wed, 17 Nov 2010 10:22:16 -0500 Message-ID: <1290007336.24866.11.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 15:21:35 -0000 On Wed, 2010-11-17 at 07:53 +0100, Ingemar Johansson S wrote: > Thanks for dropping by Steven. > > Can anyone point to a "101 fastpath vs. slowpath" article that tries > to exlain with some more detail the issues with fast and slowpath > processing ?. My personal knowledge is limited to the a book "Network > routing" by Mehdi and Ramasamy but it does not provide too much > details on this subject. On boxes that distinguish between "fast" and "slow" path (virtually anything from 1 Gig up in the provider space, and virtually all Ethernet boxes), the "fast path" is implemented in specialized silicon, with access to fast memory (e.g., RLDRAM II, QDR SRAM) and/or TCAM. These devices are programmed either in Verilog (making recompiles *very* expensive) or specialized firmware (e.g., NPUs). Often the NPU firmware is stored on on-chip memory, limiting the amount of forwarding functionality that can be implemented. There is a tight budget of memory cycles per-packet that can allow sustained wire-speed performance. Different NPU architectures are more flexible vis-a-vis trading off packet forwarding rate for functionality. In the case of hard-coded forwarding ASICs, extending "fast path" functionality means replacing linecards. "Slow path" forwarding is implemented in general purpose CPUs. Usually there is a 2-3 order-of-magnitude difference in packet rate between "slow path" and "fast path". The goal is for 99.999% of packets to stay in the "fast path". If use of an IPv6 Hop-by-hop option becomes common, vendors have to implement support for that in the "fast path". But there is a cost to that, and it will take a while to deploy, so you have to be realistic about how easy it is to introduce new Hop-by-hop options that would get used on a non-trivial fraction of packets. Regards, // Steve From richard_woundy@cable.comcast.com Wed Nov 17 08:59:35 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C81263A692A; Wed, 17 Nov 2010 08:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.463 X-Spam-Level: X-Spam-Status: No, score=-108.463 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oteLRyYhRqfM; Wed, 17 Nov 2010 08:59:35 -0800 (PST) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 97E903A6941; Wed, 17 Nov 2010 08:59:34 -0800 (PST) Received: from ([24.40.55.40]) by pacdcimo01.cable.comcast.com with ESMTP with TLS id 5503620.105431181; Wed, 17 Nov 2010 12:00:18 -0500 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%12]) with mapi id 14.01.0255.000; Wed, 17 Nov 2010 12:00:18 -0500 From: "Woundy, Richard" To: Mikael Abrahamsson , Benjamin Niven-Jenkins Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP Thread-Index: AQHLhi0Oh89LDIYhB0GG7XamnkwDvZN15DxA Date: Wed, 17 Nov 2010 17:00:16 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1034F4E@PACDCEXMB05.cable.comcast.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <002a01cb81e1$40e58740$c2b095c0$@com> <6631D123-D319-4CF6-B299-FD8CFD17EB0B@niven-jenkins.co.uk> <297EBB41-64BA-4ED7-9D9A-F074D6B7E5F9@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: httpstreaming , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 16:59:35 -0000 > That is true, but the reason for transit prices being high is usually a p= olitical problem, not a technical one. Just curious -- where is this conversation going? Are we to assume the same= economic and political conditions throughout the world? Personally, I am not convinced that the HTTP streaming "quality of experien= ce" necessarily implies Internet QoS. But I thought we discuss IETF issues = here, not UN issues (or OECD issues). -- Rich -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of M= ikael Abrahamsson Sent: Wednesday, November 17, 2010 2:57 AM To: Benjamin Niven-Jenkins Cc: httpstreaming; conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP On Wed, 17 Nov 2010, Benjamin Niven-Jenkins wrote: > My point was that if you look at global transit prices they are=20 > typically a few dollars a Mbps in the west. That pricing is not=20 > universal across the globe. That is true, but the reason for transit prices being high is usually a=20 political problem, not a technical one. No matter of talk about how nice QoS is hides the fact that if you're=20 congesting anything else than the customer port, you're not giving the=20 customer what he or she purchased. Also, the Internet became successful=20 because it adhered to "keep it simple stupid" principle. The suggestions=20 I've seen so far here is anything but simple and usually involves quite=20 intrusive changes in equipment and business models. I totally fail to see how making the network and payment models more=20 complicated will make the network better. Money (capex and opex) should be= =20 spent on upgrading capacity and keeping the network simple, not trying to=20 make the impact of too little capacity less noticable. The network that has constrained access bandwidth (for instance mobile=20 networks) already have advanced per-user queuing that assures "fair=20 access" to the media. I would imagine cable networks have the same. I see little reason to implement support for this in end-hosts, end-hosts=20 should be greedy because that's how things work in real life. End-hosts=20 are under the control of the end-user and thus can't be trusted to do "the= =20 right thing" when it comes to "fairness". So anyone who wants to underprovision their network need to make sure they= =20 have 3GPP style bearer and scheduling concept working in their network to=20 handle how resources are handled, we don't need new mechanisms for this,=20 it's already been available for 10 years. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Wed Nov 17 12:01:57 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B879F3A6975; Wed, 17 Nov 2010 12:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnBi3nwAqWXE; Wed, 17 Nov 2010 12:01:57 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 73E6B3A695F; Wed, 17 Nov 2010 12:01:55 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 788859C; Wed, 17 Nov 2010 21:02:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 76F509A; Wed, 17 Nov 2010 21:02:40 +0100 (CET) Date: Wed, 17 Nov 2010 21:02:40 +0100 (CET) From: Mikael Abrahamsson To: "conex@ietf.org" In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1034F4E@PACDCEXMB05.cable.comcast.com> Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <002a01cb81e1$40e58740$c2b095c0$@com> <6631D123-D319-4CF6-B299-FD8CFD17EB0B@niven-jenkins.co.uk> <297EBB41-64BA-4ED7-9D9A-F074D6B7E5F9@niven-jenkins.co.uk> <1CA25301D2219F40B3AA37201F0EACD1034F4E@PACDCEXMB05.cable.comcast.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: httpstreaming Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 20:01:57 -0000 On Wed, 17 Nov 2010, Woundy, Richard wrote: > Personally, I am not convinced that the HTTP streaming "quality of > experience" necessarily implies Internet QoS. But I thought we discuss > IETF issues here, not UN issues (or OECD issues). Some people describe core/distribution congestion as a force of nature that should be handled by a bunch of advanced technical means. I don't agree with this problem description, thus I guess it's hard to start to discuss a "solution" because I see "lack of capacity" should be solved by "install more capacity and make sure it can be done cheaply by means of making IP equipment low complexity" instead of "let's solve it by making the Internet more advanced and complicated so we can gracefully handle the advanced complicated network we now don't have the money to build out so it doesn't congest". Since it's next to impossible to quantify the above factors and who is "right" (nobody is, it's a matter of opinion and world view), I guess that's why we're seeing the discussion going all over the place. And I disagree that anything I have said indicates this to be a OECD or UN issue, it's a matter for the national regulators and politicians. -- Mikael Abrahamsson email: swmike@swm.pp.se From stuart.venters@adtran.com Wed Nov 17 12:21:54 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AA833A695F for ; Wed, 17 Nov 2010 12:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGccOPlwqxXD for ; Wed, 17 Nov 2010 12:21:53 -0800 (PST) Received: from p02c12o143.mxlogic.net (p02c12o143.mxlogic.net [208.65.145.76]) by core3.amsl.com (Postfix) with ESMTP id F19043A696C for ; Wed, 17 Nov 2010 12:21:52 -0800 (PST) Received: from unknown [76.164.174.82] (EHLO p02c12o143.mxlogic.net) by p02c12o143.mxlogic.net(mxl_mta-6.8.0-0) with ESMTP id f8934ec4.545bb940.5320.00-587.12433.p02c12o143.mxlogic.net (envelope-from ); Wed, 17 Nov 2010 13:22:39 -0700 (MST) X-MXL-Hash: 4ce4398f31134350-8e2ef2e7d32ffcec0b3a37af3076b0d3dcbc6931 Received: from unknown [76.164.174.82] by p02c12o143.mxlogic.net(mxl_mta-6.8.0-0) with SMTP id 78934ec4.0.5262.00-316.12279.p02c12o143.mxlogic.net (envelope-from ); Wed, 17 Nov 2010 13:22:35 -0700 (MST) X-MXL-Hash: 4ce4398b38f7a70f-62db5988946dbec45df165cb33ea13a12ecda2fa Received: from corp-exfr2.corp.adtran.com (172.23.101.22) by ex-hc3.corp.adtran.com (172.22.50.73) with Microsoft SMTP Server id 14.1.255.0; Wed, 17 Nov 2010 14:22:30 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr2.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Nov 2010 14:22:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Nov 2010 14:22:29 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D7179FB834@EXV1.corp.adtran.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuGkmh7X4ivRYZjSzmP10AKwA8g+QAAV4hw From: STUART VENTERS To: Mikael Abrahamsson X-OriginalArrivalTime: 17 Nov 2010 20:22:30.0454 (UTC) FILETIME=[28E50D60:01CB8695] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010110201)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.82] X-AnalysisOut: [v=1.0 c=1 a=zCmgScRMnMUA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-] X-AnalysisOut: [IA:10 a=J+LXdEUA8t8MtBPt16/Qbg==:17 a=48vgC7mUAAAA:8 a=V4B] X-AnalysisOut: [WB7nwYyUl7sa-u-QA:9 a=WTo0IGAfOkVIE5ObsNcA:7 a=fE0li-bv5UN] X-AnalysisOut: [51yZTPO_7oLWBrkQA:4 a=wPNLvfGTeEIA:10 a=46Mm6vj11UkA:10 a=] X-AnalysisOut: [lZB815dzVvQA:10] Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 20:21:54 -0000 In your view of how things work, if some congestion is not a part of expected behavior of the Internet = core,=20 then what are the congestion control parts of TCP for? -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org]On Behalf Of Mikael Abrahamsson Sent: Wednesday, November 17, 2010 2:03 PM To: conex@ietf.org Cc: httpstreaming Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP On Wed, 17 Nov 2010, Woundy, Richard wrote: > Personally, I am not convinced that the HTTP streaming "quality of=20 > experience" necessarily implies Internet QoS. But I thought we discuss = > IETF issues here, not UN issues (or OECD issues). Some people describe core/distribution congestion as a force of nature=20 that should be handled by a bunch of advanced technical means. I don't=20 agree with this problem description, thus I guess it's hard to start to=20 discuss a "solution" because I see "lack of capacity" should be solved = by=20 "install more capacity and make sure it can be done cheaply by means of=20 making IP equipment low complexity" instead of "let's solve it by making = the Internet more advanced and complicated so we can gracefully handle = the=20 advanced complicated network we now don't have the money to build out so = it doesn't congest". Since it's next to impossible to quantify the above factors and who is=20 "right" (nobody is, it's a matter of opinion and world view), I guess=20 that's why we're seeing the discussion going all over the place. And I disagree that anything I have said indicates this to be a OECD or = UN=20 issue, it's a matter for the national regulators and politicians. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ conex mailing list conex@ietf.org https://www.ietf.org/mailman/listinfo/conex From tme@americafree.tv Wed Nov 17 13:51:38 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259F23A6781; Wed, 17 Nov 2010 13:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.603 X-Spam-Level: X-Spam-Status: No, score=-101.603 tagged_above=-999 required=5 tests=[AWL=0.996, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oBs7eeYQ4Dk; Wed, 17 Nov 2010 13:51:37 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 3060C3A6767; Wed, 17 Nov 2010 13:51:37 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id E2AC793F3B48; Wed, 17 Nov 2010 16:52:22 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: Date: Wed, 17 Nov 2010 16:52:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <002a01cb81e1$40e58740$c2b095c0$@com> <6631D123-D319-4CF6-B299-FD8CFD17EB0B@niven-jenkins.co.uk> <297EBB41-64BA-4ED7-9D9A-F074D6B7E5F9@niven-jenkins.co.uk> <1CA25301D2219F40B3AA37201F0EACD1034F4E@PACDCEXMB05.cable.comcast.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1081) Cc: httpstreaming , "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 21:51:38 -0000 On Nov 17, 2010, at 3:02 PM, Mikael Abrahamsson wrote: > On Wed, 17 Nov 2010, Woundy, Richard wrote: >=20 >> Personally, I am not convinced that the HTTP streaming "quality of = experience" necessarily implies Internet QoS. But I thought we discuss = IETF issues here, not UN issues (or OECD issues). >=20 > Some people describe core/distribution congestion as a force of nature = that should be handled by a bunch of advanced technical means. I don't = agree with this problem description, thus I guess it's hard to start to = discuss a "solution" because I see "lack of capacity" should be solved = by "install more capacity and make sure it can be done cheaply by means = of making IP equipment low complexity" instead of "let's solve it by = making the Internet more advanced and complicated so we can gracefully = handle the advanced complicated network we now don't have the money to = build out so it doesn't congest". This is of course an "age-old" (well, 20-30 years) religious = disagreement. Those that come out of the circuit switched telco world = tend to think, QOS. Those that come out of the packet switched Internet = world tend to think "provision properly." I don't expect to see such = arguments cease in my lifetime.=20 Regards (and all I will say on this topic on this list) Marshall >=20 > Since it's next to impossible to quantify the above factors and who is = "right" (nobody is, it's a matter of opinion and world view), I guess = that's why we're seeing the discussion going all over the place. >=20 > And I disagree that anything I have said indicates this to be a OECD = or UN issue, it's a matter for the national regulators and politicians. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From swmike@swm.pp.se Wed Nov 17 21:07:13 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C503A67AE for ; Wed, 17 Nov 2010 21:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx6AeHDSRMF8 for ; Wed, 17 Nov 2010 21:07:12 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 39EE23A677E for ; Wed, 17 Nov 2010 21:07:11 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B89FB9C; Thu, 18 Nov 2010 06:07:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B59649A; Thu, 18 Nov 2010 06:07:54 +0100 (CET) Date: Thu, 18 Nov 2010 06:07:54 +0100 (CET) From: Mikael Abrahamsson To: STUART VENTERS In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D7179FB834@EXV1.corp.adtran.com> Message-ID: References: <8F242B230AD6474C8E7815DE0B4982D7179FB834@EXV1.corp.adtran.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 05:07:14 -0000 On Wed, 17 Nov 2010, STUART VENTERS wrote: > if some congestion is not a part of expected behavior of the Internet > core, > then what are the congestion control parts of TCP for? If you have a gig connected computer on a LAN connected to an ADSL line, of course there is going to be congestion, but it's on the access line, not in the core. -- Mikael Abrahamsson email: swmike@swm.pp.se From toby@moncaster.com Thu Nov 18 01:33:00 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931B83A677D for ; Thu, 18 Nov 2010 01:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-Q+f0e56OPw for ; Thu, 18 Nov 2010 01:32:59 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 5F8DD3A680F for ; Thu, 18 Nov 2010 01:32:59 -0800 (PST) Received: from TobysHP (host86-149-152-36.range86-149.btcentralplus.com [86.149.152.36]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MS0Vu-1OvGdz3Jwg-00TFLL; Thu, 18 Nov 2010 10:33:34 +0100 From: "Toby Moncaster" To: "'Mikael Abrahamsson'" , "'STUART VENTERS'" References: <8F242B230AD6474C8E7815DE0B4982D7179FB834@EXV1.corp.adtran.com> In-Reply-To: Date: Thu, 18 Nov 2010 09:33:32 -0000 Message-ID: <000301cb8703$ab2177a0$016466e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcuG3pYkMVc0k430S8ia8N+oDjntDQAIy3Qg Content-Language: en-gb X-Provags-ID: V02:K0:EeSHJPx9RwbKtMZqOQEVCrKPBMCQ3BagH1DTf5IBG0I raq65ZM4oXfthrumcZPYCz3xfsbG5RTj79fwxUVNf/iXBYgn+M bxUha+m1jT+vSh0SM4289tBrRl7xKMcWb1PKLN9vdMuf6AWhUw 3//pcjYhpkod21Nt9NLT8uOUJ6i4SlqRETnaCDgb3Ex9Cqkpli qGVX/iraVpfRpfpfpxpVGUKQfOiu4LXrWV2QEAFvUw= Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 09:33:01 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mikael Abrahamsson > Sent: 18 November 2010 05:08 > To: STUART VENTERS > Cc: conex@ietf.org > Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP > > On Wed, 17 Nov 2010, STUART VENTERS wrote: > > > if some congestion is not a part of expected behavior of the > Internet > > core, > > then what are the congestion control parts of TCP for? > > If you have a gig connected computer on a LAN connected to an ADSL > line, > of course there is going to be congestion, but it's on the access line, > not in the core. Just to check, can you define what you mean by "access" and "core"? I get the impression that there is a bit of confusion in some people's minds as to where you place the backhaul (which many of us assume is the location of most congestion). A question for you - if we are going towards a world where the standard domestic broadband connection runs at 100s of Mbps (e.g. FTTH), how fast do you feel the core has to go to ensure your 0% congestion target? My understanding has always been that a key aim of congestion control is to make efficient use of available capacity by finding the point at which it just starts to congest before backing off sufficiently to let someone else come in and share that capacity. I take it your view of the network assumes this congestion signal still comes from the access so users are, in effect, limited by the capacity constraints in their access. To me (as an engineer by training, not a computer scientist), it would seem inherently wrong to have a network that is not operating at a reasonable percentage of capacity - in effect if you have to significantly over-provision to remove congestion, you are wasting that capacity. BTW, I am all for keeping the real core simple - I think there is already a lot of complexity that is unnecessary. Complexity should be pushed towards the edges where possible... I am pretty confident that you can enable ConEx without needing to add complexity to routers (unless you want routers that are also intending to monitor the ConEx information). Toby > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Thu Nov 18 03:30:39 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2309A3A682F for ; Thu, 18 Nov 2010 03:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5bilTsiHnpm for ; Thu, 18 Nov 2010 03:30:38 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id A279D3A6824 for ; Thu, 18 Nov 2010 03:30:37 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 36F589E; Thu, 18 Nov 2010 12:31:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3559A9C; Thu, 18 Nov 2010 12:31:23 +0100 (CET) Date: Thu, 18 Nov 2010 12:31:23 +0100 (CET) From: Mikael Abrahamsson To: Toby Moncaster In-Reply-To: <000301cb8703$ab2177a0$016466e0$@com> Message-ID: References: <8F242B230AD6474C8E7815DE0B4982D7179FB834@EXV1.corp.adtran.com> <000301cb8703$ab2177a0$016466e0$@com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 11:30:39 -0000 On Thu, 18 Nov 2010, Toby Moncaster wrote: > Just to check, can you define what you mean by "access" and "core"? I get > the impression that there is a bit of confusion in some people's minds as to > where you place the backhaul (which many of us assume is the location of > most congestion). "access" is the line/port that terminates in my apartment. It's where me as a customer is "alone" with just my own traffic. Core/distribution/aggregation is everything else. > A question for you - if we are going towards a world where the standard > domestic broadband connection runs at 100s of Mbps (e.g. FTTH), how fast do > you feel the core has to go to ensure your 0% congestion target? Probably multiples of 10G and 100G respectively. In ETTH deployment, you need gig between the active ethernet switches, you might need 2 bundled GigE or 10GE between them if you're running lots of multicast TV streams for Cable IPTV. > I take it your view of the network assumes this congestion signal still > comes from the access so users are, in effect, limited by the capacity > constraints in their access. Correct. They have purchased a capacity and they should have that capacity available to them at "all" times. > To me (as an engineer by training, not a computer scientist), it would seem > inherently wrong to have a network that is not operating at a reasonable > percentage of capacity - in effect if you have to significantly > over-provision to remove congestion, you are wasting that capacity. No, the sweet spot is to reach 99% utilization of the core/aggregation network at peak. No unique customer can detect any core congestion, but you're running it close to full at peak. This is provisioning "right". This also means that having 100 customers with 10meg per second on a docsis 2 network is most likely not going to work, because it's going to congest because you only need a few people using it at full speed at one time for the capacity to not be enough. So the problem with the above isn't that some people are using an "unfair" amount of bw, it's that you're selling too much bw on a network technology that is not good enough for the job. Either you lower the customer bw or you upgrade the network. To congest it is the same thing as selling "300 gram grilled strip loin" but delivering a hamburger because "you couldn't afford to procure the ingredients but you still wanted to be competitive in the market". If you can't deliver 10 meg to the customer, don't sell 10 meg. It's that simple. What the IETF should focus on is to create mechanisms where the end users can detect trickery from the ISPs and pressure them to actually deliver what they have sold, not to help the ISPs to hide this. I understand this is not "sexy", but it's the right thing to do. -- Mikael Abrahamsson email: swmike@swm.pp.se From stuart.venters@adtran.com Thu Nov 18 06:09:19 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EF8E3A67FF for ; Thu, 18 Nov 2010 06:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FRT_SOMA2=2.199, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB33i5SJFChM for ; Thu, 18 Nov 2010 06:09:18 -0800 (PST) Received: from p02c11o143.mxlogic.net (p02c11o143.mxlogic.net [208.65.144.76]) by core3.amsl.com (Postfix) with ESMTP id C1BE63A67E7 for ; Thu, 18 Nov 2010 06:09:17 -0800 (PST) Received: from unknown [76.164.174.83] (EHLO p02c11o143.mxlogic.net) by p02c11o143.mxlogic.net(mxl_mta-6.8.0-0) with ESMTP id db335ec4.65d38940.13911.00-589.31324.p02c11o143.mxlogic.net (envelope-from ); Thu, 18 Nov 2010 07:10:05 -0700 (MST) X-MXL-Hash: 4ce533bd4e62302f-14d6cb7ee53805b8a3b4f163392ed5b68d9a60f4 Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c11o143.mxlogic.net(mxl_mta-6.8.0-0) over TLS secured channel with ESMTP id 7b335ec4.0.13889.00-393.31267.p02c11o143.mxlogic.net (envelope-from ); Thu, 18 Nov 2010 07:10:02 -0700 (MST) X-MXL-Hash: 4ce533ba3d2ac179-68da76973b03d823d300bd491e00786c2eb9e05b Received: from corp-exfr1.corp.adtran.com (172.23.101.21) by ex-hc2.corp.adtran.com (172.22.50.75) with Microsoft SMTP Server id 14.1.255.0; Thu, 18 Nov 2010 08:09:59 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr1.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Nov 2010 08:09:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB872A.48420BDC" Date: Thu, 18 Nov 2010 08:09:58 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D719E654D7@EXV1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuG3pEV7YDpTLpaQW6RuzVDK9WhngASq5LY References: <8F242B230AD6474C8E7815DE0B4982D7179FB834@EXV1.corp.adtran.com> From: STUART VENTERS To: Mikael Abrahamsson X-OriginalArrivalTime: 18 Nov 2010 14:09:59.0077 (UTC) FILETIME=[48D95550:01CB872A] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010111701)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] X-AnalysisOut: [v=1.0 c=1 a=zCmgScRMnMUA:10 a=BLceEmwcHowA:10 a=5zDNsY1we+] X-AnalysisOut: [1mvVcp/5+1jQ==:17 a=48vgC7mUAAAA:8 a=Ah9V7MFdJqu6jjzw4JcA:] X-AnalysisOut: [9 a=G5odkt1skOFEU6-koyZLq2vp1lQA:4 a=wPNLvfGTeEIA:10 a=46M] X-AnalysisOut: [m6vj11UkA:10 a=lZB815dzVvQA:10 a=nzP5d3yE6IHgUz6Mnr0A:9 a=] X-AnalysisOut: [-Q3ZHqLtqvkcER24lScA:7 a=YyzHjvAORMJCAOF2dbLryR0HCfwA:4] Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 14:09:19 -0000 ------_=_NextPart_001_01CB872A.48420BDC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok, so Mr. Gig and Mr. Adsl are communicating and TCP is only there to = prevent congestion on the access ports. So Mr. Gig and ADSL can do send any rate of packets their access will = permit between each other and not affect anybody else in the Internet. If this is all TCP is for, then why does it need the backoff mechanism? (Seems liek a simple acknowledge window like X.25 would have been = sufficient.) -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Wed 11/17/2010 11:07 PM To: STUART VENTERS Cc: conex@ietf.org Subject: RE: [conex] [httpstreaming] [dispatch] Q-HTTP =20 On Wed, 17 Nov 2010, STUART VENTERS wrote: > if some congestion is not a part of expected behavior of the Internet = > core, > then what are the congestion control parts of TCP for? If you have a gig connected computer on a LAN connected to an ADSL line, = of course there is going to be congestion, but it's on the access line,=20 not in the core. --=20 Mikael Abrahamsson email: swmike@swm.pp.se ------_=_NextPart_001_01CB872A.48420BDC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [conex] [httpstreaming] [dispatch] Q-HTTP

Ok, so Mr. Gig and Mr. Adsl are communicating and TCP = is only there to prevent congestion on the access ports.

So Mr. Gig and ADSL can do send any rate of packets their access will = permit between each other and not affect anybody else in the = Internet.

If this is all TCP is for, then why does it need the backoff = mechanism?
   (Seems liek a simple acknowledge window like X.25 would = have been sufficient.)




-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
Sent: Wed 11/17/2010 11:07 PM
To: STUART VENTERS
Cc: conex@ietf.org
Subject: RE: [conex] [httpstreaming]  = [dispatch]       Q-HTTP

On Wed, 17 Nov 2010, STUART VENTERS wrote:

>  if some congestion is not a part of expected behavior of the = Internet
> core,
>    then what are the congestion control parts of TCP = for?

If you have a gig connected computer on a LAN connected to an ADSL = line,
of course there is going to be congestion, but it's on the access = line,
not in the core.

--
Mikael Abrahamsson    email: swmike@swm.pp.se

------_=_NextPart_001_01CB872A.48420BDC-- From swmike@swm.pp.se Thu Nov 18 06:31:09 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819BC3A680C for ; Thu, 18 Nov 2010 06:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJ5vUOwusRyT for ; Thu, 18 Nov 2010 06:31:07 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id D61C03A6832 for ; Thu, 18 Nov 2010 06:31:06 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C0A929C; Thu, 18 Nov 2010 15:31:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BF3D29A; Thu, 18 Nov 2010 15:31:52 +0100 (CET) Date: Thu, 18 Nov 2010 15:31:52 +0100 (CET) From: Mikael Abrahamsson To: STUART VENTERS In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D719E654D7@EXV1.corp.adtran.com> Message-ID: References: <8F242B230AD6474C8E7815DE0B4982D7179FB834@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654D7@EXV1.corp.adtran.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 14:31:09 -0000 On Thu, 18 Nov 2010, STUART VENTERS wrote: > If this is all TCP is for, then why does it need the backoff mechanism? I see little reason to remove existing functionality. Do you? -- Mikael Abrahamsson email: swmike@swm.pp.se From stuart.venters@adtran.com Thu Nov 18 07:26:26 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFB43A6827 for ; Thu, 18 Nov 2010 07:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.95 X-Spam-Level: X-Spam-Status: No, score=-4.95 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, FRT_SOMA2=2.199, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id np6BVkEXrgZK for ; Thu, 18 Nov 2010 07:26:25 -0800 (PST) Received: from p02c12o147.mxlogic.net (p02c12o147.mxlogic.net [208.65.145.80]) by core3.amsl.com (Postfix) with ESMTP id 0D3843A67AF for ; Thu, 18 Nov 2010 07:26:24 -0800 (PST) Received: from unknown [76.164.174.83] (EHLO p02c12o147.mxlogic.net) by p02c12o147.mxlogic.net(mxl_mta-6.8.0-0) with ESMTP id 1d545ec4.62475940.12130.00-595.26395.p02c12o147.mxlogic.net (envelope-from ); Thu, 18 Nov 2010 08:27:13 -0700 (MST) X-MXL-Hash: 4ce545d10822974b-f64d92b7dbaf5de63b1c7f403a911665fa16a723 Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c12o147.mxlogic.net(mxl_mta-6.8.0-0) over TLS secured channel with ESMTP id 8c545ec4.0.12022.00-326.26125.p02c12o147.mxlogic.net (envelope-from ); Thu, 18 Nov 2010 08:27:06 -0700 (MST) X-MXL-Hash: 4ce545ca7b477eef-38a500f8433d499d088d9f5217633b07a811f73a Received: from corp-exfr1.corp.adtran.com (172.23.101.21) by ex-hc2.corp.adtran.com (172.22.50.75) with Microsoft SMTP Server id 14.1.255.0; Thu, 18 Nov 2010 09:26:42 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr1.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Nov 2010 09:26:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Nov 2010 09:26:42 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuHLVnFFu6G/yhLR6GivsMni10tQAABODgQ From: STUART VENTERS To: Mikael Abrahamsson X-OriginalArrivalTime: 18 Nov 2010 15:26:42.0572 (UTC) FILETIME=[00BEECC0:01CB8735] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010111701)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.83] X-AnalysisOut: [v=1.0 c=1 a=zCmgScRMnMUA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-] X-AnalysisOut: [IA:10 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=dFlwrJkZfQdM6z9sKBcA] X-AnalysisOut: [:9 a=gmwCBViRRXNyC2fcYSBm9eUmq8kA:4 a=wPNLvfGTeEIA:10] Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 15:26:26 -0000 Agreed, for the purpose here talking about removing backoff from TCP = would be an unnecessary diversion. I'm curious as to your thought on why backoff was put there in the first = place? Stuart, I see little reason to remove existing functionality. Do you? Mikael Mikael, Ok, so Mr. Gig and Mr. Adsl are communicating and TCP is only there to = prevent congestion on the access ports. So Mr. Gig and ADSL can do send any rate of packets their access will = permit between each other and not affect anybody else in the Internet. If this is all TCP is for, then why does it need the backoff mechanism? (Seems like a simple acknowledge window like X.25 would have been = sufficient.) Stuart Stuart =20 On Wed, 17 Nov 2010, STUART VENTERS wrote: > if some congestion is not a part of expected behavior of the Internet = > core, > then what are the congestion control parts of TCP for? If you have a gig connected computer on a LAN connected to an ADSL line, = of course there is going to be congestion, but it's on the access line,=20 not in the core. Mikael From Internet-Drafts@ietf.org Thu Nov 18 09:00:02 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A5A3A689C; Thu, 18 Nov 2010 09:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.287 X-Spam-Level: X-Spam-Status: No, score=-102.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmIwsWAr8VfH; Thu, 18 Nov 2010 09:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F5C03A688B; Thu, 18 Nov 2010 09:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101118170001.6076.92944.idtracker@localhost> Date: Thu, 18 Nov 2010 09:00:01 -0800 Cc: conex@ietf.org Subject: [conex] I-D ACTION:draft-ietf-conex-concepts-uses-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion Exposure Working Group of the IETF. Title : ConEx Concepts and Use Cases Author(s) : B. Briscoe, R. Woundy, T. Moncaster, J. Leslie Filename : draft-ietf-conex-concepts-uses-00.txt Pages : 19 Date : 2010-11-15 Internet Service Providers (operators) are facing problems where localized congestion prevents full utilization of the path between sender and receiver at today's "broadband" speeds. Operators desire to control this congestion, which often appears to be caused by a small number of users consuming a large amount of bandwidth. Building out more capacity along all of the path to handle this congestion can be expensive and may not result in improvements for all users so network operators have sought other ways to manage congestion. The current mechanisms all suffer from difficulty measuring the congestion (as distinguished from the total traffic). The ConEx Working Group is designing a mechanism to make congestion along any path visible at the Internet Layer. This document describes example cases where this mechanism would be useful. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-conex-concepts-uses-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-18085540.I-D@ietf.org> --NextPart-- From swmike@swm.pp.se Thu Nov 18 15:42:47 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A34FA3A68CF for ; Thu, 18 Nov 2010 15:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvteRzHrRBo6 for ; Thu, 18 Nov 2010 15:42:46 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id A44473A68C2 for ; Thu, 18 Nov 2010 15:42:45 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 10E1F9C; Fri, 19 Nov 2010 00:43:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0F7829A; Fri, 19 Nov 2010 00:43:32 +0100 (CET) Date: Fri, 19 Nov 2010 00:43:32 +0100 (CET) From: Mikael Abrahamsson To: STUART VENTERS In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> Message-ID: References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 23:42:47 -0000 On Thu, 18 Nov 2010, STUART VENTERS wrote: > I'm curious as to your thought on why backoff was put there in the first > place? Because it was and is needed, probably. What is your point? -- Mikael Abrahamsson email: swmike@swm.pp.se From stuart.venters@adtran.com Thu Nov 18 17:40:17 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01C43A6912 for ; Thu, 18 Nov 2010 17:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.733, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvJQ8Z4Xd9RT for ; Thu, 18 Nov 2010 17:40:16 -0800 (PST) Received: from p02c11o147.mxlogic.net (p02c11o147.mxlogic.net [208.65.144.80]) by core3.amsl.com (Postfix) with ESMTP id A6BC73A6917 for ; Thu, 18 Nov 2010 17:40:16 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO p02c11o147.mxlogic.net) by p02c11o147.mxlogic.net(mxl_mta-6.8.0-0) with ESMTP id 1b5d5ec4.65371940.50974.00-525.117327.p02c11o147.mxlogic.net (envelope-from ); Thu, 18 Nov 2010 18:41:05 -0700 (MST) X-MXL-Hash: 4ce5d5b167422b90-601450109a209ad4e0440053b0fd4b409fef6d84 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c11o147.mxlogic.net(mxl_mta-6.8.0-0) over TLS secured channel with ESMTP id 9a5d5ec4.0.50955.00-383.117292.p02c11o147.mxlogic.net (envelope-from ); Thu, 18 Nov 2010 18:41:00 -0700 (MST) X-MXL-Hash: 4ce5d5ac0feb80a6-a3c49c1f458a4e54e7de0b14b27233fc46ff6c38 Received: from corp-exfr2.corp.adtran.com (172.23.101.22) by ex-hc1.corp.adtran.com (172.22.50.71) with Microsoft SMTP Server id 14.1.255.0; Thu, 18 Nov 2010 19:40:51 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr2.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Nov 2010 19:40:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB878A.CBF13EF0" Date: Thu, 18 Nov 2010 19:36:27 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuHemqzSajCA7t+RV61BB55/hl8RwAD8RZ5 References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> From: STUART VENTERS To: Mikael Abrahamsson X-OriginalArrivalTime: 19 Nov 2010 01:40:51.0171 (UTC) FILETIME=[CC38EB30:01CB878A] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010111701)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] X-AnalysisOut: [v=1.0 c=1 a=zCmgScRMnMUA:10 a=BLceEmwcHowA:10 a=0XgpNN2/4a] X-AnalysisOut: [34ymu16SVwsQ==:17 a=48vgC7mUAAAA:8 a=KJBl3fXQhxm60yDWleUA:] X-AnalysisOut: [9 a=D7wBDHDVZO1skXLSKvyy_44o0vUA:4 a=wPNLvfGTeEIA:10 a=46M] X-AnalysisOut: [m6vj11UkA:10 a=lZB815dzVvQA:10 a=zSP-MzUBPCzpgvbDOvIA:7 a=] X-AnalysisOut: [7c95uEu0TStNuUXWQafFsyRHD7MA:4] Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 01:40:17 -0000 ------_=_NextPart_001_01CB878A.CBF13EF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was thinking it might have been added to permit congestion collapse = between unrelated traffic. As in traffic which comes from and goes to unrelated access ports. If this is so, then it would say that congestion in the core is = nothing new. -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Thu 11/18/2010 5:43 PM To: STUART VENTERS Cc: conex@ietf.org Subject: RE: [conex] [httpstreaming] [dispatch] Q-HTTP =20 On Thu, 18 Nov 2010, STUART VENTERS wrote: > I'm curious as to your thought on why backoff was put there in the = first=20 > place? Because it was and is needed, probably. What is your point? --=20 Mikael Abrahamsson email: swmike@swm.pp.se ------_=_NextPart_001_01CB878A.CBF13EF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [conex] [httpstreaming] [dispatch] Q-HTTP

I was thinking it might have been added to permit = congestion collapse between unrelated traffic.
 As in traffic which comes from and goes to unrelated access = ports.
  If this is so, then it would say that congestion in the core is = nothing new.


-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
Sent: Thu 11/18/2010 5:43 PM
To: STUART VENTERS
Cc: conex@ietf.org
Subject: RE: [conex] [httpstreaming]  = [dispatch]       Q-HTTP

On Thu, 18 Nov 2010, STUART VENTERS wrote:

> I'm curious as to your thought on why backoff was put there in the = first
> place?

Because it was and is needed, probably. What is your point?

--
Mikael Abrahamsson    email: swmike@swm.pp.se

------_=_NextPart_001_01CB878A.CBF13EF0-- From swmike@swm.pp.se Thu Nov 18 22:34:38 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEAAA3A68A8 for ; Thu, 18 Nov 2010 22:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0p+sgBtCA8Ql for ; Thu, 18 Nov 2010 22:34:37 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 77DE23A67D1 for ; Thu, 18 Nov 2010 22:34:37 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 757869C; Fri, 19 Nov 2010 07:35:23 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 74EA89A; Fri, 19 Nov 2010 07:35:23 +0100 (CET) Date: Fri, 19 Nov 2010 07:35:23 +0100 (CET) From: Mikael Abrahamsson To: STUART VENTERS In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> Message-ID: References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 06:34:39 -0000 On Thu, 18 Nov 2010, STUART VENTERS wrote: > If this is so, then it would say that congestion in the core is nothing new. Of course this is nothing new, it's been around since the inception of packet networks that there are a lot of flows that compete, you get the same thing if you have multiple TCP flows from the same machine or if the customer has multiple machines in his home, and of course TCP should be able to handle this gracefully. Again, I don't understand the relevance of this in this discussion. -- Mikael Abrahamsson email: swmike@swm.pp.se From stuart.venters@adtran.com Fri Nov 19 04:42:27 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670F73A6830 for ; Fri, 19 Nov 2010 04:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zixyoKf-mZNP for ; Fri, 19 Nov 2010 04:42:26 -0800 (PST) Received: from p02c11o145.mxlogic.net (p02c11o145.mxlogic.net [208.65.144.78]) by core3.amsl.com (Postfix) with ESMTP id 3EE023A6828 for ; Fri, 19 Nov 2010 04:42:26 -0800 (PST) Received: from unknown [76.164.174.81] (EHLO p02c11o145.mxlogic.net) by p02c11o145.mxlogic.net(mxl_mta-6.8.0-0) with ESMTP id 4e076ec4.60434940.136676.00-537.281310.p02c11o145.mxlogic.net (envelope-from ); Fri, 19 Nov 2010 05:43:16 -0700 (MST) X-MXL-Hash: 4ce670e4073dbdf0-9a0c74a2a6e6738706358c69abf08bdc4f657441 Received: from unknown [76.164.174.81] (EHLO ex-hc1.corp.adtran.com) by p02c11o145.mxlogic.net(mxl_mta-6.8.0-0) over TLS secured channel with ESMTP id ed076ec4.0.136668.00-222.281288.p02c11o145.mxlogic.net (envelope-from ); Fri, 19 Nov 2010 05:43:13 -0700 (MST) X-MXL-Hash: 4ce670e162bd3cb8-d0864f55ee5c58a1b9462f093f49ace354e6b265 Received: from corp-exfr2.corp.adtran.com (172.23.101.22) by ex-hc1.corp.adtran.com (172.22.50.71) with Microsoft SMTP Server id 14.1.255.0; Fri, 19 Nov 2010 06:43:09 -0600 Received: from EXV1.corp.adtran.com ([172.22.48.215]) by corp-exfr2.corp.adtran.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Nov 2010 06:43:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB87E7.51DD4F8C" Date: Fri, 19 Nov 2010 06:43:09 -0600 Message-ID: <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuHs/QQaXWGDhvVQ6KahAueYiQo8wAMVj66 References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> From: STUART VENTERS To: Mikael Abrahamsson X-OriginalArrivalTime: 19 Nov 2010 12:43:09.0497 (UTC) FILETIME=[521C4290:01CB87E7] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010111701)] X-MAIL-FROM: X-SOURCE-IP: [76.164.174.81] X-AnalysisOut: [v=1.0 c=1 a=zCmgScRMnMUA:10 a=BLceEmwcHowA:10 a=0XgpNN2/4a] X-AnalysisOut: [34ymu16SVwsQ==:17 a=48vgC7mUAAAA:8 a=ASZQ1kHTbEITkP2u7zsA:] X-AnalysisOut: [9 a=5bIE4vME1AO2-3Jr4HPVeFVcXOsA:4 a=wPNLvfGTeEIA:10 a=46M] X-AnalysisOut: [m6vj11UkA:10 a=lZB815dzVvQA:10 a=JmTnZPgnuom9-HmbRNEA:7 a=] X-AnalysisOut: [MKkSitZ0J-bkMM94DlFgQ8tY_HQA:4] Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Nov 2010 12:42:27 -0000 ------_=_NextPart_001_01CB87E7.51DD4F8C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well if core congestion has been around since when TCP was created, why whould you expect Mr.Gig and Mr Adsl not to encounter some. In other words I don't see the leap from the ISP sold me the BW so I want it to here's a plan for actually building a practical core to provide it. I don't think I would like for the ISP to limit my access speed to what = would give me a 95% congestion free packet path. (If they did they on average, I would run much slower with current = economics.) -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Fri 11/19/2010 12:35 AM To: STUART VENTERS Cc: conex@ietf.org Subject: RE: [conex] [httpstreaming] [dispatch] Q-HTTP =20 On Thu, 18 Nov 2010, STUART VENTERS wrote: > If this is so, then it would say that congestion in the core is = nothing new. Of course this is nothing new, it's been around since the inception of=20 packet networks that there are a lot of flows that compete, you get the=20 same thing if you have multiple TCP flows from the same machine or if = the=20 customer has multiple machines in his home, and of course TCP should be=20 able to handle this gracefully. Again, I don't understand the relevance of this in this discussion. --=20 Mikael Abrahamsson email: swmike@swm.pp.se ------_=_NextPart_001_01CB87E7.51DD4F8C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [conex] [httpstreaming] [dispatch] Q-HTTP

Well if core congestion has been around since when TCP = was created,
  why whould you expect Mr.Gig and Mr Adsl not to encounter = some.

In other words I don't see the leap
  from the ISP sold me the BW so I want it
  to here's a plan for actually building a practical core to = provide it.

I don't think I would like for the ISP to limit my access speed to what = would give me a 95% congestion free packet path.
   (If they did they on average, I would run much slower with = current economics.)


-----Original Message-----
From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
Sent: Fri 11/19/2010 12:35 AM
To: STUART VENTERS
Cc: conex@ietf.org
Subject: RE: [conex] [httpstreaming]  = [dispatch]       Q-HTTP

On Thu, 18 Nov 2010, STUART VENTERS wrote:

>  If this is so, then it would say that congestion in the core = is nothing new.

Of course this is nothing new, it's been around since the inception = of
packet networks that there are a lot of flows that compete, you get = the
same thing if you have multiple TCP flows from the same machine or if = the
customer has multiple machines in his home, and of course TCP should = be
able to handle this gracefully.

Again, I don't understand the relevance of this in this discussion.

--
Mikael Abrahamsson    email: swmike@swm.pp.se

------_=_NextPart_001_01CB87E7.51DD4F8C-- From swmike@swm.pp.se Fri Nov 19 21:31:14 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D885F3A695D for ; Fri, 19 Nov 2010 21:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2m33mSX88i1 for ; Fri, 19 Nov 2010 21:31:13 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 39F913A68BC for ; Fri, 19 Nov 2010 21:31:12 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B707E9C; Sat, 20 Nov 2010 06:31:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B5B2F9A; Sat, 20 Nov 2010 06:31:56 +0100 (CET) Date: Sat, 20 Nov 2010 06:31:56 +0100 (CET) From: Mikael Abrahamsson To: STUART VENTERS In-Reply-To: <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> Message-ID: References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 05:31:15 -0000 On Fri, 19 Nov 2010, STUART VENTERS wrote: > Well if core congestion has been around since when TCP was created, why > whould you expect Mr.Gig and Mr Adsl not to encounter some. The same way I expect to have food on my table. Just because 3-4 generations back my family sometimes didn't have enough food doesn't mean I should expect that. And TCP needs to handle congestion because it needs it for access congestion, doesn't mean core congestion is a force of nature. > to here's a plan for actually building a practical core to provide it. Where I live, there is no or little core congestion. There is no technical reason it can't be done, it's just economics and politics. > I don't think I would like for the ISP to limit my access speed to what would give me a 95% congestion free packet path. > (If they did they on average, I would run much slower with current economics.) The same way our ancestors worked hard for their kids to not go hungry, we should work hard to make sure our kids will get a good network to communicate on. We should work to provide tools for the end user to know more about their internet connection so they can demand the right things from the ISP, not give ISP tools to get out of providing what they sold. -- Mikael Abrahamsson email: swmike@swm.pp.se From toby@moncaster.com Sat Nov 20 03:30:55 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3603E3A68F3 for ; Sat, 20 Nov 2010 03:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7r0oT9NlT+5 for ; Sat, 20 Nov 2010 03:30:54 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id DBF123A6817 for ; Sat, 20 Nov 2010 03:30:53 -0800 (PST) Received: from TobysHP (host81-158-51-197.range81-158.btcentralplus.com [81.158.51.197]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MP3ch-1PMEMz1nYV-005oDL; Sat, 20 Nov 2010 12:31:42 +0100 From: "Toby Moncaster" To: "'Mikael Abrahamsson'" References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> In-Reply-To: Date: Sat, 20 Nov 2010 11:31:42 -0000 Message-ID: <000301cb88a6$81b20f70$85162e50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcuIdEcPdoJswYBaTPye9tkRZrYX5AAL3uKQ Content-Language: en-gb X-Provags-ID: V02:K0:y+spXbasMVJ0sj74y/x/DuU8wzY0I8POXUHIPvnUek7 mtTyd9WpPosjgaAfkWKRFoodKGdkPgiGxrsGcmoBQEKDF3ioBM WdJXzNc4iIjyFIipPwPpLzReEJOJ9pB5NyLnvHKwxL13v7+RhV e8lEIRr3JUr32w0Qt7Jr73dzGaIP+lVZYsjBeKKZpg/bAGqf21 BSAsNnD85tQNxvIJW63dRG94pFOjEiDNkZAZsmbj/s= Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 11:30:55 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mikael Abrahamsson > Sent: 20 November 2010 05:32 > To: STUART VENTERS > Cc: conex@ietf.org > Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP > > On Fri, 19 Nov 2010, STUART VENTERS wrote: > > > Well if core congestion has been around since when TCP was created, > why > > whould you expect Mr.Gig and Mr Adsl not to encounter some. > > The same way I expect to have food on my table. Just because 3-4 > generations back my family sometimes didn't have enough food doesn't > mean > I should expect that. And TCP needs to handle congestion because it > needs > it for access congestion, doesn't mean core congestion is a force of > nature. > > > to here's a plan for actually building a practical core to provide > it. > > Where I live, there is no or little core congestion. There is no > technical > reason it can't be done, it's just economics and politics. Remember, you live in a very prosperous country, with a relatively small population and with excellent links to the rest of the world. Most places in the world are not so fortunate... > > > I don't think I would like for the ISP to limit my access speed to > what would give me a 95% congestion free packet path. > > (If they did they on average, I would run much slower with current > economics.) > > The same way our ancestors worked hard for their kids to not go hungry, > we > should work hard to make sure our kids will get a good network to > communicate on. We should work to provide tools for the end user to > know > more about their internet connection so they can demand the right > things > from the ISP, not give ISP tools to get out of providing what they > sold. ConEx really isn't about ISPs grabbing more power. I agree that much of the marketing done by ISPs is ridiculous, since it implies all customers can get the maximum service rate at all times. However, that is not a matter for the IETF to address. It is for regulators and competition to sort out. What the IETF can do is provide tools that give ISPs better options for seeing where there are problems. Current DPI/traffic pattern analysis coupled to fair use policies is not a good solution for either party... Realistically your idea of a completely congestion-free network is not going to happen any time soon in most of the world (I accept Sweden seems to be an exception). Therefore the IETF needs to try to improve the current situation. BTW, how do you see us avoiding congestion in undersea cables - for instance, if Africa fully joins the Internet world, with a billion more users connecting at broadband speeds. Do you envisage the capacity of the expensive undersea cables being increased by several orders of magnitude to cope with the extra traffic whilst guaranteeing no congestion? Or do you have an alternative idea? Toby > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From swmike@swm.pp.se Sat Nov 20 03:38:38 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C913A69B4 for ; Sat, 20 Nov 2010 03:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Gz3TupY-3FJ for ; Sat, 20 Nov 2010 03:38:37 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 142CD3A68DB for ; Sat, 20 Nov 2010 03:38:36 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id B6E719C; Sat, 20 Nov 2010 12:39:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B5EB29A; Sat, 20 Nov 2010 12:39:26 +0100 (CET) Date: Sat, 20 Nov 2010 12:39:26 +0100 (CET) From: Mikael Abrahamsson To: Toby Moncaster In-Reply-To: <000301cb88a6$81b20f70$85162e50$@com> Message-ID: References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> <000301cb88a6$81b20f70$85162e50$@com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 11:38:38 -0000 On Sat, 20 Nov 2010, Toby Moncaster wrote: > BTW, how do you see us avoiding congestion in undersea cables - for > instance, if Africa fully joins the Internet world, with a billion more > users connecting at broadband speeds. Do you envisage the capacity of > the expensive undersea cables being increased by several orders of > magnitude to cope with the extra traffic whilst guaranteeing no > congestion? Or do you have an alternative idea? It's already being expanded by magnitudes: 5 terabits/s (just one system) means a billion people can get 5 megabits/s of capacity without congestion. (unless I made a 10^3 error in my calculations). At an establishing costs of a few billion USDs per system that still is a few dollars per person for the whole continent, and that's the complete CAPEX for the investment, not a monthly cost. -- Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Sat Nov 20 07:29:31 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5679C28C0FA for ; Sat, 20 Nov 2010 07:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN1Lq7y9Jjbz for ; Sat, 20 Nov 2010 07:29:30 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id F018B28C0DF for ; Sat, 20 Nov 2010 07:29:29 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 791209C; Sat, 20 Nov 2010 16:30:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 762139A; Sat, 20 Nov 2010 16:30:19 +0100 (CET) Date: Sat, 20 Nov 2010 16:30:19 +0100 (CET) From: Mikael Abrahamsson To: Toby Moncaster In-Reply-To: <000301cb88a6$81b20f70$85162e50$@com> Message-ID: References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> <000301cb88a6$81b20f70$85162e50$@com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 15:29:31 -0000 On Sat, 20 Nov 2010, Toby Moncaster wrote: > Remember, you live in a very prosperous country, with a relatively small > population and with excellent links to the rest of the world. Most > places in the world are not so fortunate... Yet, in the poorest countries I see the most expensive gear, because they have the least skill/experience and the most monopolies that rip off their customers. It's not a matter of prosperity really. And also, if it was a matter of prosperity, do they really need more advanced mechanisms or do they need simpler ways of producing more bandwidth? Imposing advanced "revenue sharing schemes", "QoS end-to-end" and so on, does that really help any poor contry get basic Internet, or does it help oligopoly ISPs get more money in their markets so they can give more profit? As far as I can see so far, ConEx is dominated by oligopoly ISPs, academics and vendors who want to sell more advanced gear. Why isn't there anyone who stands up for the regular user? Why isn't the KISS principle being used, why isn't there BCPs about how to solve this with the existing technology already available? ECN has after 8 years still not seen widespread adoption, yet there is talk about using even more flags in the headers. I appreciate that people are doing this because they think they're doing the right thing, but I question if they really are. In the markets where you get the most bandwidth for the least amount of money, ISPs generally can't afford a huge amount of CRS-1 or Juniper T-series, they instead build it using L3 switches that have little to no queue management, but they instead overprovision services so it works anyway. > IETF to address. It is for regulators and competition to sort out. What the > IETF can do is provide tools that give ISPs better options for seeing where > there are problems. Current DPI/traffic pattern analysis coupled to fair use > policies is not a good solution for either party... I agree, but what the IETF is not doing, is providing tools to *users* to see where the problems are. Also, most of the documents I see here have problem description wording that consists of "unfair use" and similar terms. That is not helping the users, because there is no such thing as "unfair use" to me, I'm just trying to use what I've purchased. > Realistically your idea of a completely congestion-free network is not > going to happen any time soon in most of the world (I accept Sweden > seems to be an exception). Therefore the IETF needs to try to improve > the current situation. Yes it does, but not the onesided way being done right now. -- Mikael Abrahamsson email: swmike@swm.pp.se From carlberg@g11.org.uk Sat Nov 20 09:13:18 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90BE13A687C for ; Sat, 20 Nov 2010 09:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHT-Xkca9F84 for ; Sat, 20 Nov 2010 09:13:17 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 61BA13A6886 for ; Sat, 20 Nov 2010 09:13:17 -0800 (PST) Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:58806 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from ) id 1PJr0e-0005v9-V8; Sat, 20 Nov 2010 17:13:57 +0000 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: ken carlberg In-Reply-To: Date: Sat, 20 Nov 2010 12:14:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9C5D4381-BED9-49D6-B7C6-DED24F29FE23@g11.org.uk> References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> <000301cb88a6$81b20f70$85162e50$@com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1082) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Source: X-Source-Args: X-Source-Dir: Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 17:13:18 -0000 On Nov 20, 2010, at 10:30 AM, Mikael Abrahamsson wrote: > As far as I can see so far, ConEx is dominated by oligopoly ISPs, = academics and vendors who want to sell more advanced gear. I would recommend getting a better pair of glasses. > Why isn't there anyone who stands up for the regular user? Why isn't = the KISS principle being used, why isn't there BCPs about how to solve = this with the existing technology already available? ECN has after 8 = years still not seen widespread adoption, yet there is talk about using = even more flags in the headers. in complete and all seriousness, _please_ contribute and write these = BCPs. Or if you need some help, at least start with a draft, take it to = one or more of the ADs (to see where it best fits in within the IETF) = and ask for other contributors. The next meeting is in Prague and I = would certainly enjoy seeing you give a presentation on what you've = written. =20 > I agree, but what the IETF is not doing, is providing tools to *users* = to see where the problems are. Also, most of the documents I see here = have problem description wording that consists of "unfair use" and = similar terms. That is not helping the users, because there is no such = thing as "unfair use" to me, I'm just trying to use what I've purchased. ok, so along the lines of "just trying to use what I've purchased", = multicast then should be outlawed, banned, or at a minimum, should never = be offered to clients of an ISP as a service because the network is = replicating the traffic that the source did not pay for. And before you = come back and say "well, the receivers of paying for the service through = their access link", that src/sink is not compensating the transits that = build/maintain the trees traversing their network. and so if by chance = your ISP is offering multicast service, I hope the other users who never = use it are not "unfairly" subsidizing the others that do. =20 to take one step back, the market decides what gets adopted, the degree = it gets adopted, and what does not get adopted. Anybody recall IDPR, = SDR?...didn't think so (and old timers are not allowed to respond :-). = And the stuff most of us are familiar with (RSVP, diff-serv, int-serv, = MPLS, multicast) are also things that the market has made a statement = on. So if the market decides that that output of Conex isn't worth the = trouble, then this will be reflected in its deployment. Life goes on. I have the feeling this thread has been beaten to death. I did want to = speak up this one time because I would like to see Mr Abrahamsson write = up one of more drafts of the BCPs he's asking for. cheers, -ken From hmmr@cisco.com Thu Nov 11 08:14:20 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 572453A697E; Thu, 11 Nov 2010 08:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+WUXr833MAe; Thu, 11 Nov 2010 08:14:19 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B6D7D3A6822; Thu, 11 Nov 2010 08:14:17 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFOl20ytJXG//2dsb2JhbACiRXGlbptUhUoEhFpViDo X-IronPort-AV: E=Sophos;i="4.59,183,1288569600"; d="scan'208";a="181076440" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2010 16:14:44 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id oABGEhsx021255; Thu, 11 Nov 2010 16:14:43 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 10:14:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 10:14:42 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] [dispatch] [httpstreaming] Q-HTTP Thread-Index: AcuBtZ1WcFN+xDTETyq3gnYdU5nviQAAkfoQ References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> From: "Mike Hammer (hmmr)" To: "Mikael Abrahamsson" X-OriginalArrivalTime: 11 Nov 2010 16:14:43.0938 (UTC) FILETIME=[8D483C20:01CB81BB] X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:17 -0800 Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Ingemar Johansson S , Kathy McEwen , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" , Mark Watson , David Singer Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 16:14:20 -0000 Mikael, I think the crux of our disagreement here is the difference between what it takes to be an ISP and what it takes to be an access provider. The economics are different. Apples and oranges. Saying it works for oranges means it makes sense for apples is a non-sequitor. It is nice that you have a regulated monopoly of L1 in your market, but that is not the case everywhere. Who you are now is what you were when. Some investors that paid to put copper or fiber into the ground would prefer that the fruits of their labor not be stolen from them by government fiat.=20 The telephone network had 100 years to get the blocking rates and traffic engineering right. Even now, in some countries you do still get busy signal. Should you then have the right to go out an cancel your contract as a result? I'll leave that to the market to decide. And yes, I support not having too lengthy a contract. After all, we need to vote with our feet every so often. However, comparing blocking (dial-tone means nothing, busy signal does) of QoS guaranteed telephone links with non-QoS based congestion is self-contradictory. You are in essence saying that on the one hand providers should not have the tools to provide QoS guarantees and on the other hand slapping them for not being able to provide a QoS guarantee. Now how fair is that? Also, comparing low-volume fairly predictable traffic flows like voice to bursty flows like video is also problematic. I would not be so quick to deride the advertizing as false as not very clear, but I do think there could be better education of the public. =20 (Have you never tried to explain this to a non-techie and watched their eyes glaze over?) As for treating traffic equally, you apparently don't care much about real-time interactive applications. That is your choice. But, please don't impose that on everyone. Mike -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Thursday, November 11, 2010 10:32 AM To: Mike Hammer (hmmr) Cc: David Singer; dispatch@ietf.org; Kathy McEwen; httpstreaming; conex@ietf.org; Ingemar Johansson S; Mark Watson; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) Subject: RE: [conex] [dispatch] [httpstreaming] Q-HTTP On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote: > So, you are assuming that the alternative provider is not subject to the=20 > same economic constraints as the provider you are jumping from? If that=20 > were such an easy thing to do, you would see many more players on the=20 > field, and fewer commentators in the stands. In my market there are lots of players and they all have possibility to=20 reach end users because there are "neutral" L1 providers to rent=20 fiber/copper from. Competition works, and it stops aggregation congestion. > Agree, that the core should not be getting congested, but this problem > gets worse progressively as you approach the customer edge. And the=20 > costs to overprovision the edge go up correspondingly. The last mile is=20 > the most expensive. The customer unique connection is ok to congest, it's running at the speed=20 the customer is paying for. It's everything up from that that should=20 "never" be congested, because then you're not giving the customer what=20 they're paying for. It's a breach of contract, pure and simple. You're=20 free to statistically overbook your aggregation up to the point where it's=20 extremely rarely congesting. Would you accept a telephony network that gave you no dialtone half of the=20 time you tried? I don't get it. Why would ISPs get away with not=20 delivering what they have sold and why should we help them do this? What the IETF and everybody should focus on is SHOWING to the end users=20 that there is congestion occuring, so they have a tool to give their=20 consumer protection agency this informaiton to demand to cancel their=20 contract because their ISP is not delivering on its promise. This works in all other markets, there false advertising is not tolerated,=20 why should it be in the ISP market? If you're buying 100 megabit/s of=20 residential bw you should be able to use this speed at least 99% of the=20 time, otherwise your ISP is overselling the resource and you're not=20 getting what you have bought. If the ISP has gigabit aggregation it's most=20 likely that they can get away with 1000 users or more on this gige at this=20 speed, but they will not get away with it by doing 200 meg aggregation. People talk about "fair". Fair business practice is to deliver what you've=20 sold. Fair is to treat every customers traffic equally, to deliver the=20 packets they want delivered. That is the job of the ISP. It's not to=20 mistreat some traffic or discriminate. If anything, THAT is the unfair=20 part. > > -----Original Message----- > From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > Sent: Wednesday, November 10, 2010 5:08 PM > To: Mike Hammer (hmmr) > Cc: David Singer; dispatch@ietf.org; Kathy McEwen; httpstreaming; > conex@ietf.org; Ingemar Johansson S; Mark Watson; GARCIA ARANDA, > JOSEJAVIER (JOSE JAVIER) > Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP > > On Wed, 10 Nov 2010, Mike Hammer (hmmr) wrote: > >> 3) The people that build and operate the networks will double >> (quadruple?) their investments for no additional return out of the >> goodness of their hearts. > > No, they're going to do it because if they don't give the customers what > > they promised, their customers are going to leave. This is if there is a > > functional market and customers actually have a choice of providers. I > realise this is not the case in parts of the world, but that doesn't > mean > we should solve that by technical means, that's a political and > regulatory > problem, it doesn't have any technical solution. > > Let's not forget that if you're congesting your core and distribution, > you're not delivering what your customers have purchased. Period. > > Everything else is just smoke and mirrors. > > Congestion is acceptable on the customer access, it's not acceptable in > the core. That means that any flows/pakets that should yield, are within > a > single customer domain, and thus in the customers own interest. > > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > --=20 Mikael Abrahamsson email: swmike@swm.pp.se From singer@apple.com Thu Nov 11 09:36:27 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511093A69E7; Thu, 11 Nov 2010 09:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.578 X-Spam-Level: X-Spam-Status: No, score=-107.578 tagged_above=-999 required=5 tests=[AWL=1.021, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+9NPURFtK36; Thu, 11 Nov 2010 09:35:52 -0800 (PST) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id C33903A6954; Thu, 11 Nov 2010 09:35:51 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 37C1BBC47580; Thu, 11 Nov 2010 09:36:21 -0800 (PST) X-AuditID: 11807134-b7c05ae000002d5d-83-4cdc2992b5fc Received: from [17.72.147.41] (Unknown_Domain [17.72.147.41]) by relay14.apple.com (Apple SCV relay) with SMTP id E8.0A.11613.2992CDC4; Thu, 11 Nov 2010 09:36:21 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Singer In-Reply-To: Date: Thu, 11 Nov 2010 18:36:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4EA88DB4-93EC-4094-B51F-519BEDF19CCB@apple.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Ingemar Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" , Mark Watson Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 17:36:27 -0000 On Nov 11, 2010, at 18:15 , Mikael Abrahamsson wrote: >=20 > I don't want QoS guarantees, I want *all* my packets delivered, = expediently, regardless if my neighbour is filling up his pipe or not. I = have paid for it, and I want it DELIVERED. The postal office doesn't get = to choose which of my letters it's ok to delay or throw away, they = should just deliver them. Same with my ISP. >=20 It's interesting you say this in the context of real-time media, because = I believe a network can give time guarantees ("any packet I deliver on = this will be delivered within x ms") or delivery guarantees ("all = packets will eventually be delivered") but it's hard (impossible, maybe) = to do both. eMail is an assured store-and-forward service. IP packets are not. = Most users are unwilling to pay for guaranteed bandwidth availability to = an ISP, who in turn would have to pay for guaranteed bandwidth upstream, = and so on. =20 Personally, I want my fair share of the shared 'roads' no matter how = many others are sharing them, and I expect the 'last mile' personal link = to have (at least) the capacity that was sold to me. David Singer Multimedia and Software Standards, Apple Inc. From kathy@iridescentnetworks.com Thu Nov 11 09:55:01 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3969F3A689E for ; Thu, 11 Nov 2010 09:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6G4MEVbGkHE for ; Thu, 11 Nov 2010 09:55:01 -0800 (PST) Received: from smtp115.biz.mail.mud.yahoo.com (smtp115.biz.mail.mud.yahoo.com [209.191.68.75]) by core3.amsl.com (Postfix) with SMTP id 0304E3A67B2 for ; Thu, 11 Nov 2010 09:55:00 -0800 (PST) Received: (qmail 88684 invoked from network); 11 Nov 2010 17:55:11 -0000 Received: from IridescentKathy (kathy@12.133.149.197 with login) by smtp115.biz.mail.mud.yahoo.com with SMTP; 11 Nov 2010 09:55:11 -0800 PST X-Yahoo-SMTP: 0oTc.aiswBATml9UvnuZnOzzTXTzZTa6NV7Bbr9Wm3OL X-YMail-OSG: jvJodm8VM1mEzBysKP2rhN.SUx6vFmz7c200Cm2B7fFlTAU 1dMeGQUeUF7VWs7Z2aZhaVECGtbAaMCrLydi7srQiWhXWziBFucx9HmGqFge g5Z.bWuv9ZKYTG2jISfJT1KKDpV_s4if0tdWvPnPd7UeRrNbId6EI1Pn_gud qVPCATj71lEqlLbVma0WI5_PxP2JOBxsnoRGO3d.BfiHw_fmd5.Sh3O6ZHHx or99k0TjRexYde7j9QIzvwFwC3E1Iw.ZaqtIJ1xbdG2FQrittoAkbdyDXDgD F22C3tUFJ1HMWFc1h_8Nf_b9wpGM0 X-Yahoo-Newman-Property: ymail-3 From: "Kathy McEwen" To: "'Mikael Abrahamsson'" , "'Mike Hammer \(hmmr\)'" References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> In-Reply-To: Date: Thu, 11 Nov 2010 11:55:14 -0600 Message-ID: <001801cb81c9$9833c3d0$c89b4b70$@iridescentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQIVmQZqk6YOb/SFfEdornYnDlU03gHSHZPOAhA2GDcCgFHy7wI9XcNPAw8W+5YB5eOKoQIAb8BLAhVwKwcCPlDyjAJ0wMWHArsXmJcCNhtUVwILCT0cAbJRNU8B9hItL5HQSoqg Content-language: en-us X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:17 -0800 Cc: dispatch@ietf.org, 'httpstreaming' , conex@ietf.org, 'Ingemar Johansson S' , 'Mark Watson' , "'GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)'" , 'David Singer' Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 17:55:01 -0000 Hello All, FYI... ATIS has issued a report on Policy Management, and have started a Policy Management Focus Group with Assessment and Recommendations, including numerous descriptions of market need. Input was gathered from a large number of contributing operators. The report was issued in June of this year, and includes the debates/arguments for managed QoS that also seem to be bouncing around in this IETF BoF group. Perhaps some of the ATIS study work could be useful for the HTTP streaming justification as well...so as not to duplicate work. HTTP streaming is one piece of the bigger puzzle. This IETF BoF group may want to liaison with this ATIS group. http://www.atis.org/documents/ATIS%20Policy%20Management%20Focus%20Group%20% 28PM-FG%29%20Final%20Report.pdf extracted: 1.1 Problem Statement As network resources are increasingly stretched by unprecedented growth in data traffic, Policy management is becoming an important industry topic. Many service providers are concluding that it is unrealistic to continue deploying additional capacity at the problem indefinitely. Policy management is emerging as a potential tool to get more capacity out of installed networks. Network policies are rules that are defined by the service provider to control and charge for the resources used for communication between end-points. Policies can also be used to bind the appropriate bandwidth, and Quality of Service (QoS) to a given application or subscriber. Policies can thus be used to control and better ensure the user's experience in utilizing a service or application, wherever the service is accessed. For example, a user streaming a video from a video service can be guaranteed a high quality viewing experience whether they are viewing the video on a smart phone or a High Definition TV. Service convergence has been a vision of the communications industry for years, and recent deployment has begun to translate this vision into reality. Users can have a single contact number that will terminate on their landline phone, mobile phone, or computer, depending upon their needs. A given service can be accessed from a home network, a 3G network halfway around the world, or from a WiFi hotspot at the coffee shop around the corner. All of this demonstrates that service convergence is quickly becoming a practical reality, but only at the basic connectivity level. In most cases, once a user leaves their local service provider network they are limited to best effort. In many cases today, that is good enough, and the popularity of these services is growing exponentially. Growth at this level, especially from smart phones and netbooks, is already beginning to strain some networks, and it will only increase over time. .../Kathy -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Sent: Thursday, November 11, 2010 11:16 AM To: Mike Hammer (hmmr) Cc: David Singer; dispatch@ietf.org; Kathy McEwen; httpstreaming; conex@ietf.org; Ingemar Johansson S; Mark Watson; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) Subject: RE: [conex] [dispatch] [httpstreaming] Q-HTTP On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote: > I think the crux of our disagreement here is the difference between > what it takes to be an ISP and what it takes to be an access provider. > The economics are different. Apples and oranges. Saying it works for > oranges means it makes sense for apples is a non-sequitor. For me an ISP is one who runs active equipment, L2 and up. Sometimes ISPs own L1 as well. What do you mean by it? > > It is nice that you have a regulated monopoly of L1 in your market, > but It's not a monopoly. Well, the copper is mostly, but the fiber isn't. > However, comparing blocking (dial-tone means nothing, busy signal > does) of QoS guaranteed telephone links with non-QoS based congestion > is self-contradictory. You are in essence saying that on the one hand > providers should not have the tools to provide QoS guarantees and on > the other hand slapping them for not being able to provide a QoS guarantee. > Now how fair is that? I don't want QoS guarantees, I want *all* my packets delivered, expediently, regardless if my neighbour is filling up his pipe or not. I have paid for it, and I want it DELIVERED. The postal office doesn't get to choose which of my letters it's ok to delay or throw away, they should just deliver them. Same with my ISP. > I would not be so quick to deride the advertizing as false as not very > clear, but I do think there could be better education of the public. > (Have you never tried to explain this to a non-techie and watched > their eyes glaze over?) That's why the IETF should work on tools to show this to people, not give ISPs tools to screw their customers. > As for treating traffic equally, you apparently don't care much about > real-time interactive applications. That is your choice. But, please > don't impose that on everyone. I am fine with packet prioritization within my access line. I have AQM on my own access line, because it makes my access line perform better for my packet mix (prioritizes my VoIP and ssh before my data heavy TCP sessions). The problem I'm having here is that most talk is not about how to make the customers access line behave better for the customer, it's to have certain customers traffic be lower prioritized in the distribution and core, so ISPs can oversubscribe more without customers being able to notice too much. I resent that. -- Mikael Abrahamsson email: swmike@swm.pp.se From hmmr@cisco.com Thu Nov 11 10:03:29 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D16B3A69C2; Thu, 11 Nov 2010 10:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.561 X-Spam-Level: X-Spam-Status: No, score=-11.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l5NwAQipghl; Thu, 11 Nov 2010 10:03:28 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 02AF43A6969; Thu, 11 Nov 2010 10:03:27 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN++20ytJV2Z/2dsb2JhbACiRXGmN5tUhUoEhFqJDw X-IronPort-AV: E=Sophos;i="4.59,184,1288569600"; d="scan'208";a="180904514" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2010 18:03:54 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id oABI3sKq000789; Thu, 11 Nov 2010 18:03:54 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 12:03:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 12:03:53 -0600 Message-ID: In-Reply-To: <4EA88DB4-93EC-4094-B51F-519BEDF19CCB@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [conex] [dispatch] [httpstreaming] Q-HTTP Thread-Index: AcuBxvZJyzWpf/DyTPmgPL/g414AyAAAYEpw References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <4EA88DB4-93EC-4094-B51F-519BEDF19CCB@apple.com> From: "Mike Hammer (hmmr)" To: "David Singer" , "Mikael Abrahamsson" X-OriginalArrivalTime: 11 Nov 2010 18:03:54.0565 (UTC) FILETIME=[CDC29750:01CB81CA] X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: dispatch@ietf.org, Kathy McEwen , httpstreaming , conex@ietf.org, Ingemar Johansson S , Mark Watson , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 18:03:29 -0000 David, Yes, I have to agree that there are several approaches to how packets are handled and they have to be balanced so you don't starve one or another. All packets can't be first in the queue, so some preferences and ordering will take place. There seems to be a gap between what a customer thinks they paid for and what the provider thought they offered at that price. The latter has to make assumptions about traffic volume and mix and plan pricing and costs to come out positive, or they won't be in business very long. But, as most traffic planners know, what you plan for and what traffic you get can vary widely, especially with data. If you want hard guarantees, then you need to have private roads, but that is much more expensive and most folks aren't willing to pay for it. There are certain cases where without the QoS the service just doesn't work. For those, a user may be willing to pay to ensure the service. If the network is engineered properly, then such services only take up a fraction of the network. If it is too large a share, does that mean the QoS mechanism is bad? No, it means the traffic engineering and implementation is bad. So, let us put the blame where it is due. =20 The IETF should be about designing good tools. Not attempting to control bad usage of good tools. My experience personally. My package is 20Mb up and 20 Mb down. What do I normally get is 5Mb up and 10Mb down. Am I upset? No, because the applications generally work. There are tools out there to measure that. If your provider is not even in the ball park of what he is offering, then yeah, you need to switch. Mike -----Original Message----- From: David Singer [mailto:singer@apple.com]=20 Sent: Thursday, November 11, 2010 12:36 PM To: Mikael Abrahamsson Cc: Mike Hammer (hmmr); dispatch@ietf.org; Kathy McEwen; httpstreaming; conex@ietf.org; Ingemar Johansson S; Mark Watson; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP On Nov 11, 2010, at 18:15 , Mikael Abrahamsson wrote: >=20 > I don't want QoS guarantees, I want *all* my packets delivered, expediently, regardless if my neighbour is filling up his pipe or not. I have paid for it, and I want it DELIVERED. The postal office doesn't get to choose which of my letters it's ok to delay or throw away, they should just deliver them. Same with my ISP. >=20 It's interesting you say this in the context of real-time media, because I believe a network can give time guarantees ("any packet I deliver on this will be delivered within x ms") or delivery guarantees ("all packets will eventually be delivered") but it's hard (impossible, maybe) to do both. eMail is an assured store-and-forward service. IP packets are not. Most users are unwilling to pay for guaranteed bandwidth availability to an ISP, who in turn would have to pay for guaranteed bandwidth upstream, and so on. =20 Personally, I want my fair share of the shared 'roads' no matter how many others are sharing them, and I expect the 'last mile' personal link to have (at least) the capacity that was sold to me. David Singer Multimedia and Software Standards, Apple Inc. From luismi.diaz@alcatel-lucent.com Thu Nov 11 10:42:55 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B2728C0EE; Thu, 11 Nov 2010 10:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.207 X-Spam-Level: X-Spam-Status: No, score=-7.207 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6VKgl5j9y2a; Thu, 11 Nov 2010 10:42:53 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 0C0D83A68BD; Thu, 11 Nov 2010 10:42:52 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oABIhCEN029485 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 11 Nov 2010 19:43:13 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 11 Nov 2010 19:43:12 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: Mikael Abrahamsson , "Mike Hammer (hmmr)" Date: Thu, 11 Nov 2010 19:43:11 +0100 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuBxFjYih2YrN4ESN+MSuHYLVkpagABEd4Q Message-ID: <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , Ingemar, httpstreaming , "conex@ietf.org" , Johansson S , Kathy McEwen , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 18:42:55 -0000 Hi, Just a different approach. Think in a traffic jam. I know it would be ni= ce to live in a wonderful world with no jams, but they happen. Know compare= you, going back home from work, and an ambulance with someone dying inside= . Everybody gets away to let ambulance drive first. And that's OK. Now think on Internet. You are playing a Real-Time game and your neighbo= urs are just downloading files. They can afford some amount of traffic loss= (+delay/jitter) since TCP retransmisions will do the trick (just will take= a little longer to get the job done) while you cannot afford losing (+dela= ying/jitterin) your traffic because if it happens, your opponent will blow = you away from the arena. That's the point, all traffic flows are NOT the sa= me and need different SLAs. Q-HTTP tries to address both problems: - Enable subscriber to measure the SLA is being provided. This by itself is= nice, since allows e2e players to solve the problem (reducing bit-rate of = video if possible, for instance) - Enables network operators to generate more revenue for "over-requirements= ". I dont think real-time was in mind whe Internet was created and we need = to provide ISPs with new tools like this. I dont see any drawback in trying to anticipate to the future needs...=20 Saludos, Luismi -----Mensaje original----- De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre = de Mikael Abrahamsson Enviado el: jueves, 11 de noviembre de 2010 18:16 Para: Mike Hammer (hmmr) CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; = Kathy McEwen; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote: > I think the crux of our disagreement here is the difference between=20 > what it takes to be an ISP and what it takes to be an access provider. =20 > The economics are different. Apples and oranges. Saying it works for=20 > oranges means it makes sense for apples is a non-sequitor. For me an ISP is one who runs active equipment, L2 and up. Sometimes ISPs o= wn L1 as well. What do you mean by it? > > It is nice that you have a regulated monopoly of L1 in your market,=20 > but It's not a monopoly. Well, the copper is mostly, but the fiber isn't. > However, comparing blocking (dial-tone means nothing, busy signal=20 > does) of QoS guaranteed telephone links with non-QoS based congestion=20 > is self-contradictory. You are in essence saying that on the one hand=20 > providers should not have the tools to provide QoS guarantees and on=20 > the other hand slapping them for not being able to provide a QoS guarante= e. > Now how fair is that? I don't want QoS guarantees, I want *all* my packets delivered, expediently= , regardless if my neighbour is filling up his pipe or not. I have paid for= it, and I want it DELIVERED. The postal office doesn't get to choose which= of my letters it's ok to delay or throw away, they should just deliver the= m. Same with my ISP. > I would not be so quick to deride the advertizing as false as not very=20 > clear, but I do think there could be better education of the public. > (Have you never tried to explain this to a non-techie and watched=20 > their eyes glaze over?) That's why the IETF should work on tools to show this to people, not give I= SPs tools to screw their customers. > As for treating traffic equally, you apparently don't care much about=20 > real-time interactive applications. That is your choice. But, please=20 > don't impose that on everyone. I am fine with packet prioritization within my access line. I have AQM on m= y own access line, because it makes my access line perform better for my pa= cket mix (prioritizes my VoIP and ssh before my data heavy TCP sessions). The problem I'm having here is that most talk is not about how to make the = customers access line behave better for the customer, it's to have certain = customers traffic be lower prioritized in the distribution and core, so ISP= s can oversubscribe more without customers being able to notice too much. I resent that. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From jose_javier.garcia_aranda@alcatel-lucent.com Thu Nov 11 11:51:29 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233F83A6A84; Thu, 11 Nov 2010 11:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.796 X-Spam-Level: X-Spam-Status: No, score=-3.796 tagged_above=-999 required=5 tests=[AWL=-1.547, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoUlBS9rwKfP; Thu, 11 Nov 2010 11:51:27 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 58CA03A6928; Thu, 11 Nov 2010 11:51:25 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oABJpnRR000907 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 11 Nov 2010 20:51:50 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 11 Nov 2010 20:51:50 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" Date: Thu, 11 Nov 2010 20:51:45 +0100 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuB0u/0xNI3zWThS5uX2nW0qtDdyAAAtnJg Message-ID: <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: Ingemar Johansson S , Kathy McEwen , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" , "Mike Hammer \(hmmr\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 19:51:30 -0000 Let's change one-way by two-ways ISP business User---->content provider---> ISP <----flat fee user =20 Service providers are worried about ARPU. It is decreasing becasue the "exaflood" phenomenon. The exponential traffic can not be sustained=20 by the network, with incremental increases in bandwidth. The answer consist on focuse on "ARPContent provider" instead on ARPU. And = how? The way to do that is by means of application enablement. If network provid= er=20 exposes their capabilities to the developers/content providers , then=20 internet applications becomes enough valuated to motivate users pay for the= m. These ISP capabilities can be priced to developers/content providers, incre= asing=20 ISP revenues. Capabilities such as location, presence, billing, security, Q= oS.... One of the most important is QoS. If developers can not find profitable bus= iness Models, innovation is compromised. QoS means a mix of traffic engineering += priorization + etc Look at gaming: this industry moves around 50 Billion euros per year, there= of 35 Billion are games and the rest (15%) hardware consoles. In the value chain = of Gaming industry, the distribution layer takes around 10%. (5 billion) Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP) to enab= le virtualization of games=20 (like www.onlive.com, but using the network instead locating servers at las= t mille) The potential of QoS for ISP only in Gaming are: distribution + hardware co= nsole savings + antipiracy + ... Lets make the sum.=20 virtual gaming is only one of the potential business of QoS - Jose javier From jose_javier.garcia_aranda@alcatel-lucent.com Thu Nov 11 15:02:40 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291713A657C; Thu, 11 Nov 2010 15:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.655 X-Spam-Level: X-Spam-Status: No, score=-3.655 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaLW5Ps0CWOz; Thu, 11 Nov 2010 15:02:38 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 9F9CB3A635F; Thu, 11 Nov 2010 15:02:38 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oABN2NMq015406 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Nov 2010 00:02:24 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 12 Nov 2010 00:02:23 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: Mikael Abrahamsson Date: Fri, 12 Nov 2010 00:02:21 +0100 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuB4Vl8kL6F99JJR5asvgwyuxDp7wADcA+A Message-ID: <3349FECF788C984BB34176D70A51782F16877F9C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 23:02:40 -0000 Mikael, Since several years ago, ARPU is frozen and even it has been reduced a litt= le. But traffic grows each year, and as you say, profit goes down. I have c= heck ARPU from Spanish operators and they are reduced Each year, a little, but the investments in network must increase to suppor= t the traffic growing. An operator can do much more than micropayments and location. Can provide l= ocation, presence, availability status, geofencing functionalities, profili= ng, security based on attack patterns and virus signatures, child protectio= n navigation, unified communications like integration voicemail to social n= etworks, QoS (based on priorization, reservation, traffic mode at access no= des, traffic engineering, path computation) , storage, Content delivery net= work services, IPTV and IPTV based services, advertising, interactive adver= tising over IPTV, security, billing, wallet services for micropayments, rem= ote call control, click to dial services, application store services, expos= ure of messaging services ( MMS, SMS), instant messaging services..... Priorization reduce queue times, with network full or not. For example, IPT= V services offered by operators uses priorization. But do not reduce QoS to= priorization. There are more operations involved in QoS. Regarding latency, it is possible reduce the latency using different operat= ions over the network elements, such as changing traffic mode, choose a goo= d path, priorization and so on. With around 50ms it is possible play a lot = of virtualized games. Depending on the required latency, the application ca= n work with a good user experience. But this is not only applicable to virt= ualized games, but also to traditional online gaming, in which latencies so= metimes makes not possible to play against users located in other countries= , and in that case constraints are not very restricted , however without Qo= S, they are impossible to achieve today.=20 Hard-core gamers have a high willingness to pay for virtualized games, but = today content providers can not offer virtualized games because there is no= t QoS on demand in Internet. Have you read the draft? I promise you that Q-HTTP perhaps has an horrible = name, but it is KISS, for sure. It is application level, and Q-HTTP alerts = can be used for a lot of possibilities from adapting mechanisms ( reduce b= itrate or functionalities) to priorization , reservation, or whatever. It = is not said what to do with the alerts in the draft. It is only a powerful = tool. - Jose Javier -----Mensaje original----- De: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Enviado el: jueves, 11 de noviembre de 2010 21:44 Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Mike Hammer (hmmr); I= ngemar Johansson S; Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) Asunto: RE: [dispatch] [conex] [httpstreaming] Q-HTTP On Thu, 11 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: > Service providers are worried about ARPU. It is decreasing becasue the=20 > "exaflood" phenomenon. The exponential traffic can not be sustained by=20 > the network, with incremental increases in bandwidth. I don't get it. Are you saying that because there is more traffic, the user= is paying less money per month? Yes, profit per customer might be down, bu= t why should traffic volume decrease revenue? > These ISP capabilities can be priced to developers/content providers,=20 > increasing ISP revenues. Capabilities such as location, presence, billing= , security, QoS.... I agree that an ISP can be a micropayment provider and also provice some lo= cation information. > One of the most important is QoS. If developers can not find=20 > profitable business Models, innovation is compromised. QoS means a mix=20 > of traffic engineering + priorization + etc Packet prioritization is only of value when the network is full. QoS is onl= y of interest when BE works badly. > Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP) to=20 > enable virtualization of games (like www.onlive.com, but using the=20 > network instead locating servers at last mille) I don't get this either. You can't play an FPS with tens of milliseconds of= network delay, so you need to locate servers close to the customers to kee= p latency low, plus you also don't want the access latency to eat up your l= atency budget so ADSL and cable goes out the window anyway, the only thing = left is the sub-millisecond latency of ETTH. Btw, I think Q-HTTP is a horrible idea. It seems require a lot of state in = the network. State is expensive. What happened to KISS principle? --=20 Mikael Abrahamsson email: swmike@swm.pp.se From HKaplan@acmepacket.com Thu Nov 11 16:06:32 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0533228C0EF; Thu, 11 Nov 2010 16:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWJAsrVl+0sk; Thu, 11 Nov 2010 16:06:31 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 244EA3A63EB; Thu, 11 Nov 2010 16:06:31 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 11 Nov 2010 19:06:58 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 11 Nov 2010 19:06:58 -0500 From: Hadriel Kaplan To: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" Date: Thu, 11 Nov 2010 19:06:55 -0500 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuB/YVGBN3wWySoRYK2ksPukCUhdA== Message-ID: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F9C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <3349FECF788C984BB34176D70A51782F16877F9C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , Kathy McEwen , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 00:06:32 -0000 Hi, one of the mailing lists you're CC'ing in this email thread is the DISPATCH= WG list. The purpose of the DISPATCH WG is to determine if and where to d= ispatch new work in RAI. My guess is that even if there were agreement tha= t there is a problem, and to solve the problem this way... this I-D would r= equire a new WG, possibly not in RAI. =20 Do the authors of this I-D plan to submit a proposed charter for a new WG i= nto this Dispatch mailing list? If not, I don't mean to be rude, but do you have to keep cc'ing the Dispatc= h mailing list? Don't you already have a mailing list dedicated for this di= scussion? =20 And if you do plan to submit a charter, please email a proposed charter. Don't take this as criticism, but Debating service provider OPEX, CAPEX, co= nsumer market forces, and network design theory isn't really useful on the = Dispatch mailing list. We're just not the right group for that, methinks. = =20 Just my personal opinion. To each his own. -hadriel From luismi.diaz@alcatel-lucent.com Fri Nov 12 00:54:07 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AF63A6B09; Fri, 12 Nov 2010 00:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.381 X-Spam-Level: X-Spam-Status: No, score=-4.381 tagged_above=-999 required=5 tests=[AWL=-2.132, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwJonjvdcS8M; Fri, 12 Nov 2010 00:54:00 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id E3F8F3A6B0D; Fri, 12 Nov 2010 00:53:54 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAC8sM6E007397 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Nov 2010 09:54:23 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 12 Nov 2010 09:54:22 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: Mikael Abrahamsson Date: Fri, 12 Nov 2010 09:54:20 +0100 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuB0uhyyyCMZmR/ToGi1o00hUYJ2QAcgFuA Message-ID: <3349FECF788C984BB34176D70A51782F16878047@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , Ingemar, httpstreaming , "conex@ietf.org" , Johansson S , Kathy McEwen , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 08:54:07 -0000 Few comments in-line....=20 Saludos, Luismi -----Mensaje original----- De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre = de Mikael Abrahamsson Enviado el: jueves, 11 de noviembre de 2010 20:02 Para: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; = Kathy McEwen; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP On Thu, 11 Nov 2010, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote: > Just a different approach. Think in a traffic jam. I know it would=20 > be nice to live in a wonderful world with no jams, but they happen.=20 > Know compare you, going back home from work, and an ambulance with=20 > someone dying inside. Everybody gets away to let ambulance drive=20 > first. And that's OK. When there is a traffic jam due to an accident it's ok. Where there is LA s= tyle traffic jams 12 hours of the day, that's not ok. [[Luismi]]: I dont look why it is happening. It is just happening. And we n= eed to do something about it in both cases (accident and 12-hour daily jam)= .=20 > Now think on Internet. You are playing a Real-Time game and your=20 > neighbours are just downloading files. They can afford some amount of=20 > traffic loss (+delay/jitter) since TCP retransmisions will do the=20 > trick (just will take a little longer to get the job done) while you=20 > cannot afford losing (+delaying/jitterin) your traffic because if it=20 > happens, your opponent will blow you away from the arena. That's the=20 > point, all traffic flows are NOT the same and need different SLAs. It would help the customer to get different treatment of his/her flows on t= he access. It would help the ISP and not the customer to do the same in the= distribution/core. Who do we want to help? Is it the end user or is it the= ISP? In the discussions in CONEX I mostly see people wanting to help the I= SP, not the end user. [[Luismi]]: There is one only real thing we can trust in: ISP is there beca= use of PROFIT. If there is no profit there will be no investment at all and= everything will just stale, that is precisely the reason while new real-ti= me services are not flying on Internet as it should. We are helping ISPs to= do MORE with the same money, and that will benefit users. With Q-HTTP we a= re also providing the tools to users to "audit" what they are paying for. U= sers will pay extra money for superb services (we are doing that right now = when you pay a World of Warcraft or OnLive subscription) and part of that m= oney will end-up on the ISP. Sharing profit between all the players is defi= netively a good thing IMHO. > - Enables network operators to generate more revenue for=20 > "over-requirements". I dont think real-time was in mind whe Internet=20 > was created and we need to provide ISPs with new tools like this. "over-requirement" as in "I want to actually get what you promised to deliv= er to me"? [[Luismi]]: The problem is that ISPs promises are just vague. Up to X Mbps,= with no delay/jitter guarantees is just fine for a lot of applications. It= is just not enough for real-time. Besides, a few seconds congestion (for i= nstance, a fiber goes down and all traffic re-routes by another path that b= ecomes 1.5 to 1 congested) will produce a slow down in "standard" service a= nd a complete melt-down in real-time. THAT's what we want to protect. Real-= Time application will obtain higher priority during congestion (thus slowin= g down even more the standard services) and EVERYTHING will be saved. Stand= ard services will survive with a period of "half-speed" and Real-Time will = survive unaffected. I don't buy it. [[Luismi]]: Then there are a lot of services that never will fly out on Int= ernet. Take a look on OnLive service. They provide virtualized gaming (play= XBOX games on your TV without the console, just with a small set-top-box t= hat receives video and sends keys pressed on the pad) by just bypassing the= network and installing PoPs just half mile away from your home. That is no= t economically optimized as you can imagine thus they are translating that = into a very expensive service. Just because network does not provide what t= hey need. With QoS, they can offer a centralized service, with really cheap= er deployment, lower the service fee to users (win), making more profit (wi= n) and paying a % of that to ISP (win). If we like win-win, you must love t= his win-win-win (and even better, ISP will re-invest part of that profit on= network). --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From luismi.diaz@alcatel-lucent.com Fri Nov 12 01:12:20 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C7928C111; Fri, 12 Nov 2010 01:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.077 X-Spam-Level: X-Spam-Status: No, score=-4.077 tagged_above=-999 required=5 tests=[AWL=-1.828, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNcJChNwDzO1; Fri, 12 Nov 2010 01:12:13 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id A301A28C110; Fri, 12 Nov 2010 01:12:12 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAC9CeUp010250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Nov 2010 10:12:40 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 12 Nov 2010 10:12:40 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: Mikael Abrahamsson , "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" Date: Fri, 12 Nov 2010 10:12:38 +0100 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuB4Vl8kL6F99JJR5asvgwyuxDp7wAZ+ARA Message-ID: <3349FECF788C984BB34176D70A51782F1687808C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Ingemar Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 09:12:20 -0000 =20 You said: "Packet prioritization is only of value when the network is full. QoS is on= ly of interest when BE works badly." Then, why on earth ALL ISPs are using QoS in THEIR networks to guarantee th= eir own VoIP and Broadcast TV services to their customers??? QoS is ALWAYS a MUST for ISPs to ensure real-time services at any moment. Q= -HTTP is trying to open up that window to other third parties. And about "network state", there are different solutions to implement this,= one includes network state, BUT IT IS NOT THE ONLY ONE. Indeed we tested o= ne alternative in our lab with actual equipment.... Saludos, Luismi -----Mensaje original----- De: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Enviado el: jueves, 11 de noviembre de 2010 21:44 Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Mike Hammer (hmmr); I= ngemar Johansson S; Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) Asunto: RE: [dispatch] [conex] [httpstreaming] Q-HTTP On Thu, 11 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: > Service providers are worried about ARPU. It is decreasing becasue the=20 > "exaflood" phenomenon. The exponential traffic can not be sustained by=20 > the network, with incremental increases in bandwidth. I don't get it. Are you saying that because there is more traffic, the user= is paying less money per month? Yes, profit per customer might be down, bu= t why should traffic volume decrease revenue? > These ISP capabilities can be priced to developers/content providers,=20 > increasing ISP revenues. Capabilities such as location, presence, billing= , security, QoS.... I agree that an ISP can be a micropayment provider and also provice some lo= cation information. > One of the most important is QoS. If developers can not find=20 > profitable business Models, innovation is compromised. QoS means a mix=20 > of traffic engineering + priorization + etc Packet prioritization is only of value when the network is full. QoS is onl= y of interest when BE works badly. > Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP) to=20 > enable virtualization of games (like www.onlive.com, but using the=20 > network instead locating servers at last mille) I don't get this either. You can't play an FPS with tens of milliseconds of= network delay, so you need to locate servers close to the customers to kee= p latency low, plus you also don't want the access latency to eat up your l= atency budget so ADSL and cable goes out the window anyway, the only thing = left is the sub-millisecond latency of ETTH. Btw, I think Q-HTTP is a horrible idea. It seems require a lot of state in = the network. State is expensive. What happened to KISS principle? --=20 Mikael Abrahamsson email: swmike@swm.pp.se From luismi.diaz@alcatel-lucent.com Fri Nov 12 01:28:50 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44E728C124; Fri, 12 Nov 2010 01:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sxscHnMoaog; Fri, 12 Nov 2010 01:28:44 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 0383728C0FF; Fri, 12 Nov 2010 01:28:43 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAC9TDEJ015825 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 12 Nov 2010 10:29:14 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 12 Nov 2010 10:29:13 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: Mikael Abrahamsson , "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" Date: Fri, 12 Nov 2010 10:29:12 +0100 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuCHXEVdMuY61w2Szq8gwmN/6jItQALTR4w Message-ID: <3349FECF788C984BB34176D70A51782F168780B4@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F9C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , Ingemar, httpstreaming , "conex@ietf.org" , Johansson S , Kathy McEwen Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 09:28:50 -0000 Q-HTTP is not only about testing. If you read that in detail, it has also t= he messages to alert when something is out of the line. And it also alerts = (optionally) a third entity (besides user and SP) to react. As we implemented this on the lab, we have an external policy manager that = received this alert message, and by means of a policy change make the netwo= rk in between to consider that specific flow or flows (as described in the = alert message) to be treated in the same forwarding class as Broadcast TV. = Everything keeps at best effort until congestion happens. Then, Q-HTTP aler= ts of SLA violation and this policy manager changes user profile. Real-Time= flow (a virtualized game) keeps just playing with no problem (1 second of = freeze) while other user (non-Q-HTTP) can't simply play, the game is just c= razy (character is not moving or not stopping). This was SIMPLE because it was based in the tools we already have in play i= n some ISPs (lab was based on a real-field network from a big ISP in Spain,= with ADSL, aggregation, edge and core network). Simplicity is not measured= by the number of pages ;). Of course, this is just a POSSIBLE implementati= on, not the only one. And testing is just a MUST. We need to know what is going wrong for THAT fl= ow, because not all the applications/flows have the same requirements. And yes, i also think that Q-HTTP is not a good name :D Saludos, Luismi -----Mensaje original----- De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre = de Mikael Abrahamsson Enviado el: viernes, 12 de noviembre de 2010 4:55 Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; = Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP On Fri, 12 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: > Since several years ago, ARPU is frozen and even it has been reduced a=20 > little. But traffic grows each year, and as you say, profit goes down.=20 > I have check ARPU from Spanish operators and they are reduced Yes, but the ARPU doesn't go down because traffic increases, it goes down d= ue to competition and increased market penetration. > Each year, a little, but the investments in network must increase to supp= ort the traffic growing. Yes. That means profit is down. > Priorization reduce queue times, with network full or not. For=20 > example, IPTV services offered by operators uses priorization. But do=20 > not reduce QoS to priorization. There are more operations involved in QoS= . Prioritization on the access line is good. Prioritization done because you = want to flatline your distribution/core at peak times is bad. > online gaming, in which latencies sometimes makes not possible to play=20 > against users located in other countries, and in that case constraints=20 > are not very restricted , however without QoS, they are impossible to=20 > achieve today. With hot potato routing, high latency to other countries depend on either b= ad network design or physical constraints when it comes to speed of light i= n fiber. QoS can't solve neither. > Hard-core gamers have a high willingness to pay for virtualized games,=20 > but today content providers can not offer virtualized games because=20 > there is not QoS on demand in Internet. Hard-core gamers won't accept 50ms of keypress/action delay. > Have you read the draft? I promise you that Q-HTTP perhaps has an=20 > horrible name, but it is KISS, for sure. It is application level, and=20 > Q-HTTP alerts can be used for a lot of possibilities from adapting=20 > mechanisms ( reduce bitrate or functionalities) to priorization ,=20 > reservation, or whatever. It is not said what to do with the alerts in=20 > the draft. It is only a powerful tool. I started reading the draft but fell ill after reading it a while. It seems= to do a lot of testing. We don't need more testing, we need performance in= formation for existing traffic, not more test traffic. And yes, Q-HTTP is HORRRIBLE name. And no, it's not KISS. Just the size of = the draft and the number of sections says it's not KISS. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From henry.sinnreich@gmail.com Fri Nov 12 14:53:42 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BF503A6A27; Fri, 12 Nov 2010 14:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPB2h96laebu; Fri, 12 Nov 2010 14:53:41 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 2A4B23A69CE; Fri, 12 Nov 2010 14:53:41 -0800 (PST) Received: by gwb10 with SMTP id 10so1946507gwb.31 for ; Fri, 12 Nov 2010 14:54:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=1HLcBErjOlxUfxFyeNXBWeLA8X4pDTs3/EiH3pwFxEY=; b=kU6KJ9vdq0rumbJu6Fv5miE+gVxxd8tq+KeCLBGTM1eHPozkYqpT4hH53teYC22Z6a MThrfF1v5+FnOo5WnJy76QzY7wala0vlx0paHxxOnfJeCicaQ+ybBoZGa57ig03+eMWO n6irQ2o/LsEMaruK/N2gfhx3g1nziBqJ6TwMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=YGLmpNqZBRg5It+Vb+rHVg9SMrB9iMMuybdrskktv49m0DESNYiCSFyjLMhqoniiA+ 7K5ieOHwrxw/DqDJWhilvYfRmu67EiZVUUIahf4QpXkZ2uPkRpjXw9lPurr1mJ/S1ZHc pgHmZs511NCWBUikIyDMuxUDRySplF4ETZlKg= Received: by 10.90.59.17 with SMTP id h17mr3916525aga.133.1289602454756; Fri, 12 Nov 2010 14:54:14 -0800 (PST) Received: from [192.168.0.34] (cpe-76-184-225-216.tx.res.rr.com [76.184.225.216]) by mx.google.com with ESMTPS id r25sm2703082yhc.0.2010.11.12.14.54.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 12 Nov 2010 14:54:13 -0800 (PST) User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Fri, 12 Nov 2010 16:54:05 -0600 From: Henry Sinnreich To: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" , Mikael Abrahamsson , "Mike Hammer (hmmr)" Message-ID: Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuBxFjYih2YrN4ESN+MSuHYLVkpagABEd4QADz4Uh8= In-Reply-To: <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Johansson S , Kathy McEwen , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , Ingemar@core3.amsl.com Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Nov 2010 22:53:42 -0000 > I dont see any drawback in trying to anticipate to the future needs... Yes, but who is supposed pay for this anticipation? And how do we know the anticipation is not wrong? This falls into the risk area for business plans, but not for making standards based on anticipation. > I dont think real-time was in mind whe Internet was created Wrong >and we need to > provide ISPs with new tools like this. Wrong again IMHO. ISPs would be better advised to fully utilize fiber. Thanks, Henry On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" wrote: > Hi, > Just a different approach. Think in a traffic jam. I know it would be nice > to live in a wonderful world with no jams, but they happen. Know compare you, > going back home from work, and an ambulance with someone dying inside. > Everybody gets away to let ambulance drive first. And that's OK. > > Now think on Internet. You are playing a Real-Time game and your neighbours > are just downloading files. They can afford some amount of traffic loss > (+delay/jitter) since TCP retransmisions will do the trick (just will take a > little longer to get the job done) while you cannot afford losing > (+delaying/jitterin) your traffic because if it happens, your opponent will > blow you away from the arena. That's the point, all traffic flows are NOT the > same and need different SLAs. > > Q-HTTP tries to address both problems: > > - Enable subscriber to measure the SLA is being provided. This by itself is > nice, since allows e2e players to solve the problem (reducing bit-rate of > video if possible, for instance) > - Enables network operators to generate more revenue for "over-requirements". > I dont think real-time was in mind whe Internet was created and we need to > provide ISPs with new tools like this. > > I dont see any drawback in trying to anticipate to the future needs... > > > Saludos, > Luismi > > -----Mensaje original----- > De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre de > Mikael Abrahamsson > Enviado el: jueves, 11 de noviembre de 2010 18:16 > Para: Mike Hammer (hmmr) > CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; > Kathy McEwen; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) > Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP > > On Thu, 11 Nov 2010, Mike Hammer (hmmr) wrote: > >> I think the crux of our disagreement here is the difference between >> what it takes to be an ISP and what it takes to be an access provider. >> The economics are different. Apples and oranges. Saying it works for >> oranges means it makes sense for apples is a non-sequitor. > > For me an ISP is one who runs active equipment, L2 and up. Sometimes ISPs own > L1 as well. What do you mean by it? > >> >> It is nice that you have a regulated monopoly of L1 in your market, >> but > > It's not a monopoly. Well, the copper is mostly, but the fiber isn't. > >> However, comparing blocking (dial-tone means nothing, busy signal >> does) of QoS guaranteed telephone links with non-QoS based congestion >> is self-contradictory. You are in essence saying that on the one hand >> providers should not have the tools to provide QoS guarantees and on >> the other hand slapping them for not being able to provide a QoS guarantee. >> Now how fair is that? > > I don't want QoS guarantees, I want *all* my packets delivered, expediently, > regardless if my neighbour is filling up his pipe or not. I have paid for it, > and I want it DELIVERED. The postal office doesn't get to choose which of my > letters it's ok to delay or throw away, they should just deliver them. Same > with my ISP. > >> I would not be so quick to deride the advertizing as false as not very >> clear, but I do think there could be better education of the public. >> (Have you never tried to explain this to a non-techie and watched >> their eyes glaze over?) > > That's why the IETF should work on tools to show this to people, not give ISPs > tools to screw their customers. > >> As for treating traffic equally, you apparently don't care much about >> real-time interactive applications. That is your choice. But, please >> don't impose that on everyone. > > I am fine with packet prioritization within my access line. I have AQM on my > own access line, because it makes my access line perform better for my packet > mix (prioritizes my VoIP and ssh before my data heavy TCP sessions). > > The problem I'm having here is that most talk is not about how to make the > customers access line behave better for the customer, it's to have certain > customers traffic be lower prioritized in the distribution and core, so ISPs > can oversubscribe more without customers being able to notice too much. > > I resent that. From jgunn6@csc.com Sat Nov 13 06:47:35 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C48403A6BB0; Sat, 13 Nov 2010 06:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNDOklo3fK8i; Sat, 13 Nov 2010 06:47:34 -0800 (PST) Received: from mail130.messagelabs.com (mail130.messagelabs.com [216.82.250.163]) by core3.amsl.com (Postfix) with ESMTP id 5CE323A6BA9; Sat, 13 Nov 2010 06:47:34 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-5.tower-130.messagelabs.com!1289659688!33069630!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 2210 invoked from network); 13 Nov 2010 14:48:09 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-5.tower-130.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Nov 2010 14:48:09 -0000 Received: from amer-gwdr06.amer.csc.com (amer-gwdr06.amer.csc.com [20.137.52.154]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id oADEm71a032096; Sat, 13 Nov 2010 09:48:07 -0500 In-Reply-To: References: <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: Henry Sinnreich MIME-Version: 1.0 X-KeepSent: CC8141E5:3BFB9BA9-852577DA:005012E0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Sat, 13 Nov 2010 09:48:04 -0500 X-MIMETrack: Serialize by Router on AMER-GWDR06/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 11/13/2010 09:48:08 AM, Serialize complete at 11/13/2010 09:48:08 AM Content-Type: multipart/alternative; boundary="=_alternative 00514FF9852577DA_=" X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , httpstreaming , dispatch-bounces@ietf.org, "conex@ietf.org" , Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" , Ingemar@core3.amsl.com Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 14:47:35 -0000 This is a multipart message in MIME format. --=_alternative 00514FF9852577DA_= Content-Type: text/plain; charset="US-ASCII" > On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" > wrote: > > > Hi, > > Just a different approach. Think in a traffic jam. I know it > would be nice > > to live in a wonderful world with no jams, but they happen. Know > compare you, > > going back home from work, and an ambulance with someone dying inside. > > Everybody gets away to let ambulance drive first. And that's OK. > > > > Now think on Internet. You are playing a Real-Time game and > your neighbours > > are just downloading files. They can afford some amount of traffic loss > > (+delay/jitter) since TCP retransmisions will do the trick (just will take a > > little longer to get the job done) while you cannot afford losing > > (+delaying/jitterin) your traffic because if it happens, your opponent will > > blow you away from the arena. That's the point, all traffic flows > are NOT the > > same and need different SLAs. I think your analogy is completely backwards. Yes, everyone gets out of the way of the ambulance, because the ambulance is more important. But the real time game is NOT more important than downloading the file that contains the information on how to turn off the flow of the natural gas pipeline when there is an explosion. What you are proposing in your analogy is not that "everyone should get out of the way of the ambulance", but that "everyone should get out of the brand new Ferrari so it can race with the Maserati." Janet --=_alternative 00514FF9852577DA_= Content-Type: text/html; charset="US-ASCII"



> On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)"
> <luismi.diaz@alcatel-lucent.com> wrote:
>
> > Hi,
> >    Just a different approach. Think in a traffic jam. I know it
> would be nice
> > to live in a wonderful world with no jams, but they happen. Know
> compare you,
> > going back home from work, and an ambulance with someone dying inside.
> > Everybody gets away to let ambulance drive first. And that's OK.
> >
> >    Now think on Internet. You are playing a Real-Time game and
> your neighbours
> > are just downloading files. They can afford some amount of traffic loss
> > (+delay/jitter) since TCP retransmisions will do the trick (just will take a
> > little longer to get the job done) while you cannot afford losing
> > (+delaying/jitterin) your traffic because if it happens, your opponent will
> > blow you away from the arena. That's the point, all traffic flows
> are NOT the
> > same and need different SLAs.
I think your analogy is completely backwards.  Yes, everyone gets out of the way of the ambulance,
because the ambulance is more important.

But the real time game is NOT more important than downloading the file that contains the
information on how to turn off the flow of the natural gas pipeline when there is an explosion.

What you are proposing in your analogy is not that "everyone should get out of the way of the ambulance",
but that "everyone should get out of the brand new Ferrari so it can race with the Maserati."

Janet --=_alternative 00514FF9852577DA_=-- From jose_javier.garcia_aranda@alcatel-lucent.com Sat Nov 13 08:26:20 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A4F3A6BB8; Sat, 13 Nov 2010 08:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.537 X-Spam-Level: X-Spam-Status: No, score=-5.537 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+gGw9GxL6z7; Sat, 13 Nov 2010 08:26:19 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 7FBF43A6917; Sat, 13 Nov 2010 08:26:18 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oADGQUIx005728 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sat, 13 Nov 2010 17:26:31 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sat, 13 Nov 2010 17:26:31 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: Janet P Gunn , Henry Sinnreich Date: Sat, 13 Nov 2010 17:26:26 +0100 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuDQcy6bNFn7oj2SJeZnO8E6ZQihAAC+Yrw Message-ID: <3349FECF788C984BB34176D70A51782F16B12E33@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_3349FECF788C984BB34176D70A51782F16B12E33FRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "dispatch-bounces@ietf.org" , "conex@ietf.org" , Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" , "Ingemar@core3.amsl.com" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Nov 2010 16:26:21 -0000 --_004_3349FECF788C984BB34176D70A51782F16B12E33FRMRSSXCHMBSB3d_ Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F16B12E33FRMRSSXCHMBSB3d_" --_000_3349FECF788C984BB34176D70A51782F16B12E33FRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi Janet i like your example about the explosion :-) in my oppinion : if the files about the way to avoid the explosion are so important, then these files could be downloaded using SLA , and for sure the user or t= he content provider will pay for that. user-----(pay per FTP with quality)---->content provider-------(pay for qua= lity)--------> ISP user-----(pay per game with quality)---->content provider-------(pay for qu= ality)--------> ISP user----( no pay anything)----->content provider ------( no pay for quality= )----->ISP video or videogame is not more important than FTP, and FTP is not more impo= rtant than video. It depends on how much the content provider or the user is willing to pay = for it with QoS in addition, Q-HTTP also may be used for detect packet loss and adjust FTP = bitrate, or change parallel FTP for sequential FTP. Q-HTTP is a tool. The decision to t= ake when Q-HTTP alerts is open i have attached an image named Q-HTTP_phases.jpg for quick understanding - jose Javier ________________________________ De: Janet P Gunn [mailto:jgunn6@csc.com] Enviado el: s=E1bado, 13 de noviembre de 2010 15:48 Para: Henry Sinnreich CC: conex@ietf.org; dispatch@ietf.org; dispatch-bounces@ietf.org; Mike Hamm= er (hmmr); httpstreaming; Ingemar@core3.amsl.com; Johansson S; GARCIA ARAND= A, JOSE JAVIER (JOSE JAVIER); Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUI= S MIGUEL); Mikael Abrahamsson Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP > On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" > wrote: > > > Hi, > > Just a different approach. Think in a traffic jam. I know it > would be nice > > to live in a wonderful world with no jams, but they happen. Know > compare you, > > going back home from work, and an ambulance with someone dying inside. > > Everybody gets away to let ambulance drive first. And that's OK. > > > > Now think on Internet. You are playing a Real-Time game and > your neighbours > > are just downloading files. They can afford some amount of traffic loss > > (+delay/jitter) since TCP retransmisions will do the trick (just will t= ake a > > little longer to get the job done) while you cannot afford losing > > (+delaying/jitterin) your traffic because if it happens, your opponent = will > > blow you away from the arena. That's the point, all traffic flows > are NOT the > > same and need different SLAs. I think your analogy is completely backwards. Yes, everyone gets out of th= e way of the ambulance, because the ambulance is more important. But the real time game is NOT more important than downloading the file that= contains the information on how to turn off the flow of the natural gas pipeline when th= ere is an explosion. What you are proposing in your analogy is not that "everyone should get out= of the way of the ambulance", but that "everyone should get out of the brand new Ferrari so it can race w= ith the Maserati." Janet --_000_3349FECF788C984BB34176D70A51782F16B12E33FRMRSSXCHMBSB3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi Janet
 
i like your example about the explosion=20 :-)
 
in my oppinion :
 
if the files about the way to avoid the explosio= n are=20 so important,
then these files could be downloaded using SLA ,= and=20 for sure the user or the
content provider will pay for that.
 
user-----(pay per FTP with quality)---->= content=20 provider-------(pay for quality)--------> ISP
 
user-----(pay per game with=20 quality)---->content provider-------(pay for quality)-------->=20 ISP
 
user----( no pay anything)----->content provi= der=20 ------( no pay for quality)----->ISP
 
 
video or videogame is not more important than FT= P, and=20 FTP is not more important than video.
 It depends on how much the content provide= r or=20 the user is willing to pay for it with QoS
 
in addition, Q-HTTP also may be used for detect = packet=20 loss and adjust FTP bitrate, or
change parallel FTP for sequential FTP. Q-HTTP i= s a=20 tool. The decision to take when Q-HTTP alerts is open
 
i have attached an image named Q-HTTP_phases.jpg= for=20 quick understanding
 
- jo= se=20 Javier 
 
De: Janet P Gunn [mailto:jgunn6@csc.com]
Enviado el:= =20 s=E1bado, 13 de noviembre de 2010 15:48
Para: Henry=20 Sinnreich
CC: conex@ietf.org; dispatch@ietf.org;=20 dispatch-bounces@ietf.org; Mike Hammer (hmmr); httpstreaming;=20 Ingemar@core3.amsl.com; Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIE= R);=20 Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); Mikael=20 Abrahamsson
Asunto: Re: [dispatch] [conex] [httpstreaming]=20 Q-HTTP





> On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LU= IS=20 MIGUEL)"
> <luismi.diaz@alcatel-lucent.com> wrote:
>
= >=20 > Hi,
> >    Just a different approach. Think in a tr= affic=20 jam. I know it
> would be nice
> > to live in a wonderful w= orld=20 with no jams, but they happen. Know
> compare you,
> > goin= g=20 back home from work, and an ambulance with someone dying inside.
> &g= t;=20 Everybody gets away to let ambulance drive first. And that's OK.
> &g= t;=20
> >    Now think on Internet. You are playing a Real-Ti= me=20 game and
> your neighbours
> > are just downloading files. = They=20 can afford some amount of traffic loss
> > (+delay/jitter) since T= CP=20 retransmisions will do the trick (just will take a
> > little long= er to=20 get the job done) while you cannot afford losing
> >=20 (+delaying/jitterin) your traffic because if it happens, your opponent=20 will
> > blow you away from the arena. That's the point, all traff= ic=20 flows
> are NOT the
> > same and need different=20 SLAs.

I think your analogy is complet= ely=20 backwards.  Yes, everyone gets out of the way of the ambulance,= =20
because the ambulance is more important.= =20

But the real time game is NOT more important tha= n=20 downloading the file that contains the
information on how to turn off the flow of the natural gas pipelin= e when=20 there is an explosion.

What you are= =20 proposing in your analogy is not that "everyone should get out of the way o= f the=20 ambulance",
but that "everyone should ge= t out=20 of the brand new Ferrari so it can race with the Maserati."=20

Janet --_000_3349FECF788C984BB34176D70A51782F16B12E33FRMRSSXCHMBSB3d_-- --_004_3349FECF788C984BB34176D70A51782F16B12E33FRMRSSXCHMBSB3d_ Content-Type: image/jpeg; name="Q-HTTP_phases.jpg" Content-Description: Q-HTTP_phases.jpg Content-Disposition: attachment; filename="Q-HTTP_phases.jpg"; size=83782; creation-date="Sat, 13 Nov 2010 17:23:43 GMT"; modification-date="Sat, 13 Nov 2010 17:23:43 GMT" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCALsBAwDASIA AhEBAxEB/8QAHQABAQEBAQEBAQEBAAAAAAAAAAYHBQgEAwIBCf/EAGMQAAAFAwIBAw0LCQUEBwUH BQABAgMEBQYRBxIhEzFRCBQWFyIyNkFxdJay0hU1VVdhdZW0wtPUIzdSVFaSk5S1M0JTgbMkYnaR GDRjcqGx0QklOEOCJicoOUR3hGRzhaLB/8QAGwEBAAEFAQAAAAAAAAAAAAAAAAYBAgMEBQf/xABA EQACAAMCCQkIAgAGAwEAAAAAAQIDEQQFEiExNEFScaGxExVRU2GBkdHhBhQWMjNjwfAiciNCQ5Ki 8WKC0iT/2gAMAwEAAhEDEQA/APZYDNdVDMq9HIjPHWpesoSO5XSY49pveGRNctw1p2kjsns/7xJh m8pSvZ6m8AMH3K6TDcrpMYOfodTebHwx93d6m8AMH3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XS Yc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+GPu7vU3gBg+5XSYbldJhz9Dqbx8Mfd3epvADB9yuk w3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6m8AMH3K6TDcrpMOfodTePhj7u71N4AY PuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+GPu7vU3gBg+5XSYbldJhz9Dqbx8Mfd3e pvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6m8AMH3K6TDcrpMOfodTePh j7u71N4AQmkpmaKkRmZ8Wvti7HYs07l5SmJUqR622X3WfFJrWmnuqAABnNUAPhuAzKg1AyPB9au+ oYxXcrpMc+3XgrI4U4a1Oxdl0+/QxRYdKdlfyjeAGD7ldJhuV0mNDn6HU3nT+GPu7vU3gBg+5XSY bldJhz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6m8AMH 3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+GPu7vU 3gBg+5XSYbldJhz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx 93d6m8AMH3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1 N4+GPu7vU3gBg+5XSYbldJhz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0m HP0OpvHwx93d6m8AMH3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpM Nyukw5+h1N4+GPu7vU3gBg+5XSYbldJhz9Dqbx8Mfd3epvADB9yukxrdgmZ2lBMzMzwv11DdsV5K 1xuFQ0oc+8rn9xlKZh1q6ZKdPazugADpHEAAIXVozJFNwZlxd+yMFpnchKcxqtDasVl96nwya0rp 7ql0AwfcrpMNyukxx+fodTeSH4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6m8AMH3K6TDcrpMOfod TePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+GPu7vU3gBg+5XSYbldJ hz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6m8AMH3K6T DcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+GPu7vU3gBg +5XSYbldJhz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6 m8AMH3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+G Pu7vU3gBg+5XSYbldJhz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0O pvHwx93d6m8AMH3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyuk w5+h1N4+GPu7vU3gBKaWmZ267kzP/aleqkVY7UmZysuGPpVSOWqR7vOilVrQzTVX3/j+ap9dQkRX aq+/8fzVPrqEiIhemdR/uhE+unM5ewAADQOgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABfaSd7U/K19sXYhNJO9qfla+2LsTW7M1g/dJ59fefTO7ggAAN45R8Nw+8FR81d9Qxig2u 4feCo+au+oYxQRy/vmg7/wAEw9mfpTNqAAAj5JgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1ywPBGD5F+uoZGNcsDwRg+RfrqHbuL60Wz8kf8AaTNY f7LgzugACUEJAhNW+8pvld+wLsQmrfeU3yu/YGjeWaxnVuTPpffwZAgACFHoIAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGm6WeDr3nSv VSKwSelng6950r1UisE5sWbwbEec3rnkzaZpqr7/AMfzVPrqEiK7VX3/AI/mqfXUJERW9M6j/dCJ tdOZy9gABE6eX72W3PdlE9yesux6b1ryvXHKdcd26ndjaW3+yzjJ8/yDThlxRQuJLEspuRzYIIoY G8cWTuxlsAiaxfvufq9RtP8A3J5T3ThKlde9cY5PBPHt5Pbx/sefcXffJxtgjlxQUwllVRLmwTG1 C8jo9oAAFhkAAJvU26OwuyKhc3WHX/WfJ/7PyvJb97qUd9tPGN2ebxC6CBxxKGHKy2ZHDLgccWRY ykAc21qp7uWxSq3yHW/uhCZlclu3cnyiCVtzgs4zjOCHSFGnC6MrDEokmtIARNIv33Q1erOn/uTy XuZCTK6964zymSZPbye3h/bc+4+9+XhbC6OXFLphLKq+JZLmwTU3C8ja71lAAJvU26OwuyKhc3WH X/WfJ/7PyvJb97qUd9tPGN2ebxCkEDjiUMOVl0yOGXA44sixlIA5trVT3ctilVvkOt/dCEzK5Ldu 5PlEErbnBZxnGcEOkKNOF0ZWGJRJNaQAAKFQACJ1kv3td2xGrfuT7p8vNTF5Lrjkdu5C1bs7VfoY xjx/IL5cuKZEoIVjZjmzYJMDjjdEi2AAFhkAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT8rX2xdia3Z msH7pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf+CYezP0pm1AAAR8kw AAAAAAAAHAsu8ravKJIlW3U0z2o6ybdMmltmhRlkspWkjwfTjHA+gx+lvXXQLgqlWplIn9cy6Q9y E9vkVo5Fe5acZUkiVxQrikzLh5Be5UcNap4svYY4Z0uKjUSdcmPLsO2AALDIAAAAAfy4tDadziko IzJOVHjiZ4Iv8zMiHGmXXQIl3w7SkT9lamsm/Hjcis96CJZme4k7S/s18DMj4fKQrDDFFkRbFHDD 8zodsAH8uLQ2nc4pKCMyTlR44meCL/MzIhQuP6AcSZddAiXfDtKRP2Vqayb8eNyKz3oIlmZ7iTtL +zXwMyPh8pDtirhcNKrKWwxwxVwXWgAAFC4AAgKrrJptS6pLpk64+RlxHlsPt9YyFbFoUaVFkmzI 8GR8SPAvlyo5jpBC3sMc2fLlKsyJLa6F+AnHb5tNu0n7rKtx3aKwpKXZTKVOEgzUSSI0pI1ZypPD HjHapU6LVKXFqcF3loktlD7Dm0070LSSkngyIyyRlwMsijlxQqrRWGbBE6QtPT3dJ9IAAtLwAAAA AAAAAAAAAAAAAAAAAAAAAA1ywPBGD5F+uoZGNcsDwRg+RfrqHbuL60Wz8kf9pM1h/suDO6AAJQQk CE1b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+l9/BkCAAIUeggAAAAAfjPlxYEN6bNkNRozKDW666 okoQkuczM+BECVQ3TGz9gEjRtTLCrFTOmU+6Ke7K37EoNRo3q6EmoiJX/wBJmK4XRy4oHSJULJc2 CYqwNPYAABaXgB/Li0NNqccUlCEEalKUeCIi5zMxxriuugW/VKTTKvP62l1d7kIDfIrXyq9yU4yl JknitPFRkXH5DxWGGKJ0hVS2KOGBVidEdsAAULgADiTLroES74dpSJ+ytTWTfjxuRWe9BEszPcSd pf2a+BmR8PlIVhhcWRFsUcMPzOh2wH8pWhalpSpKjQe1REedp4I8H0cDI/8AMf0KFwABAVXWTTal 1SXTJ1x8jLiPLYfb6xkK2LQo0qLJNmR4Mj4keBfLlRzHSCFvYY5s+XKVZkSW10L8BOO3zabdpP3W Vbju0VhSUuymUqcJBmokkRpSRqzlSeGPGO1Sp0WqUuLU4LvLRJbKH2HNpp3oWklJPBkRlkjLgZZF HLihVWisM2CJ0haenu6T6QABaXgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABpulng6950 r1UisEnpZ4OvedK9VIrBObFm8GxHnN655M2maaq+/wDH81T66hIiu1V9/wCP5qn11CREVvTOo/3Q ibXTmcvYB5esuo6j0/U7Uftf0Cm1flK051714sk8nh5/k9uXUc+V55+Yubx+oRnmlljVa1bxves1 CRCdj1+oFJipYWo1oTyjysLI0kRHhxPMZ8xi2yzoZUuZVJ1SxPTjKW2zxzpsrBbSTdWtGJ/9GXUO bes/qn7UevujwqVUyp7yWmYiiUhTPJSTJR4WvjuNZc/iLh00V/RbEkX/AFJu+q/ULneUSDhUGCxI xAIi8ZMqwajJRcT2nxPhx4V9dsarT9dqBfbMiEmm06nrjPNLWonlKNL5ZSRJ2mX5VPOouYxzmrEv S3b9rtfs6q0I4tfdJ2WiqsvLcjqLJ/k9h91xUrgZpIiwWOA2naJcUUMSeC8HRix1yVxtfqNFWWbB DFC4cJONvHjxUWOlUnjxdmWhB6Y1qZO0/wBXqQtdRKnU+LJOCxUFKVIjIW1ILkl7jPBkTacp8R7u kcm1tOk1rqf0XdMuSsoepkSXLpsRl1KY7BsuOq73bk1GpKj3EZHxLoGjWtpdcdGjahx5NWp09V1Q 1JakmS21dcKQ7uNaCSZJSa3lcxqPBFwHdtOxqtSdCXrEkyIS6kunzYxOtrUbO55TppPJpJWC3lnu fEfOMky1wQNuXFlih8KY95jlWGZGoVOheKGJd+Fi3ZDPqxf9cg9SrR6x12/7rVFZ01MtKj5RJJcd TvNRnncaGTLdnO48+T4NWtJm7O0sq1YhXTXJL6uQ90WZDxKYlGbzZZ27SMjJW0yMzM+5wNEo+lzj uhLGnddlRylNpdMpMbctDbhvrcQotxJMyLcRGXDxl8ola9pZqxX7UlUOt39AmMNGgoUfktiHSStO FPOE3v4JJR47rutvEJU+XDM/hEoVhNvtVVSmL9yidZp0Uv8AnA4m4El2OjrXHp35D/L+butWien7 1AiTp1OZhQl1aJBWtD77RMt4SSkd0ST7ojMiPGSPxGOfpTVLBevult2XUqtZ8hLjjc2hzUOPNT1Y LgSlOGSFFg+J8ckXDhx06bZddc0/tqkU25HqPWKIxFTy0ZxZx31NISlSHEkad7Zmnx/8uJkORGsK 6rivKi3Jf8q3iXRHFOxWKOy6XKr7k0qcW5x4GkjIiLxfKYxw2iXycULdMuTtyVVKPboMsdlmqbDH DDX5cvZStHVOHZjTIebbjt1dVJd1JKs1Ckx1UxpclyC4SHXWyai/kyUZHgjUaTPhzJx4x19E471o a03RpxEny5dGiQkS46ZKyUptR8io8YIiLPLHnBFnBCxoVjVaBrtX77ekQlU2o09EZlpC18slRJYL KiNO0i/JK5lHzl8uFCsarQNdq/fb0iEqm1GnojMtIWvlkqJLBZURp2kX5JXMo+cvlwjtMMUDgbxY C/3Km8rLsccExTFD/LlH/tdd2Qz6sRNPHrhrHZVV63flfRJW403SmJJdYFzE02Ta9hKI0+M/EWSL Bjg0yt1Ot9SHcqqrLdluQ6i3GbddWa1mjloyyI1GZmeDWZF8mC8Q0W1dPr+s5yqUm16/QEUWoSnJ RSZkZ12YwpREWCIlElWEpTxUfE8nghz6bpDcNP0buewmp9LcdqFSTJgyFOOEnkyWyf5TuO5Vta5k 7iyfP4xlhnyVROKtHC1sWXFRJbDXis094TUFKwxp06WsWOrb2smNIp0fUa5aBQ7lbdZptvUZhymU 1xsyRNcQlLa31HzKIjSeC6DPoVn6daKu9cWrD9lTo12v0KmwUuOQ7ejE48+4okq3qI+BtkSyTky4 GWMcci6rGnNYKiWPMokmnx7mtdlhhTrilExIbJskOt7iQZ4Vg8Htzgz5s8P21I0+uCp3VHvKyrgZ odeaiHFd5Vre0+nOSIzMjxjm4pPOC5sCxWiS5yjToqNLsdcvf0mR2SerO4Gquqb/APJUyZdHR0Lt OH1Pb9eg16t0CRTbuat8m0SKW7X4i23UGRJSts1d7znkkkfMkzwXEaHqn+bG6vmWZ/orHO0yti6a KqdUrwuyRXanN2EbSVGmLHIi4k2jBJIzPnMkp5ubnz0dU/zY3V8yzP8ARWNOdHDHaU12ZDoSJcUu xuGKuR5cukw/SjSVi9dKqRVp90Vph9BvHTmGHkkxFNLzmD2mkzNRr3KyRkfH5Bwb8umZdnUyUWVU XzkTYdwJhvuqLis0sOqSZ9J7VpyfjHf0ks/UWoaW0p+0r5RTKZUjf67iyGSWbJk64gzaVtMyySSP aRp4mZ54ivvnRyTK0hpFjWxMiJdhT0y3n5qlIJ09jpKPuUqweVlgscxc46kU+CCf/iRp0ixdix1r i/cpxYLLMmWb/CgarBj/APJ4qUx7eBH6yWpL01YpOoMK6a5Ua8uoNsS3JT5bHSNK3DSREkjJGUY2 mZlg/kGia3ooK5lH7LLvep1EysnaNHbc5WpKPucZbVu2lkuG0y4nxLPD7dfbGq1/2dEo1GkQmJDN QRJUqWtSUGkm3EmRGlKjzlZeLpH86k2NXKredFvW1p9PZrFJaWyiPUkLVGdSrcWT2cUmRLXzFk+5 4lgacM+GNS3HFSJYXpoxbdB0I7LHKc2GXBWF4OLH3vKq6KquMzbT+qU6k9UBR6FZsKt0m3Z8B0nY VQ5ZKHFkh1fKtocUZ4y2ktx+MlkJ+ZKgUu46kjWi3Lhkzlz1HBrEeQ8llhJ4xySSWSdpY3Fg1H4s ZTx1ZnT69H9WKBf1ZrFGlvQ23GJMdhpxlDTRtrSkms7jWeXFmZqNPiH2P2vqVSZs+Pb9xUeq0ifI U6aLhJ996IlWC2NmRmS0lg8JVguBdJmM3vMtRJp5YVV1adU3ppxWM1/c5zgacLxROiomqNKn8a9P Q8RI3Pd822upzYmUS7XrifkySgsVbrY2nWknuUZLJSjMlJJJpJR8eKfKJCmRapa9bpdatGharrml MQqqoqtNVyElnBk5wbyZq6N2enOSIa1A0epcbR+RYKpyluSVnIcm8nzSOGFknPMW1JYzxIucfBQb C1SXVYTFy6kLcocB1DjbcAjZfkkku8cWlKT2nwI8qXkug8GKS7RJhhiSayutdK0ZFuxFZtktEUUD iheRUpjwWsuNvfj6DXgABxSRF9pJ3tT8rX2xdiE0k72p+Vr7YuxNbszWD90nn1959M7uCAAA3jlH w3D7wVHzV31DGKDa7h94Kj5q76hjFBHL++aDv/BMPZn6UzagAAI+SYAAAAAAAPKPU/SHrTt1q+0u H7mKrKqVWknzIYW20bL3EyItjizzzmZLMUWnlys2lV9a7kcbJ9MOqJU2jJ4WtUiSlBZIjwRqUksi /wBGdNpdradVW07nXAmpqEt1xZRlKUg2ltNowZqSk89wfi6BwtONF5lHot6UK5J8WZCr5NIYdYUp bqeTU6ZLWS0kRLI1IVwM+JGO7OtMiZFMcT0rvVU92MjUix2mVDJUCyKJ7IsFrweLvr0knB1unU5y k1aZekCtpmPNFUqM3RnI/ue2pJ7zbex+UNJ8DIzPJ83DiNCua6bnrurTmnto1WLRfc+EUyoTnYhS F5M0GTaUKwWMOIyef7x8SwP8otj6hJZotAql2Qo9vUVTXJOUrl2JkxttO1LTp7tqU8xGRGecdOMc i/XaZR9Z11q37uoVDuNUBLNQi1xhxqLIZM0YWTuEpUrBJLBK47MZLChifIRzP8NKtH2rsqqLh0VM y95lyv8AFidG1po9NaNxN5aaVpofpa98XXD1juug3XVY71LolEVMU2xGQ2jKEsKNwjxvLKVqM0mo yI1GXiIfHTbj1Rrun0rU2HcVLgwmWpElmie5yXEONMqWStzpnv3dyrmwR4LmyPk0ohLr+u161N6p Ra5AepKYkidGThh1biWcoRxMtpEhaS4meElz847MbTfUOl2rIsKkXJQjteQl5vrmRGcOay04ajUg kkexWdx5MzLvj5uArHyMESWJOkNarFSmPRl3lspz5kLiWE4ax0o8da/xx1yZewjdTrhrF5T9KqzS 627TI9akpS3GSyS0RZjchtCnjI8crhSiIkqLBcmeO/MX0+5bppevVn2U9W+uoEmi8pP/ANkaR1y+ luRl3gkzRlTaT2pPBYx0heOk0lVEsxm0JkNmZaT5PRkzyUTMgzWhajc5Ms5NSMnjnyfTkunVLHrk /W2277XIpyYdOphxpTRLXyinTS+RmgtuDTl1POojwRi2KdIigSVKJR6MdcdPwXwyLTDMcTrVuCtH ipiwtPTXu7CMve+roiyaq7T79hnMpnLOrpVIoCprKEJUrah+SrvDwkyUZEnb3XQQmb9uK47zc0nr DFaVTPdiVyaWG45Kajy2pKGzkbTP8oWTSZIVwIkc/dGLqj6XXjRafXbUpdfo6bYrLrzrz70d1yek nEkhSC47T7giLcZmecngfH2oLoasmyo0aoUZNetSc7JY5Rbqor5LfJ3CjJBLIyNJFwLp48clllzb NA001i7NDT7OmnSzBNk2uYolEnRrJV5VEsmPorkouw7E+5bppevVn2U9W+uoEmi8pP8A9kaR1y+l uRl3gkzRlTaT2pPBYx0j47Zr+oOpCqxXLVuWn0OlU+e5FhRjgJkHM2JSrLi1HlJGSk8U/pH0ZHfq lj1yfrbbd9rkU5MOnUw40polr5RTppfIzQW3Bpy6nnUR4IxzYNhX5acuqxLErdCbo9VlrlLRUWHO WhKWREZtbO5UeC4ErBdyn5TGvhycFUphUWVYq1ddGWlDbcFownhYThwnkeOlFTTWla/kkbq1huKb oXTLsoslul1j3ZKnzjbYS4gzJlxZ7ScSZERlyavHjmzzjv6p3LqHp6zTbrqFeps6nyZqI0ikNU4k JaJSVLPa6ajWpREgyyeCzg8eIfndWiktej1Msi3Z0I5ceplPlSZe5pLyuTcSoy2JUee6SREfiTzi p19sarX/AGdEo1GkQmJDNQRJUqWtSUGkm3EmRGlKjzlZeLpGTlLLhwqFLBbirVaMVPQxOVbOTjcT eEoYaUenHXs26DQx5Mo1T9ztTtQf/uu7O+UrTv8A+m5XrPDz3/ZOY35+TvPH4vWYzzSyxqtat43v WahIhOx6/UCkxUsLUa0J5R5WFkaSIjw4nmM+Yxq2OdBKgmYWOqWLJXH2G7b7PHPmSlDio3V0Tpi7 cRklQtWt2/oHqBUqvTio6KvPjyI1KSojKIgpSOHDm74ix0ILmFLOqeoVraK0O84NwUxqDApcIipJ 04lk82tLbaTW8at27uiVhJJIubJ4yemawWzPvDTqqW5THYzMuXyPJrkKUlstjyFnk0pM+ZJ+LnHJ uyxqtVtCWbEjSISKk3T4UY3XFrJncypo1HkkmrB8meO56M48WzDa4ZihcymOLHsolp45TUjsMcqK JSq4oMTrT+VW9G3JkPhve9ZvY7b9TiXPTLXjViAiQk3ISps5xxwkGhDTBcDIt/FXHiZcBI21qpeL Lt3UJxp64ajSab17AeepRw3ne6bJXKMEZYIidJREREZpQfjMhR1TTS5WHLKr1v1KlJr9t0punrZn E4qI9hvYpRGkiUXfL44yfc82B/VD05vGHqPVrvkXHTyl1akqjOyYzBkqO/uRtNtpaVJUgktILulZ PJ8CFIHZoYGnR+ddlcnb3CZDbIpiaqtnRTLlpWvZ3nF06vK67kcpsynaj21U5UlaFTaHOgdaLjp/ +YlpacrWouYjMjLx/IPo1W1Scp2oLtnx7oj2pHiRUuyamumKmuKeVtUlpLZFgi2KIzUefHzGQ/Su aYXpdc2mtXTUrXQxT5Lb/ulTYTjVQkbeclK4JRnn7ngRkR44YFHdlj15q/VX5ZE2lR6u9D6zlx6k 0s2JCcpwo1N90SiJKS8fep5hVxWblE3TI+iiejHSnitoUFr5FwquVY3WrWmiwqrH0RbD89CdQXb4 gVePMfjypdKlcl11HZU0iSyo1cm6SFcUmexXc+LBcCGkiZ09t+r0Kny1V6vyazUpslUh5S3Fmyzk zw2yhRnsQXR/6ERUw51ocDmty8n7sOrZFMhkwqa6xfva+IAAGE2AAAAAAAAAAAAAAAA1ywPBGD5F +uoZGNcsDwRg+RfrqHbuL60Wz8kf9pM1h/suDO6AAJQQkCE1b7ym+V37AuxCat95TfK79gaN5ZrG dW5M+l9/BkCAAIUeggAAABjfVLOOTZ1jWs8l0qXWK0hE5SFmkjSS20kgzLpJxR8/OjPi4bIJTVCy Yd824VNflOwpUd0pEKW13zDySMiVjhkuJ5LJf5GRGWxZJkMudDFFk/cfcatulRTpEUEGXjjyd+Q+ KuaS6e1amIgOWxAiIQpKidhspZd4eI1pLJkfMeRytRrnrcK8Lc05tKVHhVGpsrccmyW+XVGZQlWF Ek+ClHya+Ks8U/Lw4q9N9Uq2aaddWpe6kNOpUkoEcm33CTxIzUSUmR56TV08RUagWHUKnWaFc1sV JiFXaGhbcc5iFONPtqSZbHDLuvGfdcT7pXDI2U4YYkpkzCy9LSdMWXtNOJRxQROVKcGSuRNquOlH 0ZMZyrYum56Dqsxp3d9VjVtU6CcuBUG4hR3FGW8zQtCcpLg2vjw70ufIm9Ha3qlqFY06ai8YVPeY nLZRKVSmnXVmTbatmC2oSks85pUZ7j5sELK0rGrzl/Ffl71CmSqw1E60iRqc0so8ZOVZMlL7ozMl K6Mblc4/vQKxqtYFnS6NWZEJ+Q9UFyUqiLWpBJNttJEZqSk85Qfi6BfHMkwwROGmF/HQqVx1pip0 FkuTPjmQqLCUH8tLrTFSrrXpppMR1Ivm4r10HptalT+tDara6bUI8dvYiYrkeUbWZ5yRJLJGnmM1 Z4bSGnX9X70tCv6a0Fdz+6DtUqa2KpJ6wZa66Qb7JJLZg9mEOGnKTIz5+fm4sLQ2uno1Ks6bVKai pFWjqcZxla1Mn+RS2SVmaCUX97mI8cOfiQrb3se67qrWn9ZlyKK1KoEzrmppaW6Ta/yjKjJkjSZn wbPvjLnLj0bEc2z4UMKpgpxaOlYt/wCOhGpLkWtQxRxJ4bUGnoePT0fnpZwrIuDUW770v2hQ7niU +LSqkpiPIdprby46OVeSlKEltJWSQWVLNWNpcDyY5S9Tbya051AZkT2Pd+1ZzEVFRaioInUqk8ka jQZGnJ7F+IiwoscSyL/Syxqtat43vWahIhOx6/UCkxUsLUa0J5R5WFkaSIjw4nmM+YxwKdpFUHka kxKxOhpi3XLKRDXHUta2drzrqDcSaUlkjWjgRnnBlkYuVs+G6pUWDTFsr+TNyNr5OHBbwnhp4324 OzRRnRvW66/TupyYu2HP5KtLplPfVJ5FB5W6pklntNO3jvVwxgs8MCbZvO9Kjf8AYtux7g60brtp IlyHOsmV4lLjvqJ7Bp8S0IVtIySe3HMZj7avp7qXVtLnLIm1u2URo7LMeHyLLxKebaWjbyqzztwl PMlB8SLjjI+6k6aV2JqLY1xuS6acS37fapktCXF8ot1LLyDUgtmDTlxPEzI8EfAUgdnggiq03/Kn hi0dJWNWqZMgookv4Vx9v8sj6MpEdTwxe1Q01umsUm63m5C33yYjuRW3VqmEhhZPKdcJRnuSXJmk yMuOckfEVNU1NqszRKgVWiS203NWpDNOZWbKTIpO/a4raZGkiPafix3RDuaPWbVdNINbp9RqVJct zl1zWJJqUh9vuUko3TURISkkoLiXynwLgULpbb0Gra+Vyo0mWibbVGkuzYi2l72jlSUIJW1RcDIt qvH/AHEjJHHKmzI42k1DjWLL2PvpvMUuCdIlS5SbUUVYWq5MdcJbFXJ2G/09p9iBHZkyFSn22kpd eUlKTcURYNRkkiIjM+PAiL5CHlOjVP3O1O1B/wDuu7O+UrTv/wCm5XrPDz3/AGTmN+fk7zx+L1mM 80ssarWreN71moSITsev1ApMVLC1GtCeUeVhZGkiI8OJ5jPmMadknwyoJjix1SxZNPYb9us0c6OU oMVG8eJ0xdpklQtWt2/oHqBUqvTio6KvPjyI1KSojKIgpSOHDm74ix0ILmFLOqeoVraK0O84NwUx qDApcIipJ04lk82tLbaTW8at27uiVhJJIubJ4yemawWzPvDTqqW5THYzMuXyPJrkKUlstjyFnk0p M+ZJ+LnHJuyxqtVtCWbEjSISKk3T4UY3XFrJncypo1HkkmrB8meO56M48WzDa4ZihcymOLHsolp4 5TVjsMcqKJSq4oMTrT+VW9G3JkPhve9ZvY7b9TiXPTLXjViAiQk3ISps5xxwkGhDTBcDIt/FXHiZ cBxdLtRrmmXLclrVPriuyaZTlToTzlN6wkSDIknya2jPCcm4gk8C4Fkz4j76pppcrDllV636lSk1 +26U3T1szicVEew3sUojSRKLvl8cZPuebA+q0tPropmqtRvSqVinSl1SlqjSVx21NqZeyjbyaFEo jSlLSCypWTPPAWVs6lNYnie2tdlcnb3FzVrc6GKjWNV6KU20y9neRlm3/eVzNlJZ1EtunV03TaVb tSpnIMpUSzL+1ybhngs4LPHgeOcdbU/VKTT77VZ6bniWkiJDQ7NqXucuco31ElRMoRtxjarO4y/5 GWB9F4abX/dVPcoNbrFpzYSlksqu5TFJqKcLyRESMNlw7kzLGSyXyjsVbTut0i6I12WJUqeiqopi KbJaq6HFtykIJBEtS0d3vwhOT452lzcRkw7Nh1dNNFo0Ux025U+0xqXbFLcKroq3Wry1xYWzJEl0 H4aUX5V7+tK54MKdCOvU03GIdQQwptl3elZR3zQpJ7cqSZmkyPgXEvELuxo1xxLWhx7tnxqhWkb+ uZEdJJbXlajTgiQnmRtLvS4l/mONblt3TSLSrSHrmdqFyVEn3mZD61KjRHlJVyaW0K3bW0qMjxg/ JzEOzY0a44lrQ492z41QrSN/XMiOkktrytRpwRITzI2l3pcS/wAxpWhwPC5OlK9+TYsR0bLDMWDy tXFR7MunG8fjpxnbAAGobwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSv VSKwTmxZvBsR5zeueTNpmmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/AHQibXTmcvYAABoHQAAA AAAAAAAAAAAAAAAAAAAAAAAD5qrAi1SmS6ZOa5aJLZWw+3uNO9C0mlRZLBlkjPiRkY+kATpjQaTV Gc22aFSraoceiUWL1rAjbuSa5RS9u5RqPiozM+6UZ8THSABVtxOrylIYVClDCqJAAAUKgAAAAAAA AAAF9pJ3tT8rX2xdiE0k72p+Vr7YuxNbszWD90nn1959M7uCAAA3jlHw3D7wVHzV31DGKDa7h94K j5q76hjFBHL++aDv/BMPZn6UzagAAI+SYAAAAAAAAAAAD4KxRaPWWiaq9JgVFsuZEqMh0i/yURj7 wFU2nVFHColRnz06BCpsRESnw48OOjglphom0J8hEREQ+gAFG65SqSSogAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4vrRbPyR/2kzWH+ y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR6CAAAAAAAAAAAAAAAAA AAAAAAAAB/EhlqQw4w+0h1pxJocbWklJUkywZGR85GXiH4UynU+lxSiUyBFgx08zUdlLaC/ySREP qAKulClFWoAAAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABpulng6950r1Uis EnpZ4OvedK9VIrBObFm8GxHnN655M2maaq+/8fzVPrqEiK7VX3/j+ap9dQkRFb0zqP8AdCJtdOZy 9gAAGgdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+0k72p+Vr7YuxCaSd7U/ K19sXYmt2ZrB+6Tz6+8+md3BAAAbxyj4bh94Kj5q76hjFBtdw+8FR81d9Qxigjl/fNB3/gmHsz9K ZtQAAEfJMAAAAAB8NJoFCuPVuj0+4aLTaxDRQak8mPOiofbS4UiARLJKyMtxEpRZ58KPpF0KTeM1 rZafdpLm0rSm90PuAW/aq0v+LezvoSN7AdqrS/4t7O+hI3sCzlJXS/D1OH8RPq9/oRAC37VWl/xb 2d9CRvYDtVaX/FvZ30JG9gOUldL8PUfET6vf6EQAt+1Vpf8AFvZ30JG9gO1Vpf8AFvZ30JG9gOUl dL8PUfET6vf6EQAt+1Vpf8W9nfQkb2A7VWl/xb2d9CRvYDlJXS/D1HxE+r3+hEALftVaX/FvZ30J G9gO1Vpf8W9nfQkb2A5SV0vw9R8RPq9/oRAC37VWl/xb2d9CRvYDtVaX/FvZ30JG9gOUldL8PUfE T6vf6EQAt+1Vpf8AFvZ30JG9gO1Vpf8AFvZ30JG9gOUldL8PUfET6vf6EQAt+1Vpf8W9nfQkb2A7 VWl/xb2d9CRvYDlJXS/D1HxE+r3+hEALftVaX/FvZ30JG9gO1Vpf8W9nfQkb2A5SV0vw9R8RPq9/ oRAC37VWl/xb2d9CRvYDtVaX/FvZ30JG9gOUldL8PUfET6vf6EQAt+1Vpf8AFvZ30JG9gO1Vpf8A FvZ30JG9gOUldL8PUfET6vf6EQAt+1Vpf8W9nfQkb2A7VWl/xb2d9CRvYDlJXS/D1HxE+r3+hEAL ftVaX/FvZ30JG9gO1Vpf8W9nfQkb2A5SV0vw9R8RPq9/oRAC37VWl/xb2d9CRvYDtVaX/FvZ30JG 9gOUldL8PUfET6vf6EQAt+1Vpf8AFvZ30JG9gQF9WtbFsamW2m27co9FKVRqocgqfCbj8rsegbd+ xJbsblYzzbj6RdA4I3RN+HqZ7NfjnzYZfJ0r2+h9AAAod4AAAANcsDwRg+RfrqGRjXLA8EYPkX66 h27i+tFs/JH/AGkzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR 6CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABpulng6950r1UisEnpZ4OvedK9VIrBObFm8GxHnN655M2maaq+/wDH81T66hIiu1V9/wCP 5qn11CREVvTOo/3QibXTmcvYcupQGavdloUSW9NbhT6s63KTFmOxluITAluknlGlJWRb20HgjLO3 jwF92oLJ/RuT0pqf4gRcf85FhfPT/wDTJw3Ic+dMjgUKhbWL8sj98zI1amk9CIHtQWT+jcnpTU/x AdqCyf0bk9Kan+IGe6jdUNXrc1YrOn1vaVVK7JVLbadW5AmLNxSFtNLNRtIYWaSI3UpzkyzjmzgV uiessLUWqVO3p9u1G1rmpjaXZVKn/wBoSDx3RZSlRkRqTnKS75PSMscm2QS+UbdKVy6H2Vqcj3iK tMJnV7UFk/o3J6U1P8QHagsn9G5PSmp/iBfANT3ibrPxZdyszWZA9qCyf0bk9Kan+IDtQWT+jcnp TU/xAvgD3ibrPxY5WZrMge1BZP6NyelNT/EB2oLJ/RuT0pqf4gUt6VCuUq2Zc+27e7Iqq1s5Cm9e oi8vlaSV+VWRpTtSalcefbjnMfbQ5E6XRIMuqU73NnvRm3JMPlkvdbOqSRrb3p4L2mZluLgeMkLu WnYOFhvx/FalOWj1mRvagsn9G5PSmp/iA7UFk/o3J6U1P8QL4Bb7xN1n4sryszWZA9qCyf0bk9Ka n+IDtQWT+jcnpTU/xAvgD3ibrPxY5WZrMge1BZP6NyelNT/EB2oLJ/RuT0pqf4gXwB7xN1n4scrM 1mQPagsn9G5PSmp/iA7UFk/o3J6U1P8AEC+E+xedtyL9esaPU23q/HhHNkxWyMzYaI2yLefMkz5V BknnweebGboZ0+KtIni7WU5aPWficHtQWT+jcnpTU/xAdqCyf0bk9Kan+IF8At94m6z8WV5WZrMg e1BZP6NyelNT/ECW1SsG3rWtNut0RyvMTWqtTGkqduCe+g0Oz2GnEqbceUhRGhai4kfP0jZxnfVF tOv6VSWWJK4rrlWpKUPoSlSmlHUoxEoiURkZkfHBkZcOJDNInTIpsKcTpVaS+VOmYaxvL0k2Akux i5/jHrX8hB+4DsYuf4x61/IQfuBm5OHXW/yJ5yseo93mVoCS7GLn+MetfyEH7gOxi5/jHrX8hB+4 Dk4ddb/IcrHqPd5laAkuxi5/jHrX8hB+4DsYuf4x61/IQfuA5OHXW/yHKx6j3eZtekne1PytfbF2 MN0ytC7301DrfVa4Im0288nTacrd33Pujn/4Cy7CL3+OW5voql/hRMbuVLNAk6/9kDvlt22NtUyc EaAAz/sIvf45bm+iqX+FDsIvf45bm+iqX+FG6cssrh94Kj5q76hjFBW1yyr2RRZyl6xXK4ko7hmg 6XTCJRbT4HiNkZL2MXP8Y9a/kIP3Aj9+QqJwVdMvT2dCJb7ORuGXHSFvHop+WitASXYxc/xj1r+Q g/cB2MXP8Y9a/kIP3A4PJw663+RI+Vj1Hu8ytASXYxc/xj1r+Qg/cB2MXP8AGPWv5CD9wHJw663+ Q5WPUe7zO9KrNKi1aPSZNQjMTpSDXHYcWSVOkR4PaR98fyFxHSsf89VJ/wCHKn9Zp485a5aZ3zct 0USNAqM6uklhw1y5jTLDUXui4GptCSPPPjBnw4DX+pztmvWtqTSKfX7ok11/scqW03E9ywRSKf3K VH3ai+VR+IsEXEbEdnlwSlHDGm2ni7n+4zh3lap0yTNlxS2oVTH3r9xVPSYxPqcNaV3zpvKue/Jt uUJ5FZXTmNjvWzThE0ysiLlXFGazU6ZcD6OHTtg8cdRTaenVx6PXM/eFMo89+PUXSdXOSlaokc2G j5RBq/ssmS+7Tgz2Fx7khq2aVLikTIo1kcOTLjqRWJuqPYSpDCY3XKnm0sEnfyhqLbt5855sfKOX QrstavS5EOhXLRqrJjHh9mHOaeW1xMu6SlRmnmPn6DHkSxbxKidRO3Ova3FXJAauAotIhvvuIZeb SpLiDeNJnltDiXS2qLaexKccxj/L4oFWsnXDRyW8uyYFRqFXbS9FtakJhttNrdYQolqyZupUlxaU mZFgiVjn4Z1diwooIosdWl20Vf3o7SmGeuOzOz8VM+yuhYpK+TqR+6DX+xryotr3dfkzyhZYVjvV dBjo02q0yp0xFUptRhzYC0b0So76XGlJ6SWkzIy+XI8u9ThaNs3Rrhra5clDgVhMO4lcgzOYS80k 1yZmVbFEaTV3JER4yWTxzmMguaXWaFZeuFuW2So1DjXlHjvMMntRHiqemoPbgywRqZjIMuPDhgXK 7II5jlwxY1g5f/KnmMPFU9Q9UfrSuxtOItz2HNtyuvLrKKc/vd65abI2nlGR8k4kyWRtEXE+nh0a 3HrlEke6HW9Yp73uYo0T9klCutFEWTJ3B9wZFxwrHAeSerWtPTq3NHrZfs+l0iA/IqLRNLgpShUu OTDp8os0/wBrgzR3asmW4+PdGOn1QcqTZOpl60SmxMq1OocSLEUaz2rmk8UZaeBHj8k6peTwWcF4 xVWKVNlQKDE3hZexrgqsYTTdT06q6LZTQ2K6q4qQVJkKJDE45rfW7qjVtIkuZ2qMzLBER8/AT+nd wV6sXRdsGrVuyKhFp03koLFClLdlxUb3S2zUqMyQ7hKSwnBbkudBDzZYtPdcvq1NAJLKpLFn3ZMq 8h01GWYjSOVirVwIjNan1EZFzcPEY59Gm1unU/qpplvbynoqqS3IVhSGjmS0vKI8lg0tG4ZH8nj5 g5uhSihTy0pscVE/yMM9F63apRrS0uuW4rSqdBq1Zopx0uRVvk+lo3JDTZk4htZKLuXDMuJccDlU fqgLMacsqjXJVqfDrleo8eoVBROpZiU7lIvL4cWtXcbjwSUGZqwtBnwMjPHNSLT06p/UQ0yvUumU ePWpFOpx9espSmRIkKcZN9tSy7pePyhmgzMi2Fw7kh8FAt+g1PqidEINSolNmxahp9CdmsSIqHG5 K0wZJJU4lRGS1ETbZEZ5MiQnoIZZdis7kxVricWPI8SRRxOpu1B1Uq8rqmLu03qLVIjUCh0hE5qW aVof3GmKZ8otS9m38uvmSXMnjz51Cg1ujV+AU+hVen1WGozIpEKSh5szI8GW5BmXORjzRRbdoty9 Xpf8Gv02PUoTdCYe62koJbLiiagEW9B9ysi3ZwZGWSI+ciH0aVlSrO6s3UyjU9MGhW0xb7U15hsk MRWTQ3EUbh8yUEnlXT8RFuMa86yS4of4YmoIYux5K9+Mqomenxkd0am16l9VBaul0eJTVUasUlyb IfW2s5KVpTKMiSolkki/II50mfFXHmxqFFqtLrdMaqlFqUOpQHt3JSoj6XmnMKNJ7VpMyPBkZHg+ cjIeeNQP/wAwHTv/AIce/wBOoDVscqGKKNRrJDF4pF0TN4q932lR6kzTatdFEp859RJZjSp7TTrh mZERJSpRGZ5MuYvGQmtTtXbL0+q9Do9dqTaZ9ZkNNstJcSRMMrcJByHlGZE20nJnuPn2qxnarHmm VHgX/pvqNddCtmxrbodLXPQb9Spqp1ZmSNqnVLN91RKZUs1pJPfGlRqIu9ITnW8Wt211Mr9XhxZz kuqyKdKU+whRvxWqk022yvJd22lKlESTyXdK6Tz0JV2S6rDbytNf+rf4LHGz3RIrtEj0NFdkVmnM 0lbSX0TnJKEx1NqLclZOGe00mXEjzgyCPXqHJoa67HrNOepLbSnlzm5SFR0tpTuUs3CPaSSLiZ5w RcR5m6paFXn9e9NbOotLtc6Emnu+5kCttK9ylyEpcSaHGm+ckNpZJBEnBGoi5jMhx7XpFcoC9dKZ LqVmMtHacpdQoltsTERoMnrUybUgnWiaSSkcoaiStR7vERJMi14bvhilqPCxvH3Vp++Bdh4z1Cq+ LKTAhVBV4W+UOes24cg6kzyclRKNO1tW7Cz3JUWCzxIy8Q7j8mOxGVKefaaYSncp1ayJBF0mZ8MD ybpbYdnTuogn3HPtumTKx7h1Z9E6RHS4+ytpcjk+TWojNBEaCPCTIs5PxmJV2o1Op6C6BUusOm9b E+4VRaypxeEqbam7GWl8eKOSJ3gZH/ZkfDHG7m6CKJwwxZInC8XQm8XgUw2eyabdNsVKjSK1Trjo 8ylxkKXImx5rbjDSUkZqUpxJmlJERGZmZ8MGPphVqjzaIVch1aBJpRtqdKa1IQtg0JzuVyhHtwWD yecFgxl1ItbSiga79ZUCS5SLhmUI0yKBTYpNwH4u5X5V0kNbSXnhneR8E8OPHC6jW6nZlj3h1OsJ BnWpdwN02hEZGZKgTVGvcZ85kSSMlGRHg3S58GZYpdihmukDeh41oeV9xVxUPZFFqtLrdMaqlFqU OpQHt3JSoj6XmnMKNJ7VpMyPBkZHg+cjIfYJe112raEWhaeR6zTWJ8eAhuFT3JaCkvNISZGtLZnv UX5NZmZF/dV0GKgaEcKTxZNGwuQAAFpUDJ9X/wA51pfMtW/1qeNYGT6v/nOtL5lq3+tTxns31O58 Gbt3Z1BtOeAAMpPAAAAA1ywPBGD5F+uoZGNcsDwRg+RfrqHbuL60Wz8kf9pM1h/suDO6AAJQQkCE 1b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+l9/BkCAAIUeggAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSv VSKwTmxZvBsR5zeueTNpmmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/AHQibXTmcvYfLH/ORYXz 0/8A0ycNyGGx/wA5FhfPT/8ATJw3Icy0f5dn5ZHL7zt7EeNLqp+pNS6tW/WdLa7TqNWkUiO489NQ lSHI5MQyU2W5twtxrNs+YuY+JeO+6kKkvVC4rvvq7qvJnagOPFTKxHkRG2FwibJJEkiR3KkqJCMK IiLuC4cMjVqPplQaXrBWdUY8upKrNYhJhSGHHEHGShJMkRpSSCUSvyCOdRlxVw5sfvB08osDVOdq JAlVGLUqhDTEnRW3ElFk7cbXFo25NwiIiJRKLgXNxPO9Ot0Ecrk1i/ilWmOqpVN9BxVDR1PHdHev XUqi3fe8+wahVqvGnSkRa87eKaYm3cNJMmyYWpBbWyMjUo8EoskZkZGY0TUa6b3q+l2jluVqeuJ2 VVZun16o06pNPcq2h5DScPMmaD5VKjcM0q4GkyPPEhrVyaCWVWa1PntzbjpEaquqdq1NpdUXHhVF Suc3mi588/cmnJmeciovHTe0LpsyLaVRpSGqZC5M4KYquSXDU2WEKaUXFJkXDyZIxlmXhIiigahx J9uLFTS6ZceKmQooGebdb7AtvT7WPRGm2qmXFp7twpUUFyY4+2yspUTK0copRp354kR4M05xnIre pJMu3XruWePZGX1maOVq9pTOoeqGjsigM3fdBRa8lyq1Wc69PdZaQ/ENHKuY2tIIicMiwku+PpGt VzRO1qlfMu74lWuihTqhj3Sao9XciNTsFguVJPdcP91SeJmZ5yYum2iW7MoI4m8JPHsirj2hJ1PL FYUlVo9VEpJkpJ3FBMjI+Bl7qvjvxqLFuLXnQuiznJCIkrTmGl/kHltLWgoss1I3oMlESiI0ngyP BmNzZ6nSxWLfvWhx51eZhXhIYfnJTIaM45svqeQlkzbPCdyjI9+88EXHPEdqm6M2vAvi0LvZn1hU +06K3RYDa3mzacYQ062SnSJvJrw6rik0lki4eI74ryk0iwW646f7EuKGAzGOqAbn0rUewNGrYtWb VbU9zXXyobNZVBTUjw8XIqkqPOGyRvMjUe7djnNJj4rQTd9DoGsdqVCis0C3UWjLkRKIu6I9UfpT hRdvJ4Ss3UocSo1kakkRElJcc5P0bqVp1bl/MwlVfr6JUKepS6fU6dJOPLiKUWDNtwubxcDIyyRc OA5tA0htWjWlcdBZfq0t+5YrkarVabL5efJSts28qdURlkiUeC24Iz5hrwW+XyKhax6cuWta5abq 6MhXBdTy4zZ9Ma6huDqGiTVU3FTVmqnSEVF5CYZKqamlE22lRILJLWZnjdlR8R09bqb2K6Laeaz0 2o1VV9VB2nrmVR2oPKN5LsVx9TZo3bCRuSXcpIixnPOY9E9pm1+0d2oev6x7hfrHLN9df9Z6577k 9nf8O8735eIX5oza95aX0HTyqT6wzSqH1v1s9GebS+vkGFMo3qU2aTylRmeElxxjBcBlV5S+UrE3 TDb/APV6PQpgOh56rb906la3agRahpxUb1j29ORFp0RN0e5CKWlCnUofQk8copzbvJXHb8pGkT+r tSumodRrb7V3TIs+bBu5MVmYxVWJ/LspivqSanWVrTuLcaMGo1YQRnzj1Ne+jVr3Pcb1xN1G4beq ktCW58ih1FUQ5zaSwSHiIjJRY4ZwR4IuI/G9dDbHubTOlaebJ9IodKlJlR0051CXDWlDicqU4he7 PKqMzxkz45FZd4yE5eKiTXTioqPTTH2JV04w4HjMa6rW04Gl1uUHUe1p1Ybu1NaZjSKm/U5Dq5SD bddUlaVL2kk1NllKSSnBmWMD87PsS1Z/V7XnEl0rlGabGbrsRPXDpcnONUN43ckrJ/lHXD2nlPdY xgiIvQGs2mVB1WteNb1wy6lFix5qZqFwHEIcNaULQRGa0KLGHFeLOSLiPyqGldvSdV4+pcWbV6ZX ENEzKKDJJtme2RERIfTtM1kRJTwyXepznaWMMu8EpODFE8KkSr3qnB7KlXBjPNlWsus23VLjq2st mXbcRplvSIl5UCruG5AYURZUhjlMNoRxV3RGSSyRkaSIx6o0pn0epadUOZQK9Nr9MVFSmPUJrm+Q +STNJ8qranKyMjSrJEeSPPHIi6x1P9mzp89yFV7rolPqbq3alSaXV1sQZqllhXKNYPnLgZEZDSbY odLtm3oNAokRMSnQGUsx2SMz2pLpM+Jn4zM+JmZmYwWy1QTpao3XwXhV07sRWGFpnSEDr9+bdXz1 R/6nFF8IHX7826vnqj/1OKNSz/Wh2riZ5X1IdqJUAAZj0UAAAAAAAL7STvan5Wvti7EJpJ3tT8rX 2xdia3ZmsH7pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf8AgmHsz9KZ tQAAEfJMAAAAH92P+eqk/wDDlT+s08fjyrXLchyiOV279mS3bc4zjoH7WP8AnqpP/DlT+s08XQ6d j4M5l8ZnH3cUbKMua6nzR1qjN0grHiKiNSlSkE5JfWsnDJBH+UUs17TJtPcZ28ObiedREFT7o1Ge 0/qNal6Wda3JHkk3EoPZBHX100Zt5c64ItiMEpw9pln8n/vEMEmKbDXk4qZNNNmleOghDppKKfaN sTrSK0pdBp7tBJpLSYCmS5FKUmRpIk+LBkRkZcSMsiRpmhOk9MiQ49Ps6NG6ynNz2Hm5L5PpfbMz Qo3d+9REajwk1Gn5OBDuMX3SWKzbVsV5TdLu2uxCfKjJeJ9yOZNLccJS0ltNKTbcSS+BKNPDx4+1 i87bkX69Y0eptvV+PCObJitkZmw0RtkW8+ZJnyqDJPPg882M3KK0QJpNpZdPj6lMTPytGxLVtOt1 6tW/Sus59wSeuqo71w65y7u5at2FqMk8XVnhJEXH5Cx8tI00salSLmfh2+xuul03a2l51x5EtRqc UeUOKNKSy6s8JIi4/IWK8Bi5aY23hPH29GTwK0Rlz3U+aOu0ZykKseImI7KKUskSH0LNwiWRflEr Je0icVhGdvHm4FivuqyLVumsUSsV+jtTp1Ckdc011Ti0mw5lJ5wkyJXFCTwojLJFwFEAudomxOri fi9OUUROwbJtaFfU6+ItHaauKfHTGlTSWvc42W3Bbc7S7xHEiIz2lkx+VrWDaNsVa4KrRKOmNLuN /rirLU+46Ulzc4rJpWo0p4uucEkRd1zcCxTgLOVjaphP/rJ4CiMzVoHpAcapxysantt1MklJJtx1 B4StKyJBpURtFuQk8I2keOPOY61b0o0+rUO3olStxp9u3G2m6SfXDqVxkNERITvSolKItqeCjPOM nkxbAL3aZzx4b8WMFE1T7EtWBqBUb+iUrk7kqUYosuZ1w6fKNETZEnYathcGm+JJI+5+U8/BU9Mb Ll1+47lVQUPVq4aY5TKi8uY+hMmOptCDbMiVhBGltBbkJJRYyXHOeV1RGqfaisqHcnuF7tdc1FEH kOu+t9u5t1e/dsXn+zxjHj5+A0kXNzoIVMbdHiWPopi2LEUxZCd02tOn2RZcC2KW0lmJEN1SG0LW pLZuOrdUlJrM1GklLMi3GZ4Isj+KhYlqz9QKdf0ulcpclNjHFiTOuHS5NoycI07CVsPg65xNJn3X yFilE/d1523asyjwq5U240utTW4VOj4NTkh1a0o7lJeIjWnKuYslnnIWQxzI424W6uvfXKVxJHAk aMaWyLucut+yqW5VnFGtbqkqNtSzVuNZtZ5Pfnju27s+Mf5J0Y00k2LFsiTbCHqBDeU/GjLlvqNl alGpRocNfKJyZnkiVjifSNAGbaSap9n1635bfuF7ndiVRKDy/XfK9d/lH0b9uxOz+xzjKu+5+HHL DMtEULiUTpDTTk0LiUoiluyxLRuu3GbeuOhRalTWEklhp7JqawnaRoWR70qxw3EZH8o+eg6b2RQb Nn2fR7ejQqLUWXGJkdpSyU+haNit7md5maTxu3ZLxGKwBhU6YocHCdNpWiJqj2JatI0/XYNOpXIW 25Gfiqh9cOqy08azdTvNRr4m4vjuyWeGMEPxg6c2RDsFqwm7eiu20zu5OBINT6UmpxThnucM1Z3q MyPOSzwwKsA5aZrPLXLp6dvaKIktPdNrH0/ZdbtC3IlLN4sOupNTjqyznCnFmpZlnxGeBmtp2Fd1 19UAxqvfVrQbZRSqb1nAp7dRTMcddysuWUtBEnG1xWCMs97wyQ3cBkhtUyHCdauJUq61/WUwUR1Y sGjVPVWjX+9BaKq0iKthmWT7vKKSpLqeTNvPJ7SJ5at2DUZ4LgRcbEAGGKOKKlXkxFaAAAWlQMn1 f/OdaXzLVv8AWp41gZPq/wDnOtL5lq3+tTxns31O58Gbt3Z1BtOeAAMpPAAAAA1ywPBGD5F+uoZG NcsDwRg+RfrqHbuL60Wz8kf9pM1h/suDO6AAJQQkCE1b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+ l9/BkCAAIUeggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNpmmqvv/AB/NU+uo SIrtVff+P5qn11CREVvTOo/3QibXTmcvYfLH/ORYXz0//TJw3IYbH/ORYXz0/wD0ycNyHMtH+XZ+ WRy+87exAB5q1JqM66NRq9bdCu3U+tVGnukpUC0XWKZEpadiSS2/Ic/tFqVuPO79ItpbRlVy6t39 XOpFp1fduWqQ63EvL3McqEKSqO9IZKI46RLNrbw7tJY8ewjPiNuVdccxQtRLHTurk/fA4zjSPdQD z5r1W7h0T0gqdag3XXK3Xq9UWYrcmpOIdbguqbWpZsNklKW0bW1bU4PBmRnniJawLpv6j6oW2xSa TrVVKBUpKmK8V30jKGFOGlKHmVpL8khJmalEZklKS4ZzwxwWCKOW5kMSpjp20y+gw8dD1YAldW3b sY02rrtjNIduNMU+sUqxndksmklEZGok7jSRlg1ERHzjzhppcry6vQW6xq/qDaV4yXmjqNMuyFys CYpOCW0whSUJaJSjwR7iVg8YzgxjkWRzpbjTybW92jtKuKjoeuQHlnW3Uet1PXioacx16iM0Sj01 D0huyI6VVF6QsmnCWpZ8UspS4lJ4x3R4PJKyXMq196ml1M+ox1xq8qJOo86J7jVepRF0+a/EdmIS kjUnGXEpIyWaeGFkWTyM0N2zHDC21/Km/IUw0euR8M2r0uFU4NLl1CMzOqClohx1uETj5oQpatqe c8JSZmfiwPL99xL5ovU0UbVprVS7jrkSlU2QiMmSgoa0vci3hxs0Gbq8OEZqcUrKsnjiJi4KW/fv VTaazZVxXFSX7qtCPVHX6bP5J6ApUSQZtxl7T5NszbyZYPJuOH/e4Xy7uUScTjxLC0aYVUOM9qgA Dll4AAAAAAAAAAAEDr9+bdXz1R/6nFF8IHX7826vnqj/ANTijNZ/rQ7VxMkr6kO1EqAAMx6KAAAA AAAF9pJ3tT8rX2xdiE0k72p+Vr7YuxNbszWD90nn1959M7uCAAA3jlHw3D7wVHzV31DGKDa7h94K j5q76hjFBHL++aDv/BMPZn6UzagAAI+SYi11C9Kpctdh0SZb8SHTJTcZJTILzzizVHadNRml1Bc7 uMY8Q/frbUr4atL6IkfiB+lneFd7fOzP1CKKkbEceC0klkWhdCNWXLw0228r0vpZ5p18pWpM297b RDcbm1ZDDqo7lEjOxzZLcnJqUpxWOPjykhtfU6Rb6iak0hu/J8CXN7HKlyXW7eFoT1xT8k4osJUf NzF4j4qzwqx/dj/nqpP/AA5U/rNPGWO1uZKUvBWJPHpyPwOReVghlSZs5RN1piriyrxNlHgvT/8A /L+1E/4jZ/1KePcN01b3Ct6dWCplRqhxGjcKHT2OWkPf7raP7yh596nfRmVM6mKp2NfjFTpCbgqf X7jLe1qUwhJsGgjJaVEkzNgjMlJyRKxgjGOwTYZMpxxvFhQbm2yJxKrMshWJatx6+aPUWs0rrqBX rCgSqk11w6jl3W4D6UKylRGnBR2SwkyI9vHnPNjZ9iWrP6va84kulcozTYzddiJ64dLk5xqhvG7k lZP8o64e08p7rGMERFtNV0RtSa/Z0xmo12m1O0obMGBUYMtLUh2O0jaTbqiRhSTI1ZIiTneouBKM h0qhpXb0nVePqXFm1emVxDRMyigySbZntkRESH07TNZESU8Ml3qc52ljPHeUMVUon8rXfWu9YimA eba2/dOpWt2oEWoacVG9Y9vTkRadETdHuQilpQp1KH0JPHKKc27yVx2/KRpE/q7UrpqHUa2+1d0y LPmwbuTFZmMVVify7KYr6kmp1la07i3GjBqNWEEZ849TXvo1a9z3G9cTdRuG3qpLQlufIodRVEOc 2ksEh4iIyUWOGcEeCLiPxvXQ2x7m0zpWnmyfSKHSpSZUdNOdQlw1pQ4nKlOIXuzyqjM8ZM+ORdLv GQnLxUSa6cVFR6aY+xKunGHA8ZUWJY9AsxE5VGZk9c1J1L9QkSJTj7kl4iwbijcUeDPoLBdBEKYZ 3r/pvB1RsqPbs1c5vkpyJTLkV5tvk3CbcQSnN6VbkEThmaUluM8YMuJjRBxpjwko3FVvL+DIjyFo ZYtv35rHrfTblVNfp7dwLNUFma7HbeUcmWRLXyakmrbgyIjPHdnkuYdLSu8HaHpzrJbty124UW5a NSehU+qxpBdek0t11omWXVkZcoRoRgzM8G8Xelgf3pDpTOreqGscivsXdbBSq8pylVWC69AdeaW/ LNfJOY2uoMuTMywpPen0DcqFpXZFG0+nWNGpPKUeokvr8nnVLdlLX3zi3M7jXwLBkZYwWMYIdi12 mXDG4Ym38uLoolVrt0GOGFnkDVCPU7RtO3dX7UtBNnHUKiwqLOcuaXNnzmVNrdbJ9Cj2E2tLaVKL cZ96npGrWpRIWtOt+p0TUIqk5DteazFosEpzzDcYiU+nrhKUGnKj5Mlko89/zmWBZTepnsWfbTlA qNcvGdETtKD11Vzd9zUEojJEdCkm2gsJ25NKj2mZZ4iiu7Re2LhuBVwIq1yUOqvtts1CVRqkcRdR bQWCS+SSwrJcDMiSfNx4BMt8mKGibUWNYWOqxprK65KrLuCgZ5/6p6P1l1KNtwC1Ai36mLczbSKu waT3pKPJMm1KS45uUnOMmrOMZF7oxPq14a31ZzVymu0+7KXHRMt+iurQqLDiucDdaIjPe8RkRKWf Es8Mcyb689C7FuTTOl6eE3Po9DpktMuOmnOpS4bhJcSZqU4le7PKqMzPiZ44+IUV26f0e4rxt+7n JdRp9YoS1dbyITiE8s0rvmXSUlRKbPjw4GWTwZDFFbZUUrk9LwsdMarSmTFjyOhXBdanjmjvXrqV RbvvefYNQq1XjTpSItedvFNMTbuGkmTZMLUgtrZGRqUeCUWSMyMjMdTVmlqu2odT9PvaLGl1euSP cisux6imQiZHalsoQZOsLNGVJecUakHkjcMjPKSx6KuTQSyqzWp89ubcdIjVV1TtWptLqi48KoqV zm80XPnn7k05MzzkdbUPSK0LzoVDpTyJtF7H3Ero8qkOlHfg7duCaVtPaXcI8XOkj5yIxn5zlKOF wqix9OLFSmXpx4ksnSUwHQtKHS4NEokGi0tjreBAjNxYzW9SuTabSSUJyozM8ERFkzM+kePbLuGq 2q51UFeoZOe6MWrfkFtkRqaNUuYg3Czw7glGv/6R7Jhs9bRGY/LOvck2lHKOq3LXgsZUfjM+czEH aGkdqW3Vb2nNnNqKb0kKfqsaeptxnip1RoQlKEmST5ZZYUajwRcennWW0QS4Y8PHWnfSJNl0SbpQ 8+XfYdHtTqZqbrJQqrWI9+Kg06e9WPdN5bslb62SW2slKNKklv5sf3CzniKzWahah35C0+uxNuS7 htl2kNvV21Y9SXBcU861uUalEpJr2mpJEWMkaDLGFHi1idTlYbT7DMmpXVUKDGcS7Gt6ZV1u01lZ GRkaWjLJ8SPgpRke48l0Vuo2mVtXw7T5k5dSpdVpqVJgVSkyjiy4pKLBkhafFjxGRl/zMbbt0Cjh daurxtZE1iWWuLseLQUwWYpYUel1O27+srS2q3hZ93HAQlFtV+Us0U1KTSW+OZ5WjelWN+88cohW MbRKWvTrcsWXbr2o9sX5pxcJymUSbnh1hUiJUn0F3shRqcQSV4NRpJOMErjtyPQtq6L2TQ4dbakt 1Kvyq9HTHqs6tTFSpMptJYJKlnjHi70i5k9BY5FP6nuy2JsBU6r3bWKZTXm3qdR6jWFvQYam+85N vBcC5sGZljJcx4FVbpKcSq6PxeKmWuTsiT8SmCzXh4qumDStRLcvS9LUtidWmaAqa6V2V6530Ppf QSnj61js9wSUJ5M0EZJIyNBHzGPaoyT/AKPtiJrNQlsy7jj0upPKkTKExVXG6a+6o8mtbScGfRtN W3HDGBqWG0QSG3E2nip+cjXl0l0SqecLiqdUvS1+ppk1moyVzplWlRHJiXVcthE+Myle8zzv2oSe 7Oc8RYa5Ux23dTbO0fs+0Z9TtedHk1ORRW645EKrPrJ0loXKcUasIJslmRqPO/GCM0mNbg9T5Z0S DY0NNXuJxqyZ7s6l732crW4+h5SXcNFuTvbLGNp4M+PNiv1K06ty/mYSqv19EqFPUpdPqdOknHlx FKLBm24XN4uBkZZIuHAbsV4SVHDg/KsLuq3R6Mle7QW4DoZH1L6bvoepl1WpUKKzQLdREakRKIu6 I9UfpLhE2nk8JWbqUOJUayNSSIiSkuOcn6MEfprp1b9hNTl0xyoT6jUVpcn1SpyTkTJaklhPKOHz 444IiIuJ8BYDmWydDOmuKHs/cbfEvhVEBk+r/wCc60vmWrf61PGsDJ9X/wA51pfMtW/1qeLbN9Tu fBm/d2dQbTngADKTwAAAANcsDwRg+RfrqGRjXLA8EYPkX66h27i+tFs/JH/aTNYf7LgzugACUEJA hNW+8pvld+wLsQmrfeU3yu/YGjeWaxnVuTPpffwZAgACFHoIAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGm6WeDr3nSvVSKwSelng6950 r1UisE5sWbwbEec3rnkzaZpqr7/x/NU+uoSIrtVff+P5qn11CREVvTOo/wB0Im105nL2Hyx/zkWF 89P/ANMnDchgNRqtLol62RVKzUYdNgMVl7lZUt5LLTe6nTUluWoyIsqMiLJ85kQ03tq6X/GRZ303 G9sc+dLjiULhTeL8sjl9v/8AW9iI2XolOh39XblszUGqWrGuRwna3CjQWHjfWW7umnFkfJHuWtRn hR5WfMJSo9S4y7pbM0+g3ocWnuXMddjOrpnKLZTyCmSYV+VLfhJpPfw70+548Nd7aul/xkWd9Nxv bDtq6X/GRZ303G9sZobTbIaUro0dGTRj7zjUhPr1Osmi6h2XNtWvJd6zlERk4yra40tJ5StJ82SM vGRkfMfAxF2xo7OavOk3PfF9TrxfoBOJobL8FqMiIS8FuXyfF1wiSXdHjiRHjJFip7aul/xkWd9N xvbDtq6X/GRZ303G9sYYHaYIcCFOmzpy7K6aFXRlFcFMTWaJMpa5k6EUlo2+uIUhTD7Wf7yFp4pU XSMdqeg1YuQ6bTL71SrF0W1S5TUmLTZFPYQ6pSCNOHpBZW7kjURmeDMjPjniNA7aul/xkWd9Nxvb Dtq6X/GRZ303G9sJTtEr5E/DhixdwdGcTUPSt+uXmzfVpXZLtG624fWK5rURuW08xuI9rjLnAzLH AyMvFnOCHGn6CUx3R65LFjV+SmpXLMROqlbkxyddffJ9DxqNslJIi7gyJJGWNxnxPObTtq6X/GRZ 303G9sO2rpf8ZFnfTcb2xfDNtUKSSeKlMXRk0aOh4hSE494aWdkPU/saUe7vW3JU6DB90utN+etl NHv5LeXfclzbuG7nPHHgztC3CrWn9xUS73aVXrPpUeknL9z0vImR221NqLklLw2aiW5xyrG/xmRG Vt21dL/jIs76bje2HbV0v+MizvpuN7YQTbVAqJPS8nTiegUhLEBHdtXS/wCMizvpuN7YdtXS/wCM izvpuN7Y1uQm6r8CtUWICO7aul/xkWd9NxvbDtq6X/GRZ303G9sOQm6r8BVFiAju2rpf8ZFnfTcb 2w7aul/xkWd9NxvbDkJuq/AVRYgI7tq6X/GRZ303G9sO2rpf8ZFnfTcb2w5CbqvwFUWIgdfvzbq+ eqP/AFOKPt7aul/xkWd9NxvbEdrHf9iVyym6XRb1tupz3qzSeSixKow86vbUYylbUJUZnhJGZ4Lg RGYyyJMxTYW4XlWgySmuUh2o/EAAXHowAAAAAAAX2kne1PytfbF2ITSTvan5Wvti7E1uzNYP3Sef X3n0zu4IAADeOUfDcPvBUfNXfUMYoNruH3gqPmrvqGMUEcv75oO/8Ew9mfpTNqAAAj5JiWs7wrvb 52Z+oRRUiWs7wrvb52Z+oRRUjLO+buXBGGR8r2viwP7sf89VJ/4cqf1mnj+B/dj/AJ6qT/w5U/rN PFkOnY+DNK+czj7uKNlAB4u0Xcvq7eprvG8Z+qV5sSqA/Nkw0tVDcbi2YjTxJdcWSnFNmeC2EpKe KjweRjs9l5aFxYVKNLxqQdxUPaIDx7VazqDU+pZia2vak3HGrsEkoYhw3G2YTiSmFFNTzRI/KLPB qyozLPMRDr6s6v3FUZ+mtrxOymK3cdus1ur9isdLtTdJ1lZpaj573CkLUoyIjJPEj4GQ2Fdkxuii To2n2NY2Uw0eqwHnvqfbsvcq9dNCr0K+Y1sxYBTKNWLxpZtyGdiUpcQ+4WEuHlW4uOTShRmZeLKr 2u26UWJK1Gs689V6v7nKabVXZTkaHRH1m4ltakQjLctO5ZpIsHhXOZ7RSC7Y4pjgwlox6MeT9yhx 4qntkB5Lvq779rNwW5Vrok33Q9P6vbkOa1Ks3+0alONNuLN5wkGpKSNS07fGRIMi74h0rwume11J 95V629Xp11G1Ki9YVFto4U+AhUlgjZcWhRKNW0zyoySZ7lcMGRE5uj/j/LK0tOl0y5K9gwz1EA8/ 6qXBXofUPQ7hh1upR6yqgUZ1VQalLRJNa1xiWo3CPduVuVk85PJ55xAprN513WbRu2WL6uOmxq1Y MSRPVHnLM3XDjSVOOmlW5CnTJHBakqMjJJ85EKSrvijhcWFSjf8AxVQ46Hr4B5H1EvCtxdWF6RMV bVWdRbdpLapD9sEmRWZj6+ScJ154+PJkl1KTMiLuuGMGWO7a+q+oNt6Hag1m6aJcrUqgPJTQptep ZxnpLMhzkmDcSeErW2oyNe3hhRFkxV3bMwVEmsdKd+QYaN21OvOl6e2PUbvrUeZIgQOS5VuIhKnT 5R1DZbSUpJc6yzky4Z8g6Vq1qLcdr0m4YLbzcWqQmZrCHiInEodQS0koiMyJWFFnBmWfGY8paqW1 dH/RFl3vVtRbhrL9bgU6dUIE5ba4hE88wtKWUbSNo0maOJKweFcOPD0fod+ZWxv+HKf9WbFs+zQS pGEnV4TXgkFE2yxAAGgXgAAAAAAAAAAAAAAAAAAAAAAZPq/+c60vmWrf61PGsDJ9X/znWl8y1b/W p4z2b6nc+DN27s6g2nPAAGUngAAAAa5YHgjB8i/XUMjGuWB4IwfIv11Dt3F9aLZ+SP8AtJmsP9lw Z3QABKCEgQmrfeU3yu/YF2ITVvvKb5XfsDRvLNYzq3Jn0vv4MgQABCj0EAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTdLPB17zpXqpFY JPSzwde86V6qRWCc2LN4NiPOb1zyZtM01V9/4/mqfXUJEV2qvv8Ax/NU+uoSIit6Z1H+6ETa6czl 7AAANA6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF9pJ3tT8rX2xdiE0k72p+ Vr7YuxNbszWD90nn1959M7uCAAA3jlHw3D7wVHzV31DGKDa7h94Kj5q76hjFBHL++aDv/BMPZn6U zagAAI+SYlrO8K72+dmfqEUVIlrO8K72+dmfqEUVIyzvm7lwRhkfK9r4sD+7H/PVSf8Ahyp/WaeP 4HwQK3CtrU+k1qqs1I4HuLUIqnYdNkS9rq34SkJUllCzTkmnDIzIi7kxZAm20uh8DTveFxWONLs4 o3cY7pfoh2E6K3Tpv2T9f+7/AF3/ALf1hyXIcvGQx/Z8ordt2bu+LOccOcUnbesn9K5PRap/hw7b 1k/pXJ6LVP8ADjHBDaZcLhhhdHR5OjIQtyY3/lZN9pD/APDT2meyf/8AyvWH/wDWdc/2PKf/AE9/ 8vyD6q7ouxOtyym6dcsukXPZ1PbhU2txo6FZ2sk0reyszSpKsZ25yWTLdxPPa7b1k/pXJ6LVP8OH besn9K5PRap/hxl5S2VrR5W8ml5dGnoyFOQj1WfFYmkVOoqblnXNVn7qrt0MdbVmoyWEME8zyfJ8 khpHcoRt8RZ8XHgQiU9ThP7BZtgO6o1hy0dqzp1MOnsF1u6pRuEp1wsLeSTpkvYRoLJDQ+29ZP6V yei1T/Dh23rJ/SuT0Wqf4cVhm2yFtpPRo6MlMWKnYOQi1WcE9Jrrp9GoLNrasVqhVCk0hilrUmIm TBfQ0lKSc6zdWaEOGlJFuI8/8zz/AJbugttQLHu63arUZtYlXe8cir1F1tttxbuTWlSEpTtTtcNS 0lg8KM/FwHf7b1k/pXJ6LVP8OHbesn9K5PRap/hxTlLXSlH4d+Wg5CPVZBVTQC46tpi/YFV1bqcu lNIaZpjJ0lhDcVtpaDQlwkmS3jJKDSWVpIskeO5Idmj6Ie52pdgXn2T8r2IW41Q+tesMdd7GXmuV 38p3GeWztwrvcZ45Kk7b1k/pXJ6LVP8ADh23rJ/SuT0Wqf4cXOdbGmqOjr/l6VR6B7vFqs+HUPSt +uXmzfVpXZLtG624fWK5rURuW08xuI9rjLnAzLHAyMvFnOCH7Wfo/bVDsavWxOdk1lVyOvPVudIM kvTHXc7ldzgkYzwIuY+POZmPo7b1k/pXJ6LVP8OHbesn9K5PRap/hxjwrVgqCjouzoyY6VxaByEe qyAq3U9Vyp6cyrBl6s1h+hIS0ilxnqayaYiULQoicNJpW9gkqSRGpKU5I8HtIbJY9D7GbKoVt9dd d+5NOjweX5PZyvJNpRv25PbnbnGTxnnMTXbesn9K5PRap/hw7b1k/pXJ6LVP8OE2K1TYcGKF0rXJ TH3IKRGv8rL4BA9t6yf0rk9Fqn+HDtvWT+lcnotU/wAONf3ebqvwZdyUzVZfAIHtvWT+lcnotU/w 4dt6yf0rk9Fqn+HD3ebqvwY5KZqsvgED23rJ/SuT0Wqf4cO29ZP6Vyei1T/Dh7vN1X4MclM1WXwC B7b1k/pXJ6LVP8OHbesn9K5PRap/hw93m6r8GOSmarL4BA9t6yf0rk9Fqn+HDtvWT+lcnotU/wAO Hu83VfgxyUzVZfAIHtvWT+lcnotU/wAOHbesn9K5PRap/hw93m6r8GOSmarL4BA9t6yf0rk9Fqn+ HDtvWT+lcnotU/w4e7zdV+DHJTNVl8Mn1f8AznWl8y1b/Wp47Xbesn9K5PRap/hxF3dc9Mu3USgS 6IzVlR4NJqLch2XSJURKVuvQjQkjfbQSjMmnDwWe9PIzSJMyGOsULSo9HYzcu+XGrVA2nlPqAAFS cgAAABrlgeCMHyL9dQyMa5YHgjB8i/XUO3cX1otn5I/7SZrD/ZcGd0AASghIEJq33lN8rv2BdiE1 b7ym+V37A0byzWM6tyZ9L7+DIEAAQo9BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3k BIeYfubvUinxP9r/AJehgwDT78vyhWkqNBlSESa5P7imUlpZdczXDPaRJT4k5Pis+5IsmfMIg+2f Ub2TTabecePNhNplVhB05t2mxicI+SiNl3Lrjh9+azcLCSI8FuIicw/c3epX4n+1/wAvQ44DUdMb hqFx2yuTV48dmpQ50mnyyjGrkVusPKbNaN3Ekq25Ij4lnHHAjrm1ypFFuyo0hu17iq1PpTpR6hVK cwl1ph7BGpGzcS1bSMtxpI8HkvELY7khgVYptF2r1Kw+0kUbpDJr3+hPgNgs66bevCiN1m2atGqc FwzTyjKs7VFzpUk+KVF40mRGOyLuYfubvUt+J/tf8vQwYBukuTHiMKkS5DUdlHFTjqySkvKZ8BIS tWdL4ssokjUO1m3jPG06qzw8vdcA5g+5u9R8T/a/5ehnQDbqTU6bV4SJ1JqESfFX3r8Z5LravIpJ mRj6w5h+5u9R8T/a/wCXoYMA3kYMOfb7B7ng/wAq1ropkp2nWuu9Pf8AC/jg4NNNctexdAAAHOOq AAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNpmmqvv/H81T66hIiu1V9/ 4/mqfXUJERW9M6j/AHQibXTmcvYAABoHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpndwQAAG8co+G4feCo+au+oYxQbXcPv BUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTEtZ3hXe3zsz9QiipEtZ3hXe3zsz9QiipGWd83cuCMM j5XtfFgAAYjMAAAAAAAAAAAAAAAAAAAAAAcHUWVIg6fXHNhvLYkx6VKdZdQeFIWlpRpUR9JGRGO1 HM1R21K4maCMz/yE/qn+bG6vmWZ/orHfif8AVWv+4X/kMjX+Gtr/AAYk3yrXYuLP1AAGMygAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAa5YHgjB8i/XUMjGuWB4IwfIv11Dt3F9aLZ+SP+0maw/2XBnd AAEoISBCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gyBAAEKPQQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA3kcm8a6xbNszq5IZdfTFbyhhrv3nDMkobT8qlGlJfKY6wi9YkKctmnttq /KKrlNNCMd/tltKMv3Umf+Q9DPKTHrVXXXtSmLqqlue710Oyp65EWmKQbcHkcRYzSnXMcm2STkKy ffKNRkR8CLVqE61YFoVq5b2lxob02ovVCabS1PEg3FJQyyg9pG4okJbQREWTMuBDrofotr0CZUY8 Am0vPm843Gby7LkOKIiIi/vLUoyIs/8AgRcOCza9x3JWIVau+cw01EcN+HR4qCNmI4aTSTinDLc6 6lJmRK7lKTMzSWcGK0L6ERplf9XtG00quixatTadJqMqS/UFyWVrZVJkrW2p5gj5RtJm4lJmeTSf ORFzZxZ8uoRtLqZUG3VonVBLtQku86lOvOKWpR9Pff8AgNk1Vm0V2oR7DdejUulMtM1a46jJcS02 xCQ7lDRKVzrddb2/IkleMyGJWzVIZ6JlLhvtzUUhuRHNbeTS5yKlEky4cykkk/IYjftKm5MtLGsJ cGdq43Cpsb04P5R+9t3BOt5/toWwyaJMV7kLspLBYbnspwankp5idSgyWk+cyyR58dZqF1SEup7o mmzUeJAMjJVwVRlRkrzeOeDX/wB5eE/IYgNCSbpFBuas1eShulmttT8l7ghxxKDN5Xkyok4+THiG VwkoS0pMdDqIpOuHFQ4XdIZNZm2Rl4jJOOHiGCxW+ZIhmSFjULVHtVadxKLi9m7PfNqUU6qWC20t LToqvRXG+2mIp69XI1allMuVyp3fOI8k9WZSjZQf+5HRtbSXyYMfPT7hJyWqBSLUo8hxsu6jQqCh 80F8pJbMy/zHz2jQ1XVeVHtduciCVRkbH5JrSk2GUpNTqyzw3bUmRfKZD0dT41aq9NqFp6MRGrWt +3TUhcoi2v1GWjjye7nwZlxWo+OePA8DelxTZsOHHE8eRLKyRXnzbdc/3Ox2eXWFJxxzMcMKeJLp bf7pphdpXc7blfXWLOSVvVuOolSac0lTMOcRcTafjngkGouBLIiMjx/l7ksq4YN2WlS7kppmcWox kPoI+dGS4pP5Unkj+UjHk7XibWa/TajVLspNOp1wUCp06K11oRGompLazW2tZd/zIVjOEmXDxjX+ o2k50baiuPpPZU5pMNmoskjlTPgXRuNQ37LMbbhbqsqrly0xkH9orJKcmG0wy4YI64MShdYXWFRw uHueM2oYMN5GDDlX9/p9/wCDH7Mf6v8A6/kAACPErAAAAAAAAAAANN0s8HXvOleqkVgk9LPB17zp XqpFYJzYs3g2I85vXPJm0zTVX3/j+ap9dQkRXaq+/wDH81T66hIiK3pnUf7oRNrpzOXsAAA0DoAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX2kne1PytfbF2ITSTvan5Wvti7E1uz NYP3SefX3n0zu4IAADeOUfDcPvBUfNXfUMYoNruH3gqPmrvqGMUEcv75oO/8Ew9mfpTNqAAAj5Ji Ws7wrvb52Z+oRRUiWs7wrvb52Z+oRRUjLO+buXBGGR8r2viwAAMRmAAAAAAAAAAAAAAAAAAAAAAJ vVP82N1fMsz/AEVjvxP+qtf9wv8AyGZdUPfMW1rVl0aZS5zxVynSYrElrbyaHFINOFZMjLviPm5s 45hQaTXzFvyhvVGDS50KLHcJglydv5VRJyrbtM+BZL/n8g2nIme7qZTFXyNKG0ynanKr/KixeJZA ADVN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4vrRbPyR/ 2kzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR6CAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAG8iJ1YeajFa0iStLcVNfZQ64o8JSa2nm2zM/F+UW2XlMhbD n3HSIFeoM2jVOIxLiS2VNOsvo3IUR82S+Q8HnnIyyQ9DPKUcmi8m4lpElojWwvclKy4oWRGWfLxM dKt1RFKp6pZxJctRF3DMZvctZ9HHCUl8qjIvlHn1nUg9HrUplOvq3bzeqLbRRnZTxFJZkPISZmbT xrwaVEW4iPBkXAy4DOdQ+qbvG56fIg2jR023BNBm5OkOE9IJJFk9pEWxB/L3R+QUmzYIMbZ0LJYL RbHgyYHFsWLxyEr1RFTrtyaqS26jAeentuLQ9TaeZy0Nk0lBx0mSCyrah1SjMyLu1LLmIhxdPLql 28xV4i4TFRpssv8Aa4ct1bBsvpLBmruckRp4KSfPgh6D0jpp6faQwqlCjtSrlrEdNSnypJmpchxw t5IWvvsERkXyHk8HxGc68Uq37wvK1rpjNuMRa9Rjly2UntKQtpaSSTmOc07zSfTtIce2KVaMJRZF /wB/uMkN12h2WTDJnSlFDE21TE65MuPFoeLI8RndUuysXjIi0tk4Mems93GZS0bEBkiMy3IT3zxk ZHx5iPoFlTKPphHp5R3CuHUi63yNMakwHVsMGvx7uRLuUJyRmalGYsNH5VoGin6cXnbMGewua+qg SnoyXEJNwzdUwrJZQoj3YxwUWOYyGl3tHjtvHa9CZTRKTTaU5U609TW0sOlEIzJuK0pJfkzdWhWV FxJLZ44mRlfZJUuFpSlieQpbr1me6uQ1gUeOjaXZiyvbFFF3LEeUbq041ItZLl51rTKhIoscyXKg skh5DDeeZZEtTif+9k8c5jgnXaa7VOuaLbsi3nUcSKmVBxtxHy4ykxU22t5rUmmtUepQmYtdq71B qFDjOrU86wZJQ666lWSJJ71bMnnuM+IzGrdVrXbPQqDYsekwnrhJhLh1IoxrdprCU5LaaDJSlmks 7cmRJ44PJDetEqNTOSrj7KnIum8ZciHlYoU4HlUShfhVOn7jMRl165KnHfjpuOVUTelNzZEWqHl1 x1tCkNqNwy3HglHz5Lm6BsHU70236xe9mMW5CSxV6dKXNqy1NbZDaENKJanFccpcccQSSI8GXkPG KVm2KxbF3waTUqzDrUObTkVKHLiqVjkl52KLcRKQrJHwF5pJclRs7Uu36zCdWfKzGafOQngUiO8t KDSovkM0rLoNI5bVLRBDHF24u/L04ycWmwwXrc022WSHBwK1TyOiVWlV0ahSSo2qKiSP+ggwYbyM GGG/v9Pv/BGfZj/V/wDX8gAAR4lYAAAAAAAAAABpulng6950r1UisEnpZ4OvedK9VIrBObFm8GxH nN655M2maaq+/wDH81T66hIiu1V9/wCP5qn11CREVvTOo/3QibXTmcvYAABoHQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpn dwQAAG8co+G4feCo+au+oYxQbXcPvBUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTEtZ3hXe3zsz9Q iipEtZ3hXe3zsz9QiipGWd83cuCMMj5XtfFgAAYjMAAAAAAAAAAAAAAAAAAAAHPXJmT6kqj0BlEm cnHXDzhHyEIjLO50y51Y4k2R7lcO9TlRZZMmOfGoJaq2YbTaZVmluZNdEiT1wt6Nd9mO202yuTWZ B8rS2GkkbhvI8fHBJRgzSpajIiJXPnA62mNMpdEsuBQ6WaiTARyMhDiDQ6l/nc5RJ8UqNRmeD6Sx wwNItW2oVAbdcQtcuoSMHKnPEXKvGWcFw4JQWTwhOCLj4zMz+W7LVbqj5VSmvJp1abRtTIJG5DyC yZNvJ4b09HMpOT2mWTI5PHcUfuqlqP8AknWmghMv2ple/Oa5f8GqV07fQ44D4IM9xUxyl1KKcCqs p3OxlK3EpOcco2rBco2f6Rc3MokqyRfeItMlxyonBGqNE4kzpc6BTJbqmAABYZAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4vrRbPyR/2kzWH+y4M7oAAlBCQITVvv Kb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR6CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAG8j8pcmNEZN6VIajtEeDW6skpz5TH5VefGpVJmVSavk4sNhch5f6KEJNSj/5EY/5vXFK1 B6ou/JlWdmHFpCHjTFbkOqKNEbz3KEpLvl4wZmRZM+cy4CfzZ0EmBxzHRI8tlSo5sSggVWz2P1Xt vFceiUyoRUJkO0V5uqN7e63NoyTuPk5Jaz/yHiZRHIpEuIjipTS0Jx8pGRD0PoHQ7p0wnR7VuS42 K9Z9fc9zXIRoX/sjrqTJCkbuZKj7hRFw7sjxwGF3DQZNo3hVrZkbjdpMxcQ1GXFbZcWl/wD1Nmkx ybROlWqWp8l1SdD0f2HnR2efMsE9UwlXxxP8PuZ6OrUiPV9EKFU2mZMmPJpEdCG4e7lVO8mSSQjZ x3byx5S4j4bh0tuVvSyyGoDCJ1dt6MpqZF5VKVPIeIjcSlauBqSsknxMiPB8eYZjpjqlcOm8KRFi RWaxQzUp/rB1w23GFHxVyKyI8EfE9pljPNjJj11QapCrdEg1mnOpehzWESGVl40qIjIWwuGJNw40 zlXpd9qu+bDJtENHD8r6VXL6ZVpPKlbkVfSSO9qJcVqspqq0Jp9vxJbqXDaeVuU5JWSDMkkSe5Ii PceT5iGm6bX3Fr1mndFXjP1iBctHZptb9y20rkwpjXKkr8iR7jQpKzMtpGZbSPGD4SXV9OyisyiM Nkk2HJZmrgWckkz4ePozgeSrJrK6FdlHqhrVyMOoMSloz3J7FkeTLyZ/5jfssNIKw4qEdt8X+JSJ 1wlV+J68sKyKdb99StUJtAqyokZKmqU2dKcTOnyFpMjdVHSauTSREaSUZJyajMyLBCBpFKu6LdUq 89QqVcyEIekVNmKujuKaTKcJJbDWkjwnCG07j4JQk+Y+A9a02ptqWeHUrbURLbWR8FIPilRdJGRk Y/qqzkpRltw0n0pPiLXeceHFNiScTMyuRYMMmFtQ8fQ8v0fSu/76jsXRbMGmVCiLjNQqdIdqKW1q ZYLk9xo2mady0rXjnLcXAXVkaMRrJrcC7dWbut6lRKY6UxintSMk643xSpbjhJ3EkyI9qUnkyLj4 hS0+4p9lahFGtulxXk3RCSt5h6QUeIxOJ8mW5C8EZkbpK2mSE5WbeeGDMv5sDTI7yuCFeN5VWj3H 7lS5Dj7zcF4jnTkqwg97xEXW7RZJCGy2GZZ4nkZJUmVG1OSxszz78vOTZ3dvKUlqqoklXpx0rvNb sLUm2b0qMqnUk6ixMjspkkxPgOxVvMKPCXmycIjU2ZljJf54GbjrWChdS6oWty2lqcYoNCKA+szz +WlPJeJBf91DKTP/APuEOSOT7QKjl9/4Nv2Y/wBX/wBfyAABHSVAAAAAAAAAAAGm6WeDr3nSvVSK wSelng6950r1UisE5sWbwbEec3rnkzaZpqr7/wAfzVPrqEiK7VX3/j+ap9dQkRFb0zqP90Im105n L2AAAaB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT 8rX2xdia3ZmsH7pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf+CYezP0 pm1AAAR8kxLWd4V3t87M/UIoqRLWd4V3t87M/UIoqRlnfN3LgjDI+V7XxYAAGIzAAAAAAAAAAAAA AAAH4zpUaDEdlzHkMMNJ3LcWeCSQUi3ZtzmmVW2XoNEPi3T1pNL0wul8udCD/wALnP8Av4LKBuWK wzbZHgwLFpehHOvK9JF3y8OY8ehaX+9J81NZqF1uqapDy4dISo0v1RJEancc6I5GWFH4jcPKS5i3 Hnbf0SlQKLTm6fTYyY8dvJkRGZmpRnk1KUfFSjPiajMzM+Jj62m22WkMstpbbbSSUIQnBJIuBERe If0JzYrDKscGDAsel6WeYXlek+8JmFMeLQtC/ekAADdOacq5qBT6/CSxNS4260rlI8llW16Ov9NC scD8RkeSMskZGWSEO65UKJPbpdwpRudVsiVBtO1mWfiSZf8Ay3f9w+B86TPBknTR89TgQ6nAegVC K1KivJ2utOJ3JUXkHPt93SrZDSLE9DOtdV8T7ujrDjheVfuRkUA+Kr0+faO5x9x6oUAuJSlZW/BL od8a2y/xOdJd/kiNY+ttaHEJcbUlaFFlKknkjLpIQe12ObZY8CYvU9PsF4SLdL5SU9q0raf0AANU 3QAAAAAAAAAAAAAAAAAAAAAAAAAA1ywPBGD5F+uoZGNcsDwRg+RfrqHbuL60Wz8kf9pM1h/suDO6 AAJQQkCE1b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+l9/BkCAAIUeggAAABxm7khvG71pTbkmttP OMKeh29OkNGttZoWSXG2TSrapKkngz4kZDsiq0B/Nun56rH9TlCtYYYHE1+4zl3rbplkhhctLH0/ 9oz73eR+z94+ilS+4D3eR+z94+ilS+4G/gMfLQar8fQ4vP8AaeiHwfmYB7vI/Z+8fRSpfcB7vI/Z +8fRSpfcDfwDloNV+PoOf7T0Q+D8zAPd5H7P3j6KVL7gPd5H7P3j6KVL7gb+ActBqvx9Bz/aeiHw fmYB7vI/Z+8fRSpfcB7vI/Z+8fRSpfcDfwDloNV+PoOf7T0Q+D8zAPd5H7P3j6KVL7gPd5H7P3j6 KVL7gb+ActBqvx9Bz/aeiHwfmYB7vI/Z+8fRSpfcB7vI/Z+8fRSpfcDfwDloNV+PoOf7T0Q+D8zA Pd5H7P3j6KVL7gPd5H7P3j6KVL7gb+ActBqvx9Bz/aeiHwfmYB7vI/Z+8fRSpfcB7vI/Z+8fRSpf cDfwDloNV+PoOf7T0Q+D8zAPd5H7P3j6KVL7gPd5H7P3j6KVL7gb+ActBqvx9Bz/AGnoh8H5nP1N pkitacXLSIpGqRNpMqO0RFnK1tKSRf8AMyH/ADfq1x1SLJi2TYT7jLbjbaeVaPa53SSM0mr+6ZZP cfPnPQP+oI8e9UTpJb1hXbP1Ep5qZi1dSjKMwncuPKIlOL2tlxU0siMzx3hkZ96fCdWyWoocNrCw ci7enuODZZjUWCnSuns9TN4elU22Y1Kudy75dSuMprD0KnoI+TkvoWS9hqNWdpEkzUsyIiIjMcev 3FWL4uqdeVffbOfNM2VsMIImWktqNKEJ4ZPaRYyeTPPH5OZZNaqdQjVC4Z8px2oTVnGaUZ8GGCwZ oQX90jPBcPEkfgzRuv5ynKc/PhtuyjY/2QlOuy3+dTbDJYIzIuKlmZJIbPMlpV3KZOmrCidcaoqd Cou+rOxcPtHYbvvblYpDihSoqPGn0430VVO0+595LBttIbW9IeVsYjtp3OPK8SUp8f8A/wAG7dSv XqrQKq9pbXHGpO2MqpU9xlW5MYjUXLRjPxklSiMjLpV/lnMWg3LaFGfqUWxZkfLJ8vUJE9mRNS3/ AHspI8pLxmlH/iJmh3yqyNRKBdjbK53I8p10yg+6ciuERLMvl5jL5SCxXbZYrDNmy5yjiVMjxLGb ftN7VWu9bdJgcly5arRNY3XK92RGuaoX4dM6o9qZUGik0KgsJp0qMpBLI25DZKfcJJlxURLQfkbx 4x531I0iuy2ry9zIdNcqMCoGp+jzIxkpqYxzpUhXNnaZZLxeTiPROp1lP6gVDtj6ZORbjg1Rhvry Ky+hDzbqE7SURKwWTSREpBmRkafH4vgtS1b7pdpe4epVxUuy7DKSh1piovsrmtrJW40xl5PkMmXO R5LjtIsmNaTNcMLgfd/0a14WaxR2eTOkxfzxqOHTldGnSmQhNJddZNkQSsu/qbNks01RsRpUZSTk xEkeDaURnhxBeLiRlzFksY0qpdUHpsiGTkWp1iqPqwSIbMA2lqM/7prWe0vKWRGatR+p1erap1Jk Vm4aqZFvi0x5a23lF/ecfc6fGZGZjMXG6ciqSK29TKfTlOKImIzJYZipIsERGffL4cVeMxqTlJf8 o4XXidC57HbbTFgSZiUtZYmq4K2tUr2LcsZ6A6mvUCrV/Xx5+74yIUasRetqTARtW1FcZJS2yMzL du2G9hWeJqVw4lj2BtRyZNIJKUERJIiLBEXQQ8KdT9QalI1NpFwVQ2aRBpJ+6CfdJ4oa5KDQ4lK2 kOYNbe7nXzFgekaJqcVcOYxRIVVq8lUtbUFMKA6lqS2WCJ7rhaSaS1u3FvyfBPAjyQ6Nlw3LWGqH GvuVYpNsihscbjgxY3jx6caon3HzaKqrliSZFKvqjIhTrprsqSipNzUPIdkOZU0wsi4oPkmsJ509 xjJGZEPhFU3aF31+uUZ66E0aDT6XPbqW2FLckPPutkrk2zNTaEpQSlEozLJnsIiwRmJUcS//APT7 /wAHR9mf9X/1/IAAEdJUAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNp mmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/AHQibXTmcvYAABoHQAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpndwQAAG8co +G4feCo+au+oYxQbXcPvBUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTEtZ3hXe3zsz9QiipEtZ3hX e3zsz9QiipGWd83cuCMMj5XtfFgAAYjMAAAAAAAAAETc2q1g21XJFErde61nxtvKtdZvr27kkouK UGR9yoj4H4xfLlxzHSBNvsMc2dLlLCmRJLtdC2Hx1SoMwEtJUh1+Q+vk40ZlO519eM7UF/4mZ4Ii IzMyIjMuHb16Um70kxY8hquTFlkySSm24yf03jUnKE9BY3KxwI8HjRbUtePRVLnSXjn1d5G1+atG DJPPybaePJtkf90j44yo1HxHWu+55tpirMWDCvHuODe/tDJscODKaijfgu1+RzbatN5ctmtXNyb0 1s98WEg9zEI/EouH5R3/AHz5uZJFxNVkACaSZMuRAoJaokebWm0zbTMcybFVsAAn7CvS2b6o71Xt Wpe6EJmQqM47yDjW1wkpUZYcSk+ZaTzjHH/lkqYaPKUAAAqUAAAAGXDBkIKuWtLobi6ha8c3oJma pFISZFt6Vx88En0tmZJPnLaed16AwWizS7RBgTFVG1Y7ZOscxTZLo/3KZzTZ0WoxSkw3ScbMzSfA yUhRHhSVJMspUR8DSeDIywY+kfxcbFCqV5S4NtVunxryYjlImQSXlL7RbCLrhKeKTwtBJX3xEaeC kltHyU2oFJdehyI7sKoxsdcw3sb285woscFIPB4WnJHg/GRkUIvC65lkdVjh6fM9Nui+5N4Q4L/j H0flH3AADlnbAy6oVWoWDqin3XqUuRatyL2sOSpCnE0+WWT2Eau9bV4iLgXQRJGojNeqcbbXonXV LQlSm1RlIMy70+uGyyX+RmX+Y2bJSKYpbyRYvHT3GpbqwyXNhyw4/DR3o/PTyoVW+r2n3iU6bHte EaoVIitvqQ3LURmTj60FwUXiTuz/AJGkYrpoVWuqhP1Csa8zbakNylMpiy6mretJJQonC3PoPBmo y5v7p8ej0lpO221pfayW0JQk6PFUZEWOJtJMz/zMzMeSdNKtpPAoT7N92xVqrUjlKU09EdUlCWdq SJJ4eRx3Es+bxlx6OrZP5crgrJRKiTdMfTvOHbv4ci44l/LCbq2lV06MeLQehYTlYsfROuVmn3c5 fMpJuSok9a+VSlPcNmRGbiyUlBpWs8K6SxkQVtsag1SjR7stPVfsiry22XZFAW6gko3Gncg0rc2J xg8ntTnCsHkV9Cu1K9FX5+j1trOPSZi4/udUmlPLWg/yjmwkumpR5dI+Kj5lERcwzG96nZd1tnGs 3Tuv0u9UvNqQqMxyKWF70mZmlCujODNJYPjksClngicUSa0420sn/ktC2FbVMgUMDUWJQ4knEsfT C8dXtR6rprsh+nRnpkU4slxlCnmDUSjaWZZUnKTMjweSyRmXAfQPioLc9qhwG6o4hyeiM2mUtBdy p0klvMvk3ZH2jhxZSSw5EAABQqAAAAGuWB4IwfIv11DIxrlgeCMHyL9dQ7dxfWi2fkj/ALSZrD/Z cGd0AASghIEJq33lN8rv2BdiE1b7ym+V37A0byzWM6tyZ9L7+DIEAAQo9BAAAACq0B/Nun56rH9T lCVFVoD+bdPz1WP6nKFJn0ntX5I97QfTg2srbmrEK3rdqVeqTnJw6dFclPqwZ4QhJqPgXEzwXMQ8 5dTzqxqRUtRqXT9R5CPcq8qc9OtxBR20cibbiz5PchBGeW0meVmfDZ41YFF1aNYqsmzKVptbLDku v3fMJhlhtwkKUy0ZLcyo8JIjPYR7jIsGrxEYx7UprqgolCtq4K/plQKLTbCdalxJFMktk4yy3tSb ZkUlwzbMkp3ESeZPHhkb9issEUj+dKx1pVqqpkptfAiUUWM9WXVqfYdq3XHte4rij0yqyIaprbT7 ThINlJOGazd28mn+yc4GojPGCLiWf2sDUWyb+RJVaNxRKqcU8PobJSFt8TIjNCyJWDMjwrGD8Rjz jqNc9rz+rA0uu6oPMe4Eq1m5pPPp7htKymqbWvPeklRpMzPG3GTxgUdNnQbp6t6BXbBqEGfSIdtq RXpkFROMuqUbxJQbiSNJq3HHPnLg2fHgZDFFYIFLTxp4OFXRVN4sn5K4WM0Vnqg9HHaO3Vk3xDTF cknFRvjvocNwiSZ/k1IJe0iWnu8beJ8eB40ek1GBVqZHqdLmMTIUlsnWH2VktDiD5jIy5yHkPqKL r07t7R+5Y14VOj09+TUnTdTOWhCpcfkGi5NG7+0wZr7lOTLeXDuiGndQpArkHQSMdYJaWZNQffpq FpNJpjKJOOBkXA3CdUR8ckojz0UtthgkqPBqsFpY9NejEsghibNZvi8rXsike6111uLSoZmaULeM zU4oiM9qEkRqWrBHwSRmPj091GsnUCM6/aFwxaoTPF1tJKbdbIzMiNTayJZEZkeDMsGMe1+fYo3V O6W3HdbrDNosMymeXkI/Ix5Zocwpaz7ksmbBlnGNhn4uHyUyfBurq34FcsGfCn0iFbim6/MgqJxl 1SuWJKTcSRpUrccc+f8A+Wf6JkLYbFA5OFjrguKujE6UyZe/uK4WM1G2dcNLLll06HRLsZlyalLV DiMlEfQ446lJKMtqkEaU4UXdHhPizkjIXlWqMCk0yTU6nMYhworZuvvvLJKG0FzmZnzEPOX/ALO6 OwWjtbkk0jll3A4ha8cTSmPHNJf5GpRl5THf6uyDW5ugkk6OS1MR6gw/UkISZmqMkl54ER8CcNpR nwwSTPIpNsktWz3eFtKtKv8A6QUTwalO91QWjrVGcq53xEVEalFFWaIz61k4ZLMvyaUGvaZNqwvG 3hz8Sz39QdUbAsBxDN3XPDpshaCcTHMluvGgzMiVybZKXtyRlnGOB9BjzV1a12adXHo/bLFn1OkT 349RaNpEFSVKiRzYdLk1kn+zyZI7hWDPYfDuTFtqPeklvqkJ1nv3PS9NqUmkNS5FeVGjpl1XHBLR PvZIkka1YIyM8tLIucZlYIHDDFRquFVN48VOzt6CmGzT52tWl8Oy2Lydu6Kuhvykw0yWWXXTS+pB uE2ttCDWhW1JnhSSx4+ch+0LWPS+Zcki3o97UhVRjEo3EG6aUdyRmokuGWxRkSTMySozLA8DXi6g 7P1Eaj1OVUYR3vBfiyZCu7koW1UzS+ZERFlxOxRmRER5LxYHpjqtadALVzQmAUNgoqq4cc2iQW02 ikQiJGOjBnw+UxnmXZJgjhgq/wCVejQk+juKKNs2mxNVdPb5qkql2rdEOpTYu7lGEpWhRkkyI1JJ aS3pyZd0nJcS4j5rn1j0xtm5U23Xbyp0KqGe1bKtyiaPBHhxaSNLZ4Mu/MhlV9GbPV/2Alk+TJ62 3SdJHDeRIn43Y5+9Tz9BdAxm0G6xSrG1Iot36wQ7TlFUJfuzQnaJFkyqopTadzjKnVtrUa+JJJOC LgojTuyMUu7pUdIqujSdNONtaE8lOjToKuNo96sutPsoeZcQ604klIWhRGlSTLJGRlzkY/sQfU+U 2TSNGLXp0mTUZKmoX5Nc+GmLIJo1KNpK2krWSDSg0pxuM8EWcHkivByZkKgjcKdaMvR0R5B6rK8W 51VdKlS0vks002I4WTQSCMzeUk/GlThERmXBXWxp4lkbR1Rd3rolEYoUd9yMdQYfkz5DSsONQmSS bpIPxLWa0tkfiJSjLiRDyJqaUhy24FWdbbQbUlC5CGk4QwhSDbSlJeJCC2pLoIh6I50p2iCRHkbV fEy2WxzYpEy0Qf5E2tv7wOBEbbiMJaayZJMzNR86lHxMz+Uz4j+KRcNRtOsRaiwxyzcRyQbJ8cEh /BrSZkRmlRKLJHgyMjMjwOQmeaS2r4GXPkfqioIMyJOT8hCdWyRZrZI5CP5aUp2EVs86bZpqnQPG sZV3Dq5Va9TnqdBpj6Hnkmg3EubzSRlgzLCSIjx4zPhz4EU3S50OWVQeZRP3IJLjDZ7TaIuBEjPf EReLh0jpNzSUZEasH8o+pt4lF3J5HOsfs1d9nkRSZaxRdDfqdSL2jt/vUFqwv5QZKpU8KUORFeos aQqREqU+hSFf2hNvORVH5cYIx+bkWHU5aXXXH3oyFblSpzynHJBl/dRu4knhxPx4H+XQ4S50JqW+ pin7k8o5ye9KFGsiNSixx2pyZF4zIa1SEabv8nQ7Qthq7qq8jBJbYObLe5iNSlGW1tPNxM0pIRq2 wSrotMKwY5vQtHe/wSt3xHfVliXJyZD/AM0aX8nsWiulrHoPx6n7SgtV7srDz9UepVMo7DTTi47C VLcccUatiTVwThKcmeD5y4D1tp/opp1ZTqJdNoSJtRRxKfUVdcPkfSk1cEf/AEkQ/HqbNO1ab6Zs 0mZFjR6pMkOTZ6GFb0ocWfctkr+8SEEhGebuTMucaWNifGp06Kc1RsjsM6bBIVnw24Fori20Phq9 HpFYbbbq9Lg1BDatyEyo6HSSfSRKI8GPtbQhttLbaEoQkiJKUlgiIuYiIf6AxmMDBhvIwYR2/v8A T7/wSv2Y/wBX/wBfyAABHiVgAAAAAAAAAAGm6WeDr3nSvVSKwSelng6950r1UisE5sWbwbEec3rn kzaZpqr7/wAfzVPrqEiK7VX3/j+ap9dQkRFb0zqP90Im105nL2AAAaB0AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT8rX2xdia3ZmsH7pPPr7z6Z3cEAAB vHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf+CYezP0pm1AAAR8kxLWd4V3t87M/UIoqRLW d4V3t87M/UIoqRlnfN3LgjDI+V7XxYAAGIzAAAAAAAAHlm74VwXB1RN4t2XblGumUmnoNbU1tp5D KUtR0rcQTiiSbiV4TjifFRYPiPS9vU+RerKZvLORLaUZ7TbVtfnkRmR4MuLTWSMvEtXHvCLKutbu mNt0DUupX5TFS2J0+CiCqIk20xWmkpaSnk0EgjSeGEf3jLifDmxKrouqZBWbNxVVKEGv+/pUbUmR jcLrXRXJReOUw/qYKUdEt+8dVGzp5SGqa6z7hU1LpcgtlBLUTjazyTijbLBce+VgyI8FO2lqDqbK g0S8qazqbXak/UDVU2EUsnaK9EJxZKRHJBcHCwRZ4cdxZ7ks+lKDprQKFf1ZvClPTor1ab21CAlS Os3lc/KGg0bt+cnklc6lcOJjhwdDLJiVmLMQ7W3KbDknLiUR2epdOjvmo1cohky4K4nwzjifASLA aVERDlYG22TVdq1x3b1TMyyI9y1i3aXQKQU9vrJaWylPHyXFe4jJxv8AK4NJl/cPmPiMQ7OL1/6L Puz2YXD7p9m/W3Xnuk9y3I9Y7uT37t2zdx25xniPV14aY23c12Q7olO1SDUozRsOOU+YqP10yefy Tpp4qR8hGXQZ44DIOpy0vKvaBVqz79odWpaZFdckNofZXGfbwwwSXUEtPSSiyZGR4MuPEIoXUrBH Aoa9FCjvKu1pjqyLLoLFYqDVJkUR11+A3JWUdxZImGSlNke01dyjiZZ7kughgdm3jflVpen8Xs7u Vp+pXhJhOyPdFxajbNNOJJKJRmS0pNxZklRGnulcOJ59R0HRe26PfVFvNFYuSbVqRFVGbXOnlIJ4 jQ4jc4ak7s4cPBJNKS2lgi4jkUHqdrKovY/1rVLhX7g1ddXi8pIZPe8rkMpXhoso/wBmb4Fg+KuP Ng4YmUhmS1+7TOr8uS4YGqitNGqrqdLpFBpaHEu0BBSanLeVsWTzzh4NTZcoSD5iykixxHHqt6ao T2tI4NdnXLbVYk15+nzVONLhqmIJ2Jybi2jwTiSS6ae6TgzJfDiefRF/aY0G76q1WVz61Q6w2wcb 3Ro004z6mTPPJqPBkpOfEZeP/ly39ErKM7PTDKoU9q0papkFqM8na64a21mbpqSo1ZNpPMaT5/kw cERRTYKKqM0tmPds3Xm89JlakXYmjx4aaiUw5LapqVKbYPYhw0fk0ZfzhBJ7wsbeOYil6z31L0ht mC7UKy7Nn3G7TZNQp7KXZzkdCWF8m3ngbyuuMJ8Z7OfnHpylad0Sm6rVfUhiVUFVeqw0xH2VuIOO lBE0RGlJIJRK/Ip51Hznw5sT9A0JsikWI5Z6V1aVEOpe6jMl6SlMqNI2ISS2nG0p24JBeLxn/kwI tBVTYNK6DObPue/I9ualUuXF1AYosS3JM2hVO44amJrDiGDJSVPERZXuVuTgzPCDPhxEXMuS+Le0 CsXVBF+XJLnqq7kVcKRL3x3WuUkmfKEZbnFHyOMrNWCMtpFgeiqBpHbVIoNw03r2s1CXcMRyJUqt Pl8vNdbUg0Y5Q047lJ4LufEWc4HPq2htp1LSmk6bv1GtppFKmKmMPIeaKQpZm8ZkpRt7TL8srmSR 8C484rgxUCmwV7/wZbalr9ddW3drHZFcLHWUduqcozN2rfycRzrZw9vdRy5TbyfDuUILPAcKsM3m zfbT+pl3XTadcOqKapdWRCTJoi2Fn3LKUJUWxSlJye5R9wkt5EZZHoqdpnQX9T2dRI0yrU6spbJq SmHJJtmagiIiS8naZqLCU8CMu9T0Fia/6PWnpVRLxFWCpSZfXvuH18Z043+blDaMs5x3PPjbwxgW xSsJNNVRdBaMCJRJ0aptPuRInU+ooo9wMtx5y89bvt55CaRFkzbM+JKxxNs+6LB43JLcOgLGtUqn 1mnO0+pxUSIzmDNKskaTI8kpJlxSojwZKIyMjIjIyMhml0Qqvb6G6VLq8hEWc6mPT6w022p9pw+K WnUKSaTUZEZEsk4PjkkmRGqLXncrlVmSfl0ro9Cb3L7Sq0Uk2n59D6fJ7jtAJLsYuf4x61/IQfuA 7GLn+MetfyEH7gcLk4ddb/IlPKx6j3eZWgJLsYuf4x61/IQfuA7GLn+MetfyEH7gOTh11v8AIcrH qPd5laAkuxi5/jHrX8hB+4DsYuf4x61/IQfuA5OHXW/yHKx6j3eZWgJLsYuf4x61/IQfuA7GLn+M etfyEH7gOTh11v8AIcrHqPd5laAkuxi5/jHrX8hB+4DsYuf4x61/IQfuA5OHXW/yHKx6j3eZWgJL sYuf4x61/IQfuA7GLn+MetfyEH7gOTh11v8AIcrHqPd5laNcsDwRg+RfrqHnbsYuf4x61/IQfuBp 1lWZejtsQ3GtXrjjoPfhtFMppknu1eM4xmO1ckChmxUiTxdv5RwPaGOKKzQpwtfy7Oh9DZrADP8A sIvf45bm+iqX+FDsIvf45bm+iqX+FEkIcaAITVvvKb5XfsD8uwi9/jlub6Kpf4URuptoXgwmBy+q 1wS9xubeUptOTt739GOX/j0DSvFVs0aqdS5m1bYGlXLwZ+ACS7GLn+MetfyEH7gOxi5/jHrX8hB+ 4EO5OHXW/wAiecrHqPd5laAkuxi5/jHrX8hB+4DsYuf4x61/IQfuA5OHXW/yHKx6j3eZ3qNWaVWW nXKVUI0xLLhtO8kslG2sjMjSoudJ8OYxc6A/m3T89Vj+pyh4ysTR/UN69ptcRV5NtMlMdMpiuEiQ neZ5JpOCwrnwrBceYyHsjqd23GdLWGnZC5DiKtVkreWlJKcMqlJI1GSSIiM+fgRF0EQy26RLkwUg jwsa7sTIvedpmz5MLmS3Djff+Szl0Oiy6zErUqj09+qQkqTFmuxkKfYJRGSiQ4ZbkkZGZHgyzkx9 M+HEqEF+DPisS4khtTT7D7ZLbdQosKSpJ8DIy4GRjGOqJvu6rT1Q0lotv1XrOBcFaOLVGut2nOXa 5eKnblaTNPB1ZZSZHx+QsWF96y6Y2PUlUy5ruhw5yDInIzbbkh1vKdxb0NJUackZHxIucukhp+7T nDBFDjrWlKt4nQ4WEiWrGj8xfVGWjfdHaoMG1qHRnKc5TkJNteVJlFhtpLfJ7P8AaE/3i5lcObOs USiUahxlxqJSIFMYWs3FtQ4yGUqUfE1GSSIjM+kTNw6r6e0GzYd41G54vuBNkFFjTYzbklDjuFnt /JJUZHhteclwNOD4joaiX3auntEZrV31X3NgPSUxW3et3XsuqSpRJw2lR8yFHnGOHkCY7RNwYYk+ hYnjpxeMKiM46nDRdyxtN5VsX5Dt2uvLrK6ixsa65abI2mUJMuVbSZLI2jPgXRx6NrQlKEEhCSSl JYIiLBEXQIes6uacUW6KrbNXuqJAqlIjpkTWpDbjaW0KJs04cNOxRnyrfcpMz483A8ffp5qLZWoM R6TZ9wRqolgy5ZCUqbdbyZkRqbWSVkR4PBmWDxwC0e8TW5syF0ePI6Y/MKixIoKrTqfVYLsCqQYs 6I8k0usSWUuNrIywZGlRGRljpH40Gh0WgQSgUKkU+lRCMzJiFGQy2RmZmfcoIi5zM/8AMR7utGlj d29iq72pZVXfyZt7lcmS923YbuOTJWeG3dn5BEai6l1y2uqvtS05FwMU6z5NBdnVJp9tlKNyUTD3 qdUneki5FvmURdz8p5S7LOjrDRrE3jrjp0BtGy27b9BtyEuDb1EptHircN1bECKhhtSzIiNRpQRE asJSWefBF0Dl6lUe565a7kG0boK3KpyhKTKXCalNrRgyU2tDiTLaZHzlgyMi8WSP47C1S0/vudJg WndEKpS427lGEkptzakyI1pSsiNaMqLu05Tx5x8StaNLE3cdqKvallViXyZtmpXJkvdt2crjk9+7 ht3Z+QWqXPUyuC21jxqvimKqhms/Re+7yRTqHex6dUe2INVbqbka2aa825OcSSyMnScwlO4lqzjP fH0cd1rlu2/XVR1VyhUuqKjLJyOcyI28bSy5lJ3Ee0/lIfFfd62rYtJKq3ZW4tKiKUaUKdyanFEW TJCEkalnjxJIxjjmr82u9VLY9uWhdMafZdYozsmQywy0onHkpmHxWaeUQZG033OS5ubiedhK0WlY SxKFN9C6X3lMUJsNVsOxqrIfkVSzLcnPSFIW+5JpbLinVISaEGo1JMzNKTNJGfMR4IdGr2/QaxNg TqtRKbUJVOc5WC/Kiodciryk9zalEZoVlKTynB5SXQQ6QDR5SPpLqHNkW/QZFwR7hkUSmvVmK2bU eoLioVJZQe4jSlwy3JLu18CPHdK6TH51O2rcqlTj1Sp2/SZs+LnreVIhtuOs559q1EZp5vEY6wBh xdIAAAtKmKdVxQKk7BiXHFaddgJgSabUVNoNZxkOmhTbxkXHYSkGlR+LcR8xGZeZ49xxXIy4kt+n EpaMPx35CMYMuOMnhSD5yMvF0GP+hpyWzLBpV/yHFbtu0WpCpDdr0dDyzypxMBolGfynjImk6fYZ sWFyiRs2G8p1jWClVHh/S/Rip6i15LNDddgUBolHKqT8U3WGsF3LbClbTdVnoM0pLx8xBc+ndqwL hrdux36jKNuSuI3Ikv8AdNJYJKXXUoSRJ3LeMyIjIySlB+M8l75Q+yhBIQg0pSWCIiIiIhhOsuic q4bodumzqhGjTJh/7dBnKUhhxXDLqFoSpSF9yWS2mSuJ8D4jYtF7QxSVLgn5O0xWX3d2vlJ0tKF6 EsR4on05dFnKp01bsJ9B9ypB5aeL9JJKyXHoLiQ+6i0u4KrJOPRoNWrDxERmzDgm4os82SQk8Z+X A9L0/qbLgrU9uNeVVpEejJMlOlT3FyZLvHihKnGkJaz+kRKPowPSNn29bNn0hNJtiixaVCSe7ko7 ZJ3K/SUfOo/lMzMdKze08pSko4kotr4GhbbBJU58jE3Ds3VZ4v0+6nHVC6323a1GZtOmGZGt2aZO yTT/ALjKT4H/AN8yHrvSbTG1dNKIdPt6GZyHsHLnv4VIlKLxrVjm6Elgi8RCu65b6Ff8g65b6Ff8 hgnX5InP+c1MsgkKD5UfsA/HrlvoV/yDrlvoV/yGDnSydYi/Ai6D9gH49ct9Cv8AkI+BqXQpqZJt RKknrabJhL3No4rYfWysy7vvTU2oy8eDLJFzC5XjZWqqNGWTZZ06LBlw1ZbDBhpnZ/Rv1af/AA0e 0MzHEvm0Sp2BycVaV/BLPZ+yTrPynKw0rT8gAAcQkYAAAAAAAAAABpulng6950r1UisEnpZ4Oved K9VIrBObFm8GxHnN655M2maaq+/8fzVPrqEiK7VX3/j+ap9dQkRFb0zqP90Im105nL2AAAaB0AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT8rX2xdia3Zm sH7pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf8AgmHsz9KZtQAAEfJM S1neFd7fOzP1CKKkS1neFd7fOzP1CKKkZZ3zdy4IwyPle18WAABiMwAAAAAAAc9puoUSe7VLe2bn Vb5dPcVtZlH41EePybv++XA+ZRHwNNxbVfp9fhKfhKW260rZJjOp2vRl4ztWnxH4yMskZYMjMjIx Lj4J0BxU1uqU2ScCqsp2tyUp3EpPPybieHKNn+ifNzpNJ4Mu7dl8xWekubjh3r0IvfXs7BbKzpGK Pc/Xt8TTBE66XbUrE0rrN1UhiI9Ng8hyTcpClNHvfbbPJJUk+ZZ8xlxx5B0rUupqqPnS6kwVPrTa DWuMasoeSXO4yoyLeniWS4KTktxFkjOM6rr/AOHm5/8A+J9bZEwhmwzJeHA6o88ikRyp3JzFRp40 Z25rJrrRbSYvi4tPrdVa7rDMgn48km1qQ9t5NRFy61FnengaMlnjjA2+s6i2hQrSptz3BWGqTBqU dD8Yn0q5VZKQS8E2RGszIlFkiLgPLFS0ioNmWJZeqXuXNuekPRIsqv02Q6X5MnW0r5Rs0be5So8b VbucsnjJlca89fP3/YWpFBuJdItRumrQ1WI1KKe3TlGlxW9TODyS0qSjiXc7DPnLAooollMkUEET VO3/AK0m/wBGu62KxbLlzU2uQZFHaSpbsxLpE20SSyreZ42mRcTI8GQ5VlaoWFedUfpdtXLFnzWC UamSQttRkk8GpO9Jby5uKckMV04iVKj6Pai3PSosu+G6rJ67jxKrQW4keYvcfKyEMk4s3GjJRL27 UcG8ERGfCCpsmq3XrBZ9bZrlRkzq3bcyM3NlxCjssT1Q5JGwwW1JG22p5oiPiRmrvj8VeUeItUmF 1x5D1PQdUdP67dDts0i6YEqrNKNPIINRbzIjMybUZElwyIjztM8Y4jPLS19prd5X1Sb+qVGosOh1 brGlm027y0hJOvIUak5UajIkN5NKUkW7jgjLHA6nau2/Hte0tPaja8+bddIqchyWyqCtPuWtSnlp krWoiSXcKSkuOebBcw4NistLc6pxxbSFLQU4kqMsmRZnHw/zSR/5EGE3QqpcKqv3Keibj1Dsm3rd iXDV7jgxqZNRviPEo18unGctpSRqXwMuYjxkh99Buq3K7bqrhpFahS6UhKlLlIcLY3tLKt2e9Mi4 mR4Mh42oUG4odraUXuivyqJRYUOoRl1ZFL90CprpSZXdqaweSWk0II/7u3JcSIXtm2nXKnoZqa/b 1arFVVcDpyYzkmiNwSlqJRreWw2TijNDyMJLJIxwwnoKY3oKRSYUsv7Us7v16gKvCxaZYU+j1iBX KwdPqa3GneUYLlWEEaCyjBmTqzJRkojwRlzGOjfmomodPqlyv2/aEGNQLYY5eVNrhPsHUCJKjUUU ySSTMjSZZMzI+HNuIYnVa7R6xUup7jUuPIbepcyNBmqciLaIn23YiVoJSkkSzJRKM9uSLd05GvdU 6VIqVyac2rXalUmIFWrREuHGhpdamGlxlJIdUbyDbT+VMsklffGeMpIjphNpupVwQppU6TT9OLoY vSx6VdEaK9EbqDHKci6nCkGRmlRc3EskeD8ZYMucUA/KJHYhxWosVlthhlBIbbbSSUoSRYIiIuYh K3PdjqZjtFttLMmotntkyXCNUeD/AN7GN7mOJNkZeI1GkjLNZs6CTBhzHRIskWeZaZilyYat6Do3 Zc0Whk3FaZVOqshJnGgtKIlKIuBrUfMhsvGs/IRGoyScgxDlSaj7sVuQmZU9ppb2lhmKk+dDKT5i 5sqPulY4ngiSn+6ZTmoPLOm47JlyFb5Ut8yU6+rpUZERYLmJJESUlwIiLgPtELvK947U8CDFBx2+ R6Tc3s/KsCUyZ/KZuWzzAAA4xIgAAAAAAAAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4v rRbPyR/2kzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR6CAAAA FVoD+bdPz1WP6nKEqKrQH826fnqsf1OUKTPpPavyR72g+nBtZlXVbfnq0H/4jP6zCHNkXuVQ1e1B oFcviDpZRqPJI+Qhx4rE2srWnBvqdcJRrVtQkyJKdxpcR+iPSdXt+g1ibAnVaiU2oSqc5ysF+VFQ 65FXlJ7m1KIzQrKUnlODykugh/FRtu3alVY1WqNApUyoxc9by34bbjzOefYsyM0/5GM0u2y4ZcME UORNaOmunwIo4cdT/n4USpSeonlJNp9ZUq/9z6Fmf+zNnDJHEj70uUcIsdKj+UbD1dN92ddGkVHh W3clMrD5VtmQ4mFJQ9ySOt3y7vaZ7DM1FgjwfA+gx6jhW7b8Fue3CoVMjIqLqnpyWYjaClOK75bh EXdqPxmrJmOeuwrFXRUURdl24qlod5dEI6WybCXMKLeTe3aSsKVxxnuj6TGy70lxTYZkUL/i2/Gn kUwHShhVkRI0n/2gt+OSGG3VxqCy6ya0kZtr5GCncXQe1Siz8pjlxWKs51YOstOtx3raoybNWcPH BJSlR4fJrMsGWSWszzg+c+kem49v0GPcEm4Y9EprNZlNk1IqCIqEyXUFtIkrcItyi7hHAzx3Kegg j2/QY9wSbhj0Sms1mU2TUioIioTJdQW0iStwi3KLuEcDPHcp6CGv7+q1p/kUPhTyK4J5S0vujSWm 9SbFtW/o6KlManONVC3orpIqbsjr1Ro2tE4hzJEaMnkuCTLjzH270hQpXVxaXRXqetMZNsEpEaX3 a2zQicpBLyasqSaU8cnxLOT5x6P7Grc93vd/3ApXuxt2df8AWbfXG3Occpjdj5Mj+5Fv0GRcEe4Z FEpr1Zitm1HqC4qFSWUHuI0pcMtyS7tfAjx3Sukxc7fBhxRJP+WFp0xLR+1GCeZddmau51Y9BiW2 91rVp1kzmo60nt3PnHqBNmrgecLS2fEj70ughk9DaJ/qckW9WdXChRimnHdsqLbkWRU0yOuzxt3O tvKPdhRnksFlHHGD95SLfoMi4I9wyKJTXqzFbNqPUFxUKksoPcRpS4Zbkl3a+BHjuldJj81W1biq 8VfVb9JOrpTsKecNvrgk5zjlMbsZ+UZJd6KCCGHByJdGVV6U+naijgqeb9Sm5Fs686MVq/Z/KW1C oxxHps9hLaEVAmXCU46RGpDalKNhWNxkRoMyPCTM/nqNZtqvdXzZVRteZCnRl0d9L8qGpK2n3iYm kaiWngvCdiTMjPinHiHqKsUumViA5T6vTolRhuFhyPKZS62rypURkY+Jm1LXZqsKrM23Rm6hAZNi HKRBbJ6M2e7uG1knKE92vgRkXdK6TGKG3w4ONY8Fw4smOuOneVwTsgADmF4AAAAAAAAAAAAAAAAA AAAAAAAAAYBa/wDZ1n/iOs/1KSN/GAWv/Z1n/iOs/wBSkjZk/JFtX5O3cGcv+r4o64AAvJcAAAAA AAAAAAAAABpulng6950r1UisEnpZ4OvedK9VIrBObFm8GxHnN655M2maaq+/8fzVPrqEiK7VX3/j +ap9dQkRFb0zqP8AdCJtdOZy9gAAGgdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAC+0k72p+Vr7YuxCaSd7U/K19sXYmt2ZrB+6Tz6+8+md3BAAAbxyj4bh94Kj5q76hjFBtdw+8F R81d9Qxigjl/fNB3/gmHsz9KZtQAAEfJMS1neFd7fOzP1CKKkS1neFd7fOzP1CKKkZZ3zdy4IwyP le18WAABiMwAAAAAAAAAAB8lUp8aosJbfJaVNrJxl5tRocZWXMtCi4pUXSXylzGZDo2/dciBJZpF 0uJJTiibiVQkklqQo+CUOEXBt0+bxJWfe4MyQX4j85UdiVGcjSWW3mHUmhxtxJKSpJ85GR85DoWC 8ptji/jjh0o5N63PIvGD+WKJZH+5UaCAzmkVqdam1iYcio0AuCXeLkiAXy+N1ounitP+8XeaDEkR 5cVqVEfafjuoJbTrSiUlaTLJKSZcDIxOLLa5Vqgw5b9DzC33fPsM3k5y2PQ9h+oAA2jSAAAAAAAA P8WpKEKWtRJSkjMzM8ERdI+Ss1OBR6c7UKnKRGjNY3LV0meCIiLipRngiSWTM8ERZGf1WRPu1e6q MOQqKR5apqj7uR0KkY4Y6GiPHjVk8JRp2y3SrJBhRvHoWlnRu26594TMCUsWl6EfXWLlmXIaolvP uw6RnDtTR3LkkvGmP0JP/F/c5yWX8QIcWBEbiQ2EMMNlhKEFgi8Zn8pmfEz5zMfuRERYIsEAg1tt 822R1jyaF0Hp923VIu+Xgy1j0vS/3oAAA0jpAAAAAAAAAAAAAAAAAAAAAAAa5YHgjB8i/XUMjGuW B4IwfIv11Dt3F9aLZ+SP+0maw/2XBndAAEoISBCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/ gyBAAEKPQQAAAA+Wy7ivO0qK5RIlsUCox01CbJakO115hakvynXyJSCiLJJkTm3go+bI+oBVNUo1 VGrarHKtSSmaDodse+/2Htv0mf8AwIdse+/2Htv0mf8AwI54BSXqLf5mlzHZe3xOh2x77/Ye2/SZ /wDAh2x77/Ye2/SZ/wDAjngFJeot/mOY7L2+J0O2Pff7D236TP8A4EO2Pff7D236TP8A4Ec8ApL1 Fv8AMcx2Xt8Todse+/2Htv0mf/Ah2x77/Ye2/SZ/8COeAUl6i3+Y5jsvb4nQ7Y99/sPbfpM/+BDt j33+w9t+kz/4Ec8ApL1Fv8xzHZe3xOh2x77/AGHtv0mf/Aj4qfq1eM6dUobFj29ytOfTHf3XI8Rb lNIdLH+xcS2uJ/zyP4EtZ3hXe3zsz9Qii+CGW1E8BYl29K7THHctmhihSrjfT2Nlz2x77/Ye2/SZ /wDAh2x77/Ye2/SZ/wDAjngLKS9Rb/Mycx2Xt8Todse+/wBh7b9Jn/wIdse+/wBh7b9Jn/wI54BS XqLf5jmOy9vidDtj33+w9t+kz/4EO2Pff7D236TP/gRzwCkvUW/zHMdl7fE6HbHvv9h7b9Jn/wAC HbHvv9h7b9Jn/wACOeAUl6i3+Y5jsvb4nQ7Y99/sPbfpM/8AgQ7Y99/sPbfpM/8AgRzwCkvUW/zH Mdl7fE6HbHvv9h7b9Jn/AMCHbHvv9h7b9Jn/AMCOeAUl6i3+Y5jsvb4nQ7Y99/sPbfpM/wDgQ7Y9 9/sPbfpM/wDgRzwCkvUW/wAxzHZe3xOh2x77/Ye2/SZ/8CHbHvv9h7b9Jn/wI54BSXqLf5jmOy9v idDtj33+w9t+kz/4ETdsRZ0WnyTqTcZqXKqM6c43HdU6231xKdfJBLUlJqwThFnaWTLmHUAVqkqQ qnj5mxZbtk2WPDl1rSgAAFpvgAAAAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR 5zeueTNpmmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/AHQibXTmcvYAABoHQAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpnd wQAAG8co+G4feCo+au+oYxQbXcPvBUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTEtZ3hXe3zsz9Qi ipEtZ3hXe3zsz9QiipGWd83cuCMMj5XtfFgAAYjMAAAAAAAAAAAAAAAHPhHUbblLmUFsn4bizXKp RqJKFmfFTjJnwbcPnMj7lZ8+0z3l0AGezWmZZo8OW6M1bZY5NslOVOVVw2FZb9ap1dp/XtNf5RBK NDiFJNLjKy50LQfFKi6D/wDIdEZlJhSWKh7sUWSUGqJSSVKNO5qSkuZt5P8AeLoMsKTngeDMjrrU ueNWzchvMKgVaOndIhOKyZFzb21YInGzPmUXkMknkim93XpLtkNMkXR5HmV73HOu6LCywaH5nfAA HUOIBxrpuODQGWyeS5ImyMlFhMERuvmXPguYklksqPCU5LJlwHPuq6zhSl0aiMtzqxtI1krPIQyP mW8ZePHEmy7pX+6WVFO06ndbPvTZUh2dUZGOuJb2N68cySIiwhBZPCU4IuJ8TMzPkXle0uyLBhxx 9HRtJDc1wTbe8OP+Mvp6dnmfyUedUqiir3A42/MbMzjR2snHhEZYMm8kRqXjgbhlk+OCSR7R0AAQ mfPmT43HMdWelWazSrNLUuUqJAAAYjOAAAAAAAAAAAAAAAAAAAAAAAAAAGuWB4IwfIv11DIxrlge CMHyL9dQ7dxfWi2fkj/tJmsP9lwZ3QABKCEgQmrfeU3yu/YF2ITVvvKb5XfsDRvLNYzq3Jn0vv4M gQABCj0EAAAAAAAAAAAAAAAAAAAAAAAAAAJazvCu9vnZn6hFFSJazvCu9vnZn6hFGWX8sWz8owzf mg2/hlSAAMRmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA03Szwde86V6qRWCT 0s8HXvOleqkVgnNizeDYjzm9c8mbTNNVff8Aj+ap9dQkRXaq+/8AH81T66hIiK3pnUf7oRNrpzOX sAAA0DoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX2kne1PytfbF2ITSTvan5 Wvti7E1uzNYP3SefX3n0zu4IAADeOUfDcPvBUfNXfUMYoNruH3gqPmrvqGMUEcv75oO/8Ew9mfpT NqAAAj5JiWs7wrvb52Z+oRRUiWs7wrvb52Z+oRRUjLO+buXBGGR8r2viwAAMRmAAAAAAAAAAAAAA AAAAAPiqlNZnky4a3Y8qOrfGlMK2vML/AEkqx/kZHklFwMjLgPtAXQRxQRKKF0aLY5cMyFwxqqZ9 ts3W8Utqi3KTUee4eyLLQW1iafQWe8d/7Mz486TPBkn465dMqtOLp1rP8jESo0SaukiUWS4GiORl havEbh5SnmLceSTMarttu6X3SlxtKyKjylESk5IjS0oyPykZEZfKQoICENwWG20JQhLSUpSksERE XAiId6O/Z7s6S+bJX90kVg9l7KrY4m6wZcH16MR+dMgRKbFKNDa5NG41KMzNSlqPialKPipRnxNR mZmfOPqABwG23VkrhhUKoliAAAoVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANcsDwRg+RfrqGRjXLA 8EYPkX66h27i+tFs/JH/AGkzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X3 8GQIAAhR6CAAAAAAAAAAAAAAAAAAAAAAAAAAEtZ3hXe3zsz9QiipEtZ3hXe3zsz9QijLL+WLZ+UY ZvzQbfwypAAGIzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabpZ4OvedK9VIr BJ6WeDr3nSvVSKwTmxZvBsR5zeueTNpmmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/dCJtdOZy9 gAAGgdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+0k72p+Vr7YuxCaSd7U/K 19sXYmt2ZrB+6Tz6+8+md3BAAAbxyj4bh94Kj5q76hjFBtdw+8FR81d9Qxigjl/fNB3/AIJh7M/S mbUAABHyTEtZ3hXe3zsz9QiipEtZ3hXe3zsz9QiipGWd83cuCMMj5XtfFgAAYjMAAAAAAAAAAABJ awXLPs/TqqXHTGYzsuJyPJokJUps97yEHkkmR8yj8fPgVozfqmfzI3B//G+stDPZoVFOgheRtcTX tkcUFnmRQvGk+B/tq6iv17RupXc3HjtVenU996RGUlXJpeQ0biT253bFFtUXHmPn8Y50DVtUXRal XtWoDb9VqTrkeNBhJUlLzxOuISksmoyLCMmfH5OJkQi7ljvWrplTbqhsmdNr1nNUmroQRcHjiYjP mWMnxM2zPPAjSJ4m3IOjuk91Pcsql0etPOTUIQai2nMNRKPHRyaklnxrx4+PUhskqLHTE4vw8Xiu BxI7dPgdK41Bj8Yf5eD8amgy9SdV6Cy5XLo03YaoCTSpZxpBG+wgzwalFvVn/NKS6TLnGwUSpQ6z R4lWp7vKxJjKXmV4xlKiyXA+Y/kGc6q6j2M7pjXG4ty0uc9Opz0eOxHkJcdUtxBpTlBcU4MyPiRY wO7oZTJtH0mt6DUTd65TGNxSXEmSkE4tS0oMj4ltJRJx8niGlPgTkqY4MF1ppxqnb0HQssyJWhyl Hhqla4sTr2dP4Ojqn+bG6vmWZ/orHfif9Va/7hf+Q4Gqf5sbq+ZZn+isd+J/1Vr/ALhf+Q1X9NbX +DdX1nsXFn6gADGZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANcsDwRg+RfrqGRjXLA8EYPkX66 h27i+tFs/JH/AGkzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR 6CAAAAAAAAAAAAAAAAAAAAAAAAAAEtZ3hXe3zsz9QijsXN7rFb85VBNgqollSopPI3IU4RZJJlw4 HjHyZHnzQy/79ujUuZAUxT2WJT/XtXV1sojbJtptnanKu5M+TQnjniZn4huWezxTJUyNNUS/Kf4N C1WqCVOly2nVvF4Nfk9KAADTN8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTd LPB17zpXqpFYJPSzwde86V6qRWCc2LN4NiPOb1zyZtM01V9/4/mqfXUJEV2qvv8Ax/NU+uoSIit6 Z1H+6ETa6czl7AAANA6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF9pJ3tT8r X2xdiE0k72p+Vr7YuxNbszWD90nn1959M7uCAAA3jlHw3D7wVHzV31DGKDa7h94Kj5q76hjFBHL+ +aDv/BMPZn6UzagAAI+SYlrO8K72+dmfqEUVIlrO8K72+dmfqEUVIyzvm7lwRhkfK9r4sAADEZgA AAAAAAAAAAObc1CpVy0ORRK3F66gSdvKtcopG7aolFxSZGXdJI+B+IdIBVNwuqylIoVEnDEqpnJk 23RJNqFaz8BLlHKKiIUZS1cGkkRJTuzuyREXHOeGc5H80e16BSbXTbEKmNFR0oWgojpqdQaVqNSi PeZmZGajPifjHYAV5SOlK9vf0lvJQVrRVpTu6NhGUvSvT2m1Y6pDtWCiVvJaVK3LShRcxpQozSk/ IRCzABWOZHMxxNvaJcqXKVIIUtioTeqf5sbq+ZZn+isd+J/1Vr/uF/5Dgap/mxur5lmf6Kx34n/V Wv8AuF/5Cr+mtr/BYvrPYuLP1AAGMzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa5YHgjB8i/XU MjGuWB4IwfIv11Dt3F9aLZ+SP+0maw/2XBndAAEoISBCat95TfK79gXYhNW+8pvld+wNG8s1jOrc mfS+/gyBAAEKPQQAAAAAPht2HfVy09yqUOiW4dPKZKitKmVp5l1RsPuMKUpCYqyTlTajIiUfAy8h VULaqa9otcmzJOa6V2/g+4B/fYrqf8CWd6QyfwQdiup/wJZ3pDJ/BCuD2rxXmanPNj19z8j+AH99 iup/wJZ3pDJ/BB2K6n/AlnekMn8EGD2rxXmOebHr7n5H8AP77FdT/gSzvSGT+CDsV1P+BLO9IZP4 IMHtXivMc82PX3PyP4Af32K6n/AlnekMn8EHYrqf8CWd6QyfwQYPavFeY55sevufkfwA/vsV1P8A gSzvSGT+CDsV1P8AgSzvSGT+CDB7V4rzHPNj19z8j+BP2zaFGt6tVyrU5jZJrMkpEg8cCMk8yeHM ajUryqP5MUfYrqf8CWd6QyfwQdiup/wJZ3pDJ/BC5VSaUSx9q8y2K9bDE03FjWTE/I/gB/fYrqf8 CWd6QyfwQdiup/wJZ3pDJ/BC3B7V4rzLuebHr7n5H8AP77FdT/gSzvSGT+CDsV1P+BLO9IZP4IMH tXivMc82PX3PyP4Af32K6n/AlnekMn8EHYrqf8CWd6QyfwQYPavFeY55sevufkfwA/vsV1P+BLO9 IZP4IOxXU/4Es70hk/ggwe1eK8xzzY9fc/I/gB/fYrqf8CWd6QyfwQdiup/wJZ3pDJ/BBg9q8V5j nmx6+5+R/AD++xXU/wCBLO9IZP4IOxXU/wCBLO9IZP4IMHtXivMc82PX3PyP4Af32K6n/AlnekMn 8EHYrqf8CWd6QyfwQYPavFeY55sevufkfwA/vsV1P+BLO9IZP4IOxXU/4Es70hk/ggwe1eK8xzzY 9fc/I/gB/fYrqf8AAlnekMn8EOXb8+TUIDrkyK1FlR5kqE+008bqCcjyHGVGlZpSakmbZmRmkjwZ cCBwulfyjPZ7fZ7TFgSoqvLkf5R0QABabgAAAAAAAAAAAAAAGm6WeDr3nSvVSKwSelng6950r1Ui sE5sWbwbEec3rnkzaZpqr7/x/NU+uoSIrtVff+P5qn11CREVvTOo/wB0Im105nL2AAAaB0AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT8rX2xdia3ZmsH7 pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf+CYezP0pm1AAAR8kxLWd4 V3t87M/UIoqRLWd4V3t87M/UIoqRlnfN3LgjDI+V7XxYAAGIzAAHx1ipRKTAVOnKcSylaGy5Nlbq 1LWskISlCCNSlGpSSIiIzMzIVhhcTospSKJQpxROiR9gDh9k8P4Huv0XqP3Adk8P4Huv0XqP3A2P crT1cXgzU5xsfWw/7l5ncAcPsnh/A91+i9R+4Dsnh/A91+i9R+4D3K09XF4Mc42PrYf9y8zuAOH2 Tw/ge6/Reo/cB2Tw/ge6/Reo/cB7laeri8GOcbH1sP8AuXmdwBw+yeH8D3X6L1H7gOyeH8D3X6L1 H7gPcrT1cXgxzjY+th/3LzO4A4fZPD+B7r9F6j9wHZPD+B7r9F6j9wHuVp6uLwY5xsfWw/7l5krr vedBt6z6rRKq++zMq1KlNQiJhSkOLNtScbiLBHlSefmyQ7+nt50G86a7IoD70hmKaWnVrYU2W/Gc FuIs8Mc3SQjNd6fFvmw34MOhXSuqxVdcQc2zUE5WXOjJsEREpOS4mRZwZ8w6+lzdNsux6dQW6PdJ vNN75TibXqP5R5XFav7DiWeBfIRDcisUXuypLiw69D8chz4bxg98dZsGBRY6rwy/qNDAcPsnh/A9 1+i9R+4Dsnh/A91+i9R+4Gn7laeri8GdDnGx9bD/ALl5ncAcPsnh/A91+i9R+4Dsnh/A91+i9R+4 D3K09XF4Mc42PrYf9y8zuAOH2Tw/ge6/Reo/cB2Tw/ge6/Reo/cB7laeri8GOcbH1sP+5eZ3AHD7 J4fwPdfovUfuA7J4fwPdfovUfuA9ytPVxeDHONj62H/cvM7gDh9k8P4Huv0XqP3Adk8P4Huv0XqP 3Ae5Wnq4vBjnGx9bD/uXmdwBw+yeH8D3X6L1H7gdCj1KJVoCZsJTqmTW42ZOsraWlaFqQtKkLIlJ UlSVEZGRGRkLJlnmylWOFpdqaMsq1yJzwZcaifY0z7AABhM4AAAAAAAAAAAGuWB4IwfIv11DIxrl geCMHyL9dQ7dxfWi2fkj/tJmsP8AZcGd0AASghIEJq33lN8rv2BdiE1b7ym+V37A0byzWM6tyZ9L 7+DIEAAQo9BAAAACq0B/Nun56rH9TlCVFVoD+bdPz1WP6nKFJn0ntX5I97QfTg2sq6vcFBo82BBq 1bptPlVFzkoLEqUhpyUvKS2tpUZGtWVJLCcnlRdJDpjzZ1W356tB/wDiM/rMIU2rupd9WzV5UeC/ pvbUNl3bFcuirOKkVBBII1ONsR+KU7j2luPPDiRZIXqxOOCW4HjiTfg6EVwsptoDxlrVrnd149Tl Sbrtl1q3GJNado9cbYeWcjleR5RtLTmCIm1I3KXzKzsSRmW7O1ajap1/TOxLdTd7NtSL0rc04baI spcemt/lMcspbvdpbQhTe8z5lK8RcRWO7p0KhWltqmwpho2MBh+kutE2tajp09uqZZtQqkiCcyFU rWqJyYTxkatzJkozUlwkpNWMnwIz4EZCe0b1a1r1S0/qFYt63LJamw5y2DkTHZLbCyJttZNoaSa1 KX3SsqNaU90jn4i12CbDXCokqaenJwK4SPSIDAaP1SVNf6nqTqdPoyWp0ecdM9zkP4S9LwlSUpWo s7TQolnwMyIlc+BR23eOrVOvOj0e/bKpztOrfKGzOt5Ml9NMMiI0olmtO0jPON5GRZzwwR4tisU6 GuEqUrp6MtOkYSNbAZJplqnUZkG/Y1+t0yDVbMlulL60QpptyKSDW29tWtZluJKj74/EO7oFdF0X rpnBuq64VPgyaktb0aPDaWhKI2cN7ty1GpR4NWeBYUXAsZPHMs0ctNxaKb1XF3BRJl8Jrs/sP3E9 3Oza2vcrrnrTr33VY5Dl9u/kuU3bd+3utuc44ilHiPttf/hf7J+1npt4adYe5nuF/sH/AFLlOX5L f/bf3d+e94YGax2R2itOlLxr5CKKh7cAeXqBc2rVQ6tK4LcbqtDdgUuMRrhyFPFHZpi3IqzUylPP LNC28qXlO41kR7dpB1MlzatXDrhfzNw1WhzYNMnphVls1Pf7PsOWlpEBPekjlEnuNzujSRHxVkXx XfFDA43EsST8SmHjPUIDzLVuqRqs12u1q1ntP2qBQ33mutKzWjZqdVJtBK3xUJ7narPc5JW7mLjk h1tQtfavFj6U1Kx6VTahEvd9bTzEzcbqFJcYbNpC0KJKVkpxaTMyURGkuHAyO3m20VSay+VeBXDR 6EAcKyDu46KZ3siiIqvLL7mkKdVHJrPcFl0iUasc54Is8xDujSiWC6FwAeatH9XtbNTLAn16gWtZ qpECetlxT70hpD6Uttr5JpsjWfKd0fdKWlPdI4HgxXW/rNUbv0jp152nR6O085Icj1VysVVEaHSV NoNSlOrIjWoj7jaSU5wsjPaNuZYJ0DadMTo8axFqiTNnAefNItd6rXNV4+ndzP2dVpE6M4/Eqdry H1xiUhKlGysnSzu2oWrcR470uJmP1i6v6j3g1cNx6Z2tQKna1vS3oriZUh5c6qKbQlR9bE0RpIzJ RGkj3btycceArFYJ0MWC1TI61xY8gw0bXV7goNHmwINWrdNp8qouclBYlSkNOSl5SW1tKjI1qypJ YTk8qLpIdMeT+qbuWPMvLQG66rDlUBj3WVLlsVFs2XIaUvwlOE4SiIy24PjjmLI1rT7VGZevuxeU NmDTtOaW08SZktKuu5i2iM1upLeSWmkkWe7Saj/3eOKzLDFDJhmLTWu2rVNwUWOhqwDy0rqnK17i nfCWbE7GuW5MqEdaPsg2ctyfK8l3nN3WzGccc44j8dSr21PqXVR2dR7IrdBXTKhSSqlBjS1vFCfb civ7nJXJ90pfcu7NpmkiJo+c1C+G7J1WoqLE34ZUUw0eqwABzi8DALX/ALOs/wDEdZ/qUkb+MAtf +zrP/EdZ/qUkbMn5Itq/J27gzl/1fFHXAAF5LgAAAAAAAAAAAAAANN0s8HXvOleqkVgk9LPB17zp XqpFYJzYs3g2I85vXPJm0zTVX3/j+ap9dQkRXaq+/wDH81T66hIiK3pnUf7oRNrpzOXsAAA0DoAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX2kne1PytfbF2ITSTvan5Wvti7E1uz NYP3SefX3n0zu4IAADeOUfDcPvBUfNXfUMYoNruH3gqPmrvqGMUEcv75oO/8Ew9mfpTNqAAAj5Ji Ws7wrvb52Z+oRRUiWs7wrvb52Z+oRRUjLO+buXBGGR8r2viwAAMRmA4d6+99M+f6R/UY47g4d6+9 9M+f6R/UY42bFnMv+y4mneOZzf6xcGayAAPSTxkAAAAAAAAAAAAMaufXmn0TWJqwlUB1+GUuPClV YpBkiO+8nKUmjkzz+8XMr9EUmqOpXYPd9lW/7i9f9lFQOHy3XXJda/lGUb9uw9/9tnGU97z8eFuE i/k4sWLKaCA5V5VjsdtCtXB1t1z7mU9+ZyO/ZynJNqXt3YPGduM4PHQMHpHVGXrWKc1UqRoVcNQh PZ5KRFkPOtLwZpPapMYyPBkZHjxkYOJLKIZcUSqj0aAw2/dd63bVdtygxdM6hVatWaIxVDgtS1pk R1r5TexyZMqUo0cmrJ4LmPJFgfra+vUmpzp1Cq+nVdoVzN0uRUIFLk7t042kKUTSMtpXuVsVjCD7 1XPjAphoryMdK0NtAebH+qWuyPXWKC/olW2qtJbN1iCuW6mQ6gt2VJbONuUXcK4kWO5PoG56dV6p XPZsCuVe3pduzZPKcrTZW7lWNri0FnchB90SSV3pcFF5RVRJ5BHKigVWUAAAuMYAAAAAAABk1l+9 9T+f6v8A1GSNZGTWX731P5/q/wDUZIj/ALR5tD/b8Mlvsfnkf9fyjuAACGnooAAAAAAAAAAAGuWB 4IwfIv11DIxrlgeCMHyL9dQ7dxfWi2fkj/tJmsP9lwZ3QABKCEgQmrfeU3yu/YF2ITVvvKb5XfsD RvLNYzq3Jn0vv4MgQABCj0EAAAAKrQH826fnqsf1OUJUVWgP5t0/PVY/qcoUmfSe1fkj3tB9ODay P6omxLquzVDSWtW/SuvIFv1o5VUd64ab63a5eKrdhaiNXBpZ4SRnw+Us8GNYmpNn63XhdFHs+iXg 3czqVwqrPqLbC6SkiM9ikmg1mnilOEEeSaQZmPRgCsFujhgUuiaSpp6a9PSRVwqtTxonqfNRD6nK s2F1gymrQrvVV4OZLWyosFG5Ath7/wAmZ8VES8eIjxnJa5rdpzcGqVqWdcK6DToFz0GWmauiVGSm RHdQpSDdjLcSRoUSuTRx2mRkRlwyY28BkjvKdFEo8VU2/HE/EooEYdpHYlwnqOm8avp7aOn9NiQz ZiUenw4MiSt9W5KnlSmmiUgtijLalXEj4+PP99RnYl1ae6X1Ki3fSvc2e9WnZTbXXDT2WlMMJJWW 1KLnQosZzw8g24BimWyOOGKFpUdN1e3t01KqFI8j2L1PV3VLqYazYdyQ2qJcBXEqrUwnpKHWzMo7 TZblNKUREouVTxyZc+OYa7bL+uFw3hR3q9TKfZVBpvKFU2WpjE5ysKwWw0fk8soyRn3xKwZ/JjWw F823xza4aTrV7K5aetQoUjyX1VVrVJ3W6h0m15qormokNNLrDTJ4UbbDzSzfMiMsnyZbcnnuULT4 zIbVfc+87OqNhUSw7epMi2nJjVPqynzJK4cbey2jkUk4gzMkG6fBK8EgjMiIuPct/TSxaBd9Qu6k 25Ej12oPOPSZpqWtxS3Dys07jMkbjM8kkiLiYqXI7Dj7T7jLa3msk24pBGpGefB85ZxxFZlrUSgh pVQrTpfjoVKbCihyn6GZERmZkRFzmfiHgLT6wLuv7qQ10i06OqoTUX2qYbZvtskbKYJNmslOKSRl uURcDzz9Bj3Zc9CpdzW/NoNbjHKp05o2pDJOLb3oPnLcgyUX+RkPytC2qFaNvxqBbdNZp1NjEZNM N5PGeJmZmZmpRnzqMzM/GYWS2e7QPBVYm0+zFXzEUOEzI49jXlb/AFW9R1DgUVqrW9cVNRBlPpmN srpxpSwRrUhR7nP+rlgkl/fPm28WjNjXlYmumoUuVRWpluXZMOotVZuY2nrdROPLJlTJnvUZ8uZb iwRbSPx4LcwGN22OKFwtLGkvDJpyorgo8nxdE7rslq4bYt7TKzLsi1WW89SLgqao6naQhaEpSlxt 9tanCTjJEk1EZ5My7oyFFqJpJdiqzogzRKdDqMa1KmcitSYjUaAy3ukRnFuIYTsIiM0OntQkz4cc mfH0cAyu8pziUTSrj6cdVTp6OiiKYCIDVKv39RLms1i06LTJ9GqFSTGrr8pRcrGaU6ylKmk8ok1K 2qeM8JXjZkyIiPN+PycjsOPtPuMtreayTbikEakZ58HzlnHEfqNKKNOFKmTeXHjXqN6pqTStGauu yLVplxMv111skv1IorkR7kGMuGSkmlxGDT3JGlRbT588O1UOp0uih6R2dS6SinXBUaNXFVusUd17 k4tTWokFyZKcLHBDSW+O1JktZmXiHovTuxLV09oj1FtCle5sB6SqU411w69l1SUpNWXFKPmQksZx w8opR0p15xctFHKVE3Xbox4+3QWKDFjPOEGyNSqn1Rtj6m1ezKdRabDhvwZFPhVFp5UBvkXiQpxX cEs1LkK4NkrBI+Uf5aFkauaT0+5LJ0+t+l1OlVie/LpVbdqaGjpRrbQhPKsuIUbppJCcY3EZlk+f A9IAMDvCNqjhVKJUx0xNtadFfMrgI86a3aV3veFX0ebqLDV2N0Wao7olrNhhtba3YxuHyRmnck0o cLahJnhPEsnx7dI0yqdtX/dNt0iipXppedPcKU3GeaaKlyVNm2va3lKti08O4I8Ht5iLI3ABb79N wFBioq73Wu1PIVwVWp5LoujF+0a12tPYunNhPvtyDUi+pTESStLBvmsyVGeaUtbmwzSWckRYIj4E ZW1+6b3bStd9PtQbRokeuU6hUtNHkwm32YJst7H0E6kjwjaSX87EJLvCIiIj7nfgF8V4zYoqtLHW uXHXLp4URTAQAAGgXgYBa/8AZ1n/AIjrP9SkjfxgFr/2dZ/4jrP9SkjZk/JFtX5O3cGcv+r4o64A AvJcAAAAAAAAAAAAAABpulng6950r1UisEnpZ4OvedK9VIrBObFm8GxHnN655M2maaq+/wDH81T6 6hIiu1V9/wCP5qn11CREVvTOo/3QibXTmcvYAABoHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpndwQAAG8co+G4feCo+au+ oYxQbXcPvBUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTEtZ3hXe3zsz9QiipEtZ3hXe3zsz9QiipG Wd83cuCMMj5XtfFgAAYjMBw71976Z8/0j+oxx3Bw71976Z8/0j+oxxs2LOZf9lxNO8czm/1i4M1k AAeknjIAAAAAAABz7mq8S37dqNcnqNMWnxnJLpkXHahJqPHy8B0B89TgQanAegVKHHmxHk7XWJDS XG1l0GlRYPyGKBHiKLbutNx6b1qcxZcGXTbjmlXnKmchtMpKknuI2iN4jJJESsEaDPCjxzkKnVW/ INcY0EvmpSSaZamrfqTpNqMm1svRCfUSSyoyI0KMiLJmWMZHraHEiQoTUGHFZjRGGyaaYabJDbaC LBJSkiwRERYwQ4T1hWK9BjwHrLtxyJGUtbDCqWybbRrxvNKTThJq2pzjnwWebhj5NpYmbPLpurRA XRqvYF9acXxSLVr3uhNZtioSVtdZvtYbJk0mrLiElzrSWM54/wDLzPpzNpLNmwG5PVE3DaDpcpuo 8WnznG435RWNqmnCQe4u74Fzq48cj21TrGsqm9c+51n29C66jrjSet6ay3yzKu+bXhJbkHgspPge B8na004+L+1PoaP7AOBvGIJsECaVdx5s1Aoc66td9MaNQ74qEaTLsyObFxtIcTIdJLcpZvbTWlZG 4lJ5I1ZLeec8SFToFR2KFrhWKNf1UrNVvuDHNFMmz5S3WZEI8nuZ390SsKPKTMyLu8cysegGrZtx mowak1b9Jbm0+OUaFIRDbJ2MyRKSTbatuUIIlKLaWCwZ9I/WbQqJNq0WrzKPT5FRiFiNLdjIW8wX HvFmW5POfMZCqgx1LXOqsHsMNvn/AOOWw/mB31Jw9BDnv0OiP11ivP0enu1aM2bTE5cZCpDSD3ZS lwy3EXdq4Ef94+kx0BclSpjjiwqdiAAAuLAAAAAAAADJrL976n8/1f8AqMkayMmsv3vqfz/V/wCo yRH/AGjzaH+34ZLfY/PI/wCv5R3AABDT0UAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4v rRbPyR/2kzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQI+epToVNhOT qjMjw4rREbj77hNtoyeCyo8EXEyIfQJXVRKVWkhKkkaTq1MIyMuBl1+wIbLhUUahekn02NwQRRLQ j9uz6xP21tv6UZ9oOz6xP21tv6UZ9odv3OgfqMb+Cn/0D3OgfqMb+Cn/ANBdWV0Px9Cyk7pXg/My O1eqBtabWJNKr6fctTchbTMxCuVjPJJRklWSLKcljpLx5Iei+p4fZk6XMyYzzbzDtXq623G1EpK0 nUpJkZGXAyMuORhtq6KWbR6zJrU+N7sz3pC30nKQXItblGeEt83DPOrPNwwN16n9KU6aoSkiSkqz WCIiLBEXunKGW3OzuD/ATyrg8hF7zVqUmH3lrK6Uy9+gyvqtvz1aD/8AEZ/WYQubs1fqiL4qdmaf WDNvSrUdDa6oaZ7UJiNvIzJPKOEe5fN3JF08ckZCZ6p+369WNXdFp1JolSqEWnV83Zz8WKt1uKjr iGe5xSSMkFhKjyrBYSfQY+KmM3JozrFf9ecsa5rpoF2yGZcaRQ2CmPMulyqlNuN7iUlOXF8eYiJJ Fz4K+CGXHZ5daNqF0VaVeFtWjGcBtpsu6Lrhak/TCv3zKi1CnJt51caqU59CSkMPpUSSaLjtM1KU kiPJFk8HjB45ltayXVUk0mqzNHriatusrZKBU6fLanr5Nwsk68w13bSCLiZnnHNz4I5/RnTy46bb mp10XLaLEmpXrPdlJtuXLSlKmd7q0trcJKiSpRvL6cYTzHnGfUu3rtplaosfR6xdR7Gqzc1v3WjV V/lqEllX9phS1/lsHjiWDMt3AlYwhs9mcUcMNMWlvEsXY+nTRophPEbde+sMqnajv6dWXZkm7rmi xEzJTBVFiE002e08G45nKsLQrBFzKL5cVum13TLtp0x2o2lXbYmwpJx3otUY2ksyLv2nC7l1HOW5 PR0GRnlfVC29SJl7RaxW9JLnrbLMUij3BakxSqg05ng2qOnYeCyZkvcrBeIuOO91L0XUaJQK03fL lW9zSnYoDdZUldRRFLOOXUkzyeDQWD4kZL8RpxrzJMr3ZRwqjxacbfZjfhRNFybwqF5ftyz7ciRP cq1avck6Y8bTUaCSUIRhBqNbrrhkhpHDGVHxMyIiMQ2nmtLtb1FRp9d1pKta4n4ypURpurMT2Xm0 kZmXKNY2rwlZ7cHwQZ54kOb1W9Du+tUO2zocCqVe3o1TJy5KVTFqTJmxOGUJJKiNZbScTtLJma0n 4sjO7XtWWjqoLCvO39KKxZ9qdZyIptrpxNrSvkHy5aQhrcTRqN9CCNwyM9h9AyWezyYrO4oqVo9t VkWXT0U7yjbqaDo7rxWtSaeipwdN34lLjz1x6pPVWGzZhNE2lZOd0hK3FcTyhKeBERmrjgfyrqhX Cop3qWnlYPTonuR7IuvGd5ny3I7+tc8pye7huznPDGRO9SJYtaPqcbvs+5qTVKC/WJ82PsmxVsOk 29DZb5RKVpIzLO7B4MspPoGY0XSA6da7VnTdCqlVtQEyDT7tyZMkqK4yb5/lFusyEEWG+BJIiVwI zIzyR7Xu9jc2OGmJNLLo0vHEvzToZSsVEe4Yz7UmM1JYcS4y6gltrTzKSZZIy/yGI0fXav165r3t y2tL51ZqFr1BcRJMVVpCJCUuOoNxanEp5PPJFhKeUM9x/o5PYbYpbNDtql0SO200zT4bMVtDW7Yl LaCSRJ3mpWCIuG4zPpMz4jEOpgt+vUfV3WmdVqJUqfFqNfJ2C/KirablI64mHubUoiJZYUk8pyWF F0kObZ4ZWBMiiVaUpXb2PoL3WqP1p/VFyK9YD15WhptWKxAppLVXFOTmY6YCUJ3L2mrJvGSMKwlP MfEyPgO9N10pEm37Tk2lQp1xVu7WnXKVSG3m2VfkiVyvKuqPY2STSpJnx5jwR4MZj1Odq3RSupF1 HodUtusQarM91OtoUmC42+/vgNIRsbUklK3KI0lguJkZEIalaM1dVkaZXZclh1yu0+lw50Gv2+2h bE5LXXct1laG8ocM8vbsErJ4RwMjMdJ2WyYcSyUioseXE30rTs6K6SzCiPUOm2p7V0zq9Qqxb0+3 rmt9Da6lSnFpkqSlaN6VNLbyTpGXNgs8S4cSEbduvNxWtCbuCu6SVanWwpKFLlSqxEbnIJZ4T/sW 415yackaiMuOcYHH0M09fp868bntPT1uwW5dMXAt06k5KVUVGtCVGuQ24+tCUk4hBkRJJXDGeB7s mfsSvT9F65bU7Ry55mo5KVJqNyT2CeJaUOk4RMPqWpbizaQlrY0R5Mz6TFkuzWZzX0YsVclcr+bR tfQHFFQ9B1/XJL14NWhp3aT96VpdMaqikIqTEJlLDiULSfKOGeVbHG1YIuZZfLj6Lg1lmUXSO4r4 qOn1dpk2hSWo71Lqn+zk+a3m297TxJUlaC3n3SSPO3oMjGW1y14KrVsSZdGjV4T3IFsQoxVm3HnE VSNIbaQg2XIvcKLaZKwszVguYsGePqptk6tXZ1Ol/WrXzqqykyG1WvHrS0KqKmGXUukh5ZKxuUSE JLdjCtx97gW+72ZKFuiVVWrxvHjyPo7E0MJmtXhqn2PdT+xqv7hdc8rToM73O672Y65U0Wzldh97 yvPt47eYs8JOodUDKZu6yrbg2FIqUu7LcYrTCGKkgltLebdUljC0ElREbZEbhqSREZnjhg4K+Kle txdSirT2FpVejFSplPp8CW5IgklDio7rBGbCUqNx7JoI8kjaSdx54D97UtW6GeqD0Sqj1t1huBTb CjRJ8lcFwmor5RJaTadWacIWRqSW1RkeVEXjFZdkkQy4nGlVYVMehKqyMOJ1xGtXRqrUaBDtqkv2 TKk31cLbqo1uMT2j5M20mpe+SeEEkiLviI/HgjwY/wAtjWalyYN1IuyjTLVrNpx0yKxTnnUSDbbU jelTbjfBwj4EWMHxLhxIQXVQ6XLr2pts6gSrUqF30GFDXBrNIgOGmSbSeVW2tpKVIUoyU4ZmSVZP aksYMxNW/og3dFqX+dB07TYkKqQG4lCRUX5JVF7Y4zIPrhLjziG0G6yguCSVgz48MnZBIskUpRRO lcr6MeTL0dnbXQVbiqftr9qbXL16m24JcrTmsUShVRMRdLqbspl1L6eumVkbjaT3tbiSrBmRpPhx 7ohvuh35lbG/4cp/1ZsefL6n37XOpYd01b0ou1irUqBT4Mt1cUlMukw6wRHH2KNbxnsSZ7U4SW88 9yPROjkSVA0is2DOjPRZUegQWn2HkGhxpaY6CUlST4kojIyMj4kZC22KGCzKFJL+TyOuKix5WIcp hdv6oWrZTuuF02/p11rPoNaYbqivdp1fus65NfZ5TC0GTGDNa9qSMj3Y8RGKir6/VqmWTS78kaU1 krTkR2HZlROpMEpk3SSRE2yfduJ3q2ktRNkfAy4GQyCr2VeS7Y6o9lFpV9TlYr8N2mIKnPGqahNT eWpTJbfyiSSZKM05IiMj5hq2qlv16Z1D0O3odEqUispoNGaVT2oq1ySWhcY1pNsi3bk7VZLGSwee YbM2VZ8OGqrWJLG3kwYe3Q68CibN1otRh1ijwqvT3Sehzo7cmO4XMttaSUk/8yMh9YlNHIkqBpFZ sGdGeiyo9AgtPsPINDjS0x0EpKknxJRGRkZHxIyFWOFMhUMbS0GRAeSa7qlaNjt1xipzjkVErhrB lBjES3uNRkmW7xILiR90ZcObI9bDy3ULEta84NZZr9KafcK4ayTchHcPN/8AvKT3qy44+Q8l0kN2 xOUq8rWlVk7zq3Spzmxci1hYLy7UfHp1q5bVyW8dTrFWolCkKkOITDkVFtLiUEfcme4yM89OMCk7 PrE/bW2/pRn2h8unNh0uzLdOiMrKe0mQ4627IZTyhJUfemZFxx08PIQpfc6B+oxv4Kf/AEGac5GG 8BOmj9oSmQrVycPKNYWnF5M+aiV6hVwnTotZptTJnHKnElIe2ZzjO0zxnB8/QOkJOlMssaq1lDLL bSTocAzJCSIs8vM6CFYMMyFQvF2GxJjcUNYsuPcwAALDIAAAAAAAGm6WeDr3nSvVSKwSelng6950 r1UisE5sWbwbEec3rnkzaZpqr7/x/NU+uoSIrtVff+P5qn11CREVvTOo/wB0Im105nL2AAAaB0AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT8rX2xdia3Z msH7pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf+CYezP0pm1AAAR8kx LWd4V3t87M/UIoqRLWd4V3t87M/UIoqRlnfN3LgjDI+V7XxYAAGIzAZr1S1UcpWkdQfjSXYstUmL 1q804aFtupfQ4SkqLiRlsMyMuJYGlDI+q0pxzdI3JJbi6wnsSDx8u5rj/FG1Yae8wV6UaV5NqyTK dD4HpClMrjUuJHdccccaYQhS3FGpajJJEZmZ8TM8cTMZRo3rPUNRIr9TOyHKTRIankzqkupIdbYN DaVpIk7ErUZkas8CJJEk8nnBa7HdS9HbeR3riCWWOgyyMR6m3TWvULRa4rNvWnKpztWmSkqbS+26 ZsOxmmjURtqMiPgssZzwHorrVUPHocHBbZ9dJ15ZlrpNWl2ZVIFoVmoFTqdW3JLSuUeNS090yR7k JyhXHJ8x9A7+qmpNXs1yWqn2LUKxCp7CZM+e7LbhR20GSjw0pwvyzhEnJoQR4yRZzwGKW11P1Uiy YNvVXTmgTEsyFKmXNIrck0SGN6sJRFadbUhzaaSIz7nuePHiLPWHTi/bn1OqMlMKn3BblRozkKAi dKJtqiPqSlJyCbwZuOEZLUlRFnusGadqRZWKhlcMvCxfu8607X6BKjWuzaVsTa5V7kjOSYsJ6SiG hBNrWhaVOrI07tzThERZztL9JOaJ/Vmn03SqRfdxW7XaCcdzkV02dEU1IU8eNqUbiLck8lhfNwPm MjIsjh6ZX21pNa1vVjTK37iaprcpEuDInpj1FtbkhxxK2JSHOTSgyU2ZpPj3CiPOSx3pGjd73F1O DdmXTW2pFxRZ3X8E3nlOJZIiNKWVucTVwU5x4kncRcSTkFFEHBL3l/YuqCq1eCrOuO15tr15cTr6 LGfkNvpfjmZkSiWjmVgsmky4YMs8BA0vqkZ87T+TeqNNZp0uDUExKg83VGzRHQrk8KLKEqWszcIt pJxzZUWeHdtOzLxuLWqFqbe9IhUFdIphwIcJiaUlTqz5UlPGpJERJMnV4TxPiWcYEHaulF/wepTu 2yJVA5O4KhV25MWJ14wfKNkqIZq3kvYXBpzgaiPuflIVbiChl1x9nqemKLUYtYo0KrQV74k2O3JY V0oWklJP/kZDI7x11etKpx369YVVp9tyJaordSkSW25ClEpRG4UQ/wApyeEGolHjJY4cSGj6aU2b R9OLZpFSZ5CbBpESNJa3Erk3EMpSoskZkeDIyyRmQ8v3rorqtWqBXIlRo0Cu1tNZKazX3J7ZSZzG 0kFHbQrBNNluU4aTUkiNO0kngjFY3FTEWSoYHE8LIbJWNYaoxqvcOnlFsOTW59JgplMrYqLbfLma GV4US0kTaS5XGdyj7ksJPOC/2ma7W9L0VkalOU+SyiM91q9AJwlLKT3OGyXgiMjJST3GRcDzjxD5 bOs26InVTXVfU2kKjUKpUZpiPIVIaUZukiIRo2JUaiMjacLOMdzz8SGdWvoZeEzqbKvZ1Zp7dNr6 K+dVp7TkltaV4Ybb4qbUpJZLlU8eY8GZeMUrFxL1DLxV7PU7bN63hVeqpsan1OJWbZjyaK6uXRF1 DlWFr5OWonDJB7F8yOJkRkaMGRbRtGqV6U7T+y5tz1Nl19qPtShlrgpxxR4SkjPm4+PxERjKIVra l1zqjbO1BuG1I1KgQqS5HlkxUWn+t1m3JIkq4kalGpxJ9ySiIlF3R4MytuqOsCVqNpnIolOU2mpR 5CJkInFbUKcSSkmkz8WUrWXHhky/yqq0ZbHguKFPIZwzet4VXqqbGp9TiVm2Y8miurl0RdQ5Vha+ TlqJwyQexfMjiZEZGjBkW0cuwtbOxLQl27/c24a9ylznTeTrVw9cvIzFS5uS9yBYQW3Gzbzmo88c ClhWtqXXOqNs7UG4bUjUqBCpLkeWTFRaf63WbckiSriRqUanEn3JKIiUXdHgzLOe0tqX/wBHHsR7 Gv8A312X+6XW3X0f/q/WfJ79/Kbe/wCGM58eMCz+WgzLk3ROmj8m3VnVqrU1VJpCrAnruutOvnTa L7oMkpUdsjUTzrveNmaSM9vdY2mRnwHStvVqh1KyLguWowpdIctt52PVoL21bjDzfOhJp4Lyfckf Dj0CT6obSaRd130S8oVBj3L1hHXEnUV6eqGctru1Nmh4u9Ula1H4s8M8MkPktbRVb2kV3UGVbtIt WfcRNm3FiTJEnkCZUbjCXnHHFkpRKPujbJJHx4HzFdWKpipLwUyos7VO4Lhjb1ab1OE5Ppr9RoJq mtLaqCEJI0JW4Rf7Ope5ON5Y485jFLL1Rvuq6B3lWbmbrcyFHloUmu0+stQZKHTeiJKK2lLajbLa s1mskmkyNSeBnktr0bY1QhR6LQrkoVMotFodNKAtaZiZLtQW2lCGnUEki5JOEmZkozM+gvFlNI0q 1Io+hF9aYlbTUtyVUGZtNnt1BkkzPysfckkKURowhk1ZUZZzgi4EZ0eEXQ4CbWLKjTj1QRQrNsKm 0ujVS47juKkMPQYDs5BvLSUdK1LekLIiM+le0smSjwXMEvW+nI0quK841CknPt2WiHUaPIfS0408 byGjLlEkojLujMjIuO0y4eKenab3fSZOml90Kkxp9wWvQGaZUKO9MSybpFHUgyQ73SCUlTjhZ5j4 HkyIcqpaPXf2oNRlKhRpF23lU2ZyoEeSnk2UJlk6TfKLNKTMiU6Znw8RcRWsRRQy8X7p8itpGuLj txWdArdkzaNTrtjtqps9ya24S3lEjuCQks7MuJIlK2meSPYRHw4OiVUffXeFBlOqddo1yzmUqWo1 LUhby15WZ5M1Gs3OIXdpzeU/tE9aUflOxXrX3a/2lkutdnWm7nX3eOSc7zd3vykOboXBM7z1OrxE sm59zSGm8lwMm3XVZLh/2v8A4Dj34q2V4WhqhIvZh4NuWBpTr++Bq4AAhR6OAAAAAAAAAAABrlge CMHyL9dQyMa5YHgjB8i/XUO3cX1otn5I/wC0maw/2XBndAAEoISBCat95TfK79gXYhNW+8pvld+w NG8s1jOrcmfS+/gyBEtql4KN/O1M+vsCpEtql4KN/O1M+vsCHyPqQ7UTu0fRj2PgVIAAxGYCq0B/ Nun56rH9TlCVFVoD+bdPz1WP6nKFJn0ntX5I97QfTg2svgGTdVhetyWFo5MrdrINM5clqMqVsJXW iFmZG7g+GcklJcD4rI8DKrTpeq1JnU66tPdY+23HdmoKsUg5TRJbZMjUvbyz5kgyzgiLYZGaeGCM iuk2JzJXKOJLQq10duRd5FXFR0PVwDzBPuqqM9U9q/S6tclyt23TbLdllFgTlEqLiNDUp2MhStiH iJSzSrBd0rPjMXli6n2RbOgFDu+XXbnmUmS68xDdrqyk1WW71w6nYewzJaspUScHwQlOcYCZYY4Y YWsdab1UKJGxgPK+r2q06uaoaOR6A9d1rlKryW6rSpzT0B15pb8Qkcq3na6gyNwiPKi74ukXSr5t eia86gctV79lT6Dbi6lPpjkltdIbYbZjOGcVo1EZPGRp4qwWVOceJCrsExQpvK03TY6FMNG3AMXj 9UhZkq0Y10wrdvWZTV7jlux6MbiKelK1JNT7iVcmngndglKPapJ444FhX9VrIounkG+5VWNyjVAk dYm00pTslS+9QhvG418DyR4xg84wMMVknQtJwvG6d5XCRcAMgX1Qdos1u2KHNt+7qdVLimJiMRJ1 L63djqWttCVuk4su4M3OCkb+8V4ywejXvcUW0rRqlzTo0uTEpkdUl9qKlKnTQniraSlJI8Fk+Jlz C2OzzYGlEsuQrVM7IDOa/rNZlGXYxSFT3U3sbfuWppkjJCXOT2qdyojSWXUFwyfPw4GP8uzUS3ZJ 6hWrvr7Dts0NcqqzadsbcYS4wpZFHWas8uSMqSZkSSMi48BVWaa6fx/a044hhI0cBgdpa3WJaGnN gKkzL2qcG55EtiFUKypqRLRycrYtUpZLLuSU4W3YSj2JLhksHXUTW61ahfES0ZlJuihTageKa7WK Q5EanHjJ8kau6+Tukp4mRFnJC+OxToa/xdFXdiZTCRpwDOLt1ktWgXkq0WoNwV2rsIS5NZotMXM6 yQoskp3bxIsY4ERnxLgM16mO+5FUvrWmq1u6Zsy3qbVCfhOTZbi2IkXlZh5QSzw2jYlPAiLgkugh WGxzHKimNUSo9tXQYSrQ9IgMbidUbYjr7D8mmXXT6DJcJqNcMykLbpryjMiIidzkuOeJpIi2nkXE e/qG7qTLsFSJbNUj0tNVS6tCeQejmokmpCiUZmZGeDIyL5M4GOOzToPmhaK4SZWAMopOvtiVPSqt 6kR0VZNHo0rrR9tcdJSFuGbZJ2J34MlcqjGTLx5xgxqECR13BjyyZdZ5ZpLnJukRLRuLO1WDMsln B4MxZMkzJfzqmgJpn7gADGVAAAAAAAAAAAAwC1/7Os/8R1n+pSRv4wC1/wCzrP8AxHWf6lJGzJ+S Lavydu4M5f8AV8UdcAAXkuJeD+dis/MUD/XmCoEvB/OxWfmKB/rzBUDJNyrYuBhkfK9r4sAADGZg AAAAAAA03Szwde86V6qRWCT0s8HXvOleqkVgnNizeDYjzm9c8mbTNNVff+P5qn11CRFdqr7/AMfz VPrqEiIremdR/uhE2unM5ewAADQOgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BfaSd7U/K19sXYhNJO9qfla+2LsTW7M1g/dJ59fefTO7ggAAN45R8Nw+8FR81d9Qxig2u4feCo+a u+oYxQRy/vmg7/wTD2Z+lM2oAACPkmJazvCu9vnZn6hFFSJazvCu9vnZn6hFFSMs75u5cEYZHyva +LAAAxGYCY1OpsKsWuzSKkzy8KdV6XGkt7jTvbXPYSpOSwZZIzLJGRinHIu2FOnUppNMRGXLjz4U xtEh1TTa+QlNPGk1pSo05JsyztPBnzDPZYlBPgiiyJria1ugijs0yGHK4XTwNPhRmYUNmHHSaGWG 0ttpNRqMkpLBcT4nwLnPiP1Ge9l99fsfbfpE/wDgg7L76/Y+2/SJ/wDBCdc62PrEeW8w3j1T3eZo QDPey++v2Ptv0if/AAQdl99fsfbfpE/+CDnWx9YhzDePVPd5mhAM97L76/Y+2/SJ/wDBB2X31+x9 t+kT/wCCDnWx9YhzDePVPd5mhAM97L76/Y+2/SJ/8EHZffX7H236RP8A4IOdbH1iHMN49U93maEA z3svvr9j7b9In/wQdl99fsfbfpE/+CDnWx9YhzDePVPd5mhAM97L76/Y+2/SJ/8ABD4GtRLycuGT Q02ZQCkxojMtajuF7YaHVuoSRH1nnOWlZ4eMv8qq9LI/9RFHcV4KlZT3GogM97L76/Y+2/SJ/wDB B2X31+x9t+kT/wCCFOdbH1iK8w3j1T3eZoQDPey++v2Ptv0if/BB2X31+x9t+kT/AOCDnWx9YhzD ePVPd5mhAM97L76/Y+2/SJ/8EHZffX7H236RP/gg51sfWIcw3j1T3eZoQDPey++v2Ptv0if/AAQd l99fsfbfpE/+CDnWx9YhzDePVPd5mhAM97L76/Y+2/SJ/wDBB2X31+x9t+kT/wCCDnWx9YhzDePV Pd5mhDHtOoUan0WfFiNcm03XKqhJZMzwme+ksmfE+CSLJ8eA7/ZffX7H236RP/ghzbShToNKeRUk Rm5cifNmONx3VONo5eU68SSWpKTVgnCLO0uJcw41+W2RPkQwy4quv4ZJPZm7LVZLTFHOgaTh/KOu AAIuTcAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4vrRbPyR/2kzWH+y4M7oAAlBCQITVv vKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIltUvBRv52pn19gVIltUvBRv52pn19gQ+R9SHai d2j6Mex8CpAAGIzAVWgP5t0/PVY/qcoSoqtAfzbp+eqx/U5QpM+k9q/JHvaD6cG1nN6oe5LztagU 2p25asO6KOqVyNfgLhrkPnGVjum0pURcxKI9yVl3STMiIjz5gqsq0b3vW3n9BNOrltq7YlWbOVMN jkokdsiUSyWlDikp4mW7O3KSUR5zge7wGWzW5SIKKHHtxPatJFIoanju8f8A4ltff/25lfU4Y4tJ otXV1O+iF7RIk2oUq1q9Jl1WHFbNxRtHUTVyuwj47SaUnmPHKeIsj28Ayq9GoYUoclNPRC4ejTXu KYB5C1zvqgX5rFofUraTNfpzdwoJM56E7HQ8o5MQzQjlEpNW0sGZkWO7LBnxH4Xj/wDEtr7/APtz K+pwx7EAWwXjDAlDDBiSay9MVegrgVPNej6Ul/7P+ee0uNu1wz4c575XH/wIZrSaNV1dTvohe0SJ NqFKtavSZdVhxWjcUbR1BSuV2EfHaTSk8x/2niLI9vCP1Msydd0aAql3jcFrT6e8bzMimSDShw+H cvNGex5OUkeFF0lzKUR3SrwWG21SsTi8U1Tfl3FHBiPOeut8UK+tYtDqnbbc56nJuBGyc/CdjofN UmIZpRyiUmrbwMzItvdlgz4j1nU4bFRpsqnykEuPKZWy6ky4KSpJkZf8jGWUDSCsv3pRrt1E1Cm3 lUKEtxdLbKmMQWGFLJJGo0N53H3JHnJcxdA1wYLXNluGXBLfyp723pS4IrCnjqeELdti4rmt286f VVSTqGlVGVApDqGiychqY5IJ1JbeCuTYS2REZ9zg/GNV04KfWepj1V1Eq7eydeEWrTiQZcWmER3G mm88NxJ2KweCyRl5R6aAZpt5uYqYNMafmu94woKHgqjpSq0epdSoiUk7inEZGXAy91WBsXVbEXbr 0IPHHsjP6zCHpMAivLCmwzMHJhadavZoqMDFQ8xWRWY+j2v+pPZ4mqIYuya1Mos9uA9JRITueVyC eTJatyScJJF/2fiLAhNNaNV70pvVKUuiRJUOpVCe24zEMkpdJRSZbhsGR8CMyI0GXymPbACivGib UP8AJ4OOuL+LVMVOzpGAePLwvqkXX1M1N0boVJrMi/EwKbBeo/uW8h2MtlbJrcWakklKT2c+f75Z xxHY6peDcmm9n2DdNNkOzKpAojtq1B5KcrfU9E2ocMz3HlLiFLIuOVYLPHj6rAUhvBQxLBgxVbab y1VHoyDAPGEyxKhbOr9uaMU1DpW/X10mszjU2RoPrJpwpCTIiL+0U0lajzwVt4HnA9ngA17VaorR g1WReL6eHgVhhoAABqlwAAAAAAAAAAAGAWv/AGdZ/wCI6z/UpI38YBa/9nWf+I6z/UpI2ZPyRbV+ Tt3BnL/q+KOuAALyXEvB/OxWfmKB/rzBUCXg/nYrPzFA/wBeYKgZJuVbFwMMj5XtfFgAAYzMAAAA AAAGm6WeDr3nSvVSKwSelng6950r1UisE5sWbwbEec3rnkzaZpqr7/x/NU+uoSIrtVff+P5qn11C REVvTOo/3QibXTmcvYAABoHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvtJO 9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpndwQAAG8co+G4feCo+au+oYxQbXcPvBUfNXfUMY oI5f3zQd/wCCYezP0pm1AAAR8kxLWd4V3t87M/UIoqRLWd4V3t87M/UIoqRlnfN3LgjDI+V7XxYA AGIzAAAAAAAAAAAAAAAAAAAAAAAS8H87FZ+YoH+vMFQJeD+dis/MUD/XmDJLyRbPyjDN+aDb+GVA AAxmYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4vrRbPyR/ 2kzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIltUvBRv52pn19gVIl tUvBRv52pn19gQ+R9SHaid2j6Mex8CpAAGIzAculwbho8d2JRb7r9NhLkvyUxmo8BaG1vOrdWSTc jKXjetR8VHjOB1AFyiaMM6zyp6SmQ1ofLy17fGZcn8lTPwgcte3xmXJ/JUz8IPqAMPsXgvI1+bLJ qI+Xlr2+My5P5KmfhA5a9vjMuT+Spn4QfUAYfYvBeQ5ssmoj5eWvb4zLk/kqZ+EDlr2+My5P5Kmf hB9QBh9i8F5DmyyaiPl5a9vjMuT+Spn4QOWvb4zLk/kqZ+EH1AGH2LwXkObLJqI+Xlr2+My5P5Km fhA5a9vjMuT+Spn4QfUAYfYvBeQ5ssmoj5eWvb4zLk/kqZ+EDlr2+My5P5KmfhB9QBh9i8F5Dmyy aiOQ1WrtcrsijJ1NufrqPFalLzBpm3Y4pxKcH1pz5aV/4D7eWvb4zLk/kqZ+EHBg/nYrPzFA/wBe YKgZI3gvElkWheRjlXdZYk24FlfE+Xlr2+My5P5KmfhA5a9vjMuT+Spn4QfUAx4fYvBeRk5ssmoj 5eWvb4zLk/kqZ+EDlr2+My5P5KmfhB9QBh9i8F5DmyyaiPl5a9vjMuT+Spn4QOWvb4zLk/kqZ+EH 1AGH2LwXkObLJqI+Xlr2+My5P5KmfhA5a9vjMuT+Spn4QfUAYfYvBeQ5ssmoj5eWvb4zLk/kqZ+E Dlr2+My5P5KmfhB9QBh9i8F5DmyyaiPl5a9vjMuT+Spn4QOWvb4zLk/kqZ+EH1AGH2LwXkObLJqI +Xlr2+My5P5KmfhA5a9vjMuT+Spn4QfUAYfYvBeQ5ssmoj5eWvb4zLk/kqZ+EH50KmlSoCoxzJM1 xyS/KekSCQTjrrzy3XFGSEpSWVrVwJJEQ+4Acbap+EjLJsciRFhS4aMAAC02SXg/nYrPzFA/15gq BLwfzsVn5igf68wVAyTcq2LgYZHyva+LAAAxmYAAAAAAANN0s8HXvOleqkVgk9LPB17zpXqpFYJz Ys3g2I85vXPJm0zTVX3/AI/mqfXUJEV2qvv/AB/NU+uoSIit6Z1H+6ETa6czl7AAANA6AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF9pJ3tT8rX2xdiE0k72p+Vr7YuxNbszWD90n n1959M7uCAAA3jlHw3D7wVHzV31DGKDa7h94Kj5q76hjFBHL++aDv/BMPZn6UzagAAI+SYgIdxU6 3LxuxqrM1Rs5VQZfYUzSpL6HEdZx0ZJTbak98hRc/ORjpdsS2OmtfQM77kVoDM45cWNp+Poa6lzY aqGJUq9HS69JJdsS2OmtfQM77kO2JbHTWvoGd9yK0BTClar8fQuwZ2svB/8A0SXbEtjprX0DO+5D tiWx01r6BnfcitAMKVqvx9BgztZeD/8Aoku2JbHTWvoGd9yHbEtjprX0DO+5FaAYUrVfj6DBnay8 H/8ARJdsS2OmtfQM77kO2JbHTWvoGd9yK0AwpWq/H0GDO1l4P/6JLtiWx01r6Bnfch2xLY6a19Az vuRWgGFK1X4+gwZ2svB//RJdsS2OmtfQM77kO2JbHTWvoGd9yK0AwpWq/H0GDO1l4P8A+iS7Ylsd Na+gZ33IdsS2OmtfQM77kVoBhStV+PoMGdrLwf8A9El2xLY6a19AzvuR89p1Fit6hVmqwGZxQvcm FHJ2TBej7nEuylKSROoSZ4JaT4cOItQFcOBJqFPH2+hTk5jiTiiWLs9WAABhM4AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAGuWB4IwfIv11DIxrlgeCMHyL9dQ7dxfWi2fkj/tJmsP8AZcGd0AASghIE Jq33lN8rv2BdiE1b7ym+V37A0byzWM6tyZ9L7+DIES2qXgo387Uz6+wKkS2qXgo387Uz6+wIfI+p DtRO7R9GPY+BUgADEZgAAAAAAAAAAAAAAAAAAAAAAPzkPNR47kh9aW2mkGta1cyUkWTM/wDIfoBk RkZGWSPxYAGYwL/sk9TanLK6KSbD1IhMNOFIThbiXpRqSXSZEtHD/eIacPO9p6OJp/VAyn3I5e4E Ak1KGWO5Upaj5Nv/AOhRKPyITnvh6IG5bYJUMUPJuuJHPu+OfHDFy0NMb4/tAAANM6AAAAAAAAAA AAAAAAAAAAAAAAAAAAAAS8H87FZ+YoH+vMFQJeD+dis/MUD/AF5gqBkm5VsXAwyPle18WAABjMwA AAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNpmmqvv/H81T66hIiu1V9/4/mqf XUJERW9M6j/dCJtdOZy9gAAGgdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+ 0k72p+Vr7YuxCaSd7U/K19sXYmt2ZrB+6Tz6+8+md3BAAAbxyj4bh94Kj5q76hjFBtdw+8FR81d9 Qxigjl/fNB3/AIJh7M/SmbUAABHyTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABrlgeCMHyL9dQyMa5YHgjB8i/XUO3cX1otn5I/wC0maw/2XBndAAE oISBCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gyBEtql4KN/O1M+vsCpEtql4KN/O1M+vsC HyPqQ7UTu0fRj2PgVIAAxGYAAAAAAAAAAAAAAAAAAAABmREZnwIvGAA55vzqnUXKRbzbb0psyKVK cIzjwiMs93jG5eOJNkZGfAzNJGSh/tKjT7tVimPOQaIR4cqSSw5J6Ux8l3vS6fD9DJ90nQaPTIFH pzVPpkVuLFaI9raC8ZnkzM+c1GeTMz4meTPiJFdlyObSZPVF0dJEL69pYZFZNldYtL0LZ0smFadU UoGW3ZCa0R8p7smZHKNePGeMG3/2WNmOYiMiMuIiTNgVFNHr7LcacrPW7zeeQmERZNTZnzKwWTbP uk4Pvk90emj4q3SqfWqc5T6nGRIjuYM0nkjSZHklJMuKVEfElEZGRlkjId23XVJtUFEqNZGv3IRe 7L9tFimNt4ULyp8dpHgPgqjNQtR0m6w6uZSFK2s1Q0kRtZ5kSMFhPyOERJPmPaeN33iEWqyzbLHg TEemWK3SbbK5SS6retoAAGubYAAAAAAAAAAAAAAAAAAAAAAAAAEvB/OxWfmKB/rzBUCXg/nYrPzF A/15gqBkm5VsXAwyPle18WAABjMwAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeu eTNpmmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/AHQibXTmcvYAABoHQAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpndwQAA G8co+G4feCo+au+oYxQbXcPvBUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABrlgeCMHyL9dQyMa5YHgjB8i /XUO3cX1otn5I/7SZrD/AGXBndAAEoISBCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gyBEt ql4KN/O1M+vsCpEtql4KN/O1M+vsCHyPqQ7UTu0fRj2PgVIAAxGYAAAAAAAAAAAAAAAAD4qpUWoR tMpadlTJCjRGiMFl19XQkuYiLxqMySkuJmRC6CCKOJQwqrZbMmQy4XHG6JH7VCZFgRHJcx5DLLZd 0tX/ACIi6TM+BEXEz4EP7o9sy7k2y7ijuRKTztUtfByQXiVI6E/9l0d/zmhPTti0nETG61campVS bPdHjt5OPB4f3MkW9zxG4ZEfOSSSRnmuEwuy5YZNJk7HF0aF6nnl9e0kVorJszpBpel+SP8AEpSh JIQkkpSWCIiwRF8g/wBABICJAAAAfy62h1pbTqErbWk0qSoskZHzkZeMZ9WLdm2zulUNh6dRS4uU 9BGp6IXSwXOtH/Zc5F3mSIkDQwGvabLKtMGBMVUblit06xTVMkuj3PaZ3Blxp0RuXDfbfjuluQ4g 8kZD9x9lzWm8mW9WrZ5Fic4rfKhrPaxNPpMyL8m7/vkXHmUR8DTx6XUWZ6XUJQ7Hkx1bJMV5O11h f6Ki/wDEjLJGXEjMjIxB7wuybY4qvHD0+Z6ddN9SbxgosUayry6UfYAAOadgAAAAAD8Z65LcJ9yH HbkSUtqNppbnJpcWRcEmrB7SM+GcHjoAN0P2ASunt6Q7st5+pORzpkqE64xUYbrhKVEcQZ7iUrBc MFnOC/8AATT+rDhaf1++I9tm5SKdJSxAWqZtVPI3ktKcIuTPYkjVw77ODLhgZ1ZpricNMaaXe8hr O2SVCo3Fiab05Fl/e7KaeAw+LrZecuK1Ki6MV9+O8gnGnW3HVIWkyySkmUfBkZcSMhb3ZqNEtezq NWavSJyalVkNExSWkmp/llpI1Nnki4pM8HwI84LGTwL47HOgahaxvtT4MsgvCzxwuJRYl0prii5A ZbZGryqvc0a3Lms+rWrUJu7rMpZKND2CzjKkIMj5/EZcOfJkQ1IYpsmOS6RqhmkWiXPhwpbr+9oA AGIzEvB/OxWfmKB/rzBUCXg/nYrPzFA/15gqBkm5VsXAwyPle18WAABjMwAAAAAAAabpZ4OvedK9 VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNpmmqvv/AB/NU+uoSI0u9bYnVuptSor0ZCEMk2ZOKMjz uUfiI+kcLtf1f9ag/vq9kcG32C0TbRFHBDVPZ0Eou28rLKssEEcaTSJEBXdr+r/rUH99Xsh2v6v+ tQf31eyNPmu1anDzN7nax9YiRAV3a/q/61B/fV7Idr+r/rUH99XshzXatTh5jnax9YiRAV3a/q/6 1B/fV7Idr+r/AK1B/fV7Ic12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q/61B/fV7Ic12rU4eY52sf WIkQFd2v6v8ArUH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/rUH99Xsh2v6v+tQf31eyH Ndq1OHmOdrH1iJEBXdr+r/rUH99Xsh2v6v8ArUH99XshzXatTh5jnax9YiRAV3a/q/61B/fV7Idr +r/rUH99XshzXatTh5jnax9YiRAV3a/q/wCtQf31eyHa/q/61B/fV7Ic12rU4eY52sfWIkQFd2v6 v+tQf31eyHa/q/61B/fV7Ic12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q/wCtQf31eyHNdq1OHmOd rH1iJEBXdr+r/rUH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/AK1B/fV7Idr+r/rUH99X shzXatTh5jnax9YiRAV3a/q/61B/fV7Idr+r/rUH99XshzXatTh5jnax9YjoaSd7U/K19sXYmrHo EuhFLKU6w5y+zbyRmeMbufJF0ilEpsEuKVZ4YI1RohV7TYJ1rjjgdU6cEAABtnOPhuH3gqPmrvqG MUG4VRhcqmSorZpJbzK20mrmIzSZcRnva/q/61B/fV7I4l72WbPcHJw1pUk9wWyRZ5camxUqyRAV 3a/q/wCtQf31eyHa/q/61B/fV7I43Ndq1OHmd/nax9YiRAV3a/q/61B/fV7Idr+r/rUH99XshzXa tTh5jnax9YiRAV3a/q/61B/fV7Idr+r/AK1B/fV7Ic12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q/ 61B/fV7Ic12rU4eY52sfWIkQFd2v6v8ArUH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/r UH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/rUH99Xsh2v6v8ArUH99XshzXatTh5jnax9 YiRAV3a/q/61B/fV7Idr+r/rUH99XshzXatTh5jnax9YiRAV3a/q/wCtQf31eyHa/q/61B/fV7Ic 12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q/61B/fV7Ic12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q /wCtQf31eyHNdq1OHmOdrH1iJEBXdr+r/rUH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/ AK1B/fV7Idr+r/rUH99XshzXatTh5jnax9YiRAV3a/q/61B/fV7Idr+r/rUH99XshzXatTh5jnax 9YiRAV3a/q/61B/fV7Idr+r/AK1B/fV7Ic12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q/61B/fV7I c12rU4eY52sfWIkQFd2v6v8ArUH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/rUH99Xsh2 v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/rUH99Xsh2v6v8ArUH99XshzXatTh5jnax9YiRAV3a/ q/61B/fV7Idr+r/rUH99XshzXatTh5jnax9YiRGuWB4IwfIv11CR7X9X/WoP76vZFzbEB2l0ONBf UhbjW7JoM8cVGfjIukdW6bHOkTInMhpiOJftus9os8MMqJN1/DOkAAO+RQCE1b7ym+V37AuxCat9 5TfK79gaN5ZrGdW5M+l9/BkCJbVLwUb+dqZ9fYFSJbVLwUb+dqZ9fYEPkfUh2ondo+jHsfAqQABi MwAAAAAAAAAAAAQHVDT59L0erk6mTZMGW11vyb8d1TbiMyGyPCk4MskZl5DHm/ssrkKDFmUPV2v1 OsLjtKVTnmZKi5ZZpJTKDWa0rUnJ5MySR4LaZmeC6Fku6K0wYULpjppOVbr2gsczAihrirlXTTJp PYD8uXJqPuPRIyZdS2kpw1ZJmKk+Zbqi5vkQXdKxwwRGpNdalsRaETklx1c6qPpIpM51JEtZc5IS RcENl4kFw8Z5UZqODlXomwaRatqUu0H6leFdi9c+5LElLeXibJTy3X3PHkld0rJntPOMDrW5q1RK lY9wXLUYMykuW287Hq0F3atxh5vnSk0nheT4EfDjkS277uk2NdMWl+R5/e972i8YqZINC/L6TRAG Gta91JNQsiNP07lU9q75iGob7tTbNJMLcaSh4iSgzMzJ3JoVtMsFxMjyXboGsXur2z//ALOcj2B8 v/8Ard3X3J9cf9mXJ55D/exu+Tj08NHGcqNaDVwHnKu6plczmjlf62uGkdkNXea60ptd5FkuTlss 4kJ5E+uEHz7e4wRqLPHJd7TvX166LcqF0TrIkUq3qWT3X9QKooeJtSEIUhCEbUqWtZqxjBEnue6P dhNMNFXJiSqbeAye0NZHKpcNAptes2oW9GuZpT1AmOymnky0Egl5UlHFszJScEeecunhKUrqkJ8/ T6TeyNNZh0uBUExag83VWjRHQrkyJRbkJUtZm4RbCTjmM1Fngw4SnJR9B6DAZJG1tYO77bplQtOp U2jXTgqJVX5DR9dGeCIzaSZqQk97eNx57su5IfFU9e48c6rWIVm1SfZ9Hn9YVCuNyWk8m9uSnuGT PctOVp45LnLhxFcNDkoug2gcC67XjVpSJsd46fV2Emlia2jcZJ59jieHKNmfOk/Kk0qwZRd5avOU PVOh2NTLVfri6xTOv478aYhtR5J40pJC0knB8kRmo1pwSjPHDjC33rjcFT0buqfQKG/b9y0GpswK q2ctp06clTpp5VJmnDm5SDawSSMjUaiySciyZgRwuGJVRkkqbLjUcDo9DNBjTJDNQOkVmKUGqJSa iQR7mpCC53GVYLcnmyXBSclkiyRn94zOZqXIa0btBF8WZLlVytGwxRiTU2yVLUTLW2ackiIoylqd 5j7osnnJZx0bCu2vvtvwr1tasUB+PIKMiXMYMmH1GZkkuVJJNqMzLBKT3KjwZbdyUnD7yuhyazJO OHo0r0PQ7m9oFaEpVpxR6Hofr+9hdgADhEnAAAA8/a90hynaiUaNR5z1PZvtaaZV0NEWFkl1pPKF /vGlwyP5M9Jiv6oGnQ6R1PlXplPYSxFitRGmm0lwSkpDREKq8rHpN1V23qxUJE5qRQJXXMVLC0pQ tW5tWFkaTMyy2nmMuc/8vtvq2YF4WtMtypuyWYkvZyi46kpcLYtKywakmXOkvFzZHQhtUP8Ag1/y vH4+Ry4rFF/j0XzKi71j2Y6sxiy6Br49Z1Feo97UCNTV09hUNlxhJrbZNtJoSo+tz4knBHxPymLP WaBbNxVqg29KuFyh3Sy717RZBRlKIlFkzLdt2c7ZHjcR5SnpIj4f/RpsT4WuT+YZ+5FvcGmFpV61 qTb9WiPSWaRGRHhyOU2voSlBI4qSREeSSWSxjJcwyzbRJcxRwxdOSFLLxMEmy2hSYpcUPRlibWLo 1duwz9dVum29R7WoGo7FuXS3NkKRTaiiGnruK5uRtXjbhHdGjmLxZ3dyN0Gd2Do1ZVm1RuqwGJky e1nkpE14lm3ngZkSUpTnHDOMjRBqWuZLjawNHZTdoN6wypsuGLlNLxY6tYtLxVAAA1TdJeD+dis/ MUD/AF5gqBLwfzsVn5igf68wVAyTcq2LgYZHyva+LAAAxmYAAAAAAANN0s8HXvOleqkVgk9LPB17 zpXqpFYJzYs3g2I85vXPJm0AADaOeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gyBEtql4KN/O1M+vs CpEtql4KN/O1M+vsCHyPqQ7UTu0fRj2PgVIAAxGYAAAAAAAA/KZJjw4rsqW82ww0k1uOOKJKUkXO ZmfMP1HMrlNdmuQpcZ1tEunvlIjofRyjC1kR4JxHj6SUWFJMiMj4C+VDDFGlG6LpMc6KOGW3LVXo WSpK6tWleV/aXVdihwFsodJk4UF3Y0/Nw+gzUvlDImkEklKJJmSzMizt71X5VnSKs0rT6zrgsKkU +j6gUCFF66aaS0hM9XJJS+06ojJC1biM95mecHx4kZbDalzxq5ykV5hUCqx0kqTBcVlSS5t6FYIn GzPmWXkMkqI0l3h6FY7NIlSkpOTp6e08kvC3WqfPbtGKJaOjs2GBa1aX1W+qvbF9u2i1U5kSCceq 23IqfWynU4WpKUSG1GkjStajznB8M8MkP9tfRZx3SG7qDJtyj2rPuImzbixJkiTyBMqNxgnnHHFk pRKM8m2SSPjwPxb4Im/dV7AsSsNUi6q97nTXo5SW2us33ctmpSSVltCi50KLGc8PINlwwrGzSUyN pQo873pHvGn3PoLRbuosSlLpVTZgRyZmE+p9LT0RBuq2lhBKIkYTkz5845ir5Gnmo9BuLVmHQreh VWl3rHfeZnOVFDJsrWT58kTZllSzN9SSztSWCM1c5DQadV9H9X69R58Ooxa1VbfdVMp6OVfjux1E tszc5I9hqLchvvkmXN0jThRQJ6S6Ka0kqftanlynaUX+zQdEozlBNLtsVeTJrCeu2P8AZm1zm3Uq zv7vKEmeEbj4Y5+A7OkOj1xl1Ol06fXbDKjz6pUVyI+XkOknDbBtrM21GWOUa4lnOCPgPRQC5S0W ufE1T96TzNpbotPp922+7VNM6HSE0Q2npVYVXJMpyc+3hSHGGkOpS0e9OTJxJp48CwWB8tq6UX/B 6lO7bIlUDk7gqFXbkxYnXjB8o2SohmreS9hcGnOBqI+5+Uh6Ou+46NaVvSrguCZ1lTImzlnuSW5s 3rJCe5QRqPKlJLgXj/5fVRqjCrFHhVemvcvCmx0SYzu00721pJSVYMiMskZHgyIxTAhyFXOjy/uI wi7tObyn9onrSj8p2K9a+7X+0sl1rs603c6+7xyTnebu9+UhHK6nup0eoz6NF0+otyMyZ6nINdm1 p9luFGPb+TdjtuIWsyIlERpPOT48B6zAHLTKKfElRGHy9OK9D6o2wq/S6QgrXoFvFTXZCH0kllSW pSEoJC1m6ovyjZZ7rn4nwMxLI0fvWoU7WynvwGoPZRVGZVHddkNqTIS3Lee47VGaMkaC7oixu5uB 43W377tOvT6/BplYbcft102qtyjS2kxVEayPKlpJJkRtL4kZl3Oc4wPitTVHT+6q05RrfuiDOntm f5FO5JrwWTNBqIiWWPGnIYMPSV5SNaMn/ZnFTte/aropa1Bnac25PepLKIk+j1SYS3nm2m0tpdjS GlkllxREvnM9u4uPA89vqeLIum37YrlNvNhtulT5JnTqG/K69KBHMjI2lOHlKk4NKdpcO5M+dR41 0BVQKtSxzW1Qzmr0adae5+ImRUbfTxNvunJEAvk51OtF/mtP+8XefrGfYlR25MZ5t5l1JLbcbUSk qSfMZGXOQoLsuhiirRBiRzqFXeTuYhoVtwnm5RxWD5NvP94yyeDJJKPgM0Oxo8mRImzqxWWZUp1T zzdMqL8KMlaufk2m1ESSzxMzyozMzMzMxEb6stllRpwukTypcew9A9mrdbp8pwzIcKFZIm6d3aV4 CS7Aab8OXb6RTPvA7Aab8OXb6RTPvBw8GXrPw9SUYc7VXj6FaAkuwGm/Dl2+kUz7wOwGm/Dl2+kU z7wMGXrPw9RhztVePoVoCS7Aab8OXb6RTPvA7Aab8OXb6RTPvAwZes/D1GHO1V4+hWgJLsBpvw5d vpFM+8DsBpvw5dvpFM+8DBl6z8PUYc7VXj6FaAkuwGm/Dl2+kUz7wOwGm/Dl2+kUz7wMGXrPw9Rh ztVePofrB/OxWfmKB/rzBUDh23a9NoMuVLivVGTJkoQ249OnOyV7EGo0pI3FGZERrUeC6THcFJsS cWLsKyYYoYf5ZavewAAMZlAAAAAAADTdLPB17zpXqpFYJPSzwde86V6qRWCc2LN4NiPOb1zyZtAA A2jngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQmrf eU3yu/YF2ITVvvKb5XfsDRvLNYzq3Jn0vv4MgRLapeCjfztTPr7AqRLapeCjfztTPr7Ah8j6kO1E 7tH0Y9j4FSAAMRmAAAAAAAAAAAPiqlNZnck5yjsaXHUa40pg9rrCulJ48fjI8kouBkZcB27Zux3r tqi3ITMaoLPbGlNkaWJvyJz3jvjNszPPOk1ER7fhH4T4cafEciTGEPsOFhSFlkj8ZeQyPiR+IyHS u+85tjioscPR5HGva5ZN4wVeKNZH59KNEHlHqlo9ZldVDa0e37cpNx1NVA/I02qNoXGfwqWat6Vq Sk9qSUosqLikvINso1xzLa2xbgkOzKMXBqprPc7FLokfpIL/ABecv7/Max0Klp7QqrqnR9S3Jk/3 UpkJUWO204jrZbaidLcothqM8PK4koi4F8omsi0S7XLUct4uB5taLJOu+c4Jyo9zMP6nKgzLh1im 3dVYFtWrPt1hdPft+ixVRVcoreXKOt5MjLCjwojURmlPNtEozqPqTdLFauiiJ1JdrkeqKapsOmU0 naOyyRoM2ZCSIzN0kmfiM+9490ePTcnTihL1QZ1EiSJ9PrKWOt5KYq0JZmIxj8sk0GajwSeJGR9y noLHDrmh1l1asSpjj9biwZsrrufSIs9TcCY9wPe41jieSI+BlxIZcB0xGFTYW6sndWLgk1g7VpCK /ddJrNZppSmrZoRIiVFx1SSWanX3DwyhBJcI0ngzMlcT2mRZPa2q1+V/TW0rekV+cxLrd1qo71YZ IkyG4xJjcOU8ThnIPCufCOfgY9HXxpVa12VikViSdRptQpLZsR5NLlHGcNgyUXImpJZ2d0rgWDLJ lnBmQ48fQix49qz7baVVUQpFUVVYykSEpdp8g0kklR1kgjSRElJESt3elnIq4YmykMyBKjI7XOiV a3+pzvml1C7ZNxxWZEIoS5qkuS46OXj5Q84RFvPOTIzLOD4mfil6bUrnsOo6HyIt3VqfDumLFiS6 dKcR1qy0aY6EJaQlJbTSl/vjyozQWTGzSNHbXfsCs2e/NrbzdadaeqNSemctOkLbUhSVKcWky/8A lpLG3GM4Is5H6VfSS3Kn2CcvNqyOwjkvc3k3Wy5Xk+R28tlHdf2CM7dvOrm4YOB5RDMhSo/3Eec2 dR9SbpYrV0UROpLtcj1RTVNh0ymk7R2WSNBmzISRGZukkz8Rn3vHujxqWoVz3Hc2p2nFjsT69aUa uU46pUFxS63kJWTS3CY3GR4Uk2zJSDIy7os5FbXNDrLq1YlTHH63FgzZXXc+kRZ6m4Ex7ge9xrHE 8kR8DLiQ7l+ab27d6qQ9KXUKZLoy90GXS5Bxn2U4IjQSyLJJMiIuGDLxGQKGIOZBVURi/U40CFXb y1tt64DXUosirIZlq5RTSn8Py8mZtmkyyZZMiwXHHMO3RbPqN16ywG1UKZbNo6cqJiikqO82uoKz jcl1f9o2RskZ4M8kZZM95mNI000xt/T+rXDUaJJqbrldfS/JRLeS4ls0qcURIPaSsflVd8aj4Fxz kx+lkaf0Cxq9ddxwZs5TtxSuvp/XbqDaZUS3VnswlO1P5VXfGfAi484qoMSqUimJttFmI25bsfdl vUa2OSdmNKNEqctO5iGfjSX+I7/uEeE86jLgk+bV7hnXQao1FefgUM+C5yDND8wuhnxttn/id8f9 zBYWP9hRY0KI3EhsNsMNJ2obQnCUl8hDg3nfSlVlSMcXT0epJ7k9mop9J1qVIdC0vb0I/Gl05ino cNCnHn318pIkvK3Ovr5ty1Y4n4iLgRERERERERfYACIxRRRtxROrZ6DBBDLhUMKokAABaXAAAAAA AAAAAAAAAAAAAAAAAAAAAAABpulng6950r1UisEnpZ4OvedK9VIrBObFm8GxHnN655M2gAAbRzwA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITVvvKb5Xf sC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIltUvBRv52pn19gVIltUvBRv52pn19gQ+R9SHaid2j6Me x8CpAAGIzAAAAAAAAAAAAAAADLJYMh8FLfqFpLNVKZXMopnl2mJPu4/SqNngRdLR4I/7ppPJK+8B s2W1zbLHhy36mnbrBJtsrk5yqt62FjRqpArFOaqFMkokRnM7VpyWDI8GRkZEaVEZGRpMiMjIyMiM uH2DMlR51NqK6xb7qGJi8HIjuGZR5hFwwvBHtXjgThFksFklEW0WlrXHBr7DpNIcizY+ClQnyInW DPOMkXA0ng8KSZpPB4PgeJxd95SrZDixRaUeY3tc067o8eOB5H59DOyAAOiccAAAAADiXVcsOgtt NG25MqMjPWsFjHKO451ceCUFksrVgiyRc5kR2xRwwQuKJ0SL5cuKZEoIFVs+2uVan0SnOVCpyUx4 6DIs4NSlKPgSUpIsqUZ8CSRGZnzEIGpO1C6nUu1lg4lKSolsUszIzWZcy5BlwUfjJsspSfE9xkRp NxZk6oprFeeRJnpI+QaRnkIaT50tEZcTxwNw+6V/ulhJfeIhed9RTay5GKHp6fQ9CuX2bhs9J1pV YtC0LzYAAEeJaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABpulng6950r1UisEnpZ4OvedK9V IrBObFm8GxHnN655M2gAAbRzwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIltUvBRv52pn19gVIlt UvBRv52pn19gQ+R9SHaid2j6Mex8CpAAGIzAAAAAAAAAAAAAAAAAAAHw1GnFIfZmxpDkGpRs9bzG SLejPOkyPgpB4LKD4Hgj4GRGX3ALpcyKXEooXRosmyoJsDgjVU9B07Vus5kpFHrjTUGsYM29meQl kRZNbJn48cTbM9yePfFhR1QzmpQYtRinGltb0ZJSTJRpUhRHklJUWDSoj4kojIyPmH1UO6ZdFdRT rof5WGoyRHq6iJJEfiRIIiIkK8ROFhKuY9p43TK7L5htFJc7FFufqedX17OR2Ws6z44OjSvNF4AG ZERmfAi4+QQNaueXX1Lg2zIVHpxGaX6sjBm70pjZLB/K6fAv7u4+6R17RaZdmgw5joiP2OxTrZNU qSqvhtOldF2Kjy3KLb7bMyrJ/tlryceFkskbplzqxxJsjJR8Mmkj3DgUynIiOPSnXnZk+SZHJmP4 Nx4y5uYiJKSyeEpIkl4iH7U6DFp8RMWGyTTScnjJmZmZ5NSjPipRnkzMzMzMzMx9Ag943pMtkVMk PR5npt0XJJu6GuWN5X5AAAcw7YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabpZ4OvedK 9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNoAAG0c8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACE1b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+l9/BkCJb VLwUb+dqZ9fYFSJbVLwUb+dqZ9fYEPkfUh2ondo+jHsfAqQABiMwAAAAAAAAAAAAAAAAHAZvK2nr zfs5upp93WEE45ENpZHt2pXwUadpntUR4IzPGeg8XQwxRVoshbFHDBTCdK4u874DiTLroES74dpS J+ytTWTfjxuRWe9BEszPcSdpf2a+BmR8PlIfJd9/WfaTpM3BXosJ80krkcKcd2meCPYgjVj5cC5S o20lC8ZbFPlQptxKiy48hTD+XG0ONqbcQlaFkaVJUWSMj5yMhzbbuGh3JBObQqpFqDCVbVLYWStq sZwoucjx4jHUFjThdHlL4YoYlVOqJBhqQ9ccyyXJ0lVuRIEeYmCZ5JXKuPI5E1Y3GyXIkZN5x3W3 vCJJVyEpQgkISSUpLBERYIiExB/OxWfmKB/rzBUDYtM6ZNaw3WiXA1LFZ5UmGLk4Uqt1ptAAA1jc AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANN0s8HXvOleqkVgk9LPB17zpXqpFYJzY s3g2I85vXPJm0AADaOeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gyBEtql4KN/O1M+vsCpEtql4KN/ O1M+vsCHyPqQ7UTu0fRj2PgVIAAxGYAAAAAAAAAAAAAAAPNFzUipVPqlLylUNZorNJpjNRpxYyS3 W24pcmZZLJLQpaOP6Q9LjPKFY1Wga7V++3pEJVNqNPRGZaQtfLJUSWCyojTtIvySuZR85fLjdsU5 SnG3q/lYjn3hZ3PUuFL/ADKvZieMz9u4IV09Urp9X6ef5CZQFr25IzQrZMJSDx40mRkfkH1dT1QK Jece5buuqixajVpNZdaUie0T3IJJCFEgkrLBY3mnmLgki8Q7cPSadTdeY9806VCRRUm64uKpaydQ 4404lRISSdu01r3c5d8rh0/zXNMbxo9xVOtaZXc1RyqbvLSYMtrezyhmZqUkzSsi5zPG3hzZxgi3 I50qKHAlxUrCsePFjbo6bTnS7PPhi5SbBhUiiqsWOqSTVdj8Tn0+BDs7qoYdHtuEUWnVmjKdmRmM pabUnlTJe0uBcWkkXNjeeOfjuAzrTTTmbQbhm3ZdFecr1xS2uR5fZsbZb4ZSlPlIuOCwXAiLjnRR oWuZDHEqOtEk30nUsEqKXBFhKlW2l0Lu8e8l4P52Kz8xQP8AXmCoEvB/OxWfmKB/rzBUDDNyrYuB nkfK9r4sAADGZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTdLPB17zpXqpFYJPSz wde86V6qRWCc2LN4NiPOb1zyZtAAA2jngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAQmrfeU3yu/YF2ITVvvKb5XfsDRvLNYzq3Jn0vv4MgRLapeCjfztT Pr7AqRLapeCjfztTPr7Ah8j6kO1E7tH0Y9j4FSAAMRmAAAAAAAAAAAAAAAAAAAAAAAAP8WpKEmpR klJFkzPgREAJiD+dis/MUD/XmCoEfBmwi1VrCzlx9p0OARK5QsZJ+ZwFgMs5Ua2LgYZDrC9r4sAA DEZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTdLPB17zpXqpFYJPSzwde86V6qRW Cc2LN4NiPOb1zyZtAAA2jngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAQmrfeU3yu/YF2ITVvvKb5XfsDRvLNYzq3Jn0vv4MgRLapeCjfztTPr7AqRLape CjfztTPr7Ah8j6kO1E7tH0Y9j4FSAAMRmAAAAAA49i2jalw1u8plftii1aS3W22kPTYDT60IKnw1 EklLSZkWVKPHNkzPxjeu+xe+zXLwqYq9Jy73vJXdIU5w4VXTLTp29B2AHS7WmnHxf2p9DR/YDtaa cfF/an0NH9gdr4afWbvUjnxnD1P/AC9DmgOl2tNOPi/tT6Gj+wHa004+L+1PoaP7AfDT6zd6j4zh 6n/l6HNAdLtaacfF/an0NH9gO1ppx8X9qfQ0f2A+Gn1m71HxnD1P/L0OaA6Xa004+L+1PoaP7Adr TTj4v7U+ho/sB8NPrN3qPjOHqf8Al6HNH8PtNvsuMvNpcacSaVoUWSURlgyMugdXtaacfF/an0NH 9gO1ppx8X9qfQ0f2A+Gn1m71HxnD1P8Ay9DyLaOjzrGv8ijymFroVLUVRStZZJ1kzyygz8ZmojSf Tyax6oHS7WmnHxf2p9DR/YDtaacfF/an0NH9gbVquWZaWnHNyKmT1NKxe00myKJQScrr827JoOaA 6Xa004+L+1PoaP7AdrTTj4v7U+ho/sDV+Gn1m71N34zh6n/l6HNAdLtaacfF/an0NH9gO1ppx8X9 qfQ0f2A+Gn1m71HxnD1P/L0OaA6Xa004+L+1PoaP7AdrTTj4v7U+ho/sB8NPrN3qPjOHqf8Al6HN AdLtaacfF/an0NH9gO1ppx8X9qfQ0f2A+Gn1m71HxnD1P/L0OaA6Xa004+L+1PoaP7AdrTTj4v7U +ho/sB8NPrN3qPjOHqf+Xoc0Bx76tG1LerdnS6BbFFpMlytuNOOwYDTC1IOnzFGk1ISRmWUpPHNk i6B2BxbwsXuU1S8KuKvQSO6LzV4yHOUODR0y16NnSAABonUAAAAAAAAAAAAAAAAAAAAAANN0s8HX vOleqkVgk9LPB17zpXqpFYJzYs3g2I85vXPJm0AADaOeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gy BEtql4KN/O1M+vsCpEtql4KN/O1M+vsCHyPqQ7UTu0fRj2PgVIAAxGYAAAAP60l98L2+f0f06EP5 H9aS++F7fP6P6dCHe9nc6f8AV8URb2uzGH+y4MuwABNDzYAAAAAAAA/l1aGm1OOLShCCNSlKPBJI uc8j+hlXVWXam09GqqbbhomVXFNjYMyPLhHvMjLmw2Sz8uBRuiqXQw4TSRodAuCg3BHckUCt02rM tK2OOQZSH0oVjODNBmRHjjgf1S65RKrMnQ6XWKfOk09zkpjMaShxcZeVFtcSkzNCspUWDx3p9HDy /wBTNcFn21rI5aVpVxdTo9dpLCuVW263tnsoM3Cw4kj7oicVnm7pJEfDArupd/O/rX8/l9YmCyGO tDLHKwa9htlw3Nbdu8h2QXBSaP1xu5Dr6Y2xym3G7bvMs43JzjmyQ+WkXzZVYqLVOpF4W9UJrueS jxaky66vBGo9qUqMzwRGZ48RGMB6uFLa7k01Q7SHay2qZKJVOaUpK5hb4uWUmgjURr70jSRmWeHE floXCpLOqlHcjdTtcNoOly+2sSp85xuN+QczlLrZIPcXccT51cOOAw3hUClLk8LyN5b1J06cWltu /rVUtR4SlNXjmZmfNjuucdGtXXa1EZjPVm5aNTG5ZKOMuXOaZS8ScbjQajLdjcnOObJDwFp4/bcG zpU24dI5l0NdfG0Vb91pEONHNSUEllRoTyZGRnuyoyPuy8WB6a0g0NpM3SSiUrU2mpqkmK9IlQmU TXEphtv7DNBKZWklZNBKPirBqPBikMbiyF0yTDBlZq0PUKwZsxmHDvi2ZMl9xLTLLNVYWtxajwlK UkrJqMzIiIhTDyj1GGnNm3FaC7urNH65rVMr59ZyeuXkclyTbDiO5SokqwszPiR58eSHq4XwNtVZ imwwwRUQAAFxjAAAAAAACF1a98LK+f1/06aP4H96te+FlfP6/wCnTR/AhftFnS/quLPSfZDMYv7P ggAAOCSkAAAAAAAAAAAAAAAAAAAAAA03Szwde86V6qRWCT0s8HXvOleqkVgnNizeDYjzm9c8mbQA ANo54AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEJq3 3lN8rv2BdiE1b7ym+V37A0byzWM6tyZ9L7+DIESerTzMazOuZDrbLLVTprjjjiiSlCSnMGajM+BE REZmYrB/LiEOINDiErSfA0qLJGIZLiwI1F0E+mwYcDh6UTvZ9Yn7a239KM+0HZ9Yn7a239KM+0O3 7nQP1GN/BT/6B7nQP1GN/BT/AOgvrK6H4+hZSd0rwfmcTs+sT9tbb+lGfaDs+sT9tbb+lGfaHb9z oH6jG/gp/wDQPc6B+oxv4Kf/AECsrofj6Ck7pXg/M4nZ9Yn7a239KM+0O7olUIFUVeU6mTo06I5X 08m/HdS42rFPhkeFJyR4MjLykY/n3OgfqMb+Cn/0HK0ZrudTNQLTj05CI8SVGnnKQ7gtzsRhsmyQ SeH9io858eMeMdy4HB7y8GuR8URn2rUz3JYTXzLg+01sBzqvXqFR5UOLVq1Tac/OWbcRqVKQ0uQr JFhslGRrPKklgs98XSP4cuK3m6GivLrtLRSVluROOW2UdRceJOZ2nzH4/EJhU86ozqAPxiy4kuGi bFlMPxVp3oeacJSFJ6SUXAyHxUa4rfrTz7FGrtLqTsZRpfREltuqaMuBkokmeD8oqUodMByqfclu 1CqPUqn1+lS6gxxeisTG1vN/95BHkv8AMh+1SrdGpkqPEqNXp8KRJPaw0/JQ2t0+PBJKMjUfA+bo FKlaM+8QOo2m0e+LxtmrVee07SKGp1xykOxCdblrWWCNZmrGCwXA0n4y4Z4VtWrtDpEuFEqtZp0C TPc5OG1JkoaXIXki2tpUZGs8qSWCz3xdI/qj1qjVkpB0irQKiUZ02X+tZCHeRcLnSraZ7VfIfEHR 4mVTcONEBeOjNuVGo2/VLVjUq0ajRqk3N64gUtCTfQnnaUSDRwPhxMzwWSxxEXUup4uTswuG4Lf1 cq1ve7dQdmvswYjjffuLWlKlIfTv271ERmRc58CyY3mqVCBS4Ls6pzY0GI0W5x+Q6lttBdJqVgiH xHc1tlQVXB2QUkqOjG6f1431unJkRflM7eJmRc/OZC1wwl8M2NZDI7x0Hrdy2zZ1PlamVD3WtlyU 6VXciLckPrddS4hRGbxKQpvYkiPcZ8CxjGB0NOdI71ti8oFcq+slw3FCjcpytOlJe5J7c2pBZ3Pq LuTUSuKT4pLm5y02Dcluzp7NPg1+lSpj8cpTMdmY2txxkyyTqUkeTQZGXdFwHw3xd9JtejVSS7Lh O1KFTJFQapqpaW3pCWW1LPaXFWD243Ek8ZDBhyjlI2sEkdKdHKfZumNZsOrVMq/Bq0l159fW3W+E uNNtmki3q4lyeSVkuJ/Jkd/SCzajYVpJtuZca65FjOqOC45G5Jxho+JNme9W4iPOD4YLhjBFj99I rx7P9PKZd3ud7m9f8t/s3Lcryex5bff7U5zszzFz/JkfRfF30m16NVJLsuE7UoVMkVBqmqlpbekJ ZbUs9pcVYPbjcSTxkVShSqUicbbhZwdBtNe1ZaEu3/dr3X64qC5nL9a8ht3Nto27d6s/2ec58fNw GgjI7f1jl1q37ErEe2aey3dUx6O63JuBhhcQm5JM7m0uJSqSo8mrYgslgi51ENCZu21Hqg5Tmbmo rk1qSURyOie0biHz3YaNJHklnsX3PP3KuHA8IWqYhGoq1iO0A5zFdob9YdozFZpztTaLc5DRJQp5 BceJoI9xcx+LxD/a1XKJROQ92axT6b1w4TTHXclDXKLPmSncZblfIQrUsozoAM91O1btqwrht2h1 NROSK28lO9L7aG4bJuJRy7xqPKUd0oyPGD5NfEsD7LdvxVa1KqFrxYdJcpkentzY1SjV2O+7IStL KiPrVH5RCDJ3gs+5MiSZd+kUwlWhXAipUtgHwMVujP1Z2kMVenu1FktzkRElCnkFx4mgj3FzHzl4 h80u6rXiT5tPlXJRo8yAzy8yO5ObS5Gbwk97iTPKE4UnieC7oukhWpSjJ3Vr3wsr5/X/AE6aP4HG 1kuWnMyNO57L8eVS5lew3NYeJxs1ORJDTe00kZKJRu99nBbf+XZEM9ol/wDphfZ+WekeyDXuUS/8 nwQAAHBJSAAAAAAAAAAAAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNo AAG0c8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACE1 b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+l9/BkCAAIUeggAAAAAAAGd9TCqS5q3q6uakkvlUYyUd PJkqSSP/APUkDRBN6M0GdF1c1FuFCopUyU/EibCUrlSfbitOGrG3G0yf585znh4x3vZ5/wD6Wuwi 3tcv/wASfb5kt1WsKLUdTtHqdOZQ/FlVlxl9pZZStCn4iVJMvGRkZkOV1SdOl03VawocSFaUO12I b6IjNdbNFIbkYcNaXUoIkpLbye0v0ufhkej6pQ6LVZkKZVKPT50mnucrDekRkOLjLyR7m1KIzQrK Unksd6XRw/arUynVaEuDVafEnxV9+xJZS62rn50qIyMTBwVqeewzaJLoPMem7zVu6LanTqr7k3Tb ipalpp1urlssJWtRpeaQ4tCMMFlvumzWRIJRmZ8MxNsSaZL1utyezOo9NptWtiWua3bEQ2EwCVDk qUwZNGanH2y2KM8bt2zhkiHtKFTadBpqKbCgRY0FCOTRGZZShpKMY2kkiwRY8WB8Ea1LXjKgqjW1 RmFU41Kgm3BbScU1YJRt4T3Bngs7cZwXQKcnkKqcseLKeS9JF2hQb8sikIat28WH5zhUmtUY5EOp xV78mqYyW01J3HgicyRNko8mnJDoXadBO79cO2SVNKs9Z/8A2b69xv2bHuR6338d39hnZ493iyPV MG27dgVV6rQaBSolQeLDstmG2h5flWREZ/5mP1qVEo1SlR5VRpECY/GVuYdfjIcW0fHik1FlJ8T5 ukFLxBz1Wp5LvCLVZtK6nSFdza3ZUictp9DudymVSYpNkrPHJtGjOfHkXWlUOHQurIvyhUWJHp1K KitOlDjNk20le2IeSSRYLi4s+H6RjeapQ6LVZkKZVKPT50mnucrDekRkOLjLyR7m1KIzQrKUnksd 6XRwMUOiR67IrzFHp7VWkNk0/ORGQmQ6gtuEqcItyi7hPAz/ALpdBYqoMdSjnVVNvGplHVQ12i0p FpQqtb8CouVCpG1Gl1U1KptOUZEhTz7eSS4ZJcMySrhhKzyWOPnulfkdJNdYLM2PJiNVGmrjqitk 1HcSqcvDrTZGZIQpJIMiLht2lkyIh7gq1LptXhnDq1OiT425K+RkspdRuSeUq2qIyyR8S6B8Eq0b Ulde9c2xRXuv0NomcpAaV1wlvHJk5lPdknanBHnG0sYxwRQNuognKGGlP2p5er1Jplv1PqcanRYE aBOqXWvX0hhpKXJO4oZHvUXFXBxZceYlYH+3EVCK89dOz5NLKudZK7H+uccpyfJPcnyG/ju28ju2 /wC94sj1LItm3JHuZ1xb9Jd9yNvubvhtq6y27ccjlP5PGxGNuMbS6Cx/dSoFCqUpUqo0SmzJBx1x jdfiocWbKyMlt5UWdqi508x+MU5Mryy/dtTOupF/+Hm2P/5f1t4Y5cRUIrz107Pk0sq51krsf65x ynJ8k9yfIb+O7byO7b/veLI9X0imU2j05qnUinxKdCZzyUeKylppvJmo9qUkRFkzMzx4zMfhUqBQ qlKVKqNEpsyQcdcY3X4qHFmysjJbeVFnaoudPMfjFzhxJFqmpRN9J44pHgx1Nvz/ADP6myLLR6ho qWouutShU2JKuGn1GSdFeeaJSo8hbkzaaDxlJmpCOJYPBD0Yi0LTQ1TWkWvREt0pxTtOSUBoihrN RLNTJbfyajURKM044kR84+ul0OiUqZOmUuj0+BJnucrMejRkNrkLyo9zikkRrVlSjyee+PpMWqXj L4p6adF+1qeG7Pg1GRbNqFCq+ndJrsetm5HUtEtVdckpdcw3JJltauTM+kiLBIyZHnOxXl2Pl1V1 U7aHuV2Pdjf/ALo91NvIZy3u28p3PKbuXxjjzeMb+3b1Aaraq43Q6YiqqSaVTUxEE+aTPJlymN2M +LI/us0KiVomCrNHp9R63cJ1jruMh3kllzKTuI8K+UgUuiKRT03Wh5a1ng2YUrQupU6GkrYXJSw5 JqbXPCJ6OpKH1OFxbJKnTIldztNWOBmOvQ2n43VUals2kzFbkNWYSaS2ykiaSoo8ImSSSeBJztwR eLmHo+s0WjVqB7n1mkwKjDIyPreXGQ62RlzHtURlkh+cK3qBBq7tYhUOmRqk6yTDkxmIhDy2yJJE g1kW40kSEFjOC2l0FiuBjKKdip+5TxdC9yu1PYXYr1n20uyhfXG3HX2eUf8A7bH5TZ/Y53cO++Ua fSaBRbi6te+oFepcSpRE0NpwmJLROI3clCIj2mWMkSjx0c49DM0WjMVZ2rsUmA1UXU7XJaIyCeWX HgayLcfOfj8Zj/GKHRI9dkV5ij09qrSGyafnIjITIdQW3CVOEW5RdwngZ/3S6CxRSyrn1qeGKbLn q6lilHGWbsuJqClEFBn3p9abySXyb1Z/zHroTGsNk0ZqRYdLpFIplKpHZKcp+PCYSwS3kRXnEK2o SSTyTJkZnx4JLm5qcRL2hiSmwQdC4/8ARP8A2ThbkTJmhvh/2AABHyVgAAAAAAAAAAAAAAAAAAAA AGm6WeDr3nSvVSKwSelng6950r1UisE5sWbwbEec3rnkzaAABtHPAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhNW+8pvld+wLsQmrfeU3yu/YGjeWaxnV uTPpffwZAgACFHoIAAAAAAABxrPuimWxWbsj1eNW0KlVdEmOqPRJkltxvrGKjcS2mlJ75tZYzkjS OyA3bDbYrHMcyFVxUOdel2wXjJUqNtKtcXf5n1ds21f8O5PRipfcB2zbV/w7k9GKl9wPlAdb4kna i3nA+DrP1j3H1ds21f8ADuT0YqX3Ads21f8ADuT0YqX3A+UA+JJ2ot4+DrP1j3H1ds21f8O5PRip fcB2zbV/w7k9GKl9wPlAPiSdqLePg6z9Y9x9XbNtX/DuT0YqX3Ads21f8O5PRipfcD5QD4knai3j 4Os/WPcfV2zbV/w7k9GKl9wHbNtX/DuT0YqX3A+UA+JJ2ot4+DrP1j3H1ds21f8ADuT0YqX3Ads2 1f8ADuT0YqX3A+UA+JJ2ot4+DrP1j3H1ds21f8O5PRipfcB2zbV/w7k9GKl9wPlAPiSdqLePg6z9 Y9x9XbNtX/DuT0YqX3Ads21f8O5PRipfcD5QD4knai3j4Os/WPcfV2zbV/w7k9GKl9wHbNtX/DuT 0YqX3A+UA+JJ2ot4+DrP1j3H1ds21f8ADuT0YqX3Ads21f8ADuT0YqX3A+UA+JJ2ot4+DrP1j3H1 ds21f8O5PRipfcB2zbV/w7k9GKl9wPlAPiSdqLePg6z9Y9xx7wuimXPWbUj0iNWlqiVdyS+qRRJk ZttvrGW3uNbrSU984gsZzx/5dgAHJt1titkxTIlTFQ7913bBd0lyoG2m64+7yAAA0jogAAAAAAAA AAAAAAAAAAAAAGm6WeDr3nSvVSKwSelng6950r1UisE5sWbwbEec3rnkzaAABtHPAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhNW+8pvld+wLsQmrfeU3 yu/YGjeWaxnVuTPpffwZAgACFHoIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGm6WeDr3nSvVSKwSelng6950r1UisE5sWbwbEec3rnkz aAABtHPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+ GrUinVUmynxie5LOzu1JxnGeYy6CH3AKRQqJUaL4JkUuLCgdH2HC7ELd+DS/ir9oOxC3fg0v4q/a HdAYvd5OqvBGf361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/i r9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrI vFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB 7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2I W78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XY hbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5Oqv BD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v 4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS /ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/Wr rIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7 oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB 2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4 XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5O qvBD361dZF4s+Wl06FTI5x4LJMtKUazTuM+OCLPE/kIfUADKkkqI1444o3hROrP/2Q== --_004_3349FECF788C984BB34176D70A51782F16B12E33FRMRSSXCHMBSB3d_-- From luismi.diaz@alcatel-lucent.com Mon Nov 15 07:56:39 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795953A6CC4; Mon, 15 Nov 2010 07:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.892 X-Spam-Level: X-Spam-Status: No, score=-5.892 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFNh78TPFZiW; Mon, 15 Nov 2010 07:56:38 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 1AF693A6CCC; Mon, 15 Nov 2010 07:56:33 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAFFv16I011190 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 15 Nov 2010 16:57:04 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 15 Nov 2010 16:57:02 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: Janet P Gunn , Henry Sinnreich Date: Mon, 15 Nov 2010 16:56:59 +0100 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuDQcy6bNFn7oj2SJeZnO8E6ZQihABmoygQ Message-ID: <3349FECF788C984BB34176D70A51782F16B13386@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F16B13386FRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "dispatch-bounces@ietf.org" , "conex@ietf.org" , Johansson S , Kathy McEwen , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , "Ingemar@core3.amsl.com" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2010 15:56:39 -0000 --_000_3349FECF788C984BB34176D70A51782F16B13386FRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Good point, but anyway that file will also have that quality upgraded, a= nd probably more than the online-game :). Today, 20% of people is just using 80% of the network, meaning that 80% = of people is just using 20% of network. It doesn't seems fair to me that al= l the costs are paid equally. In a wonderful world, flat rates will just ha= f down and everything else will be "extras".... Saludos, Luismi ________________________________ De: Janet P Gunn [mailto:jgunn6@csc.com] Enviado el: s=E1bado, 13 de noviembre de 2010 15:48 Para: Henry Sinnreich CC: conex@ietf.org; dispatch@ietf.org; dispatch-bounces@ietf.org; Mike Hamm= er (hmmr); httpstreaming; Ingemar@core3.amsl.com; Johansson S; GARCIA ARAND= A, JOSE JAVIER (JOSE JAVIER); Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUI= S MIGUEL); Mikael Abrahamsson Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP > On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" > wrote: > > > Hi, > > Just a different approach. Think in a traffic jam. I know it > would be nice > > to live in a wonderful world with no jams, but they happen. Know > compare you, > > going back home from work, and an ambulance with someone dying inside. > > Everybody gets away to let ambulance drive first. And that's OK. > > > > Now think on Internet. You are playing a Real-Time game and > your neighbours > > are just downloading files. They can afford some amount of traffic loss > > (+delay/jitter) since TCP retransmisions will do the trick (just will t= ake a > > little longer to get the job done) while you cannot afford losing > > (+delaying/jitterin) your traffic because if it happens, your opponent = will > > blow you away from the arena. That's the point, all traffic flows > are NOT the > > same and need different SLAs. I think your analogy is completely backwards. Yes, everyone gets out of th= e way of the ambulance, because the ambulance is more important. But the real time game is NOT more important than downloading the file that= contains the information on how to turn off the flow of the natural gas pipeline when th= ere is an explosion. What you are proposing in your analogy is not that "everyone should get out= of the way of the ambulance", but that "everyone should get out of the brand new Ferrari so it can race w= ith the Maserati." Janet --_000_3349FECF788C984BB34176D70A51782F16B13386FRMRSSXCHMBSB3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
   Good point, but anyway that file will= also=20 have that quality upgraded, and probably more than the online-game=20 :).
 
   Today, 20% of people is just using 80= % of the=20 network, meaning that 80% of people is just using 20% of network. It=20 doesn't seems fair to me that all the costs are paid equally. In a wonderfu= l=20 world, flat rates will just haf down and everything else will be=20 "extras"....
 
    Saludos,
         Luismi
 

De: Janet P Gunn [mailto:jgunn6@csc.com= ]=20
Enviado el: s=E1bado, 13 de noviembre de 2010 15:48
Para:<= /B>=20 Henry Sinnreich
CC: conex@ietf.org; dispatch@ietf.org;=20 dispatch-bounces@ietf.org; Mike Hammer (hmmr); httpstreaming;=20 Ingemar@core3.amsl.com; Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIE= R);=20 Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); Mikael=20 Abrahamsson
Asunto: Re: [dispatch] [conex] [httpstreaming]=20 Q-HTTP





> On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LU= IS=20 MIGUEL)"
> <luismi.diaz@alcatel-lucent.com> wrote:
>
= >=20 > Hi,
> >    Just a different approach. Think in a tr= affic=20 jam. I know it
> would be nice
> > to live in a wonderful w= orld=20 with no jams, but they happen. Know
> compare you,
> > goin= g=20 back home from work, and an ambulance with someone dying inside.
> &g= t;=20 Everybody gets away to let ambulance drive first. And that's OK.
> &g= t;=20
> >    Now think on Internet. You are playing a Real-Ti= me=20 game and
> your neighbours
> > are just downloading files. = They=20 can afford some amount of traffic loss
> > (+delay/jitter) since T= CP=20 retransmisions will do the trick (just will take a
> > little long= er to=20 get the job done) while you cannot afford losing
> >=20 (+delaying/jitterin) your traffic because if it happens, your opponent=20 will
> > blow you away from the arena. That's the point, all traff= ic=20 flows
> are NOT the
> > same and need different=20 SLAs.

I think your analogy is complet= ely=20 backwards.  Yes, everyone gets out of the way of the ambulance,= =20
because the ambulance is more important.= =20

But the real time game is NOT more important tha= n=20 downloading the file that contains the
information on how to turn off the flow of the natural gas pipelin= e when=20 there is an explosion.

What you are= =20 proposing in your analogy is not that "everyone should get out of the way o= f the=20 ambulance",
but that "everyone should ge= t out=20 of the brand new Ferrari so it can race with the Maserati."=20

Janet --_000_3349FECF788C984BB34176D70A51782F16B13386FRMRSSXCHMBSB3d_-- From jose_javier.garcia_aranda@alcatel-lucent.com Tue Nov 16 02:30:45 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6943A6DC2; Tue, 16 Nov 2010 02:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.592 X-Spam-Level: X-Spam-Status: No, score=-5.592 tagged_above=-999 required=5 tests=[AWL=0.656, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdZFmwfQ+CbM; Tue, 16 Nov 2010 02:30:42 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 575AD3A6BDE; Tue, 16 Nov 2010 02:30:40 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAGAVJGn031394 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Nov 2010 11:31:22 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 16 Nov 2010 11:31:08 +0100 From: "GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER)" To: "dispatch@ietf.org" , "conex@ietf.org" , "dispatch-bounces@ietf.org" , httpstreaming Date: Tue, 16 Nov 2010 11:31:07 +0100 Thread-Topic: [dispatch] [conex] [httpstreaming] Q-HTTP Thread-Index: AcuDQcy6bNFn7oj2SJeZnO8E6ZQihAAC+YrwAIqwEDA= Message-ID: <3349FECF788C984BB34176D70A51782F16B13702@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_3349FECF788C984BB34176D70A51782F16B13702FRMRSSXCHMBSB3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "PEREZ LAJO, Jacobo \(Jacobo\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 10:30:45 -0000 --_004_3349FECF788C984BB34176D70A51782F16B13702FRMRSSXCHMBSB3d_ Content-Type: multipart/alternative; boundary="_000_3349FECF788C984BB34176D70A51782F16B13702FRMRSSXCHMBSB3d_" --_000_3349FECF788C984BB34176D70A51782F16B13702FRMRSSXCHMBSB3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi Janet i like your example about the explosion :-) i have attached an image named Q-HTTP_phases.jpg for quick understanding (= for people that have asked for it) There are two ways to address an undesirable situation: "adaptative solutio= ns" and "enhance QoS solutions" For both cases Q-HTTP could be a handy tool Regarding QoS solutions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If the files about the way to avoid the explosion are so important, then these files could be downloaded using SLA , and for sure the user or t= he content provider will pay for that. user-----(pay per FTP with quality)---->content provider-------(pay for qua= lity)--------> ISP user-----(pay per game with quality)---->content provider-------(pay for qu= ality)--------> ISP user----( no pay anything)----->content provider ------( no pay for quality= )----->ISP video or videogame is not more important than FTP, and FTP is not more impo= rtant than video. It depends on how much the content provider or the user is willing to pay = for it with QoS Regarding adaptative solutions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Q-HTTP also may be used for detect packet loss and adjust FTP bitrate, or change parallel FTP for sequential FTP. Q-HTTP is a tool. The decision to t= ake when Q-HTTP alerts is open - jose Javier ________________________________ De: Janet P Gunn [mailto:jgunn6@csc.com] Enviado el: s=E1bado, 13 de noviembre de 2010 15:48 Para: Henry Sinnreich CC: conex@ietf.org; dispatch@ietf.org; dispatch-bounces@ietf.org; Mike Hamm= er (hmmr); httpstreaming; Ingemar@core3.amsl.com; Johansson S; GARCIA ARAND= A, JOSE JAVIER (JOSE JAVIER); Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUI= S MIGUEL); Mikael Abrahamsson Asunto: Re: [dispatch] [conex] [httpstreaming] Q-HTTP > On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" > wrote: > > > Hi, > > Just a different approach. Think in a traffic jam. I know it > would be nice > > to live in a wonderful world with no jams, but they happen. Know > compare you, > > going back home from work, and an ambulance with someone dying inside. > > Everybody gets away to let ambulance drive first. And that's OK. > > > > Now think on Internet. You are playing a Real-Time game and > your neighbours > > are just downloading files. They can afford some amount of traffic loss > > (+delay/jitter) since TCP retransmisions will do the trick (just will t= ake a > > little longer to get the job done) while you cannot afford losing > > (+delaying/jitterin) your traffic because if it happens, your opponent = will > > blow you away from the arena. That's the point, all traffic flows > are NOT the > > same and need different SLAs. I think your analogy is completely backwards. Yes, everyone gets out of th= e way of the ambulance, because the ambulance is more important. But the real time game is NOT more important than downloading the file that= contains the information on how to turn off the flow of the natural gas pipeline when th= ere is an explosion. What you are proposing in your analogy is not that "everyone should get out= of the way of the ambulance", but that "everyone should get out of the brand new Ferrari so it can race w= ith the Maserati." Janet --_000_3349FECF788C984BB34176D70A51782F16B13702FRMRSSXCHMBSB3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
  = ;hi=20 Janet
 
i like your example about the explosion=20 :-)
i have attached an image named Q-HTTP_phases= .jpg for=20 quick understanding  ( for peopl= e that=20 have asked for it)
 
<= /SPAN>
There are two w= ays to=20 address an undesirable situation: "adaptative solutions" and "enhance QoS=20 solutions"
For both cases = Q-HTTP=20 could be a handy tool
 
Regarding QoS=20 solutions:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
If t= he files=20 about the way to avoid the explosion are so important,=20
then these files could be downloaded using SLA ,= and=20 for sure the user or the
content provider will pay for that.
 
user-----(pay per FTP with quality)---->= content=20 provider-------(pay for quality)--------> ISP
 
user-----(pay per game with=20 quality)---->content provider-------(pay for quality)-------->=20 ISP
 
user----( no pay anything)----->content provi= der=20 ------( no pay for quality)----->ISP
 
 
video or videogame is not more important than FT= P, and=20 FTP is not more important than video.
 It depends on how much the content provide= r or=20 the user is willing to pay for it with QoS
 
Regarding adapt= ative=20 solutions:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 
 Q-HTTP=20 also may be used for detect packet loss and adjust FTP bitrate, or=20
change parallel FTP for sequential FTP. Q-HTTP i= s a=20 tool. The decision to take when Q-HTTP alerts is open
 
 
- jo= se=20 Javier 
 
De: Janet P Gunn [mailto:jgunn6@csc.com]
Enviado el:= =20 s=E1bado, 13 de noviembre de 2010 15:48
Para: Henry=20 Sinnreich
CC: conex@ietf.org; dispatch@ietf.org;=20 dispatch-bounces@ietf.org; Mike Hammer (hmmr); httpstreaming;=20 Ingemar@core3.amsl.com; Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIE= R);=20 Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); Mikael=20 Abrahamsson
Asunto: Re: [dispatch] [conex] [httpstreaming]=20 Q-HTTP





> On 11/11/10 12:43 PM, "DIAZ VIZCAINO, LUIS MIGUEL (LU= IS=20 MIGUEL)"
> <luismi.diaz@alcatel-lucent.com> wrote:
>
= >=20 > Hi,
> >    Just a different approach. Think in a tr= affic=20 jam. I know it
> would be nice
> > to live in a wonderful w= orld=20 with no jams, but they happen. Know
> compare you,
> > goin= g=20 back home from work, and an ambulance with someone dying inside.
> &g= t;=20 Everybody gets away to let ambulance drive first. And that's OK.
> &g= t;=20
> >    Now think on Internet. You are playing a Real-Ti= me=20 game and
> your neighbours
> > are just downloading files. = They=20 can afford some amount of traffic loss
> > (+delay/jitter) since T= CP=20 retransmisions will do the trick (just will take a
> > little long= er to=20 get the job done) while you cannot afford losing
> >=20 (+delaying/jitterin) your traffic because if it happens, your opponent=20 will
> > blow you away from the arena. That's the point, all traff= ic=20 flows
> are NOT the
> > same and need different=20 SLAs.

I think your analogy is complet= ely=20 backwards.  Yes, everyone gets out of the way of the ambulance,= =20
because the ambulance is more important.= =20

But the real time game is NOT more important tha= n=20 downloading the file that contains the
information on how to turn off the flow of the natural gas pipelin= e when=20 there is an explosion.

What you are= =20 proposing in your analogy is not that "everyone should get out of the way o= f the=20 ambulance",
but that "everyone should ge= t out=20 of the brand new Ferrari so it can race with the Maserati."=20

Janet --_000_3349FECF788C984BB34176D70A51782F16B13702FRMRSSXCHMBSB3d_-- --_004_3349FECF788C984BB34176D70A51782F16B13702FRMRSSXCHMBSB3d_ Content-Type: image/jpeg; name="Q-HTTP_phases.jpg" Content-Description: Q-HTTP_phases.jpg Content-Disposition: attachment; filename="Q-HTTP_phases.jpg"; size=83782; creation-date="Sat, 13 Nov 2010 17:23:43 GMT"; modification-date="Sat, 13 Nov 2010 17:23:43 GMT" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCALsBAwDASIA AhEBAxEB/8QAHQABAQEBAQEBAQEBAAAAAAAAAAYHBQgEAwIBCf/EAGMQAAAFAwIBAw0LCQUEBwUH BQABAgMEBQYRBxIhEzFRCBQWFyIyNkFxdJay0hU1VVdhdZW0wtPUIzdSVFaSk5S1M0JTgbMkYnaR GDRjcqGx0QklOEOCJicoOUR3hGRzhaLB/8QAGwEBAAEFAQAAAAAAAAAAAAAAAAYBAgMEBQf/xABA EQACAAMCCQkIAgAGAwEAAAAAAQIDEQQFEiExNEFScaGxExVRU2GBkdHhBhQWMjNjwfAiciNCQ5Ki 8WKC0iT/2gAMAwEAAhEDEQA/APZYDNdVDMq9HIjPHWpesoSO5XSY49pveGRNctw1p2kjsns/7xJh m8pSvZ6m8AMH3K6TDcrpMYOfodTebHwx93d6m8AMH3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XS Yc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+GPu7vU3gBg+5XSYbldJhz9Dqbx8Mfd3epvADB9yuk w3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6m8AMH3K6TDcrpMOfodTePhj7u71N4AY PuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+GPu7vU3gBg+5XSYbldJhz9Dqbx8Mfd3e pvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6m8AMH3K6TDcrpMOfodTePh j7u71N4AQmkpmaKkRmZ8Wvti7HYs07l5SmJUqR622X3WfFJrWmnuqAABnNUAPhuAzKg1AyPB9au+ oYxXcrpMc+3XgrI4U4a1Oxdl0+/QxRYdKdlfyjeAGD7ldJhuV0mNDn6HU3nT+GPu7vU3gBg+5XSY bldJhz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6m8AMH 3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+GPu7vU 3gBg+5XSYbldJhz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx 93d6m8AMH3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1 N4+GPu7vU3gBg+5XSYbldJhz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0m HP0OpvHwx93d6m8AMH3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpM Nyukw5+h1N4+GPu7vU3gBg+5XSYbldJhz9Dqbx8Mfd3epvADB9yukxrdgmZ2lBMzMzwv11DdsV5K 1xuFQ0oc+8rn9xlKZh1q6ZKdPazugADpHEAAIXVozJFNwZlxd+yMFpnchKcxqtDasVl96nwya0rp 7ql0AwfcrpMNyukxx+fodTeSH4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6m8AMH3K6TDcrpMOfod TePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+GPu7vU3gBg+5XSYbldJ hz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6m8AMH3K6T DcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+GPu7vU3gBg +5XSYbldJhz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0OpvHwx93d6 m8AMH3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyukw5+h1N4+G Pu7vU3gBg+5XSYbldJhz9Dqbx8Mfd3epvADB9yukw3K6TDn6HU3j4Y+7u9TeAGD7ldJhuV0mHP0O pvHwx93d6m8AMH3K6TDcrpMOfodTePhj7u71N4AYPuV0mG5XSYc/Q6m8fDH3d3qbwAwfcrpMNyuk w5+h1N4+GPu7vU3gBKaWmZ267kzP/aleqkVY7UmZysuGPpVSOWqR7vOilVrQzTVX3/j+ap9dQkRX aq+/8fzVPrqEiIhemdR/uhE+unM5ewAADQOgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABfaSd7U/K19sXYhNJO9qfla+2LsTW7M1g/dJ59fefTO7ggAAN45R8Nw+8FR81d9Qxig2u 4feCo+au+oYxQRy/vmg7/wAEw9mfpTNqAAAj5JgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1ywPBGD5F+uoZGNcsDwRg+RfrqHbuL60Wz8kf8AaTNY f7LgzugACUEJAhNW+8pvld+wLsQmrfeU3yu/YGjeWaxnVuTPpffwZAgACFHoIAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGm6WeDr3nSv VSKwSelng6950r1UisE5sWbwbEec3rnkzaZpqr7/AMfzVPrqEiK7VX3/AI/mqfXUJERW9M6j/dCJ tdOZy9gABE6eX72W3PdlE9yesux6b1ryvXHKdcd26ndjaW3+yzjJ8/yDThlxRQuJLEspuRzYIIoY G8cWTuxlsAiaxfvufq9RtP8A3J5T3ThKlde9cY5PBPHt5Pbx/sefcXffJxtgjlxQUwllVRLmwTG1 C8jo9oAAFhkAAJvU26OwuyKhc3WHX/WfJ/7PyvJb97qUd9tPGN2ebxC6CBxxKGHKy2ZHDLgccWRY ykAc21qp7uWxSq3yHW/uhCZlclu3cnyiCVtzgs4zjOCHSFGnC6MrDEokmtIARNIv33Q1erOn/uTy XuZCTK6964zymSZPbye3h/bc+4+9+XhbC6OXFLphLKq+JZLmwTU3C8ja71lAAJvU26OwuyKhc3WH X/WfJ/7PyvJb97qUd9tPGN2ebxCkEDjiUMOVl0yOGXA44sixlIA5trVT3ctilVvkOt/dCEzK5Ldu 5PlEErbnBZxnGcEOkKNOF0ZWGJRJNaQAAKFQACJ1kv3td2xGrfuT7p8vNTF5Lrjkdu5C1bs7VfoY xjx/IL5cuKZEoIVjZjmzYJMDjjdEi2AAFhkAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT8rX2xdia3Z msH7pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf+CYezP0pm1AAAR8kw AAAAAAAAHAsu8ravKJIlW3U0z2o6ybdMmltmhRlkspWkjwfTjHA+gx+lvXXQLgqlWplIn9cy6Q9y E9vkVo5Fe5acZUkiVxQrikzLh5Be5UcNap4svYY4Z0uKjUSdcmPLsO2AALDIAAAAAfy4tDadziko IzJOVHjiZ4Iv8zMiHGmXXQIl3w7SkT9lamsm/Hjcis96CJZme4k7S/s18DMj4fKQrDDFFkRbFHDD 8zodsAH8uLQ2nc4pKCMyTlR44meCL/MzIhQuP6AcSZddAiXfDtKRP2Vqayb8eNyKz3oIlmZ7iTtL +zXwMyPh8pDtirhcNKrKWwxwxVwXWgAAFC4AAgKrrJptS6pLpk64+RlxHlsPt9YyFbFoUaVFkmzI 8GR8SPAvlyo5jpBC3sMc2fLlKsyJLa6F+AnHb5tNu0n7rKtx3aKwpKXZTKVOEgzUSSI0pI1ZypPD HjHapU6LVKXFqcF3loktlD7Dm0070LSSkngyIyyRlwMsijlxQqrRWGbBE6QtPT3dJ9IAAtLwAAAA AAAAAAAAAAAAAAAAAAAAAA1ywPBGD5F+uoZGNcsDwRg+RfrqHbuL60Wz8kf9pM1h/suDO6AAJQQk CE1b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+l9/BkCAAIUeggAAAAAfjPlxYEN6bNkNRozKDW666 okoQkuczM+BECVQ3TGz9gEjRtTLCrFTOmU+6Ke7K37EoNRo3q6EmoiJX/wBJmK4XRy4oHSJULJc2 CYqwNPYAABaXgB/Li0NNqccUlCEEalKUeCIi5zMxxriuugW/VKTTKvP62l1d7kIDfIrXyq9yU4yl JknitPFRkXH5DxWGGKJ0hVS2KOGBVidEdsAAULgADiTLroES74dpSJ+ytTWTfjxuRWe9BEszPcSd pf2a+BmR8PlIVhhcWRFsUcMPzOh2wH8pWhalpSpKjQe1REedp4I8H0cDI/8AMf0KFwABAVXWTTal 1SXTJ1x8jLiPLYfb6xkK2LQo0qLJNmR4Mj4keBfLlRzHSCFvYY5s+XKVZkSW10L8BOO3zabdpP3W Vbju0VhSUuymUqcJBmokkRpSRqzlSeGPGO1Sp0WqUuLU4LvLRJbKH2HNpp3oWklJPBkRlkjLgZZF HLihVWisM2CJ0haenu6T6QABaXgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABpulng6950 r1UisEnpZ4OvedK9VIrBObFm8GxHnN655M2maaq+/wDH81T66hIiu1V9/wCP5qn11CREVvTOo/3Q ibXTmcvYB5esuo6j0/U7Uftf0Cm1flK051714sk8nh5/k9uXUc+V55+Yubx+oRnmlljVa1bxves1 CRCdj1+oFJipYWo1oTyjysLI0kRHhxPMZ8xi2yzoZUuZVJ1SxPTjKW2zxzpsrBbSTdWtGJ/9GXUO bes/qn7UevujwqVUyp7yWmYiiUhTPJSTJR4WvjuNZc/iLh00V/RbEkX/AFJu+q/ULneUSDhUGCxI xAIi8ZMqwajJRcT2nxPhx4V9dsarT9dqBfbMiEmm06nrjPNLWonlKNL5ZSRJ2mX5VPOouYxzmrEv S3b9rtfs6q0I4tfdJ2WiqsvLcjqLJ/k9h91xUrgZpIiwWOA2naJcUUMSeC8HRix1yVxtfqNFWWbB DFC4cJONvHjxUWOlUnjxdmWhB6Y1qZO0/wBXqQtdRKnU+LJOCxUFKVIjIW1ILkl7jPBkTacp8R7u kcm1tOk1rqf0XdMuSsoepkSXLpsRl1KY7BsuOq73bk1GpKj3EZHxLoGjWtpdcdGjahx5NWp09V1Q 1JakmS21dcKQ7uNaCSZJSa3lcxqPBFwHdtOxqtSdCXrEkyIS6kunzYxOtrUbO55TppPJpJWC3lnu fEfOMky1wQNuXFlih8KY95jlWGZGoVOheKGJd+Fi3ZDPqxf9cg9SrR6x12/7rVFZ01MtKj5RJJcd TvNRnncaGTLdnO48+T4NWtJm7O0sq1YhXTXJL6uQ90WZDxKYlGbzZZ27SMjJW0yMzM+5wNEo+lzj uhLGnddlRylNpdMpMbctDbhvrcQotxJMyLcRGXDxl8ola9pZqxX7UlUOt39AmMNGgoUfktiHSStO FPOE3v4JJR47rutvEJU+XDM/hEoVhNvtVVSmL9yidZp0Uv8AnA4m4El2OjrXHp35D/L+butWien7 1AiTp1OZhQl1aJBWtD77RMt4SSkd0ST7ojMiPGSPxGOfpTVLBevult2XUqtZ8hLjjc2hzUOPNT1Y LgSlOGSFFg+J8ckXDhx06bZddc0/tqkU25HqPWKIxFTy0ZxZx31NISlSHEkad7Zmnx/8uJkORGsK 6rivKi3Jf8q3iXRHFOxWKOy6XKr7k0qcW5x4GkjIiLxfKYxw2iXycULdMuTtyVVKPboMsdlmqbDH DDX5cvZStHVOHZjTIebbjt1dVJd1JKs1Ckx1UxpclyC4SHXWyai/kyUZHgjUaTPhzJx4x19E471o a03RpxEny5dGiQkS46ZKyUptR8io8YIiLPLHnBFnBCxoVjVaBrtX77ekQlU2o09EZlpC18slRJYL KiNO0i/JK5lHzl8uFCsarQNdq/fb0iEqm1GnojMtIWvlkqJLBZURp2kX5JXMo+cvlwjtMMUDgbxY C/3Km8rLsccExTFD/LlH/tdd2Qz6sRNPHrhrHZVV63flfRJW403SmJJdYFzE02Ta9hKI0+M/EWSL Bjg0yt1Ot9SHcqqrLdluQ6i3GbddWa1mjloyyI1GZmeDWZF8mC8Q0W1dPr+s5yqUm16/QEUWoSnJ RSZkZ12YwpREWCIlElWEpTxUfE8nghz6bpDcNP0buewmp9LcdqFSTJgyFOOEnkyWyf5TuO5Vta5k 7iyfP4xlhnyVROKtHC1sWXFRJbDXis094TUFKwxp06WsWOrb2smNIp0fUa5aBQ7lbdZptvUZhymU 1xsyRNcQlLa31HzKIjSeC6DPoVn6daKu9cWrD9lTo12v0KmwUuOQ7ejE48+4okq3qI+BtkSyTky4 GWMcci6rGnNYKiWPMokmnx7mtdlhhTrilExIbJskOt7iQZ4Vg8Htzgz5s8P21I0+uCp3VHvKyrgZ odeaiHFd5Vre0+nOSIzMjxjm4pPOC5sCxWiS5yjToqNLsdcvf0mR2SerO4Gquqb/APJUyZdHR0Lt OH1Pb9eg16t0CRTbuat8m0SKW7X4i23UGRJSts1d7znkkkfMkzwXEaHqn+bG6vmWZ/orHO0yti6a KqdUrwuyRXanN2EbSVGmLHIi4k2jBJIzPnMkp5ubnz0dU/zY3V8yzP8ARWNOdHDHaU12ZDoSJcUu xuGKuR5cukw/SjSVi9dKqRVp90Vph9BvHTmGHkkxFNLzmD2mkzNRr3KyRkfH5Bwb8umZdnUyUWVU XzkTYdwJhvuqLis0sOqSZ9J7VpyfjHf0ks/UWoaW0p+0r5RTKZUjf67iyGSWbJk64gzaVtMyySSP aRp4mZ54ivvnRyTK0hpFjWxMiJdhT0y3n5qlIJ09jpKPuUqweVlgscxc46kU+CCf/iRp0ixdix1r i/cpxYLLMmWb/CgarBj/APJ4qUx7eBH6yWpL01YpOoMK6a5Ua8uoNsS3JT5bHSNK3DSREkjJGUY2 mZlg/kGia3ooK5lH7LLvep1EysnaNHbc5WpKPucZbVu2lkuG0y4nxLPD7dfbGq1/2dEo1GkQmJDN QRJUqWtSUGkm3EmRGlKjzlZeLpH86k2NXKredFvW1p9PZrFJaWyiPUkLVGdSrcWT2cUmRLXzFk+5 4lgacM+GNS3HFSJYXpoxbdB0I7LHKc2GXBWF4OLH3vKq6KquMzbT+qU6k9UBR6FZsKt0m3Z8B0nY VQ5ZKHFkh1fKtocUZ4y2ktx+MlkJ+ZKgUu46kjWi3Lhkzlz1HBrEeQ8llhJ4xySSWSdpY3Fg1H4s ZTx1ZnT69H9WKBf1ZrFGlvQ23GJMdhpxlDTRtrSkms7jWeXFmZqNPiH2P2vqVSZs+Pb9xUeq0ifI U6aLhJ996IlWC2NmRmS0lg8JVguBdJmM3vMtRJp5YVV1adU3ppxWM1/c5zgacLxROiomqNKn8a9P Q8RI3Pd822upzYmUS7XrifkySgsVbrY2nWknuUZLJSjMlJJJpJR8eKfKJCmRapa9bpdatGharrml MQqqoqtNVyElnBk5wbyZq6N2enOSIa1A0epcbR+RYKpyluSVnIcm8nzSOGFknPMW1JYzxIucfBQb C1SXVYTFy6kLcocB1DjbcAjZfkkku8cWlKT2nwI8qXkug8GKS7RJhhiSayutdK0ZFuxFZtktEUUD iheRUpjwWsuNvfj6DXgABxSRF9pJ3tT8rX2xdiE0k72p+Vr7YuxNbszWD90nn1959M7uCAAA3jlH w3D7wVHzV31DGKDa7h94Kj5q76hjFBHL++aDv/BMPZn6UzagAAI+SYAAAAAAAPKPU/SHrTt1q+0u H7mKrKqVWknzIYW20bL3EyItjizzzmZLMUWnlys2lV9a7kcbJ9MOqJU2jJ4WtUiSlBZIjwRqUksi /wBGdNpdradVW07nXAmpqEt1xZRlKUg2ltNowZqSk89wfi6BwtONF5lHot6UK5J8WZCr5NIYdYUp bqeTU6ZLWS0kRLI1IVwM+JGO7OtMiZFMcT0rvVU92MjUix2mVDJUCyKJ7IsFrweLvr0knB1unU5y k1aZekCtpmPNFUqM3RnI/ue2pJ7zbex+UNJ8DIzPJ83DiNCua6bnrurTmnto1WLRfc+EUyoTnYhS F5M0GTaUKwWMOIyef7x8SwP8otj6hJZotAql2Qo9vUVTXJOUrl2JkxttO1LTp7tqU8xGRGecdOMc i/XaZR9Z11q37uoVDuNUBLNQi1xhxqLIZM0YWTuEpUrBJLBK47MZLChifIRzP8NKtH2rsqqLh0VM y95lyv8AFidG1po9NaNxN5aaVpofpa98XXD1juug3XVY71LolEVMU2xGQ2jKEsKNwjxvLKVqM0mo yI1GXiIfHTbj1Rrun0rU2HcVLgwmWpElmie5yXEONMqWStzpnv3dyrmwR4LmyPk0ohLr+u161N6p Ra5AepKYkidGThh1biWcoRxMtpEhaS4meElz847MbTfUOl2rIsKkXJQjteQl5vrmRGcOay04ajUg kkexWdx5MzLvj5uArHyMESWJOkNarFSmPRl3lspz5kLiWE4ax0o8da/xx1yZewjdTrhrF5T9KqzS 627TI9akpS3GSyS0RZjchtCnjI8crhSiIkqLBcmeO/MX0+5bppevVn2U9W+uoEmi8pP/ANkaR1y+ luRl3gkzRlTaT2pPBYx0heOk0lVEsxm0JkNmZaT5PRkzyUTMgzWhajc5Ms5NSMnjnyfTkunVLHrk /W2277XIpyYdOphxpTRLXyinTS+RmgtuDTl1POojwRi2KdIigSVKJR6MdcdPwXwyLTDMcTrVuCtH ipiwtPTXu7CMve+roiyaq7T79hnMpnLOrpVIoCprKEJUrah+SrvDwkyUZEnb3XQQmb9uK47zc0nr DFaVTPdiVyaWG45Kajy2pKGzkbTP8oWTSZIVwIkc/dGLqj6XXjRafXbUpdfo6bYrLrzrz70d1yek nEkhSC47T7giLcZmecngfH2oLoasmyo0aoUZNetSc7JY5Rbqor5LfJ3CjJBLIyNJFwLp48clllzb NA001i7NDT7OmnSzBNk2uYolEnRrJV5VEsmPorkouw7E+5bppevVn2U9W+uoEmi8pP8A9kaR1y+l uRl3gkzRlTaT2pPBYx0j47Zr+oOpCqxXLVuWn0OlU+e5FhRjgJkHM2JSrLi1HlJGSk8U/pH0ZHfq lj1yfrbbd9rkU5MOnUw40polr5RTppfIzQW3Bpy6nnUR4IxzYNhX5acuqxLErdCbo9VlrlLRUWHO WhKWREZtbO5UeC4ErBdyn5TGvhycFUphUWVYq1ddGWlDbcFownhYThwnkeOlFTTWla/kkbq1huKb oXTLsoslul1j3ZKnzjbYS4gzJlxZ7ScSZERlyavHjmzzjv6p3LqHp6zTbrqFeps6nyZqI0ikNU4k JaJSVLPa6ajWpREgyyeCzg8eIfndWiktej1Msi3Z0I5ceplPlSZe5pLyuTcSoy2JUee6SREfiTzi p19sarX/AGdEo1GkQmJDNQRJUqWtSUGkm3EmRGlKjzlZeLpGTlLLhwqFLBbirVaMVPQxOVbOTjcT eEoYaUenHXs26DQx5Mo1T9ztTtQf/uu7O+UrTv8A+m5XrPDz3/ZOY35+TvPH4vWYzzSyxqtat43v WahIhOx6/UCkxUsLUa0J5R5WFkaSIjw4nmM+Yxq2OdBKgmYWOqWLJXH2G7b7PHPmSlDio3V0Tpi7 cRklQtWt2/oHqBUqvTio6KvPjyI1KSojKIgpSOHDm74ix0ILmFLOqeoVraK0O84NwUxqDApcIipJ 04lk82tLbaTW8at27uiVhJJIubJ4yemawWzPvDTqqW5THYzMuXyPJrkKUlstjyFnk0pM+ZJ+LnHJ uyxqtVtCWbEjSISKk3T4UY3XFrJncypo1HkkmrB8meO56M48WzDa4ZihcymOLHsolp45TUjsMcqK JSq4oMTrT+VW9G3JkPhve9ZvY7b9TiXPTLXjViAiQk3ISps5xxwkGhDTBcDIt/FXHiZcBI21qpeL Lt3UJxp64ajSab17AeepRw3ne6bJXKMEZYIidJREREZpQfjMhR1TTS5WHLKr1v1KlJr9t0punrZn E4qI9hvYpRGkiUXfL44yfc82B/VD05vGHqPVrvkXHTyl1akqjOyYzBkqO/uRtNtpaVJUgktILulZ PJ8CFIHZoYGnR+ddlcnb3CZDbIpiaqtnRTLlpWvZ3nF06vK67kcpsynaj21U5UlaFTaHOgdaLjp/ +YlpacrWouYjMjLx/IPo1W1Scp2oLtnx7oj2pHiRUuyamumKmuKeVtUlpLZFgi2KIzUefHzGQ/Su aYXpdc2mtXTUrXQxT5Lb/ulTYTjVQkbeclK4JRnn7ngRkR44YFHdlj15q/VX5ZE2lR6u9D6zlx6k 0s2JCcpwo1N90SiJKS8fep5hVxWblE3TI+iiejHSnitoUFr5FwquVY3WrWmiwqrH0RbD89CdQXb4 gVePMfjypdKlcl11HZU0iSyo1cm6SFcUmexXc+LBcCGkiZ09t+r0Kny1V6vyazUpslUh5S3Fmyzk zw2yhRnsQXR/6ERUw51ocDmty8n7sOrZFMhkwqa6xfva+IAAGE2AAAAAAAAAAAAAAAA1ywPBGD5F +uoZGNcsDwRg+RfrqHbuL60Wz8kf9pM1h/suDO6AAJQQkCE1b7ym+V37AuxCat95TfK79gaN5ZrG dW5M+l9/BkCAAIUeggAAABjfVLOOTZ1jWs8l0qXWK0hE5SFmkjSS20kgzLpJxR8/OjPi4bIJTVCy Yd824VNflOwpUd0pEKW13zDySMiVjhkuJ5LJf5GRGWxZJkMudDFFk/cfcatulRTpEUEGXjjyd+Q+ KuaS6e1amIgOWxAiIQpKidhspZd4eI1pLJkfMeRytRrnrcK8Lc05tKVHhVGpsrccmyW+XVGZQlWF Ek+ClHya+Ks8U/Lw4q9N9Uq2aaddWpe6kNOpUkoEcm33CTxIzUSUmR56TV08RUagWHUKnWaFc1sV JiFXaGhbcc5iFONPtqSZbHDLuvGfdcT7pXDI2U4YYkpkzCy9LSdMWXtNOJRxQROVKcGSuRNquOlH 0ZMZyrYum56Dqsxp3d9VjVtU6CcuBUG4hR3FGW8zQtCcpLg2vjw70ufIm9Ha3qlqFY06ai8YVPeY nLZRKVSmnXVmTbatmC2oSks85pUZ7j5sELK0rGrzl/Ffl71CmSqw1E60iRqc0so8ZOVZMlL7ozMl K6Mblc4/vQKxqtYFnS6NWZEJ+Q9UFyUqiLWpBJNttJEZqSk85Qfi6BfHMkwwROGmF/HQqVx1pip0 FkuTPjmQqLCUH8tLrTFSrrXpppMR1Ivm4r10HptalT+tDara6bUI8dvYiYrkeUbWZ5yRJLJGnmM1 Z4bSGnX9X70tCv6a0Fdz+6DtUqa2KpJ6wZa66Qb7JJLZg9mEOGnKTIz5+fm4sLQ2uno1Ks6bVKai pFWjqcZxla1Mn+RS2SVmaCUX97mI8cOfiQrb3se67qrWn9ZlyKK1KoEzrmppaW6Ta/yjKjJkjSZn wbPvjLnLj0bEc2z4UMKpgpxaOlYt/wCOhGpLkWtQxRxJ4bUGnoePT0fnpZwrIuDUW770v2hQ7niU +LSqkpiPIdprby46OVeSlKEltJWSQWVLNWNpcDyY5S9Tbya051AZkT2Pd+1ZzEVFRaioInUqk8ka jQZGnJ7F+IiwoscSyL/Syxqtat43vWahIhOx6/UCkxUsLUa0J5R5WFkaSIjw4nmM+YxwKdpFUHka kxKxOhpi3XLKRDXHUta2drzrqDcSaUlkjWjgRnnBlkYuVs+G6pUWDTFsr+TNyNr5OHBbwnhp4324 OzRRnRvW66/TupyYu2HP5KtLplPfVJ5FB5W6pklntNO3jvVwxgs8MCbZvO9Kjf8AYtux7g60brtp IlyHOsmV4lLjvqJ7Bp8S0IVtIySe3HMZj7avp7qXVtLnLIm1u2URo7LMeHyLLxKebaWjbyqzztwl PMlB8SLjjI+6k6aV2JqLY1xuS6acS37fapktCXF8ot1LLyDUgtmDTlxPEzI8EfAUgdnggiq03/Kn hi0dJWNWqZMgookv4Vx9v8sj6MpEdTwxe1Q01umsUm63m5C33yYjuRW3VqmEhhZPKdcJRnuSXJmk yMuOckfEVNU1NqszRKgVWiS203NWpDNOZWbKTIpO/a4raZGkiPafix3RDuaPWbVdNINbp9RqVJct zl1zWJJqUh9vuUko3TURISkkoLiXynwLgULpbb0Gra+Vyo0mWibbVGkuzYi2l72jlSUIJW1RcDIt qvH/AHEjJHHKmzI42k1DjWLL2PvpvMUuCdIlS5SbUUVYWq5MdcJbFXJ2G/09p9iBHZkyFSn22kpd eUlKTcURYNRkkiIjM+PAiL5CHlOjVP3O1O1B/wDuu7O+UrTv/wCm5XrPDz3/AGTmN+fk7zx+L1mM 80ssarWreN71moSITsev1ApMVLC1GtCeUeVhZGkiI8OJ5jPmMadknwyoJjix1SxZNPYb9us0c6OU oMVG8eJ0xdpklQtWt2/oHqBUqvTio6KvPjyI1KSojKIgpSOHDm74ix0ILmFLOqeoVraK0O84NwUx qDApcIipJ04lk82tLbaTW8at27uiVhJJIubJ4yemawWzPvDTqqW5THYzMuXyPJrkKUlstjyFnk0p M+ZJ+LnHJuyxqtVtCWbEjSISKk3T4UY3XFrJncypo1HkkmrB8meO56M48WzDa4ZihcymOLHsolp4 5TVjsMcqKJSq4oMTrT+VW9G3JkPhve9ZvY7b9TiXPTLXjViAiQk3ISps5xxwkGhDTBcDIt/FXHiZ cBxdLtRrmmXLclrVPriuyaZTlToTzlN6wkSDIknya2jPCcm4gk8C4Fkz4j76pppcrDllV636lSk1 +26U3T1szicVEew3sUojSRKLvl8cZPuebA+q0tPropmqtRvSqVinSl1SlqjSVx21NqZeyjbyaFEo jSlLSCypWTPPAWVs6lNYnie2tdlcnb3FzVrc6GKjWNV6KU20y9neRlm3/eVzNlJZ1EtunV03TaVb tSpnIMpUSzL+1ybhngs4LPHgeOcdbU/VKTT77VZ6bniWkiJDQ7NqXucuco31ElRMoRtxjarO4y/5 GWB9F4abX/dVPcoNbrFpzYSlksqu5TFJqKcLyRESMNlw7kzLGSyXyjsVbTut0i6I12WJUqeiqopi KbJaq6HFtykIJBEtS0d3vwhOT452lzcRkw7Nh1dNNFo0Ux025U+0xqXbFLcKroq3Wry1xYWzJEl0 H4aUX5V7+tK54MKdCOvU03GIdQQwptl3elZR3zQpJ7cqSZmkyPgXEvELuxo1xxLWhx7tnxqhWkb+ uZEdJJbXlajTgiQnmRtLvS4l/mONblt3TSLSrSHrmdqFyVEn3mZD61KjRHlJVyaW0K3bW0qMjxg/ JzEOzY0a44lrQ492z41QrSN/XMiOkktrytRpwRITzI2l3pcS/wAxpWhwPC5OlK9+TYsR0bLDMWDy tXFR7MunG8fjpxnbAAGobwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSv VSKwTmxZvBsR5zeueTNpmmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/AHQibXTmcvYAABoHQAAA AAAAAAAAAAAAAAAAAAAAAAAD5qrAi1SmS6ZOa5aJLZWw+3uNO9C0mlRZLBlkjPiRkY+kATpjQaTV Gc22aFSraoceiUWL1rAjbuSa5RS9u5RqPiozM+6UZ8THSABVtxOrylIYVClDCqJAAAUKgAAAAAAA AAAF9pJ3tT8rX2xdiE0k72p+Vr7YuxNbszWD90nn1959M7uCAAA3jlHw3D7wVHzV31DGKDa7h94K j5q76hjFBHL++aDv/BMPZn6UzagAAI+SYAAAAAAAAAAAD4KxRaPWWiaq9JgVFsuZEqMh0i/yURj7 wFU2nVFHColRnz06BCpsRESnw48OOjglphom0J8hEREQ+gAFG65SqSSogAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4vrRbPyR/2kzWH+ y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR6CAAAAAAAAAAAAAAAAA AAAAAAAAB/EhlqQw4w+0h1pxJocbWklJUkywZGR85GXiH4UynU+lxSiUyBFgx08zUdlLaC/ySREP qAKulClFWoAAAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABpulng6950r1Uis EnpZ4OvedK9VIrBObFm8GxHnN655M2maaq+/8fzVPrqEiK7VX3/j+ap9dQkRFb0zqP8AdCJtdOZy 9gAAGgdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+0k72p+Vr7YuxCaSd7U/ K19sXYmt2ZrB+6Tz6+8+md3BAAAbxyj4bh94Kj5q76hjFBtdw+8FR81d9Qxigjl/fNB3/gmHsz9K ZtQAAEfJMAAAAAB8NJoFCuPVuj0+4aLTaxDRQak8mPOiofbS4UiARLJKyMtxEpRZ58KPpF0KTeM1 rZafdpLm0rSm90PuAW/aq0v+LezvoSN7AdqrS/4t7O+hI3sCzlJXS/D1OH8RPq9/oRAC37VWl/xb 2d9CRvYDtVaX/FvZ30JG9gOUldL8PUfET6vf6EQAt+1Vpf8AFvZ30JG9gO1Vpf8AFvZ30JG9gOUl dL8PUfET6vf6EQAt+1Vpf8W9nfQkb2A7VWl/xb2d9CRvYDlJXS/D1HxE+r3+hEALftVaX/FvZ30J G9gO1Vpf8W9nfQkb2A5SV0vw9R8RPq9/oRAC37VWl/xb2d9CRvYDtVaX/FvZ30JG9gOUldL8PUfE T6vf6EQAt+1Vpf8AFvZ30JG9gO1Vpf8AFvZ30JG9gOUldL8PUfET6vf6EQAt+1Vpf8W9nfQkb2A7 VWl/xb2d9CRvYDlJXS/D1HxE+r3+hEALftVaX/FvZ30JG9gO1Vpf8W9nfQkb2A5SV0vw9R8RPq9/ oRAC37VWl/xb2d9CRvYDtVaX/FvZ30JG9gOUldL8PUfET6vf6EQAt+1Vpf8AFvZ30JG9gO1Vpf8A FvZ30JG9gOUldL8PUfET6vf6EQAt+1Vpf8W9nfQkb2A7VWl/xb2d9CRvYDlJXS/D1HxE+r3+hEAL ftVaX/FvZ30JG9gO1Vpf8W9nfQkb2A5SV0vw9R8RPq9/oRAC37VWl/xb2d9CRvYDtVaX/FvZ30JG 9gOUldL8PUfET6vf6EQAt+1Vpf8AFvZ30JG9gQF9WtbFsamW2m27co9FKVRqocgqfCbj8rsegbd+ xJbsblYzzbj6RdA4I3RN+HqZ7NfjnzYZfJ0r2+h9AAAod4AAAANcsDwRg+RfrqGRjXLA8EYPkX66 h27i+tFs/JH/AGkzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR 6CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABpulng6950r1UisEnpZ4OvedK9VIrBObFm8GxHnN655M2maaq+/wDH81T66hIiu1V9/wCP 5qn11CREVvTOo/3QibXTmcvYcupQGavdloUSW9NbhT6s63KTFmOxluITAluknlGlJWRb20HgjLO3 jwF92oLJ/RuT0pqf4gRcf85FhfPT/wDTJw3Ic+dMjgUKhbWL8sj98zI1amk9CIHtQWT+jcnpTU/x AdqCyf0bk9Kan+IGe6jdUNXrc1YrOn1vaVVK7JVLbadW5AmLNxSFtNLNRtIYWaSI3UpzkyzjmzgV uiessLUWqVO3p9u1G1rmpjaXZVKn/wBoSDx3RZSlRkRqTnKS75PSMscm2QS+UbdKVy6H2Vqcj3iK tMJnV7UFk/o3J6U1P8QHagsn9G5PSmp/iBfANT3ibrPxZdyszWZA9qCyf0bk9Kan+IDtQWT+jcnp TU/xAvgD3ibrPxY5WZrMge1BZP6NyelNT/EB2oLJ/RuT0pqf4gUt6VCuUq2Zc+27e7Iqq1s5Cm9e oi8vlaSV+VWRpTtSalcefbjnMfbQ5E6XRIMuqU73NnvRm3JMPlkvdbOqSRrb3p4L2mZluLgeMkLu WnYOFhvx/FalOWj1mRvagsn9G5PSmp/iA7UFk/o3J6U1P8QL4Bb7xN1n4sryszWZA9qCyf0bk9Ka n+IDtQWT+jcnpTU/xAvgD3ibrPxY5WZrMge1BZP6NyelNT/EB2oLJ/RuT0pqf4gXwB7xN1n4scrM 1mQPagsn9G5PSmp/iA7UFk/o3J6U1P8AEC+E+xedtyL9esaPU23q/HhHNkxWyMzYaI2yLefMkz5V BknnweebGboZ0+KtIni7WU5aPWficHtQWT+jcnpTU/xAdqCyf0bk9Kan+IF8At94m6z8WV5WZrMg e1BZP6NyelNT/ECW1SsG3rWtNut0RyvMTWqtTGkqduCe+g0Oz2GnEqbceUhRGhai4kfP0jZxnfVF tOv6VSWWJK4rrlWpKUPoSlSmlHUoxEoiURkZkfHBkZcOJDNInTIpsKcTpVaS+VOmYaxvL0k2Akux i5/jHrX8hB+4DsYuf4x61/IQfuBm5OHXW/yJ5yseo93mVoCS7GLn+MetfyEH7gOxi5/jHrX8hB+4 Dk4ddb/IcrHqPd5laAkuxi5/jHrX8hB+4DsYuf4x61/IQfuA5OHXW/yHKx6j3eZtekne1PytfbF2 MN0ytC7301DrfVa4Im0288nTacrd33Pujn/4Cy7CL3+OW5voql/hRMbuVLNAk6/9kDvlt22NtUyc EaAAz/sIvf45bm+iqX+FDsIvf45bm+iqX+FG6cssrh94Kj5q76hjFBW1yyr2RRZyl6xXK4ko7hmg 6XTCJRbT4HiNkZL2MXP8Y9a/kIP3Aj9+QqJwVdMvT2dCJb7ORuGXHSFvHop+WitASXYxc/xj1r+Q g/cB2MXP8Y9a/kIP3A4PJw663+RI+Vj1Hu8ytASXYxc/xj1r+Qg/cB2MXP8AGPWv5CD9wHJw663+ Q5WPUe7zO9KrNKi1aPSZNQjMTpSDXHYcWSVOkR4PaR98fyFxHSsf89VJ/wCHKn9Zp485a5aZ3zct 0USNAqM6uklhw1y5jTLDUXui4GptCSPPPjBnw4DX+pztmvWtqTSKfX7ok11/scqW03E9ywRSKf3K VH3ai+VR+IsEXEbEdnlwSlHDGm2ni7n+4zh3lap0yTNlxS2oVTH3r9xVPSYxPqcNaV3zpvKue/Jt uUJ5FZXTmNjvWzThE0ysiLlXFGazU6ZcD6OHTtg8cdRTaenVx6PXM/eFMo89+PUXSdXOSlaokc2G j5RBq/ssmS+7Tgz2Fx7khq2aVLikTIo1kcOTLjqRWJuqPYSpDCY3XKnm0sEnfyhqLbt5855sfKOX QrstavS5EOhXLRqrJjHh9mHOaeW1xMu6SlRmnmPn6DHkSxbxKidRO3Ova3FXJAauAotIhvvuIZeb SpLiDeNJnltDiXS2qLaexKccxj/L4oFWsnXDRyW8uyYFRqFXbS9FtakJhttNrdYQolqyZupUlxaU mZFgiVjn4Z1diwooIosdWl20Vf3o7SmGeuOzOz8VM+yuhYpK+TqR+6DX+xryotr3dfkzyhZYVjvV dBjo02q0yp0xFUptRhzYC0b0So76XGlJ6SWkzIy+XI8u9ThaNs3Rrhra5clDgVhMO4lcgzOYS80k 1yZmVbFEaTV3JER4yWTxzmMguaXWaFZeuFuW2So1DjXlHjvMMntRHiqemoPbgywRqZjIMuPDhgXK 7II5jlwxY1g5f/KnmMPFU9Q9UfrSuxtOItz2HNtyuvLrKKc/vd65abI2nlGR8k4kyWRtEXE+nh0a 3HrlEke6HW9Yp73uYo0T9klCutFEWTJ3B9wZFxwrHAeSerWtPTq3NHrZfs+l0iA/IqLRNLgpShUu OTDp8os0/wBrgzR3asmW4+PdGOn1QcqTZOpl60SmxMq1OocSLEUaz2rmk8UZaeBHj8k6peTwWcF4 xVWKVNlQKDE3hZexrgqsYTTdT06q6LZTQ2K6q4qQVJkKJDE45rfW7qjVtIkuZ2qMzLBER8/AT+nd wV6sXRdsGrVuyKhFp03koLFClLdlxUb3S2zUqMyQ7hKSwnBbkudBDzZYtPdcvq1NAJLKpLFn3ZMq 8h01GWYjSOVirVwIjNan1EZFzcPEY59Gm1unU/qpplvbynoqqS3IVhSGjmS0vKI8lg0tG4ZH8nj5 g5uhSihTy0pscVE/yMM9F63apRrS0uuW4rSqdBq1Zopx0uRVvk+lo3JDTZk4htZKLuXDMuJccDlU fqgLMacsqjXJVqfDrleo8eoVBROpZiU7lIvL4cWtXcbjwSUGZqwtBnwMjPHNSLT06p/UQ0yvUumU ePWpFOpx9espSmRIkKcZN9tSy7pePyhmgzMi2Fw7kh8FAt+g1PqidEINSolNmxahp9CdmsSIqHG5 K0wZJJU4lRGS1ETbZEZ5MiQnoIZZdis7kxVricWPI8SRRxOpu1B1Uq8rqmLu03qLVIjUCh0hE5qW aVof3GmKZ8otS9m38uvmSXMnjz51Cg1ujV+AU+hVen1WGozIpEKSh5szI8GW5BmXORjzRRbdoty9 Xpf8Gv02PUoTdCYe62koJbLiiagEW9B9ysi3ZwZGWSI+ciH0aVlSrO6s3UyjU9MGhW0xb7U15hsk MRWTQ3EUbh8yUEnlXT8RFuMa86yS4of4YmoIYux5K9+Mqomenxkd0am16l9VBaul0eJTVUasUlyb IfW2s5KVpTKMiSolkki/II50mfFXHmxqFFqtLrdMaqlFqUOpQHt3JSoj6XmnMKNJ7VpMyPBkZHg+ cjIeeNQP/wAwHTv/AIce/wBOoDVscqGKKNRrJDF4pF0TN4q932lR6kzTatdFEp859RJZjSp7TTrh mZERJSpRGZ5MuYvGQmtTtXbL0+q9Do9dqTaZ9ZkNNstJcSRMMrcJByHlGZE20nJnuPn2qxnarHmm VHgX/pvqNddCtmxrbodLXPQb9Spqp1ZmSNqnVLN91RKZUs1pJPfGlRqIu9ITnW8Wt211Mr9XhxZz kuqyKdKU+whRvxWqk022yvJd22lKlESTyXdK6Tz0JV2S6rDbytNf+rf4LHGz3RIrtEj0NFdkVmnM 0lbSX0TnJKEx1NqLclZOGe00mXEjzgyCPXqHJoa67HrNOepLbSnlzm5SFR0tpTuUs3CPaSSLiZ5w RcR5m6paFXn9e9NbOotLtc6Emnu+5kCttK9ylyEpcSaHGm+ckNpZJBEnBGoi5jMhx7XpFcoC9dKZ LqVmMtHacpdQoltsTERoMnrUybUgnWiaSSkcoaiStR7vERJMi14bvhilqPCxvH3Vp++Bdh4z1Cq+ LKTAhVBV4W+UOes24cg6kzyclRKNO1tW7Cz3JUWCzxIy8Q7j8mOxGVKefaaYSncp1ayJBF0mZ8MD ybpbYdnTuogn3HPtumTKx7h1Z9E6RHS4+ytpcjk+TWojNBEaCPCTIs5PxmJV2o1Op6C6BUusOm9b E+4VRaypxeEqbam7GWl8eKOSJ3gZH/ZkfDHG7m6CKJwwxZInC8XQm8XgUw2eyabdNsVKjSK1Trjo 8ylxkKXImx5rbjDSUkZqUpxJmlJERGZmZ8MGPphVqjzaIVch1aBJpRtqdKa1IQtg0JzuVyhHtwWD yecFgxl1ItbSiga79ZUCS5SLhmUI0yKBTYpNwH4u5X5V0kNbSXnhneR8E8OPHC6jW6nZlj3h1OsJ BnWpdwN02hEZGZKgTVGvcZ85kSSMlGRHg3S58GZYpdihmukDeh41oeV9xVxUPZFFqtLrdMaqlFqU OpQHt3JSoj6XmnMKNJ7VpMyPBkZHg+cjIfYJe112raEWhaeR6zTWJ8eAhuFT3JaCkvNISZGtLZnv UX5NZmZF/dV0GKgaEcKTxZNGwuQAAFpUDJ9X/wA51pfMtW/1qeNYGT6v/nOtL5lq3+tTxns31O58 Gbt3Z1BtOeAAMpPAAAAA1ywPBGD5F+uoZGNcsDwRg+RfrqHbuL60Wz8kf9pM1h/suDO6AAJQQkCE 1b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+l9/BkCAAIUeggAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSv VSKwTmxZvBsR5zeueTNpmmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/AHQibXTmcvYfLH/ORYXz 0/8A0ycNyGGx/wA5FhfPT/8ATJw3Icy0f5dn5ZHL7zt7EeNLqp+pNS6tW/WdLa7TqNWkUiO489NQ lSHI5MQyU2W5twtxrNs+YuY+JeO+6kKkvVC4rvvq7qvJnagOPFTKxHkRG2FwibJJEkiR3KkqJCMK IiLuC4cMjVqPplQaXrBWdUY8upKrNYhJhSGHHEHGShJMkRpSSCUSvyCOdRlxVw5sfvB08osDVOdq JAlVGLUqhDTEnRW3ElFk7cbXFo25NwiIiJRKLgXNxPO9Ot0Ecrk1i/ilWmOqpVN9BxVDR1PHdHev XUqi3fe8+wahVqvGnSkRa87eKaYm3cNJMmyYWpBbWyMjUo8EoskZkZGY0TUa6b3q+l2jluVqeuJ2 VVZun16o06pNPcq2h5DScPMmaD5VKjcM0q4GkyPPEhrVyaCWVWa1PntzbjpEaquqdq1NpdUXHhVF Suc3mi588/cmnJmeciovHTe0LpsyLaVRpSGqZC5M4KYquSXDU2WEKaUXFJkXDyZIxlmXhIiigahx J9uLFTS6ZceKmQooGebdb7AtvT7WPRGm2qmXFp7twpUUFyY4+2yspUTK0copRp354kR4M05xnIre pJMu3XruWePZGX1maOVq9pTOoeqGjsigM3fdBRa8lyq1Wc69PdZaQ/ENHKuY2tIIicMiwku+PpGt VzRO1qlfMu74lWuihTqhj3Sao9XciNTsFguVJPdcP91SeJmZ5yYum2iW7MoI4m8JPHsirj2hJ1PL FYUlVo9VEpJkpJ3FBMjI+Bl7qvjvxqLFuLXnQuiznJCIkrTmGl/kHltLWgoss1I3oMlESiI0ngyP BmNzZ6nSxWLfvWhx51eZhXhIYfnJTIaM45svqeQlkzbPCdyjI9+88EXHPEdqm6M2vAvi0LvZn1hU +06K3RYDa3mzacYQ062SnSJvJrw6rik0lki4eI74ryk0iwW646f7EuKGAzGOqAbn0rUewNGrYtWb VbU9zXXyobNZVBTUjw8XIqkqPOGyRvMjUe7djnNJj4rQTd9DoGsdqVCis0C3UWjLkRKIu6I9UfpT hRdvJ4Ss3UocSo1kakkRElJcc5P0bqVp1bl/MwlVfr6JUKepS6fU6dJOPLiKUWDNtwubxcDIyyRc OA5tA0htWjWlcdBZfq0t+5YrkarVabL5efJSts28qdURlkiUeC24Iz5hrwW+XyKhax6cuWta5abq 6MhXBdTy4zZ9Ma6huDqGiTVU3FTVmqnSEVF5CYZKqamlE22lRILJLWZnjdlR8R09bqb2K6Laeaz0 2o1VV9VB2nrmVR2oPKN5LsVx9TZo3bCRuSXcpIixnPOY9E9pm1+0d2oev6x7hfrHLN9df9Z6577k 9nf8O8735eIX5oza95aX0HTyqT6wzSqH1v1s9GebS+vkGFMo3qU2aTylRmeElxxjBcBlV5S+UrE3 TDb/APV6PQpgOh56rb906la3agRahpxUb1j29ORFp0RN0e5CKWlCnUofQk8copzbvJXHb8pGkT+r tSumodRrb7V3TIs+bBu5MVmYxVWJ/LspivqSanWVrTuLcaMGo1YQRnzj1Ne+jVr3Pcb1xN1G4beq ktCW58ih1FUQ5zaSwSHiIjJRY4ZwR4IuI/G9dDbHubTOlaebJ9IodKlJlR0051CXDWlDicqU4he7 PKqMzxkz45FZd4yE5eKiTXTioqPTTH2JV04w4HjMa6rW04Gl1uUHUe1p1Ybu1NaZjSKm/U5Dq5SD bddUlaVL2kk1NllKSSnBmWMD87PsS1Z/V7XnEl0rlGabGbrsRPXDpcnONUN43ckrJ/lHXD2nlPdY xgiIvQGs2mVB1WteNb1wy6lFix5qZqFwHEIcNaULQRGa0KLGHFeLOSLiPyqGldvSdV4+pcWbV6ZX ENEzKKDJJtme2RERIfTtM1kRJTwyXepznaWMMu8EpODFE8KkSr3qnB7KlXBjPNlWsus23VLjq2st mXbcRplvSIl5UCruG5AYURZUhjlMNoRxV3RGSSyRkaSIx6o0pn0epadUOZQK9Nr9MVFSmPUJrm+Q +STNJ8qranKyMjSrJEeSPPHIi6x1P9mzp89yFV7rolPqbq3alSaXV1sQZqllhXKNYPnLgZEZDSbY odLtm3oNAokRMSnQGUsx2SMz2pLpM+Jn4zM+JmZmYwWy1QTpao3XwXhV07sRWGFpnSEDr9+bdXz1 R/6nFF8IHX7826vnqj/1OKNSz/Wh2riZ5X1IdqJUAAZj0UAAAAAAAL7STvan5Wvti7EJpJ3tT8rX 2xdia3ZmsH7pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf8AgmHsz9KZ tQAAEfJMAAAAH92P+eqk/wDDlT+s08fjyrXLchyiOV279mS3bc4zjoH7WP8AnqpP/DlT+s08XQ6d j4M5l8ZnH3cUbKMua6nzR1qjN0grHiKiNSlSkE5JfWsnDJBH+UUs17TJtPcZ28ObiedREFT7o1Ge 0/qNal6Wda3JHkk3EoPZBHX100Zt5c64ItiMEpw9pln8n/vEMEmKbDXk4qZNNNmleOghDppKKfaN sTrSK0pdBp7tBJpLSYCmS5FKUmRpIk+LBkRkZcSMsiRpmhOk9MiQ49Ps6NG6ynNz2Hm5L5PpfbMz Qo3d+9REajwk1Gn5OBDuMX3SWKzbVsV5TdLu2uxCfKjJeJ9yOZNLccJS0ltNKTbcSS+BKNPDx4+1 i87bkX69Y0eptvV+PCObJitkZmw0RtkW8+ZJnyqDJPPg882M3KK0QJpNpZdPj6lMTPytGxLVtOt1 6tW/Sus59wSeuqo71w65y7u5at2FqMk8XVnhJEXH5Cx8tI00salSLmfh2+xuul03a2l51x5EtRqc UeUOKNKSy6s8JIi4/IWK8Bi5aY23hPH29GTwK0Rlz3U+aOu0ZykKseImI7KKUskSH0LNwiWRflEr Je0icVhGdvHm4FivuqyLVumsUSsV+jtTp1Ckdc011Ti0mw5lJ5wkyJXFCTwojLJFwFEAudomxOri fi9OUUROwbJtaFfU6+ItHaauKfHTGlTSWvc42W3Bbc7S7xHEiIz2lkx+VrWDaNsVa4KrRKOmNLuN /rirLU+46Ulzc4rJpWo0p4uucEkRd1zcCxTgLOVjaphP/rJ4CiMzVoHpAcapxysantt1MklJJtx1 B4StKyJBpURtFuQk8I2keOPOY61b0o0+rUO3olStxp9u3G2m6SfXDqVxkNERITvSolKItqeCjPOM nkxbAL3aZzx4b8WMFE1T7EtWBqBUb+iUrk7kqUYosuZ1w6fKNETZEnYathcGm+JJI+5+U8/BU9Mb Ll1+47lVQUPVq4aY5TKi8uY+hMmOptCDbMiVhBGltBbkJJRYyXHOeV1RGqfaisqHcnuF7tdc1FEH kOu+t9u5t1e/dsXn+zxjHj5+A0kXNzoIVMbdHiWPopi2LEUxZCd02tOn2RZcC2KW0lmJEN1SG0LW pLZuOrdUlJrM1GklLMi3GZ4Isj+KhYlqz9QKdf0ulcpclNjHFiTOuHS5NoycI07CVsPg65xNJn3X yFilE/d1523asyjwq5U240utTW4VOj4NTkh1a0o7lJeIjWnKuYslnnIWQxzI424W6uvfXKVxJHAk aMaWyLucut+yqW5VnFGtbqkqNtSzVuNZtZ5Pfnju27s+Mf5J0Y00k2LFsiTbCHqBDeU/GjLlvqNl alGpRocNfKJyZnkiVjifSNAGbaSap9n1635bfuF7ndiVRKDy/XfK9d/lH0b9uxOz+xzjKu+5+HHL DMtEULiUTpDTTk0LiUoiluyxLRuu3GbeuOhRalTWEklhp7JqawnaRoWR70qxw3EZH8o+eg6b2RQb Nn2fR7ejQqLUWXGJkdpSyU+haNit7md5maTxu3ZLxGKwBhU6YocHCdNpWiJqj2JatI0/XYNOpXIW 25Gfiqh9cOqy08azdTvNRr4m4vjuyWeGMEPxg6c2RDsFqwm7eiu20zu5OBINT6UmpxThnucM1Z3q MyPOSzwwKsA5aZrPLXLp6dvaKIktPdNrH0/ZdbtC3IlLN4sOupNTjqyznCnFmpZlnxGeBmtp2Fd1 19UAxqvfVrQbZRSqb1nAp7dRTMcddysuWUtBEnG1xWCMs97wyQ3cBkhtUyHCdauJUq61/WUwUR1Y sGjVPVWjX+9BaKq0iKthmWT7vKKSpLqeTNvPJ7SJ5at2DUZ4LgRcbEAGGKOKKlXkxFaAAAWlQMn1 f/OdaXzLVv8AWp41gZPq/wDnOtL5lq3+tTxns31O58Gbt3Z1BtOeAAMpPAAAAA1ywPBGD5F+uoZG NcsDwRg+RfrqHbuL60Wz8kf9pM1h/suDO6AAJQQkCE1b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+ l9/BkCAAIUeggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNpmmqvv/AB/NU+uo SIrtVff+P5qn11CREVvTOo/3QibXTmcvYfLH/ORYXz0//TJw3IYbH/ORYXz0/wD0ycNyHMtH+XZ+ WRy+87exAB5q1JqM66NRq9bdCu3U+tVGnukpUC0XWKZEpadiSS2/Ic/tFqVuPO79ItpbRlVy6t39 XOpFp1fduWqQ63EvL3McqEKSqO9IZKI46RLNrbw7tJY8ewjPiNuVdccxQtRLHTurk/fA4zjSPdQD z5r1W7h0T0gqdag3XXK3Xq9UWYrcmpOIdbguqbWpZsNklKW0bW1bU4PBmRnniJawLpv6j6oW2xSa TrVVKBUpKmK8V30jKGFOGlKHmVpL8khJmalEZklKS4ZzwxwWCKOW5kMSpjp20y+gw8dD1YAldW3b sY02rrtjNIduNMU+sUqxndksmklEZGok7jSRlg1ERHzjzhppcry6vQW6xq/qDaV4yXmjqNMuyFys CYpOCW0whSUJaJSjwR7iVg8YzgxjkWRzpbjTybW92jtKuKjoeuQHlnW3Uet1PXioacx16iM0Sj01 D0huyI6VVF6QsmnCWpZ8UspS4lJ4x3R4PJKyXMq196ml1M+ox1xq8qJOo86J7jVepRF0+a/EdmIS kjUnGXEpIyWaeGFkWTyM0N2zHDC21/Km/IUw0euR8M2r0uFU4NLl1CMzOqClohx1uETj5oQpatqe c8JSZmfiwPL99xL5ovU0UbVprVS7jrkSlU2QiMmSgoa0vci3hxs0Gbq8OEZqcUrKsnjiJi4KW/fv VTaazZVxXFSX7qtCPVHX6bP5J6ApUSQZtxl7T5NszbyZYPJuOH/e4Xy7uUScTjxLC0aYVUOM9qgA Dll4AAAAAAAAAAAEDr9+bdXz1R/6nFF8IHX7826vnqj/ANTijNZ/rQ7VxMkr6kO1EqAAMx6KAAAA AAAF9pJ3tT8rX2xdiE0k72p+Vr7YuxNbszWD90nn1959M7uCAAA3jlHw3D7wVHzV31DGKDa7h94K j5q76hjFBHL++aDv/BMPZn6UzagAAI+SYi11C9Kpctdh0SZb8SHTJTcZJTILzzizVHadNRml1Bc7 uMY8Q/frbUr4atL6IkfiB+lneFd7fOzP1CKKkbEceC0klkWhdCNWXLw0228r0vpZ5p18pWpM297b RDcbm1ZDDqo7lEjOxzZLcnJqUpxWOPjykhtfU6Rb6iak0hu/J8CXN7HKlyXW7eFoT1xT8k4osJUf NzF4j4qzwqx/dj/nqpP/AA5U/rNPGWO1uZKUvBWJPHpyPwOReVghlSZs5RN1piriyrxNlHgvT/8A /L+1E/4jZ/1KePcN01b3Ct6dWCplRqhxGjcKHT2OWkPf7raP7yh596nfRmVM6mKp2NfjFTpCbgqf X7jLe1qUwhJsGgjJaVEkzNgjMlJyRKxgjGOwTYZMpxxvFhQbm2yJxKrMshWJatx6+aPUWs0rrqBX rCgSqk11w6jl3W4D6UKylRGnBR2SwkyI9vHnPNjZ9iWrP6va84kulcozTYzddiJ64dLk5xqhvG7k lZP8o64e08p7rGMERFtNV0RtSa/Z0xmo12m1O0obMGBUYMtLUh2O0jaTbqiRhSTI1ZIiTneouBKM h0qhpXb0nVePqXFm1emVxDRMyigySbZntkRESH07TNZESU8Ml3qc52ljPHeUMVUon8rXfWu9YimA eba2/dOpWt2oEWoacVG9Y9vTkRadETdHuQilpQp1KH0JPHKKc27yVx2/KRpE/q7UrpqHUa2+1d0y LPmwbuTFZmMVVify7KYr6kmp1la07i3GjBqNWEEZ849TXvo1a9z3G9cTdRuG3qpLQlufIodRVEOc 2ksEh4iIyUWOGcEeCLiPxvXQ2x7m0zpWnmyfSKHSpSZUdNOdQlw1pQ4nKlOIXuzyqjM8ZM+ORdLv GQnLxUSa6cVFR6aY+xKunGHA8ZUWJY9AsxE5VGZk9c1J1L9QkSJTj7kl4iwbijcUeDPoLBdBEKYZ 3r/pvB1RsqPbs1c5vkpyJTLkV5tvk3CbcQSnN6VbkEThmaUluM8YMuJjRBxpjwko3FVvL+DIjyFo ZYtv35rHrfTblVNfp7dwLNUFma7HbeUcmWRLXyakmrbgyIjPHdnkuYdLSu8HaHpzrJbty124UW5a NSehU+qxpBdek0t11omWXVkZcoRoRgzM8G8Xelgf3pDpTOreqGscivsXdbBSq8pylVWC69AdeaW/ LNfJOY2uoMuTMywpPen0DcqFpXZFG0+nWNGpPKUeokvr8nnVLdlLX3zi3M7jXwLBkZYwWMYIdi12 mXDG4Ym38uLoolVrt0GOGFnkDVCPU7RtO3dX7UtBNnHUKiwqLOcuaXNnzmVNrdbJ9Cj2E2tLaVKL cZ96npGrWpRIWtOt+p0TUIqk5DteazFosEpzzDcYiU+nrhKUGnKj5Mlko89/zmWBZTepnsWfbTlA qNcvGdETtKD11Vzd9zUEojJEdCkm2gsJ25NKj2mZZ4iiu7Re2LhuBVwIq1yUOqvtts1CVRqkcRdR bQWCS+SSwrJcDMiSfNx4BMt8mKGibUWNYWOqxprK65KrLuCgZ5/6p6P1l1KNtwC1Ai36mLczbSKu waT3pKPJMm1KS45uUnOMmrOMZF7oxPq14a31ZzVymu0+7KXHRMt+iurQqLDiucDdaIjPe8RkRKWf Es8Mcyb689C7FuTTOl6eE3Po9DpktMuOmnOpS4bhJcSZqU4le7PKqMzPiZ44+IUV26f0e4rxt+7n JdRp9YoS1dbyITiE8s0rvmXSUlRKbPjw4GWTwZDFFbZUUrk9LwsdMarSmTFjyOhXBdanjmjvXrqV RbvvefYNQq1XjTpSItedvFNMTbuGkmTZMLUgtrZGRqUeCUWSMyMjMdTVmlqu2odT9PvaLGl1euSP cisux6imQiZHalsoQZOsLNGVJecUakHkjcMjPKSx6KuTQSyqzWp89ubcdIjVV1TtWptLqi48KoqV zm80XPnn7k05MzzkdbUPSK0LzoVDpTyJtF7H3Ero8qkOlHfg7duCaVtPaXcI8XOkj5yIxn5zlKOF wqix9OLFSmXpx4ksnSUwHQtKHS4NEokGi0tjreBAjNxYzW9SuTabSSUJyozM8ERFkzM+kePbLuGq 2q51UFeoZOe6MWrfkFtkRqaNUuYg3Czw7glGv/6R7Jhs9bRGY/LOvck2lHKOq3LXgsZUfjM+czEH aGkdqW3Vb2nNnNqKb0kKfqsaeptxnip1RoQlKEmST5ZZYUajwRcennWW0QS4Y8PHWnfSJNl0SbpQ 8+XfYdHtTqZqbrJQqrWI9+Kg06e9WPdN5bslb62SW2slKNKklv5sf3CzniKzWahah35C0+uxNuS7 htl2kNvV21Y9SXBcU861uUalEpJr2mpJEWMkaDLGFHi1idTlYbT7DMmpXVUKDGcS7Gt6ZV1u01lZ GRkaWjLJ8SPgpRke48l0Vuo2mVtXw7T5k5dSpdVpqVJgVSkyjiy4pKLBkhafFjxGRl/zMbbt0Cjh daurxtZE1iWWuLseLQUwWYpYUel1O27+srS2q3hZ93HAQlFtV+Us0U1KTSW+OZ5WjelWN+88cohW MbRKWvTrcsWXbr2o9sX5pxcJymUSbnh1hUiJUn0F3shRqcQSV4NRpJOMErjtyPQtq6L2TQ4dbakt 1Kvyq9HTHqs6tTFSpMptJYJKlnjHi70i5k9BY5FP6nuy2JsBU6r3bWKZTXm3qdR6jWFvQYam+85N vBcC5sGZljJcx4FVbpKcSq6PxeKmWuTsiT8SmCzXh4qumDStRLcvS9LUtidWmaAqa6V2V6530Ppf QSnj61js9wSUJ5M0EZJIyNBHzGPaoyT/AKPtiJrNQlsy7jj0upPKkTKExVXG6a+6o8mtbScGfRtN W3HDGBqWG0QSG3E2nip+cjXl0l0SqecLiqdUvS1+ppk1moyVzplWlRHJiXVcthE+Myle8zzv2oSe 7Oc8RYa5Ux23dTbO0fs+0Z9TtedHk1ORRW645EKrPrJ0loXKcUasIJslmRqPO/GCM0mNbg9T5Z0S DY0NNXuJxqyZ7s6l732crW4+h5SXcNFuTvbLGNp4M+PNiv1K06ty/mYSqv19EqFPUpdPqdOknHlx FKLBm24XN4uBkZZIuHAbsV4SVHDg/KsLuq3R6Mle7QW4DoZH1L6bvoepl1WpUKKzQLdREakRKIu6 I9UfpLhE2nk8JWbqUOJUayNSSIiSkuOcn6MEfprp1b9hNTl0xyoT6jUVpcn1SpyTkTJaklhPKOHz 444IiIuJ8BYDmWydDOmuKHs/cbfEvhVEBk+r/wCc60vmWrf61PGsDJ9X/wA51pfMtW/1qeLbN9Tu fBm/d2dQbTngADKTwAAAANcsDwRg+RfrqGRjXLA8EYPkX66h27i+tFs/JH/aTNYf7LgzugACUEJA hNW+8pvld+wLsQmrfeU3yu/YGjeWaxnVuTPpffwZAgACFHoIAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGm6WeDr3nSvVSKwSelng6950 r1UisE5sWbwbEec3rnkzaZpqr7/x/NU+uoSIrtVff+P5qn11CREVvTOo/wB0Im105nL2Hyx/zkWF 89P/ANMnDchgNRqtLol62RVKzUYdNgMVl7lZUt5LLTe6nTUluWoyIsqMiLJ85kQ03tq6X/GRZ303 G9sc+dLjiULhTeL8sjl9v/8AW9iI2XolOh39XblszUGqWrGuRwna3CjQWHjfWW7umnFkfJHuWtRn hR5WfMJSo9S4y7pbM0+g3ocWnuXMddjOrpnKLZTyCmSYV+VLfhJpPfw70+548Nd7aul/xkWd9Nxv bDtq6X/GRZ303G9sZobTbIaUro0dGTRj7zjUhPr1Osmi6h2XNtWvJd6zlERk4yra40tJ5StJ82SM vGRkfMfAxF2xo7OavOk3PfF9TrxfoBOJobL8FqMiIS8FuXyfF1wiSXdHjiRHjJFip7aul/xkWd9N xvbDtq6X/GRZ303G9sYYHaYIcCFOmzpy7K6aFXRlFcFMTWaJMpa5k6EUlo2+uIUhTD7Wf7yFp4pU XSMdqeg1YuQ6bTL71SrF0W1S5TUmLTZFPYQ6pSCNOHpBZW7kjURmeDMjPjniNA7aul/xkWd9Nxvb Dtq6X/GRZ303G9sJTtEr5E/DhixdwdGcTUPSt+uXmzfVpXZLtG624fWK5rURuW08xuI9rjLnAzLH AyMvFnOCHGn6CUx3R65LFjV+SmpXLMROqlbkxyddffJ9DxqNslJIi7gyJJGWNxnxPObTtq6X/GRZ 303G9sO2rpf8ZFnfTcb2xfDNtUKSSeKlMXRk0aOh4hSE494aWdkPU/saUe7vW3JU6DB90utN+etl NHv5LeXfclzbuG7nPHHgztC3CrWn9xUS73aVXrPpUeknL9z0vImR221NqLklLw2aiW5xyrG/xmRG Vt21dL/jIs76bje2HbV0v+MizvpuN7YQTbVAqJPS8nTiegUhLEBHdtXS/wCMizvpuN7YdtXS/wCM izvpuN7Y1uQm6r8CtUWICO7aul/xkWd9NxvbDtq6X/GRZ303G9sOQm6r8BVFiAju2rpf8ZFnfTcb 2w7aul/xkWd9NxvbDkJuq/AVRYgI7tq6X/GRZ303G9sO2rpf8ZFnfTcb2w5CbqvwFUWIgdfvzbq+ eqP/AFOKPt7aul/xkWd9NxvbEdrHf9iVyym6XRb1tupz3qzSeSixKow86vbUYylbUJUZnhJGZ4Lg RGYyyJMxTYW4XlWgySmuUh2o/EAAXHowAAAAAAAX2kne1PytfbF2ITSTvan5Wvti7E1uzNYP3Sef X3n0zu4IAADeOUfDcPvBUfNXfUMYoNruH3gqPmrvqGMUEcv75oO/8Ew9mfpTNqAAAj5JiWs7wrvb 52Z+oRRUiWs7wrvb52Z+oRRUjLO+buXBGGR8r2viwP7sf89VJ/4cqf1mnj+B/dj/AJ6qT/w5U/rN PFkOnY+DNK+czj7uKNlAB4u0Xcvq7eprvG8Z+qV5sSqA/Nkw0tVDcbi2YjTxJdcWSnFNmeC2EpKe KjweRjs9l5aFxYVKNLxqQdxUPaIDx7VazqDU+pZia2vak3HGrsEkoYhw3G2YTiSmFFNTzRI/KLPB qyozLPMRDr6s6v3FUZ+mtrxOymK3cdus1ur9isdLtTdJ1lZpaj573CkLUoyIjJPEj4GQ2Fdkxuii To2n2NY2Uw0eqwHnvqfbsvcq9dNCr0K+Y1sxYBTKNWLxpZtyGdiUpcQ+4WEuHlW4uOTShRmZeLKr 2u26UWJK1Gs689V6v7nKabVXZTkaHRH1m4ltakQjLctO5ZpIsHhXOZ7RSC7Y4pjgwlox6MeT9yhx 4qntkB5Lvq779rNwW5Vrok33Q9P6vbkOa1Ks3+0alONNuLN5wkGpKSNS07fGRIMi74h0rwume11J 95V629Xp11G1Ki9YVFto4U+AhUlgjZcWhRKNW0zyoySZ7lcMGRE5uj/j/LK0tOl0y5K9gwz1EA8/ 6qXBXofUPQ7hh1upR6yqgUZ1VQalLRJNa1xiWo3CPduVuVk85PJ55xAprN513WbRu2WL6uOmxq1Y MSRPVHnLM3XDjSVOOmlW5CnTJHBakqMjJJ85EKSrvijhcWFSjf8AxVQ46Hr4B5H1EvCtxdWF6RMV bVWdRbdpLapD9sEmRWZj6+ScJ154+PJkl1KTMiLuuGMGWO7a+q+oNt6Hag1m6aJcrUqgPJTQptep ZxnpLMhzkmDcSeErW2oyNe3hhRFkxV3bMwVEmsdKd+QYaN21OvOl6e2PUbvrUeZIgQOS5VuIhKnT 5R1DZbSUpJc6yzky4Z8g6Vq1qLcdr0m4YLbzcWqQmZrCHiInEodQS0koiMyJWFFnBmWfGY8paqW1 dH/RFl3vVtRbhrL9bgU6dUIE5ba4hE88wtKWUbSNo0maOJKweFcOPD0fod+ZWxv+HKf9WbFs+zQS pGEnV4TXgkFE2yxAAGgXgAAAAAAAAAAAAAAAAAAAAAAZPq/+c60vmWrf61PGsDJ9X/znWl8y1b/W p4z2b6nc+DN27s6g2nPAAGUngAAAAa5YHgjB8i/XUMjGuWB4IwfIv11Dt3F9aLZ+SP8AtJmsP9lw Z3QABKCEgQmrfeU3yu/YF2ITVvvKb5XfsDRvLNYzq3Jn0vv4MgQABCj0EAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTdLPB17zpXqpFY JPSzwde86V6qRWCc2LN4NiPOb1zyZtM01V9/4/mqfXUJEV2qvv8Ax/NU+uoSIit6Z1H+6ETa6czl 7AAANA6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF9pJ3tT8rX2xdiE0k72p+ Vr7YuxNbszWD90nn1959M7uCAAA3jlHw3D7wVHzV31DGKDa7h94Kj5q76hjFBHL++aDv/BMPZn6U zagAAI+SYlrO8K72+dmfqEUVIlrO8K72+dmfqEUVIyzvm7lwRhkfK9r4sD+7H/PVSf8Ahyp/WaeP 4HwQK3CtrU+k1qqs1I4HuLUIqnYdNkS9rq34SkJUllCzTkmnDIzIi7kxZAm20uh8DTveFxWONLs4 o3cY7pfoh2E6K3Tpv2T9f+7/AF3/ALf1hyXIcvGQx/Z8ordt2bu+LOccOcUnbesn9K5PRap/hw7b 1k/pXJ6LVP8ADjHBDaZcLhhhdHR5OjIQtyY3/lZN9pD/APDT2meyf/8AyvWH/wDWdc/2PKf/AE9/ 8vyD6q7ouxOtyym6dcsukXPZ1PbhU2txo6FZ2sk0reyszSpKsZ25yWTLdxPPa7b1k/pXJ6LVP8OH besn9K5PRap/hxl5S2VrR5W8ml5dGnoyFOQj1WfFYmkVOoqblnXNVn7qrt0MdbVmoyWEME8zyfJ8 khpHcoRt8RZ8XHgQiU9ThP7BZtgO6o1hy0dqzp1MOnsF1u6pRuEp1wsLeSTpkvYRoLJDQ+29ZP6V yei1T/Dh23rJ/SuT0Wqf4cVhm2yFtpPRo6MlMWKnYOQi1WcE9Jrrp9GoLNrasVqhVCk0hilrUmIm TBfQ0lKSc6zdWaEOGlJFuI8/8zz/AJbugttQLHu63arUZtYlXe8cir1F1tttxbuTWlSEpTtTtcNS 0lg8KM/FwHf7b1k/pXJ6LVP8OHbesn9K5PRap/hxTlLXSlH4d+Wg5CPVZBVTQC46tpi/YFV1bqcu lNIaZpjJ0lhDcVtpaDQlwkmS3jJKDSWVpIskeO5Idmj6Ie52pdgXn2T8r2IW41Q+tesMdd7GXmuV 38p3GeWztwrvcZ45Kk7b1k/pXJ6LVP8ADh23rJ/SuT0Wqf4cXOdbGmqOjr/l6VR6B7vFqs+HUPSt +uXmzfVpXZLtG624fWK5rURuW08xuI9rjLnAzLHAyMvFnOCH7Wfo/bVDsavWxOdk1lVyOvPVudIM kvTHXc7ldzgkYzwIuY+POZmPo7b1k/pXJ6LVP8OHbesn9K5PRap/hxjwrVgqCjouzoyY6VxaByEe qyAq3U9Vyp6cyrBl6s1h+hIS0ilxnqayaYiULQoicNJpW9gkqSRGpKU5I8HtIbJY9D7GbKoVt9dd d+5NOjweX5PZyvJNpRv25PbnbnGTxnnMTXbesn9K5PRap/hw7b1k/pXJ6LVP8OE2K1TYcGKF0rXJ TH3IKRGv8rL4BA9t6yf0rk9Fqn+HDtvWT+lcnotU/wAONf3ebqvwZdyUzVZfAIHtvWT+lcnotU/w 4dt6yf0rk9Fqn+HD3ebqvwY5KZqsvgED23rJ/SuT0Wqf4cO29ZP6Vyei1T/Dh7vN1X4MclM1WXwC B7b1k/pXJ6LVP8OHbesn9K5PRap/hw93m6r8GOSmarL4BA9t6yf0rk9Fqn+HDtvWT+lcnotU/wAO Hu83VfgxyUzVZfAIHtvWT+lcnotU/wAOHbesn9K5PRap/hw93m6r8GOSmarL4BA9t6yf0rk9Fqn+ HDtvWT+lcnotU/w4e7zdV+DHJTNVl8Mn1f8AznWl8y1b/Wp47Xbesn9K5PRap/hxF3dc9Mu3USgS 6IzVlR4NJqLch2XSJURKVuvQjQkjfbQSjMmnDwWe9PIzSJMyGOsULSo9HYzcu+XGrVA2nlPqAAFS cgAAABrlgeCMHyL9dQyMa5YHgjB8i/XUO3cX1otn5I/7SZrD/ZcGd0AASghIEJq33lN8rv2BdiE1 b7ym+V37A0byzWM6tyZ9L7+DIEAAQo9BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3k BIeYfubvUinxP9r/AJehgwDT78vyhWkqNBlSESa5P7imUlpZdczXDPaRJT4k5Pis+5IsmfMIg+2f Ub2TTabecePNhNplVhB05t2mxicI+SiNl3Lrjh9+azcLCSI8FuIicw/c3epX4n+1/wAvQ44DUdMb hqFx2yuTV48dmpQ50mnyyjGrkVusPKbNaN3Ekq25Ij4lnHHAjrm1ypFFuyo0hu17iq1PpTpR6hVK cwl1ph7BGpGzcS1bSMtxpI8HkvELY7khgVYptF2r1Kw+0kUbpDJr3+hPgNgs66bevCiN1m2atGqc FwzTyjKs7VFzpUk+KVF40mRGOyLuYfubvUt+J/tf8vQwYBukuTHiMKkS5DUdlHFTjqySkvKZ8BIS tWdL4ssokjUO1m3jPG06qzw8vdcA5g+5u9R8T/a/5ehnQDbqTU6bV4SJ1JqESfFX3r8Z5LravIpJ mRj6w5h+5u9R8T/a/wCXoYMA3kYMOfb7B7ng/wAq1ropkp2nWuu9Pf8AC/jg4NNNctexdAAAHOOq AAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNpmmqvv/H81T66hIiu1V9/ 4/mqfXUJERW9M6j/AHQibXTmcvYAABoHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpndwQAAG8co+G4feCo+au+oYxQbXcPv BUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTEtZ3hXe3zsz9QiipEtZ3hXe3zsz9QiipGWd83cuCMM j5XtfFgAAYjMAAAAAAAAAAAAAAAAAAAAAAcHUWVIg6fXHNhvLYkx6VKdZdQeFIWlpRpUR9JGRGO1 HM1R21K4maCMz/yE/qn+bG6vmWZ/orHfif8AVWv+4X/kMjX+Gtr/AAYk3yrXYuLP1AAGMygAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAa5YHgjB8i/XUMjGuWB4IwfIv11Dt3F9aLZ+SP+0maw/2XBnd AAEoISBCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gyBAAEKPQQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA3kcm8a6xbNszq5IZdfTFbyhhrv3nDMkobT8qlGlJfKY6wi9YkKctmnttq /KKrlNNCMd/tltKMv3Umf+Q9DPKTHrVXXXtSmLqqlue710Oyp65EWmKQbcHkcRYzSnXMcm2STkKy ffKNRkR8CLVqE61YFoVq5b2lxob02ovVCabS1PEg3FJQyyg9pG4okJbQREWTMuBDrofotr0CZUY8 Am0vPm843Gby7LkOKIiIi/vLUoyIs/8AgRcOCza9x3JWIVau+cw01EcN+HR4qCNmI4aTSTinDLc6 6lJmRK7lKTMzSWcGK0L6ERplf9XtG00quixatTadJqMqS/UFyWVrZVJkrW2p5gj5RtJm4lJmeTSf ORFzZxZ8uoRtLqZUG3VonVBLtQku86lOvOKWpR9Pff8AgNk1Vm0V2oR7DdejUulMtM1a46jJcS02 xCQ7lDRKVzrddb2/IkleMyGJWzVIZ6JlLhvtzUUhuRHNbeTS5yKlEky4cykkk/IYjftKm5MtLGsJ cGdq43Cpsb04P5R+9t3BOt5/toWwyaJMV7kLspLBYbnspwankp5idSgyWk+cyyR58dZqF1SEup7o mmzUeJAMjJVwVRlRkrzeOeDX/wB5eE/IYgNCSbpFBuas1eShulmttT8l7ghxxKDN5Xkyok4+THiG VwkoS0pMdDqIpOuHFQ4XdIZNZm2Rl4jJOOHiGCxW+ZIhmSFjULVHtVadxKLi9m7PfNqUU6qWC20t LToqvRXG+2mIp69XI1allMuVyp3fOI8k9WZSjZQf+5HRtbSXyYMfPT7hJyWqBSLUo8hxsu6jQqCh 80F8pJbMy/zHz2jQ1XVeVHtduciCVRkbH5JrSk2GUpNTqyzw3bUmRfKZD0dT41aq9NqFp6MRGrWt +3TUhcoi2v1GWjjye7nwZlxWo+OePA8DelxTZsOHHE8eRLKyRXnzbdc/3Ox2eXWFJxxzMcMKeJLp bf7pphdpXc7blfXWLOSVvVuOolSac0lTMOcRcTafjngkGouBLIiMjx/l7ksq4YN2WlS7kppmcWox kPoI+dGS4pP5Unkj+UjHk7XibWa/TajVLspNOp1wUCp06K11oRGompLazW2tZd/zIVjOEmXDxjX+ o2k50baiuPpPZU5pMNmoskjlTPgXRuNQ37LMbbhbqsqrly0xkH9orJKcmG0wy4YI64MShdYXWFRw uHueM2oYMN5GDDlX9/p9/wCDH7Mf6v8A6/kAACPErAAAAAAAAAAANN0s8HXvOleqkVgk9LPB17zp XqpFYJzYs3g2I85vXPJm0zTVX3/j+ap9dQkRXaq+/wDH81T66hIiK3pnUf7oRNrpzOXsAAA0DoAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX2kne1PytfbF2ITSTvan5Wvti7E1uz NYP3SefX3n0zu4IAADeOUfDcPvBUfNXfUMYoNruH3gqPmrvqGMUEcv75oO/8Ew9mfpTNqAAAj5Ji Ws7wrvb52Z+oRRUiWs7wrvb52Z+oRRUjLO+buXBGGR8r2viwAAMRmAAAAAAAAAAAAAAAAAAAAAAJ vVP82N1fMsz/AEVjvxP+qtf9wv8AyGZdUPfMW1rVl0aZS5zxVynSYrElrbyaHFINOFZMjLviPm5s 45hQaTXzFvyhvVGDS50KLHcJglydv5VRJyrbtM+BZL/n8g2nIme7qZTFXyNKG0ynanKr/KixeJZA ADVN0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4vrRbPyR/ 2kzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR6CAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAG8iJ1YeajFa0iStLcVNfZQ64o8JSa2nm2zM/F+UW2XlMhbD n3HSIFeoM2jVOIxLiS2VNOsvo3IUR82S+Q8HnnIyyQ9DPKUcmi8m4lpElojWwvclKy4oWRGWfLxM dKt1RFKp6pZxJctRF3DMZvctZ9HHCUl8qjIvlHn1nUg9HrUplOvq3bzeqLbRRnZTxFJZkPISZmbT xrwaVEW4iPBkXAy4DOdQ+qbvG56fIg2jR023BNBm5OkOE9IJJFk9pEWxB/L3R+QUmzYIMbZ0LJYL RbHgyYHFsWLxyEr1RFTrtyaqS26jAeentuLQ9TaeZy0Nk0lBx0mSCyrah1SjMyLu1LLmIhxdPLql 28xV4i4TFRpssv8Aa4ct1bBsvpLBmruckRp4KSfPgh6D0jpp6faQwqlCjtSrlrEdNSnypJmpchxw t5IWvvsERkXyHk8HxGc68Uq37wvK1rpjNuMRa9Rjly2UntKQtpaSSTmOc07zSfTtIce2KVaMJRZF /wB/uMkN12h2WTDJnSlFDE21TE65MuPFoeLI8RndUuysXjIi0tk4Mems93GZS0bEBkiMy3IT3zxk ZHx5iPoFlTKPphHp5R3CuHUi63yNMakwHVsMGvx7uRLuUJyRmalGYsNH5VoGin6cXnbMGewua+qg SnoyXEJNwzdUwrJZQoj3YxwUWOYyGl3tHjtvHa9CZTRKTTaU5U609TW0sOlEIzJuK0pJfkzdWhWV FxJLZ44mRlfZJUuFpSlieQpbr1me6uQ1gUeOjaXZiyvbFFF3LEeUbq041ItZLl51rTKhIoscyXKg skh5DDeeZZEtTif+9k8c5jgnXaa7VOuaLbsi3nUcSKmVBxtxHy4ykxU22t5rUmmtUepQmYtdq71B qFDjOrU86wZJQ666lWSJJ71bMnnuM+IzGrdVrXbPQqDYsekwnrhJhLh1IoxrdprCU5LaaDJSlmks 7cmRJ44PJDetEqNTOSrj7KnIum8ZciHlYoU4HlUShfhVOn7jMRl165KnHfjpuOVUTelNzZEWqHl1 x1tCkNqNwy3HglHz5Lm6BsHU70236xe9mMW5CSxV6dKXNqy1NbZDaENKJanFccpcccQSSI8GXkPG KVm2KxbF3waTUqzDrUObTkVKHLiqVjkl52KLcRKQrJHwF5pJclRs7Uu36zCdWfKzGafOQngUiO8t KDSovkM0rLoNI5bVLRBDHF24u/L04ycWmwwXrc022WSHBwK1TyOiVWlV0ahSSo2qKiSP+ggwYbyM GGG/v9Pv/BGfZj/V/wDX8gAAR4lYAAAAAAAAAABpulng6950r1UisEnpZ4OvedK9VIrBObFm8GxH nN655M2maaq+/wDH81T66hIiu1V9/wCP5qn11CREVvTOo/3QibXTmcvYAABoHQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpn dwQAAG8co+G4feCo+au+oYxQbXcPvBUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTEtZ3hXe3zsz9Q iipEtZ3hXe3zsz9QiipGWd83cuCMMj5XtfFgAAYjMAAAAAAAAAAAAAAAAAAAAHPXJmT6kqj0BlEm cnHXDzhHyEIjLO50y51Y4k2R7lcO9TlRZZMmOfGoJaq2YbTaZVmluZNdEiT1wt6Nd9mO202yuTWZ B8rS2GkkbhvI8fHBJRgzSpajIiJXPnA62mNMpdEsuBQ6WaiTARyMhDiDQ6l/nc5RJ8UqNRmeD6Sx wwNItW2oVAbdcQtcuoSMHKnPEXKvGWcFw4JQWTwhOCLj4zMz+W7LVbqj5VSmvJp1abRtTIJG5DyC yZNvJ4b09HMpOT2mWTI5PHcUfuqlqP8AknWmghMv2ple/Oa5f8GqV07fQ44D4IM9xUxyl1KKcCqs p3OxlK3EpOcco2rBco2f6Rc3MokqyRfeItMlxyonBGqNE4kzpc6BTJbqmAABYZAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4vrRbPyR/2kzWH+y4M7oAAlBCQITVvv Kb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR6CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAG8j8pcmNEZN6VIajtEeDW6skpz5TH5VefGpVJmVSavk4sNhch5f6KEJNSj/5EY/5vXFK1 B6ou/JlWdmHFpCHjTFbkOqKNEbz3KEpLvl4wZmRZM+cy4CfzZ0EmBxzHRI8tlSo5sSggVWz2P1Xt vFceiUyoRUJkO0V5uqN7e63NoyTuPk5Jaz/yHiZRHIpEuIjipTS0Jx8pGRD0PoHQ7p0wnR7VuS42 K9Z9fc9zXIRoX/sjrqTJCkbuZKj7hRFw7sjxwGF3DQZNo3hVrZkbjdpMxcQ1GXFbZcWl/wD1Nmkx ybROlWqWp8l1SdD0f2HnR2efMsE9UwlXxxP8PuZ6OrUiPV9EKFU2mZMmPJpEdCG4e7lVO8mSSQjZ x3byx5S4j4bh0tuVvSyyGoDCJ1dt6MpqZF5VKVPIeIjcSlauBqSsknxMiPB8eYZjpjqlcOm8KRFi RWaxQzUp/rB1w23GFHxVyKyI8EfE9pljPNjJj11QapCrdEg1mnOpehzWESGVl40qIjIWwuGJNw40 zlXpd9qu+bDJtENHD8r6VXL6ZVpPKlbkVfSSO9qJcVqspqq0Jp9vxJbqXDaeVuU5JWSDMkkSe5Ii PceT5iGm6bX3Fr1mndFXjP1iBctHZptb9y20rkwpjXKkr8iR7jQpKzMtpGZbSPGD4SXV9OyisyiM Nkk2HJZmrgWckkz4ePozgeSrJrK6FdlHqhrVyMOoMSloz3J7FkeTLyZ/5jfssNIKw4qEdt8X+JSJ 1wlV+J68sKyKdb99StUJtAqyokZKmqU2dKcTOnyFpMjdVHSauTSREaSUZJyajMyLBCBpFKu6LdUq 89QqVcyEIekVNmKujuKaTKcJJbDWkjwnCG07j4JQk+Y+A9a02ptqWeHUrbURLbWR8FIPilRdJGRk Y/qqzkpRltw0n0pPiLXeceHFNiScTMyuRYMMmFtQ8fQ8v0fSu/76jsXRbMGmVCiLjNQqdIdqKW1q ZYLk9xo2mady0rXjnLcXAXVkaMRrJrcC7dWbut6lRKY6UxintSMk643xSpbjhJ3EkyI9qUnkyLj4 hS0+4p9lahFGtulxXk3RCSt5h6QUeIxOJ8mW5C8EZkbpK2mSE5WbeeGDMv5sDTI7yuCFeN5VWj3H 7lS5Dj7zcF4jnTkqwg97xEXW7RZJCGy2GZZ4nkZJUmVG1OSxszz78vOTZ3dvKUlqqoklXpx0rvNb sLUm2b0qMqnUk6ixMjspkkxPgOxVvMKPCXmycIjU2ZljJf54GbjrWChdS6oWty2lqcYoNCKA+szz +WlPJeJBf91DKTP/APuEOSOT7QKjl9/4Nv2Y/wBX/wBfyAABHSVAAAAAAAAAAAGm6WeDr3nSvVSK wSelng6950r1UisE5sWbwbEec3rnkzaZpqr7/wAfzVPrqEiK7VX3/j+ap9dQkRFb0zqP90Im105n L2AAAaB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT 8rX2xdia3ZmsH7pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf+CYezP0 pm1AAAR8kxLWd4V3t87M/UIoqRLWd4V3t87M/UIoqRlnfN3LgjDI+V7XxYAAGIzAAAAAAAAAAAAA AAAH4zpUaDEdlzHkMMNJ3LcWeCSQUi3ZtzmmVW2XoNEPi3T1pNL0wul8udCD/wALnP8Av4LKBuWK wzbZHgwLFpehHOvK9JF3y8OY8ehaX+9J81NZqF1uqapDy4dISo0v1RJEancc6I5GWFH4jcPKS5i3 Hnbf0SlQKLTm6fTYyY8dvJkRGZmpRnk1KUfFSjPiajMzM+Jj62m22WkMstpbbbSSUIQnBJIuBERe If0JzYrDKscGDAsel6WeYXlek+8JmFMeLQtC/ekAADdOacq5qBT6/CSxNS4260rlI8llW16Ov9NC scD8RkeSMskZGWSEO65UKJPbpdwpRudVsiVBtO1mWfiSZf8Ay3f9w+B86TPBknTR89TgQ6nAegVC K1KivJ2utOJ3JUXkHPt93SrZDSLE9DOtdV8T7ujrDjheVfuRkUA+Kr0+faO5x9x6oUAuJSlZW/BL od8a2y/xOdJd/kiNY+ttaHEJcbUlaFFlKknkjLpIQe12ObZY8CYvU9PsF4SLdL5SU9q0raf0AANU 3QAAAAAAAAAAAAAAAAAAAAAAAAAA1ywPBGD5F+uoZGNcsDwRg+RfrqHbuL60Wz8kf9pM1h/suDO6 AAJQQkCE1b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+l9/BkCAAIUeggAAABxm7khvG71pTbkmttP OMKeh29OkNGttZoWSXG2TSrapKkngz4kZDsiq0B/Nun56rH9TlCtYYYHE1+4zl3rbplkhhctLH0/ 9oz73eR+z94+ilS+4D3eR+z94+ilS+4G/gMfLQar8fQ4vP8AaeiHwfmYB7vI/Z+8fRSpfcB7vI/Z +8fRSpfcDfwDloNV+PoOf7T0Q+D8zAPd5H7P3j6KVL7gPd5H7P3j6KVL7gb+ActBqvx9Bz/aeiHw fmYB7vI/Z+8fRSpfcB7vI/Z+8fRSpfcDfwDloNV+PoOf7T0Q+D8zAPd5H7P3j6KVL7gPd5H7P3j6 KVL7gb+ActBqvx9Bz/aeiHwfmYB7vI/Z+8fRSpfcB7vI/Z+8fRSpfcDfwDloNV+PoOf7T0Q+D8zA Pd5H7P3j6KVL7gPd5H7P3j6KVL7gb+ActBqvx9Bz/aeiHwfmYB7vI/Z+8fRSpfcB7vI/Z+8fRSpf cDfwDloNV+PoOf7T0Q+D8zAPd5H7P3j6KVL7gPd5H7P3j6KVL7gb+ActBqvx9Bz/AGnoh8H5nP1N pkitacXLSIpGqRNpMqO0RFnK1tKSRf8AMyH/ADfq1x1SLJi2TYT7jLbjbaeVaPa53SSM0mr+6ZZP cfPnPQP+oI8e9UTpJb1hXbP1Ep5qZi1dSjKMwncuPKIlOL2tlxU0siMzx3hkZ96fCdWyWoocNrCw ci7enuODZZjUWCnSuns9TN4elU22Y1Kudy75dSuMprD0KnoI+TkvoWS9hqNWdpEkzUsyIiIjMcev 3FWL4uqdeVffbOfNM2VsMIImWktqNKEJ4ZPaRYyeTPPH5OZZNaqdQjVC4Z8px2oTVnGaUZ8GGCwZ oQX90jPBcPEkfgzRuv5ynKc/PhtuyjY/2QlOuy3+dTbDJYIzIuKlmZJIbPMlpV3KZOmrCidcaoqd Cou+rOxcPtHYbvvblYpDihSoqPGn0430VVO0+595LBttIbW9IeVsYjtp3OPK8SUp8f8A/wAG7dSv XqrQKq9pbXHGpO2MqpU9xlW5MYjUXLRjPxklSiMjLpV/lnMWg3LaFGfqUWxZkfLJ8vUJE9mRNS3/ AHspI8pLxmlH/iJmh3yqyNRKBdjbK53I8p10yg+6ciuERLMvl5jL5SCxXbZYrDNmy5yjiVMjxLGb ftN7VWu9bdJgcly5arRNY3XK92RGuaoX4dM6o9qZUGik0KgsJp0qMpBLI25DZKfcJJlxURLQfkbx 4x531I0iuy2ry9zIdNcqMCoGp+jzIxkpqYxzpUhXNnaZZLxeTiPROp1lP6gVDtj6ZORbjg1Rhvry Ky+hDzbqE7SURKwWTSREpBmRkafH4vgtS1b7pdpe4epVxUuy7DKSh1piovsrmtrJW40xl5PkMmXO R5LjtIsmNaTNcMLgfd/0a14WaxR2eTOkxfzxqOHTldGnSmQhNJddZNkQSsu/qbNks01RsRpUZSTk xEkeDaURnhxBeLiRlzFksY0qpdUHpsiGTkWp1iqPqwSIbMA2lqM/7prWe0vKWRGatR+p1erap1Jk Vm4aqZFvi0x5a23lF/ecfc6fGZGZjMXG6ciqSK29TKfTlOKImIzJYZipIsERGffL4cVeMxqTlJf8 o4XXidC57HbbTFgSZiUtZYmq4K2tUr2LcsZ6A6mvUCrV/Xx5+74yIUasRetqTARtW1FcZJS2yMzL du2G9hWeJqVw4lj2BtRyZNIJKUERJIiLBEXQQ8KdT9QalI1NpFwVQ2aRBpJ+6CfdJ4oa5KDQ4lK2 kOYNbe7nXzFgekaJqcVcOYxRIVVq8lUtbUFMKA6lqS2WCJ7rhaSaS1u3FvyfBPAjyQ6Nlw3LWGqH GvuVYpNsihscbjgxY3jx6caon3HzaKqrliSZFKvqjIhTrprsqSipNzUPIdkOZU0wsi4oPkmsJ509 xjJGZEPhFU3aF31+uUZ66E0aDT6XPbqW2FLckPPutkrk2zNTaEpQSlEozLJnsIiwRmJUcS//APT7 /wAHR9mf9X/1/IAAEdJUAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNp mmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/AHQibXTmcvYAABoHQAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpndwQAAG8co +G4feCo+au+oYxQbXcPvBUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTEtZ3hXe3zsz9QiipEtZ3hX e3zsz9QiipGWd83cuCMMj5XtfFgAAYjMAAAAAAAAAETc2q1g21XJFErde61nxtvKtdZvr27kkouK UGR9yoj4H4xfLlxzHSBNvsMc2dLlLCmRJLtdC2Hx1SoMwEtJUh1+Q+vk40ZlO519eM7UF/4mZ4Ii IzMyIjMuHb16Um70kxY8hquTFlkySSm24yf03jUnKE9BY3KxwI8HjRbUtePRVLnSXjn1d5G1+atG DJPPybaePJtkf90j44yo1HxHWu+55tpirMWDCvHuODe/tDJscODKaijfgu1+RzbatN5ctmtXNyb0 1s98WEg9zEI/EouH5R3/AHz5uZJFxNVkACaSZMuRAoJaokebWm0zbTMcybFVsAAn7CvS2b6o71Xt Wpe6EJmQqM47yDjW1wkpUZYcSk+ZaTzjHH/lkqYaPKUAAAqUAAAAGXDBkIKuWtLobi6ha8c3oJma pFISZFt6Vx88En0tmZJPnLaed16AwWizS7RBgTFVG1Y7ZOscxTZLo/3KZzTZ0WoxSkw3ScbMzSfA yUhRHhSVJMspUR8DSeDIywY+kfxcbFCqV5S4NtVunxryYjlImQSXlL7RbCLrhKeKTwtBJX3xEaeC kltHyU2oFJdehyI7sKoxsdcw3sb285woscFIPB4WnJHg/GRkUIvC65lkdVjh6fM9Nui+5N4Q4L/j H0flH3AADlnbAy6oVWoWDqin3XqUuRatyL2sOSpCnE0+WWT2Eau9bV4iLgXQRJGojNeqcbbXonXV LQlSm1RlIMy70+uGyyX+RmX+Y2bJSKYpbyRYvHT3GpbqwyXNhyw4/DR3o/PTyoVW+r2n3iU6bHte EaoVIitvqQ3LURmTj60FwUXiTuz/AJGkYrpoVWuqhP1Csa8zbakNylMpiy6mretJJQonC3PoPBmo y5v7p8ej0lpO221pfayW0JQk6PFUZEWOJtJMz/zMzMeSdNKtpPAoT7N92xVqrUjlKU09EdUlCWdq SJJ4eRx3Es+bxlx6OrZP5crgrJRKiTdMfTvOHbv4ci44l/LCbq2lV06MeLQehYTlYsfROuVmn3c5 fMpJuSok9a+VSlPcNmRGbiyUlBpWs8K6SxkQVtsag1SjR7stPVfsiry22XZFAW6gko3Gncg0rc2J xg8ntTnCsHkV9Cu1K9FX5+j1trOPSZi4/udUmlPLWg/yjmwkumpR5dI+Kj5lERcwzG96nZd1tnGs 3Tuv0u9UvNqQqMxyKWF70mZmlCujODNJYPjksClngicUSa0420sn/ktC2FbVMgUMDUWJQ4knEsfT C8dXtR6rprsh+nRnpkU4slxlCnmDUSjaWZZUnKTMjweSyRmXAfQPioLc9qhwG6o4hyeiM2mUtBdy p0klvMvk3ZH2jhxZSSw5EAABQqAAAAGuWB4IwfIv11DIxrlgeCMHyL9dQ7dxfWi2fkj/ALSZrD/Z cGd0AASghIEJq33lN8rv2BdiE1b7ym+V37A0byzWM6tyZ9L7+DIEAAQo9BAAAACq0B/Nun56rH9T lCVFVoD+bdPz1WP6nKFJn0ntX5I97QfTg2srbmrEK3rdqVeqTnJw6dFclPqwZ4QhJqPgXEzwXMQ8 5dTzqxqRUtRqXT9R5CPcq8qc9OtxBR20cibbiz5PchBGeW0meVmfDZ41YFF1aNYqsmzKVptbLDku v3fMJhlhtwkKUy0ZLcyo8JIjPYR7jIsGrxEYx7UprqgolCtq4K/plQKLTbCdalxJFMktk4yy3tSb ZkUlwzbMkp3ESeZPHhkb9issEUj+dKx1pVqqpkptfAiUUWM9WXVqfYdq3XHte4rij0yqyIaprbT7 ThINlJOGazd28mn+yc4GojPGCLiWf2sDUWyb+RJVaNxRKqcU8PobJSFt8TIjNCyJWDMjwrGD8Rjz jqNc9rz+rA0uu6oPMe4Eq1m5pPPp7htKymqbWvPeklRpMzPG3GTxgUdNnQbp6t6BXbBqEGfSIdtq RXpkFROMuqUbxJQbiSNJq3HHPnLg2fHgZDFFYIFLTxp4OFXRVN4sn5K4WM0Vnqg9HHaO3Vk3xDTF cknFRvjvocNwiSZ/k1IJe0iWnu8beJ8eB40ek1GBVqZHqdLmMTIUlsnWH2VktDiD5jIy5yHkPqKL r07t7R+5Y14VOj09+TUnTdTOWhCpcfkGi5NG7+0wZr7lOTLeXDuiGndQpArkHQSMdYJaWZNQffpq FpNJpjKJOOBkXA3CdUR8ckojz0UtthgkqPBqsFpY9NejEsghibNZvi8rXsike6111uLSoZmaULeM zU4oiM9qEkRqWrBHwSRmPj091GsnUCM6/aFwxaoTPF1tJKbdbIzMiNTayJZEZkeDMsGMe1+fYo3V O6W3HdbrDNosMymeXkI/Ix5Zocwpaz7ksmbBlnGNhn4uHyUyfBurq34FcsGfCn0iFbim6/MgqJxl 1SuWJKTcSRpUrccc+f8A+Wf6JkLYbFA5OFjrguKujE6UyZe/uK4WM1G2dcNLLll06HRLsZlyalLV DiMlEfQ446lJKMtqkEaU4UXdHhPizkjIXlWqMCk0yTU6nMYhworZuvvvLJKG0FzmZnzEPOX/ALO6 OwWjtbkk0jll3A4ha8cTSmPHNJf5GpRl5THf6uyDW5ugkk6OS1MR6gw/UkISZmqMkl54ER8CcNpR nwwSTPIpNsktWz3eFtKtKv8A6QUTwalO91QWjrVGcq53xEVEalFFWaIz61k4ZLMvyaUGvaZNqwvG 3hz8Sz39QdUbAsBxDN3XPDpshaCcTHMluvGgzMiVybZKXtyRlnGOB9BjzV1a12adXHo/bLFn1OkT 349RaNpEFSVKiRzYdLk1kn+zyZI7hWDPYfDuTFtqPeklvqkJ1nv3PS9NqUmkNS5FeVGjpl1XHBLR PvZIkka1YIyM8tLIucZlYIHDDFRquFVN48VOzt6CmGzT52tWl8Oy2Lydu6Kuhvykw0yWWXXTS+pB uE2ttCDWhW1JnhSSx4+ch+0LWPS+Zcki3o97UhVRjEo3EG6aUdyRmokuGWxRkSTMySozLA8DXi6g 7P1Eaj1OVUYR3vBfiyZCu7koW1UzS+ZERFlxOxRmRER5LxYHpjqtadALVzQmAUNgoqq4cc2iQW02 ikQiJGOjBnw+UxnmXZJgjhgq/wCVejQk+juKKNs2mxNVdPb5qkql2rdEOpTYu7lGEpWhRkkyI1JJ aS3pyZd0nJcS4j5rn1j0xtm5U23Xbyp0KqGe1bKtyiaPBHhxaSNLZ4Mu/MhlV9GbPV/2Alk+TJ62 3SdJHDeRIn43Y5+9Tz9BdAxm0G6xSrG1Iot36wQ7TlFUJfuzQnaJFkyqopTadzjKnVtrUa+JJJOC LgojTuyMUu7pUdIqujSdNONtaE8lOjToKuNo96sutPsoeZcQ604klIWhRGlSTLJGRlzkY/sQfU+U 2TSNGLXp0mTUZKmoX5Nc+GmLIJo1KNpK2krWSDSg0pxuM8EWcHkivByZkKgjcKdaMvR0R5B6rK8W 51VdKlS0vks002I4WTQSCMzeUk/GlThERmXBXWxp4lkbR1Rd3rolEYoUd9yMdQYfkz5DSsONQmSS bpIPxLWa0tkfiJSjLiRDyJqaUhy24FWdbbQbUlC5CGk4QwhSDbSlJeJCC2pLoIh6I50p2iCRHkbV fEy2WxzYpEy0Qf5E2tv7wOBEbbiMJaayZJMzNR86lHxMz+Uz4j+KRcNRtOsRaiwxyzcRyQbJ8cEh /BrSZkRmlRKLJHgyMjMjwOQmeaS2r4GXPkfqioIMyJOT8hCdWyRZrZI5CP5aUp2EVs86bZpqnQPG sZV3Dq5Va9TnqdBpj6Hnkmg3EubzSRlgzLCSIjx4zPhz4EU3S50OWVQeZRP3IJLjDZ7TaIuBEjPf EReLh0jpNzSUZEasH8o+pt4lF3J5HOsfs1d9nkRSZaxRdDfqdSL2jt/vUFqwv5QZKpU8KUORFeos aQqREqU+hSFf2hNvORVH5cYIx+bkWHU5aXXXH3oyFblSpzynHJBl/dRu4knhxPx4H+XQ4S50JqW+ pin7k8o5ye9KFGsiNSixx2pyZF4zIa1SEabv8nQ7Qthq7qq8jBJbYObLe5iNSlGW1tPNxM0pIRq2 wSrotMKwY5vQtHe/wSt3xHfVliXJyZD/AM0aX8nsWiulrHoPx6n7SgtV7srDz9UepVMo7DTTi47C VLcccUatiTVwThKcmeD5y4D1tp/opp1ZTqJdNoSJtRRxKfUVdcPkfSk1cEf/AEkQ/HqbNO1ab6Zs 0mZFjR6pMkOTZ6GFb0ocWfctkr+8SEEhGebuTMucaWNifGp06Kc1RsjsM6bBIVnw24Fori20Phq9 HpFYbbbq9Lg1BDatyEyo6HSSfSRKI8GPtbQhttLbaEoQkiJKUlgiIuYiIf6AxmMDBhvIwYR2/v8A T7/wSv2Y/wBX/wBfyAABHiVgAAAAAAAAAAGm6WeDr3nSvVSKwSelng6950r1UisE5sWbwbEec3rn kzaZpqr7/wAfzVPrqEiK7VX3/j+ap9dQkRFb0zqP90Im105nL2AAAaB0AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT8rX2xdia3ZmsH7pPPr7z6Z3cEAAB vHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf+CYezP0pm1AAAR8kxLWd4V3t87M/UIoqRLW d4V3t87M/UIoqRlnfN3LgjDI+V7XxYAAGIzAAAAAAAAHlm74VwXB1RN4t2XblGumUmnoNbU1tp5D KUtR0rcQTiiSbiV4TjifFRYPiPS9vU+RerKZvLORLaUZ7TbVtfnkRmR4MuLTWSMvEtXHvCLKutbu mNt0DUupX5TFS2J0+CiCqIk20xWmkpaSnk0EgjSeGEf3jLifDmxKrouqZBWbNxVVKEGv+/pUbUmR jcLrXRXJReOUw/qYKUdEt+8dVGzp5SGqa6z7hU1LpcgtlBLUTjazyTijbLBce+VgyI8FO2lqDqbK g0S8qazqbXak/UDVU2EUsnaK9EJxZKRHJBcHCwRZ4cdxZ7ks+lKDprQKFf1ZvClPTor1ab21CAlS Os3lc/KGg0bt+cnklc6lcOJjhwdDLJiVmLMQ7W3KbDknLiUR2epdOjvmo1cohky4K4nwzjifASLA aVERDlYG22TVdq1x3b1TMyyI9y1i3aXQKQU9vrJaWylPHyXFe4jJxv8AK4NJl/cPmPiMQ7OL1/6L Puz2YXD7p9m/W3Xnuk9y3I9Y7uT37t2zdx25xniPV14aY23c12Q7olO1SDUozRsOOU+YqP10yefy Tpp4qR8hGXQZ44DIOpy0vKvaBVqz79odWpaZFdckNofZXGfbwwwSXUEtPSSiyZGR4MuPEIoXUrBH Aoa9FCjvKu1pjqyLLoLFYqDVJkUR11+A3JWUdxZImGSlNke01dyjiZZ7kughgdm3jflVpen8Xs7u Vp+pXhJhOyPdFxajbNNOJJKJRmS0pNxZklRGnulcOJ59R0HRe26PfVFvNFYuSbVqRFVGbXOnlIJ4 jQ4jc4ak7s4cPBJNKS2lgi4jkUHqdrKovY/1rVLhX7g1ddXi8pIZPe8rkMpXhoso/wBmb4Fg+KuP Ng4YmUhmS1+7TOr8uS4YGqitNGqrqdLpFBpaHEu0BBSanLeVsWTzzh4NTZcoSD5iykixxHHqt6ao T2tI4NdnXLbVYk15+nzVONLhqmIJ2Jybi2jwTiSS6ae6TgzJfDiefRF/aY0G76q1WVz61Q6w2wcb 3Ro004z6mTPPJqPBkpOfEZeP/ly39ErKM7PTDKoU9q0papkFqM8na64a21mbpqSo1ZNpPMaT5/kw cERRTYKKqM0tmPds3Xm89JlakXYmjx4aaiUw5LapqVKbYPYhw0fk0ZfzhBJ7wsbeOYil6z31L0ht mC7UKy7Nn3G7TZNQp7KXZzkdCWF8m3ngbyuuMJ8Z7OfnHpylad0Sm6rVfUhiVUFVeqw0xH2VuIOO lBE0RGlJIJRK/Ip51Hznw5sT9A0JsikWI5Z6V1aVEOpe6jMl6SlMqNI2ISS2nG0p24JBeLxn/kwI tBVTYNK6DObPue/I9ualUuXF1AYosS3JM2hVO44amJrDiGDJSVPERZXuVuTgzPCDPhxEXMuS+Le0 CsXVBF+XJLnqq7kVcKRL3x3WuUkmfKEZbnFHyOMrNWCMtpFgeiqBpHbVIoNw03r2s1CXcMRyJUqt Pl8vNdbUg0Y5Q047lJ4LufEWc4HPq2htp1LSmk6bv1GtppFKmKmMPIeaKQpZm8ZkpRt7TL8srmSR 8C484rgxUCmwV7/wZbalr9ddW3drHZFcLHWUduqcozN2rfycRzrZw9vdRy5TbyfDuUILPAcKsM3m zfbT+pl3XTadcOqKapdWRCTJoi2Fn3LKUJUWxSlJye5R9wkt5EZZHoqdpnQX9T2dRI0yrU6spbJq SmHJJtmagiIiS8naZqLCU8CMu9T0Fia/6PWnpVRLxFWCpSZfXvuH18Z043+blDaMs5x3PPjbwxgW xSsJNNVRdBaMCJRJ0aptPuRInU+ooo9wMtx5y89bvt55CaRFkzbM+JKxxNs+6LB43JLcOgLGtUqn 1mnO0+pxUSIzmDNKskaTI8kpJlxSojwZKIyMjIjIyMhml0Qqvb6G6VLq8hEWc6mPT6w022p9pw+K WnUKSaTUZEZEsk4PjkkmRGqLXncrlVmSfl0ro9Cb3L7Sq0Uk2n59D6fJ7jtAJLsYuf4x61/IQfuA 7GLn+MetfyEH7gcLk4ddb/IlPKx6j3eZWgJLsYuf4x61/IQfuA7GLn+MetfyEH7gOTh11v8AIcrH qPd5laAkuxi5/jHrX8hB+4DsYuf4x61/IQfuA5OHXW/yHKx6j3eZWgJLsYuf4x61/IQfuA7GLn+M etfyEH7gOTh11v8AIcrHqPd5laAkuxi5/jHrX8hB+4DsYuf4x61/IQfuA5OHXW/yHKx6j3eZWgJL sYuf4x61/IQfuA7GLn+MetfyEH7gOTh11v8AIcrHqPd5laNcsDwRg+RfrqHnbsYuf4x61/IQfuBp 1lWZejtsQ3GtXrjjoPfhtFMppknu1eM4xmO1ckChmxUiTxdv5RwPaGOKKzQpwtfy7Oh9DZrADP8A sIvf45bm+iqX+FDsIvf45bm+iqX+FEkIcaAITVvvKb5XfsD8uwi9/jlub6Kpf4URuptoXgwmBy+q 1wS9xubeUptOTt739GOX/j0DSvFVs0aqdS5m1bYGlXLwZ+ACS7GLn+MetfyEH7gOxi5/jHrX8hB+ 4EO5OHXW/wAiecrHqPd5laAkuxi5/jHrX8hB+4DsYuf4x61/IQfuA5OHXW/yHKx6j3eZ3qNWaVWW nXKVUI0xLLhtO8kslG2sjMjSoudJ8OYxc6A/m3T89Vj+pyh4ysTR/UN69ptcRV5NtMlMdMpiuEiQ neZ5JpOCwrnwrBceYyHsjqd23GdLWGnZC5DiKtVkreWlJKcMqlJI1GSSIiM+fgRF0EQy26RLkwUg jwsa7sTIvedpmz5MLmS3Djff+Szl0Oiy6zErUqj09+qQkqTFmuxkKfYJRGSiQ4ZbkkZGZHgyzkx9 M+HEqEF+DPisS4khtTT7D7ZLbdQosKSpJ8DIy4GRjGOqJvu6rT1Q0lotv1XrOBcFaOLVGut2nOXa 5eKnblaTNPB1ZZSZHx+QsWF96y6Y2PUlUy5ruhw5yDInIzbbkh1vKdxb0NJUackZHxIucukhp+7T nDBFDjrWlKt4nQ4WEiWrGj8xfVGWjfdHaoMG1qHRnKc5TkJNteVJlFhtpLfJ7P8AaE/3i5lcObOs USiUahxlxqJSIFMYWs3FtQ4yGUqUfE1GSSIjM+kTNw6r6e0GzYd41G54vuBNkFFjTYzbklDjuFnt /JJUZHhteclwNOD4joaiX3auntEZrV31X3NgPSUxW3et3XsuqSpRJw2lR8yFHnGOHkCY7RNwYYk+ hYnjpxeMKiM46nDRdyxtN5VsX5Dt2uvLrK6ixsa65abI2mUJMuVbSZLI2jPgXRx6NrQlKEEhCSSl JYIiLBEXQIes6uacUW6KrbNXuqJAqlIjpkTWpDbjaW0KJs04cNOxRnyrfcpMz483A8ffp5qLZWoM R6TZ9wRqolgy5ZCUqbdbyZkRqbWSVkR4PBmWDxwC0e8TW5syF0ePI6Y/MKixIoKrTqfVYLsCqQYs 6I8k0usSWUuNrIywZGlRGRljpH40Gh0WgQSgUKkU+lRCMzJiFGQy2RmZmfcoIi5zM/8AMR7utGlj d29iq72pZVXfyZt7lcmS923YbuOTJWeG3dn5BEai6l1y2uqvtS05FwMU6z5NBdnVJp9tlKNyUTD3 qdUneki5FvmURdz8p5S7LOjrDRrE3jrjp0BtGy27b9BtyEuDb1EptHircN1bECKhhtSzIiNRpQRE asJSWefBF0Dl6lUe565a7kG0boK3KpyhKTKXCalNrRgyU2tDiTLaZHzlgyMi8WSP47C1S0/vudJg WndEKpS427lGEkptzakyI1pSsiNaMqLu05Tx5x8StaNLE3cdqKvallViXyZtmpXJkvdt2crjk9+7 ht3Z+QWqXPUyuC21jxqvimKqhms/Re+7yRTqHex6dUe2INVbqbka2aa825OcSSyMnScwlO4lqzjP fH0cd1rlu2/XVR1VyhUuqKjLJyOcyI28bSy5lJ3Ee0/lIfFfd62rYtJKq3ZW4tKiKUaUKdyanFEW TJCEkalnjxJIxjjmr82u9VLY9uWhdMafZdYozsmQywy0onHkpmHxWaeUQZG033OS5ubiedhK0WlY SxKFN9C6X3lMUJsNVsOxqrIfkVSzLcnPSFIW+5JpbLinVISaEGo1JMzNKTNJGfMR4IdGr2/QaxNg TqtRKbUJVOc5WC/Kiodciryk9zalEZoVlKTynB5SXQQ6QDR5SPpLqHNkW/QZFwR7hkUSmvVmK2bU eoLioVJZQe4jSlwy3JLu18CPHdK6TH51O2rcqlTj1Sp2/SZs+LnreVIhtuOs559q1EZp5vEY6wBh xdIAAAtKmKdVxQKk7BiXHFaddgJgSabUVNoNZxkOmhTbxkXHYSkGlR+LcR8xGZeZ49xxXIy4kt+n EpaMPx35CMYMuOMnhSD5yMvF0GP+hpyWzLBpV/yHFbtu0WpCpDdr0dDyzypxMBolGfynjImk6fYZ sWFyiRs2G8p1jWClVHh/S/Rip6i15LNDddgUBolHKqT8U3WGsF3LbClbTdVnoM0pLx8xBc+ndqwL hrdux36jKNuSuI3Ikv8AdNJYJKXXUoSRJ3LeMyIjIySlB+M8l75Q+yhBIQg0pSWCIiIiIhhOsuic q4bodumzqhGjTJh/7dBnKUhhxXDLqFoSpSF9yWS2mSuJ8D4jYtF7QxSVLgn5O0xWX3d2vlJ0tKF6 EsR4on05dFnKp01bsJ9B9ypB5aeL9JJKyXHoLiQ+6i0u4KrJOPRoNWrDxERmzDgm4os82SQk8Z+X A9L0/qbLgrU9uNeVVpEejJMlOlT3FyZLvHihKnGkJaz+kRKPowPSNn29bNn0hNJtiixaVCSe7ko7 ZJ3K/SUfOo/lMzMdKze08pSko4kotr4GhbbBJU58jE3Ds3VZ4v0+6nHVC6323a1GZtOmGZGt2aZO yTT/ALjKT4H/AN8yHrvSbTG1dNKIdPt6GZyHsHLnv4VIlKLxrVjm6Elgi8RCu65b6Ff8g65b6Ff8 hgnX5InP+c1MsgkKD5UfsA/HrlvoV/yDrlvoV/yGDnSydYi/Ai6D9gH49ct9Cv8AkI+BqXQpqZJt RKknrabJhL3No4rYfWysy7vvTU2oy8eDLJFzC5XjZWqqNGWTZZ06LBlw1ZbDBhpnZ/Rv1af/AA0e 0MzHEvm0Sp2BycVaV/BLPZ+yTrPynKw0rT8gAAcQkYAAAAAAAAAABpulng6950r1UisEnpZ4Oved K9VIrBObFm8GxHnN655M2maaq+/8fzVPrqEiK7VX3/j+ap9dQkRFb0zqP90Im105nL2AAAaB0AAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT8rX2xdia3Zm sH7pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf8AgmHsz9KZtQAAEfJM S1neFd7fOzP1CKKkS1neFd7fOzP1CKKkZZ3zdy4IwyPle18WAABiMwAAAAAAAc9puoUSe7VLe2bn Vb5dPcVtZlH41EePybv++XA+ZRHwNNxbVfp9fhKfhKW260rZJjOp2vRl4ztWnxH4yMskZYMjMjIx Lj4J0BxU1uqU2ScCqsp2tyUp3EpPPybieHKNn+ifNzpNJ4Mu7dl8xWekubjh3r0IvfXs7BbKzpGK Pc/Xt8TTBE66XbUrE0rrN1UhiI9Ng8hyTcpClNHvfbbPJJUk+ZZ8xlxx5B0rUupqqPnS6kwVPrTa DWuMasoeSXO4yoyLeniWS4KTktxFkjOM6rr/AOHm5/8A+J9bZEwhmwzJeHA6o88ikRyp3JzFRp40 Z25rJrrRbSYvi4tPrdVa7rDMgn48km1qQ9t5NRFy61FnengaMlnjjA2+s6i2hQrSptz3BWGqTBqU dD8Yn0q5VZKQS8E2RGszIlFkiLgPLFS0ioNmWJZeqXuXNuekPRIsqv02Q6X5MnW0r5Rs0be5So8b VbucsnjJlca89fP3/YWpFBuJdItRumrQ1WI1KKe3TlGlxW9TODyS0qSjiXc7DPnLAooollMkUEET VO3/AK0m/wBGu62KxbLlzU2uQZFHaSpbsxLpE20SSyreZ42mRcTI8GQ5VlaoWFedUfpdtXLFnzWC UamSQttRkk8GpO9Jby5uKckMV04iVKj6Pai3PSosu+G6rJ67jxKrQW4keYvcfKyEMk4s3GjJRL27 UcG8ERGfCCpsmq3XrBZ9bZrlRkzq3bcyM3NlxCjssT1Q5JGwwW1JG22p5oiPiRmrvj8VeUeItUmF 1x5D1PQdUdP67dDts0i6YEqrNKNPIINRbzIjMybUZElwyIjztM8Y4jPLS19prd5X1Sb+qVGosOh1 brGlm027y0hJOvIUak5UajIkN5NKUkW7jgjLHA6nau2/Hte0tPaja8+bddIqchyWyqCtPuWtSnlp krWoiSXcKSkuOebBcw4NistLc6pxxbSFLQU4kqMsmRZnHw/zSR/5EGE3QqpcKqv3Keibj1Dsm3rd iXDV7jgxqZNRviPEo18unGctpSRqXwMuYjxkh99Buq3K7bqrhpFahS6UhKlLlIcLY3tLKt2e9Mi4 mR4Mh42oUG4odraUXuivyqJRYUOoRl1ZFL90CprpSZXdqaweSWk0II/7u3JcSIXtm2nXKnoZqa/b 1arFVVcDpyYzkmiNwSlqJRreWw2TijNDyMJLJIxwwnoKY3oKRSYUsv7Us7v16gKvCxaZYU+j1iBX KwdPqa3GneUYLlWEEaCyjBmTqzJRkojwRlzGOjfmomodPqlyv2/aEGNQLYY5eVNrhPsHUCJKjUUU ySSTMjSZZMzI+HNuIYnVa7R6xUup7jUuPIbepcyNBmqciLaIn23YiVoJSkkSzJRKM9uSLd05GvdU 6VIqVyac2rXalUmIFWrREuHGhpdamGlxlJIdUbyDbT+VMsklffGeMpIjphNpupVwQppU6TT9OLoY vSx6VdEaK9EbqDHKci6nCkGRmlRc3EskeD8ZYMucUA/KJHYhxWosVlthhlBIbbbSSUoSRYIiIuYh K3PdjqZjtFttLMmotntkyXCNUeD/AN7GN7mOJNkZeI1GkjLNZs6CTBhzHRIskWeZaZilyYat6Do3 Zc0Whk3FaZVOqshJnGgtKIlKIuBrUfMhsvGs/IRGoyScgxDlSaj7sVuQmZU9ppb2lhmKk+dDKT5i 5sqPulY4ngiSn+6ZTmoPLOm47JlyFb5Ut8yU6+rpUZERYLmJJESUlwIiLgPtELvK947U8CDFBx2+ R6Tc3s/KsCUyZ/KZuWzzAAA4xIgAAAAAAAAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4v rRbPyR/2kzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR6CAAAA FVoD+bdPz1WP6nKEqKrQH826fnqsf1OUKTPpPavyR72g+nBtZlXVbfnq0H/4jP6zCHNkXuVQ1e1B oFcviDpZRqPJI+Qhx4rE2srWnBvqdcJRrVtQkyJKdxpcR+iPSdXt+g1ibAnVaiU2oSqc5ysF+VFQ 65FXlJ7m1KIzQrKUnlODykugh/FRtu3alVY1WqNApUyoxc9by34bbjzOefYsyM0/5GM0u2y4ZcME UORNaOmunwIo4cdT/n4USpSeonlJNp9ZUq/9z6Fmf+zNnDJHEj70uUcIsdKj+UbD1dN92ddGkVHh W3clMrD5VtmQ4mFJQ9ySOt3y7vaZ7DM1FgjwfA+gx6jhW7b8Fue3CoVMjIqLqnpyWYjaClOK75bh EXdqPxmrJmOeuwrFXRUURdl24qlod5dEI6WybCXMKLeTe3aSsKVxxnuj6TGy70lxTYZkUL/i2/Gn kUwHShhVkRI0n/2gt+OSGG3VxqCy6ya0kZtr5GCncXQe1Siz8pjlxWKs51YOstOtx3raoybNWcPH BJSlR4fJrMsGWSWszzg+c+kem49v0GPcEm4Y9EprNZlNk1IqCIqEyXUFtIkrcItyi7hHAzx3Kegg j2/QY9wSbhj0Sms1mU2TUioIioTJdQW0iStwi3KLuEcDPHcp6CGv7+q1p/kUPhTyK4J5S0vujSWm 9SbFtW/o6KlManONVC3orpIqbsjr1Ro2tE4hzJEaMnkuCTLjzH270hQpXVxaXRXqetMZNsEpEaX3 a2zQicpBLyasqSaU8cnxLOT5x6P7Grc93vd/3ApXuxt2df8AWbfXG3Occpjdj5Mj+5Fv0GRcEe4Z FEpr1Zitm1HqC4qFSWUHuI0pcMtyS7tfAjx3Sukxc7fBhxRJP+WFp0xLR+1GCeZddmau51Y9BiW2 91rVp1kzmo60nt3PnHqBNmrgecLS2fEj70ughk9DaJ/qckW9WdXChRimnHdsqLbkWRU0yOuzxt3O tvKPdhRnksFlHHGD95SLfoMi4I9wyKJTXqzFbNqPUFxUKksoPcRpS4Zbkl3a+BHjuldJj81W1biq 8VfVb9JOrpTsKecNvrgk5zjlMbsZ+UZJd6KCCGHByJdGVV6U+naijgqeb9Sm5Fs686MVq/Z/KW1C oxxHps9hLaEVAmXCU46RGpDalKNhWNxkRoMyPCTM/nqNZtqvdXzZVRteZCnRl0d9L8qGpK2n3iYm kaiWngvCdiTMjPinHiHqKsUumViA5T6vTolRhuFhyPKZS62rypURkY+Jm1LXZqsKrM23Rm6hAZNi HKRBbJ6M2e7uG1knKE92vgRkXdK6TGKG3w4ONY8Fw4smOuOneVwTsgADmF4AAAAAAAAAAAAAAAAA AAAAAAAAAYBa/wDZ1n/iOs/1KSN/GAWv/Z1n/iOs/wBSkjZk/JFtX5O3cGcv+r4o64AAvJcAAAAA AAAAAAAAABpulng6950r1UisEnpZ4OvedK9VIrBObFm8GxHnN655M2maaq+/8fzVPrqEiK7VX3/j +ap9dQkRFb0zqP8AdCJtdOZy9gAAGgdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAC+0k72p+Vr7YuxCaSd7U/K19sXYmt2ZrB+6Tz6+8+md3BAAAbxyj4bh94Kj5q76hjFBtdw+8F R81d9Qxigjl/fNB3/gmHsz9KZtQAAEfJMS1neFd7fOzP1CKKkS1neFd7fOzP1CKKkZZ3zdy4IwyP le18WAABiMwAAAAAAAAAAB8lUp8aosJbfJaVNrJxl5tRocZWXMtCi4pUXSXylzGZDo2/dciBJZpF 0uJJTiibiVQkklqQo+CUOEXBt0+bxJWfe4MyQX4j85UdiVGcjSWW3mHUmhxtxJKSpJ85GR85DoWC 8ptji/jjh0o5N63PIvGD+WKJZH+5UaCAzmkVqdam1iYcio0AuCXeLkiAXy+N1ounitP+8XeaDEkR 5cVqVEfafjuoJbTrSiUlaTLJKSZcDIxOLLa5Vqgw5b9DzC33fPsM3k5y2PQ9h+oAA2jSAAAAAAAA P8WpKEKWtRJSkjMzM8ERdI+Ss1OBR6c7UKnKRGjNY3LV0meCIiLipRngiSWTM8ERZGf1WRPu1e6q MOQqKR5apqj7uR0KkY4Y6GiPHjVk8JRp2y3SrJBhRvHoWlnRu26594TMCUsWl6EfXWLlmXIaolvP uw6RnDtTR3LkkvGmP0JP/F/c5yWX8QIcWBEbiQ2EMMNlhKEFgi8Zn8pmfEz5zMfuRERYIsEAg1tt 822R1jyaF0Hp923VIu+Xgy1j0vS/3oAAA0jpAAAAAAAAAAAAAAAAAAAAAAAa5YHgjB8i/XUMjGuW B4IwfIv11Dt3F9aLZ+SP+0maw/2XBndAAEoISBCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/ gyBAAEKPQQAAAA+Wy7ivO0qK5RIlsUCox01CbJakO115hakvynXyJSCiLJJkTm3go+bI+oBVNUo1 VGrarHKtSSmaDodse+/2Htv0mf8AwIdse+/2Htv0mf8AwI54BSXqLf5mlzHZe3xOh2x77/Ye2/SZ /wDAh2x77/Ye2/SZ/wDAjngFJeot/mOY7L2+J0O2Pff7D236TP8A4EO2Pff7D236TP8A4Ec8ApL1 Fv8AMcx2Xt8Todse+/2Htv0mf/Ah2x77/Ye2/SZ/8COeAUl6i3+Y5jsvb4nQ7Y99/sPbfpM/+BDt j33+w9t+kz/4Ec8ApL1Fv8xzHZe3xOh2x77/AGHtv0mf/Aj4qfq1eM6dUobFj29ytOfTHf3XI8Rb lNIdLH+xcS2uJ/zyP4EtZ3hXe3zsz9Qii+CGW1E8BYl29K7THHctmhihSrjfT2Nlz2x77/Ye2/SZ /wDAh2x77/Ye2/SZ/wDAjngLKS9Rb/Mycx2Xt8Todse+/wBh7b9Jn/wIdse+/wBh7b9Jn/wI54BS XqLf5jmOy9vidDtj33+w9t+kz/4EO2Pff7D236TP/gRzwCkvUW/zHMdl7fE6HbHvv9h7b9Jn/wAC HbHvv9h7b9Jn/wACOeAUl6i3+Y5jsvb4nQ7Y99/sPbfpM/8AgQ7Y99/sPbfpM/8AgRzwCkvUW/zH Mdl7fE6HbHvv9h7b9Jn/AMCHbHvv9h7b9Jn/AMCOeAUl6i3+Y5jsvb4nQ7Y99/sPbfpM/wDgQ7Y9 9/sPbfpM/wDgRzwCkvUW/wAxzHZe3xOh2x77/Ye2/SZ/8CHbHvv9h7b9Jn/wI54BSXqLf5jmOy9v idDtj33+w9t+kz/4ETdsRZ0WnyTqTcZqXKqM6c43HdU6231xKdfJBLUlJqwThFnaWTLmHUAVqkqQ qnj5mxZbtk2WPDl1rSgAAFpvgAAAAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR 5zeueTNpmmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/AHQibXTmcvYAABoHQAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpnd wQAAG8co+G4feCo+au+oYxQbXcPvBUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTEtZ3hXe3zsz9Qi ipEtZ3hXe3zsz9QiipGWd83cuCMMj5XtfFgAAYjMAAAAAAAAAAAAAAAHPhHUbblLmUFsn4bizXKp RqJKFmfFTjJnwbcPnMj7lZ8+0z3l0AGezWmZZo8OW6M1bZY5NslOVOVVw2FZb9ap1dp/XtNf5RBK NDiFJNLjKy50LQfFKi6D/wDIdEZlJhSWKh7sUWSUGqJSSVKNO5qSkuZt5P8AeLoMsKTngeDMjrrU ueNWzchvMKgVaOndIhOKyZFzb21YInGzPmUXkMknkim93XpLtkNMkXR5HmV73HOu6LCywaH5nfAA HUOIBxrpuODQGWyeS5ImyMlFhMERuvmXPguYklksqPCU5LJlwHPuq6zhSl0aiMtzqxtI1krPIQyP mW8ZePHEmy7pX+6WVFO06ndbPvTZUh2dUZGOuJb2N68cySIiwhBZPCU4IuJ8TMzPkXle0uyLBhxx 9HRtJDc1wTbe8OP+Mvp6dnmfyUedUqiir3A42/MbMzjR2snHhEZYMm8kRqXjgbhlk+OCSR7R0AAQ mfPmT43HMdWelWazSrNLUuUqJAAAYjOAAAAAAAAAAAAAAAAAAAAAAAAAAGuWB4IwfIv11DIxrlge CMHyL9dQ7dxfWi2fkj/tJmsP9lwZ3QABKCEgQmrfeU3yu/YF2ITVvvKb5XfsDRvLNYzq3Jn0vv4M gQABCj0EAAAAAAAAAAAAAAAAAAAAAAAAAAJazvCu9vnZn6hFFSJazvCu9vnZn6hFGWX8sWz8owzf mg2/hlSAAMRmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA03Szwde86V6qRWCT 0s8HXvOleqkVgnNizeDYjzm9c8mbTNNVff8Aj+ap9dQkRXaq+/8AH81T66hIiK3pnUf7oRNrpzOX sAAA0DoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX2kne1PytfbF2ITSTvan5 Wvti7E1uzNYP3SefX3n0zu4IAADeOUfDcPvBUfNXfUMYoNruH3gqPmrvqGMUEcv75oO/8Ew9mfpT NqAAAj5JiWs7wrvb52Z+oRRUiWs7wrvb52Z+oRRUjLO+buXBGGR8r2viwAAMRmAAAAAAAAAAAAAA AAAAAPiqlNZnky4a3Y8qOrfGlMK2vML/AEkqx/kZHklFwMjLgPtAXQRxQRKKF0aLY5cMyFwxqqZ9 ts3W8Utqi3KTUee4eyLLQW1iafQWe8d/7Mz486TPBkn465dMqtOLp1rP8jESo0SaukiUWS4GiORl havEbh5SnmLceSTMarttu6X3SlxtKyKjylESk5IjS0oyPykZEZfKQoICENwWG20JQhLSUpSksERE XAiId6O/Z7s6S+bJX90kVg9l7KrY4m6wZcH16MR+dMgRKbFKNDa5NG41KMzNSlqPialKPipRnxNR mZmfOPqABwG23VkrhhUKoliAAAoVAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANcsDwRg+RfrqGRjXLA 8EYPkX66h27i+tFs/JH/AGkzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X3 8GQIAAhR6CAAAAAAAAAAAAAAAAAAAAAAAAAAEtZ3hXe3zsz9QiipEtZ3hXe3zsz9QijLL+WLZ+UY ZvzQbfwypAAGIzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabpZ4OvedK9VIr BJ6WeDr3nSvVSKwTmxZvBsR5zeueTNpmmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/dCJtdOZy9 gAAGgdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+0k72p+Vr7YuxCaSd7U/K 19sXYmt2ZrB+6Tz6+8+md3BAAAbxyj4bh94Kj5q76hjFBtdw+8FR81d9Qxigjl/fNB3/AIJh7M/S mbUAABHyTEtZ3hXe3zsz9QiipEtZ3hXe3zsz9QiipGWd83cuCMMj5XtfFgAAYjMAAAAAAAAAAABJ awXLPs/TqqXHTGYzsuJyPJokJUps97yEHkkmR8yj8fPgVozfqmfzI3B//G+stDPZoVFOgheRtcTX tkcUFnmRQvGk+B/tq6iv17RupXc3HjtVenU996RGUlXJpeQ0biT253bFFtUXHmPn8Y50DVtUXRal XtWoDb9VqTrkeNBhJUlLzxOuISksmoyLCMmfH5OJkQi7ljvWrplTbqhsmdNr1nNUmroQRcHjiYjP mWMnxM2zPPAjSJ4m3IOjuk91Pcsql0etPOTUIQai2nMNRKPHRyaklnxrx4+PUhskqLHTE4vw8Xiu BxI7dPgdK41Bj8Yf5eD8amgy9SdV6Cy5XLo03YaoCTSpZxpBG+wgzwalFvVn/NKS6TLnGwUSpQ6z R4lWp7vKxJjKXmV4xlKiyXA+Y/kGc6q6j2M7pjXG4ty0uc9Opz0eOxHkJcdUtxBpTlBcU4MyPiRY wO7oZTJtH0mt6DUTd65TGNxSXEmSkE4tS0oMj4ltJRJx8niGlPgTkqY4MF1ppxqnb0HQssyJWhyl Hhqla4sTr2dP4Ojqn+bG6vmWZ/orHfif9Va/7hf+Q4Gqf5sbq+ZZn+isd+J/1Vr/ALhf+Q1X9NbX +DdX1nsXFn6gADGZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANcsDwRg+RfrqGRjXLA8EYPkX66 h27i+tFs/JH/AGkzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIAAhR 6CAAAAAAAAAAAAAAAAAAAAAAAAAAEtZ3hXe3zsz9QijsXN7rFb85VBNgqollSopPI3IU4RZJJlw4 HjHyZHnzQy/79ujUuZAUxT2WJT/XtXV1sojbJtptnanKu5M+TQnjniZn4huWezxTJUyNNUS/Kf4N C1WqCVOly2nVvF4Nfk9KAADTN8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTd LPB17zpXqpFYJPSzwde86V6qRWCc2LN4NiPOb1zyZtM01V9/4/mqfXUJEV2qvv8Ax/NU+uoSIit6 Z1H+6ETa6czl7AAANA6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF9pJ3tT8r X2xdiE0k72p+Vr7YuxNbszWD90nn1959M7uCAAA3jlHw3D7wVHzV31DGKDa7h94Kj5q76hjFBHL+ +aDv/BMPZn6UzagAAI+SYlrO8K72+dmfqEUVIlrO8K72+dmfqEUVIyzvm7lwRhkfK9r4sAADEZgA AAAAAAAAAAObc1CpVy0ORRK3F66gSdvKtcopG7aolFxSZGXdJI+B+IdIBVNwuqylIoVEnDEqpnJk 23RJNqFaz8BLlHKKiIUZS1cGkkRJTuzuyREXHOeGc5H80e16BSbXTbEKmNFR0oWgojpqdQaVqNSi PeZmZGajPifjHYAV5SOlK9vf0lvJQVrRVpTu6NhGUvSvT2m1Y6pDtWCiVvJaVK3LShRcxpQozSk/ IRCzABWOZHMxxNvaJcqXKVIIUtioTeqf5sbq+ZZn+isd+J/1Vr/uF/5Dgap/mxur5lmf6Kx34n/V Wv8AuF/5Cr+mtr/BYvrPYuLP1AAGMzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAa5YHgjB8i/XU MjGuWB4IwfIv11Dt3F9aLZ+SP+0maw/2XBndAAEoISBCat95TfK79gXYhNW+8pvld+wNG8s1jOrc mfS+/gyBAAEKPQQAAAAAPht2HfVy09yqUOiW4dPKZKitKmVp5l1RsPuMKUpCYqyTlTajIiUfAy8h VULaqa9otcmzJOa6V2/g+4B/fYrqf8CWd6QyfwQdiup/wJZ3pDJ/BCuD2rxXmanPNj19z8j+AH99 iup/wJZ3pDJ/BB2K6n/AlnekMn8EGD2rxXmOebHr7n5H8AP77FdT/gSzvSGT+CDsV1P+BLO9IZP4 IMHtXivMc82PX3PyP4Af32K6n/AlnekMn8EHYrqf8CWd6QyfwQYPavFeY55sevufkfwA/vsV1P8A gSzvSGT+CDsV1P8AgSzvSGT+CDB7V4rzHPNj19z8j+BP2zaFGt6tVyrU5jZJrMkpEg8cCMk8yeHM ajUryqP5MUfYrqf8CWd6QyfwQdiup/wJZ3pDJ/BC5VSaUSx9q8y2K9bDE03FjWTE/I/gB/fYrqf8 CWd6QyfwQdiup/wJZ3pDJ/BC3B7V4rzLuebHr7n5H8AP77FdT/gSzvSGT+CDsV1P+BLO9IZP4IMH tXivMc82PX3PyP4Af32K6n/AlnekMn8EHYrqf8CWd6QyfwQYPavFeY55sevufkfwA/vsV1P+BLO9 IZP4IOxXU/4Es70hk/ggwe1eK8xzzY9fc/I/gB/fYrqf8CWd6QyfwQdiup/wJZ3pDJ/BBg9q8V5j nmx6+5+R/AD++xXU/wCBLO9IZP4IOxXU/wCBLO9IZP4IMHtXivMc82PX3PyP4Af32K6n/AlnekMn 8EHYrqf8CWd6QyfwQYPavFeY55sevufkfwA/vsV1P+BLO9IZP4IOxXU/4Es70hk/ggwe1eK8xzzY 9fc/I/gB/fYrqf8AAlnekMn8EOXb8+TUIDrkyK1FlR5kqE+008bqCcjyHGVGlZpSakmbZmRmkjwZ cCBwulfyjPZ7fZ7TFgSoqvLkf5R0QABabgAAAAAAAAAAAAAAGm6WeDr3nSvVSKwSelng6950r1Ui sE5sWbwbEec3rnkzaZpqr7/x/NU+uoSIrtVff+P5qn11CREVvTOo/wB0Im105nL2AAAaB0AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT8rX2xdia3ZmsH7 pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf+CYezP0pm1AAAR8kxLWd4 V3t87M/UIoqRLWd4V3t87M/UIoqRlnfN3LgjDI+V7XxYAAGIzAAHx1ipRKTAVOnKcSylaGy5Nlbq 1LWskISlCCNSlGpSSIiIzMzIVhhcTospSKJQpxROiR9gDh9k8P4Huv0XqP3Adk8P4Huv0XqP3A2P crT1cXgzU5xsfWw/7l5ncAcPsnh/A91+i9R+4Dsnh/A91+i9R+4D3K09XF4Mc42PrYf9y8zuAOH2 Tw/ge6/Reo/cB2Tw/ge6/Reo/cB7laeri8GOcbH1sP8AuXmdwBw+yeH8D3X6L1H7gOyeH8D3X6L1 H7gPcrT1cXgxzjY+th/3LzO4A4fZPD+B7r9F6j9wHZPD+B7r9F6j9wHuVp6uLwY5xsfWw/7l5krr vedBt6z6rRKq++zMq1KlNQiJhSkOLNtScbiLBHlSefmyQ7+nt50G86a7IoD70hmKaWnVrYU2W/Gc FuIs8Mc3SQjNd6fFvmw34MOhXSuqxVdcQc2zUE5WXOjJsEREpOS4mRZwZ8w6+lzdNsux6dQW6PdJ vNN75TibXqP5R5XFav7DiWeBfIRDcisUXuypLiw69D8chz4bxg98dZsGBRY6rwy/qNDAcPsnh/A9 1+i9R+4Dsnh/A91+i9R+4Gn7laeri8GdDnGx9bD/ALl5ncAcPsnh/A91+i9R+4Dsnh/A91+i9R+4 D3K09XF4Mc42PrYf9y8zuAOH2Tw/ge6/Reo/cB2Tw/ge6/Reo/cB7laeri8GOcbH1sP+5eZ3AHD7 J4fwPdfovUfuA7J4fwPdfovUfuA9ytPVxeDHONj62H/cvM7gDh9k8P4Huv0XqP3Adk8P4Huv0XqP 3Ae5Wnq4vBjnGx9bD/uXmdwBw+yeH8D3X6L1H7gdCj1KJVoCZsJTqmTW42ZOsraWlaFqQtKkLIlJ UlSVEZGRGRkLJlnmylWOFpdqaMsq1yJzwZcaifY0z7AABhM4AAAAAAAAAAAGuWB4IwfIv11DIxrl geCMHyL9dQ7dxfWi2fkj/tJmsP8AZcGd0AASghIEJq33lN8rv2BdiE1b7ym+V37A0byzWM6tyZ9L 7+DIEAAQo9BAAAACq0B/Nun56rH9TlCVFVoD+bdPz1WP6nKFJn0ntX5I97QfTg2sq6vcFBo82BBq 1bptPlVFzkoLEqUhpyUvKS2tpUZGtWVJLCcnlRdJDpjzZ1W356tB/wDiM/rMIU2rupd9WzV5UeC/ pvbUNl3bFcuirOKkVBBII1ONsR+KU7j2luPPDiRZIXqxOOCW4HjiTfg6EVwsptoDxlrVrnd149Tl Sbrtl1q3GJNado9cbYeWcjleR5RtLTmCIm1I3KXzKzsSRmW7O1ajap1/TOxLdTd7NtSL0rc04baI spcemt/lMcspbvdpbQhTe8z5lK8RcRWO7p0KhWltqmwpho2MBh+kutE2tajp09uqZZtQqkiCcyFU rWqJyYTxkatzJkozUlwkpNWMnwIz4EZCe0b1a1r1S0/qFYt63LJamw5y2DkTHZLbCyJttZNoaSa1 KX3SsqNaU90jn4i12CbDXCokqaenJwK4SPSIDAaP1SVNf6nqTqdPoyWp0ecdM9zkP4S9LwlSUpWo s7TQolnwMyIlc+BR23eOrVOvOj0e/bKpztOrfKGzOt5Ml9NMMiI0olmtO0jPON5GRZzwwR4tisU6 GuEqUrp6MtOkYSNbAZJplqnUZkG/Y1+t0yDVbMlulL60QpptyKSDW29tWtZluJKj74/EO7oFdF0X rpnBuq64VPgyaktb0aPDaWhKI2cN7ty1GpR4NWeBYUXAsZPHMs0ctNxaKb1XF3BRJl8Jrs/sP3E9 3Oza2vcrrnrTr33VY5Dl9u/kuU3bd+3utuc44ilHiPttf/hf7J+1npt4adYe5nuF/sH/AFLlOX5L f/bf3d+e94YGax2R2itOlLxr5CKKh7cAeXqBc2rVQ6tK4LcbqtDdgUuMRrhyFPFHZpi3IqzUylPP LNC28qXlO41kR7dpB1MlzatXDrhfzNw1WhzYNMnphVls1Pf7PsOWlpEBPekjlEnuNzujSRHxVkXx XfFDA43EsST8SmHjPUIDzLVuqRqs12u1q1ntP2qBQ33mutKzWjZqdVJtBK3xUJ7narPc5JW7mLjk h1tQtfavFj6U1Kx6VTahEvd9bTzEzcbqFJcYbNpC0KJKVkpxaTMyURGkuHAyO3m20VSay+VeBXDR 6EAcKyDu46KZ3siiIqvLL7mkKdVHJrPcFl0iUasc54Is8xDujSiWC6FwAeatH9XtbNTLAn16gWtZ qpECetlxT70hpD6Uttr5JpsjWfKd0fdKWlPdI4HgxXW/rNUbv0jp152nR6O085Icj1VysVVEaHSV NoNSlOrIjWoj7jaSU5wsjPaNuZYJ0DadMTo8axFqiTNnAefNItd6rXNV4+ndzP2dVpE6M4/Eqdry H1xiUhKlGysnSzu2oWrcR470uJmP1i6v6j3g1cNx6Z2tQKna1vS3oriZUh5c6qKbQlR9bE0RpIzJ RGkj3btycceArFYJ0MWC1TI61xY8gw0bXV7goNHmwINWrdNp8qouclBYlSkNOSl5SW1tKjI1qypJ YTk8qLpIdMeT+qbuWPMvLQG66rDlUBj3WVLlsVFs2XIaUvwlOE4SiIy24PjjmLI1rT7VGZevuxeU NmDTtOaW08SZktKuu5i2iM1upLeSWmkkWe7Saj/3eOKzLDFDJhmLTWu2rVNwUWOhqwDy0rqnK17i nfCWbE7GuW5MqEdaPsg2ctyfK8l3nN3WzGccc44j8dSr21PqXVR2dR7IrdBXTKhSSqlBjS1vFCfb civ7nJXJ90pfcu7NpmkiJo+c1C+G7J1WoqLE34ZUUw0eqwABzi8DALX/ALOs/wDEdZ/qUkb+MAtf +zrP/EdZ/qUkbMn5Itq/J27gzl/1fFHXAAF5LgAAAAAAAAAAAAAANN0s8HXvOleqkVgk9LPB17zp XqpFYJzYs3g2I85vXPJm0zTVX3/j+ap9dQkRXaq+/wDH81T66hIiK3pnUf7oRNrpzOXsAAA0DoAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX2kne1PytfbF2ITSTvan5Wvti7E1uz NYP3SefX3n0zu4IAADeOUfDcPvBUfNXfUMYoNruH3gqPmrvqGMUEcv75oO/8Ew9mfpTNqAAAj5Ji Ws7wrvb52Z+oRRUiWs7wrvb52Z+oRRUjLO+buXBGGR8r2viwAAMRmA4d6+99M+f6R/UY47g4d6+9 9M+f6R/UY42bFnMv+y4mneOZzf6xcGayAAPSTxkAAAAAAAAAAAAMaufXmn0TWJqwlUB1+GUuPClV YpBkiO+8nKUmjkzz+8XMr9EUmqOpXYPd9lW/7i9f9lFQOHy3XXJda/lGUb9uw9/9tnGU97z8eFuE i/k4sWLKaCA5V5VjsdtCtXB1t1z7mU9+ZyO/ZynJNqXt3YPGduM4PHQMHpHVGXrWKc1UqRoVcNQh PZ5KRFkPOtLwZpPapMYyPBkZHjxkYOJLKIZcUSqj0aAw2/dd63bVdtygxdM6hVatWaIxVDgtS1pk R1r5TexyZMqUo0cmrJ4LmPJFgfra+vUmpzp1Cq+nVdoVzN0uRUIFLk7t042kKUTSMtpXuVsVjCD7 1XPjAphoryMdK0NtAebH+qWuyPXWKC/olW2qtJbN1iCuW6mQ6gt2VJbONuUXcK4kWO5PoG56dV6p XPZsCuVe3pduzZPKcrTZW7lWNri0FnchB90SSV3pcFF5RVRJ5BHKigVWUAAAuMYAAAAAAABk1l+9 9T+f6v8A1GSNZGTWX731P5/q/wDUZIj/ALR5tD/b8Mlvsfnkf9fyjuAACGnooAAAAAAAAAAAGuWB 4IwfIv11DIxrlgeCMHyL9dQ7dxfWi2fkj/tJmsP9lwZ3QABKCEgQmrfeU3yu/YF2ITVvvKb5XfsD RvLNYzq3Jn0vv4MgQABCj0EAAAAKrQH826fnqsf1OUJUVWgP5t0/PVY/qcoUmfSe1fkj3tB9ODay P6omxLquzVDSWtW/SuvIFv1o5VUd64ab63a5eKrdhaiNXBpZ4SRnw+Us8GNYmpNn63XhdFHs+iXg 3czqVwqrPqLbC6SkiM9ikmg1mnilOEEeSaQZmPRgCsFujhgUuiaSpp6a9PSRVwqtTxonqfNRD6nK s2F1gymrQrvVV4OZLWyosFG5Ath7/wAmZ8VES8eIjxnJa5rdpzcGqVqWdcK6DToFz0GWmauiVGSm RHdQpSDdjLcSRoUSuTRx2mRkRlwyY28BkjvKdFEo8VU2/HE/EooEYdpHYlwnqOm8avp7aOn9NiQz ZiUenw4MiSt9W5KnlSmmiUgtijLalXEj4+PP99RnYl1ae6X1Ki3fSvc2e9WnZTbXXDT2WlMMJJWW 1KLnQosZzw8g24BimWyOOGKFpUdN1e3t01KqFI8j2L1PV3VLqYazYdyQ2qJcBXEqrUwnpKHWzMo7 TZblNKUREouVTxyZc+OYa7bL+uFw3hR3q9TKfZVBpvKFU2WpjE5ysKwWw0fk8soyRn3xKwZ/JjWw F823xza4aTrV7K5aetQoUjyX1VVrVJ3W6h0m15qormokNNLrDTJ4UbbDzSzfMiMsnyZbcnnuULT4 zIbVfc+87OqNhUSw7epMi2nJjVPqynzJK4cbey2jkUk4gzMkG6fBK8EgjMiIuPct/TSxaBd9Qu6k 25Ej12oPOPSZpqWtxS3Dys07jMkbjM8kkiLiYqXI7Dj7T7jLa3msk24pBGpGefB85ZxxFZlrUSgh pVQrTpfjoVKbCihyn6GZERmZkRFzmfiHgLT6wLuv7qQ10i06OqoTUX2qYbZvtskbKYJNmslOKSRl uURcDzz9Bj3Zc9CpdzW/NoNbjHKp05o2pDJOLb3oPnLcgyUX+RkPytC2qFaNvxqBbdNZp1NjEZNM N5PGeJmZmZmpRnzqMzM/GYWS2e7QPBVYm0+zFXzEUOEzI49jXlb/AFW9R1DgUVqrW9cVNRBlPpmN srpxpSwRrUhR7nP+rlgkl/fPm28WjNjXlYmumoUuVRWpluXZMOotVZuY2nrdROPLJlTJnvUZ8uZb iwRbSPx4LcwGN22OKFwtLGkvDJpyorgo8nxdE7rslq4bYt7TKzLsi1WW89SLgqao6naQhaEpSlxt 9tanCTjJEk1EZ5My7oyFFqJpJdiqzogzRKdDqMa1KmcitSYjUaAy3ukRnFuIYTsIiM0OntQkz4cc mfH0cAyu8pziUTSrj6cdVTp6OiiKYCIDVKv39RLms1i06LTJ9GqFSTGrr8pRcrGaU6ylKmk8ok1K 2qeM8JXjZkyIiPN+PycjsOPtPuMtreayTbikEakZ58HzlnHEfqNKKNOFKmTeXHjXqN6pqTStGauu yLVplxMv111skv1IorkR7kGMuGSkmlxGDT3JGlRbT588O1UOp0uih6R2dS6SinXBUaNXFVusUd17 k4tTWokFyZKcLHBDSW+O1JktZmXiHovTuxLV09oj1FtCle5sB6SqU411w69l1SUpNWXFKPmQksZx w8opR0p15xctFHKVE3Xbox4+3QWKDFjPOEGyNSqn1Rtj6m1ezKdRabDhvwZFPhVFp5UBvkXiQpxX cEs1LkK4NkrBI+Uf5aFkauaT0+5LJ0+t+l1OlVie/LpVbdqaGjpRrbQhPKsuIUbppJCcY3EZlk+f A9IAMDvCNqjhVKJUx0xNtadFfMrgI86a3aV3veFX0ebqLDV2N0Wao7olrNhhtba3YxuHyRmnck0o cLahJnhPEsnx7dI0yqdtX/dNt0iipXppedPcKU3GeaaKlyVNm2va3lKti08O4I8Ht5iLI3ABb79N wFBioq73Wu1PIVwVWp5LoujF+0a12tPYunNhPvtyDUi+pTESStLBvmsyVGeaUtbmwzSWckRYIj4E ZW1+6b3bStd9PtQbRokeuU6hUtNHkwm32YJst7H0E6kjwjaSX87EJLvCIiIj7nfgF8V4zYoqtLHW uXHXLp4URTAQAAGgXgYBa/8AZ1n/AIjrP9SkjfxgFr/2dZ/4jrP9SkjZk/JFtX5O3cGcv+r4o64A AvJcAAAAAAAAAAAAAABpulng6950r1UisEnpZ4OvedK9VIrBObFm8GxHnN655M2maaq+/wDH81T6 6hIiu1V9/wCP5qn11CREVvTOo/3QibXTmcvYAABoHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpndwQAAG8co+G4feCo+au+ oYxQbXcPvBUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTEtZ3hXe3zsz9QiipEtZ3hXe3zsz9QiipG Wd83cuCMMj5XtfFgAAYjMBw71976Z8/0j+oxx3Bw71976Z8/0j+oxxs2LOZf9lxNO8czm/1i4M1k AAeknjIAAAAAAABz7mq8S37dqNcnqNMWnxnJLpkXHahJqPHy8B0B89TgQanAegVKHHmxHk7XWJDS XG1l0GlRYPyGKBHiKLbutNx6b1qcxZcGXTbjmlXnKmchtMpKknuI2iN4jJJESsEaDPCjxzkKnVW/ INcY0EvmpSSaZamrfqTpNqMm1svRCfUSSyoyI0KMiLJmWMZHraHEiQoTUGHFZjRGGyaaYabJDbaC LBJSkiwRERYwQ4T1hWK9BjwHrLtxyJGUtbDCqWybbRrxvNKTThJq2pzjnwWebhj5NpYmbPLpurRA XRqvYF9acXxSLVr3uhNZtioSVtdZvtYbJk0mrLiElzrSWM54/wDLzPpzNpLNmwG5PVE3DaDpcpuo 8WnznG435RWNqmnCQe4u74Fzq48cj21TrGsqm9c+51n29C66jrjSet6ay3yzKu+bXhJbkHgspPge B8na004+L+1PoaP7AOBvGIJsECaVdx5s1Aoc66td9MaNQ74qEaTLsyObFxtIcTIdJLcpZvbTWlZG 4lJ5I1ZLeec8SFToFR2KFrhWKNf1UrNVvuDHNFMmz5S3WZEI8nuZ390SsKPKTMyLu8cysegGrZtx mowak1b9Jbm0+OUaFIRDbJ2MyRKSTbatuUIIlKLaWCwZ9I/WbQqJNq0WrzKPT5FRiFiNLdjIW8wX HvFmW5POfMZCqgx1LXOqsHsMNvn/AOOWw/mB31Jw9BDnv0OiP11ivP0enu1aM2bTE5cZCpDSD3ZS lwy3EXdq4Ef94+kx0BclSpjjiwqdiAAAuLAAAAAAAADJrL976n8/1f8AqMkayMmsv3vqfz/V/wCo yRH/AGjzaH+34ZLfY/PI/wCv5R3AABDT0UAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4v rRbPyR/2kzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQI+epToVNhOT qjMjw4rREbj77hNtoyeCyo8EXEyIfQJXVRKVWkhKkkaTq1MIyMuBl1+wIbLhUUahekn02NwQRRLQ j9uz6xP21tv6UZ9oOz6xP21tv6UZ9odv3OgfqMb+Cn/0D3OgfqMb+Cn/ANBdWV0Px9Cyk7pXg/My O1eqBtabWJNKr6fctTchbTMxCuVjPJJRklWSLKcljpLx5Iei+p4fZk6XMyYzzbzDtXq623G1EpK0 nUpJkZGXAyMuORhtq6KWbR6zJrU+N7sz3pC30nKQXItblGeEt83DPOrPNwwN16n9KU6aoSkiSkqz WCIiLBEXunKGW3OzuD/ATyrg8hF7zVqUmH3lrK6Uy9+gyvqtvz1aD/8AEZ/WYQubs1fqiL4qdmaf WDNvSrUdDa6oaZ7UJiNvIzJPKOEe5fN3JF08ckZCZ6p+369WNXdFp1JolSqEWnV83Zz8WKt1uKjr iGe5xSSMkFhKjyrBYSfQY+KmM3JozrFf9ecsa5rpoF2yGZcaRQ2CmPMulyqlNuN7iUlOXF8eYiJJ Fz4K+CGXHZ5daNqF0VaVeFtWjGcBtpsu6Lrhak/TCv3zKi1CnJt51caqU59CSkMPpUSSaLjtM1KU kiPJFk8HjB45ltayXVUk0mqzNHriatusrZKBU6fLanr5Nwsk68w13bSCLiZnnHNz4I5/RnTy46bb mp10XLaLEmpXrPdlJtuXLSlKmd7q0trcJKiSpRvL6cYTzHnGfUu3rtplaosfR6xdR7Gqzc1v3WjV V/lqEllX9phS1/lsHjiWDMt3AlYwhs9mcUcMNMWlvEsXY+nTRophPEbde+sMqnajv6dWXZkm7rmi xEzJTBVFiE002e08G45nKsLQrBFzKL5cVum13TLtp0x2o2lXbYmwpJx3otUY2ksyLv2nC7l1HOW5 PR0GRnlfVC29SJl7RaxW9JLnrbLMUij3BakxSqg05ng2qOnYeCyZkvcrBeIuOO91L0XUaJQK03fL lW9zSnYoDdZUldRRFLOOXUkzyeDQWD4kZL8RpxrzJMr3ZRwqjxacbfZjfhRNFybwqF5ftyz7ciRP cq1avck6Y8bTUaCSUIRhBqNbrrhkhpHDGVHxMyIiMQ2nmtLtb1FRp9d1pKta4n4ypURpurMT2Xm0 kZmXKNY2rwlZ7cHwQZ54kOb1W9Du+tUO2zocCqVe3o1TJy5KVTFqTJmxOGUJJKiNZbScTtLJma0n 4sjO7XtWWjqoLCvO39KKxZ9qdZyIptrpxNrSvkHy5aQhrcTRqN9CCNwyM9h9AyWezyYrO4oqVo9t VkWXT0U7yjbqaDo7rxWtSaeipwdN34lLjz1x6pPVWGzZhNE2lZOd0hK3FcTyhKeBERmrjgfyrqhX Cop3qWnlYPTonuR7IuvGd5ny3I7+tc8pye7huznPDGRO9SJYtaPqcbvs+5qTVKC/WJ82PsmxVsOk 29DZb5RKVpIzLO7B4MspPoGY0XSA6da7VnTdCqlVtQEyDT7tyZMkqK4yb5/lFusyEEWG+BJIiVwI zIzyR7Xu9jc2OGmJNLLo0vHEvzToZSsVEe4Yz7UmM1JYcS4y6gltrTzKSZZIy/yGI0fXav165r3t y2tL51ZqFr1BcRJMVVpCJCUuOoNxanEp5PPJFhKeUM9x/o5PYbYpbNDtql0SO200zT4bMVtDW7Yl LaCSRJ3mpWCIuG4zPpMz4jEOpgt+vUfV3WmdVqJUqfFqNfJ2C/KirablI64mHubUoiJZYUk8pyWF F0kObZ4ZWBMiiVaUpXb2PoL3WqP1p/VFyK9YD15WhptWKxAppLVXFOTmY6YCUJ3L2mrJvGSMKwlP MfEyPgO9N10pEm37Tk2lQp1xVu7WnXKVSG3m2VfkiVyvKuqPY2STSpJnx5jwR4MZj1Odq3RSupF1 HodUtusQarM91OtoUmC42+/vgNIRsbUklK3KI0lguJkZEIalaM1dVkaZXZclh1yu0+lw50Gv2+2h bE5LXXct1laG8ocM8vbsErJ4RwMjMdJ2WyYcSyUioseXE30rTs6K6SzCiPUOm2p7V0zq9Qqxb0+3 rmt9Da6lSnFpkqSlaN6VNLbyTpGXNgs8S4cSEbduvNxWtCbuCu6SVanWwpKFLlSqxEbnIJZ4T/sW 415yackaiMuOcYHH0M09fp868bntPT1uwW5dMXAt06k5KVUVGtCVGuQ24+tCUk4hBkRJJXDGeB7s mfsSvT9F65bU7Ry55mo5KVJqNyT2CeJaUOk4RMPqWpbizaQlrY0R5Mz6TFkuzWZzX0YsVclcr+bR tfQHFFQ9B1/XJL14NWhp3aT96VpdMaqikIqTEJlLDiULSfKOGeVbHG1YIuZZfLj6Lg1lmUXSO4r4 qOn1dpk2hSWo71Lqn+zk+a3m297TxJUlaC3n3SSPO3oMjGW1y14KrVsSZdGjV4T3IFsQoxVm3HnE VSNIbaQg2XIvcKLaZKwszVguYsGePqptk6tXZ1Ol/WrXzqqykyG1WvHrS0KqKmGXUukh5ZKxuUSE JLdjCtx97gW+72ZKFuiVVWrxvHjyPo7E0MJmtXhqn2PdT+xqv7hdc8rToM73O672Y65U0Wzldh97 yvPt47eYs8JOodUDKZu6yrbg2FIqUu7LcYrTCGKkgltLebdUljC0ElREbZEbhqSREZnjhg4K+Kle txdSirT2FpVejFSplPp8CW5IgklDio7rBGbCUqNx7JoI8kjaSdx54D97UtW6GeqD0Sqj1t1huBTb CjRJ8lcFwmor5RJaTadWacIWRqSW1RkeVEXjFZdkkQy4nGlVYVMehKqyMOJ1xGtXRqrUaBDtqkv2 TKk31cLbqo1uMT2j5M20mpe+SeEEkiLviI/HgjwY/wAtjWalyYN1IuyjTLVrNpx0yKxTnnUSDbbU jelTbjfBwj4EWMHxLhxIQXVQ6XLr2pts6gSrUqF30GFDXBrNIgOGmSbSeVW2tpKVIUoyU4ZmSVZP aksYMxNW/og3dFqX+dB07TYkKqQG4lCRUX5JVF7Y4zIPrhLjziG0G6yguCSVgz48MnZBIskUpRRO lcr6MeTL0dnbXQVbiqftr9qbXL16m24JcrTmsUShVRMRdLqbspl1L6eumVkbjaT3tbiSrBmRpPhx 7ohvuh35lbG/4cp/1ZsefL6n37XOpYd01b0ou1irUqBT4Mt1cUlMukw6wRHH2KNbxnsSZ7U4SW88 9yPROjkSVA0is2DOjPRZUegQWn2HkGhxpaY6CUlST4kojIyMj4kZC22KGCzKFJL+TyOuKix5WIcp hdv6oWrZTuuF02/p11rPoNaYbqivdp1fus65NfZ5TC0GTGDNa9qSMj3Y8RGKir6/VqmWTS78kaU1 krTkR2HZlROpMEpk3SSRE2yfduJ3q2ktRNkfAy4GQyCr2VeS7Y6o9lFpV9TlYr8N2mIKnPGqahNT eWpTJbfyiSSZKM05IiMj5hq2qlv16Z1D0O3odEqUispoNGaVT2oq1ySWhcY1pNsi3bk7VZLGSwee YbM2VZ8OGqrWJLG3kwYe3Q68CibN1otRh1ijwqvT3Sehzo7cmO4XMttaSUk/8yMh9YlNHIkqBpFZ sGdGeiyo9AgtPsPINDjS0x0EpKknxJRGRkZHxIyFWOFMhUMbS0GRAeSa7qlaNjt1xipzjkVErhrB lBjES3uNRkmW7xILiR90ZcObI9bDy3ULEta84NZZr9KafcK4ayTchHcPN/8AvKT3qy44+Q8l0kN2 xOUq8rWlVk7zq3Spzmxci1hYLy7UfHp1q5bVyW8dTrFWolCkKkOITDkVFtLiUEfcme4yM89OMCk7 PrE/bW2/pRn2h8unNh0uzLdOiMrKe0mQ4627IZTyhJUfemZFxx08PIQpfc6B+oxv4Kf/AEGac5GG 8BOmj9oSmQrVycPKNYWnF5M+aiV6hVwnTotZptTJnHKnElIe2ZzjO0zxnB8/QOkJOlMssaq1lDLL bSTocAzJCSIs8vM6CFYMMyFQvF2GxJjcUNYsuPcwAALDIAAAAAAAGm6WeDr3nSvVSKwSelng6950 r1UisE5sWbwbEec3rnkzaZpqr7/x/NU+uoSIrtVff+P5qn11CREVvTOo/wB0Im105nL2AAAaB0AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL7STvan5Wvti7EJpJ3tT8rX2xdia3Z msH7pPPr7z6Z3cEAABvHKPhuH3gqPmrvqGMUG13D7wVHzV31DGKCOX980Hf+CYezP0pm1AAAR8kx LWd4V3t87M/UIoqRLWd4V3t87M/UIoqRlnfN3LgjDI+V7XxYAAGIzAZr1S1UcpWkdQfjSXYstUmL 1q804aFtupfQ4SkqLiRlsMyMuJYGlDI+q0pxzdI3JJbi6wnsSDx8u5rj/FG1Yae8wV6UaV5NqyTK dD4HpClMrjUuJHdccccaYQhS3FGpajJJEZmZ8TM8cTMZRo3rPUNRIr9TOyHKTRIankzqkupIdbYN DaVpIk7ErUZkas8CJJEk8nnBa7HdS9HbeR3riCWWOgyyMR6m3TWvULRa4rNvWnKpztWmSkqbS+26 ZsOxmmjURtqMiPgssZzwHorrVUPHocHBbZ9dJ15ZlrpNWl2ZVIFoVmoFTqdW3JLSuUeNS090yR7k JyhXHJ8x9A7+qmpNXs1yWqn2LUKxCp7CZM+e7LbhR20GSjw0pwvyzhEnJoQR4yRZzwGKW11P1Uiy YNvVXTmgTEsyFKmXNIrck0SGN6sJRFadbUhzaaSIz7nuePHiLPWHTi/bn1OqMlMKn3BblRozkKAi dKJtqiPqSlJyCbwZuOEZLUlRFnusGadqRZWKhlcMvCxfu8607X6BKjWuzaVsTa5V7kjOSYsJ6SiG hBNrWhaVOrI07tzThERZztL9JOaJ/Vmn03SqRfdxW7XaCcdzkV02dEU1IU8eNqUbiLck8lhfNwPm MjIsjh6ZX21pNa1vVjTK37iaprcpEuDInpj1FtbkhxxK2JSHOTSgyU2ZpPj3CiPOSx3pGjd73F1O DdmXTW2pFxRZ3X8E3nlOJZIiNKWVucTVwU5x4kncRcSTkFFEHBL3l/YuqCq1eCrOuO15tr15cTr6 LGfkNvpfjmZkSiWjmVgsmky4YMs8BA0vqkZ87T+TeqNNZp0uDUExKg83VGzRHQrk8KLKEqWszcIt pJxzZUWeHdtOzLxuLWqFqbe9IhUFdIphwIcJiaUlTqz5UlPGpJERJMnV4TxPiWcYEHaulF/wepTu 2yJVA5O4KhV25MWJ14wfKNkqIZq3kvYXBpzgaiPuflIVbiChl1x9nqemKLUYtYo0KrQV74k2O3JY V0oWklJP/kZDI7x11etKpx369YVVp9tyJaordSkSW25ClEpRG4UQ/wApyeEGolHjJY4cSGj6aU2b R9OLZpFSZ5CbBpESNJa3Erk3EMpSoskZkeDIyyRmQ8v3rorqtWqBXIlRo0Cu1tNZKazX3J7ZSZzG 0kFHbQrBNNluU4aTUkiNO0kngjFY3FTEWSoYHE8LIbJWNYaoxqvcOnlFsOTW59JgplMrYqLbfLma GV4US0kTaS5XGdyj7ksJPOC/2ma7W9L0VkalOU+SyiM91q9AJwlLKT3OGyXgiMjJST3GRcDzjxD5 bOs26InVTXVfU2kKjUKpUZpiPIVIaUZukiIRo2JUaiMjacLOMdzz8SGdWvoZeEzqbKvZ1Zp7dNr6 K+dVp7TkltaV4Ybb4qbUpJZLlU8eY8GZeMUrFxL1DLxV7PU7bN63hVeqpsan1OJWbZjyaK6uXRF1 DlWFr5OWonDJB7F8yOJkRkaMGRbRtGqV6U7T+y5tz1Nl19qPtShlrgpxxR4SkjPm4+PxERjKIVra l1zqjbO1BuG1I1KgQqS5HlkxUWn+t1m3JIkq4kalGpxJ9ySiIlF3R4MytuqOsCVqNpnIolOU2mpR 5CJkInFbUKcSSkmkz8WUrWXHhky/yqq0ZbHguKFPIZwzet4VXqqbGp9TiVm2Y8miurl0RdQ5Vha+ TlqJwyQexfMjiZEZGjBkW0cuwtbOxLQl27/c24a9ylznTeTrVw9cvIzFS5uS9yBYQW3Gzbzmo88c ClhWtqXXOqNs7UG4bUjUqBCpLkeWTFRaf63WbckiSriRqUanEn3JKIiUXdHgzLOe0tqX/wBHHsR7 Gv8A312X+6XW3X0f/q/WfJ79/Kbe/wCGM58eMCz+WgzLk3ROmj8m3VnVqrU1VJpCrAnruutOvnTa L7oMkpUdsjUTzrveNmaSM9vdY2mRnwHStvVqh1KyLguWowpdIctt52PVoL21bjDzfOhJp4Lyfckf Dj0CT6obSaRd130S8oVBj3L1hHXEnUV6eqGctru1Nmh4u9Ula1H4s8M8MkPktbRVb2kV3UGVbtIt WfcRNm3FiTJEnkCZUbjCXnHHFkpRKPujbJJHx4HzFdWKpipLwUyos7VO4Lhjb1ab1OE5Ppr9RoJq mtLaqCEJI0JW4Rf7Ope5ON5Y485jFLL1Rvuq6B3lWbmbrcyFHloUmu0+stQZKHTeiJKK2lLajbLa s1mskmkyNSeBnktr0bY1QhR6LQrkoVMotFodNKAtaZiZLtQW2lCGnUEki5JOEmZkozM+gvFlNI0q 1Io+hF9aYlbTUtyVUGZtNnt1BkkzPysfckkKURowhk1ZUZZzgi4EZ0eEXQ4CbWLKjTj1QRQrNsKm 0ujVS47juKkMPQYDs5BvLSUdK1LekLIiM+le0smSjwXMEvW+nI0quK841CknPt2WiHUaPIfS0408 byGjLlEkojLujMjIuO0y4eKenab3fSZOml90Kkxp9wWvQGaZUKO9MSybpFHUgyQ73SCUlTjhZ5j4 HkyIcqpaPXf2oNRlKhRpF23lU2ZyoEeSnk2UJlk6TfKLNKTMiU6Znw8RcRWsRRQy8X7p8itpGuLj txWdArdkzaNTrtjtqps9ya24S3lEjuCQks7MuJIlK2meSPYRHw4OiVUffXeFBlOqddo1yzmUqWo1 LUhby15WZ5M1Gs3OIXdpzeU/tE9aUflOxXrX3a/2lkutdnWm7nX3eOSc7zd3vykOboXBM7z1OrxE sm59zSGm8lwMm3XVZLh/2v8A4Dj34q2V4WhqhIvZh4NuWBpTr++Bq4AAhR6OAAAAAAAAAAABrlge CMHyL9dQyMa5YHgjB8i/XUO3cX1otn5I/wC0maw/2XBndAAEoISBCat95TfK79gXYhNW+8pvld+w NG8s1jOrcmfS+/gyBEtql4KN/O1M+vsCpEtql4KN/O1M+vsCHyPqQ7UTu0fRj2PgVIAAxGYCq0B/ Nun56rH9TlCVFVoD+bdPz1WP6nKFJn0ntX5I97QfTg2svgGTdVhetyWFo5MrdrINM5clqMqVsJXW iFmZG7g+GcklJcD4rI8DKrTpeq1JnU66tPdY+23HdmoKsUg5TRJbZMjUvbyz5kgyzgiLYZGaeGCM iuk2JzJXKOJLQq10duRd5FXFR0PVwDzBPuqqM9U9q/S6tclyt23TbLdllFgTlEqLiNDUp2MhStiH iJSzSrBd0rPjMXli6n2RbOgFDu+XXbnmUmS68xDdrqyk1WW71w6nYewzJaspUScHwQlOcYCZYY4Y YWsdab1UKJGxgPK+r2q06uaoaOR6A9d1rlKryW6rSpzT0B15pb8Qkcq3na6gyNwiPKi74ukXSr5t eia86gctV79lT6Dbi6lPpjkltdIbYbZjOGcVo1EZPGRp4qwWVOceJCrsExQpvK03TY6FMNG3AMXj 9UhZkq0Y10wrdvWZTV7jlux6MbiKelK1JNT7iVcmngndglKPapJ444FhX9VrIounkG+5VWNyjVAk dYm00pTslS+9QhvG418DyR4xg84wMMVknQtJwvG6d5XCRcAMgX1Qdos1u2KHNt+7qdVLimJiMRJ1 L63djqWttCVuk4su4M3OCkb+8V4ywejXvcUW0rRqlzTo0uTEpkdUl9qKlKnTQniraSlJI8Fk+Jlz C2OzzYGlEsuQrVM7IDOa/rNZlGXYxSFT3U3sbfuWppkjJCXOT2qdyojSWXUFwyfPw4GP8uzUS3ZJ 6hWrvr7Dts0NcqqzadsbcYS4wpZFHWas8uSMqSZkSSMi48BVWaa6fx/a044hhI0cBgdpa3WJaGnN gKkzL2qcG55EtiFUKypqRLRycrYtUpZLLuSU4W3YSj2JLhksHXUTW61ahfES0ZlJuihTageKa7WK Q5EanHjJ8kau6+Tukp4mRFnJC+OxToa/xdFXdiZTCRpwDOLt1ktWgXkq0WoNwV2rsIS5NZotMXM6 yQoskp3bxIsY4ERnxLgM16mO+5FUvrWmq1u6Zsy3qbVCfhOTZbi2IkXlZh5QSzw2jYlPAiLgkugh WGxzHKimNUSo9tXQYSrQ9IgMbidUbYjr7D8mmXXT6DJcJqNcMykLbpryjMiIidzkuOeJpIi2nkXE e/qG7qTLsFSJbNUj0tNVS6tCeQejmokmpCiUZmZGeDIyL5M4GOOzToPmhaK4SZWAMopOvtiVPSqt 6kR0VZNHo0rrR9tcdJSFuGbZJ2J34MlcqjGTLx5xgxqECR13BjyyZdZ5ZpLnJukRLRuLO1WDMsln B4MxZMkzJfzqmgJpn7gADGVAAAAAAAAAAAAwC1/7Os/8R1n+pSRv4wC1/wCzrP8AxHWf6lJGzJ+S Lavydu4M5f8AV8UdcAAXkuJeD+dis/MUD/XmCoEvB/OxWfmKB/rzBUDJNyrYuBhkfK9r4sAADGZg AAAAAAA03Szwde86V6qRWCT0s8HXvOleqkVgnNizeDYjzm9c8mbTNNVff+P5qn11CRFdqr7/AMfz VPrqEiIremdR/uhE2unM5ewAADQOgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BfaSd7U/K19sXYhNJO9qfla+2LsTW7M1g/dJ59fefTO7ggAAN45R8Nw+8FR81d9Qxig2u4feCo+a u+oYxQRy/vmg7/wTD2Z+lM2oAACPkmJazvCu9vnZn6hFFSJazvCu9vnZn6hFFSMs75u5cEYZHyva +LAAAxGYCY1OpsKsWuzSKkzy8KdV6XGkt7jTvbXPYSpOSwZZIzLJGRinHIu2FOnUppNMRGXLjz4U xtEh1TTa+QlNPGk1pSo05JsyztPBnzDPZYlBPgiiyJria1ugijs0yGHK4XTwNPhRmYUNmHHSaGWG 0ttpNRqMkpLBcT4nwLnPiP1Ge9l99fsfbfpE/wDgg7L76/Y+2/SJ/wDBCdc62PrEeW8w3j1T3eZo QDPey++v2Ptv0if/AAQdl99fsfbfpE/+CDnWx9YhzDePVPd5mhAM97L76/Y+2/SJ/wDBB2X31+x9 t+kT/wCCDnWx9YhzDePVPd5mhAM97L76/Y+2/SJ/8EHZffX7H236RP8A4IOdbH1iHMN49U93maEA z3svvr9j7b9In/wQdl99fsfbfpE/+CDnWx9YhzDePVPd5mhAM97L76/Y+2/SJ/8ABD4GtRLycuGT Q02ZQCkxojMtajuF7YaHVuoSRH1nnOWlZ4eMv8qq9LI/9RFHcV4KlZT3GogM97L76/Y+2/SJ/wDB B2X31+x9t+kT/wCCFOdbH1iK8w3j1T3eZoQDPey++v2Ptv0if/BB2X31+x9t+kT/AOCDnWx9YhzD ePVPd5mhAM97L76/Y+2/SJ/8EHZffX7H236RP/gg51sfWIcw3j1T3eZoQDPey++v2Ptv0if/AAQd l99fsfbfpE/+CDnWx9YhzDePVPd5mhAM97L76/Y+2/SJ/wDBB2X31+x9t+kT/wCCDnWx9YhzDePV Pd5mhDHtOoUan0WfFiNcm03XKqhJZMzwme+ksmfE+CSLJ8eA7/ZffX7H236RP/ghzbShToNKeRUk Rm5cifNmONx3VONo5eU68SSWpKTVgnCLO0uJcw41+W2RPkQwy4quv4ZJPZm7LVZLTFHOgaTh/KOu AAIuTcAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4vrRbPyR/2kzWH+y4M7oAAlBCQITVv vKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIltUvBRv52pn19gVIltUvBRv52pn19gQ+R9SHai d2j6Mex8CpAAGIzAVWgP5t0/PVY/qcoSoqtAfzbp+eqx/U5QpM+k9q/JHvaD6cG1nN6oe5LztagU 2p25asO6KOqVyNfgLhrkPnGVjum0pURcxKI9yVl3STMiIjz5gqsq0b3vW3n9BNOrltq7YlWbOVMN jkokdsiUSyWlDikp4mW7O3KSUR5zge7wGWzW5SIKKHHtxPatJFIoanju8f8A4ltff/25lfU4Y4tJ otXV1O+iF7RIk2oUq1q9Jl1WHFbNxRtHUTVyuwj47SaUnmPHKeIsj28Ayq9GoYUoclNPRC4ejTXu KYB5C1zvqgX5rFofUraTNfpzdwoJM56E7HQ8o5MQzQjlEpNW0sGZkWO7LBnxH4Xj/wDEtr7/APtz K+pwx7EAWwXjDAlDDBiSay9MVegrgVPNej6Ul/7P+ee0uNu1wz4c575XH/wIZrSaNV1dTvohe0SJ NqFKtavSZdVhxWjcUbR1BSuV2EfHaTSk8x/2niLI9vCP1Msydd0aAql3jcFrT6e8bzMimSDShw+H cvNGex5OUkeFF0lzKUR3SrwWG21SsTi8U1Tfl3FHBiPOeut8UK+tYtDqnbbc56nJuBGyc/CdjofN UmIZpRyiUmrbwMzItvdlgz4j1nU4bFRpsqnykEuPKZWy6ky4KSpJkZf8jGWUDSCsv3pRrt1E1Cm3 lUKEtxdLbKmMQWGFLJJGo0N53H3JHnJcxdA1wYLXNluGXBLfyp723pS4IrCnjqeELdti4rmt286f VVSTqGlVGVApDqGiychqY5IJ1JbeCuTYS2REZ9zg/GNV04KfWepj1V1Eq7eydeEWrTiQZcWmER3G mm88NxJ2KweCyRl5R6aAZpt5uYqYNMafmu94woKHgqjpSq0epdSoiUk7inEZGXAy91WBsXVbEXbr 0IPHHsjP6zCHpMAivLCmwzMHJhadavZoqMDFQ8xWRWY+j2v+pPZ4mqIYuya1Mos9uA9JRITueVyC eTJatyScJJF/2fiLAhNNaNV70pvVKUuiRJUOpVCe24zEMkpdJRSZbhsGR8CMyI0GXymPbACivGib UP8AJ4OOuL+LVMVOzpGAePLwvqkXX1M1N0boVJrMi/EwKbBeo/uW8h2MtlbJrcWakklKT2c+f75Z xxHY6peDcmm9n2DdNNkOzKpAojtq1B5KcrfU9E2ocMz3HlLiFLIuOVYLPHj6rAUhvBQxLBgxVbab y1VHoyDAPGEyxKhbOr9uaMU1DpW/X10mszjU2RoPrJpwpCTIiL+0U0lajzwVt4HnA9ngA17VaorR g1WReL6eHgVhhoAABqlwAAAAAAAAAAAGAWv/AGdZ/wCI6z/UpI38YBa/9nWf+I6z/UpI2ZPyRbV+ Tt3BnL/q+KOuAALyXEvB/OxWfmKB/rzBUCXg/nYrPzFA/wBeYKgZJuVbFwMMj5XtfFgAAYzMAAAA AAAGm6WeDr3nSvVSKwSelng6950r1UisE5sWbwbEec3rnkzaZpqr7/x/NU+uoSIrtVff+P5qn11C REVvTOo/3QibXTmcvYAABoHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvtJO 9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpndwQAAG8co+G4feCo+au+oYxQbXcPvBUfNXfUMY oI5f3zQd/wCCYezP0pm1AAAR8kxLWd4V3t87M/UIoqRLWd4V3t87M/UIoqRlnfN3LgjDI+V7XxYA AGIzAAAAAAAAAAAAAAAAAAAAAAAS8H87FZ+YoH+vMFQJeD+dis/MUD/XmDJLyRbPyjDN+aDb+GVA AAxmYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADXLA8EYPkX66hkY1ywPBGD5F+uodu4vrRbPyR/ 2kzWH+y4M7oAAlBCQITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIltUvBRv52pn19gVIl tUvBRv52pn19gQ+R9SHaid2j6Mex8CpAAGIzAculwbho8d2JRb7r9NhLkvyUxmo8BaG1vOrdWSTc jKXjetR8VHjOB1AFyiaMM6zyp6SmQ1ofLy17fGZcn8lTPwgcte3xmXJ/JUz8IPqAMPsXgvI1+bLJ qI+Xlr2+My5P5KmfhA5a9vjMuT+Spn4QfUAYfYvBeQ5ssmoj5eWvb4zLk/kqZ+EDlr2+My5P5Kmf hB9QBh9i8F5DmyyaiPl5a9vjMuT+Spn4QOWvb4zLk/kqZ+EH1AGH2LwXkObLJqI+Xlr2+My5P5Km fhA5a9vjMuT+Spn4QfUAYfYvBeQ5ssmoj5eWvb4zLk/kqZ+EDlr2+My5P5KmfhB9QBh9i8F5Dmyy aiOQ1WrtcrsijJ1NufrqPFalLzBpm3Y4pxKcH1pz5aV/4D7eWvb4zLk/kqZ+EHBg/nYrPzFA/wBe YKgZI3gvElkWheRjlXdZYk24FlfE+Xlr2+My5P5KmfhA5a9vjMuT+Spn4QfUAx4fYvBeRk5ssmoj 5eWvb4zLk/kqZ+EDlr2+My5P5KmfhB9QBh9i8F5DmyyaiPl5a9vjMuT+Spn4QOWvb4zLk/kqZ+EH 1AGH2LwXkObLJqI+Xlr2+My5P5KmfhA5a9vjMuT+Spn4QfUAYfYvBeQ5ssmoj5eWvb4zLk/kqZ+E Dlr2+My5P5KmfhB9QBh9i8F5DmyyaiPl5a9vjMuT+Spn4QOWvb4zLk/kqZ+EH1AGH2LwXkObLJqI +Xlr2+My5P5KmfhA5a9vjMuT+Spn4QfUAYfYvBeQ5ssmoj5eWvb4zLk/kqZ+EH50KmlSoCoxzJM1 xyS/KekSCQTjrrzy3XFGSEpSWVrVwJJEQ+4Acbap+EjLJsciRFhS4aMAAC02SXg/nYrPzFA/15gq BLwfzsVn5igf68wVAyTcq2LgYZHyva+LAAAxmYAAAAAAANN0s8HXvOleqkVgk9LPB17zpXqpFYJz Ys3g2I85vXPJm0zTVX3/AI/mqfXUJEV2qvv/AB/NU+uoSIit6Z1H+6ETa6czl7AAANA6AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAF9pJ3tT8rX2xdiE0k72p+Vr7YuxNbszWD90n n1959M7uCAAA3jlHw3D7wVHzV31DGKDa7h94Kj5q76hjFBHL++aDv/BMPZn6UzagAAI+SYgIdxU6 3LxuxqrM1Rs5VQZfYUzSpL6HEdZx0ZJTbak98hRc/ORjpdsS2OmtfQM77kVoDM45cWNp+Poa6lzY aqGJUq9HS69JJdsS2OmtfQM77kO2JbHTWvoGd9yK0BTClar8fQuwZ2svB/8A0SXbEtjprX0DO+5D tiWx01r6BnfcitAMKVqvx9BgztZeD/8Aoku2JbHTWvoGd9yHbEtjprX0DO+5FaAYUrVfj6DBnay8 H/8ARJdsS2OmtfQM77kO2JbHTWvoGd9yK0AwpWq/H0GDO1l4P/6JLtiWx01r6Bnfch2xLY6a19Az vuRWgGFK1X4+gwZ2svB//RJdsS2OmtfQM77kO2JbHTWvoGd9yK0AwpWq/H0GDO1l4P8A+iS7Ylsd Na+gZ33IdsS2OmtfQM77kVoBhStV+PoMGdrLwf8A9El2xLY6a19AzvuR89p1Fit6hVmqwGZxQvcm FHJ2TBej7nEuylKSROoSZ4JaT4cOItQFcOBJqFPH2+hTk5jiTiiWLs9WAABhM4AAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAGuWB4IwfIv11DIxrlgeCMHyL9dQ7dxfWi2fkj/tJmsP8AZcGd0AASghIE Jq33lN8rv2BdiE1b7ym+V37A0byzWM6tyZ9L7+DIES2qXgo387Uz6+wKkS2qXgo387Uz6+wIfI+p DtRO7R9GPY+BUgADEZgAAAAAAAAAAAAAAAAAAAAAAPzkPNR47kh9aW2mkGta1cyUkWTM/wDIfoBk RkZGWSPxYAGYwL/sk9TanLK6KSbD1IhMNOFIThbiXpRqSXSZEtHD/eIacPO9p6OJp/VAyn3I5e4E Ak1KGWO5Upaj5Nv/AOhRKPyITnvh6IG5bYJUMUPJuuJHPu+OfHDFy0NMb4/tAAANM6AAAAAAAAAA AAAAAAAAAAAAAAAAAAAAS8H87FZ+YoH+vMFQJeD+dis/MUD/AF5gqBkm5VsXAwyPle18WAABjMwA AAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNpmmqvv/H81T66hIiu1V9/4/mqf XUJERW9M6j/dCJtdOZy9gAAGgdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC+ 0k72p+Vr7YuxCaSd7U/K19sXYmt2ZrB+6Tz6+8+md3BAAAbxyj4bh94Kj5q76hjFBtdw+8FR81d9 Qxigjl/fNB3/AIJh7M/SmbUAABHyTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAABrlgeCMHyL9dQyMa5YHgjB8i/XUO3cX1otn5I/wC0maw/2XBndAAE oISBCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gyBEtql4KN/O1M+vsCpEtql4KN/O1M+vsC HyPqQ7UTu0fRj2PgVIAAxGYAAAAAAAAAAAAAAAAAAAABmREZnwIvGAA55vzqnUXKRbzbb0psyKVK cIzjwiMs93jG5eOJNkZGfAzNJGSh/tKjT7tVimPOQaIR4cqSSw5J6Ux8l3vS6fD9DJ90nQaPTIFH pzVPpkVuLFaI9raC8ZnkzM+c1GeTMz4meTPiJFdlyObSZPVF0dJEL69pYZFZNldYtL0LZ0smFadU UoGW3ZCa0R8p7smZHKNePGeMG3/2WNmOYiMiMuIiTNgVFNHr7LcacrPW7zeeQmERZNTZnzKwWTbP uk4Pvk90emj4q3SqfWqc5T6nGRIjuYM0nkjSZHklJMuKVEfElEZGRlkjId23XVJtUFEqNZGv3IRe 7L9tFimNt4ULyp8dpHgPgqjNQtR0m6w6uZSFK2s1Q0kRtZ5kSMFhPyOERJPmPaeN33iEWqyzbLHg TEemWK3SbbK5SS6retoAAGubYAAAAAAAAAAAAAAAAAAAAAAAAAEvB/OxWfmKB/rzBUCXg/nYrPzF A/15gqBkm5VsXAwyPle18WAABjMwAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeu eTNpmmqvv/H81T66hIiu1V9/4/mqfXUJERW9M6j/AHQibXTmcvYAABoHQAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAvtJO9qfla+2LsQmkne1PytfbF2Jrdmawfuk8+vvPpndwQAA G8co+G4feCo+au+oYxQbXcPvBUfNXfUMYoI5f3zQd/4Jh7M/SmbUAABHyTAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABrlgeCMHyL9dQyMa5YHgjB8i /XUO3cX1otn5I/7SZrD/AGXBndAAEoISBCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gyBEt ql4KN/O1M+vsCpEtql4KN/O1M+vsCHyPqQ7UTu0fRj2PgVIAAxGYAAAAAAAAAAAAAAAAD4qpUWoR tMpadlTJCjRGiMFl19XQkuYiLxqMySkuJmRC6CCKOJQwqrZbMmQy4XHG6JH7VCZFgRHJcx5DLLZd 0tX/ACIi6TM+BEXEz4EP7o9sy7k2y7ijuRKTztUtfByQXiVI6E/9l0d/zmhPTti0nETG61campVS bPdHjt5OPB4f3MkW9zxG4ZEfOSSSRnmuEwuy5YZNJk7HF0aF6nnl9e0kVorJszpBpel+SP8AEpSh JIQkkpSWCIiwRF8g/wBABICJAAAAfy62h1pbTqErbWk0qSoskZHzkZeMZ9WLdm2zulUNh6dRS4uU 9BGp6IXSwXOtH/Zc5F3mSIkDQwGvabLKtMGBMVUblit06xTVMkuj3PaZ3Blxp0RuXDfbfjuluQ4g 8kZD9x9lzWm8mW9WrZ5Fic4rfKhrPaxNPpMyL8m7/vkXHmUR8DTx6XUWZ6XUJQ7Hkx1bJMV5O11h f6Ki/wDEjLJGXEjMjIxB7wuybY4qvHD0+Z6ddN9SbxgosUayry6UfYAAOadgAAAAAD8Z65LcJ9yH HbkSUtqNppbnJpcWRcEmrB7SM+GcHjoAN0P2ASunt6Q7st5+pORzpkqE64xUYbrhKVEcQZ7iUrBc MFnOC/8AATT+rDhaf1++I9tm5SKdJSxAWqZtVPI3ktKcIuTPYkjVw77ODLhgZ1ZpricNMaaXe8hr O2SVCo3Fiab05Fl/e7KaeAw+LrZecuK1Ki6MV9+O8gnGnW3HVIWkyySkmUfBkZcSMhb3ZqNEtezq NWavSJyalVkNExSWkmp/llpI1Nnki4pM8HwI84LGTwL47HOgahaxvtT4MsgvCzxwuJRYl0prii5A ZbZGryqvc0a3Lms+rWrUJu7rMpZKND2CzjKkIMj5/EZcOfJkQ1IYpsmOS6RqhmkWiXPhwpbr+9oA AGIzEvB/OxWfmKB/rzBUCXg/nYrPzFA/15gqBkm5VsXAwyPle18WAABjMwAAAAAAAabpZ4OvedK9 VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNpmmqvv/AB/NU+uoSI0u9bYnVuptSor0ZCEMk2ZOKMjz uUfiI+kcLtf1f9ag/vq9kcG32C0TbRFHBDVPZ0Eou28rLKssEEcaTSJEBXdr+r/rUH99Xsh2v6v+ tQf31eyNPmu1anDzN7nax9YiRAV3a/q/61B/fV7Idr+r/rUH99XshzXatTh5jnax9YiRAV3a/q/6 1B/fV7Idr+r/AK1B/fV7Ic12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q/61B/fV7Ic12rU4eY52sf WIkQFd2v6v8ArUH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/rUH99Xsh2v6v+tQf31eyH Ndq1OHmOdrH1iJEBXdr+r/rUH99Xsh2v6v8ArUH99XshzXatTh5jnax9YiRAV3a/q/61B/fV7Idr +r/rUH99XshzXatTh5jnax9YiRAV3a/q/wCtQf31eyHa/q/61B/fV7Ic12rU4eY52sfWIkQFd2v6 v+tQf31eyHa/q/61B/fV7Ic12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q/wCtQf31eyHNdq1OHmOd rH1iJEBXdr+r/rUH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/AK1B/fV7Idr+r/rUH99X shzXatTh5jnax9YiRAV3a/q/61B/fV7Idr+r/rUH99XshzXatTh5jnax9YjoaSd7U/K19sXYmrHo EuhFLKU6w5y+zbyRmeMbufJF0ilEpsEuKVZ4YI1RohV7TYJ1rjjgdU6cEAABtnOPhuH3gqPmrvqG MUG4VRhcqmSorZpJbzK20mrmIzSZcRnva/q/61B/fV7I4l72WbPcHJw1pUk9wWyRZ5camxUqyRAV 3a/q/wCtQf31eyHa/q/61B/fV7I43Ndq1OHmd/nax9YiRAV3a/q/61B/fV7Idr+r/rUH99XshzXa tTh5jnax9YiRAV3a/q/61B/fV7Idr+r/AK1B/fV7Ic12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q/ 61B/fV7Ic12rU4eY52sfWIkQFd2v6v8ArUH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/r UH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/rUH99Xsh2v6v8ArUH99XshzXatTh5jnax9 YiRAV3a/q/61B/fV7Idr+r/rUH99XshzXatTh5jnax9YiRAV3a/q/wCtQf31eyHa/q/61B/fV7Ic 12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q/61B/fV7Ic12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q /wCtQf31eyHNdq1OHmOdrH1iJEBXdr+r/rUH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/ AK1B/fV7Idr+r/rUH99XshzXatTh5jnax9YiRAV3a/q/61B/fV7Idr+r/rUH99XshzXatTh5jnax 9YiRAV3a/q/61B/fV7Idr+r/AK1B/fV7Ic12rU4eY52sfWIkQFd2v6v+tQf31eyHa/q/61B/fV7I c12rU4eY52sfWIkQFd2v6v8ArUH99Xsh2v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/rUH99Xsh2 v6v+tQf31eyHNdq1OHmOdrH1iJEBXdr+r/rUH99Xsh2v6v8ArUH99XshzXatTh5jnax9YiRAV3a/ q/61B/fV7Idr+r/rUH99XshzXatTh5jnax9YiRGuWB4IwfIv11CR7X9X/WoP76vZFzbEB2l0ONBf UhbjW7JoM8cVGfjIukdW6bHOkTInMhpiOJftus9os8MMqJN1/DOkAAO+RQCE1b7ym+V37AuxCat9 5TfK79gaN5ZrGdW5M+l9/BkCJbVLwUb+dqZ9fYFSJbVLwUb+dqZ9fYEPkfUh2ondo+jHsfAqQABi MwAAAAAAAAAAAAQHVDT59L0erk6mTZMGW11vyb8d1TbiMyGyPCk4MskZl5DHm/ssrkKDFmUPV2v1 OsLjtKVTnmZKi5ZZpJTKDWa0rUnJ5MySR4LaZmeC6Fku6K0wYULpjppOVbr2gsczAihrirlXTTJp PYD8uXJqPuPRIyZdS2kpw1ZJmKk+Zbqi5vkQXdKxwwRGpNdalsRaETklx1c6qPpIpM51JEtZc5IS RcENl4kFw8Z5UZqODlXomwaRatqUu0H6leFdi9c+5LElLeXibJTy3X3PHkld0rJntPOMDrW5q1RK lY9wXLUYMykuW287Hq0F3atxh5vnSk0nheT4EfDjkS277uk2NdMWl+R5/e972i8YqZINC/L6TRAG Gta91JNQsiNP07lU9q75iGob7tTbNJMLcaSh4iSgzMzJ3JoVtMsFxMjyXboGsXur2z//ALOcj2B8 v/8Ard3X3J9cf9mXJ55D/exu+Tj08NHGcqNaDVwHnKu6plczmjlf62uGkdkNXea60ptd5FkuTlss 4kJ5E+uEHz7e4wRqLPHJd7TvX166LcqF0TrIkUq3qWT3X9QKooeJtSEIUhCEbUqWtZqxjBEnue6P dhNMNFXJiSqbeAye0NZHKpcNAptes2oW9GuZpT1AmOymnky0Egl5UlHFszJScEeecunhKUrqkJ8/ T6TeyNNZh0uBUExag83VWjRHQrkyJRbkJUtZm4RbCTjmM1Fngw4SnJR9B6DAZJG1tYO77bplQtOp U2jXTgqJVX5DR9dGeCIzaSZqQk97eNx57su5IfFU9e48c6rWIVm1SfZ9Hn9YVCuNyWk8m9uSnuGT PctOVp45LnLhxFcNDkoug2gcC67XjVpSJsd46fV2Emlia2jcZJ59jieHKNmfOk/Kk0qwZRd5avOU PVOh2NTLVfri6xTOv478aYhtR5J40pJC0knB8kRmo1pwSjPHDjC33rjcFT0buqfQKG/b9y0GpswK q2ctp06clTpp5VJmnDm5SDawSSMjUaiySciyZgRwuGJVRkkqbLjUcDo9DNBjTJDNQOkVmKUGqJSa iQR7mpCC53GVYLcnmyXBSclkiyRn94zOZqXIa0btBF8WZLlVytGwxRiTU2yVLUTLW2ackiIoylqd 5j7osnnJZx0bCu2vvtvwr1tasUB+PIKMiXMYMmH1GZkkuVJJNqMzLBKT3KjwZbdyUnD7yuhyazJO OHo0r0PQ7m9oFaEpVpxR6Hofr+9hdgADhEnAAAA8/a90hynaiUaNR5z1PZvtaaZV0NEWFkl1pPKF /vGlwyP5M9Jiv6oGnQ6R1PlXplPYSxFitRGmm0lwSkpDREKq8rHpN1V23qxUJE5qRQJXXMVLC0pQ tW5tWFkaTMyy2nmMuc/8vtvq2YF4WtMtypuyWYkvZyi46kpcLYtKywakmXOkvFzZHQhtUP8Ag1/y vH4+Ry4rFF/j0XzKi71j2Y6sxiy6Br49Z1Feo97UCNTV09hUNlxhJrbZNtJoSo+tz4knBHxPymLP WaBbNxVqg29KuFyh3Sy717RZBRlKIlFkzLdt2c7ZHjcR5SnpIj4f/RpsT4WuT+YZ+5FvcGmFpV61 qTb9WiPSWaRGRHhyOU2voSlBI4qSREeSSWSxjJcwyzbRJcxRwxdOSFLLxMEmy2hSYpcUPRlibWLo 1duwz9dVum29R7WoGo7FuXS3NkKRTaiiGnruK5uRtXjbhHdGjmLxZ3dyN0Gd2Do1ZVm1RuqwGJky e1nkpE14lm3ngZkSUpTnHDOMjRBqWuZLjawNHZTdoN6wypsuGLlNLxY6tYtLxVAAA1TdJeD+dis/ MUD/AF5gqBLwfzsVn5igf68wVAyTcq2LgYZHyva+LAAAxmYAAAAAAANN0s8HXvOleqkVgk9LPB17 zpXqpFYJzYs3g2I85vXPJm0AADaOeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gyBEtql4KN/O1M+vs CpEtql4KN/O1M+vsCHyPqQ7UTu0fRj2PgVIAAxGYAAAAAAAA/KZJjw4rsqW82ww0k1uOOKJKUkXO ZmfMP1HMrlNdmuQpcZ1tEunvlIjofRyjC1kR4JxHj6SUWFJMiMj4C+VDDFGlG6LpMc6KOGW3LVXo WSpK6tWleV/aXVdihwFsodJk4UF3Y0/Nw+gzUvlDImkEklKJJmSzMizt71X5VnSKs0rT6zrgsKkU +j6gUCFF66aaS0hM9XJJS+06ojJC1biM95mecHx4kZbDalzxq5ykV5hUCqx0kqTBcVlSS5t6FYIn GzPmWXkMkqI0l3h6FY7NIlSkpOTp6e08kvC3WqfPbtGKJaOjs2GBa1aX1W+qvbF9u2i1U5kSCceq 23IqfWynU4WpKUSG1GkjStajznB8M8MkP9tfRZx3SG7qDJtyj2rPuImzbixJkiTyBMqNxgnnHHFk pRKM8m2SSPjwPxb4Im/dV7AsSsNUi6q97nTXo5SW2us33ctmpSSVltCi50KLGc8PINlwwrGzSUyN pQo873pHvGn3PoLRbuosSlLpVTZgRyZmE+p9LT0RBuq2lhBKIkYTkz5845ir5Gnmo9BuLVmHQreh VWl3rHfeZnOVFDJsrWT58kTZllSzN9SSztSWCM1c5DQadV9H9X69R58Ooxa1VbfdVMp6OVfjux1E tszc5I9hqLchvvkmXN0jThRQJ6S6Ka0kqftanlynaUX+zQdEozlBNLtsVeTJrCeu2P8AZm1zm3Uq zv7vKEmeEbj4Y5+A7OkOj1xl1Ol06fXbDKjz6pUVyI+XkOknDbBtrM21GWOUa4lnOCPgPRQC5S0W ufE1T96TzNpbotPp922+7VNM6HSE0Q2npVYVXJMpyc+3hSHGGkOpS0e9OTJxJp48CwWB8tq6UX/B 6lO7bIlUDk7gqFXbkxYnXjB8o2SohmreS9hcGnOBqI+5+Uh6Ou+46NaVvSrguCZ1lTImzlnuSW5s 3rJCe5QRqPKlJLgXj/5fVRqjCrFHhVemvcvCmx0SYzu00721pJSVYMiMskZHgyIxTAhyFXOjy/uI wi7tObyn9onrSj8p2K9a+7X+0sl1rs603c6+7xyTnebu9+UhHK6nup0eoz6NF0+otyMyZ6nINdm1 p9luFGPb+TdjtuIWsyIlERpPOT48B6zAHLTKKfElRGHy9OK9D6o2wq/S6QgrXoFvFTXZCH0kllSW pSEoJC1m6ovyjZZ7rn4nwMxLI0fvWoU7WynvwGoPZRVGZVHddkNqTIS3Lee47VGaMkaC7oixu5uB 43W377tOvT6/BplYbcft102qtyjS2kxVEayPKlpJJkRtL4kZl3Oc4wPitTVHT+6q05RrfuiDOntm f5FO5JrwWTNBqIiWWPGnIYMPSV5SNaMn/ZnFTte/aropa1Bnac25PepLKIk+j1SYS3nm2m0tpdjS GlkllxREvnM9u4uPA89vqeLIum37YrlNvNhtulT5JnTqG/K69KBHMjI2lOHlKk4NKdpcO5M+dR41 0BVQKtSxzW1Qzmr0adae5+ImRUbfTxNvunJEAvk51OtF/mtP+8XefrGfYlR25MZ5t5l1JLbcbUSk qSfMZGXOQoLsuhiirRBiRzqFXeTuYhoVtwnm5RxWD5NvP94yyeDJJKPgM0Oxo8mRImzqxWWZUp1T zzdMqL8KMlaufk2m1ESSzxMzyozMzMzMxEb6stllRpwukTypcew9A9mrdbp8pwzIcKFZIm6d3aV4 CS7Aab8OXb6RTPvA7Aab8OXb6RTPvBw8GXrPw9SUYc7VXj6FaAkuwGm/Dl2+kUz7wOwGm/Dl2+kU z7wMGXrPw9RhztVePoVoCS7Aab8OXb6RTPvA7Aab8OXb6RTPvAwZes/D1GHO1V4+hWgJLsBpvw5d vpFM+8DsBpvw5dvpFM+8DBl6z8PUYc7VXj6FaAkuwGm/Dl2+kUz7wOwGm/Dl2+kUz7wMGXrPw9Rh ztVePofrB/OxWfmKB/rzBUDh23a9NoMuVLivVGTJkoQ249OnOyV7EGo0pI3FGZERrUeC6THcFJsS cWLsKyYYoYf5ZavewAAMZlAAAAAAADTdLPB17zpXqpFYJPSzwde86V6qRWCc2LN4NiPOb1zyZtAA A2jngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQmrf eU3yu/YF2ITVvvKb5XfsDRvLNYzq3Jn0vv4MgRLapeCjfztTPr7AqRLapeCjfztTPr7Ah8j6kO1E 7tH0Y9j4FSAAMRmAAAAAAAAAAAPiqlNZnck5yjsaXHUa40pg9rrCulJ48fjI8kouBkZcB27Zux3r tqi3ITMaoLPbGlNkaWJvyJz3jvjNszPPOk1ER7fhH4T4cafEciTGEPsOFhSFlkj8ZeQyPiR+IyHS u+85tjioscPR5HGva5ZN4wVeKNZH59KNEHlHqlo9ZldVDa0e37cpNx1NVA/I02qNoXGfwqWat6Vq Sk9qSUosqLikvINso1xzLa2xbgkOzKMXBqprPc7FLokfpIL/ABecv7/Max0Klp7QqrqnR9S3Jk/3 UpkJUWO204jrZbaidLcothqM8PK4koi4F8omsi0S7XLUct4uB5taLJOu+c4Jyo9zMP6nKgzLh1im 3dVYFtWrPt1hdPft+ixVRVcoreXKOt5MjLCjwojURmlPNtEozqPqTdLFauiiJ1JdrkeqKapsOmU0 naOyyRoM2ZCSIzN0kmfiM+9490ePTcnTihL1QZ1EiSJ9PrKWOt5KYq0JZmIxj8sk0GajwSeJGR9y noLHDrmh1l1asSpjj9biwZsrrufSIs9TcCY9wPe41jieSI+BlxIZcB0xGFTYW6sndWLgk1g7VpCK /ddJrNZppSmrZoRIiVFx1SSWanX3DwyhBJcI0ngzMlcT2mRZPa2q1+V/TW0rekV+cxLrd1qo71YZ IkyG4xJjcOU8ThnIPCufCOfgY9HXxpVa12VikViSdRptQpLZsR5NLlHGcNgyUXImpJZ2d0rgWDLJ lnBmQ48fQix49qz7baVVUQpFUVVYykSEpdp8g0kklR1kgjSRElJESt3elnIq4YmykMyBKjI7XOiV a3+pzvml1C7ZNxxWZEIoS5qkuS46OXj5Q84RFvPOTIzLOD4mfil6bUrnsOo6HyIt3VqfDumLFiS6 dKcR1qy0aY6EJaQlJbTSl/vjyozQWTGzSNHbXfsCs2e/NrbzdadaeqNSemctOkLbUhSVKcWky/8A lpLG3GM4Is5H6VfSS3Kn2CcvNqyOwjkvc3k3Wy5Xk+R28tlHdf2CM7dvOrm4YOB5RDMhSo/3Eec2 dR9SbpYrV0UROpLtcj1RTVNh0ymk7R2WSNBmzISRGZukkz8Rn3vHujxqWoVz3Hc2p2nFjsT69aUa uU46pUFxS63kJWTS3CY3GR4Uk2zJSDIy7os5FbXNDrLq1YlTHH63FgzZXXc+kRZ6m4Ex7ge9xrHE 8kR8DLiQ7l+ab27d6qQ9KXUKZLoy90GXS5Bxn2U4IjQSyLJJMiIuGDLxGQKGIOZBVURi/U40CFXb y1tt64DXUosirIZlq5RTSn8Py8mZtmkyyZZMiwXHHMO3RbPqN16ywG1UKZbNo6cqJiikqO82uoKz jcl1f9o2RskZ4M8kZZM95mNI000xt/T+rXDUaJJqbrldfS/JRLeS4ls0qcURIPaSsflVd8aj4Fxz kx+lkaf0Cxq9ddxwZs5TtxSuvp/XbqDaZUS3VnswlO1P5VXfGfAi484qoMSqUimJttFmI25bsfdl vUa2OSdmNKNEqctO5iGfjSX+I7/uEeE86jLgk+bV7hnXQao1FefgUM+C5yDND8wuhnxttn/id8f9 zBYWP9hRY0KI3EhsNsMNJ2obQnCUl8hDg3nfSlVlSMcXT0epJ7k9mop9J1qVIdC0vb0I/Gl05ino cNCnHn318pIkvK3Ovr5ty1Y4n4iLgRERERERERfYACIxRRRtxROrZ6DBBDLhUMKokAABaXAAAAAA AAAAAAAAAAAAAAAAAAAAAAABpulng6950r1UisEnpZ4OvedK9VIrBObFm8GxHnN655M2gAAbRzwA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAITVvvKb5Xf sC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIltUvBRv52pn19gVIltUvBRv52pn19gQ+R9SHaid2j6Me x8CpAAGIzAAAAAAAAAAAAAAADLJYMh8FLfqFpLNVKZXMopnl2mJPu4/SqNngRdLR4I/7ppPJK+8B s2W1zbLHhy36mnbrBJtsrk5yqt62FjRqpArFOaqFMkokRnM7VpyWDI8GRkZEaVEZGRpMiMjIyMiM uH2DMlR51NqK6xb7qGJi8HIjuGZR5hFwwvBHtXjgThFksFklEW0WlrXHBr7DpNIcizY+ClQnyInW DPOMkXA0ng8KSZpPB4PgeJxd95SrZDixRaUeY3tc067o8eOB5H59DOyAAOiccAAAAADiXVcsOgtt NG25MqMjPWsFjHKO451ceCUFksrVgiyRc5kR2xRwwQuKJ0SL5cuKZEoIFVs+2uVan0SnOVCpyUx4 6DIs4NSlKPgSUpIsqUZ8CSRGZnzEIGpO1C6nUu1lg4lKSolsUszIzWZcy5BlwUfjJsspSfE9xkRp NxZk6oprFeeRJnpI+QaRnkIaT50tEZcTxwNw+6V/ulhJfeIhed9RTay5GKHp6fQ9CuX2bhs9J1pV YtC0LzYAAEeJaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABpulng6950r1UisEnpZ4OvedK9V IrBObFm8GxHnN655M2gAAbRzwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAITVvvKb5XfsC7EJq33lN8rv2Bo3lmsZ1bkz6X38GQIltUvBRv52pn19gVIlt UvBRv52pn19gQ+R9SHaid2j6Mex8CpAAGIzAAAAAAAAAAAAAAAAAAAHw1GnFIfZmxpDkGpRs9bzG SLejPOkyPgpB4LKD4Hgj4GRGX3ALpcyKXEooXRosmyoJsDgjVU9B07Vus5kpFHrjTUGsYM29meQl kRZNbJn48cTbM9yePfFhR1QzmpQYtRinGltb0ZJSTJRpUhRHklJUWDSoj4kojIyPmH1UO6ZdFdRT rof5WGoyRHq6iJJEfiRIIiIkK8ROFhKuY9p43TK7L5htFJc7FFufqedX17OR2Ws6z44OjSvNF4AG ZERmfAi4+QQNaueXX1Lg2zIVHpxGaX6sjBm70pjZLB/K6fAv7u4+6R17RaZdmgw5joiP2OxTrZNU qSqvhtOldF2Kjy3KLb7bMyrJ/tlryceFkskbplzqxxJsjJR8Mmkj3DgUynIiOPSnXnZk+SZHJmP4 Nx4y5uYiJKSyeEpIkl4iH7U6DFp8RMWGyTTScnjJmZmZ5NSjPipRnkzMzMzMzMx9Ag943pMtkVMk PR5npt0XJJu6GuWN5X5AAAcw7YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAabpZ4OvedK 9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNoAAG0c8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACE1b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+l9/BkCJb VLwUb+dqZ9fYFSJbVLwUb+dqZ9fYEPkfUh2ondo+jHsfAqQABiMwAAAAAAAAAAAAAAAAHAZvK2nr zfs5upp93WEE45ENpZHt2pXwUadpntUR4IzPGeg8XQwxRVoshbFHDBTCdK4u874DiTLroES74dpS J+ytTWTfjxuRWe9BEszPcSdpf2a+BmR8PlIfJd9/WfaTpM3BXosJ80krkcKcd2meCPYgjVj5cC5S o20lC8ZbFPlQptxKiy48hTD+XG0ONqbcQlaFkaVJUWSMj5yMhzbbuGh3JBObQqpFqDCVbVLYWStq sZwoucjx4jHUFjThdHlL4YoYlVOqJBhqQ9ccyyXJ0lVuRIEeYmCZ5JXKuPI5E1Y3GyXIkZN5x3W3 vCJJVyEpQgkISSUpLBERYIiExB/OxWfmKB/rzBUDYtM6ZNaw3WiXA1LFZ5UmGLk4Uqt1ptAAA1jc AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANN0s8HXvOleqkVgk9LPB17zpXqpFYJzY s3g2I85vXPJm0AADaOeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gyBEtql4KN/O1M+vsCpEtql4KN/ O1M+vsCHyPqQ7UTu0fRj2PgVIAAxGYAAAAAAAAAAAAAAAPNFzUipVPqlLylUNZorNJpjNRpxYyS3 W24pcmZZLJLQpaOP6Q9LjPKFY1Wga7V++3pEJVNqNPRGZaQtfLJUSWCyojTtIvySuZR85fLjdsU5 SnG3q/lYjn3hZ3PUuFL/ADKvZieMz9u4IV09Urp9X6ef5CZQFr25IzQrZMJSDx40mRkfkH1dT1QK Jece5buuqixajVpNZdaUie0T3IJJCFEgkrLBY3mnmLgki8Q7cPSadTdeY9806VCRRUm64uKpaydQ 4404lRISSdu01r3c5d8rh0/zXNMbxo9xVOtaZXc1RyqbvLSYMtrezyhmZqUkzSsi5zPG3hzZxgi3 I50qKHAlxUrCsePFjbo6bTnS7PPhi5SbBhUiiqsWOqSTVdj8Tn0+BDs7qoYdHtuEUWnVmjKdmRmM pabUnlTJe0uBcWkkXNjeeOfjuAzrTTTmbQbhm3ZdFecr1xS2uR5fZsbZb4ZSlPlIuOCwXAiLjnRR oWuZDHEqOtEk30nUsEqKXBFhKlW2l0Lu8e8l4P52Kz8xQP8AXmCoEvB/OxWfmKB/rzBUDDNyrYuB nkfK9r4sAADGZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTdLPB17zpXqpFYJPSz wde86V6qRWCc2LN4NiPOb1zyZtAAA2jngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAQmrfeU3yu/YF2ITVvvKb5XfsDRvLNYzq3Jn0vv4MgRLapeCjfztT Pr7AqRLapeCjfztTPr7Ah8j6kO1E7tH0Y9j4FSAAMRmAAAAAAAAAAAAAAAAAAAAAAAAP8WpKEmpR klJFkzPgREAJiD+dis/MUD/XmCoEfBmwi1VrCzlx9p0OARK5QsZJ+ZwFgMs5Ua2LgYZDrC9r4sAA DEZgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADTdLPB17zpXqpFYJPSzwde86V6qRW Cc2LN4NiPOb1zyZtAAA2jngAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAQmrfeU3yu/YF2ITVvvKb5XfsDRvLNYzq3Jn0vv4MgRLapeCjfztTPr7AqRLape CjfztTPr7Ah8j6kO1E7tH0Y9j4FSAAMRmAAAAAA49i2jalw1u8plftii1aS3W22kPTYDT60IKnw1 EklLSZkWVKPHNkzPxjeu+xe+zXLwqYq9Jy73vJXdIU5w4VXTLTp29B2AHS7WmnHxf2p9DR/YDtaa cfF/an0NH9gdr4afWbvUjnxnD1P/AC9DmgOl2tNOPi/tT6Gj+wHa004+L+1PoaP7AfDT6zd6j4zh 6n/l6HNAdLtaacfF/an0NH9gO1ppx8X9qfQ0f2A+Gn1m71HxnD1P/L0OaA6Xa004+L+1PoaP7Adr TTj4v7U+ho/sB8NPrN3qPjOHqf8Al6HNH8PtNvsuMvNpcacSaVoUWSURlgyMugdXtaacfF/an0NH 9gO1ppx8X9qfQ0f2A+Gn1m71HxnD1P8Ay9DyLaOjzrGv8ijymFroVLUVRStZZJ1kzyygz8ZmojSf Tyax6oHS7WmnHxf2p9DR/YDtaacfF/an0NH9gbVquWZaWnHNyKmT1NKxe00myKJQScrr827JoOaA 6Xa004+L+1PoaP7AdrTTj4v7U+ho/sDV+Gn1m71N34zh6n/l6HNAdLtaacfF/an0NH9gO1ppx8X9 qfQ0f2A+Gn1m71HxnD1P/L0OaA6Xa004+L+1PoaP7AdrTTj4v7U+ho/sB8NPrN3qPjOHqf8Al6HN AdLtaacfF/an0NH9gO1ppx8X9qfQ0f2A+Gn1m71HxnD1P/L0OaA6Xa004+L+1PoaP7AdrTTj4v7U +ho/sB8NPrN3qPjOHqf+Xoc0Bx76tG1LerdnS6BbFFpMlytuNOOwYDTC1IOnzFGk1ISRmWUpPHNk i6B2BxbwsXuU1S8KuKvQSO6LzV4yHOUODR0y16NnSAABonUAAAAAAAAAAAAAAAAAAAAAANN0s8HX vOleqkVgk9LPB17zpXqpFYJzYs3g2I85vXPJm0AADaOeAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCat95TfK79gXYhNW+8pvld+wNG8s1jOrcmfS+/gy BEtql4KN/O1M+vsCpEtql4KN/O1M+vsCHyPqQ7UTu0fRj2PgVIAAxGYAAAAP60l98L2+f0f06EP5 H9aS++F7fP6P6dCHe9nc6f8AV8URb2uzGH+y4MuwABNDzYAAAAAAAA/l1aGm1OOLShCCNSlKPBJI uc8j+hlXVWXam09GqqbbhomVXFNjYMyPLhHvMjLmw2Sz8uBRuiqXQw4TSRodAuCg3BHckUCt02rM tK2OOQZSH0oVjODNBmRHjjgf1S65RKrMnQ6XWKfOk09zkpjMaShxcZeVFtcSkzNCspUWDx3p9HDy /wBTNcFn21rI5aVpVxdTo9dpLCuVW263tnsoM3Cw4kj7oicVnm7pJEfDArupd/O/rX8/l9YmCyGO tDLHKwa9htlw3Nbdu8h2QXBSaP1xu5Dr6Y2xym3G7bvMs43JzjmyQ+WkXzZVYqLVOpF4W9UJrueS jxaky66vBGo9qUqMzwRGZ48RGMB6uFLa7k01Q7SHay2qZKJVOaUpK5hb4uWUmgjURr70jSRmWeHE floXCpLOqlHcjdTtcNoOly+2sSp85xuN+QczlLrZIPcXccT51cOOAw3hUClLk8LyN5b1J06cWltu /rVUtR4SlNXjmZmfNjuucdGtXXa1EZjPVm5aNTG5ZKOMuXOaZS8ScbjQajLdjcnOObJDwFp4/bcG zpU24dI5l0NdfG0Vb91pEONHNSUEllRoTyZGRnuyoyPuy8WB6a0g0NpM3SSiUrU2mpqkmK9IlQmU TXEphtv7DNBKZWklZNBKPirBqPBikMbiyF0yTDBlZq0PUKwZsxmHDvi2ZMl9xLTLLNVYWtxajwlK UkrJqMzIiIhTDyj1GGnNm3FaC7urNH65rVMr59ZyeuXkclyTbDiO5SokqwszPiR58eSHq4XwNtVZ imwwwRUQAAFxjAAAAAAACF1a98LK+f1/06aP4H96te+FlfP6/wCnTR/AhftFnS/quLPSfZDMYv7P ggAAOCSkAAAAAAAAAAAAAAAAAAAAAA03Szwde86V6qRWCT0s8HXvOleqkVgnNizeDYjzm9c8mbQA ANo54AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEJq3 3lN8rv2BdiE1b7ym+V37A0byzWM6tyZ9L7+DIESerTzMazOuZDrbLLVTprjjjiiSlCSnMGajM+BE REZmYrB/LiEOINDiErSfA0qLJGIZLiwI1F0E+mwYcDh6UTvZ9Yn7a239KM+0HZ9Yn7a239KM+0O3 7nQP1GN/BT/6B7nQP1GN/BT/AOgvrK6H4+hZSd0rwfmcTs+sT9tbb+lGfaDs+sT9tbb+lGfaHb9z oH6jG/gp/wDQPc6B+oxv4Kf/AECsrofj6Ck7pXg/M4nZ9Yn7a239KM+0O7olUIFUVeU6mTo06I5X 08m/HdS42rFPhkeFJyR4MjLykY/n3OgfqMb+Cn/0HK0ZrudTNQLTj05CI8SVGnnKQ7gtzsRhsmyQ SeH9io858eMeMdy4HB7y8GuR8URn2rUz3JYTXzLg+01sBzqvXqFR5UOLVq1Tac/OWbcRqVKQ0uQr JFhslGRrPKklgs98XSP4cuK3m6GivLrtLRSVluROOW2UdRceJOZ2nzH4/EJhU86ozqAPxiy4kuGi bFlMPxVp3oeacJSFJ6SUXAyHxUa4rfrTz7FGrtLqTsZRpfREltuqaMuBkokmeD8oqUodMByqfclu 1CqPUqn1+lS6gxxeisTG1vN/95BHkv8AMh+1SrdGpkqPEqNXp8KRJPaw0/JQ2t0+PBJKMjUfA+bo FKlaM+8QOo2m0e+LxtmrVee07SKGp1xykOxCdblrWWCNZmrGCwXA0n4y4Z4VtWrtDpEuFEqtZp0C TPc5OG1JkoaXIXki2tpUZGs8qSWCz3xdI/qj1qjVkpB0irQKiUZ02X+tZCHeRcLnSraZ7VfIfEHR 4mVTcONEBeOjNuVGo2/VLVjUq0ajRqk3N64gUtCTfQnnaUSDRwPhxMzwWSxxEXUup4uTswuG4Lf1 cq1ve7dQdmvswYjjffuLWlKlIfTv271ERmRc58CyY3mqVCBS4Ls6pzY0GI0W5x+Q6lttBdJqVgiH xHc1tlQVXB2QUkqOjG6f1431unJkRflM7eJmRc/OZC1wwl8M2NZDI7x0Hrdy2zZ1PlamVD3WtlyU 6VXciLckPrddS4hRGbxKQpvYkiPcZ8CxjGB0NOdI71ti8oFcq+slw3FCjcpytOlJe5J7c2pBZ3Pq LuTUSuKT4pLm5y02Dcluzp7NPg1+lSpj8cpTMdmY2txxkyyTqUkeTQZGXdFwHw3xd9JtejVSS7Lh O1KFTJFQapqpaW3pCWW1LPaXFWD243Ek8ZDBhyjlI2sEkdKdHKfZumNZsOrVMq/Bq0l159fW3W+E uNNtmki3q4lyeSVkuJ/Jkd/SCzajYVpJtuZca65FjOqOC45G5Jxho+JNme9W4iPOD4YLhjBFj99I rx7P9PKZd3ud7m9f8t/s3Lcryex5bff7U5zszzFz/JkfRfF30m16NVJLsuE7UoVMkVBqmqlpbekJ ZbUs9pcVYPbjcSTxkVShSqUicbbhZwdBtNe1ZaEu3/dr3X64qC5nL9a8ht3Nto27d6s/2ec58fNw GgjI7f1jl1q37ErEe2aey3dUx6O63JuBhhcQm5JM7m0uJSqSo8mrYgslgi51ENCZu21Hqg5Tmbmo rk1qSURyOie0biHz3YaNJHklnsX3PP3KuHA8IWqYhGoq1iO0A5zFdob9YdozFZpztTaLc5DRJQp5 BceJoI9xcx+LxD/a1XKJROQ92axT6b1w4TTHXclDXKLPmSncZblfIQrUsozoAM91O1btqwrht2h1 NROSK28lO9L7aG4bJuJRy7xqPKUd0oyPGD5NfEsD7LdvxVa1KqFrxYdJcpkentzY1SjV2O+7IStL KiPrVH5RCDJ3gs+5MiSZd+kUwlWhXAipUtgHwMVujP1Z2kMVenu1FktzkRElCnkFx4mgj3FzHzl4 h80u6rXiT5tPlXJRo8yAzy8yO5ObS5Gbwk97iTPKE4UnieC7oukhWpSjJ3Vr3wsr5/X/AE6aP4HG 1kuWnMyNO57L8eVS5lew3NYeJxs1ORJDTe00kZKJRu99nBbf+XZEM9ol/wDphfZ+WekeyDXuUS/8 nwQAAHBJSAAAAAAAAAAAAAAAAAAAAAAabpZ4OvedK9VIrBJ6WeDr3nSvVSKwTmxZvBsR5zeueTNo AAG0c8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACE1 b7ym+V37AuxCat95TfK79gaN5ZrGdW5M+l9/BkCAAIUeggAAAAAAAGd9TCqS5q3q6uakkvlUYyUd PJkqSSP/APUkDRBN6M0GdF1c1FuFCopUyU/EibCUrlSfbitOGrG3G0yf585znh4x3vZ5/wD6Wuwi 3tcv/wASfb5kt1WsKLUdTtHqdOZQ/FlVlxl9pZZStCn4iVJMvGRkZkOV1SdOl03VawocSFaUO12I b6IjNdbNFIbkYcNaXUoIkpLbye0v0ufhkej6pQ6LVZkKZVKPT50mnucrDekRkOLjLyR7m1KIzQrK Unksd6XRw/arUynVaEuDVafEnxV9+xJZS62rn50qIyMTBwVqeewzaJLoPMem7zVu6LanTqr7k3Tb ipalpp1urlssJWtRpeaQ4tCMMFlvumzWRIJRmZ8MxNsSaZL1utyezOo9NptWtiWua3bEQ2EwCVDk qUwZNGanH2y2KM8bt2zhkiHtKFTadBpqKbCgRY0FCOTRGZZShpKMY2kkiwRY8WB8Ea1LXjKgqjW1 RmFU41Kgm3BbScU1YJRt4T3Bngs7cZwXQKcnkKqcseLKeS9JF2hQb8sikIat28WH5zhUmtUY5EOp xV78mqYyW01J3HgicyRNko8mnJDoXadBO79cO2SVNKs9Z/8A2b69xv2bHuR6338d39hnZ493iyPV MG27dgVV6rQaBSolQeLDstmG2h5flWREZ/5mP1qVEo1SlR5VRpECY/GVuYdfjIcW0fHik1FlJ8T5 ukFLxBz1Wp5LvCLVZtK6nSFdza3ZUictp9DudymVSYpNkrPHJtGjOfHkXWlUOHQurIvyhUWJHp1K KitOlDjNk20le2IeSSRYLi4s+H6RjeapQ6LVZkKZVKPT50mnucrDekRkOLjLyR7m1KIzQrKUnksd 6XRwMUOiR67IrzFHp7VWkNk0/ORGQmQ6gtuEqcItyi7hPAz/ALpdBYqoMdSjnVVNvGplHVQ12i0p FpQqtb8CouVCpG1Gl1U1KptOUZEhTz7eSS4ZJcMySrhhKzyWOPnulfkdJNdYLM2PJiNVGmrjqitk 1HcSqcvDrTZGZIQpJIMiLht2lkyIh7gq1LptXhnDq1OiT425K+RkspdRuSeUq2qIyyR8S6B8Eq0b Ulde9c2xRXuv0NomcpAaV1wlvHJk5lPdknanBHnG0sYxwRQNuognKGGlP2p5er1Jplv1PqcanRYE aBOqXWvX0hhpKXJO4oZHvUXFXBxZceYlYH+3EVCK89dOz5NLKudZK7H+uccpyfJPcnyG/ju28ju2 /wC94sj1LItm3JHuZ1xb9Jd9yNvubvhtq6y27ccjlP5PGxGNuMbS6Cx/dSoFCqUpUqo0SmzJBx1x jdfiocWbKyMlt5UWdqi508x+MU5Mryy/dtTOupF/+Hm2P/5f1t4Y5cRUIrz107Pk0sq51krsf65x ynJ8k9yfIb+O7byO7b/veLI9X0imU2j05qnUinxKdCZzyUeKylppvJmo9qUkRFkzMzx4zMfhUqBQ qlKVKqNEpsyQcdcY3X4qHFmysjJbeVFnaoudPMfjFzhxJFqmpRN9J44pHgx1Nvz/ADP6myLLR6ho qWouutShU2JKuGn1GSdFeeaJSo8hbkzaaDxlJmpCOJYPBD0Yi0LTQ1TWkWvREt0pxTtOSUBoihrN RLNTJbfyajURKM044kR84+ul0OiUqZOmUuj0+BJnucrMejRkNrkLyo9zikkRrVlSjyee+PpMWqXj L4p6adF+1qeG7Pg1GRbNqFCq+ndJrsetm5HUtEtVdckpdcw3JJltauTM+kiLBIyZHnOxXl2Pl1V1 U7aHuV2Pdjf/ALo91NvIZy3u28p3PKbuXxjjzeMb+3b1Aaraq43Q6YiqqSaVTUxEE+aTPJlymN2M +LI/us0KiVomCrNHp9R63cJ1jruMh3kllzKTuI8K+UgUuiKRT03Wh5a1ng2YUrQupU6GkrYXJSw5 JqbXPCJ6OpKH1OFxbJKnTIldztNWOBmOvQ2n43VUals2kzFbkNWYSaS2ykiaSoo8ImSSSeBJztwR eLmHo+s0WjVqB7n1mkwKjDIyPreXGQ62RlzHtURlkh+cK3qBBq7tYhUOmRqk6yTDkxmIhDy2yJJE g1kW40kSEFjOC2l0FiuBjKKdip+5TxdC9yu1PYXYr1n20uyhfXG3HX2eUf8A7bH5TZ/Y53cO++Ua fSaBRbi6te+oFepcSpRE0NpwmJLROI3clCIj2mWMkSjx0c49DM0WjMVZ2rsUmA1UXU7XJaIyCeWX HgayLcfOfj8Zj/GKHRI9dkV5ij09qrSGyafnIjITIdQW3CVOEW5RdwngZ/3S6CxRSyrn1qeGKbLn q6lilHGWbsuJqClEFBn3p9abySXyb1Z/zHroTGsNk0ZqRYdLpFIplKpHZKcp+PCYSwS3kRXnEK2o SSTyTJkZnx4JLm5qcRL2hiSmwQdC4/8ARP8A2ThbkTJmhvh/2AABHyVgAAAAAAAAAAAAAAAAAAAA AGm6WeDr3nSvVSKwSelng6950r1UisE5sWbwbEec3rnkzaAABtHPAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhNW+8pvld+wLsQmrfeU3yu/YGjeWaxnV uTPpffwZAgACFHoIAAAAAAABxrPuimWxWbsj1eNW0KlVdEmOqPRJkltxvrGKjcS2mlJ75tZYzkjS OyA3bDbYrHMcyFVxUOdel2wXjJUqNtKtcXf5n1ds21f8O5PRipfcB2zbV/w7k9GKl9wPlAdb4kna i3nA+DrP1j3H1ds21f8ADuT0YqX3Ads21f8ADuT0YqX3A+UA+JJ2ot4+DrP1j3H1ds21f8O5PRip fcB2zbV/w7k9GKl9wPlAPiSdqLePg6z9Y9x9XbNtX/DuT0YqX3Ads21f8O5PRipfcD5QD4knai3j 4Os/WPcfV2zbV/w7k9GKl9wHbNtX/DuT0YqX3A+UA+JJ2ot4+DrP1j3H1ds21f8ADuT0YqX3Ads2 1f8ADuT0YqX3A+UA+JJ2ot4+DrP1j3H1ds21f8O5PRipfcB2zbV/w7k9GKl9wPlAPiSdqLePg6z9 Y9x9XbNtX/DuT0YqX3Ads21f8O5PRipfcD5QD4knai3j4Os/WPcfV2zbV/w7k9GKl9wHbNtX/DuT 0YqX3A+UA+JJ2ot4+DrP1j3H1ds21f8ADuT0YqX3Ads21f8ADuT0YqX3A+UA+JJ2ot4+DrP1j3H1 ds21f8O5PRipfcB2zbV/w7k9GKl9wPlAPiSdqLePg6z9Y9xx7wuimXPWbUj0iNWlqiVdyS+qRRJk ZttvrGW3uNbrSU984gsZzx/5dgAHJt1titkxTIlTFQ7913bBd0lyoG2m64+7yAAA0jogAAAAAAAA AAAAAAAAAAAAAGm6WeDr3nSvVSKwSelng6950r1UisE5sWbwbEec3rnkzaAABtHPAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhNW+8pvld+wLsQmrfeU3 yu/YGjeWaxnVuTPpffwZAgACFHoIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGm6WeDr3nSvVSKwSelng6950r1UisE5sWbwbEec3rnkz aAABtHPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA+ GrUinVUmynxie5LOzu1JxnGeYy6CH3AKRQqJUaL4JkUuLCgdH2HC7ELd+DS/ir9oOxC3fg0v4q/a HdAYvd5OqvBGf361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/i r9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrI vFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB 7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2I W78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XY hbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5Oqv BD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v 4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS /ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/Wr rIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB2IW78Gl/FX7Q7 oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4XYhbvwaX8VftB 2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5OqvBD361dZF4s4 XYhbvwaX8VftB2IW78Gl/FX7Q7oB7vJ1V4Ie/WrrIvFnC7ELd+DS/ir9oOxC3fg0v4q/aHdAPd5O qvBD361dZF4s+Wl06FTI5x4LJMtKUazTuM+OCLPE/kIfUADKkkqI1444o3hROrP/2Q== --_004_3349FECF788C984BB34176D70A51782F16B13702FRMRSSXCHMBSB3d_-- From ben@niven-jenkins.co.uk Tue Nov 16 08:47:32 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB833A6B69; Tue, 16 Nov 2010 08:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.681 X-Spam-Level: X-Spam-Status: No, score=-103.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTTcmZeD1CKN; Tue, 16 Nov 2010 08:47:31 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by core3.amsl.com (Postfix) with ESMTP id 305E43A68F2; Tue, 16 Nov 2010 08:47:31 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-105-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PIOha-0007HL-2j; Tue, 16 Nov 2010 16:48:14 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 16 Nov 2010 16:48:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1081) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Ingemar Johansson S , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 16:47:32 -0000 On 10 Nov 2010, at 22:08, Mikael Abrahamsson wrote: > On Wed, 10 Nov 2010, Mike Hammer (hmmr) wrote: >=20 >> 3) The people that build and operate the networks will double = (quadruple?) their investments for no additional return out of the = goodness of their hearts. >=20 > No, they're going to do it because if they don't give the customers = what they promised, their customers are going to leave. This is if there = is a functional market and customers actually have a choice of = providers. I realise this is not the case in parts of the world, but = that doesn't mean we should solve that by technical means, that's a = political and regulatory problem, it doesn't have any technical = solution. >=20 > Let's not forget that if you're congesting your core and distribution, = you're not delivering what your customers have purchased. Period. >=20 It depends what the customer has purchased. Many times what the customer = *thinks* they have purchased and what they have *actually* purchased are = not the same. > Everything else is just smoke and mirrors. >=20 > Congestion is acceptable on the customer access, it's not acceptable = in the core. That means that any flows/pakets that should yield, are = within a single customer domain, and thus in the customers own interest. I used to work at a large PTT. Our design was to make the core = non-blocking (i.e. does not drop packets except under multiple failures) = and constrain the backhaul[1] (and to a lesser extent the access line = itself). Your sentence above seems to ignore the backhaul? Which is strange as = the backhaul is a significant proportion of the overall cost and larger = than the cost of the core itself. Ben [1] The bit that transports & aggregates many access connections into = the core.= From ben@niven-jenkins.co.uk Tue Nov 16 08:59:31 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BC03A6DBF; Tue, 16 Nov 2010 08:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.672 X-Spam-Level: X-Spam-Status: No, score=-103.672 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eu-G7dTo0Fe; Tue, 16 Nov 2010 08:59:30 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by core3.amsl.com (Postfix) with ESMTP id 2E2C33A6DBD; Tue, 16 Nov 2010 08:59:30 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-105-devlan.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PIOtB-0003xX-9Z; Tue, 16 Nov 2010 17:00:13 +0000 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 16 Nov 2010 17:00:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6631D123-D319-4CF6-B299-FD8CFD17EB0B@niven-jenkins.co.uk> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <002a01cb81e1$40e58740$c2b095c0$@com> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1081) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: httpstreaming , conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 16:59:31 -0000 Mikael, On 11 Nov 2010, at 20:57, Mikael Abrahamsson wrote: > On Thu, 11 Nov 2010, Toby Moncaster wrote: >> There is also the issue of fair allocation of upgrades. Obviously if = an ISP spends a lot of money on increasing their backhaul then this = money has to come from the customers. However as things stand the 20% of = customers grabbing 80% of the network will also grab 80% of this = increased capacity, so they are being even more heavily = cross-subsidised. Clearly cross-subsidy is always going to happen to an = extent so long as you have flat fees for access (even if you put in = tiered fees, there is still cross-subsidy). But this should not be = excessive else customers suffer. >=20 > With global transit prices in the few dollars per megabit/month, the = actual bandwidth cost per user even if they averaged 1 megabit/s/user at = peak, is still not a major cost for the service which usually is in the = several tens of dollars per month. Please cite evidence to support this assertion. At least for the ISPs I = have worked with & for the margins are pretty thin and while = Transit/Peering costs are not the largest cost they are not = insignificant. We saw large scale "streaming events", e.g. day long = sports event broadcast on the Internet, had significant (localised) = impact to the Transit costs and if they were permanent (e.g. your = average 1 Mbps / user at peak time) they would have made a significant = impact to the bottom-line. Ben From singer@apple.com Tue Nov 16 10:02:39 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02CCB3A6CE7; Tue, 16 Nov 2010 10:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zp+dEVSFxkX; Tue, 16 Nov 2010 10:02:38 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 5F2783A6ACF; Tue, 16 Nov 2010 10:02:38 -0800 (PST) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 53305BD99C65; Tue, 16 Nov 2010 10:03:22 -0800 (PST) X-AuditID: 1180711d-b7c86ae000000247-9a-4ce2c76ab440 Received: from singda.apple.com (singda.apple.com [17.197.20.4]) by relay13.apple.com (Apple SCV relay) with SMTP id C1.0F.00583.A67C2EC4; Tue, 16 Nov 2010 10:03:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Singer In-Reply-To: <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Tue, 16 Nov 2010 10:03:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <663377F3-630B-428F-92CC-775CC63B816B@apple.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Johansson S , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , Ingemar@core3.amsl.com Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 18:02:39 -0000 On Nov 11, 2010, at 10:43 , DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) = wrote: > Now think on Internet. You are playing a Real-Time game and your = neighbours are just downloading files.=20 I am downloading a critical file that will enable me to respond to an = urgent legal issue I have; you are merely playing games. You can wait. I paid the same as you for my bandwidth, so I should get at least fair = treatment, if not preferential -:) David Singer Multimedia and Software Standards, Apple Inc. From hmmr@cisco.com Tue Nov 16 10:09:12 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F633A6D8C; Tue, 16 Nov 2010 10:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.677 X-Spam-Level: X-Spam-Status: No, score=-10.677 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrDqIQsOhIRI; Tue, 16 Nov 2010 10:09:11 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8595D3A6C89; Tue, 16 Nov 2010 10:09:10 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYEAANY4kytJV2c/2dsb2JhbACUII5AcaR5myiFSwSEWokQ X-IronPort-AV: E=Sophos;i="4.59,206,1288569600"; d="scan'208";a="182858842" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 16 Nov 2010 18:09:53 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id oAGI9rXB010035; Tue, 16 Nov 2010 18:09:53 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Nov 2010 12:09:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Nov 2010 12:09:52 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuFrXy27IEAx05lRCSpS4xFl5NZUAAC8SYQ References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><6750274E2CC345C18EDE9FDDD59F24FA@china.huawei.com><3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com><1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com><01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> From: "Mike Hammer (hmmr)" To: "Marshall Eubanks" X-OriginalArrivalTime: 16 Nov 2010 18:09:53.0885 (UTC) FILETIME=[77FF38D0:01CB85B9] X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: dispatch@ietf.org, Kathy McEwen , httpstreaming , conex@ietf.org, Ingemar Johansson S , Mark Watson , "GARCIA ARANDA, JOSEJAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 18:09:12 -0000 Marshall, It is over-provisioned if a large percentage of time, the majority of capacity is sitting idle, versus time-shifting applications flows that can be time shifted. FEC does absolutely nothing to solve the latency and jitter issue. Mike -----Original Message----- From: Marshall Eubanks [mailto:tme@americafree.tv]=20 Sent: Tuesday, November 16, 2010 11:43 AM To: Mike Hammer (hmmr) Cc: Mark Watson; Kathy McEwen; dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) Subject: Re: [httpstreaming] [dispatch] Q-HTTP On Nov 10, 2010, at 10:05 AM, Mike Hammer (hmmr) wrote: > Nice theory. Until it gets down to who is going to pay for the > over-provisioning. It is a mistake to call it over-provisioning. (Anything needed for proper performance I would call proper provisioning.) And, of course, the customers pay for it. (It is interesting that no one ever seems to ask who pays for QOS.) It is a question of where is it better to put resources, and I think that there is a long history to show that in many (not all) situations it is better to put resources in provisioning than in QOS.=20 I also think that a modest amount of FEC would go a long way to address concerns about real-time traffic, and I surprised that this is not already used routinely.=20 Regards Marshall=20 >=20 > Is the ARPU going to go up? Are content distributors willing to pay > more to send that data? >=20 > Also, note how the volume of traffic always seems to expand to fill the > BW available. >=20 > Mike >=20 >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mark Watson > Sent: Tuesday, November 09, 2010 11:19 PM > To: Kathy McEwen > Cc: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson > S; Lars Eggert; GARCIA ARANDA, JOSEJAVIER (JOSE JAVIER) > Subject: Re: [dispatch] [httpstreaming] Q-HTTP >=20 >=20 >=20 > Sent from my iPad >=20 > On Nov 9, 2010, at 7:01 PM, "Kathy McEwen" > wrote: >=20 >> One problem with the voice analogy is that the sheer volume of data >> traversing the web today is not driven by voice...it's video...and > it's not >> even a fraction of the viewing that folks are doing of broadcast > content. A >> solution that depends on "simply" having too much bandwidth, is that > someone >> is paying for it. Eventually it hits someone's pocket books....and if > there >> isn't sufficient revenue to cover the costs, the too much does > degrade. >> Today the mass media is consumed via cheap broadcast technologies... > why >> shouldn't the web (fixed and mobile) be as cheap AND as good?? =20 >>=20 >=20 > It should, the question is what is the cheapest way to do it. QoS is > expensive too. I tend to agree with the thesis below that history is > telling us that avoiding scarcity in the first place is cheaper than > rationing here. >=20 > ...Mark >=20 >> -----Original Message----- >> From: httpstreaming-bounces@ietf.org > [mailto:httpstreaming-bounces@ietf.org] >> On Behalf Of Lars Eggert >> Sent: Tuesday, November 09, 2010 8:02 PM >> To: David Singer >> Cc: Ingemar Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); >> httpstreaming; dispatch@ietf.org; conex@ietf.org >> Subject: Re: [httpstreaming] [dispatch] Q-HTTP >>=20 >> On 2010-11-9, at 18:31, David Singer wrote: >>> It is that there are two ways to solve a real-time bandwidth need. > One is >> to reserve bandwidth, manage QoS and so on; one gets protocols and > systems >> like diffserv, ATM, and so on. The other is simply to have 'too much' > of >> the resource. Though it feels wrong, the latter often ends up being > the >> cheaper and easier solution. So, for example, voice over IP is > getting used >> quite a lot, and to good effect, on the internet today not because we > have >> successfully deployed any bandwidth reservation or QoS management > protocols >> and systems, but because the available bandwidth is, for the most > part, >> greatly in excess of what is needed, and the systems can adapt in > real-time >> to what they get (rather than asking for what they want). The same is > true >> for multimedia delivery; the complexity of RTP + TCP friendliness + > QoS >> management is not worth it compared to having adaptable end-systems > and >> overall more bandwidth than needed. >>=20 >> Fully agreed.=20 >>=20 >> Folks who like pictures can take a look at >> https://fit.nokia.com/lars/talks/2008-mit-cfp.pdf, which gives much > the same >> argument. >>=20 >> Lars >>=20 >> _______________________________________________ >> httpstreaming mailing list >> httpstreaming@ietf.org >> https://www.ietf.org/mailman/listinfo/httpstreaming >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 From hmmr@cisco.com Tue Nov 16 10:46:12 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E0983A6E0E; Tue, 16 Nov 2010 10:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.669 X-Spam-Level: X-Spam-Status: No, score=-10.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUdAjgrKfTwS; Tue, 16 Nov 2010 10:46:11 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2D8273A6BA6; Tue, 16 Nov 2010 10:46:11 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYEAEFg4kytJXHA/2dsb2JhbACUII5AcaUAmyeFSwSEWokQ X-IronPort-AV: E=Sophos;i="4.59,207,1288569600"; d="scan'208";a="182871558" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 16 Nov 2010 18:46:54 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id oAGIks28010749; Tue, 16 Nov 2010 18:46:54 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Nov 2010 12:46:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Nov 2010 12:46:53 -0600 Message-ID: In-Reply-To: <663377F3-630B-428F-92CC-775CC63B816B@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [httpstreaming] [dispatch] [conex] Q-HTTP Thread-Index: AcuFuJnMe2hI9goRTouIbIDAqjwlKAABeetw References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <663377F3-630B-428F-92CC-775CC63B816B@apple.com> From: "Mike Hammer (hmmr)" To: "David Singer" , "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" X-OriginalArrivalTime: 16 Nov 2010 18:46:54.0681 (UTC) FILETIME=[A3B1CC90:01CB85BE] X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , Ingemar@core3.amsl.com Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 18:46:12 -0000 David, Let us be real. If your file shows up 1 second later, does it matter? Probably not. If my voice or video packet shows up 1 second later, does it matter? Yes, it gets dropped. Mike -----Original Message----- From: David Singer [mailto:singer@apple.com]=20 Sent: Tuesday, November 16, 2010 1:03 PM To: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) Cc: Mikael Abrahamsson; Mike Hammer (hmmr); dispatch@ietf.org; Ingemar@core3.amsl.com; httpstreaming; conex@ietf.org; Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) Subject: Re: [httpstreaming] [dispatch] [conex] Q-HTTP On Nov 11, 2010, at 10:43 , DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote: > Now think on Internet. You are playing a Real-Time game and your neighbours are just downloading files.=20 I am downloading a critical file that will enable me to respond to an urgent legal issue I have; you are merely playing games. You can wait. I paid the same as you for my bandwidth, so I should get at least fair treatment, if not preferential -:) David Singer Multimedia and Software Standards, Apple Inc. From singer@apple.com Tue Nov 16 11:39:20 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40BB23A6DD1; Tue, 16 Nov 2010 11:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAK9M2cPaAlx; Tue, 16 Nov 2010 11:39:19 -0800 (PST) Received: from mail-out4.apple.com (mail-out.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 65A983A6D91; Tue, 16 Nov 2010 11:39:19 -0800 (PST) Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id 6B814BDA2D67; Tue, 16 Nov 2010 11:40:03 -0800 (PST) X-AuditID: 11807134-b7c05ae000002d5d-15-4ce2de13a322 Received: from singda.apple.com (singda.apple.com [17.197.20.4]) by relay14.apple.com (Apple SCV relay) with SMTP id 97.69.11613.31ED2EC4; Tue, 16 Nov 2010 11:40:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Singer In-Reply-To: Date: Tue, 16 Nov 2010 11:40:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F 16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <663377F3-630B-428F-92CC-775CC63B816B@apple.com> To: Mike Hammer (hmmr) X-Mailer: Apple Mail (2.1081) X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" , Ingemar@core3.amsl.com Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 19:39:20 -0000 OK, so my example was slightly humorous. But in general I think the = claim that you can give preferential treatment -- preferential = allocation of bandwidth -- to certain traffic simply because of its type = is doubtful. =20 Remember, this issue only comes up when there is a shortage; and the = thesis that I should be short-changed more (treated worse) than you = because you are doing a real-time operation and I am not, is doubtful. On Nov 16, 2010, at 10:46 , Mike Hammer (hmmr) wrote: > David, >=20 > Let us be real. If your file shows up 1 second later, does it matter? > Probably not. >=20 > If my voice or video packet shows up 1 second later, does it matter? > Yes, it gets dropped. >=20 > Mike >=20 >=20 > -----Original Message----- > From: David Singer [mailto:singer@apple.com]=20 > Sent: Tuesday, November 16, 2010 1:03 PM > To: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) > Cc: Mikael Abrahamsson; Mike Hammer (hmmr); dispatch@ietf.org; > Ingemar@core3.amsl.com; httpstreaming; conex@ietf.org; Johansson S; > GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) > Subject: Re: [httpstreaming] [dispatch] [conex] Q-HTTP >=20 >=20 > On Nov 11, 2010, at 10:43 , DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) > wrote: >=20 >> Now think on Internet. You are playing a Real-Time game and your > neighbours are just downloading files.=20 >=20 > I am downloading a critical file that will enable me to respond to an > urgent legal issue I have; you are merely playing games. You can = wait. >=20 > I paid the same as you for my bandwidth, so I should get at least fair > treatment, if not preferential -:) >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 David Singer Multimedia and Software Standards, Apple Inc. From adam@nostrum.com Tue Nov 16 11:52:42 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763043A6CFB; Tue, 16 Nov 2010 11:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8TnawJD2ILC; Tue, 16 Nov 2010 11:52:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id EB1A23A6DED; Tue, 16 Nov 2010 11:52:39 -0800 (PST) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oAGJrCJZ053485 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 16 Nov 2010 13:53:13 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4CE2E128.9020207@nostrum.com> Date: Tue, 16 Nov 2010 13:53:12 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: David Singer References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F 16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <663377F3-630B-428F-92CC-775CC63B816B@apple.com> <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com> In-Reply-To: <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:17 -0800 Cc: dispatch@ietf.org, httpstreaming , conex@ietf.org, Johansson S , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , Ingemar@core3.amsl.com, "DIAZ VIZCAINO, LUIS MIGUEL \(LUIS MIGUEL\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 19:52:42 -0000 On 11/16/10 13:40, Nov 16, David Singer wrote: > OK, so my example was slightly humorous. But in general I think the claim that you can give preferential treatment -- preferential allocation of bandwidth -- to certain traffic simply because of its type is doubtful. I think you need to differentiate between "preferential" and "appropriate." For example, your gaming neighbor probably would dislike a policy of "deliver this packet with little regard to latency, but with a higher effort" approach. And you, in downloading a file, probably would dislike a policy of "deliver this packet with very little latency, unless it can't get there in time, in which case you should just drop it." /a From ben@niven-jenkins.co.uk Tue Nov 16 12:46:25 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B715F3A6E56; Tue, 16 Nov 2010 12:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooDOTio9Q5Kg; Tue, 16 Nov 2010 12:46:25 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by core3.amsl.com (Postfix) with ESMTP id ACA923A6E51; Tue, 16 Nov 2010 12:46:24 -0800 (PST) Received: from host86-156-248-113.range86-156.btcentralplus.com ([86.156.248.113] helo=unknown-00-22-43-25-f9-66.home) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PISQl-0006pf-KX; Tue, 16 Nov 2010 20:47:08 +0000 References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F 16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <663377F3-630B-428F-92CC-775CC63B816B@apple.com> <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com> In-Reply-To: <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Tue, 16 Nov 2010 20:47:06 +0000 To: David Singer X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: httpstreaming , conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2010 20:46:25 -0000 David, On 16 Nov 2010, at 19:40, David Singer wrote: > OK, so my example was slightly humorous. But in general I think the = claim that you can give preferential treatment -- preferential = allocation of bandwidth -- to certain traffic simply because of its type = is doubtful. =20 >=20 > Remember, this issue only comes up when there is a shortage; and the = thesis that I should be short-changed more (treated worse) than you = because you are doing a real-time operation and I am not, is doubtful. One solution that I have deployed in a previous life & that I know is = used by other ISPs is hierarchical shaping at the BNG. Each "subscriber" gets a "fair" allocation of bandwidth but they (or = their ISP via their service bundle) choose how to prioritise packets = within their allocation. You can then prioritise your download over your daughter's VoIP and Mike = can prioritise his VoIP over his daughter's download while you both get = the bandwidth you have individually "paid" for. Everyone's a winner :-) Ben From ben@niven-jenkins.co.uk Tue Nov 16 23:26:00 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8333A6898; Tue, 16 Nov 2010 23:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UymmjbC1RpX; Tue, 16 Nov 2010 23:25:59 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by core3.amsl.com (Postfix) with ESMTP id 35AF03A6897; Tue, 16 Nov 2010 23:25:59 -0800 (PST) Received: from host86-164-251-101.range86-164.btcentralplus.com ([86.164.251.101] helo=unknown-00-22-43-25-f9-66.home) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1PIcPi-0008G4-Qx; Wed, 17 Nov 2010 07:26:43 +0000 References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <002a01cb81e1$40e58740$c2b095c0$@com> <6631D123-D319-4CF6-B299-FD8CFD17EB0B@niven-jenkins.co.uk> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <297EBB41-64BA-4ED7-9D9A-F074D6B7E5F9@niven-jenkins.co.uk> Content-Transfer-Encoding: quoted-printable From: Benjamin Niven-Jenkins Date: Wed, 17 Nov 2010 07:26:40 +0000 To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1078) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: httpstreaming , conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 07:26:00 -0000 On 16 Nov 2010, at 21:56, Mikael Abrahamsson wrote: > On Tue, 16 Nov 2010, Ben Niven-Jenkins wrote: >=20 >> Please cite evidence to support this assertion. >=20 > Are you for real? You're free to say what you want, but I have to = "cite evidence"? >=20 My language probably came across a little harshly. My point was that if = you look at global transit prices they are typically a few dollars a = Mbps in the west. That pricing is not universal across the globe. =20 >> At least for the ISPs I have worked with & for the margins are pretty = thin and while Transit/Peering costs are not the largest cost they are = not insignificant. We saw large scale "streaming events", e.g. day long = sports event broadcast on the Internet, had significant (localised) = impact to the Transit costs and if they were permanent (e.g. your = average 1 Mbps / user at peak time) they would have made a significant = impact to the bottom-line. >=20 > Well then, your experience differs from mine. Indeed. Ben From luismi.diaz@alcatel-lucent.com Wed Nov 17 02:08:36 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92263A68A8; Wed, 17 Nov 2010 02:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.928 X-Spam-Level: X-Spam-Status: No, score=-5.928 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpzHeDExHlpv; Wed, 17 Nov 2010 02:08:35 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id EAD1B3A68BE; Wed, 17 Nov 2010 02:08:34 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAHA7NsM032574 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Nov 2010 11:09:07 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 17 Nov 2010 11:08:31 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: Marshall Eubanks Date: Wed, 17 Nov 2010 11:08:29 +0100 Thread-Topic: [dispatch] [httpstreaming] [conex] Q-HTTP Thread-Index: AcuFrpoz+nDGpWHISxWNLFSoo9eM0QAj/qgw Message-ID: <3349FECF788C984BB34176D70A51782F16BB3AAA@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F16877F68@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1687808C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <7C3A8DA4-18F3-4AA4-A2F4-325FC2D817DA@americafree.tv> In-Reply-To: <7C3A8DA4-18F3-4AA4-A2F4-325FC2D817DA@americafree.tv> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , Ingemar, httpstreaming , "conex@ietf.org" , Johansson S , Mikael, "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" Subject: Re: [conex] [dispatch] [httpstreaming] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 10:08:36 -0000 I have worked extensively (in engineering and network design) for every ISP= on Spain (Telefonica, France Telecom, Orange, BT...) and all of them have = QoS in their network. They use it to provide VoIP, Broadcast TV and to prot= ect Bussiness Services (VPLS and IP-VPN). Indeed the only traffic that is B= est-Effort is internet traffic for residential users (internet for corporat= e customers has also higher priority). Maybe they are not SELLING QoS directly to their customers. But for sure th= ey are USING it a lot. What we propose is opening that feature to everyone,= providing a tool to monitor and control QoS to everyone. Saludos, Luismi -----Mensaje original----- De: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] En nombre = de Marshall Eubanks Enviado el: martes, 16 de noviembre de 2010 17:51 Para: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Ingemar Johansson S; = GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER); Mikael Abrahamsson Asunto: Re: [dispatch] [httpstreaming] [conex] Q-HTTP On Nov 12, 2010, at 4:12 AM, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote= : >=20 > You said: >=20 > "Packet prioritization is only of value when the network is full. QoS is = only of interest when BE works badly." >=20 > Then, why on earth ALL ISPs are using QoS in THEIR networks to guarantee = their own VoIP and Broadcast TV services to their customers??? >=20 > QoS is ALWAYS a MUST for ISPs to ensure real-time services at any moment.= Q-HTTP is trying to open up that window to other third parties. >=20 I have three personal / office ISP accounts for Internet access. If any are= offering QOS as a service, they sure haven't told me. (One, the cable comp= any, does do a "walled garden" type solution for IPTV, but I don't think th= at that is the type of QOS you are talking about.) =20 Regards Marshall > And about "network state", there are different solutions to implement thi= s, one includes network state, BUT IT IS NOT THE ONLY ONE. Indeed we tested= one alternative in our lab with actual equipment.... >=20 > Saludos, > Luismi >=20 > -----Mensaje original----- > De: Mikael Abrahamsson [mailto:swmike@swm.pp.se] Enviado el: jueves,=20 > 11 de noviembre de 2010 21:44 > Para: GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) > CC: dispatch@ietf.org; httpstreaming; conex@ietf.org; Mike Hammer=20 > (hmmr); Ingemar Johansson S; Kathy McEwen; DIAZ VIZCAINO, LUIS MIGUEL=20 > (LUIS MIGUEL) > Asunto: RE: [dispatch] [conex] [httpstreaming] Q-HTTP >=20 > On Thu, 11 Nov 2010, GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) wrote: >=20 >> Service providers are worried about ARPU. It is decreasing becasue=20 >> the "exaflood" phenomenon. The exponential traffic can not be=20 >> sustained by the network, with incremental increases in bandwidth. >=20 > I don't get it. Are you saying that because there is more traffic, the us= er is paying less money per month? Yes, profit per customer might be down, = but why should traffic volume decrease revenue? >=20 >> These ISP capabilities can be priced to developers/content providers,=20 >> increasing ISP revenues. Capabilities such as location, presence, billin= g, security, QoS.... >=20 > I agree that an ISP can be a micropayment provider and also provice some = location information. >=20 >> One of the most important is QoS. If developers can not find=20 >> profitable business Models, innovation is compromised. QoS means a=20 >> mix of traffic engineering + priorization + etc >=20 > Packet prioritization is only of value when the network is full. QoS is o= nly of interest when BE works badly. >=20 >> Now imagine an ISP which offer "intelligent" QoS ( based on Q-HTTP)=20 >> to enable virtualization of games (like www.onlive.com, but using the=20 >> network instead locating servers at last mille) >=20 > I don't get this either. You can't play an FPS with tens of milliseconds = of network delay, so you need to locate servers close to the customers to k= eep latency low, plus you also don't want the access latency to eat up your= latency budget so ADSL and cable goes out the window anyway, the only thin= g left is the sub-millisecond latency of ETTH. >=20 > Btw, I think Q-HTTP is a horrible idea. It seems require a lot of state i= n the network. State is expensive. What happened to KISS principle? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > httpstreaming mailing list > httpstreaming@ietf.org > https://www.ietf.org/mailman/listinfo/httpstreaming >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From luismi.diaz@alcatel-lucent.com Wed Nov 17 02:17:30 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B157A3A68B9; Wed, 17 Nov 2010 02:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.557 X-Spam-Level: X-Spam-Status: No, score=-4.557 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_00=-2.599, GB_PAYLESS=0.5, HELO_EQ_FR=0.35, MANGLED_MEDS=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBIn5eoC7gfB; Wed, 17 Nov 2010 02:17:29 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 85B003A68A8; Wed, 17 Nov 2010 02:17:28 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAHAI1lQ011790 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Nov 2010 11:18:03 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 17 Nov 2010 11:17:52 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: David Singer Date: Wed, 17 Nov 2010 11:17:50 +0100 Thread-Topic: [httpstreaming] [dispatch] [conex] Q-HTTP Thread-Index: AcuFuJV9SbDz6PT3QQ+a1hXQFFKW8AAhub4A Message-ID: <3349FECF788C984BB34176D70A51782F16BB3ABF@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <663377F3-630B-428F-92CC-775CC63B816B@apple.com> In-Reply-To: <663377F3-630B-428F-92CC-775CC63B816B@apple.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Johansson S , "Mike Hammer \(hmmr\)" , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , "Ingemar@core3.amsl.com" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 10:17:30 -0000 Importance is something heavely subjective. If your file is so critical you= will pay for QoS the same as i am paying for gaming, to ensure that flow (= file download) is delivered as expected. Moreover, our proposal includes th= e different requirements for every flow, gaming and critical file downloadi= ng will have different needs and network can do different things to ensure = both services are honouring its SLA. You paid the same for bandwidth, but if i pay an "extra" to ensure my gamin= g experience we are not fair anymore.... Everyone thinks that people in your flight using bussiness class has the ri= ght to board first (among other privileges) because the pay more, but on th= e other hand, Internet should remain "fair"...I dont really see any differe= nce, you obtain what you pay for, if you pay more you will have more (for s= ure not in an 1:1 way). INDEED, dont forget that i am personally convinced that this Q-HTTP initiat= ive should help ISPs to lower flat rates. If you only need Internet access = for emailing and web surfing you will pay LESS, and people that make extens= ive use of resources will pay More. That is fairness for me :D. Saludos, Luismi -----Mensaje original----- De: David Singer [mailto:singer@apple.com]=20 Enviado el: martes, 16 de noviembre de 2010 19:03 Para: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) CC: Mikael Abrahamsson; Mike Hammer (hmmr); dispatch@ietf.org; Ingemar@core= 3.amsl.com; httpstreaming; conex@ietf.org; Johansson S; GARCIA ARANDA, JOSE= JAVIER (JOSE JAVIER) Asunto: Re: [httpstreaming] [dispatch] [conex] Q-HTTP On Nov 11, 2010, at 10:43 , DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) wrote: > Now think on Internet. You are playing a Real-Time game and your neighb= ours are just downloading files.=20 I am downloading a critical file that will enable me to respond to an urgen= t legal issue I have; you are merely playing games. You can wait. I paid the same as you for my bandwidth, so I should get at least fair trea= tment, if not preferential -:) David Singer Multimedia and Software Standards, Apple Inc. From luismi.diaz@alcatel-lucent.com Wed Nov 17 02:20:38 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD1E03A68C3; Wed, 17 Nov 2010 02:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBKQ7IjkA+Ke; Wed, 17 Nov 2010 02:20:37 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 5162C3A68D2; Wed, 17 Nov 2010 02:20:37 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAHAKOI0010285 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 17 Nov 2010 11:20:46 +0100 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 17 Nov 2010 11:20:40 +0100 From: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" To: David Singer , Mike Hammer Date: Wed, 17 Nov 2010 11:20:37 +0100 Thread-Topic: [httpstreaming] [dispatch] [conex] Q-HTTP Thread-Index: AcuFxhq98dD6DuE0ReS+PssNzDmf1wAerEnQ Message-ID: <3349FECF788C984BB34176D70A51782F16BB3AC5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F 16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <663377F3-630B-428F-92CC-775CC63B816B@apple.com> <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com> In-Reply-To: <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com> Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: es-ES, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-Mailman-Approved-At: Sun, 21 Nov 2010 16:27:18 -0800 Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Johansson S , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , "Ingemar@core3.amsl.com" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Nov 2010 10:20:39 -0000 You are treated worse because you are paying less :D. I think it is a good = assumption to think that if you are not willing to pay an extra cost, maybe= what you are doing is not so important... When i am in a hurry i take the toll highway, while when i am not i use the= toll-free (ussually jammed) one.... Saludos, Luismi -----Mensaje original----- De: David Singer [mailto:singer@apple.com]=20 Enviado el: martes, 16 de noviembre de 2010 20:40 Para: Mike Hammer CC: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); Mikael Abrahamsson; dispatch@= ietf.org; Ingemar@core3.amsl.com; httpstreaming; conex@ietf.org; Johansson = S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) Asunto: Re: [httpstreaming] [dispatch] [conex] Q-HTTP OK, so my example was slightly humorous. But in general I think the claim = that you can give preferential treatment -- preferential allocation of band= width -- to certain traffic simply because of its type is doubtful. =20 Remember, this issue only comes up when there is a shortage; and the thesi= s that I should be short-changed more (treated worse) than you because you = are doing a real-time operation and I am not, is doubtful. On Nov 16, 2010, at 10:46 , Mike Hammer (hmmr) wrote: > David, >=20 > Let us be real. If your file shows up 1 second later, does it matter? > Probably not. >=20 > If my voice or video packet shows up 1 second later, does it matter? > Yes, it gets dropped. >=20 > Mike >=20 >=20 > -----Original Message----- > From: David Singer [mailto:singer@apple.com] > Sent: Tuesday, November 16, 2010 1:03 PM > To: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) > Cc: Mikael Abrahamsson; Mike Hammer (hmmr); dispatch@ietf.org;=20 > Ingemar@core3.amsl.com; httpstreaming; conex@ietf.org; Johansson S;=20 > GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) > Subject: Re: [httpstreaming] [dispatch] [conex] Q-HTTP >=20 >=20 > On Nov 11, 2010, at 10:43 , DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) > wrote: >=20 >> Now think on Internet. You are playing a Real-Time game and your > neighbours are just downloading files.=20 >=20 > I am downloading a critical file that will enable me to respond to an=20 > urgent legal issue I have; you are merely playing games. You can wait. >=20 > I paid the same as you for my bandwidth, so I should get at least fair=20 > treatment, if not preferential -:) >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 David Singer Multimedia and Software Standards, Apple Inc. From prvs=59420511CB=Kevin.Mason@telecom.co.nz Sun Nov 21 16:45:30 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B213A68F5 for ; Sun, 21 Nov 2010 16:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[AWL=-0.407, BAYES_40=-0.185, GB_AFFORDABLE=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1bvSLSfyIb8 for ; Sun, 21 Nov 2010 16:45:29 -0800 (PST) Received: from mgate1.telecom.co.nz (envoy-out.telecom.co.nz [146.171.15.100]) by core3.amsl.com (Postfix) with ESMTP id 0C94E3A68BA for ; Sun, 21 Nov 2010 16:45:28 -0800 (PST) Received: from mgate6.telecom.co.nz (unknown [146.171.1.21]) by mgate1.telecom.co.nz (Postfix) with ESMTP id 1147662D1E9D; Mon, 22 Nov 2010 13:46:19 +1300 (NZDT) X-WSS-ID: 0LC9GT3-09-2Q5-02 X-M-MSG: Received: from hp2848.telecom.tcnz.net (hp2848.telecom.tcnz.net [146.171.228.250]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mgate6.telecom.co.nz (Postfix) with ESMTP id 176865B4DA6E; Mon, 22 Nov 2010 13:46:14 +1300 (NZDT) Received: from hp3120.telecom.tcnz.net (146.171.212.205) by hp2848.telecom.tcnz.net (146.171.228.250) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 22 Nov 2010 13:46:21 +1300 Received: from WNEXMBX01.telecom.tcnz.net ([146.171.212.201]) by hp3120.telecom.tcnz.net ([146.171.212.205]) with mapi; Mon, 22 Nov 2010 13:46:21 +1300 From: Kevin Mason To: Mikael Abrahamsson Date: Mon, 22 Nov 2010 13:46:19 +1300 Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuIx91rriIoU7g+SHWmFUlih/lmPQA8P9Fw Message-ID: <9BC62293D3D9534AACB0FEC5F2DE51B201A76418@WNEXMBX01.telecom.tcnz.net> References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> <000301cb88a6$81b20f70$85162e50$@com> In-Reply-To: Accept-Language: en-US, en-NZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-NZ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 00:45:30 -0000 Cheers Kevin Mason > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of > Mikael Abrahamsson > Sent: Sunday, 21 November 2010 4:30 a.m. > To: Toby Moncaster > Cc: conex@ietf.org > Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP [Kevin Mason] Mikael you seem to think that paths to every destination that= any user may wish to reach at any time should be dimensioned in such a way= that capacity matching or exceeding the user's access speed will always be= available. Your comparison re Africa might be valid if the only path everybody in Afri= ca used was the same. However even if all of Africa was served by a single = cable, say to Western Europe, unless all Africans only used a single source= in Western Europe, then the capacity required on every possible route beyo= nd the European end of the cable in western Europe would result in a very l= arge investment that all African users would have to alos contribute to, as= they are the ones using it.=20 On the assumption that nobody, regardless of local politics and commerciali= sm, can afford a dedicated access speed path to every possible destination,= then providers must make choices about how much capacity to provision on w= hat core paths. This is typically based on average typical peak behaviour. = But by definition events do occur, more frequently that most see or wish to= admit, that result in non typical average flows, so congestion cannot be a= voided if instantaneous source and sink combinations occurs that are other = than average. On average many providers try to ensure that congestion (whatever the defin= ition of "congestion" might be) does not occur MOST of the time as far as a= ny measurement systems they are currently using can detect. However end use= r applications can often detect it now, typically in variation in RTT and/o= r some loss. But just because providers can't see it today does not mean it= is never occurring, or if they could see it that to always avoid any conge= stion ever would be commercially viable for every combination of source and= sink paths users collectively chose to use at any instant in time. >=20 > On Sat, 20 Nov 2010, Toby Moncaster wrote: >=20 > > Remember, you live in a very prosperous country, with a relatively smal= l > > population and with excellent links to the rest of the world. Most > > places in the world are not so fortunate... >=20 > Yet, in the poorest countries I see the most expensive gear, because they > have the least skill/experience and the most monopolies that rip off thei= r > customers. It's not a matter of prosperity really. And also, if it was a > matter of prosperity, do they really need more advanced mechanisms or do > they need simpler ways of producing more bandwidth? Imposing advanced > "revenue sharing schemes", "QoS end-to-end" and so on, does that really > help any poor contry get basic Internet, or does it help oligopoly ISPs > get more money in their markets so they can give more profit? >=20 > As far as I can see so far, ConEx is dominated by oligopoly ISPs, > academics and vendors who want to sell more advanced gear. >=20 > Why isn't there anyone who stands up for the regular user? Why isn't the > KISS principle being used, why isn't there BCPs about how to solve this > with the existing technology already available? ECN has after 8 years > still not seen widespread adoption, yet there is talk about using even > more flags in the headers.=20 So I would suggest that providers believe, that users believe, TCP congesti= on mechanisms are good enough, and user don't know what might be different = if ECN was turned on by providers and users enabled it on their equipment. = So is ECN unnecessary or is there just a market education problem? So if providers had better mechanisms to observe congestion occurring, that= is in many cases is being masked by long term aggregate averaging measurem= ents today AND provider systems could identify what paths (source and sink = combinations) were being affected by it 9and not just the next hop), then t= here might be benefits for both providers and their users. It remains that = the potential for mis use of information always exists, but this is not a I= ETF issue, it's a market structure one in each jurisdiction. My expectation= is enough providers will use the information to reward those that assist i= n making the overall service more affordable for all, just as electricity c= ompanies use off-peak metered rates to reward users for allowing them to tu= rn off some of their load when demand peaks occur. >=20 > I appreciate that people are doing this because they think they're doing > the right thing, but I question if they really are. >=20 > In the markets where you get the most bandwidth for the least amount of > money, ISPs generally can't afford a huge amount of CRS-1 or Juniper > T-series, they instead build it using L3 switches that have little to no > queue management, but they instead overprovision services so it works > anyway. You appear to assume that devices, router/switches are the most significant= cost component. This may be the case for very high density geographies, bu= t not for all. The cost of carrying internet traffic from the south pacific= to/from Europe Asia and the US is not dominated by routing/swtiching equip= ment!. >=20 > > IETF to address. It is for regulators and competition to sort out. What > the > > IETF can do is provide tools that give ISPs better options for seeing > where > > there are problems. Current DPI/traffic pattern analysis coupled to fai= r > use > > policies is not a good solution for either party... >=20 > I agree, but what the IETF is not doing, is providing tools to *users* to > see where the problems are. Also, most of the documents I see here have > problem description wording that consists of "unfair use" and similar > terms. That is not helping the users, because there is no such thing as > "unfair use" to me, I'm just trying to use what I've purchased.[Kevin Mas= on]=20 [Kevin Mason] TCP, LEDBAT, the proposed Q-HTTP among others are primarily t= ools for users so I don't see any lack of "tools" for users. CONEX I unders= tand is trying to provide some of that visibility to providers because zero= congestion is not achievable at any realistic price unless all sources dir= ectly connected to access lines (i.e. there is no core !). >=20 > > Realistically your idea of a completely congestion-free network is not > > going to happen any time soon in most of the world (I accept Sweden > > seems to be an exception). Therefore the IETF needs to try to improve > > the current situation. >=20 > Yes it does, but not the onesided way being done right now. >=20 > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From tme@americafree.tv Sun Nov 21 20:13:29 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFED3A6A00; Sun, 21 Nov 2010 20:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.792 X-Spam-Level: X-Spam-Status: No, score=-101.792 tagged_above=-999 required=5 tests=[AWL=0.807, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDGsMTQJwRU7; Sun, 21 Nov 2010 20:13:27 -0800 (PST) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 649E83A6888; Sun, 21 Nov 2010 20:13:27 -0800 (PST) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 137719461E87; Sun, 21 Nov 2010 23:14:22 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Marshall Eubanks In-Reply-To: <3349FECF788C984BB34176D70A51782F16BB3AC5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Date: Sun, 21 Nov 2010 23:14:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9B6DA2F5-B734-41D8-AE63-143C0CA17C49@americafree.tv> References: <3349FECF788C984BB34176D70A51782F106701E2@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F1067054D@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <3349FECF788C984BB34176D70A51782F168772C1@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <1104E0EB-CBAD-4001-962F-9D5F8B856D42@nokia.com> <01d801cb8083$8ca250f0$a5e6f2d0$@iridescentnetworks.com> <1E1ED4EA-7CB5-4A86-BD3F-B1F5F72EF456@netflix.com> <3349FECF788C984BB34176D70A51782F 16877F3C@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <663377F3-630B-428F-92CC-775CC63B816B@apple.com> <0068F76E-8631-4A43-A414-02AC36F2F81E@apple.com> <3349FECF788C984BB34176D70A51782F16BB3AC5@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> To: "DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL)" X-Mailer: Apple Mail (2.1081) Cc: "dispatch@ietf.org" , httpstreaming , "conex@ietf.org" , Johansson S , Mike Hammer , "GARCIA ARANDA, JOSE JAVIER \(JOSE JAVIER\)" , David Singer , "Ingemar@core3.amsl.com" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 04:13:29 -0000 I have pinged the Secretariat to stop all of these 4-day old messages.=20= Regards Marshall On Nov 17, 2010, at 5:20 AM, DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) = wrote: > You are treated worse because you are paying less :D. I think it is a = good assumption to think that if you are not willing to pay an extra = cost, maybe what you are doing is not so important... >=20 > When i am in a hurry i take the toll highway, while when i am not i = use the toll-free (ussually jammed) one.... >=20 >=20 > Saludos, > Luismi >=20 > -----Mensaje original----- > De: David Singer [mailto:singer@apple.com]=20 > Enviado el: martes, 16 de noviembre de 2010 20:40 > Para: Mike Hammer > CC: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL); Mikael Abrahamsson; = dispatch@ietf.org; Ingemar@core3.amsl.com; httpstreaming; = conex@ietf.org; Johansson S; GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) > Asunto: Re: [httpstreaming] [dispatch] [conex] Q-HTTP >=20 > OK, so my example was slightly humorous. But in general I think the = claim that you can give preferential treatment -- preferential = allocation of bandwidth -- to certain traffic simply because of its type = is doubtful. =20 >=20 > Remember, this issue only comes up when there is a shortage; and the = thesis that I should be short-changed more (treated worse) than you = because you are doing a real-time operation and I am not, is doubtful. >=20 > On Nov 16, 2010, at 10:46 , Mike Hammer (hmmr) wrote: >=20 >> David, >>=20 >> Let us be real. If your file shows up 1 second later, does it = matter? >> Probably not. >>=20 >> If my voice or video packet shows up 1 second later, does it matter? >> Yes, it gets dropped. >>=20 >> Mike >>=20 >>=20 >> -----Original Message----- >> From: David Singer [mailto:singer@apple.com] >> Sent: Tuesday, November 16, 2010 1:03 PM >> To: DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) >> Cc: Mikael Abrahamsson; Mike Hammer (hmmr); dispatch@ietf.org;=20 >> Ingemar@core3.amsl.com; httpstreaming; conex@ietf.org; Johansson S;=20= >> GARCIA ARANDA, JOSE JAVIER (JOSE JAVIER) >> Subject: Re: [httpstreaming] [dispatch] [conex] Q-HTTP >>=20 >>=20 >> On Nov 11, 2010, at 10:43 , DIAZ VIZCAINO, LUIS MIGUEL (LUIS MIGUEL) >> wrote: >>=20 >>> Now think on Internet. You are playing a Real-Time game and your >> neighbours are just downloading files.=20 >>=20 >> I am downloading a critical file that will enable me to respond to an=20= >> urgent legal issue I have; you are merely playing games. You can = wait. >>=20 >> I paid the same as you for my bandwidth, so I should get at least = fair=20 >> treatment, if not preferential -:) >>=20 >> David Singer >> Multimedia and Software Standards, Apple Inc. >>=20 >=20 > David Singer > Multimedia and Software Standards, Apple Inc. >=20 > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex >=20 From swmike@swm.pp.se Sun Nov 21 22:17:47 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23353A6A0E for ; Sun, 21 Nov 2010 22:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFGANJ2zszFJ for ; Sun, 21 Nov 2010 22:17:47 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 5732B3A6A2C for ; Sun, 21 Nov 2010 22:17:45 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D06C99C; Mon, 22 Nov 2010 07:18:38 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CEDE59A; Mon, 22 Nov 2010 07:18:38 +0100 (CET) Date: Mon, 22 Nov 2010 07:18:38 +0100 (CET) From: Mikael Abrahamsson To: Kevin Mason In-Reply-To: <9BC62293D3D9534AACB0FEC5F2DE51B201A76418@WNEXMBX01.telecom.tcnz.net> Message-ID: References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> <000301cb88a6$81b20f70$85162e50$@com> <9BC62293D3D9534AACB0FEC5F2DE51B201A76418@WNEXMBX01.telecom.tcnz.net> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 06:17:47 -0000 On Mon, 22 Nov 2010, Kevin Mason wrote: > [Kevin Mason] TCP, LEDBAT, the proposed Q-HTTP among others are > primarily tools for users so I don't see any lack of "tools" for users. > CONEX I understand is trying to provide some of that visibility to > providers because zero congestion is not achievable at any realistic > price unless all sources directly connected to access lines (i.e. there > is no core !). At IETF75 I proposed in multiple WGs (and at the general session one evening) to have some work done to give the user insight into what TCP (and other protocols) is doing. I still haven't seen any takers or even someone saying this is a way forward that they think is worthwile spending time on. Zero. So I would like to say that using TCP as an example of "tool" for a user to see what is going "on", is not something I agree on today. Q-HTTP might do it if I understand it correctly, but I don't like that it actually introduces testing traffic, when instead my strong opinion is that one should not introduce testing traffic, one should instead look at the real traffic and what is going on there. TCP has lots of tools to help itself (timestamping, noticing single packet loss etc), but there is no way to expose this to the general user. I can fire up wireshark and spend minutes/hours trying to figure out what is going on, but I've been doing packet networking for 15+ years and know my way around that tool. I don't know what tools LEDBAT has to inform the user, but I guess since it's "background" the user can see the transfer speed to see what extra bandwidth is available, and when it's very low, the network is obviously full. -- Mikael Abrahamsson email: swmike@swm.pp.se From toby@moncaster.com Mon Nov 22 06:49:19 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84B7B28C10F for ; Mon, 22 Nov 2010 06:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkLfbOpPo-NL for ; Mon, 22 Nov 2010 06:49:18 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 5DFD528C10E for ; Mon, 22 Nov 2010 06:49:18 -0800 (PST) Received: from TobysHP (host86-140-35-91.range86-140.btcentralplus.com [86.140.35.91]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lp8ey-1OqjHY15AS-00es5U; Mon, 22 Nov 2010 15:50:08 +0100 From: "Toby Moncaster" To: "'Mikael Abrahamsson'" , "'Kevin Mason'" References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> <000301cb88a6$81b20f70$85162e50$@com> <9BC62293D3D9534AACB0FEC5F2DE51B201A76418@WNEXMBX01.telecom.tcnz.net> In-Reply-To: Date: Mon, 22 Nov 2010 14:50:08 -0000 Message-ID: <002201cb8a54$8ef1d350$acd579f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcuKDR+gY1osihfQRxaAF0zHnnsNXAARmSew Content-Language: en-gb X-Provags-ID: V02:K0:bM655J2GUZ9CkE1zygDydzYgJMOV0jClusY/RAqDY5m qsqRJVvAx7EtTeigRUq8x0oKz504WXKWjrx3rsmw21AiwiDwee VKGouQ0o7BHJMN6eSBWE+mG4E+R3OWI/3xVRU0f+hmWsKzkPxj KH3fD9YmXqgcoyi8q7iAomNkHBaeSA5ZNenMZcXZTbd/rtcwTG QRnCbv3YkoQuq0EC4roCzOvqIcss3uwvNSxjScj46k= Cc: conex@ietf.org Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 14:49:19 -0000 > -----Original Message----- > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > Of Mikael Abrahamsson > Sent: 22 November 2010 06:19 > To: Kevin Mason > Cc: conex@ietf.org > Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP > > On Mon, 22 Nov 2010, Kevin Mason wrote: > > > [Kevin Mason] TCP, LEDBAT, the proposed Q-HTTP among others are > > primarily tools for users so I don't see any lack of "tools" for > users. > > CONEX I understand is trying to provide some of that visibility to > > providers because zero congestion is not achievable at any realistic > > price unless all sources directly connected to access lines (i.e. > there > > is no core !). > > At IETF75 I proposed in multiple WGs (and at the general session one > evening) to have some work done to give the user insight into what TCP > (and other protocols) is doing. I still haven't seen any takers or even > someone saying this is a way forward that they think is worthwile > spending > time on. Zero. Or perhaps they think that is a job for OS writers, not the IETF? There are limits to what the IETF should take on else we will spread ourselves rather too thin... > So I would like to say that using TCP as an example of "tool" for a > user > to see what is going "on", is not something I agree on today. Q-HTTP > might > do it if I understand it correctly, but I don't like that it actually > introduces testing traffic, when instead my strong opinion is that one > should not introduce testing traffic, one should instead look at the > real > traffic and what is going on there. TCP has lots of tools to help > itself > (timestamping, noticing single packet loss etc), but there is no way to > expose this to the general user. I can fire up wireshark and spend > minutes/hours trying to figure out what is going on, but I've been > doing > packet networking for 15+ years and know my way around that tool. > > I don't know what tools LEDBAT has to inform the user, but I guess > since > it's "background" the user can see the transfer speed to see what extra > bandwidth is available, and when it's very low, the network is > obviously > full. To my mind it is NOT sensible to show users what is happening. Bluntly, 99% of people couldn't care less how the Internet works, what their PC is doing when they start a Skype video call, etc, any more than they want to know what their car's engine management system does when they press the gas pedal. What things like LEDBAT are trying to do is translate the user's behaviour (we want a file, so we tell our PC to find it and download it) into sensible actions (user is also doing something interactive and if the file transfer grabs all their bandwidth suddenly their interactive session dies, so we slow the transfer down until the interactive session goes away). I do believe there is room for improvement (perhaps an app that allows the user to say, actually this transfer is quite important as I want to watch this film tonight (said film being copyright free or paid for of course ;) I am not convinced the IETF should be going into that much detail though... Toby > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > _______________________________________________ > conex mailing list > conex@ietf.org > https://www.ietf.org/mailman/listinfo/conex From richard_woundy@cable.comcast.com Mon Nov 22 08:37:31 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CF5F28C119 for ; Mon, 22 Nov 2010 08:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-3.364, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYOj7eZGcj4P for ; Mon, 22 Nov 2010 08:37:30 -0800 (PST) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by core3.amsl.com (Postfix) with ESMTP id 786133A6A9B for ; Mon, 22 Nov 2010 08:37:30 -0800 (PST) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.15669898; Mon, 22 Nov 2010 09:46:57 -0700 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%12]) with mapi id 14.01.0255.000; Mon, 22 Nov 2010 11:38:20 -0500 From: "Woundy, Richard" To: "conex@ietf.org" Thread-Topic: [conex] I-D ACTION:draft-ietf-conex-concepts-uses-00.txt Thread-Index: AQHLh0IsimlMO2qBZkqlXkOVUANQC5N9tNEg Date: Mon, 22 Nov 2010 16:38:20 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD10381C2@PACDCEXMB05.cable.comcast.com> References: <20101118170001.6076.92944.idtracker@localhost> In-Reply-To: <20101118170001.6076.92944.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.25.253.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Woundy, Richard" , "bob.briscoe@bt.com" Subject: Re: [conex] I-D ACTION:draft-ietf-conex-concepts-uses-00.txt X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 16:37:31 -0000 Folks, The latest use cases draft (draft-ietf-conex-concepts-uses-00) reflects the= consensus from the Conex session in Beijing to accept the use cases draft = (previously draft-moncaster-conex-concepts-uses-02) as a working group draf= t after making certain modifications. These modifications were to remove section 5.3 ("ConEx to mitigate DDoS") a= nd the appendix ("ConEx Architectural Elements"). Per direction of the work= ing group, we did not modify terminology in this version of the draft to ma= tch the Abstract Mechanism draft (draft-mathis-conex-abstract-mech-00). Our expectation is that the next version of the draft will correct the term= inology, as well as include additional use cases and updates following the = direction of the working group. -- Rich -----Original Message----- From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf Of I= nternet-Drafts@ietf.org Sent: Thursday, November 18, 2010 12:00 PM To: i-d-announce@ietf.org Cc: conex@ietf.org Subject: [conex] I-D ACTION:draft-ietf-conex-concepts-uses-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Congestion Exposure Working Group of the I= ETF. Title : ConEx Concepts and Use Cases Author(s) : B. Briscoe, R. Woundy, T. Moncaster, J. Leslie Filename : draft-ietf-conex-concepts-uses-00.txt Pages : 19 Date : 2010-11-15 =09 Internet Service Providers (operators) are facing problems where localized congestion prevents full utilization of the path between sender and receiver at today's "broadband" speeds. Operators desire to control this congestion, which often appears to be caused by a small number of users consuming a large amount of bandwidth. Building out more capacity along all of the path to handle this congestion can be expensive and may not result in improvements for all users so network operators have sought other ways to manage congestion. The current mechanisms all suffer from difficulty measuring the congestion (as distinguished from the total traffic). The ConEx Working Group is designing a mechanism to make congestion along any path visible at the Internet Layer. This document describes example cases where this mechanism would be useful. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementa= tion to automatically retrieve the ASCII version of the Internet-Draft. From marcelo@it.uc3m.es Mon Nov 22 10:53:33 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4114C3A6AED for ; Mon, 22 Nov 2010 10:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZM1jYXuk3JX for ; Mon, 22 Nov 2010 10:53:32 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 55C0E3A6A2A for ; Mon, 22 Nov 2010 10:53:31 -0800 (PST) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (dummyhost7.it.uc3m.es [163.117.139.248]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 4A045728CE4 for ; Mon, 22 Nov 2010 19:54:20 +0100 (CET) Message-ID: <4CEABC5C.3050506@it.uc3m.es> Date: Mon, 22 Nov 2010 19:54:20 +0100 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: conex@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17784.000 Subject: [conex] draft minutes posted X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 18:53:33 -0000 You can find the draft minutes at: http://www.ietf.org/proceedings/79/minutes/conex.txt thanks Mat Ford to taking the minutes. Let me know if you have comments. Regards, marcelo From prvs=59420511CB=Kevin.Mason@telecom.co.nz Mon Nov 22 15:40:51 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC8E28C185 for ; Mon, 22 Nov 2010 15:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=1.504, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NZ+5gy3b3og for ; Mon, 22 Nov 2010 15:40:40 -0800 (PST) Received: from mgate1.telecom.co.nz (envoy-out.telecom.co.nz [146.171.15.100]) by core3.amsl.com (Postfix) with ESMTP id B669A28C187 for ; Mon, 22 Nov 2010 15:40:34 -0800 (PST) Received: from mgate3.telecom.co.nz (unknown [146.171.1.21]) by mgate1.telecom.co.nz (Postfix) with ESMTP id 1895262D0BAF; Tue, 23 Nov 2010 12:41:19 +1300 (NZDT) X-WSS-ID: 0LCB8GU-03-2KN-02 X-M-MSG: Received: from hp2848.telecom.tcnz.net (hp2848.telecom.tcnz.net [146.171.228.250]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mgate3.telecom.co.nz (Postfix) with ESMTP id 1C0D14A1A775; Tue, 23 Nov 2010 12:41:17 +1300 (NZDT) Received: from hp3120.telecom.tcnz.net (146.171.212.205) by hp2848.telecom.tcnz.net (146.171.228.250) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 23 Nov 2010 12:41:20 +1300 Received: from WNEXMBX01.telecom.tcnz.net ([146.171.212.201]) by hp3120.telecom.tcnz.net ([146.171.212.205]) with mapi; Tue, 23 Nov 2010 12:41:20 +1300 From: Kevin Mason To: Toby Moncaster , 'Mikael Abrahamsson' Date: Tue, 23 Nov 2010 12:41:19 +1300 Thread-Topic: [conex] [httpstreaming] [dispatch] Q-HTTP Thread-Index: AcuKDR+gY1osihfQRxaAF0zHnnsNXAARmSewABINUEA= Message-ID: <9BC62293D3D9534AACB0FEC5F2DE51B21069C4AD@WNEXMBX01.telecom.tcnz.net> References: <8F242B230AD6474C8E7815DE0B4982D7179FB836@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DA@EXV1.corp.adtran.com> <8F242B230AD6474C8E7815DE0B4982D719E654DC@EXV1.corp.adtran.com> <000301cb88a6$81b20f70$85162e50$@com> <9BC62293D3D9534AACB0FEC5F2DE51B201A76418@WNEXMBX01.telecom.tcnz.net> <002201cb8a54$8ef1d350$acd579f0$@com> In-Reply-To: <002201cb8a54$8ef1d350$acd579f0$@com> Accept-Language: en-US, en-NZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-NZ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "conex@ietf.org" Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Nov 2010 23:40:52 -0000 Cheers Kevin Mason > -----Original Message----- > From: Toby Moncaster [mailto:toby@moncaster.com] > Sent: Tuesday, 23 November 2010 3:50 a.m. > To: 'Mikael Abrahamsson'; Kevin Mason > Cc: conex@ietf.org > Subject: RE: [conex] [httpstreaming] [dispatch] Q-HTTP >=20 >=20 >=20 > > -----Original Message----- > > From: conex-bounces@ietf.org [mailto:conex-bounces@ietf.org] On Behalf > > Of Mikael Abrahamsson > > Sent: 22 November 2010 06:19 > > To: Kevin Mason > > Cc: conex@ietf.org > > Subject: Re: [conex] [httpstreaming] [dispatch] Q-HTTP > > > > On Mon, 22 Nov 2010, Kevin Mason wrote: > > > > > [Kevin Mason] TCP, LEDBAT, the proposed Q-HTTP among others are > > > primarily tools for users so I don't see any lack of "tools" for > > users. > > > CONEX I understand is trying to provide some of that visibility to > > > providers because zero congestion is not achievable at any realistic > > > price unless all sources directly connected to access lines (i.e. > > there > > > is no core !). > > > > At IETF75 I proposed in multiple WGs (and at the general session one > > evening) to have some work done to give the user insight into what TCP > > (and other protocols) is doing. I still haven't seen any takers or even > > someone saying this is a way forward that they think is worthwile > > spending > > time on. Zero. >=20 > Or perhaps they think that is a job for OS writers, not the IETF? There > are > limits to what the IETF should take on else we will spread ourselves > rather > too thin... >=20 >=20 > > So I would like to say that using TCP as an example of "tool" for a > > user > > to see what is going "on", is not something I agree on today. Q-HTTP > > might > > do it if I understand it correctly, but I don't like that it actually > > introduces testing traffic, when instead my strong opinion is that one > > should not introduce testing traffic, one should instead look at the > > real > > traffic and what is going on there. TCP has lots of tools to help > > itself > > (timestamping, noticing single packet loss etc), but there is no way to > > expose this to the general user. I can fire up wireshark and spend > > minutes/hours trying to figure out what is going on, but I've been > > doing > > packet networking for 15+ years and know my way around that tool. > > > > I don't know what tools LEDBAT has to inform the user, but I guess > > since > > it's "background" the user can see the transfer speed to see what extra > > bandwidth is available, and when it's very low, the network is > > obviously > > full. [Kevin Mason] My definition of "tool" is perhaps wider that yours, in that = these protocols already expose end to end path information to end user devi= ces. The user's application is acting on the user's behalf, so the extent t= o which path information derived from the transport protocol is literally c= onveyed to the "human user", rather than acted on by the application in an = attempt to achieve the experience or outcome preferences set by the human u= ser, are from a network behaviour perspective synonymous. No equivalent information is currently exposed to the network to enable a s= ervice provider to observe the current impact of user behaviour to craft an= d manage suitable incentives and rewards for mutually beneficial behaviours= . >=20 > To my mind it is NOT sensible to show users what is happening. Bluntly, > 99% > of people couldn't care less how the Internet works, what their PC is > doing > when they start a Skype video call, etc, any more than they want to know > what their car's engine management system does when they press the gas > pedal. >=20 > What things like LEDBAT are trying to do is translate the user's behaviou= r > (we want a file, so we tell our PC to find it and download it) into > sensible > actions (user is also doing something interactive and if the file transfe= r > grabs all their bandwidth suddenly their interactive session dies, so we > slow the transfer down until the interactive session goes away). >=20 > I do believe there is room for improvement (perhaps an app that allows th= e > user to say, actually this transfer is quite important as I want to watch > this film tonight (said film being copyright free or paid for of course ;= ) >=20 > I am not convinced the IETF should be going into that much detail > though... >=20 > Toby >=20 > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > > conex mailing list > > conex@ietf.org > > https://www.ietf.org/mailman/listinfo/conex From ingemar.s.johansson@ericsson.com Tue Nov 23 23:30:00 2010 Return-Path: X-Original-To: conex@core3.amsl.com Delivered-To: conex@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F1C93A6989 for ; Tue, 23 Nov 2010 23:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.588 X-Spam-Level: X-Spam-Status: No, score=-6.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPF7a+X6DEjl for ; Tue, 23 Nov 2010 23:29:59 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0B5D03A6993 for ; Tue, 23 Nov 2010 23:29:58 -0800 (PST) X-AuditID: c1b4fb39-b7cabae000005002-d0-4cecbf301a4c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 49.C6.20482.03FBCEC4; Wed, 24 Nov 2010 08:30:57 +0100 (CET) Received: from ESESSCMS0366.eemea.ericsson.se ([169.254.1.174]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 24 Nov 2010 08:30:56 +0100 From: Ingemar Johansson S To: Steven Blake Date: Wed, 24 Nov 2010 08:30:55 +0100 Thread-Topic: [conex] Abstract marking and encoding in IPv6 Thread-Index: AcuGaznwV4Kv6ookQZ2fihdSZe55MQFPV7Qw Message-ID: References: <4CDD297D.9030204@kit.edu> <4CE1AC4E.5040805@kit.edu> <1289921665.6883.13.camel@tachyon> <1290007336.24866.11.camel@tachyon> In-Reply-To: <1290007336.24866.11.camel@tachyon> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "conex@ietf.org" Subject: Re: [conex] Abstract marking and encoding in IPv6 X-BeenThere: conex@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Congestion Exposure working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 07:30:00 -0000 VGhhbmtzIGZvciB0aGUgcHJpbWVyLiANCkkgZ3Vlc3MgaXQgY2FuIGJlIGludGVycHJldGVkIGlu IG1hbnkgd2F5cy4NCiANCk15IGludGVycHJldGF0aW9uIGlzIHRoYXQgZXh0ZW5zaW9uIGhlYWRl cnMgaXMgbm90IGEgdmVyeSBnb29kIGlkZWEuIFRoZXJlZm9yZSBJIGJlbGlldmUgdGhlIFdHIHNo b3VsZCBjb25zaWRlciB0aGUgb3B0aW9uIHRvIHVzZSAxIGJpdCBmcm9tIHRoZSBmbG93bGFiZWwg YW5kIHNlZSB3aGF0IGNhbiBiZSBhY2hpZXZlZCB3aXRoIHRoYXQuIA0KT2YgY291cnNlIHRoaXMg ZXh0cmEgYml0IG1lYW5zIGV4dHJhIHByb2Nlc3NpbmcgaW4gdGhlICJmYXN0IHBhdGgiIGZvciBh IENvbkV4IGF3YXJlIHJvdXRlciBidXQgaXQgY2FuIGJlIHNhZmVseSBpZ25vcmVkIGJ5IGFueSBu b24tQ29uRXggcm91dGVyLiBIZWFkZXIgZXh0ZW5zaW9uIHRvIG1lYW5zIHRoYXQgcGF0dGVybiBt YXRjaGluZyBuZWVkcyB0byBiZSBkb25lIG9uIGV2ZXJ5IHBhY2tldCB0byBzZWUgaWYgZXh0ZW5z aW9uIFggaXMgc3VwcG9ydGVkIGJ5IHRoZSByb3V0ZXIgYW5kIGlmIHByb2Nlc3Npbmcgc2hvdWxk IGJlIGluIHRoZSBmYXN0IG9yIHNsb3cgcGF0aC4NCg0KbXkgNeKCrA0KUmVnYXJkcyANCi9Jbmdl YW1yDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RldmVuIEJsYWtl IFttYWlsdG86c2xibGFrZUBwZXRyaS1tZWF0LmNvbV0gDQo+IFNlbnQ6IGRlbiAxNyBub3ZlbWJl ciAyMDEwIDE2OjIyDQo+IFRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTDQo+IENjOiBSb2xhbmQgQmxl c3M7IGNvbmV4QGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbY29uZXhdIEFic3RyYWN0IG1hcmtp bmcgYW5kIGVuY29kaW5nIGluIElQdjYNCj4gDQo+IE9uIFdlZCwgMjAxMC0xMS0xNyBhdCAwNzo1 MyArMDEwMCwgSW5nZW1hciBKb2hhbnNzb24gUyB3cm90ZToNCj4gDQo+ID4gVGhhbmtzIGZvciBk cm9wcGluZyBieSBTdGV2ZW4uIA0KPiA+IA0KPiA+IENhbiBhbnlvbmUgcG9pbnQgdG8gYSAiMTAx IGZhc3RwYXRoIHZzLiBzbG93cGF0aCIgYXJ0aWNsZSANCj4gdGhhdCB0cmllcyANCj4gPiB0byBl eGxhaW4gd2l0aCBzb21lIG1vcmUgZGV0YWlsIHRoZSBpc3N1ZXMgd2l0aCBmYXN0IGFuZCBzbG93 cGF0aCANCj4gPiBwcm9jZXNzaW5nID8uIE15IHBlcnNvbmFsIGtub3dsZWRnZSBpcyBsaW1pdGVk IHRvIHRoZSBhIA0KPiBib29rICJOZXR3b3JrIA0KPiA+IHJvdXRpbmciIGJ5IE1laGRpIGFuZCBS YW1hc2FteSBidXQgaXQgZG9lcyBub3QgcHJvdmlkZSB0b28gbXVjaCANCj4gPiBkZXRhaWxzIG9u IHRoaXMgc3ViamVjdC4NCj4gDQo+IE9uIGJveGVzIHRoYXQgZGlzdGluZ3Vpc2ggYmV0d2VlbiAi ZmFzdCIgYW5kICJzbG93IiBwYXRoIA0KPiAodmlydHVhbGx5IGFueXRoaW5nIGZyb20gMSBHaWcg dXAgaW4gdGhlIHByb3ZpZGVyIHNwYWNlLCBhbmQgDQo+IHZpcnR1YWxseSBhbGwgRXRoZXJuZXQg Ym94ZXMpLCB0aGUgImZhc3QgcGF0aCIgaXMgaW1wbGVtZW50ZWQgDQo+IGluIHNwZWNpYWxpemVk IHNpbGljb24sIHdpdGggYWNjZXNzIHRvIGZhc3QgbWVtb3J5IChlLmcuLCANCj4gUkxEUkFNIElJ LCBRRFIgU1JBTSkgYW5kL29yIFRDQU0uICBUaGVzZSBkZXZpY2VzIGFyZSANCj4gcHJvZ3JhbW1l ZCBlaXRoZXIgaW4gVmVyaWxvZyAobWFraW5nIHJlY29tcGlsZXMgKnZlcnkqDQo+IGV4cGVuc2l2 ZSkgb3Igc3BlY2lhbGl6ZWQgZmlybXdhcmUgKGUuZy4sIE5QVXMpLiAgT2Z0ZW4gdGhlIA0KPiBO UFUgZmlybXdhcmUgaXMgc3RvcmVkIG9uIG9uLWNoaXAgbWVtb3J5LCBsaW1pdGluZyB0aGUgYW1v dW50IA0KPiBvZiBmb3J3YXJkaW5nIGZ1bmN0aW9uYWxpdHkgdGhhdCBjYW4gYmUgaW1wbGVtZW50 ZWQuICBUaGVyZSANCj4gaXMgYSB0aWdodCBidWRnZXQgb2YgbWVtb3J5IGN5Y2xlcyBwZXItcGFj a2V0IHRoYXQgY2FuIGFsbG93IA0KPiBzdXN0YWluZWQgd2lyZS1zcGVlZCBwZXJmb3JtYW5jZS4g IERpZmZlcmVudCBOUFUgDQo+IGFyY2hpdGVjdHVyZXMgYXJlIG1vcmUgZmxleGlibGUgdmlzLWEt dmlzIHRyYWRpbmcgb2ZmIHBhY2tldCANCj4gZm9yd2FyZGluZyByYXRlIGZvciBmdW5jdGlvbmFs aXR5LiAgSW4gdGhlIGNhc2Ugb2YgaGFyZC1jb2RlZCANCj4gZm9yd2FyZGluZyBBU0lDcywgZXh0 ZW5kaW5nICJmYXN0IHBhdGgiIGZ1bmN0aW9uYWxpdHkgbWVhbnMgDQo+IHJlcGxhY2luZyBsaW5l Y2FyZHMuDQo+IA0KPiAiU2xvdyBwYXRoIiBmb3J3YXJkaW5nIGlzIGltcGxlbWVudGVkIGluIGdl bmVyYWwgcHVycG9zZSANCj4gQ1BVcy4gIFVzdWFsbHkgdGhlcmUgaXMgYSAyLTMgb3JkZXItb2Yt bWFnbml0dWRlIGRpZmZlcmVuY2UgDQo+IGluIHBhY2tldCByYXRlIGJldHdlZW4gInNsb3cgcGF0 aCIgYW5kICJmYXN0IHBhdGgiLg0KPiANCj4gVGhlIGdvYWwgaXMgZm9yIDk5Ljk5OSUgb2YgcGFj a2V0cyB0byBzdGF5IGluIHRoZSAiZmFzdCANCj4gcGF0aCIuICAgIElmIHVzZQ0KPiBvZiBhbiBJ UHY2IEhvcC1ieS1ob3Agb3B0aW9uIGJlY29tZXMgY29tbW9uLCB2ZW5kb3JzIGhhdmUgdG8gDQo+ IGltcGxlbWVudCBzdXBwb3J0IGZvciB0aGF0IGluIHRoZSAiZmFzdCBwYXRoIi4gIEJ1dCB0aGVy ZSBpcyANCj4gYSBjb3N0IHRvIHRoYXQsIGFuZCBpdCB3aWxsIHRha2UgYSB3aGlsZSB0byBkZXBs b3ksIHNvIHlvdSANCj4gaGF2ZSB0byBiZSByZWFsaXN0aWMgYWJvdXQgaG93IGVhc3kgaXQgaXMg dG8gaW50cm9kdWNlIG5ldyANCj4gSG9wLWJ5LWhvcCBvcHRpb25zIHRoYXQgd291bGQgZ2V0IHVz ZWQgb24gYSBub24tdHJpdmlhbCANCj4gZnJhY3Rpb24gb2YgcGFja2V0cy4NCj4gDQo+IA0KPiBS ZWdhcmRzLA0KPiANCj4gLy8gU3RldmUNCj4gDQo+IA==