From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0088.outbound.protection.outlook.com [157.55.234.88]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 84D0A21F512 for ; Mon, 16 Nov 2015 04:22:29 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=kevin@darbyshire-bryant.me.uk; Received: from [IPv6:2001:470:183f:da2b::632f:a7da] (2001:470:183f:da2b::632f:a7da) by VI1PR07MB0941.eurprd07.prod.outlook.com (10.161.110.146) with Microsoft SMTP Server (TLS) id 15.1.325.17; Mon, 16 Nov 2015 12:22:24 +0000 To: Jonathan Morton References: <5638A4F4.2010701@darbyshire-bryant.me.uk> <87si4nntcg.fsf@toke.dk> <0196FDEC-50A7-4ECA-9973-1FD23FF2945A@gmx.de> <877flznq3f.fsf@toke.dk> <848953E5-8571-4B81-B67F-D4A7BA4A1F96@darbyshire-bryant.me.uk> <8737wnnpco.fsf@toke.dk> <563B86D4.6030704@darbyshire-bryant.me.uk> <563F21AE.5040506@darbyshire-bryant.me.uk> <56408DAB.6080106@darbyshire-bryant.me.uk> <0B75A2D1-80FC-4499-8DCD-FC2C4E150448@gmail.com> From: Kevin Darbyshire-Bryant X-Enigmail-Draft-Status: N1110 Message-ID: <5649CA7A.5060706@darbyshire-bryant.me.uk> Date: Mon, 16 Nov 2015 12:22:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0B75A2D1-80FC-4499-8DCD-FC2C4E150448@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090202030604080001020105" X-Originating-IP: [2001:470:183f:da2b::632f:a7da] X-ClientProxiedBy: VI1PR07CA0033.eurprd07.prod.outlook.com (25.163.160.171) To VI1PR07MB0941.eurprd07.prod.outlook.com (25.161.110.146) X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0941; 2:4xcEC5DjvNm2OTUWs7oqTEv17CmMvS0yEhYscyNJGAOdoVuowW+tTDfWOLGdcXgDA99mwzg25XaD5dArC45PAcBhRtaAwVRRBhRuKx0cg/yIxHlR7U386jKpPBoNVjS7f2/lvSRBg8OrlVDcfMQQfDaR1ksSjAQlsau20tmdE2Y=; 3:1C4ZPz9gX4A81bQGeFnumYBSjJZH5ZdWTvAXcljs5F0VhidK1xjv1D9GP9aak/i2DZJQX2Z9/32Y9xrdI6wOTJzoRxuiv1R4PEFlLMDs5vHYVlbriRaR75vUb9QQ8osw6NzEDwe4w851gisE2QPYgw==; 25:Q8IqONNVVRl3uxgSmm80MjqBSR4Au9APM+Pz+uzWZq2XzggnHg2jr/kS2JdfSZOTyQSUC44vCKAokF2Tb6VdGR0GlXgXvC3YYvgppqxoeTH7QFwnoFaXBLdrX/2QkidiUuGdEk7z5duxxGnsUS0sk92uvEI9SYRMXsDQfaBvt2u7p6LGhexr+lHqtPizeJ7VJply6b6rOmZIxpdhUcIwKfFhLFwz5N9uGulYmM35YKqaWzNWPd/5AIkH+nksHWb9Z/L/WYRas9xydVKumahdGw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB0941; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB0941; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB0941; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0941; 4:IcEcayOHUG3G/hk7N5AOSzHEpTIs0C92nwaQH8Nh/y10TbpA1ri6o+JCPgr5O2pTHSulok0nXP2xrG4K8xRklkrkQpLQvPfVaKLf1zp2QkUyPlAocquWEmxawrAxzQnuu/wrMAVJhp0/e0LQJbprd0TyXleT9+DYm7zJTEAQVFlxTe3TwLm2soWwmFoax2aulZOKD1W6LrVEj1pCtXL+MeIWvI7v2KUvT0I0Ax+NvJIEGEapRwglvokWs5uiSDGoEaj53K7qFSSOKV9J4ieosyr9sX+t5TQ7FRSqrwrYbbtxBLZ801en3ObusgjphnrycN2P+ebL9CvlMdI7Ebfumnud3hZM57WZboNLJtJNwSdXO/VnN8+nIHZH6yS1yX8X X-Forefront-PRVS: 0762FFD075 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(199003)(24454002)(189002)(110136002)(5890100001)(101416001)(2950100001)(36756003)(93886004)(5007970100001)(5008740100001)(87976001)(105586002)(50986999)(87266999)(33656002)(64126003)(84326002)(586003)(65816999)(4001350100001)(76176999)(77096005)(54356999)(5001960100002)(81156007)(5004730100002)(86362001)(42186005)(83506001)(568964002)(189998001)(59896002)(74482002)(65956001)(106356001)(97736004)(65806001)(40100003)(1411001)(19580395003)(19580405001)(92566002)(512944002)(80316001)(122386002)(3826002)(5001840100002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB0941; H:[IPv6:2001:470:183f:da2b::632f:a7da]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: darbyshire-bryant.me.uk does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR07MB0941; 23:Zr1j6/0LJPKrXtQCmCr3l9X1C1gpidM9sInO2JgSv?= =?us-ascii?Q?9Khg2++mKVo5keK9gnzvUp3bGbrWQ8LYEMllVCJ2IrkvHDVIyF+p5H1vgS87?= =?us-ascii?Q?i/+pzejpEi8Bf3aPK9712uJ8pJL6OBFqN3GAy2j2a9MaCBb7Z5IHdQdg9F6P?= =?us-ascii?Q?+EHsm8eFABH3OgxmB3BxLIEG6KUL4ghAci4dJp2sRSO6oVKhKwNwkcT5CIT0?= =?us-ascii?Q?6p46qKRNH31a2P6tjo97Fd/GrFE05t+9DeiZaeTWHz9sAwxtw+POavI/NWfE?= =?us-ascii?Q?6W8cxfN6NBT2n7fYOLkH6VN0ShiZk0Tk/g5+7UHhVdO6csoINawBvurEaxHF?= =?us-ascii?Q?mIn+mKc1lGmLOMf/u8p2k5PLv4vESs2KPTkNHWl/UNXjxn4bqDky+tv6A/xJ?= =?us-ascii?Q?Z9PmD1yNpPr4kS+pE2/L+jnZoeMqqd4qeBESVgxkiYZv69EBCZ0DkWbKTAzL?= =?us-ascii?Q?4TfRFTPPlxfuJJzxGVuncx4R99ewv6QbZkzo+zdyiAThPJIPBnH6VOt7pi/j?= =?us-ascii?Q?7AZRr9b9uskOLwU9Pv1G7CElUx0olFWD1LKLu3s1gT23mczUHWXuWx6v87l6?= =?us-ascii?Q?HQp2NzVEr6jpDaC+IMrPHEgobOH+UgOB2inBHg/ajiNkYE4eVSNgQK3ikSRm?= =?us-ascii?Q?yVtcrFHYDDAbqg6MhEAMlzNDm0Csc0BrGPjpbpBQc6pqL6QlUGMsmi0NtEGC?= =?us-ascii?Q?OdhsvjzA/mcgWKzjo2e8QwIo+JKtps2PfnDbz053yzmsjIcLZ592T57gDwye?= =?us-ascii?Q?POasx/lqthTdQMgamqfRv0irwDR/sSuPG78Gx3/XaTcO2J3tK6Gdec/AA5Jj?= =?us-ascii?Q?c2o1IcU+DxkfkScYa5LoVm0OJ/USttnynAKVe732BXIyRq9+xGNJR4nIQOXV?= =?us-ascii?Q?nmbAOrmUSl6fe5D4pS70hy81IilXNGivRHSr1lTgJend5XDp0bwFYqzFm/CW?= =?us-ascii?Q?Rwgnl5k0kVt6YLZ/Fzuq9cfZTScW9ndWym8SWJUbNo02awDvMNxAst9BGL2x?= =?us-ascii?Q?lPFwm5coN/TDBQxq3hMCqvNvX4avGa7ZVTumj7UB45WDOjh2dKqUHaf65zF+?= =?us-ascii?Q?24AuyM5CDTcpPeAoA+0VtQTBwkca2h4mYBLZwmrdOgzXKXiYdMdakZRKwhZ9?= =?us-ascii?Q?1xcXXmmq8XTuKs6d813fOscjzAU1gG0UivI1+pAzh0d7J31zI9kSLpBlrYIo?= =?us-ascii?Q?TBuoyC1mMRYzSBHPAJX/nD+e567E0hBG+waFxg9HEeHGdg2Th+yVJtLUq8rt?= =?us-ascii?Q?cG2f7xQnLpJfNxSo2Ti3kn8Ml8tbVVRqbKo/xcSpdM1wkT2BZS0SdGORXa6t?= =?us-ascii?Q?bC6GEZcUt0qhQJ2uAli/yg=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB0941; 5:ULBLkJL/AXNON3LWtREfBp6i50mH4xFRP0bsEGDLstuPKXRqu2NSwzVdK5GFYZbaTYVgEarUV9gzZ45bP4pmQw3pGjOiQctdARGVsC0um9mj8Dacm+x0QuHazfJwSonlqv7VV/7XYbGrXvqRZR9iJg==; 24:5MG7RBL8DGnGeNxWcYS8HmsNicMd9pH++aT0dgQnzc65WMXmYIsmxYHTyNLlxroZU8PT69l7xB76m0pzXaqfgB1dUg2D9h31bANCbT0lsBI=; 20:M1G3iFDopjP0UmJgHlVQ5VaVp4HyPR2cnuG8qwTlUYtoiWu31xMjqjy1nyGOwRs+TgQm0XpoyQhdgbKpR52Xwg== SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: darbyshire-bryant.me.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Nov 2015 12:22:24.0791 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB0941 Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] More on 'target' corner cases - rate/target/interval confusion? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 12:22:52 -0000 --------------ms090202030604080001020105 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I've had a long think :-) On 09/11/15 15:07, Jonathan Morton wrote: >> On 9 Nov, 2015, at 14:12, Kevin Darbyshire-Bryant wrote: >> >> In the presence of a full link, that link having competing =91full' fl= ows in all 'tins', then how should cake split the link in terms of bandwi= dth? > That=92s a good question, and one that I think becomes more critical at= low bandwidths. I=92ve tended towards generous allocations for that rea= son, so as to avoid causing trouble to low-latency applications. > > The main requirement I keep in mind is that an application should not b= e able to guarantee itself an excessive bandwidth share simply by selecti= ng a particular DSCP. At the same time, there are applications for which= a relatively large, consistent bandwidth is a requirement for satisfacto= ry performance (consider streaming video), such that best-effort traffic = should defer to them. These are conflicting requirements, so a compromis= e has to be established somehow. > > The current thresholds are at 100%, 15/16, =BE and =BC. Under saturate= d conditions, this gives throughputs of 1/16, 3/16, =BD and =BC. The =93= video=94 class (Tin 2) can usurp =BE of the bandwidth when competing agai= nst any mixture of best-effort and bulk traffic. This, admittedly, might= turn out to be too much, so I could consider setting Tin 2=92s threshold= at =BD instead of =BE. Indeed it is a compromise :-) Personally I think 3/4 for video is too much. Experimentally I found I could significantly reduce bulk & best effort (down to 1/16th ish) by having video & voice tins fully active.=20 So I tweaked my cake thresholds to set video to 1/2 rather than 3/4 as you suggested. Video & Voice can gang together to claim 3/4 bandwidth still leaving 1/4ish to be battled between bulk & best effort, this is in my opinion is much better than before. Without a full voice tin, video could only claim 1/2 in the presence of best effort traffic.=20 There comes a point where the link bandwidth is so low you have to ask if you're being realistic in trying to run video over it :-) > And yes, I have long noticed that Flent=92s standard RRUL test doesn=92= t use Tin 2 at all. > >> With each increasing priority of tini[0-3], we decrease the 'expected'= bandwidth (good) but also as a result increase the target and interval. > Yes, there are a number of counter-intuitive things happening here. > > Most of Cake=92s latency-reducing power comes from the liberal applicat= ion of flow isolation, *not* from AQM itself. Diffserv prioritisation pl= ays a lesser role, and mainly has to do with restoring the desired alloca= tions of bandwidth, replacing the reliance on measure queue fill level th= at some protocols presently use to stay out from underfoot. Both these m= echanisms primarily control the effects that one flow can have on another= , and say little about the latency that a flow causes to itself. > > This latter is the domain of AQM, specifically Codel, which is what we=92= re talking about when we mention =93interval" and "target=94. As I menti= oned elsewhere recently, Codel is designed specifically to give congestio= n signals to TCP-like flows, and deals rather less efficiently with unres= ponsive and anti-responsive flows, which as a result tend to spend some t= ime bouncing off the queue=92s hard limit until Codel finds the correct o= perating point to control them. There are other AQMs which are designed = with unresponsive flows more in mind, but which somehow perform less well= with TCP-like flows. > > A key design principle of Codel is that no packet whose sojourn time is= below target will be signalled. However, if the sojourn time is consist= ently above target, signalling begins and increases steadily in frequency= =2E It is also a fundamental truth that if it takes longer than target t= o transmit the previous packet, the following packet can have a =93conges= ted=94 sojourn time even if there is consistently precisely one packet in= the queue (which is the ideal state). This is why I constrain =93target= =94 to be at least 1.5 packet times at MTU; the difference can be substan= tial at low bandwidths. > > But there are subtleties here too. > > If there are multiple flows, isolated into multiple queues, then the ef= fective packet-to-packet time for each queue will be increased proportion= ately. Early versions of Codel refused to signal on the last packet in t= he queue, to account for this. However, if there were a large number of = occupied queues, this meant that the minimum queue fill could be rather h= igh, and this seemed to lead to high induced latencies in fq_codel under = heavy load. Due to the statistical multiplexing effect, it turned out to= be sufficient to tune =93target=94 as above for the final output bandwid= th (even though this is unknown to fq_codel) and to remove the special st= atus of the last remaining packet. > > The same logic could naively be applied to traffic in separate tins. H= owever, unlike queues for flow isolation, bandwidth is not shared evenly = between tins. More subtly, traffic characteristics also differ - low-lat= ency traffic tends to be unresponsive to TCP-style congestion signalling,= and dropping any of it tends to reduce service quality in some way. Not= e that network-control traffic (most relevantly NTP) falls into the =93vo= ice=94 category. Since unresponsive flows aren=92t what Codel is meant t= o deal with, the mere fact that =93target=94 is higher is not meaningful = - and in any case this has no effect on the primary flow-isolation mechan= ism. > > The tin-specific tuning of target and interval was introduced when Cake= had a separate hard shaper per tin. It was the obvious design at the ti= me. Now that Cake uses soft shaping between tins (allowing any tin to us= e the full link bandwidth if uncontended), it=92s possible that choosing = identical target and interval for all tins might suffice. Alternatively,= we might choose an even more conservative strategy. > > But which - and how do we decide? I've no idea! I tried the following experiment: set ingress & egress b/widths to 2mbit & 448kbit respectively (like my parents adsl...on a good day) Ran a 'rrul8_splittin' and noted ping box_plot for each tin - EF was about 30ms higher (120ms) than CS3 (90ms) Thinking I'd found a smoking gun and that 120ms was quite close to the EF target of 140ms I tweaked code to copy tin 0 target across all tins, uploaded,flashed etc etc, re-ran test......and........ ..... ..... it barely made any difference at all! Conclusion 1 - more testing required. conclusion 2 - my testing strategy is flawed. conclusion 3 - as you said, flow isolation is more important than excessively messing with targets and intervals ;-) > > As a final point, I haven=92t even mentioned =93rtt=94 as the user-spec= ified input to this mayhem. That parameter must be understood to be *sep= arate* from both =93target=94 and =93interval=94, even though Codel speci= fies the latter to be related to expected RTT. Simply put, the user tell= s us what the expected RTT is (on the understanding that an order of magn= itude variation either way is typical), and we calculate =93target=94 and= =93interval=94 to be as consistent with that estimate as is practical, g= iven the link bandwidth and other constraints that he has also specified.= So there is a firm conceptual distinction between the user=92s intent a= nd the implementation details. > > - Jonathan Morton > --------------ms090202030604080001020105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DYEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB0UwggYtoAMCAQICAw5ySjANBgkqhkiG 9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE1MDYyMDIw MzA1MloXDTE2MDYyMDE0MjY0N1owVjEmMCQGA1UEAwwda2V2aW5AZGFyYnlzaGlyZS1icnlh bnQubWUudWsxLDAqBgkqhkiG9w0BCQEWHWtldmluQGRhcmJ5c2hpcmUtYnJ5YW50Lm1lLnVr MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAugCNtDhytCJ9HOfenUHr/vUGUECv PL1IJXgHMl4cIJmwgLOkXhIcTMxHnX+kFweqvT+eDWv1hzA9yMWhvjLFC4eLoFaV0xiAat8O XQ7t3MwKY5DW0mB1dOnjiFIcc/XMwyYI4KfEGnFMJQkzon0rDVpkl/Q1f/hu1sELO7Zc6TFL wuuDuiP7S73zrz50TRoq0+Ob3x0uOMW2uVwVzf6NLwHgBE2LFleMXblyUMx0IlIcLan2nWiI Vsa3XYd+C6KAGGwlmO4VAZ25KuX7hkj8f82lSapvtKTtvrSoDghXlHH2JXiIQX+Sn0UgOmbX 1KyOe9vN7WzQ+tpPRzpFRffnnnp1VQye3wVRPBumjDxQSFTOhUtslnvbefUQSPw6p5w9ZiXI GJICLkX/MkYN/TwGCvuUG2PxBybSR1A2I5ap+VI/zGSG3XGVEA69SOZQyD+8YjJZfaY2nCu+ DuM64JrJUi2CvX6fwcdHNschJNrrfetpnrx3JrGnG9o+pWuUG1phBg+KKN2bhrdzY79qm7ha 86EMKSUOn5nBdGY3YxdXq/naoUQeOCUV2JMFGOulu7sKpiWcz7HVFacXjd9ebisVLv+jOwll z14BWRb87s1+LBEJn/Ybn3ekhtgyEAhB4kgj0scl4hI8xCU6zrZyDnbXmxSvDXbClZA0PACt f/jhGvUCAwEAAaOCAuMwggLfMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQG CCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQULkW2CpDiQpRNumQ7wdspjFfgX+AwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKAYDVR0RBCEwH4Eda2V2aW5AZGFyYnlz aGlyZS1icnlhbnQubWUudWswggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIB KjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYI KwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEg VmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVs aWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0 aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDov L2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2Nh MEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3Mx LmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0G CSqGSIb3DQEBCwUAA4IBAQBicQWe98eF/o09TXFsExc+WSyYjt3oSnXyocLzXQp82CQhIg21 5RqNZ1e+hsO7tq8S6hdItUDbKpecpIV59+57ke1zVl2slTRIT19fhYINHH78rVVRPzuHoiDt MXnGrp9hbq3Cz8P4mm8INKDiYK46kyplRAQ3ZMouPG1lsnDzgQAvbCj74H8yAp7fK8if6cxs 28BCUmdP8D3c6M1ffdNNaqNT+4Z3mtOujXXg7zOfmXN0Zg/mEtZ0NrWE2uICGdWjTv9KZiI7 fi4hk2CRpCL63qzmu6BwtcgtwhgYYtuAk2N43+SiyDkyLKGAcjEor3t5f9HivN29E0F0MXTH 1OdgMYIFDTCCBQkCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQID DnJKMA0GCWCGSAFlAwQCAwUAoIICSTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTExMTYxMjIyMThaME8GCSqGSIb3DQEJBDFCBECGsNqZMQGlIc9I3Cy1 B0O0whdc1RKTETLesjC0Cyl9S2UYaIvbvySIDAkACanUhiutR1py6Qoeo5jm/7VOCL9EMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw gaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2 BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB AgMOckowgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln bmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAw5ySjANBgkqhkiG9w0BAQEFAASCAgCRG8zYTIXWCTWart3FVv7z1gGz00fJ amN28K6S2afvbNNe1++kwwmJ4g/CnZcEL64gT3wKeArADsFAtZFFOqr4athVosnHEWue5KNR GkHMCX+UsMpfL9yzLNd2Nl7G8YO52hUQcaPqiT/YhvGXr0rpX14aR6JhmqFMNp8EtZhYmIs9 Vq9Ddoawx35PTPq2DH21AmpxLFsJMtTHJyiHSADv2YXI5/RK9NtIQVY55XNYXd6/uf/9MArG gIdI3K/crO9pXbJWp8YlO7G4ln/n4mK6wE8gUSK/Wudu3HElWW34GmZphX7LFOLs0PQvfa6w 62BSKWKY/5MQSpd4h8IohnPmIOMPUrCqKNHeh1wgska8P/svnHzdgGFf08xzQ0c5D51yEqOf FK3rxXgmZFbumCoF544rOeqvxgdzLtYsntXz+yvFgyxMp7Rx5Wk1YfZIiDLQMR+aQzsJe7tT hj35TC+F5yLmvdu/37c95D29iMOF3B2+UNdYHVLCXiksYl1Y+dDfZrMeM21H8+zscJUORg0W xa+tuUk6WSlMGh67Xqi8wiJRFZEgDGab+i14OTZI5OQ8IMWQmJ9bC5+UNrXSyF8iB05GCr1P cMo/GkXZqKjZrvs6/Y3d0RsSRRAgEdzEWDD6M8wX0x9rkBPeCzFd6PR6FTAeFSeV5fe+4sKn SyxieQAAAAAAAA== --------------ms090202030604080001020105--