From nobody Thu Nov 1 03:49:15 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FA1130934; Thu, 1 Nov 2018 03:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouq87ys4gqBp; Thu, 1 Nov 2018 03:49:02 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15DE3127B92; Thu, 1 Nov 2018 03:49:01 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id wA1Amu91017623; Thu, 1 Nov 2018 11:48:56 +0100 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 6AF361D53C1; Thu, 1 Nov 2018 11:48:55 +0100 (CET) Received: from 79.158.50.20 by webmail.entel.upc.edu with HTTP; Thu, 1 Nov 2018 11:48:56 +0100 Message-ID: In-Reply-To: References: <26ed385e2f00a41e717a9d4b4043f9b9.squirrel@webmail.entel.upc.edu> Date: Thu, 1 Nov 2018 11:48:56 +0100 From: "Carles Gomez Montenegro" To: "Yoshifumi Nishida" Cc: "tcpm@ietf.org" , lwip@ietf.org, jon.crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.99.2 at dash X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Thu, 01 Nov 2018 11:48:57 +0100 (CET) Archived-At: Subject: Re: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 10:49:05 -0000 Hello Yoshi, Sorry for the late reply, and thanks a lot for taking the time for your review and for providing comments. Please find below my inline responses: > Hello, > > I've read the draft and I think the draft looks fine and mostly ready. > I have some comments below.. > > 1: Section 4.2.4: > "In that case, RTO algorithm tuning may be considered, although > careful assessment of possible drawbacks is recommended" > > -> It might be better if we refer draft-ietf-tcpm-rto-consider here > although it is not very certain the draft will be published at this > moment? It seems to me the motivation of the doc fits the situation > like this. I agree. I guess we may cite draft-ietf-tcpm-rto-consider as an informative reference for this section. > 2: Section 4.3.1: > "These algorithms work efficiently for window size of at least 5 MSS" > > -> Just curious why this is 5? Is it because the use of delayed ack is > presumed? > A receiver may have a chance to send an ack for segment 1 before > segment 3 arrives. Yes, the text was written under the assumption that delayed ACKs might be in place. In the next revision we will explicitly indicate the assumption, and update the related text as per your comment. > 3: Section 5.3 > CCN -> CNN? Thanks for catching the typo! > "This overhead could be reduced by TCP Fast Open (TFO)" > > -> Yes, but the use of TLS is not mandatory in this draft. If an > implementation utilizes TFO, we might want to mention about app level > idempotency here. Not sure I'm following you here. Could you please elaborate? > "TCP keep-alive messages are not very useful to..." > > -> We don't need to discuss reducing the interval of keep-alive here? Currently, we have some text on this, although I agree it is a bit too indirect. In the next revision, we will elaborate further. Once again, thanks for your comments. Cheers, Carles > Thanks, > -- > Yoshi From nobody Thu Nov 1 07:47:57 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CD912777C; Thu, 1 Nov 2018 07:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZtIe2QJHyDx; Thu, 1 Nov 2018 07:47:43 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A543129C6B; Thu, 1 Nov 2018 07:47:43 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 0C5A725A15; Thu, 1 Nov 2018 15:47:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1541083661; bh=qmOHYklV5uJ5QfrfBlhFZYjA3HU/DGP3Ui+qxRv30yI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=b9OUZsMsFcQE8SZzW7P1WgwON4mhZ3twGdjYKjTFYWuicxyNOlHXll+fbm+kGxK8S 0yv+ZpO58baBxVHP/RLiav8RBC3EEN6gX4RX3IsAqJJrb9Qf4nXw8kLea78jdG2mNn UpjA9YVbnRano8ESEY5OW2mJonkvaUxJP9wGScG0= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m12XlvZORKBQ; Thu, 1 Nov 2018 15:47:41 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.hs-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 1 Nov 2018 15:47:41 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.25]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Thu, 1 Nov 2018 15:47:40 +0100 From: "Scharf, Michael" To: Yoshifumi Nishida , "carlesgo@entel.upc.edu" CC: "lwip@ietf.org" , "tcpm@ietf.org" Thread-Topic: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt] Thread-Index: AQHUX5OV8O3hLD7KpEaq0Dr7QoOm7KU1l8cAgAWG19A= Date: Thu, 1 Nov 2018 14:47:40 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D14760C@rznt8114.rznt.rzdir.fht-esslingen.de> References: <26ed385e2f00a41e717a9d4b4043f9b9.squirrel@webmail.entel.upc.edu> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 14:47:48 -0000 Chiming in... > 3: Section 5.3 > CCN -> CNN? >=20 > "This overhead could be reduced by TCP Fast Open (TFO)" >=20 > -> Yes, but the use of TLS is not mandatory in this draft. If an > implementation utilizes TFO, we might want to mention about app level > idempotency here. We could add the following two sentences from RFC 7413 at the end of the pa= ragraph: "However, TFO deviates from the standard TCP semantics, since the data in= the SYN could be replayed to an application in some rare circumstances. Applicat= ions should not use TFO unless they can tolerate this issue, e.g., by using T= ransport Layer Security (TLS)." =20 > "TCP keep-alive messages are not very useful to..." >=20 > -> We don't need to discuss reducing the interval of keep-alive here? We could add the following sentence (again adapted from RFC 7413): "Sending TCP keep-alive probes more frequently risks draining power on mo= bile devices [MQXMZ11]." I am not sure how much more guidance we could give on picking an interval. And the document already explains the benefits of application-layer heartbe= at messages (if applicable). Michael From nobody Thu Nov 1 16:12:37 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F67512D4EC; Thu, 1 Nov 2018 16:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DIv-Zc9PtDo; Thu, 1 Nov 2018 16:12:24 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9145812D4EA; Thu, 1 Nov 2018 16:12:24 -0700 (PDT) Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4E0DB2786C7; Fri, 2 Nov 2018 08:12:22 +0900 (JST) Received: by mail-it1-f176.google.com with SMTP id e74-v6so866878ita.2; Thu, 01 Nov 2018 16:12:22 -0700 (PDT) X-Gm-Message-State: AGRZ1gJYfktCDnu3pV1HyutnS7lT1dY3lsh35nFplJcT7u/Uw5b1rN2d zD2DzLzwA5PsQKFVs+LqKlnVoqmPnQ0NkzCV39s= X-Google-Smtp-Source: AJdET5coIBzPvNB3tuj8RXrRJWy0oPjCI/tF+9O2JWHzZkQdDDUg2N6cJBm01j5erqWJ83aFutI8zvyET6DwsG+TKAc= X-Received: by 2002:a24:36d2:: with SMTP id l201-v6mr7961210itl.130.1541113940661; Thu, 01 Nov 2018 16:12:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Thu, 1 Nov 2018 16:12:09 -0700 X-Gmail-Original-Message-ID: Message-ID: To: ianswett=40google.com@dmarc.ietf.org Cc: Yoshifumi Nishida , jri.ietf@gmail.com, "tcpm@ietf.org" , quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000fddd190579a28ce7" Archived-At: Subject: Re: [tcpm] questions on draft-ietf-quic-recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 23:12:28 -0000 --000000000000fddd190579a28ce7 Content-Type: text/plain; charset="UTF-8" Hi Ian, Thank you so much for the detailed response. Things are getting clearer to me now. I will need to have some time to think about some of them, but I would like to comments on the following points. Also, I am very sorry that I have mostly read -15 version and didn't have enough time to check -16 carefully (so, my question on 4.5.7.3 was wrong) . I will try to re-read -16 before the meeting. On Tue, Oct 30, 2018 at 6:34 PM Ian Swett wrote: > > Thanks for your careful reading, answers inline. > On Mon, Oct 29, 2018 at 1:03 PM Yoshifumi Nishida wrote: >> Section 4: >> QUIC supports both ack and timer for loss detection. >> But, it's not very clear whether an implementation can choose one >> of them or it should implement both and can use both at the same time. >> Can it be clarified? > > Yes, there's an open Issue to clarify this. https://github.com/quicwg/base-drafts/issues/1212 > > The outstanding PR is quite old, but has some helpful clarifications in it, so I'm intending to migrate the best parts to a new PR. Suggestions(or PRs) welcome. I don't have explicit suggestions for now, but I guess we will need to think about the following 2 questions. Q1: Should implementations should support both modes or are they allow to support only one of them? Q2: An implementation that supports both modes can activate both logics at the same time or the mode should be used exclusively? I think these questions will lead to another question: How much freedom implementations should have. For example, how much implementations should follow the pseudo codes. >> Section 4.2.2: >> The early retransmit logic in QUIC seems to be different from TCP's one. >> It doesn't look ack-based as it relies on timer. (I don't say this >> is bad, but it's a bit strange to categorize it as an ack-based >> method) >> TCP's early retransmit will be triggered only when the amount of >> outstanding data is less than 4*SMSS, but this draft doesn't mention >> about the condition. Is there any reason for it? >> when timer-based loss detection is used, it this logic still >> available? or it won't be used with timer-based loss detection? We >> might need clarifications here. > > > The timer is taken from Linux, as mentioned at the end of 4.2.2. It's categorized as ACK based because it is only armed when a packet with a larger packet number than the one being lost has been acknowledged. One could argue the same issue for time based loss detection, which also needs a timer. > > Instead of 4*SMSS, we specify kReorderingThreshold, since it seemed like the core issue being fixed was that there was no other mechanism for quickly declaring these packets lost, and if one did implement adaptive reordering tolerance, one threshold wouldn't be out of sync with the other. > > The intent is that like RACK, timer based loss detection subsumes early retransmit. But yes, this text could use some further clarification, including and not limited to items pointed out in #1212. Hmm... but, as you implement the logic in such a way, I think the current early transmit logic in the draft is similar to the TLP logic in the draft. If time_reordering_fraction is 1/8, it seems to me they are mostly identical. (Well, one may say this is a natural thing because early transmit and TLP is aiming similar goal) I might still overlook something, but it seems to me that the ack-based scheme in QUIC just looks the time-based scheme in QUIC + retransmission scheme with dupack threshold. But, in this case, I am wondering that it may be enough just to have ack-based scheme. BTW, the original early retransmit in RFC5827 is to reduce dupack threshold (kReorderingThreshold in QUIC) when outstanding data is less than 4 *SMSS. Another condition is to activate only when there's no data to be sent in the queue. I am thinking there would be a way to do this type of early retransmit in QUIC by tweaking reordering_threshold although I probably don't recommend it. Thanks, -- Yoshi --000000000000fddd190579a28ce7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ian,

Thank y= ou so much for the detailed response. Things are getting clearer to me now.=
I will need to have some time to th= ink about some of them, but I would like to comments on the following point= s.
Also, I am very sorry that I have mostly rea= d -15 version and didn't have enough time to check -16 carefully (so, m= y question on 4.5.7.3 was wrong) . I will try to re-read -16 before the mee= ting.

On Tue, O= ct 30, 2018 at 6:34 PM Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> w= rote:
>
> Thanks for your careful reading, answers inline.
&= gt; On Mon, Oct 29, 2018 at 1:03 PM Yoshifumi Nishida <nishida@sfc.wide.ad.jp> w= rote:
>> Section 4:
>> =C2=A0 =C2=A0QUIC supports both ac= k and timer for loss detection.
>> =C2=A0 =C2=A0But, it's not = very clear whether an implementation can choose one
>> of them or = it should implement both and can use both at the same time.
>> Can= it be clarified?
>
> Yes, there's an open Issue to clarify= this. =C2=A0https://github.com/quicwg/base-drafts/issues/1212
= >
> The outstanding PR is quite old, but has some helpful clarific= ations in it, so I'm intending to migrate the best parts to a new PR.= =C2=A0 Suggestions(or PRs) welcome.

I don't have explicit sugges= tions for now, but I guess we will need to think about the following 2 ques= tions.

Q1: Should implementations should support both modes or= are they allow to support only one of them?
Q2: An implementation that = supports both modes can activate both logics at the same time or the mode s= hould be used exclusively?
I think these questions will lead to a= nother question: How much freedom implementations should have. For example,= how much implementations should follow the pseudo codes.

>> Section 4.2.2:
>> =C2=A0 =C2=A0The early ret= ransmit logic in QUIC seems to be different from TCP's one.
>>= =C2=A0 =C2=A0It doesn't look ack-based as it relies on timer. (I don&#= 39;t say this
>> is bad, but it's a bit strange to categorize = it as an ack-based
>> method)
>> =C2=A0 =C2=A0TCP's e= arly retransmit will be triggered only when the amount of
>> outst= anding data is less than 4*SMSS, but this draft doesn't mention
>= > about the condition. Is there any reason for it?
>> =C2=A0 = =C2=A0when timer-based loss detection is used, it this logic still
>&= gt; available? or it won't be used with timer-based loss detection? We<= br>>> might need clarifications here.
>
>
> The tim= er is taken from Linux, as mentioned at the end of 4.2.2.=C2=A0 It's ca= tegorized as ACK based because it is only armed when a packet with a larger= packet number than the one being lost has been acknowledged.=C2=A0 One cou= ld argue the same issue for time based loss detection, which also needs a t= imer.
>
> Instead of 4*SMSS, we specify kReorderingThreshold, s= ince it seemed like the core issue being fixed was that there was no other = mechanism for quickly declaring these packets lost, and if one did implemen= t adaptive reordering tolerance, one threshold wouldn't be out of sync = with the other.
>
> The intent is that like RACK, timer based l= oss detection subsumes early retransmit.=C2=A0 But yes, this text could use= some further clarification, including and not limited to items pointed out= in #1212.

Hmm... but, as you implement the logic = in such a way, I think the current early transmit logic in the draft is sim= ilar to the TLP logic in the draft.=C2=A0
If=C2=A0time_reordering_fraction is 1/8, it s= eems to me they are mostly identical.
(Well,=C2=A0one may say this is=C2=A0a natural thing because=C2=A0early transmit and TL= P is aiming similar goal)=C2=A0

I might still overlook something, bu= t it seems to me that the ack-based scheme in QUIC just looks the time-base= d scheme in QUIC=C2=A0+ retransmission scheme with dupack threshold.=
But, in this case, I am wondering that it may be enough just t= o have ack-based scheme.

<= span style=3D"font-size:13.3333px">BTW, the original early retransmit in RF= C5827 is to reduce dupack threshold (kReorderingThreshold in = QUIC) when outstanding data is less than 4 *SMSS.
Another conditi= on is to activate only when there's no data to be sent in the queue.=C2= =A0
I=C2=A0 am thinking there would be a way to do this type of early retra= nsmit in QUIC by tweaking reordering_threshold although I probably don'= t recommend it.

Thanks,
--
Yoshi
--000000000000fddd190579a28ce7-- From nobody Thu Nov 1 18:12:08 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745E8124BE5 for ; Thu, 1 Nov 2018 18:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FORGED_MUA_EUDORA=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSal4gbP3HXx for ; Thu, 1 Nov 2018 18:12:04 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20096.outbound.protection.outlook.com [40.107.2.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B52120072 for ; Thu, 1 Nov 2018 18:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oheijRrGBLhXi7cDuN8dQP692ThR4F5wP2RCH5K+FLY=; b=UgEABKZ9U7EzK5KAEzs9fYhnDqNlVmKRcXzVrOOAdPL3aVH9PIarRMUiwX6AiySjHcGRg5gTRcUUroOT5UDmoXyTX7LSZfNEW6AtMT2BHxEh6qOrMHr5qOQ5TDKk5HpuKqEnQBJj3Y6udIo+cIg9Ru1d0gMe3+zsCJByis6Rl48= Received: from AM4PR0701CA0042.eurprd07.prod.outlook.com (2603:10a6:200:42::52) by VI1PR0701MB2845.eurprd07.prod.outlook.com (2603:10a6:800:85::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.11; Fri, 2 Nov 2018 01:12:01 +0000 Received: from VE1EUR03FT003.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::206) by AM4PR0701CA0042.outlook.office365.com (2603:10a6:200:42::52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1294.14 via Frontend Transport; Fri, 2 Nov 2018 01:12:01 +0000 Received-SPF: Pass (protection.outlook.com: domain of nokia.com designates 135.245.43.118 as permitted sender) receiver=protection.outlook.com; client-ip=135.245.43.118; helo=us70tusmtp1.zam.alcatel-lucent.com; Received: from us70tusmtp1.zam.alcatel-lucent.com (135.245.43.118) by VE1EUR03FT003.mail.protection.outlook.com (10.152.18.108) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.1294.14 via Frontend Transport; Fri, 2 Nov 2018 01:12:00 +0000 Received: from cliff.eng.ascend.com (cliff.eng.ascend.com [192.207.23.55]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id wA21BvQu017487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Nov 2018 01:11:58 GMT Received: from igoyret-c1.nokia.com (igoyret-pc [135.227.139.12]) by cliff.eng.ascend.com (8.13.1/8.13.1) with ESMTP id wA21IgmH012681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Nov 2018 18:18:43 -0700 Message-ID: <201811020118.wA21IgmH012681@cliff.eng.ascend.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 1 Nov 2018 18:10:41 -0700 To: "Jakob Heitz (jheitz)" From: Ignacio Goyret CC: "tcpm@ietf.org" In-Reply-To: <6ec702c1f6ae426f9b169a035eda5345@XCH-ALN-014.cisco.com> References: <95f4b81948844b2799ecca33450bdde1@XCH-ALN-014.cisco.com> <7597333b9a414761be688375acf48dd6@XCH-ALN-014.cisco.com> <0C168054-E3D6-4BC5-9E1E-A28059F1A27B@strayalpha.com> <12b0f677e60443d8a32b4d56370787d7@XCH-ALN-014.cisco.com> <4C874E0B-BB5D-4765-8A33-3B9C736B646B@strayalpha.com> <68FFD5DF-E6B1-4E3A-B5F7-AB5114DA1BA0@strayalpha.com> <6ec702c1f6ae426f9b169a035eda5345@XCH-ALN-014.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:135.245.43.118; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(376002)(136003)(2980300002)(438002)(199004)(189003)(126002)(81166006)(476003)(5660300001)(106002)(316002)(16586007)(81156014)(956004)(53936002)(76176011)(486006)(93886005)(446003)(336012)(11346002)(86362001)(186003)(97756001)(50226002)(8676002)(50466002)(478600001)(229853002)(97736004)(8936002)(47776003)(44832011)(23726003)(8276002)(9686003)(1076002)(53416004)(46406003)(6246003)(2906002)(6916009)(68736007)(106466001)(4720700003)(26005)(6346003)(356004)(305945005)(4326008)(90706001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2845; H:us70tusmtp1.zam.alcatel-lucent.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-Microsoft-Exchange-Diagnostics: 1; VE1EUR03FT003; 1:cbaPe0wukUBfkxwgTx+PeEHx+injL0w/ws5Ijed+4fUkh6xU8O8cI9c+wIbxFnQFBahqCfUS2Edniqv2gZDQnjiVCK0Y3G4rXGgIFXiF4XtUerxx+3OTHObOgHddGgoM X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4d45e150-77a4-45cc-bd50-08d64060314b X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4608076)(2017052603328); SRVR:VI1PR0701MB2845; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2845; 3:hb4zfjgRT05QnmjC7XFyHjh2UcXaZMAWChAoHD2mlOuplx0xatPLIukuMUYirJyEpxnOOERCW/zUrCTa2jblQuGXYivdao96m4v1QPq+x7YavEQIVQZ+hF+EzgvCTokIbC/E3d+qZCpzw08a4/VMYGBA2nvQRrj9A0GR34nTAhhWNG0BqPF4/3nFTB98JAbR2urwaYSYDyPHP+2jE9jsCgqyByaB6uDzYypeXSE1Ldb5Cs0CDo8Mn5D8eyf0pUcPN0D6SKJtIs1bAahpxGlNFprxduxCyPMgjB/PchTFeS24pj1jwG2SWWSqJo8wAFrwcvuufxPqtI/QOb7L+6EWqPnMv8N9dOU5fpIoaLNyQOs=; 25:zsH3JUgEMJrDruhC+osrsvVOWCuCU/HwvE+XwcACK9i+u0GmfAIgOfl4MWZ3tgN15MY+L14oLOdjKFYcKCdQrXObHid+YqrXqOj08tkFNjd4whhCbNlHwE3Nwr0RCPmJ6atX2fzYf6skiwRK0UrPVEFJwTD164CE6wwGkDGfqACSzAi/p51K4oCWrnoXIGD96F5Ma4M75EOloULwpmJvI31YByMKFtGO+h7+NglkUatmvib503ceKQUEjFc0THfG9WLe6ST+FO6/C0WRvy5yNZLRxEdzZM6JECFJ65hiuNKaTWkHe0xJwWpQkiHOIArUJwkTfObvEGe1gnPrsqejcw== X-MS-TrafficTypeDiagnostic: VI1PR0701MB2845: X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2845; 31:rjXLAaX+TXZdRi0SS76JxjzUjPKWDiq98e8ww1QZM9R8+aVzqGewQYMG1n9buyqYo8AoPq1N8cmVjurTgBhtn0AYyndMBmwkuj7nVdcQcCQiQSQOFAF0Wp/cS+w86upopkxKdA27hHwGVQ3SPfWoQ2SE4ZgGnGLOgC4HwBCdpIqYYQJEX8oJhWec3UhRDDiFXWyrggBqydEQmK2IGTXHawfOAaLP92QTbnyxxqRR5Fk=; 20:ZYksH4eQDDIzAyPh9PJRdO4g9bA/AHXy3U1scyXkva5hQyOqoZkVUL6/QUi5fmvxksM0AjqWMdlPk18CFeYNHFyRwlL2Uu/Zzb83LLTtA1zFml052tbDRdedOgBDhuFtT/PUiZDPm4HJ868VNmVdJQf4k1zYd5bMmIWycE981ABRB5tf/hzLpyUodmoRTunDHoLZfSgy0vCUMKUD+EaUhw/s9g84fD9lw6B32gN++UxdMSdT0eBqF72/olZersYlmdr9dqGz3WIQPiYAN0h+E7+Tg/oC2pWJ9ZON/9kDsR8stiJ5X0+rIIfYIg0oOO1PBN8z6KnrfiJUsr0JuO7uY1HbIcjImFIpyMRvQf1bDzte5k/5FGqyn898+jneeKsDLhrlCQpWmT+j93YE9ApXlOUuQpA58d2q/hgouk9aELdN2Y8gimSfFQgJGhOaRcmvKTZHf0zzL5ja4FReQjiwpbXN9THorTNPsQH95IZmkMRBnHfE/9EljB2XwxrJ9vUXQOunowma/cjIHNZHvfeZJoiICHJoFkTn0cl/UjZ7VbS8XD0gxSfCHxZQxdt/1z5a1MoSKNXKsbOQpIQD6J3kpchsfA7csDd2gSa99Wcq+n4= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(11241501184)(806099)(944501410)(52105095)(93006095)(93004095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2845; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2845; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2845; 4:jda61tONC42QJKfEeEJtvTLLINm14CDTORufWSCvTOVBTOukH/0hQbfIT5CFBDkwY80EGJazxhP2heRa8KXNWPgmz/HOV/SGAekqHux4IB+y/WnX/Qma57idrSIa3EYUey+RVjnfNhYWTwzZZkSVfi9ywr3B1WBqNwPhGXceZnt2dfQVKkTDb2DwO1u/e5KnMQ4FICZW4tUcfOoqegy9OxTrXdEGlbUYbfRbFbqcjO1F2RnDNm9/tg34weq5doz8iYTE3Be4X+92NfH03S8/GA== X-Forefront-PRVS: 08444C7C87 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; VI1PR0701MB2845; 23:pzlk7X7CQj4cT+vyE2Fw/I2ZCGt40Dr9IHTfBMW?= =?us-ascii?Q?fK1nngD27hVwTxlzrgfVQnBIGQa+vIE1dRfRho3SHzB7m6b7lCnwPi30DZBO?= =?us-ascii?Q?bUQ4oHs+ltX6YOdrYS8aZ1SveifWlUsEQXAXBxFh5W/XpmbUkypJZzIr++I2?= =?us-ascii?Q?+wzHh7pM8KYm1Xq1GEtrfShQ0c86QN7OmRHh4t3vymgTvmKLyUlEZned4GFR?= =?us-ascii?Q?kkNXCbi0YRnOBugszcCKwk6ENfLYZeDCUFiW1GB1TU2NlSEu2qsod3VnSaF6?= =?us-ascii?Q?MIDpQm4BVjb/TgEGKREMXqDmRLfY5tiI+3ZVx916bWkEgW9itO1ofBnLlM1C?= =?us-ascii?Q?s4kW8OMlmFwJmusCeQ+/ZATB35TwuG0wvI1wrPCgNa7mjuUMvBNNTCcDc7Sk?= =?us-ascii?Q?qn83azDKx1OR0QZc6j7De0RbEDGhX1/zFIoO5J3SGu4b5/5JEkiMJwG4tnsa?= =?us-ascii?Q?sgu9ca5GppTRdVKa0xySUEjc46eRuckdncHLfUE3eykV0Y+WljjCNHQV5Igk?= =?us-ascii?Q?b8p74XxxJl0m4XAZqJRPK+O5FBBHPwEsg2HuUWPK+Br1qfccNl0tl/ZJTHQY?= =?us-ascii?Q?kzX9lrsKVgGsaV0VN4ISjWAIZFjNbeqqUsii6Qpkmm99rm8aFgCAOzQSvLGn?= =?us-ascii?Q?3fVOw7ijfv2wGBlSUC9rUPZTrzGkjJTu6/20q7WpgTNJjfzkbbdJPkIvC8/i?= =?us-ascii?Q?kPjglZWNQ7NcY+yHPW52PFSoGyPdehdwRBDnBwBCF1h+QIvEA37j5BGVwTpV?= =?us-ascii?Q?/iSG65x7KEB7Um+ZkQQWVy3+8sf0xSEXmgtn7gZ8IPX+XhafHt4irD41bilm?= =?us-ascii?Q?v/UUATCxDqZmnQzVbthM1WFJ1wB6u7Qtu0UhnUb05/iVu0zB90E/BkMpZz+w?= =?us-ascii?Q?HG17fWYmo/KttkgEcAz8EMzF1tYAblunskVQAHgK6sScvJxynEs5qLBUWo8J?= =?us-ascii?Q?5SLjw8+8wbJ6nB/gRbPxsIYMJn6mkk5guc31pK+v5fSp+ZsOGMINJ6FRkOFZ?= =?us-ascii?Q?0LLz9kAU20MneeLRc9gquCBIEzkADEZ6tQHCD8mx7ywgae6oOfEBz6W5C0rI?= =?us-ascii?Q?/dgoi1ocnnAoUsB1g6MM+1TtBqRQyIgRnvaQzSWSEoII6LjTEgjjT59Zy3TR?= =?us-ascii?Q?0ayC4JtBuC/mKBmls/dv4uA0+i+bRZYIjd7hGpUc2czo59gtVWkspuMC7GWv?= =?us-ascii?Q?P6RLYS5zanYn7GTNhflkeCsoE/MhTIIl8zifm?= X-Microsoft-Antispam-Message-Info: kvj//2rQS75ThE82Lg6XPLzvRIHCDsaEhh3+HYOJfbIW/d3YZtC573++gOYMMFdFWRStl+gcalzxWFUQUT4XOkwFfGX2LLDJDVi7uEfLui2eVwFzTpNlVcqlB8Ryra1XQcaBiCBHBLT4JmowcSbkForOd132xqENE1L+/HmoMfWa1JcKLPlZzlCKnGr1yP8rj183AExq3gd3Dr4aUTgp415+dynz2R+zz8SNTp2L9EbRtLPFkpXwtLhQ/xErIRN04MT8XhNKvnaU818ou5NzNdVbSSlQNvcXV0qT67GUogmd4cpuUSZl3BXJu5WkGd6IlOblg5VRiZoGyEJHpEqeCDuRQN8sHuQ++Ohd7EH2ArA= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB2845; 6:hO/En29c6T0DMB9KkZ5qlyU5X0Aynw/PXk6Lcx3S0IPRX2xDn2hIndBe0nW/y8/KNImk9UyBKMwtLrrCwNaSad+BA3YVu6NENOSXXMB/3uNSUr28Tgk3kloqqaujD16xgLjVuGKf2H9ckXkcEsTkZ6J3KCbd9dw030oJtVJjKEcgecv6J02tKgMImVwiPWkFU83sqDLraXDTvHPAkLxMYnk8Fp8Glb2Y4hM904Mn6HCj+T9DYM555fr6ffoAhHtwdt4r3AmTYpNo9cSHSIv0gFZ1h4LaTvFOEnFrm8Fhx6DvUG/GbcNisDteM59Nhe6sKYb5yPMnBYiq1Xwp5/5JBKumXNWJTnDy2qITjX8QZVj7AhF6j2q9lKRFzO84oiQW7MN5/xg3qlScVVOHg9u5sxFXZGFlSpePR7F79m6zVJSkqyBCbt/bEFQR8Ajcm9rXWJmWMudKQt7RCS+xLG2msg==; 5:TadjneotWoKpFJlIodQzmP1Ohk4bbsNO3G4CwY6GcDkUDrVJ0eDvwwlooil4tFiec70QI/X2xB/GQOxBOFKn6OfJQ5vey0ubOkQe9RFi27rPMkU0T4mHW22VdZ+UZCwkQYY9do2cy9rv3M/mG0HZqtnU57wCH0K7xqHg4eTLDrc=; 7:2K1AWR+klX8cV3KViU1r3/dmRjD/b5F96BmwR3a/TpykIgrunEd4j/Rhzde9EeEQCUkkg0mMeuE46vaEQnbpKoul3wnp2+Ox1DcnaaY4zINzd7W3wuera5XpnwHS4Yz0GGtiXE9lFOM3RuDcHEhhYQ== SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Nov 2018 01:12:00.1182 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4d45e150-77a4-45cc-bd50-08d64060314b X-MS-Exchange-CrossTenant-Id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5d471751-9675-428d-917b-70f44f9630b0; Ip=[135.245.43.118]; Helo=[us70tusmtp1.zam.alcatel-lucent.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2845 Archived-At: Subject: Re: [tcpm] public-private keys for TCP-AO X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Nov 2018 01:12:06 -0000 At 20:25 10/29/2018, Jakob Heitz (jheitz) wrote: >If it's public-private, I need one per sender. >It doesn't need to be the same key ID in both directions on the same session, does it? Each direction is independent and can use different IDs. Further, the key info associated with a particular key ID can be different for each direction. -Ignacio From nobody Sat Nov 3 00:08:14 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6866312D4EA; Sat, 3 Nov 2018 00:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WAFjS-uo6Hs; Sat, 3 Nov 2018 00:08:02 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB3E130E01; Sat, 3 Nov 2018 00:08:01 -0700 (PDT) Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A4FAD27855D; Sat, 3 Nov 2018 16:07:59 +0900 (JST) Received: by mail-it1-f176.google.com with SMTP id h13so6181086itl.1; Sat, 03 Nov 2018 00:07:59 -0700 (PDT) X-Gm-Message-State: AGRZ1gJl2vIHXu9kewyXFKCyx/huYJYkDEwGRhm0pCtNPYlCXd9cWg2/ nMqWDgDxnG6iISD7ZxdSz+7Px1EOYC6XwFYudPA= X-Google-Smtp-Source: AJdET5fKvEKZCAVTHgOiQm//L2P2YY9NB3ezjx0U86Qc1urH2jDNCh2v1PKqkSCdLWRIxytaq5hjrCQ5Ogs4IuPKqL4= X-Received: by 2002:a24:36d2:: with SMTP id l201-v6mr100050itl.130.1541228878272; Sat, 03 Nov 2018 00:07:58 -0700 (PDT) MIME-Version: 1.0 References: <26ed385e2f00a41e717a9d4b4043f9b9.squirrel@webmail.entel.upc.edu> <6EC6417807D9754DA64F3087E2E2E03E2D14760C@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D14760C@rznt8114.rznt.rzdir.fht-esslingen.de> From: Yoshifumi Nishida Date: Sat, 3 Nov 2018 00:07:47 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Michael.Scharf@hs-esslingen.de Cc: Yoshifumi Nishida , carlesgo@entel.upc.edu, lwip@ietf.org, "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cea2400579bd4fdf" Archived-At: Subject: Re: [tcpm] [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-04.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 07:08:06 -0000 --000000000000cea2400579bd4fdf Content-Type: text/plain; charset="UTF-8" Hi Caerles, Michael, Thanks for the addressing the comments. On Thu, Nov 1, 2018 at 7:47 AM Scharf, Michael < Michael.Scharf@hs-esslingen.de> wrote: > Chiming in... > > > 3: Section 5.3 > > CCN -> CNN? > > > > "This overhead could be reduced by TCP Fast Open (TFO)" > > > > -> Yes, but the use of TLS is not mandatory in this draft. If an > > implementation utilizes TFO, we might want to mention about app level > > idempotency here. > > We could add the following two sentences from RFC 7413 at the end of the > paragraph: > > "However, TFO deviates from the standard TCP semantics, since the data > in the SYN > could be replayed to an application in some rare circumstances. > Applications > should not use TFO unless they can tolerate this issue, e.g., by using > Transport > Layer Security (TLS)." > Works for me. > > > "TCP keep-alive messages are not very useful to..." > > > > -> We don't need to discuss reducing the interval of keep-alive here? > > We could add the following sentence (again adapted from RFC 7413): > > "Sending TCP keep-alive probes more frequently risks draining power on > mobile > devices [MQXMZ11]." > > I am not sure how much more guidance we could give on picking an interval. > I agree. I think we don't need to talk about specific interval. I just thought it would be good to mention it as this is one possible way although it might not be a good approach in some cases. Thanks, -- Yoshi --000000000000cea2400579bd4fdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Caerles, Michael,

Thanks for the add= ressing the comments.

On= Thu, Nov 1, 2018 at 7:47 AM Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
Chiming in...

> 3: Section 5.3
>=C2=A0 =C2=A0 =C2=A0CCN -> CNN?
>
>=C2=A0 =C2=A0 "This overhead could be reduced by TCP Fast Open (TF= O)"
>
> -> Yes, but the use of TLS is not mandatory in this draft. If an > implementation utilizes TFO, we might want to mention about app level<= br> > idempotency here.

We could add the following two sentences from RFC 7413 at the end of the pa= ragraph:

=C2=A0 "However, TFO deviates from the standard TCP semantics, since t= he data in the SYN
=C2=A0 =C2=A0could be replayed to an application in some rare circumstances= . Applications
=C2=A0 =C2=A0should not use TFO unless they can tolerate this issue, e.g., = by using Transport
=C2=A0 =C2=A0Layer Security (TLS)."

Works for me.=C2=A0

>=C2=A0 =C2=A0 "TCP keep-alive messages are not very useful to...&q= uot;
>
> -> We don't need to discuss reducing the interval of keep-alive= here?

We could add the following sentence (again adapted from RFC 7413):

=C2=A0 "Sending TCP keep-alive probes more frequently risks draining p= ower on mobile
=C2=A0 devices [MQXMZ11]."

I am not sure how much more guidance we could give on picking an interval.<= br>

I agree. I think we don't need to t= alk about specific interval.=C2=A0
I just thought it would be goo= d to mention it as this is one possible way although it might not be a good= approach in some cases.

Thanks,
--
<= /div>
Yoshi

--000000000000cea2400579bd4fdf-- From nobody Sat Nov 3 15:28:31 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4A8130DC6 for ; Sat, 3 Nov 2018 15:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-VO6NceLaaB for ; Sat, 3 Nov 2018 15:28:18 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A290130DF5 for ; Sat, 3 Nov 2018 15:28:17 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id o15-v6so1818738wrv.4 for ; Sat, 03 Nov 2018 15:28:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I1DWqSZCs+ulrEkue1DkZ9xC1zxjh6y206+kWVG3nTE=; b=gcxLmYPAkujwxQfe+7e8wE1dYQMbim+PGluy2R+dN6lO/HV0nULaPHgk+srEI0N696 akQyNireIqmCnQnW3yNUxdZuWCPyZhkR/MsoljmDBZOTK2SOziulhKmPLi5hLUN+B9QY N2e1fLtbeubB6T7ctmey31kK3f6ABsajJd7Eo3j9BzKYIDDiauf+GL4bzvoR1yHkg33p ekGx7GoeKvs1Cr1f5OgKXw7BWmcy7a5FYQeTyzCenpxGHxq5USmwrDQF/86ZmLMSYDVS za6Aatu43i47W5YD6xd+MGqrIk0yH+HjOj4zsszyYSaM2W9qaesEtXhmomHZSnSyjWb3 /oUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I1DWqSZCs+ulrEkue1DkZ9xC1zxjh6y206+kWVG3nTE=; b=qcqE/3Nl7s/QnP+3E2MtDVatx/9szJv0iTXKKkPzESFtHlJeJ151VLXMmvcT4GFmNf 8e/L2WwKCXswy5CXQPccjD8D41Yx0Y65oXuLO1RvyHt8XcWcJuazxtY16wQxtXNDQW8H 13nFajnqfh/7rBqiqQ/WUrAFrN1+/b4eMTMX+uer1xIh/zUzG9iQ8+LIh2u+/q2quNqR zgtAcTvqP9zRhVjxe5uWe+hAui7ud8bJCLi/bKuitjomQNBGasAo4RST2Nq2GP3JCT19 6Dd6/rE8k7wI12ODDhE5gi0vpfimqGSOS95phLeq2uTOH79oL6ADdfdBtt2RdXzqMVD3 HWzg== X-Gm-Message-State: AGRZ1gIHFbcw7cW+Ds+keHFBmSKcFhXP3v8vjlD+ayS7df+D+5EoehEu ytPp99l/CLltxHkkH5XLItD2LNMzUXR79V89tL+xow== X-Google-Smtp-Source: AJdET5cK/xZWhMXewQUi5ptLea/QIUEwO2rRjMjH8I99gW2VJFhIt/u3cJCxnhJQXm4L6EeOGk+Icja4/TXtf26LvbE= X-Received: by 2002:a5d:6489:: with SMTP id r9-v6mr13079979wru.92.1541284095488; Sat, 03 Nov 2018 15:28:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Sat, 3 Nov 2018 18:28:03 -0400 Message-ID: To: nishida@sfc.wide.ad.jp Cc: Jana Iyengar , tcpm@ietf.org, IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000032a910579ca2bb0" Archived-At: Subject: Re: [tcpm] questions on draft-ietf-quic-recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 22:28:27 -0000 --000000000000032a910579ca2bb0 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 1, 2018 at 7:12 PM Yoshifumi Nishida wrote: > Hi Ian, > > Thank you so much for the detailed response. Things are getting clearer to > me now. > I will need to have some time to think about some of them, but I would > like to comments on the following points. > Also, I am very sorry that I have mostly read -15 version and didn't have > enough time to check -16 carefully (so, my question on 4.5.7.3 was wrong) . > I will try to re-read -16 before the meeting. > Not a problem, the drafts are still changing quite rapidly. > > On Tue, Oct 30, 2018 at 6:34 PM Ian Swett 40google.com@dmarc.ietf.org> wrote: > > > > Thanks for your careful reading, answers inline. > > On Mon, Oct 29, 2018 at 1:03 PM Yoshifumi Nishida < > nishida@sfc.wide.ad.jp> wrote: > >> Section 4: > >> QUIC supports both ack and timer for loss detection. > >> But, it's not very clear whether an implementation can choose one > >> of them or it should implement both and can use both at the same time. > >> Can it be clarified? > > > > Yes, there's an open Issue to clarify this. > https://github.com/quicwg/base-drafts/issues/1212 > > > > The outstanding PR is quite old, but has some helpful clarifications in > it, so I'm intending to migrate the best parts to a new PR. Suggestions(or > PRs) welcome. > > I don't have explicit suggestions for now, but I guess we will need to > think about the following 2 questions. > > Q1: Should implementations should support both modes or are they allow to > support only one of them? > Q2: An implementation that supports both modes can activate both logics at > the same time or the mode should be used exclusively? > I think these questions will lead to another question: How much freedom > implementations should have. For example, how much implementations should > follow the pseudo codes. > The existing text says one may use one or the other or both. I tend to think we'll end up with always using both and removing the early retransmit special case. I believe the recent RACK draft removes early retransmit entirely, correct?(BTW, it mentions early retransmit, but doesn't explicitly say it replaces it from my reading). If you think that would be an improvement, I can file an issue for that and it might be worth discussing in tcpm. > >> Section 4.2.2: > >> The early retransmit logic in QUIC seems to be different from TCP's > one. > >> It doesn't look ack-based as it relies on timer. (I don't say this > >> is bad, but it's a bit strange to categorize it as an ack-based > >> method) > >> TCP's early retransmit will be triggered only when the amount of > >> outstanding data is less than 4*SMSS, but this draft doesn't mention > >> about the condition. Is there any reason for it? > >> when timer-based loss detection is used, it this logic still > >> available? or it won't be used with timer-based loss detection? We > >> might need clarifications here. > > > > > > The timer is taken from Linux, as mentioned at the end of 4.2.2. It's > categorized as ACK based because it is only armed when a packet with a > larger packet number than the one being lost has been acknowledged. One > could argue the same issue for time based loss detection, which also needs > a timer. > > > > Instead of 4*SMSS, we specify kReorderingThreshold, since it seemed like > the core issue being fixed was that there was no other mechanism for > quickly declaring these packets lost, and if one did implement adaptive > reordering tolerance, one threshold wouldn't be out of sync with the other. > > > > The intent is that like RACK, timer based loss detection subsumes early > retransmit. But yes, this text could use some further clarification, > including and not limited to items pointed out in #1212. > > Hmm... but, as you implement the logic in such a way, I think the current > early transmit logic in the draft is similar to the TLP logic in the draft. > If time_reordering_fraction is 1/8, it seems to me they are mostly > identical. > (Well, one may say this is a natural thing because early transmit and TLP > is aiming similar goal) > I tried to clarify the timers used in Early Retransmit and Time-Based loss detection in PR#1957 . Please take a look if you have time. The text about time-based loss detection needs further work, but this is a start along that direction. > > I might still overlook something, but it seems to me that the ack-based > scheme in QUIC just looks the time-based scheme in QUIC + retransmission > scheme with dupack threshold. > But, in this case, I am wondering that it may be enough just to have > ack-based scheme. > I'm not sure I understand fully, but I expect that's because the current text is unclear. > > BTW, the original early retransmit in RFC5827 is to reduce dupack > threshold (kReorderingThreshold in QUIC) when outstanding data is less > than 4 *SMSS. > Another condition is to activate only when there's no data to be sent in > the queue. > I am thinking there would be a way to do this type of early retransmit in > QUIC by tweaking reordering_threshold although I probably don't recommend > it. > > Thanks, > -- > Yoshi > --000000000000032a910579ca2bb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Nov 1, 2018 at 7:12 PM Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hi Ian,

Thank you so much for the detailed response. Things are getting c= learer to me now.
I will need to hav= e some time to think about some of them, but I would like to comments on th= e following points.
Also, I am very sorry that = I have mostly read -15 version and didn't have enough time to check -16= carefully (so, my question on 4.5.7.3 was wrong) . I will try to re-read -= 16 before the meeting.

Not a pr= oblem, the drafts are still changing quite rapidly.=C2=A0=C2=A0

<= /div>
On Tue, Oct 30, 2018 at 6:34 PM Ian Swett <ianswet= t=3D40goog= le.com@dmarc.ietf.org> wrote:
>
> Thanks for your carefu= l reading, answers inline.
> On Mon, Oct 29, 2018 at 1:03 PM Yoshifum= i Nishida <n= ishida@sfc.wide.ad.jp> wrote:
>> Section 4:
>> =C2= =A0 =C2=A0QUIC supports both ack and timer for loss detection.
>> = =C2=A0 =C2=A0But, it's not very clear whether an implementation can cho= ose one
>> of them or it should implement both and can use both at= the same time.
>> Can it be clarified?
>
> Yes, there= 's an open Issue to clarify this. =C2=A0https://github.com/quicwg/= base-drafts/issues/1212
>
> The outstanding PR is quite old= , but has some helpful clarifications in it, so I'm intending to migrat= e the best parts to a new PR.=C2=A0 Suggestions(or PRs) welcome.

I d= on't have explicit suggestions for now, but I guess we will need to thi= nk about the following 2 questions.

Q1: Should implementations= should support both modes or are they allow to support only one of them?Q2: An implementation that supports both modes can activate both logics a= t the same time or the mode should be used exclusively?
I think t= hese questions will lead to another question: How much freedom implementati= ons should have. For example, how much implementations should follow the ps= eudo codes.

The exi= sting text says one may use one or the other or both.=C2=A0 I tend to think= we'll end up with always using both and removing the early retransmit = special case.=C2=A0 I believe the recent RACK draft removes early retransmi= t entirely, correct?(BTW, it mentions early retransmit, but doesn't exp= licitly say it replaces it from my reading).=C2=A0 If you think that would = be an improvement, I can file an issue for that and it might be worth discu= ssing in tcpm.


>> Section 4.= 2.2:
>> =C2=A0 =C2=A0The early retransmit logic in QUIC seems to b= e different from TCP's one.
>> =C2=A0 =C2=A0It doesn't loo= k ack-based as it relies on timer. (I don't say this
>> is bad= , but it's a bit strange to categorize it as an ack-based
>> m= ethod)
>> =C2=A0 =C2=A0TCP's early retransmit will be triggere= d only when the amount of
>> outstanding data is less than 4*SMSS,= but this draft doesn't mention
>> about the condition. Is the= re any reason for it?
>> =C2=A0 =C2=A0when timer-based loss detect= ion is used, it this logic still
>> available? or it won't be = used with timer-based loss detection? We
>> might need clarificati= ons here.
>
>
> The timer is taken from Linux, as mention= ed at the end of 4.2.2.=C2=A0 It's categorized as ACK based because it = is only armed when a packet with a larger packet number than the one being = lost has been acknowledged.=C2=A0 One could argue the same issue for time b= ased loss detection, which also needs a timer.
>
> Instead of 4= *SMSS, we specify kReorderingThreshold, since it seemed like the core issue= being fixed was that there was no other mechanism for quickly declaring th= ese packets lost, and if one did implement adaptive reordering tolerance, o= ne threshold wouldn't be out of sync with the other.
>
> Th= e intent is that like RACK, timer based loss detection subsumes early retra= nsmit.=C2=A0 But yes, this text could use some further clarification, inclu= ding and not limited to items pointed out in #1212.

Hmm... but, as you implement the logic in such a way, I think the current= early transmit logic in the draft is similar to the TLP logic in the draft= .=C2=A0
If=C2=A0time_reordering_fraction is 1/8, it seems to me they are mostly identic= al.
(= Well,=C2=A0one = may say this is= =C2=A0a natural thing because=C2=A0early transmit and TLP is aiming similar goal)=C2=A0

I tried = to clarify the timers used in Early Retransmit and Time-Based loss detectio= n in=C2=A0PR#19= 57.=C2=A0 Please take a look if you have time.=C2=A0 The text about tim= e-based loss detection needs further work, but this is a start along that d= irection.
I might still overlook something, but it seems to me that the ack= -based scheme in QUIC just looks the time-based scheme in QUIC=C2=A0+ retra= nsmission scheme with dupack threshold.
But, in this cas= e, I am wondering that it may be enough just to have ack-based scheme.

I'm not sure = I understand fully, but I expect that's because the current text is unc= lear.

BTW, the original early retransmit in RFC5827 is to reduce = dupack threshold (kReorderingThreshold in QUIC) when outstand= ing data is less than 4 *SMSS.
Another condition is to activate o= nly when there's no data to be sent in the queue.=C2=A0
= I=C2=A0 am thin= king there would be a way to do this type of early retransmit in QUIC by tw= eaking reordering_threshold although I probably don't recommend it.

Thanks,
--
Yoshi
--000000000000032a910579ca2bb0-- From nobody Sun Nov 4 01:22:21 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A069127332; Sun, 4 Nov 2018 01:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OD3nsSbqxJS; Sun, 4 Nov 2018 01:22:13 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2402B127133; Sun, 4 Nov 2018 01:22:12 -0700 (PDT) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2B42127877C; Sun, 4 Nov 2018 17:22:10 +0900 (JST) Received: by mail-it1-f177.google.com with SMTP id b7-v6so8647285itd.5; Sun, 04 Nov 2018 01:22:10 -0700 (PDT) X-Gm-Message-State: AGRZ1gKEF4Snvkjci3LwceK8UhyTrtNmPcCu2kDydZ7/bBYK87Jni4T2 ra4l1WsDOq/lU9LAzhksiItCML6kuljvTtGUw4s= X-Google-Smtp-Source: AJdET5euM1sbnFMB12aukH53ThHfqZmRsImlHMnMyh3yEiJXMLN9pyrOgHPBY9Vqnf8WmI7QOc83idxzx3+MfYFu/rA= X-Received: by 2002:a05:660c:9c6:: with SMTP id i6mr3393573itl.25.1541319728503; Sun, 04 Nov 2018 01:22:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Sun, 4 Nov 2018 01:21:57 -0700 X-Gmail-Original-Message-ID: Message-ID: To: ianswett@google.com Cc: Yoshifumi Nishida , jri.ietf@gmail.com, "tcpm@ietf.org" , quic@ietf.org Content-Type: multipart/alternative; boundary="000000000000e722940579d2764c" Archived-At: Subject: Re: [tcpm] questions on draft-ietf-quic-recovery X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2018 08:22:16 -0000 --000000000000e722940579d2764c Content-Type: text/plain; charset="UTF-8" Hi Ian, On Sat, Nov 3, 2018 at 3:28 PM Ian Swett wrote: > > > On Thu, Nov 1, 2018 at 7:12 PM Yoshifumi Nishida > wrote: > >> Hi Ian, >> >> Thank you so much for the detailed response. Things are getting clearer >> to me now. >> I will need to have some time to think about some of them, but I would >> like to comments on the following points. >> Also, I am very sorry that I have mostly read -15 version and didn't have >> enough time to check -16 carefully (so, my question on 4.5.7.3 was wrong) . >> I will try to re-read -16 before the meeting. >> > > Not a problem, the drafts are still changing quite rapidly. > >> >> On Tue, Oct 30, 2018 at 6:34 PM Ian Swett > 40google.com@dmarc.ietf.org> wrote: >> > >> > Thanks for your careful reading, answers inline. >> > On Mon, Oct 29, 2018 at 1:03 PM Yoshifumi Nishida < >> nishida@sfc.wide.ad.jp> wrote: >> >> Section 4: >> >> QUIC supports both ack and timer for loss detection. >> >> But, it's not very clear whether an implementation can choose one >> >> of them or it should implement both and can use both at the same time. >> >> Can it be clarified? >> > >> > Yes, there's an open Issue to clarify this. >> https://github.com/quicwg/base-drafts/issues/1212 >> > >> > The outstanding PR is quite old, but has some helpful clarifications in >> it, so I'm intending to migrate the best parts to a new PR. Suggestions(or >> PRs) welcome. >> >> I don't have explicit suggestions for now, but I guess we will need to >> think about the following 2 questions. >> >> Q1: Should implementations should support both modes or are they allow to >> support only one of them? >> Q2: An implementation that supports both modes can activate both logics >> at the same time or the mode should be used exclusively? >> I think these questions will lead to another question: How much freedom >> implementations should have. For example, how much implementations should >> follow the pseudo codes. >> > > The existing text says one may use one or the other or both. I tend to > think we'll end up with always using both and removing the early retransmit > special case. I believe the recent RACK draft removes early retransmit > entirely, correct?(BTW, it mentions early retransmit, but doesn't > explicitly say it replaces it from my reading). If you think that would be > an improvement, I can file an issue for that and it might be worth > discussing in tcpm. > The current RACK uses adopted reordering window and it will be ACK-based when no reordering is observed. I am thinking it might be an interesting topic to be discussed. >> Section 4.2.2: >> >> The early retransmit logic in QUIC seems to be different from TCP's >> one. >> >> It doesn't look ack-based as it relies on timer. (I don't say this >> >> is bad, but it's a bit strange to categorize it as an ack-based >> >> method) >> >> TCP's early retransmit will be triggered only when the amount of >> >> outstanding data is less than 4*SMSS, but this draft doesn't mention >> >> about the condition. Is there any reason for it? >> >> when timer-based loss detection is used, it this logic still >> >> available? or it won't be used with timer-based loss detection? We >> >> might need clarifications here. >> > >> > >> > The timer is taken from Linux, as mentioned at the end of 4.2.2. It's >> categorized as ACK based because it is only armed when a packet with a >> larger packet number than the one being lost has been acknowledged. One >> could argue the same issue for time based loss detection, which also needs >> a timer. >> > >> > Instead of 4*SMSS, we specify kReorderingThreshold, since it seemed >> like the core issue being fixed was that there was no other mechanism for >> quickly declaring these packets lost, and if one did implement adaptive >> reordering tolerance, one threshold wouldn't be out of sync with the other. >> > >> > The intent is that like RACK, timer based loss detection subsumes early >> retransmit. But yes, this text could use some further clarification, >> including and not limited to items pointed out in #1212. >> >> Hmm... but, as you implement the logic in such a way, I think the current >> early transmit logic in the draft is similar to the TLP logic in the draft. >> If time_reordering_fraction is 1/8, it seems to me they are mostly >> identical. >> (Well, one may say this is a natural thing because early transmit and >> TLP is aiming similar goal) >> > > I tried to clarify the timers used in Early Retransmit and Time-Based loss > detection in PR#1957 . > Please take a look if you have time. The text about time-based loss > detection needs further work, but this is a start along that direction. > OK. I will think about this a bit more. > I might still overlook something, but it seems to me that the ack-based >> scheme in QUIC just looks the time-based scheme in QUIC + retransmission >> scheme with dupack threshold. >> But, in this case, I am wondering that it may be enough just to have >> ack-based scheme. >> > > I'm not sure I understand fully, but I expect that's because the current > text is unclear. > Or, I overlook something. In any case, I think it is great to have a chance to discuss specifically loss discovery and CC. Thank you so much! -- Yoshi --000000000000e722940579d2764c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Ian,

On Sat, Nov 3, 2018 at 3:28 PM Ian Swett <ianswett@google.com> wrote:


On Thu, Nov 1, 2018 at 7:12 PM Yoshifumi Nishida <nishida@sfc.wide.ad.jp&g= t; wrote:
Hi Ian,

Thank you so much for the detail= ed response. Things are getting clearer to me now.
I will need to have some time to think about some of them, b= ut I would like to comments on the following points.
Also, I am very sorry that I have mostly read -15 version and didn= 9;t have enough time to check -16 carefully (so, my question on 4.5.7.3 was= wrong) . I will try to re-read -16 before the meeting.

Not a problem, the drafts are still changing quite= rapidly.=C2=A0=C2=A0
=

On Tue, Oct 30, 2018= at 6:34 PM Ian Swett <ianswett=3D40google.com@dmarc.ietf.org> wrote:
&g= t;
> Thanks for your careful reading, answers inline.
> On Mon,= Oct 29, 2018 at 1:03 PM Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
&g= t;> Section 4:
>> =C2=A0 =C2=A0QUIC supports both ack and timer= for loss detection.
>> =C2=A0 =C2=A0But, it's not very clear = whether an implementation can choose one
>> of them or it should i= mplement both and can use both at the same time.
>> Can it be clar= ified?
>
> Yes, there's an open Issue to clarify this. =C2= =A0https://github.com/quicwg/base-drafts/issues/1212
>
&g= t; The outstanding PR is quite old, but has some helpful clarifications in = it, so I'm intending to migrate the best parts to a new PR.=C2=A0 Sugge= stions(or PRs) welcome.

I don't have explicit suggestions for no= w, but I guess we will need to think about the following 2 questions.
<= br>
Q1: Should implementations should support both modes or are they al= low to support only one of them?
Q2: An implementation that supports bot= h modes can activate both logics at the same time or the mode should be use= d exclusively?
I think these questions will lead to another quest= ion: How much freedom implementations should have. For example, how much im= plementations should follow the pseudo codes.

The existing text says one may use one or the ot= her or both.=C2=A0 I tend to think we'll end up with always using both = and removing the early retransmit special case.=C2=A0 I believe the recent = RACK draft removes early retransmit entirely, correct?(BTW, it mentions ear= ly retransmit, but doesn't explicitly say it replaces it from my readin= g).=C2=A0 If you think that would be an improvement, I can file an issue fo= r that and it might be worth discussing in tcpm.

The current RACK uses adopted reordering window and= it will be ACK-based when no reordering is observed. I am thinking it migh= t be an interesting topic to be discussed.

>>= ; Section 4.2.2:
>> =C2=A0 =C2=A0The early retransmit logic in QUI= C seems to be different from TCP's one.
>> =C2=A0 =C2=A0It doe= sn't look ack-based as it relies on timer. (I don't say this
>= ;> is bad, but it's a bit strange to categorize it as an ack-based>> method)
>> =C2=A0 =C2=A0TCP's early retransmit will= be triggered only when the amount of
>> outstanding data is less = than 4*SMSS, but this draft doesn't mention
>> about the condi= tion. Is there any reason for it?
>> =C2=A0 =C2=A0when timer-based= loss detection is used, it this logic still
>> available? or it w= on't be used with timer-based loss detection? We
>> might need= clarifications here.
>
>
> The timer is taken from Linux= , as mentioned at the end of 4.2.2.=C2=A0 It's categorized as ACK based= because it is only armed when a packet with a larger packet number than th= e one being lost has been acknowledged.=C2=A0 One could argue the same issu= e for time based loss detection, which also needs a timer.
>
> = Instead of 4*SMSS, we specify kReorderingThreshold, since it seemed like th= e core issue being fixed was that there was no other mechanism for quickly = declaring these packets lost, and if one did implement adaptive reordering = tolerance, one threshold wouldn't be out of sync with the other.
>= ;
> The intent is that like RACK, timer based loss detection subsumes= early retransmit.=C2=A0 But yes, this text could use some further clarific= ation, including and not limited to items pointed out in #1212.
<= br>
Hmm... but, as you implement the logic in such a way, I think= the current early transmit logic in the draft is similar to the TLP logic = in the draft.=C2=A0
If=C2=A0time_reordering_fraction is 1/8, it seems to me they are mo= stly identical.
(Well,=C2=A0one may say this is=C2=A0a natural thing because=C2=A0early transmit and TLP is aiming similar go= al)=C2=A0

<= div>I tried to clarify the timers used in Early Retransmit and Time-Based l= oss detection in=C2=A0PR#1957.=C2=A0 Please take a look if you have = time.=C2=A0 The text about time-based loss detection needs further work, bu= t this is a start along that direction.
=
OK. I will think about this a bit more.
=C2=A0
I m= ight still overlook something, but it seems to me that the ack-based scheme= in QUIC just looks the time-based scheme in QUIC=C2=A0+ retransmission sch= eme with dupack threshold.
But, in this case, I am wonde= ring that it may be enough just to have ack-based scheme.
=

I'm not sure I understand = fully, but I expect that's because the current text is unclear.

Or, I overlook something. In any= case, I think it is great to have a chance to discuss specifically loss di= scovery and CC. Thank you so much!
--
Yoshi
=C2=A0

--000000000000e722940579d2764c-- From nobody Sun Nov 4 23:50:28 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2A5130D7A; Sun, 4 Nov 2018 23:50:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.87.3 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , tcpm@ietf.org, tuexen@fh-muenster.de, draft-ietf-tcpm-alternativebackoff-ecn@ietf.org, ietf@kuehlewind.net, =?utf-8?q?Michael_T=C3=BCxen?= , rfc-editor@rfc-editor.org, tcpm-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <154140422116.26462.5138592878376603551.idtracker@ietfa.amsl.com> Date: Sun, 04 Nov 2018 23:50:21 -0800 Archived-At: Subject: [tcpm] Document Action: 'TCP Alternative Backoff with ECN (ABE)' to Experimental RFC (draft-ietf-tcpm-alternativebackoff-ecn-12.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 07:50:22 -0000 The IESG has approved the following document: - 'TCP Alternative Backoff with ECN (ABE)' (draft-ietf-tcpm-alternativebackoff-ecn-12.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-alternativebackoff-ecn/ Technical Summary The recently published RFC 8311 (Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation) allows a TCP sender to react to an ECN signal in a different way than to a inferred loss signal if the behaviour is documented in an experimental RFC. This document describes such an experiment in which the reduction of the congestion window in response to an ECN signal is smaller than in response to an inferred packet loss. Therefore the TCPM working group requests publication as an experimental document. Working Group Summary Was there anything in the WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Document Quality The document has been discussed several times in working group meetings without any major controversy. There were also no substantial problems reported during the working group last call and it is implemented for FreeBSD (the code has been committed to the FreeBSD code base). The risk of running this experiment is relatively low, since the reaction to a loss is not changed. There is very strong consensus in the TCPM working group that this document should be published. Personnel The document shepherd is Michael Tüxen . The responsible Area Director is Mirja Kühlewind . From nobody Mon Nov 5 02:52:24 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36AC130F04; Mon, 5 Nov 2018 02:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYyl1h3ny6z1; Mon, 5 Nov 2018 02:52:15 -0800 (PST) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD00130E9F; Mon, 5 Nov 2018 02:52:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 42pTyf0zdVz15Lp3; Mon, 5 Nov 2018 11:52:10 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-Ubp4RYt-iB; Mon, 5 Nov 2018 11:52:08 +0100 (CET) X-MtScore: NO score=0 Received: from dhcp-821a.meeting.ietf.org (dhcp-821a.meeting.ietf.org [31.133.130.26]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 5 Nov 2018 11:52:07 +0100 (CET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <627FA33A-9F92-4473-B94E-27D6783F441F@tik.ee.ethz.ch> Date: Mon, 5 Nov 2018 17:52:03 +0700 Cc: tcpm@ietf.org To: draft-ietf-tcpm-generalized-ecn@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [tcpm] ECN++: text on congestion response to CE on pure ACKs X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 10:52:22 -0000 Hi Bob, hi all, based on the discussion we just had in the session, I would like to = propose to eventually add an section on goals of the experiments (which = is anything recommended) and potentially move any discussion about = responses to CE markings on pure ACK (as just presented) there as one = question that needs experimentation. Mirja From nobody Tue Nov 6 11:20:18 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA2A130DFA; Tue, 6 Nov 2018 11:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGGL2xVt7Bkw; Tue, 6 Nov 2018 11:20:14 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C38112F1A5; Tue, 6 Nov 2018 11:20:14 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 5FE8E25A13; Tue, 6 Nov 2018 20:20:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1541532012; bh=TDbIhNngvyUqlEb5wit4zsPRa5CKnlgR7mDtCU1fYmg=; h=From:To:CC:Subject:Date:From; b=qIW8Wz50kDlylVapmSzbldZj/I6faJ4/TJkOQb9kM1pTrZivZtGfONvDOh/PmCTkE 3KPpqedF66Bj5Yi3jn/A9Ob4MB4Deh6Az3Nndi2l6ookLUHbmzSEQoC/jK2kjyHNh+ Uwrihb/0q/sMwRT5x5XcRyLgZBvagFCcc5Iz+WUM= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaXdl1a43LQ3; Tue, 6 Nov 2018 20:20:12 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.hs-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 6 Nov 2018 20:20:12 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.25]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Tue, 6 Nov 2018 20:20:11 +0100 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: "tsvwg@ietf.org" Thread-Topic: Cross-area alignment on "L4S and RACK" Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFg== Date: Tue, 6 Nov 2018 19:20:11 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 19:20:17 -0000 A comment on the TCPM presentation "L4S and RACK": As far as I understand, the DETNET WG in RTG area has quite some uses cases= for ultra-low latency transport - in particular also with bounded jitter. = And some of these applications (e.g. using UDP) apparently may not be able = to tolerate *any* out-of-order packet delivery. So perhaps some cross-area alignment on ulta-low-latency application requir= ements would be useful? Michael (who recently had to review draft-ietf-detnet-architecture) From nobody Tue Nov 6 14:14:35 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B311288BD; Tue, 6 Nov 2018 14:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MkpBZZ9AAVJ; Tue, 6 Nov 2018 14:14:25 -0800 (PST) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73556130E19; Tue, 6 Nov 2018 14:14:25 -0800 (PST) Received: by mail-lf1-x135.google.com with SMTP id v5so5071236lfe.7; Tue, 06 Nov 2018 14:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sKOEuwAABIytkBbF08W6mFqZe/L/PL5OOoi4ZkG2StI=; b=NLZY0/d6bC4V373+fdRmw3GI7e3A75hS4Fssr9cETdzLrvKV/yRP/ttWXG7o9dIUoS RTUdKjvZaMtdpbVbrEBans0W1RY2xsI3/iKeLhuST5ZA1BY/CHIjJjPZGqPOrd5i6hi4 wXd3NtAZOnMO0Vjr6WoStlAg52Q9l2/4FRPUVgwTqWtVC2EhkYmEnIVOn3KTIIKcfAOZ YVXObaa9tjZ0HVqmFI1MRI70qDUaxav1Z3Yalq+3vIs5/xvCMTwhOW6Lqpsiszo2LnMJ AmW5eAh8L0dWCZkc4LfHRyKYOeIf5fxTTbxoX8FIgHCJHh71xurt1jvTEye2bj+MradX Ksiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sKOEuwAABIytkBbF08W6mFqZe/L/PL5OOoi4ZkG2StI=; b=UJVb/3z0tud4HMvI4Q7oPxUcvr+TrOPs9mX+lj3OEDOjIQ7hiF8PQwITwx/WX0hmNc 5nzehIIyBMlOzd1dWVGFhIGqrJSIwlbPM1lHvSZ3X/BQox9WYPs70lIQjti4SCrRu5h3 i3K7cKNalDATphQcRZh6TfL+2B07w9DdMOVP6w5I5veF5oY3jFlOql09uZ7HN0Zsz79t LwN6WeeNZXnXIZfOyeNV1dwigAN2jEVrs2FHqKdLedizvaAaLDLGMQwbDi5DpXcZUw68 QkbjfUHnwQdsbXCiPCCJMTAt/Vmey49mt35tp2LJ6jHHzvoE9LnMknigF7F4rYgwuSxX XACA== X-Gm-Message-State: AGRZ1gIKYSBHttGjs39oM76gYpWXLLfLDdcdoCr22IRViJUSzU4zFpTF ZPMwpAhNWCROVOkowX3s8sgJv8jzfZZp5ejHxewo4bLJ+nM= X-Google-Smtp-Source: AJdET5dnV5U1Z7Ol8T/YnsIg62gaMsOCj0nRvRGvKCvCVRZlnV67vXAdk04IT/T3fr0D1ldIlnck1x7DYZVEAnAQPWQ= X-Received: by 2002:a19:4345:: with SMTP id m5mr16092323lfj.142.1541542462905; Tue, 06 Nov 2018 14:14:22 -0800 (PST) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> From: Spencer Dawkins at IETF Date: Wed, 7 Nov 2018 05:14:12 +0700 Message-ID: To: Michael.Scharf@hs-esslingen.de Cc: tcpm IETF list , tsvwg@ietf.org Content-Type: multipart/alternative; boundary="000000000000e864ba057a065209" Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 22:14:28 -0000 --000000000000e864ba057a065209 Content-Type: text/plain; charset="UTF-8" Michael, On Wed, Nov 7, 2018 at 2:20 AM Scharf, Michael < Michael.Scharf@hs-esslingen.de> wrote: > A comment on the TCPM presentation "L4S and RACK": > > As far as I understand, the DETNET WG in RTG area has quite some uses > cases for ultra-low latency transport - in particular also with bounded > jitter. And some of these applications (e.g. using UDP) apparently may not > be able to tolerate *any* out-of-order packet delivery. > > So perhaps some cross-area alignment on ulta-low-latency application > requirements would be useful? > > Michael > (who recently had to review draft-ietf-detnet-architecture) > I'm not a responsible AD for DETNET, but we approved https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ within the last couple of weeks. My understanding is that at least some of the use cases have that intolerance for out-of-order delivery (among other characteristics). That was certainly the case when we chartered DETNET. I'm sure TSV will do the right thing ;-) Spencer --000000000000e864ba057a065209 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Michael,=C2=A0

On Wed, Nov 7, 2018 at 2:20 AM Scharf, Michael &l= t;Michael.Scharf@hs-essli= ngen.de> wrote:
A comment on the TCPM presentation "L4S and RACK":

As far as I understand, the DETNET WG in RTG area has quite some uses cases= for ultra-low latency transport - in particular also with bounded jitter. = And some of these applications (e.g. using UDP) apparently may not be able = to tolerate *any* out-of-order packet delivery.

So perhaps some cross-area alignment on ulta-low-latency application requir= ements would be useful?

Michael
(who recently had to review draft-ietf-detnet-architecture)

I'm not a responsible AD for DETNET, but we approv= ed=C2=A0https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ wi= thin the last couple of weeks.=C2=A0

My understand= ing is that at least some of the use cases have that intolerance for out-of= -order delivery (among other characteristics). That was certainly the case = when we chartered DETNET.=C2=A0

I'm sure TSV w= ill do the right thing ;-)

Spencer
--000000000000e864ba057a065209-- From nobody Tue Nov 6 18:01:43 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1F5127598; Tue, 6 Nov 2018 18:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.17 X-Spam-Level: X-Spam-Status: No, score=-3.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=LnLSphus; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=fhFEf2Z3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYMe4J8041aI; Tue, 6 Nov 2018 18:01:33 -0800 (PST) Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73902126CB6; Tue, 6 Nov 2018 18:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1541556093; x=1573092093; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=UNcZvAmjWRCwXrVjBO8Dt8E5mSuTu5iLPTL3qkYTRKg=; b=LnLSphus2SBp0nEQCiuEXPDetR5XHq524bTgYWmSn0B1X0x+K9ccJH+f XpI7E16XoKt/33nI7HbgGchGQF/CPWQQRz5lvxjeiWpWyn/IJdFk5MtP0 xk13yMi1pQvjFFlnv94xQ3SVM6CbpN5qZ6olVzk3TA+87VJqD0/KIT7GJ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EJAAA1RuJbhyWd50NkHQEBBQEHBQG?= =?us-ascii?q?BUQgBCwGBDSMlgRSBAicKg2yIGF+NRJcwFIErOwsBASMLhD4CF4NCIjQNDQE?= =?us-ascii?q?DAQECAQECAQECEAEBAQoLCQgpIwyCNiQBD0svCTMBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEXAkMBEgEBGAEBAQECARIRChMfGgEECwIBCBEBAwEBCx0DAgICMBQDBgg?= =?us-ascii?q?BAQQBEggagn8BgR1cCAEOnXwCgRCJWAEBAW2BLoJ9gUJAhR8DBYpcgRyBWT6?= =?us-ascii?q?BEUaCTIMbAgMBgSoBEgENFAwfCQKCTDGCJokLeoRfkFcDBAIChm2DJIcXgVa?= =?us-ascii?q?FAIoOjQ2KGQIEAgQFAhSBQ4EdcXBQgmwJgiyDU4UUhT5BMYsXgR+BHwEB?= X-IPAS-Result: =?us-ascii?q?A2EJAAA1RuJbhyWd50NkHQEBBQEHBQGBUQgBCwGBDSMlg?= =?us-ascii?q?RSBAicKg2yIGF+NRJcwFIErOwsBASMLhD4CF4NCIjQNDQEDAQECAQECAQECE?= =?us-ascii?q?AEBAQoLCQgpIwyCNiQBD0svCTMBAQEBAQEBAQEBAQEBAQEBAQEXAkMBEgEBG?= =?us-ascii?q?AEBAQECARIRChMfGgEECwIBCBEBAwEBCx0DAgICMBQDBggBAQQBEggagn8Bg?= =?us-ascii?q?R1cCAEOnXwCgRCJWAEBAW2BLoJ9gUJAhR8DBYpcgRyBWT6BEUaCTIMbAgMBg?= =?us-ascii?q?SoBEgENFAwfCQKCTDGCJokLeoRfkFcDBAIChm2DJIcXgVaFAIoOjQ2KGQIEA?= =?us-ascii?q?gQFAhSBQ4EdcXBQgmwJgiyDU4UUhT5BMYsXgR+BHwEB?= Received: from mx0b-00154901.pphosted.com ([67.231.157.37]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/AES256-SHA256; 06 Nov 2018 20:01:31 -0600 Received: from pps.filterd (m0144103.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wA71r239092347; Tue, 6 Nov 2018 21:01:31 -0500 Received: from esa6.dell-outbound2.iphmx.com (esa6.dell-outbound2.iphmx.com [68.232.154.99]) by mx0b-00154901.pphosted.com with ESMTP id 2nkdat32e4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 06 Nov 2018 21:01:30 -0500 From: "Black, David" Cc: tcpm IETF list , "tsvwg@ietf.org" , "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA256; 07 Nov 2018 08:01:28 +0600 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id wA721R9Z002666 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Nov 2018 21:01:27 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com wA721R9Z002666 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1541556088; bh=AxO0iPDwc77SBp/QIc1HPdWC/9M=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=fhFEf2Z3CTuZq9U0dYbXTiJm/uquckqgRpf5aTO+g/jTbtaZObLKdKxJ5WCsnaVwa ae6/opRav+qgg68xGoAhVqvQywueIQSgbtlgypmhHvzZ5oel72dlt4sre6GuCwkZ4s YfnLZtHAHCO/imU1NxQXkeL4F0FN4bVgoMqyIP78= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com wA721R9Z002666 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd02.lss.emc.com (RSA Interceptor); Tue, 6 Nov 2018 21:01:07 -0500 Received: from MXHUB312.corp.emc.com (MXHUB312.corp.emc.com [10.146.3.90]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id wA72170O022088 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 6 Nov 2018 21:01:07 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB312.corp.emc.com ([10.146.3.90]) with mapi id 14.03.0399.000; Tue, 6 Nov 2018 21:01:06 -0500 To: Spencer Dawkins at IETF , "Michael.Scharf@hs-esslingen.de" Thread-Topic: [tsvwg] Cross-area alignment on "L4S and RACK" Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFgAQjaIAAALVYtA= Date: Wed, 7 Nov 2018 02:01:06 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D24327794936303334FBMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811070016 Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2018 02:01:37 -0000 --_000_CE03DB3D7B45C245BCA0D24327794936303334FBMX307CL04corpem_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGUgREVUTkVUIFdHIGluIFJURyBhcmVhIGhhcyBx dWl0ZSBzb21lIHVzZXMgY2FzZXMgZm9yIHVsdHJhLWxvdyBsYXRlbmN5IHRyYW5zcG9ydCAtIGlu IHBhcnRpY3VsYXIgYWxzbyB3aXRoIGJvdW5kZWQgaml0dGVyLg0KPiBBbmQgc29tZSBvZiB0aGVz ZSBhcHBsaWNhdGlvbnMgKGUuZy4gdXNpbmcgVURQKSBhcHBhcmVudGx5IG1heSBub3QgYmUgYWJs ZSB0byB0b2xlcmF0ZSAqYW55KiBvdXQtb2Ytb3JkZXIgcGFja2V0IGRlbGl2ZXJ5Lg0KDQpJ4oCZ bSB0aGUgVHJhbnNwb3J0IFRlY2huaWNhbCBBZHZpc29yIHRvIHRoZSBERVRORVQgV0cg4oCTIHRo ZSBlbnZpc2lvbmVkIERFVE5FVCBkYXRhIHBhdGggc3RydWN0dXJlIGlzIHNpbWlsYXIgdG8gSW50 c2VydiBvciBwb2xpY3ktYmFzZWQgcm91dGluZy0gYSBmdWxsIDUtdHVwbGUgbWF0Y2ggKDIgeCBh ZGRyLCBwcm90b2NvbCAyIHggcG9ydCkgb24gYWxsIGluYm91bmQgdHJhZmZpYyBwaWNrcyBvZmYg dGhlIGZsb3dzIHRoYXQgcmVxdWlyZXMgZGV0ZXJtaW5pc3RpYyBmb3J3YXJkaW5nIGFuZCBkaXZl cnRzIHRoZW0gaW50byBhIERFVE5FVCBkYXRhIHBhdGggdGhhdCBtYWludGFpbnMgcGVyLWZsb3cg c3RhdGUgYmVmb3JlIHRoZSBEaWZmc2VydiBsb2dpYyBsb29rcyBhdCB0aGUgRFNDUCBvciBMNFMg bG9naWMgIGxvb2tzIGF0IEVDVCgxKSB0byBmaWd1cmUgb3V0IHdoYXQgdG8gZG8gd2l0aCB0aGUg KG5vbi1kZXRlcm1pbmlzdGljKSByZXN0IG9mIHRoZSB0cmFmZmljIHdoaWNoIGlzIGhhbmRsZWQg YXMgZmxvdyBhZ2dyZWdhdGVzIChubyBwZXItZmxvdyBzdGF0ZSBpbiBmb3J3YXJkaW5nIHBhdGgp Lg0KDQpUaGlzIGNvdWxkIGJlIG1hZGUgY2xlYXJlciBpbiB0aGVpciBkcmFmdHMg4oCmDQoNClRo YW5rcywgLS1EYXZpZA0KDQpGcm9tOiB0c3Z3ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURg0KU2VudDogVHVlc2RheSwg Tm92ZW1iZXIgNiwgMjAxOCA1OjE0IFBNDQpUbzogTWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2Vu LmRlDQpDYzogdGNwbSBJRVRGIGxpc3Q7IHRzdndnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Rz dndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAiTDRTIGFuZCBSQUNLIg0KDQoNCltFWFRFUk5B TCBFTUFJTF0NClBsZWFzZSByZXBvcnQgYW55IHN1c3BpY2lvdXMgYXR0YWNobWVudHMsIGxpbmtz LCBvciByZXF1ZXN0cyBmb3Igc2Vuc2l0aXZlIGluZm9ybWF0aW9uLg0KTWljaGFlbCwNCg0KT24g V2VkLCBOb3YgNywgMjAxOCBhdCAyOjIwIEFNIFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5TY2hh cmZAaHMtZXNzbGluZ2VuLmRlPG1haWx0bzpNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGU+ PiB3cm90ZToNCkEgY29tbWVudCBvbiB0aGUgVENQTSBwcmVzZW50YXRpb24gIkw0UyBhbmQgUkFD SyI6DQoNCkFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZSBERVRORVQgV0cgaW4gUlRHIGFyZWEg aGFzIHF1aXRlIHNvbWUgdXNlcyBjYXNlcyBmb3IgdWx0cmEtbG93IGxhdGVuY3kgdHJhbnNwb3J0 IC0gaW4gcGFydGljdWxhciBhbHNvIHdpdGggYm91bmRlZCBqaXR0ZXIuIEFuZCBzb21lIG9mIHRo ZXNlIGFwcGxpY2F0aW9ucyAoZS5nLiB1c2luZyBVRFApIGFwcGFyZW50bHkgbWF5IG5vdCBiZSBh YmxlIHRvIHRvbGVyYXRlICphbnkqIG91dC1vZi1vcmRlciBwYWNrZXQgZGVsaXZlcnkuDQoNClNv IHBlcmhhcHMgc29tZSBjcm9zcy1hcmVhIGFsaWdubWVudCBvbiB1bHRhLWxvdy1sYXRlbmN5IGFw cGxpY2F0aW9uIHJlcXVpcmVtZW50cyB3b3VsZCBiZSB1c2VmdWw/DQoNCk1pY2hhZWwNCih3aG8g cmVjZW50bHkgaGFkIHRvIHJldmlldyBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUpDQoN CkknbSBub3QgYSByZXNwb25zaWJsZSBBRCBmb3IgREVUTkVULCBidXQgd2UgYXBwcm92ZWQgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kZXRuZXQtdXNlLWNhc2Vz LyB3aXRoaW4gdGhlIGxhc3QgY291cGxlIG9mIHdlZWtzLg0KDQpNeSB1bmRlcnN0YW5kaW5nIGlz IHRoYXQgYXQgbGVhc3Qgc29tZSBvZiB0aGUgdXNlIGNhc2VzIGhhdmUgdGhhdCBpbnRvbGVyYW5j ZSBmb3Igb3V0LW9mLW9yZGVyIGRlbGl2ZXJ5IChhbW9uZyBvdGhlciBjaGFyYWN0ZXJpc3RpY3Mp LiBUaGF0IHdhcyBjZXJ0YWlubHkgdGhlIGNhc2Ugd2hlbiB3ZSBjaGFydGVyZWQgREVUTkVULg0K DQpJJ20gc3VyZSBUU1Ygd2lsbCBkbyB0aGUgcmlnaHQgdGhpbmcgOy0pDQoNClNwZW5jZXINCg== --_000_CE03DB3D7B45C245BCA0D24327794936303334FBMX307CL04corpem_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPiZndDsgQXMgZmFyIGFzIEkg dW5kZXJzdGFuZCwgdGhlIERFVE5FVCBXRyBpbiBSVEcgYXJlYSBoYXMgcXVpdGUgc29tZSB1c2Vz IGNhc2VzIGZvciB1bHRyYS1sb3cgbGF0ZW5jeSB0cmFuc3BvcnQgLSBpbiBwYXJ0aWN1bGFyIGFs c28gd2l0aCBib3VuZGVkIGppdHRlci48bzpwPjwvbzpwPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IEFuZCBzb21lIG9mIHRoZXNlIGFwcGxpY2F0aW9ucyAoZS5nLiB1c2luZyBV RFApIGFwcGFyZW50bHkgbWF5IG5vdCBiZSBhYmxlIHRvIHRvbGVyYXRlICphbnkqIG91dC1vZi1v cmRlciBwYWNrZXQgZGVsaXZlcnkuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SeKAmW0gdGhlIFRyYW5zcG9y dCBUZWNobmljYWwgQWR2aXNvciB0byB0aGUgREVUTkVUIFdHIOKAkyB0aGUgZW52aXNpb25lZCBE RVRORVQgZGF0YSBwYXRoIHN0cnVjdHVyZSBpcyBzaW1pbGFyIHRvIEludHNlcnYgb3IgcG9saWN5 LWJhc2VkIHJvdXRpbmctIGEgZnVsbCA1LXR1cGxlDQogbWF0Y2ggKDIgeCBhZGRyLCBwcm90b2Nv bCAyIHggcG9ydCkgb24gYWxsIGluYm91bmQgdHJhZmZpYyBwaWNrcyBvZmYgdGhlIGZsb3dzIHRo YXQgcmVxdWlyZXMgZGV0ZXJtaW5pc3RpYyBmb3J3YXJkaW5nIGFuZCBkaXZlcnRzIHRoZW0gaW50 byBhIERFVE5FVCBkYXRhIHBhdGggdGhhdCBtYWludGFpbnMgcGVyLWZsb3cgc3RhdGUgYmVmb3Jl IHRoZSBEaWZmc2VydiBsb2dpYyBsb29rcyBhdCB0aGUgRFNDUCBvciBMNFMgbG9naWMgJm5ic3A7 bG9va3MgYXQNCiBFQ1QoMSkgdG8gZmlndXJlIG91dCB3aGF0IHRvIGRvIHdpdGggdGhlIChub24t ZGV0ZXJtaW5pc3RpYykgcmVzdCBvZiB0aGUgdHJhZmZpYyB3aGljaCBpcyBoYW5kbGVkIGFzIGZs b3cgYWdncmVnYXRlcyAobm8gcGVyLWZsb3cgc3RhdGUgaW4gZm9yd2FyZGluZyBwYXRoKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgY291bGQgYmUgbWFk ZSBjbGVhcmVyIGluIHRoZWlyIGRyYWZ0cyDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgLS1EYXZpZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHRzdndnIFttYWlsdG86 dHN2d2ctYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+U3BlbmNlciBEYXdr aW5zIGF0IElFVEY8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgNiwgMjAxOCA1 OjE0IFBNPGJyPg0KPGI+VG86PC9iPiBNaWNoYWVsLlNjaGFyZkBocy1lc3NsaW5nZW4uZGU8YnI+ DQo8Yj5DYzo8L2I+IHRjcG0gSUVURiBsaXN0OyB0c3Z3Z0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAmcXVvdDtMNFMgYW5k IFJBQ0smcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6I0NFMTEyNiI+W0VYVEVSTkFM IEVNQUlMXSA8YnI+DQpQbGVhc2UgcmVwb3J0IGFueSBzdXNwaWNpb3VzIGF0dGFjaG1lbnRzLCBs aW5rcywgb3IgcmVxdWVzdHMgZm9yIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlj aGFlbCwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gV2VkLCBOb3YgNywgMjAxOCBhdCAyOjIwIEFNIFNjaGFyZiwgTWljaGFlbCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOk1pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZSI+TWljaGFlbC5TY2hhcmZA aHMtZXNzbGluZ2VuLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGNvbW1lbnQgb24gdGhlIFRDUE0gcHJl c2VudGF0aW9uICZxdW90O0w0UyBhbmQgUkFDSyZxdW90Ozo8YnI+DQo8YnI+DQpBcyBmYXIgYXMg SSB1bmRlcnN0YW5kLCB0aGUgREVUTkVUIFdHIGluIFJURyBhcmVhIGhhcyBxdWl0ZSBzb21lIHVz ZXMgY2FzZXMgZm9yIHVsdHJhLWxvdyBsYXRlbmN5IHRyYW5zcG9ydCAtIGluIHBhcnRpY3VsYXIg YWxzbyB3aXRoIGJvdW5kZWQgaml0dGVyLiBBbmQgc29tZSBvZiB0aGVzZSBhcHBsaWNhdGlvbnMg KGUuZy4gdXNpbmcgVURQKSBhcHBhcmVudGx5IG1heSBub3QgYmUgYWJsZSB0byB0b2xlcmF0ZSAq YW55KiBvdXQtb2Ytb3JkZXIgcGFja2V0DQogZGVsaXZlcnkuPGJyPg0KPGJyPg0KU28gcGVyaGFw cyBzb21lIGNyb3NzLWFyZWEgYWxpZ25tZW50IG9uIHVsdGEtbG93LWxhdGVuY3kgYXBwbGljYXRp b24gcmVxdWlyZW1lbnRzIHdvdWxkIGJlIHVzZWZ1bD88YnI+DQo8YnI+DQpNaWNoYWVsPGJyPg0K KHdobyByZWNlbnRseSBoYWQgdG8gcmV2aWV3IGRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVy ZSk8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkknbSBub3QgYSByZXNwb25zaWJsZSBBRCBmb3IgREVUTkVULCBidXQgd2UgYXBwcm92 ZWQmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWRldG5ldC11c2UtY2FzZXMvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWRldG5ldC11c2UtY2FzZXMvPC9hPiB3aXRoaW4gdGhlIGxhc3QgY291cGxlIG9m IHdlZWtzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYXQgbGVhc3Qgc29tZSBvZiB0aGUg dXNlIGNhc2VzIGhhdmUgdGhhdCBpbnRvbGVyYW5jZSBmb3Igb3V0LW9mLW9yZGVyIGRlbGl2ZXJ5 IChhbW9uZyBvdGhlciBjaGFyYWN0ZXJpc3RpY3MpLiBUaGF0IHdhcyBjZXJ0YWlubHkgdGhlIGNh c2Ugd2hlbiB3ZSBjaGFydGVyZWQgREVUTkVULiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gc3VyZSBUU1Ygd2lsbCBkbyB0aGUg cmlnaHQgdGhpbmcgOy0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNwZW5jZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CE03DB3D7B45C245BCA0D24327794936303334FBMX307CL04corpem_-- From nobody Thu Nov 8 03:15:05 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00526130DE1; Thu, 8 Nov 2018 03:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRp-Q4E5EXkL; Thu, 8 Nov 2018 03:14:52 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335B3128CF3; Thu, 8 Nov 2018 03:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Cc:Subject:From:To:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=XU9SBk3JlH/aaqZYc1gJPM/9MR51vfF55NQOcKYBaqQ=; b=IWDsXQDec70Ymc2zrnFcvSD9Zy lyNliYXCWwWUmosTsybzx4hw/p4faZKh2cHax3ImmwA/bP/g9eTv56w3qcqSn+ti7LOJbwCHOMAzr ml2DflzleOlhu3yqaOGuxuphn+yHriaE7bYneSLRBAaa6re/cWZOaTA3m6S3aGX1CvWxbsFYznbSd axE1hIXXqyzPtSYPCPF8pgxPRQlOxqBJkQBEvwS4A+Hzu8wwAea1v1ZyRylNkDUAvdkEMMy3ueo54 UXTjYWjN+eL0QShps6vSEMCBU5zYCW4YFNQ+zBXwPmPIOCIFmMJmgM2Rmr8dhT3nSzN1WN/8PuUpm S3S91mDw==; Received: from dhcp-bb61.meeting.ietf.org ([31.133.187.97]:40932) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gKiGv-0007bZ-PC; Thu, 08 Nov 2018 11:14:50 +0000 To: quic-chairs@ietf.org, "tcpm-chairs@ietf.org" , Jana Iyengar , Ian Swett From: Bob Briscoe Cc: QUIC IETF mailing list , tcpm IETF list Message-ID: Date: Thu, 8 Nov 2018 11:14:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 11:14:54 -0000 I just wanted to thank Jana for explaining QUIC loss recovery to us (and QUIC CC as far as it goes). And thank you Jana, Ian, the chairs of both WGs (and anyone else involved) for setting it up. If one is not full-time on QUIC, it's very difficult to keep up with all the changes. But now we have a checkpoint to start from, I feel I will not be wasting people's time if I try to get involved - at least I only might say something un-QUIC occasionally, rather than nearly always. This has allowed people who understand how TCP cold be improved to help with QUIC, when working on QUIC isn't their day job. Again, Thank you. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Nov 8 03:55:48 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDE0123FFD; Thu, 8 Nov 2018 03:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4fjYUbIvt02; Thu, 8 Nov 2018 03:55:36 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFDD12896A; Thu, 8 Nov 2018 03:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=EC3iUSN2yCGc+kEqvmDXNIh4i9sQVVPOB+P5rv3kt1E=; b=IBKNNafgs5y+BfxifkRZixnzQ pdDy4V+8+pctN3NKGKSOaVYEt1JGbgdsDMmch9RKlfJF6pS42iaGQponGNwZEmXBsOZmRsh3n7h3F NNkRHiex5bOwZ0S3Ni6DBAUC3LNEHSAlP/44lgrxWj/v2/d0RCocAfWwhhJ4VTPaXf3nIbfE5A8/7 kKdSspUq2L4WvajuPEIUwCFLCU0ZKvBomGCCGaPXUmNKG17QSJSCpiG7twdEuB1/xzKdBw1++pyAg WMFH/tIGLXZdDaD4ISNLU8I71BRdjI8zC107XKjcna/vydg++2rRzSmt2l8RzSIrONoWy4LHNIjdx 8w+jB3Uvw==; Received: from dhcp-bb61.meeting.ietf.org ([31.133.187.97]:41494) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gKiuM-0003kc-Kh; Thu, 08 Nov 2018 11:55:34 +0000 To: "Scharf, Michael" , "tcpm@ietf.org" Cc: "tsvwg@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> Date: Thu, 8 Nov 2018 11:55:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------93F7985647850F4F3DF81E38" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 11:55:39 -0000 This is a multi-part message in MIME format. --------------93F7985647850F4F3DF81E38 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Michael, This is merely a symptom of a difference in opinion on where the resequencing function should be located. * L4S takes the end-to-end approach saying that it is sufficient to do resequencing in one place (the receiving host) if it is needed. Then any resequencing delay only affects that flow. * The DETNET approach is saying the resequencing must be done hop-by-hop. This means there appears to be no resequencing needed on the receiver (except if there's re-ordering on the final hop). * In order to guarantee no resequencing in the network (DETNET approach), only the the worst case latency can be guaranteed, and every packet has to have that same worst-case latency. * When you leave resequencing to the receiver (end-to-end approach), most of the packets arrive earlier than they would with DETNET, but out of order ones might not. Then the application chooses whether it wants to wait. The 3 DupACK rule in TCP led the Internet not to follow the end-to-end principle on re-sequencing. Now we're removing the 3 DupACK rule, we can take advantage of the e2e principle. Of course, an application might choose to use TCP and L4S, rather than UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the receiving TCP stack. But at least there's no HoL blocking in the network, and the app can choose between stream (TCP) or datagram (UDP). Bob On 06/11/2018 19:20, Scharf, Michael wrote: > A comment on the TCPM presentation "L4S and RACK": > > As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery. > > So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful? > > Michael > (who recently had to review draft-ietf-detnet-architecture) > > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------93F7985647850F4F3DF81E38 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Michael,

This is merely a symptom of a difference in opinion on where the resequencing function should be located.

  • L4S takes the end-to-end approach saying that it is sufficient to do resequencing in one place (the receiving host) if it is needed. Then any resequencing delay only affects that flow.
  • The DETNET approach is saying the resequencing must be done hop-by-hop. This means there appears to be no resequencing needed on the receiver (except if there's re-ordering on the final hop).

  • In order to guarantee no resequencing in the network (DETNET approach), only the the worst case latency can be guaranteed, and every packet has to have that same worst-case latency.
  • When you leave resequencing to the receiver (end-to-end approach), most of the packets arrive earlier than they would with DETNET, but out of order ones might not. Then the application chooses whether it wants to wait.
The 3 DupACK rule in TCP led the Internet not to follow the end-to-end principle on re-sequencing. Now we're removing the 3 DupACK rule, we can take advantage of the e2e principle.

Of course, an application might choose to use TCP and L4S, rather than UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the receiving TCP stack. But at least there's no HoL blocking in the network, and the app can choose between stream (TCP) or datagram (UDP).


Bob

On 06/11/2018 19:20, Scharf, Michael wrote:
A comment on the TCPM presentation "L4S and RACK":

As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery.

So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful?

Michael
(who recently had to review draft-ietf-detnet-architecture)




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------93F7985647850F4F3DF81E38-- From nobody Thu Nov 8 08:35:18 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E255712F295; Thu, 8 Nov 2018 08:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sejjj1LGmr3c; Thu, 8 Nov 2018 08:35:05 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CAD0128BCC; Thu, 8 Nov 2018 08:35:04 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id B3FA925A17; Thu, 8 Nov 2018 17:35:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1541694902; bh=15lO1jkTSb1SZkdL0GEv20VeZFAISuw7KEIxEWuXzmM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=WWi0u/w1ZtYwTxDoKphpzdEvd9wIrU3p6q6Bag4S1W7zlIinpnofGOnPUHwknmoXN 13Uuv8qr2Ax6ldK3vjiT3KuTh4nYcksY38DZPsrSXa2zCw5WwC7PdKPIfvObD8f/qT E6MQE2ZH4D10yYzZGSp3GBcUk9GDmx9MLa2AJ4w8= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItRtp1Dmlm3i; Thu, 8 Nov 2018 17:35:02 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.hs-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 8 Nov 2018 17:35:02 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.25]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Thu, 8 Nov 2018 17:35:02 +0100 From: "Scharf, Michael" To: Bob Briscoe , "tcpm@ietf.org" CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Cross-area alignment on "L4S and RACK" Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFgBS9LuAAAnyRqA= Date: Thu, 8 Nov 2018 16:35:01 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> In-Reply-To: <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D15201Arznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 16:35:08 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D15201Arznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5saW5lIFttc10NCg0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0bzppbkBib2JicmlzY29lLm5l dF0NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciA4LCAyMDE4IDEyOjU2IFBNDQpUbzogU2NoYXJm LCBNaWNoYWVsOyB0Y3BtQGlldGYub3JnDQpDYzogdHN2d2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbdHN2d2ddIENyb3NzLWFyZWEgYWxpZ25tZW50IG9uICJMNFMgYW5kIFJBQ0siDQoNCk1pY2hh ZWwsDQoNClRoaXMgaXMgbWVyZWx5IGEgc3ltcHRvbSBvZiBhIGRpZmZlcmVuY2UgaW4gb3Bpbmlv biBvbiB3aGVyZSB0aGUgcmVzZXF1ZW5jaW5nIGZ1bmN0aW9uIHNob3VsZCBiZSBsb2NhdGVkLg0K DQogICogICBMNFMgdGFrZXMgdGhlIGVuZC10by1lbmQgYXBwcm9hY2ggc2F5aW5nIHRoYXQgaXQg aXMgc3VmZmljaWVudCB0byBkbyByZXNlcXVlbmNpbmcgaW4gb25lIHBsYWNlICh0aGUgcmVjZWl2 aW5nIGhvc3QpIGlmIGl0IGlzIG5lZWRlZC4gVGhlbiBhbnkgcmVzZXF1ZW5jaW5nIGRlbGF5IG9u bHkgYWZmZWN0cyB0aGF0IGZsb3cuDQogICogICBUaGUgREVUTkVUIGFwcHJvYWNoIGlzIHNheWlu ZyB0aGUgcmVzZXF1ZW5jaW5nIG11c3QgYmUgZG9uZSBob3AtYnktaG9wLiBUaGlzIG1lYW5zIHRo ZXJlIGFwcGVhcnMgdG8gYmUgbm8gcmVzZXF1ZW5jaW5nIG5lZWRlZCBvbiB0aGUgcmVjZWl2ZXIg KGV4Y2VwdCBpZiB0aGVyZSdzIHJlLW9yZGVyaW5nIG9uIHRoZSBmaW5hbCBob3ApLg0KDQoNCiAg KiAgIEluIG9yZGVyIHRvIGd1YXJhbnRlZSBubyByZXNlcXVlbmNpbmcgaW4gdGhlIG5ldHdvcmsg KERFVE5FVCBhcHByb2FjaCksIG9ubHkgdGhlIHRoZSB3b3JzdCBjYXNlIGxhdGVuY3kgY2FuIGJl IGd1YXJhbnRlZWQsIGFuZCBldmVyeSBwYWNrZXQgaGFzIHRvIGhhdmUgdGhhdCBzYW1lIHdvcnN0 LWNhc2UgbGF0ZW5jeS4NCiAgKiAgIFdoZW4geW91IGxlYXZlIHJlc2VxdWVuY2luZyB0byB0aGUg cmVjZWl2ZXIgKGVuZC10by1lbmQgYXBwcm9hY2gpLCBtb3N0IG9mIHRoZSBwYWNrZXRzIGFycml2 ZSBlYXJsaWVyIHRoYW4gdGhleSB3b3VsZCB3aXRoIERFVE5FVCwgYnV0IG91dCBvZiBvcmRlciBv bmVzIG1pZ2h0IG5vdC4gVGhlbiB0aGUgYXBwbGljYXRpb24gY2hvb3NlcyB3aGV0aGVyIGl0IHdh bnRzIHRvIHdhaXQuDQpbbXNdIE15IHBvaW50IGlzIGRpZmZlcmVudDogVGhlcmUgc2VlbSB0byBi ZSBvdGhlciB3b3JraW5nIGdyb3VwcyBpbiB0aGUgSUVURiB0aGF0IGRvIHRhbGsgYWJvdXQg4oCc bG93IGxhdGVuY3nigJ0gYXMgd2VsbCBidXQgYXBwYXJlbnRseSB0aGV5IGFsc28gZG8gbmVlZCBp bi1vcmRlciBkZWxpdmVyeSBvZiBwYWNrZXRzLCB0b28uIFNvIHRoZSBhc3N1bXB0aW9uIHRoYXQg ZS5nLiBhIGxpbmsgbGF5ZXIgdGVjaG5vbG9neSBjYW4gc2ltcGx5IGRpc2FibGUgaW4tb3JkZXIg ZGVsaXZlcnkgZm9yIGFsbCDigJxsb3cgbGF0ZW5jeeKAnSBhcHBsaWNhdGlvbnMgc2VlbXMgbm90 IGNvcnJlY3QuIFRoZSByZWFsaXR5IG1heSBiZSBhIGJpdCBtb3JlIGNvbXBsZXguDQpUaGUgMyBE dXBBQ0sgcnVsZSBpbiBUQ1AgbGVkIHRoZSBJbnRlcm5ldCBub3QgdG8gZm9sbG93IHRoZSBlbmQt dG8tZW5kIHByaW5jaXBsZSBvbiByZS1zZXF1ZW5jaW5nLiBOb3cgd2UncmUgcmVtb3ZpbmcgdGhl IDMgRHVwQUNLIHJ1bGUsIHdlIGNhbiB0YWtlIGFkdmFudGFnZSBvZiB0aGUgZTJlIHByaW5jaXBs ZS4NClttc10gRm9yIFRDUCwgdGhyZWUgRHVwQUNLUyBhcmUgYSBTSE9VTEQgaW4gUkZDIDU2ODEg YW5kIFJGQyA1NjgxIGlzIHN0YW5kYXJkcyB0cmFjay4gU28gdGhlIGJhciBmb3Ig4oCccmVtb3Zp bmfigJ0gdGhhdCBydWxlIGZvciBUQ1AgaXMgbm90IGxvd+KApg0KW21zXSBBbHNvLCB0aGUgZW5k LXRvLWVuZCBwcmluY2lwbGUgY29tZXMgd2l0aCB0cmFkZW9mZnMuIEZvciBpbnN0YW5jZSwgcmVs eWluZyBvbiB0aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUgZm9yIHJlY292ZXJ5IG9mIGJpdCBlcnJv cnMgaXMgbm90IGVmZmljaWVudC4gRm9yIGluLW9yZGVyIGRlbGl2ZXJ5IHRoZXJlIGFyZSB0cmFk ZW9mZnMgYXMgd2VsbCwgc2VlIGUuZy4gU2VjdGlvbiA0IGluIGRyYWZ0LWlldGYtdGNwbS1yYWNr LTA0LiBUaGVyZSBtYXkgYmUgbm8gZnJlZSBsdW5jaC4NCk9mIGNvdXJzZSwgYW4gYXBwbGljYXRp b24gbWlnaHQgY2hvb3NlIHRvIHVzZSBUQ1AgYW5kIEw0UywgcmF0aGVyIHRoYW4gVURQIGFuZCBM NFMgKGUuZyBRVUlDKS4gVGhlbiB0aGVyZSBjb3VsZCBzdGlsbCBiZSBIb0wgYmxvY2tpbmcgaW4g dGhlIHJlY2VpdmluZyBUQ1Agc3RhY2suIEJ1dCBhdCBsZWFzdCB0aGVyZSdzIG5vIEhvTCBibG9j a2luZyBpbiB0aGUgbmV0d29yaywgYW5kIHRoZSBhcHAgY2FuIGNob29zZSBiZXR3ZWVuIHN0cmVh bSAoVENQKSBvciBkYXRhZ3JhbSAoVURQKS4NClttc10gSWYgTFJPL0dSTyBpbiB0aGUgcmVjZWl2 aW5nIFRDUCBzdGFjayBnZXRzIG1lc3NlZCB1cCwgSSBmYWlsIHRvIHNlZSB0aGUgYmVuZWZpdCAo c2VlIGRyYWZ0LWlldGYtdGNwbS1yYWNrLTA0KS4NCk1pY2hhZWwNCg0KDQpCb2INCk9uIDA2LzEx LzIwMTggMTk6MjAsIFNjaGFyZiwgTWljaGFlbCB3cm90ZToNCg0KQSBjb21tZW50IG9uIHRoZSBU Q1BNIHByZXNlbnRhdGlvbiAiTDRTIGFuZCBSQUNLIjoNCg0KDQoNCkFzIGZhciBhcyBJIHVuZGVy c3RhbmQsIHRoZSBERVRORVQgV0cgaW4gUlRHIGFyZWEgaGFzIHF1aXRlIHNvbWUgdXNlcyBjYXNl cyBmb3IgdWx0cmEtbG93IGxhdGVuY3kgdHJhbnNwb3J0IC0gaW4gcGFydGljdWxhciBhbHNvIHdp dGggYm91bmRlZCBqaXR0ZXIuIEFuZCBzb21lIG9mIHRoZXNlIGFwcGxpY2F0aW9ucyAoZS5nLiB1 c2luZyBVRFApIGFwcGFyZW50bHkgbWF5IG5vdCBiZSBhYmxlIHRvIHRvbGVyYXRlICphbnkqIG91 dC1vZi1vcmRlciBwYWNrZXQgZGVsaXZlcnkuDQoNCg0KDQpTbyBwZXJoYXBzIHNvbWUgY3Jvc3Mt YXJlYSBhbGlnbm1lbnQgb24gdWx0YS1sb3ctbGF0ZW5jeSBhcHBsaWNhdGlvbiByZXF1aXJlbWVu dHMgd291bGQgYmUgdXNlZnVsPw0KDQoNCg0KTWljaGFlbA0KDQood2hvIHJlY2VudGx5IGhhZCB0 byByZXZpZXcgZHJhZnQtaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlKQ0KDQoNCg0KDQoNCg0KDQot LQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D15201Arznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNobiI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFZv cmZvcm1hdGllcnRaY2huDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNo biI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZv cm1hdGllcnQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u RS1NYWlsRm9ybWF0dm9ybGFnZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo1MjE0MzEyNjU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDEzNDQ2 NDA4O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEN Cgl7bXNvLWxpc3QtaWQ6MjEyMTg3MDczNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1OTMx NTAwMTI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbmxpbmUgW21zXTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgW21haWx0bzppbkBib2JicmlzY29lLm5ldF0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgOCwgMjAxOCAxMjo1NiBQTTxi cj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsOyB0Y3BtQGlldGYub3JnPGJyPg0KPGI+Q2M6 PC9iPiB0c3Z3Z0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RzdndnXSBDcm9z cy1hcmVhIGFsaWdubWVudCBvbiAmcXVvdDtMNFMgYW5kIFJBQ0smcXVvdDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPk1pY2hhZWwsPGJyPg0KPGJyPg0KVGhpcyBpcyBtZXJlbHkgYSBzeW1wdG9tIG9mIGEg ZGlmZmVyZW5jZSBpbiBvcGluaW9uIG9uIHdoZXJlIHRoZSByZXNlcXVlbmNpbmcgZnVuY3Rpb24g c2hvdWxkIGJlIGxvY2F0ZWQuPG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCkw0UyB0YWtlcyB0 aGUgZW5kLXRvLWVuZCBhcHByb2FjaCBzYXlpbmcgdGhhdCBpdCBpcyBzdWZmaWNpZW50IHRvIGRv IHJlc2VxdWVuY2luZyBpbiBvbmUgcGxhY2UgKHRoZSByZWNlaXZpbmcgaG9zdCkgaWYgaXQgaXMg bmVlZGVkLiBUaGVuIGFueSByZXNlcXVlbmNpbmcgZGVsYXkgb25seSBhZmZlY3RzIHRoYXQgZmxv dy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZl bDEgbGZvMSI+DQpUaGUgREVUTkVUIGFwcHJvYWNoIGlzIHNheWluZyB0aGUgcmVzZXF1ZW5jaW5n IG11c3QgYmUgZG9uZSBob3AtYnktaG9wLiBUaGlzIG1lYW5zIHRoZXJlIGFwcGVhcnMgdG8gYmUg bm8gcmVzZXF1ZW5jaW5nIG5lZWRlZCBvbiB0aGUgcmVjZWl2ZXIgKGV4Y2VwdCBpZiB0aGVyZSdz IHJlLW9yZGVyaW5nIG9uIHRoZSBmaW5hbCBob3ApLg0KPG86cD48L286cD48L2xpPjwvdWw+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KSW4g b3JkZXIgdG8gZ3VhcmFudGVlIG5vIHJlc2VxdWVuY2luZyBpbiB0aGUgbmV0d29yayAoREVUTkVU IGFwcHJvYWNoKSwgb25seSB0aGUgdGhlIHdvcnN0IGNhc2UgbGF0ZW5jeSBjYW4gYmUgZ3VhcmFu dGVlZCwgYW5kIGV2ZXJ5IHBhY2tldCBoYXMgdG8gaGF2ZSB0aGF0IHNhbWUgd29yc3QtY2FzZSBs YXRlbmN5LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8yIj4NCldoZW4geW91IGxlYXZlIHJlc2VxdWVuY2luZyB0byB0aGUgcmVjZWl2 ZXIgKGVuZC10by1lbmQgYXBwcm9hY2gpLCBtb3N0IG9mIHRoZSBwYWNrZXRzIGFycml2ZSBlYXJs aWVyIHRoYW4gdGhleSB3b3VsZCB3aXRoIERFVE5FVCwgYnV0IG91dCBvZiBvcmRlciBvbmVzIG1p Z2h0IG5vdC4gVGhlbiB0aGUgYXBwbGljYXRpb24gY2hvb3NlcyB3aGV0aGVyIGl0IHdhbnRzIHRv IHdhaXQuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+W21zXSBNeSBwb2ludCBpcyBkaWZmZXJlbnQ6IFRoZXJlIHNlZW0gdG8gYmUgb3RoZXIg d29ya2luZyBncm91cHMgaW4gdGhlIElFVEYgdGhhdCBkbyB0YWxrIGFib3V0IOKAnGxvdyBsYXRl bmN54oCdIGFzIHdlbGwgYnV0IGFwcGFyZW50bHkgdGhleSBhbHNvIGRvIG5lZWQgaW4tb3JkZXIg ZGVsaXZlcnkNCiBvZiBwYWNrZXRzLCB0b28uIFNvIHRoZSBhc3N1bXB0aW9uIHRoYXQgZS5nLiBh IGxpbmsgbGF5ZXIgdGVjaG5vbG9neSBjYW4gc2ltcGx5IGRpc2FibGUgaW4tb3JkZXIgZGVsaXZl cnkgZm9yIGFsbCDigJxsb3cgbGF0ZW5jeeKAnSBhcHBsaWNhdGlvbnMgc2VlbXMgbm90IGNvcnJl Y3QuIFRoZSByZWFsaXR5IG1heSBiZSBhIGJpdCBtb3JlIGNvbXBsZXguPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIDMgRHVwQUNLIHJ1bGUgaW4gVENQIGxlZCB0aGUgSW50 ZXJuZXQgbm90IHRvIGZvbGxvdyB0aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUgb24gcmUtc2VxdWVu Y2luZy4NCjwvc3Bhbj5Ob3cgd2UncmUgcmVtb3ZpbmcgdGhlIDMgRHVwQUNLIHJ1bGUsIHdlIGNh biB0YWtlIGFkdmFudGFnZSBvZiB0aGUgZTJlIHByaW5jaXBsZS48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlttc10gRm9yIFRDUCwgdGhyZWUgRHVwQUNLUyBhcmUg YSBTSE9VTEQgaW4gUkZDIDU2ODEgYW5kIFJGQyA1NjgxIGlzIHN0YW5kYXJkcyB0cmFjay4gU28g dGhlIGJhciBmb3Ig4oCccmVtb3ZpbmfigJ0gdGhhdA0KIHJ1bGUgZm9yIFRDUCBpcyBub3QgbG93 4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlttc10gQWxzbywgdGhlIGVuZC10by1lbmQgcHJpbmNpcGxlIGNv bWVzIHdpdGggdHJhZGVvZmZzLiBGb3IgaW5zdGFuY2UsIHJlbHlpbmcgb24gdGhlIGVuZC10by1l bmQgcHJpbmNpcGxlIGZvciByZWNvdmVyeQ0KIG9mIGJpdCBlcnJvcnMgaXMgbm90IGVmZmljaWVu dC4gRm9yIGluLW9yZGVyIGRlbGl2ZXJ5IHRoZXJlIGFyZSB0cmFkZW9mZnMgYXMgd2VsbCwgc2Vl IGUuZy4gU2VjdGlvbiA0IGluIGRyYWZ0LWlldGYtdGNwbS1yYWNrLTA0LiBUaGVyZSBtYXkgYmUg bm8gZnJlZSBsdW5jaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5PZiBjb3Vy c2UsIGFuIGFwcGxpY2F0aW9uIG1pZ2h0IGNob29zZSB0byB1c2UgVENQIGFuZCBMNFMsIHJhdGhl ciB0aGFuIFVEUCBhbmQgTDRTIChlLmcgUVVJQykuDQo8L3NwYW4+VGhlbiB0aGVyZSBjb3VsZCBz dGlsbCBiZSBIb0wgYmxvY2tpbmcgaW4gdGhlIHJlY2VpdmluZyBUQ1Agc3RhY2suIEJ1dCBhdCBs ZWFzdCB0aGVyZSdzIG5vIEhvTCBibG9ja2luZyBpbiB0aGUgbmV0d29yaywgYW5kIHRoZSBhcHAg Y2FuIGNob29zZSBiZXR3ZWVuIHN0cmVhbSAoVENQKSBvciBkYXRhZ3JhbSAoVURQKS48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlttc10gSWYgTFJPL0dSTyBpbiB0 aGUgcmVjZWl2aW5nIFRDUCBzdGFjayBnZXRzIG1lc3NlZCB1cCwgSSBmYWlsIHRvIHNlZSB0aGUg YmVuZWZpdCAoc2VlIGRyYWZ0LWlldGYtdGNwbS1yYWNrLTA0KS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWlj aGFlbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPGJyPg0KQm9iPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA2LzExLzIw MTggMTk6MjAsIFNjaGFyZiwgTWljaGFlbCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cHJlPkEgY29tbWVudCBvbiB0aGUgVENQTSBwcmVzZW50YXRpb24gJnF1b3Q7TDRTIGFuZCBS QUNLJnF1b3Q7OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPkFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZSBERVRORVQgV0cgaW4gUlRHIGFyZWEg aGFzIHF1aXRlIHNvbWUgdXNlcyBjYXNlcyBmb3IgdWx0cmEtbG93IGxhdGVuY3kgdHJhbnNwb3J0 IC0gaW4gcGFydGljdWxhciBhbHNvIHdpdGggYm91bmRlZCBqaXR0ZXIuIEFuZCBzb21lIG9mIHRo ZXNlIGFwcGxpY2F0aW9ucyAoZS5nLiB1c2luZyBVRFApIGFwcGFyZW50bHkgbWF5IG5vdCBiZSBh YmxlIHRvIHRvbGVyYXRlICphbnkqIG91dC1vZi1vcmRlciBwYWNrZXQgZGVsaXZlcnkuPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U28gcGVyaGFw cyBzb21lIGNyb3NzLWFyZWEgYWxpZ25tZW50IG9uIHVsdGEtbG93LWxhdGVuY3kgYXBwbGljYXRp b24gcmVxdWlyZW1lbnRzIHdvdWxkIGJlIHVzZWZ1bD88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5NaWNoYWVsPG86cD48L286cD48L3ByZT4NCjxw cmU+KHdobyByZWNlbnRseSBoYWQgdG8gcmV2aWV3IGRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVj dHVyZSk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5u ZXQvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_6EC6417807D9754DA64F3087E2E2E03E2D15201Arznt8114rzntrzd_-- From nobody Thu Nov 8 16:38:40 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8872D12F1A2 for ; Thu, 8 Nov 2018 16:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.502 X-Spam-Level: X-Spam-Status: No, score=-17.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuRA5SLBXtIK for ; Thu, 8 Nov 2018 16:38:37 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABAA129C6A for ; Thu, 8 Nov 2018 16:38:37 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id m34-v6so890881iti.1 for ; Thu, 08 Nov 2018 16:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=erTzarVDxKn4IzqJ350OpoqmKUkXydN0a2uSBg1+q4g=; b=SQK8/oepp7paXQpGC+m5/yeexiZbxW1U016JceZnyz0UdwkDRcpcdJF96DlGI4CKto 2C/Q8iSaD5DGXB5CTik2HYCBB0saoTlVC4U4WcEpQZy+BgxshPfO/AXH8jlrb4chqcdl 45eYiWCfKDFcMF0EnIS6wgA4gsdwiBRR3KbDHTolcwnE1pmoiArcXFsfGBW7NwiyRzZ7 kJo1sQHTOxh2Wi9/QFbOSzeTaT33auoF3pcsIr6Rc/ABYt2eEIVJDnyrw9v2Q0dKwyMS HdHGJ0apE5YPaaF786xjyv0oblGF+3+hRPOau990er6XQAJcKn10+qOKKG19caL93ZeQ H7IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=erTzarVDxKn4IzqJ350OpoqmKUkXydN0a2uSBg1+q4g=; b=FTDZxRmmYUMyWcLffRUwkpAEsco0/v6HY568lvumcwWjh/EShaMbsAj1CepUVzNqR1 qO77c8bOowmlmvG4bIp8nO0GLDjRAyiix3CjAKAWUPgcE+nuve2/4Fitd0OFxgBdEeJ4 yDWJ9f+kUqFTI/tKyDce79M/lLDzzFWGS0lhXFMnMJJBunFOLKRPimLhrKyfha03+i4T /kVDCnwTHuLbT/BEmjN+fXPoEAU43tCvzweBIKd3zhZpHwd3XFBg+iqe7S+1WkRg0lUL 3a0hXO4C8hn0Ra77icy1rhN/LH8h9vS8PBhcI915juaCf2UhBuP6byWlKklR1NTzv6Mq zBfQ== X-Gm-Message-State: AGRZ1gIOxJfwpRlZC5ImlM/fWK0AIR7Il+WlVM9Kzc0x5mYU4LdcJgei JNX/66hi1fb56ZzBduTrEKSpsowfRs/+f/1CB8CB6A== X-Google-Smtp-Source: AJdET5cK8yDq4QGiOjHoJeMx9QXqbv3YfzHdfPDbCcBTUMbiSRZLojzYqt0qPBDHX75UtmZIANYmi7S2cukjawQoWjA= X-Received: by 2002:a24:2f8c:: with SMTP id j134-v6mr538798itj.125.1541723916270; Thu, 08 Nov 2018 16:38:36 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a5e:8515:0:0:0:0:0 with HTTP; Thu, 8 Nov 2018 16:37:55 -0800 (PST) In-Reply-To: References: From: Yuchung Cheng Date: Thu, 8 Nov 2018 16:37:55 -0800 Message-ID: To: Bob Briscoe Cc: Jana Iyengar , Ian Swett , tcpm IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 00:38:39 -0000 On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe wrote: > > I just wanted to thank Jana for explaining QUIC loss recovery to us (and = QUIC CC as far as it goes). > And thank you Jana, Ian, the chairs of both WGs (and anyone else involved= ) for setting it up. > > If one is not full-time on QUIC, it's very difficult to keep up with all = the changes. But now we have a checkpoint to start from, I feel I will not = be wasting people's time if I try to get involved - at least I only might s= ay something un-QUIC occasionally, rather than nearly always. This has allo= wed people who understand how TCP cold be improved to help with QUIC, when = working on QUIC isn't their day job. > > Again, Thank you. I like particularly that QUIC only reduces cwnd to 1 after the loss is confirmed not upon RTO fires. It should be very feasible for TCP (at least Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd reductions! Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt-ids. Google internally uses usec. We wish we could upstream it but RFC needs to be updated. > > > Bob > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Nov 8 17:34:41 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5381A12F1AB for ; Thu, 8 Nov 2018 17:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jo4w2h0f5EQw for ; Thu, 8 Nov 2018 17:34:36 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0131.outbound.protection.outlook.com [104.47.36.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515C7124D68 for ; Thu, 8 Nov 2018 17:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/R7Og7juYSISUdulNFXQuVTtZXS5F8iWhJqzxXNx9sM=; b=Qo003iGjOSRU7mbuJ/wnPTb8OV82rj+e7HKmfUOk0z6jGH7bRN9Q+mdYPparVxw9Ruo8cYv4uzTLHA0ME29iMC6ut58wdV49VRZODd4zJaF6tFjj46Y//vQ06+caW7T0MXzyTF0TLGGeRWsDIWiDCz2DS1JaQFneoCVXtpTYRQc= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1020.namprd21.prod.outlook.com (52.132.148.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.8; Fri, 9 Nov 2018 01:34:34 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a%4]) with mapi id 15.20.1339.009; Fri, 9 Nov 2018 01:34:34 +0000 From: Praveen Balasubramanian To: Yuchung Cheng , Bob Briscoe CC: Ian Swett , tcpm IETF list Thread-Topic: [tcpm] Thank you for the QUIC session in tcpm Thread-Index: AQHUd1RO08g6biwnTkKIBqYAsYD8EKVGmkCAgAAPe9A= Date: Fri, 9 Nov 2018 01:34:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:3:f570:32cd:aba6:c7e2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR2101MB1020; 6:DiRR2+xqxGnpdf02JInFzUTakuRd1cGo2/OYuHa+0n/v02jwq4VquwtgBcLp8DgDA++gltpWGyeCG0EfMj4f59weJS6/xDCbxiXiAdwTgmobyurIjQCopzSPfV1y7J5Qa2/IjA2TC+NzhdNW+UlYQMk4yJsCcl+246sHSBFze7Q7XS/6c8e9Q+L5hXBQZiOQlIDDTk0VJb8Ra+WTHagqrW7VKMT+X/YXxh3vgIRVXWfEgDrnY8R7ybpEHFk8dk86Ck0otCj7uaAPXzIeLe7UKIkIU/OKjoqMks/L2QAeG4WUaY0NbvehtsI7wiuUvlDfdeokjs1p3MoyHTllO7WMS2wzYzxcRVk0LgYBn4RJfXaBFCSYkQ7OAedei0SopsBRILO/XM5YH0RrjGi5hxTVh2sOsDScJFlAOjqGzyaS6dhQB/+8FSNGBKXiFYlhRVhrJ92m3cI70jnpZBKx5AkBlw==; 5:EECXWqwilGu7yh9huDdlmiaLNu0EpqMoo5F97k0+3XxxZ+Yt/qSJJAmwgbfTi+Q9gUKNxCeIPPdVAGTW+bsmD4+cgvylDWo1G3KBRd+xRrYQTpxaXjHl1h9RpvM69IVmB71xOgmtoXkf/xVkytmjo1vc66gHZPeBQ6V9GWThNsU=; 7:avV8In0MK/z0ZHcH+30J/M9Y2wG0hhuu+3KIwRrE7ILbplPOEk7cKu2OP6Lug/shvoFESO1xbnaVEq252FR7t2O8QC+KPL7zQhnKa8teBxW7fAy8rJ3xHG4rSoSogXWyfqiBXn/Kh/rsNPt4Wq3S/g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 29a45add-1e8d-4e1f-30e8-08d645e38131 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MW2PR2101MB1020; x-ms-traffictypediagnostic: MW2PR2101MB1020: x-ms-exchange-purlcount: 3 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(8220035)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231390)(944501410)(4982022)(2018427008)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:MW2PR2101MB1020; BCL:0; PCL:0; RULEID:; SRVR:MW2PR2101MB1020; x-forefront-prvs: 08512C5403 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(39860400002)(396003)(366004)(13464003)(199004)(189003)(345774005)(2900100001)(102836004)(2906002)(305945005)(97736004)(76176011)(478600001)(99286004)(10290500003)(4326008)(86362001)(86612001)(6116002)(7696005)(25786009)(7736002)(256004)(5660300001)(53546011)(446003)(106356001)(6506007)(11346002)(105586002)(71200400001)(33656002)(486006)(476003)(71190400001)(14454004)(110136005)(46003)(54906003)(22452003)(186003)(966005)(68736007)(316002)(6246003)(74316002)(8990500004)(10090500001)(9686003)(55016002)(6306002)(6436002)(8676002)(81156014)(229853002)(81166006)(53936002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1020; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: sGYtL7r7+N1L4yO8ZbcZoig9vDMU5QeDcNda4OGKnXMwO5lwokrPqfg1Z5oOrnvel6wDqt7b/OMv3tmEjY3dU52FrJtUEJVvkEvmfELHs7FsEkCgyfBsvESeWOfm4W4j7PgLQi5KET2GJDvw6MJaM9shW6/UeH9Nxs/EgA6m8dIDlv0ZU6GI8S/sRoyleLiYmKmcPL0yXhKsOiJO85ap9nu8eVOOo9qP+RB12/nXS4i5P1/CM2b3cQFqtCGE69NbPDOTp6yQ2MZqtmUmTjcxsHNPLS+0Bf1hXEp4fx7Gm61UpFYZOFjcjgY7koqHIlfqEAsqnyWhpe66PrgQq+Rz4N6VrZatluI1sD3k719/8Qk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29a45add-1e8d-4e1f-30e8-08d645e38131 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2018 01:34:34.5079 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1020 Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 01:34:40 -0000 Yuchung I brought that difference up in an email to the quic wg earlier thi= s week.=20 In app send limited case, inflight could be very small compared to cwnd. So= in QUIC there is potential to send a burst out after a long idle period (w= ith outstanding data) where TCP wouldn't. The draft claims this is okay to = do because RTO may have been a result of RTT increase instead of loss. Is t= here data to suggest on which side we should err? i.e. data on what are the= chances that an RTO is due to an RTT increase versus loss. Do you see any safety concerns with delayed reduction of cwnd in case where= the RTO is not spurious? -----Original Message----- From: tcpm On Behalf Of Yuchung Cheng Sent: Thursday, November 8, 2018 4:38 PM To: Bob Briscoe Cc: Ian Swett ; tcpm IETF list Subject: Re: [tcpm] Thank you for the QUIC session in tcpm On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe wrote: > > I just wanted to thank Jana for explaining QUIC loss recovery to us (and = QUIC CC as far as it goes). > And thank you Jana, Ian, the chairs of both WGs (and anyone else involved= ) for setting it up. > > If one is not full-time on QUIC, it's very difficult to keep up with all = the changes. But now we have a checkpoint to start from, I feel I will not = be wasting people's time if I try to get involved - at least I only might s= ay something un-QUIC occasionally, rather than nearly always. This has allo= wed people who understand how TCP cold be improved to help with QUIC, when = working on QUIC isn't their day job. > > Again, Thank you. I like particularly that QUIC only reduces cwnd to 1 after the loss is conf= irmed not upon RTO fires. It should be very feasible for TCP (at least Linu= x) w/ TCP timestamps. It'll save a lot of spurious cwnd reductions! Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt-ids. Goo= gle internally uses usec. We wish we could upstream it but RFC needs to be = updated. > > > Bob > > > -- > ________________________________________________________________ > Bob Briscoe https://na01.safelinks.protecti= on.outlook.com/?url=3Dhttp%3A%2F%2Fbobbriscoe.net%2F&data=3D02%7C01%7Cp= ravb%40microsoft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af9= 1ab2d7cd011db47%7C1%7C0%7C636773207316711149&sdata=3D0pt6YfpYOaF%2B5IWE= KY3LMj1idEnYbApqUvWzhtLa5qE%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microso > ft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7cd0 > 11db47%7C1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfAlyhK > QQ05Cea421rgb64DlEMvs%3D&reserved=3D0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.com= %7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7cd011db47%7C1%= 7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfAlyhKQQ05Cea421rgb6= 4DlEMvs%3D&reserved=3D0 From nobody Thu Nov 8 20:02:11 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA541292F1; Thu, 8 Nov 2018 20:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=0EFTq2K9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ytmJp8cA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vSFrMNWqB8B; Thu, 8 Nov 2018 20:02:05 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8871B1277BB; Thu, 8 Nov 2018 20:02:05 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 541F1BF8; Thu, 8 Nov 2018 23:02:04 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 08 Nov 2018 23:02:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=3 c7+Xg0+gtErgvV8floy4BeiD5bvry0s5jqri8ab0do=; b=0EFTq2K9EIBzh3LLI Dhd/rxllxlUveBxGl4r1BeNsWRTBMWoF69TDB0LXwgvPG2qFYmWwZr9GbMcA+2mU Ptbw+MoJkHzwEwAphLMfozKpgP3gidbJmJTbCoA1MOlKNudQYlDLX2e84jiNbaqI DLujTEdIXIdgACNFTnQ/YhmcpgES9pBgmUPmBTAE1XPy0+xru5nJ6y2d2Z2FvzPG HcgfuDLSFCjHD5V+gCpEu6fe95mVChf1MwzCoVFyXcrDjKKPoL6y23WhgAWgCu/D Q6Nad9PTAUTzX2NdmSOEYvIrjEixxvS2/XcExHa9p7t9NU5tynribPgq3BVanqcX bnjCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=3c7+Xg0+gtErgvV8floy4BeiD5bvry0s5jqri8ab0 do=; b=ytmJp8cAi/pUrE9WInRqqjgP9RKlv59TwzM8y7eL0iK5+BOHuNZsJl6TT pClzID2ir+M8cpeDV2/o6ThONApAGEv3+2oL75CsdMUyauocDrjuBE4ibDZNR764 T5ExNVRAYx1q8Q6+tXFZgDS/s5XrqPTgPeJLAStuzNhUxwkIXx0c4/e67rJTOcc5 5R9oiCZnUxVx8agB7uYoQzP40GF/ZpcUc03xNmXtIbkMNjKTRvhKX+AMLDe6RMLR rKB3BOgfh7ZST8bx3QQ2XIVNz8PO9tmMvGEa46Ozgh/jJQO9fciceOOlRYGl6FHW 2TjfUEv/auS6dCUGtoEPxoQf3IjBg== X-ME-Sender: X-ME-Proxy: Received: from dhcp-b893.meeting.ietf.org (dhcp-b893.meeting.ietf.org [31.133.184.147]) by mail.messagingengine.com (Postfix) with ESMTPA id 742A5E45E8; Thu, 8 Nov 2018 23:01:59 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Mark Nottingham In-Reply-To: Date: Fri, 9 Nov 2018 11:01:53 +0700 Cc: QUIC Chairs , "tcpm-chairs@ietf.org" , Jana Iyengar , Ian Swett , tcpm IETF list , QUIC IETF mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <15A4F4D1-3C15-462A-A560-BD803FC30CC8@mnot.net> References: To: Bob Briscoe X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 04:02:10 -0000 Thank you for the feedback, Bob; we really appreciate it. And of course = thanks to Jana for going the extra distance here. Cheers, > On 8 Nov 2018, at 6:14 pm, Bob Briscoe wrote: >=20 > I just wanted to thank Jana for explaining QUIC loss recovery to us = (and QUIC CC as far as it goes). > And thank you Jana, Ian, the chairs of both WGs (and anyone else = involved) for setting it up. >=20 > If one is not full-time on QUIC, it's very difficult to keep up with = all the changes. But now we have a checkpoint to start from, I feel I = will not be wasting people's time if I try to get involved - at least I = only might say something un-QUIC occasionally, rather than nearly = always. This has allowed people who understand how TCP cold be improved = to help with QUIC, when working on QUIC isn't their day job. >=20 > Again, Thank you. >=20 >=20 > Bob >=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Nov 8 21:42:18 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E571B130DCA; Thu, 8 Nov 2018 21:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lTUGre126l4; Thu, 8 Nov 2018 21:42:13 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4A11276D0; Thu, 8 Nov 2018 21:42:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IiQB2fJusUXYSSOwpHWtAY3idjm5U0Yhzy27+5SuSx4=; b=rmli56X1mobmlGW0/uM/cpNMl RlCo+gho6yL/KvlHuGkT3m5i9F9F7ZGE0REwGyN3mJ88fmy7tkWS+2rn0/S1MQRmhcE/cMf35frF2 O1Ey6Uv4THFwMxJkDpIrszYcJS8H1oO1Ut+j9KmELI3jkUt5tBqhh1/bUD8UjdTCupfMmFKeuaEcB Zr/8vjhbcvlz6EFYgAWTmKzfI0UMhERB9vxdmYZI7vjscrtZB46Jgs1jJZtwSTSYgu5Di9dAQq2kw hnQzYWwMFW1UE2vtGx9G1pIbzYJ4muyRVLrCV02js+7TnZsWjqLxp9uXhfIX+9pBS3Yn0csOtI4IZ OGg459dxA==; Received: from dhcp-bb61.meeting.ietf.org ([31.133.187.97]:39178) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gKzYX-0004sU-VY; Fri, 09 Nov 2018 05:42:10 +0000 To: "Scharf, Michael" , "tcpm@ietf.org" Cc: "tsvwg@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> Date: Fri, 9 Nov 2018 05:42:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------638676A780AB8BE147164C51" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 05:42:17 -0000 This is a multi-part message in MIME format. --------------638676A780AB8BE147164C51 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael, That is the point I thought you were making, and my point /is/ about that. If an application needs all the packets (i.e. a reliable protocol), it's not useful to reduce the latency of some packets but not all. That's where the in-order requirement comes from. However, if a stream-based transport is used (i.e. TCP) the /application/ still gets in-order delivery from TCP. It just doesn't have to require links to provide in order delivery as well. Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions). So, if the link loses a packet from flow A (the link isn't aware of microflows, I'm just saying the packet happens to be from flow A), link-layer in-order delivery will hold back all packets sent after that packet (from all flows, not just flow A) until the link repairs the gap or gives up. So hop-by-hop in-order delivery gives every flow the same delay as the worst delayed flow. Of course, someone building a network for DETNET would avoid link technologies like WiFi or LTE that frequently lose and retransmit packets. But wherever there is variable delay in a link, guaranteed in-order delivery per-hop means every flow is guaranteed to always get the worst delay from every link, which would have been experienced by only one flow without per-hop in-order delivery. And many of the applications of DETNET involve dumb industrial machinery that just expects everything to arrive in order and to a clocked schedule. But it's always as effective to deploy a resequencing buffer as the penultimate hop, screwed onto the receiving machine if necessary, rather than require per-hop resequencing in the network. ________________ So, why do Internet links often ensure in-order delivery even though TCP puts everything in order for the application? Short answer: the 3 DupACK rule (which is to do with loss-recovery, a different issue from the discussion above). Long answer: As flow rates have scaled up, the typical time between 3 packet arrivals has become so small that TCP's 3-DupACK rule makes links have to provide delivery with only a very small re-ordering degree - so small that it's easier for a link to just deliver everything in the order it received it; not because TCP doesn't put packets back in order, but just so as not to trigger TCP into generating spurious retransmissions. Bob On 08/11/2018 16:35, Scharf, Michael wrote: > > Inline [ms] > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Thursday, November 8, 2018 12:56 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > This is merely a symptom of a difference in opinion on where the > resequencing function should be located. > > * L4S takes the end-to-end approach saying that it is sufficient to > do resequencing in one place (the receiving host) if it is needed. > Then any resequencing delay only affects that flow. > * The DETNET approach is saying the resequencing must be done > hop-by-hop. This means there appears to be no resequencing needed > on the receiver (except if there's re-ordering on the final hop). > > * In order to guarantee no resequencing in the network (DETNET > approach), only the the worst case latency can be guaranteed, and > every packet has to have that same worst-case latency. > * When you leave resequencing to the receiver (end-to-end approach), > most of the packets arrive earlier than they would with DETNET, > but out of order ones might not. Then the application chooses > whether it wants to wait. > > [ms] My point is different: There seem to be other working groups in > the IETF that do talk about “low latency” as well but apparently they > also do need in-order delivery of packets, too. So the assumption that > e.g. a link layer technology can simply disable in-order delivery for > all “low latency” applications seems not correct. The reality may be a > bit more complex. > > The 3 DupACK rule in TCP led the Internet not to follow the end-to-end > principle on re-sequencing. Now we're removing the 3 DupACK rule, we > can take advantage of the e2e principle. > > [ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 is > standards track. So the bar for “removing” that rule for TCP is not low… > > [ms] Also, the end-to-end principle comes with tradeoffs. For > instance, relying on the end-to-end principle for recovery of bit > errors is not efficient. For in-order delivery there are tradeoffs as > well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may be no > free lunch. > > Of course, an application might choose to use TCP and L4S, rather than > UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the > receiving TCP stack. But at least there's no HoL blocking in the > network, and the app can choose between stream (TCP) or datagram (UDP). > > [ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail to > see the benefit (see draft-ietf-tcpm-rack-04). > > Michael > > > Bob > > On 06/11/2018 19:20, Scharf, Michael wrote: > > A comment on the TCPM presentation "L4S and RACK": > > As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery. > > So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful? > > Michael > > (who recently had to review draft-ietf-detnet-architecture) > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------638676A780AB8BE147164C51 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael,

That is the point I thought you were making, and my point /is/ about that.

If an application needs all the packets (i.e. a reliable protocol), it's not useful to reduce the latency of some packets but not all. That's where the in-order requirement comes from.

However, if a stream-based transport is used (i.e. TCP) the /application/ still gets in-order delivery from TCP. It just doesn't have to require links to provide in order delivery as well.

Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

So, if the link loses a packet from flow A (the link isn't aware of microflows, I'm just saying the packet happens to be from flow A), link-layer in-order delivery will hold back all packets sent after that packet (from all flows, not just flow A) until the link repairs the gap or gives up.

So hop-by-hop in-order delivery gives every flow the same delay as the worst delayed flow.

Of course, someone building a network for DETNET would avoid link technologies like WiFi or LTE that frequently lose and retransmit packets. But wherever there is variable delay in a link, guaranteed in-order delivery per-hop means every flow is guaranteed to always get the worst delay from every link, which would have been experienced by only one flow without per-hop in-order delivery.

And many of the applications of DETNET involve dumb industrial machinery that just expects everything to arrive in order and to a clocked schedule. But it's always as effective to deploy a resequencing buffer as the penultimate hop, screwed onto the receiving machine if necessary, rather than require per-hop resequencing in the network.

________________
So, why do Internet links often ensure in-order delivery even though TCP puts everything in order for the application?

Short answer: the 3 DupACK rule (which is to do with loss-recovery, a different issue from the discussion above).

Long answer: As flow rates have scaled up, the typical time between 3 packet arrivals has become so small that TCP's 3-DupACK rule makes links have to provide delivery with only a very small re-ordering degree - so small that it's easier for a link to just deliver everything in the order it received it; not because TCP doesn't put packets back in order, but just so as not to trigger TCP into generating spurious retransmissions.



Bob

On 08/11/2018 16:35, Scharf, Michael wrote:

Inline [ms]

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Thursday, November 8, 2018 12:56 PM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

This is merely a symptom of a difference in opinion on where the resequencing function should be located.

  • L4S takes the end-to-end approach saying that it is sufficient to do resequencing in one place (the receiving host) if it is needed. Then any resequencing delay only affects that flow.
  • The DETNET approach is saying the resequencing must be done hop-by-hop. This means there appears to be no resequencing needed on the receiver (except if there's re-ordering on the final hop).

 

  • In order to guarantee no resequencing in the network (DETNET approach), only the the worst case latency can be guaranteed, and every packet has to have that same worst-case latency.
  • When you leave resequencing to the receiver (end-to-end approach), most of the packets arrive earlier than they would with DETNET, but out of order ones might not. Then the application chooses whether it wants to wait.

[ms] My point is different: There seem to be other working groups in the IETF that do talk about “low latency” as well but apparently they also do need in-order delivery of packets, too. So the assumption that e.g. a link layer technology can simply disable in-order delivery for all “low latency” applications seems not correct. The reality may be a bit more complex.

The 3 DupACK rule in TCP led the Internet not to follow the end-to-end principle on re-sequencing. Now we're removing the 3 DupACK rule, we can take advantage of the e2e principle.

[ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 is standards track. So the bar for “removing” that rule for TCP is not low…

[ms] Also, the end-to-end principle comes with tradeoffs. For instance, relying on the end-to-end principle for recovery of bit errors is not efficient. For in-order delivery there are tradeoffs as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may be no free lunch.

Of course, an application might choose to use TCP and L4S, rather than UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the receiving TCP stack. But at least there's no HoL blocking in the network, and the app can choose between stream (TCP) or datagram (UDP).

[ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail to see the benefit (see draft-ietf-tcpm-rack-04).

Michael


Bob

On 06/11/2018 19:20, Scharf, Michael wrote:

A comment on the TCPM presentation "L4S and RACK":
 
As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery.
 
So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful?
 
Michael
(who recently had to review draft-ietf-detnet-architecture)
 
 



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------638676A780AB8BE147164C51-- From nobody Thu Nov 8 22:21:32 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8E7130DD8; Thu, 8 Nov 2018 22:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8blHcfWAX5us; Thu, 8 Nov 2018 22:21:26 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9D1130DD1; Thu, 8 Nov 2018 22:21:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 3BD4F25A17; Fri, 9 Nov 2018 07:21:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1541744484; bh=gpj0gyGW6IWi9jwwN3cYKRyoRI3KV9ARLOPZwrMK49s=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=vIXIgUYk909+Kaedhfv21wPz5ayIvC2WR6Z0nKJmGjQV+51WaKUMQrufZLRF4kQK6 VNZHGp8d1zIu8c2FP1GGuL0PFStEYxx5FoQ1/RjggjEXyhrCYS7bY3v1N3S/PSrqtW 1ByW7UhjxbvE1iVysFNJtwt6JlIuoYWXqg3tMunk= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-d-ZuHS3XQ6; Fri, 9 Nov 2018 07:21:24 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.hs-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 9 Nov 2018 07:21:24 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.25]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Fri, 9 Nov 2018 07:21:23 +0100 From: "Scharf, Michael" To: Bob Briscoe , "tcpm@ietf.org" CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Cross-area alignment on "L4S and RACK" Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFgBS9LuAAAnyRqAAG025AAACx04Q Date: Fri, 9 Nov 2018 06:21:23 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> In-Reply-To: <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D152905rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 06:21:30 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D152905rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb27igJl0IHNlZSB0aGUgZnVuZGFtZW50YWwgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgbGluayB0 ZWNobm9sb2d5IHRoYXQgZ3VhcmFudGVlcyBpbi1vcmRlciBkZWxpdmVyeSB3aXRoaW4gYSBmbG93 IChzYXkgYnkgZmxvdyBoYXNoaW5nLCBzZWUgRUNNUCkgdnMuIHNvbWUgbGluayBzY2hlbWUgdGhh dCBndWFyYW50ZWVzIGluLW9yZGVyIGRlbGl2ZXJ5LCBzYXksIG9ubHkgZm9yIHNvbWUgZnJhY3Rp b24gb2YgdGhlIHRyYWZmaWMgY2hhcmFjdGVyaXplZCBieSBzb21lIG90aGVyIG1lYW5zIChzYXks IG90aGVyIGhlYWRlciBiaXRzKS4NCg0KQ2xlYXJseSwgcmVvcmRlcmluZyBpcyBhIHByb2JsZW0g dGhhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgaW4gdGhlIElFVEYgYXMgYSB3aG9sZS4gQW5kIHdl IGNvdWxkIGRpc2N1c3Mgd2hldGhlciBhIHJldmlzaW9uIG9mIFJGQyAzMzY2IGlzIG5lZWRlZC4N Cg0KQnV0IEkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IHRoaXMgdG9waWMgaGFzIHRvIGJlIHRpZWQg aW50byBhbiBleHBlcmltZW50IHN1Y2ggYXMgTDRTLg0KDQpNaWNoYWVsDQoNCkZyb206IEJvYiBC cmlzY29lIFttYWlsdG86aW5AYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBGcmlkYXksIE5vdmVtYmVy IDksIDIwMTggNjo0MiBBTQ0KVG86IFNjaGFyZiwgTWljaGFlbDsgdGNwbUBpZXRmLm9yZw0KQ2M6 IHRzdndnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVu dCBvbiAiTDRTIGFuZCBSQUNLIg0KDQpNaWNoYWVsLA0KDQpUaGF0IGlzIHRoZSBwb2ludCBJIHRo b3VnaHQgeW91IHdlcmUgbWFraW5nLCBhbmQgbXkgcG9pbnQgL2lzLyBhYm91dCB0aGF0Lg0KDQpJ ZiBhbiBhcHBsaWNhdGlvbiBuZWVkcyBhbGwgdGhlIHBhY2tldHMgKGkuZS4gYSByZWxpYWJsZSBw cm90b2NvbCksIGl0J3Mgbm90IHVzZWZ1bCB0byByZWR1Y2UgdGhlIGxhdGVuY3kgb2Ygc29tZSBw YWNrZXRzIGJ1dCBub3QgYWxsLiBUaGF0J3Mgd2hlcmUgdGhlIGluLW9yZGVyIHJlcXVpcmVtZW50 IGNvbWVzIGZyb20uDQoNCkhvd2V2ZXIsIGlmIGEgc3RyZWFtLWJhc2VkIHRyYW5zcG9ydCBpcyB1 c2VkIChpLmUuIFRDUCkgdGhlIC9hcHBsaWNhdGlvbi8gc3RpbGwgZ2V0cyBpbi1vcmRlciBkZWxp dmVyeSBmcm9tIFRDUC4gSXQganVzdCBkb2Vzbid0IGhhdmUgdG8gcmVxdWlyZSBsaW5rcyB0byBw cm92aWRlIGluIG9yZGVyIGRlbGl2ZXJ5IGFzIHdlbGwuDQoNCk5vdGUgdGhhdCB0aGVyZSBjYW4g YmUgbXVsdGlwbGUgZmxvd3Mgb3ZlciBvbmUgbGluay4gU28gJ2luLW9yZGVyIGRlbGl2ZXJ5JyBm b3IgYSBsaW5rIGRvZXMgbm90IG1lYW4gaW4gb3JkZXIgb2YgVENQIHNlcXVlbmNlIG51bWJlci4g SXQgbWVhbnMgJ2RlbGl2ZXJlZCBpbiB0aGUgb3JkZXIgdGhhdCBwYWNrZXRzIGFycml2ZWQgYXQg dGhlIGxpbmsnICh0aGUgbGluayBpbmdyZXNzIGFkZHMgaXRzIG93biBzZXF1ZW5jZSBudW1iZXJz LCBhbmQgdGhlIGxpbmsgZWdyZXNzIGJ1ZmZlcnMgdGhlbSB1bnRpbCBpdCBjYW4gc2VuZCBvdXQg aW4gdGhlIHNhbWUgb3JkZXIsIG9yIHVudGlsIGEgdGltZS1vdXQgb3IgbWF4IG5vLiBvZiBsaW5r IHJldHJhbnNtaXNzaW9ucykuDQoNClNvLCBpZiB0aGUgbGluayBsb3NlcyBhIHBhY2tldCBmcm9t IGZsb3cgQSAodGhlIGxpbmsgaXNuJ3QgYXdhcmUgb2YgbWljcm9mbG93cywgSSdtIGp1c3Qgc2F5 aW5nIHRoZSBwYWNrZXQgaGFwcGVucyB0byBiZSBmcm9tIGZsb3cgQSksIGxpbmstbGF5ZXIgaW4t b3JkZXIgZGVsaXZlcnkgd2lsbCBob2xkIGJhY2sgYWxsIHBhY2tldHMgc2VudCBhZnRlciB0aGF0 IHBhY2tldCAoZnJvbSBhbGwgZmxvd3MsIG5vdCBqdXN0IGZsb3cgQSkgdW50aWwgdGhlIGxpbmsg cmVwYWlycyB0aGUgZ2FwIG9yIGdpdmVzIHVwLg0KDQpTbyBob3AtYnktaG9wIGluLW9yZGVyIGRl bGl2ZXJ5IGdpdmVzIGV2ZXJ5IGZsb3cgdGhlIHNhbWUgZGVsYXkgYXMgdGhlIHdvcnN0IGRlbGF5 ZWQgZmxvdy4NCg0KT2YgY291cnNlLCBzb21lb25lIGJ1aWxkaW5nIGEgbmV0d29yayBmb3IgREVU TkVUIHdvdWxkIGF2b2lkIGxpbmsgdGVjaG5vbG9naWVzIGxpa2UgV2lGaSBvciBMVEUgdGhhdCBm cmVxdWVudGx5IGxvc2UgYW5kIHJldHJhbnNtaXQgcGFja2V0cy4gQnV0IHdoZXJldmVyIHRoZXJl IGlzIHZhcmlhYmxlIGRlbGF5IGluIGEgbGluaywgZ3VhcmFudGVlZCBpbi1vcmRlciBkZWxpdmVy eSBwZXItaG9wIG1lYW5zIGV2ZXJ5IGZsb3cgaXMgZ3VhcmFudGVlZCB0byBhbHdheXMgZ2V0IHRo ZSB3b3JzdCBkZWxheSBmcm9tIGV2ZXJ5IGxpbmssIHdoaWNoIHdvdWxkIGhhdmUgYmVlbiBleHBl cmllbmNlZCBieSBvbmx5IG9uZSBmbG93IHdpdGhvdXQgcGVyLWhvcCBpbi1vcmRlciBkZWxpdmVy eS4NCg0KQW5kIG1hbnkgb2YgdGhlIGFwcGxpY2F0aW9ucyBvZiBERVRORVQgaW52b2x2ZSBkdW1i IGluZHVzdHJpYWwgbWFjaGluZXJ5IHRoYXQganVzdCBleHBlY3RzIGV2ZXJ5dGhpbmcgdG8gYXJy aXZlIGluIG9yZGVyIGFuZCB0byBhIGNsb2NrZWQgc2NoZWR1bGUuIEJ1dCBpdCdzIGFsd2F5cyBh cyBlZmZlY3RpdmUgdG8gZGVwbG95IGEgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBhcyB0aGUgcGVudWx0 aW1hdGUgaG9wLCBzY3Jld2VkIG9udG8gdGhlIHJlY2VpdmluZyBtYWNoaW5lIGlmIG5lY2Vzc2Fy eSwgcmF0aGVyIHRoYW4gcmVxdWlyZSBwZXItaG9wIHJlc2VxdWVuY2luZyBpbiB0aGUgbmV0d29y ay4NCg0KX19fX19fX19fX19fX19fXw0KU28sIHdoeSBkbyBJbnRlcm5ldCBsaW5rcyBvZnRlbiBl bnN1cmUgaW4tb3JkZXIgZGVsaXZlcnkgZXZlbiB0aG91Z2ggVENQIHB1dHMgZXZlcnl0aGluZyBp biBvcmRlciBmb3IgdGhlIGFwcGxpY2F0aW9uPw0KDQpTaG9ydCBhbnN3ZXI6IHRoZSAzIER1cEFD SyBydWxlICh3aGljaCBpcyB0byBkbyB3aXRoIGxvc3MtcmVjb3ZlcnksIGEgZGlmZmVyZW50IGlz c3VlIGZyb20gdGhlIGRpc2N1c3Npb24gYWJvdmUpLg0KDQpMb25nIGFuc3dlcjogQXMgZmxvdyBy YXRlcyBoYXZlIHNjYWxlZCB1cCwgdGhlIHR5cGljYWwgdGltZSBiZXR3ZWVuIDMgcGFja2V0IGFy cml2YWxzIGhhcyBiZWNvbWUgc28gc21hbGwgdGhhdCBUQ1AncyAzLUR1cEFDSyBydWxlIG1ha2Vz IGxpbmtzIGhhdmUgdG8gcHJvdmlkZSBkZWxpdmVyeSB3aXRoIG9ubHkgYSB2ZXJ5IHNtYWxsIHJl LW9yZGVyaW5nIGRlZ3JlZSAtIHNvIHNtYWxsIHRoYXQgaXQncyBlYXNpZXIgZm9yIGEgbGluayB0 byBqdXN0IGRlbGl2ZXIgZXZlcnl0aGluZyBpbiB0aGUgb3JkZXIgaXQgcmVjZWl2ZWQgaXQ7IG5v dCBiZWNhdXNlIFRDUCBkb2Vzbid0IHB1dCBwYWNrZXRzIGJhY2sgaW4gb3JkZXIsIGJ1dCBqdXN0 IHNvIGFzIG5vdCB0byB0cmlnZ2VyIFRDUCBpbnRvIGdlbmVyYXRpbmcgc3B1cmlvdXMgcmV0cmFu c21pc3Npb25zLg0KDQoNCg0KQm9iDQpPbiAwOC8xMS8yMDE4IDE2OjM1LCBTY2hhcmYsIE1pY2hh ZWwgd3JvdGU6DQpJbmxpbmUgW21zXQ0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmluQGJv YmJyaXNjb2UubmV0XQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDgsIDIwMTggMTI6NTYgUE0N ClRvOiBTY2hhcmYsIE1pY2hhZWw7IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+ DQpDYzogdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gIkw0UyBhbmQgUkFDSyINCg0KTWljaGFl bCwNCg0KVGhpcyBpcyBtZXJlbHkgYSBzeW1wdG9tIG9mIGEgZGlmZmVyZW5jZSBpbiBvcGluaW9u IG9uIHdoZXJlIHRoZSByZXNlcXVlbmNpbmcgZnVuY3Rpb24gc2hvdWxkIGJlIGxvY2F0ZWQuDQoN CiAgKiAgIEw0UyB0YWtlcyB0aGUgZW5kLXRvLWVuZCBhcHByb2FjaCBzYXlpbmcgdGhhdCBpdCBp cyBzdWZmaWNpZW50IHRvIGRvIHJlc2VxdWVuY2luZyBpbiBvbmUgcGxhY2UgKHRoZSByZWNlaXZp bmcgaG9zdCkgaWYgaXQgaXMgbmVlZGVkLiBUaGVuIGFueSByZXNlcXVlbmNpbmcgZGVsYXkgb25s eSBhZmZlY3RzIHRoYXQgZmxvdy4NCiAgKiAgIFRoZSBERVRORVQgYXBwcm9hY2ggaXMgc2F5aW5n IHRoZSByZXNlcXVlbmNpbmcgbXVzdCBiZSBkb25lIGhvcC1ieS1ob3AuIFRoaXMgbWVhbnMgdGhl cmUgYXBwZWFycyB0byBiZSBubyByZXNlcXVlbmNpbmcgbmVlZGVkIG9uIHRoZSByZWNlaXZlciAo ZXhjZXB0IGlmIHRoZXJlJ3MgcmUtb3JkZXJpbmcgb24gdGhlIGZpbmFsIGhvcCkuDQoNCg0KICAq ICAgSW4gb3JkZXIgdG8gZ3VhcmFudGVlIG5vIHJlc2VxdWVuY2luZyBpbiB0aGUgbmV0d29yayAo REVUTkVUIGFwcHJvYWNoKSwgb25seSB0aGUgdGhlIHdvcnN0IGNhc2UgbGF0ZW5jeSBjYW4gYmUg Z3VhcmFudGVlZCwgYW5kIGV2ZXJ5IHBhY2tldCBoYXMgdG8gaGF2ZSB0aGF0IHNhbWUgd29yc3Qt Y2FzZSBsYXRlbmN5Lg0KICAqICAgV2hlbiB5b3UgbGVhdmUgcmVzZXF1ZW5jaW5nIHRvIHRoZSBy ZWNlaXZlciAoZW5kLXRvLWVuZCBhcHByb2FjaCksIG1vc3Qgb2YgdGhlIHBhY2tldHMgYXJyaXZl IGVhcmxpZXIgdGhhbiB0aGV5IHdvdWxkIHdpdGggREVUTkVULCBidXQgb3V0IG9mIG9yZGVyIG9u ZXMgbWlnaHQgbm90LiBUaGVuIHRoZSBhcHBsaWNhdGlvbiBjaG9vc2VzIHdoZXRoZXIgaXQgd2Fu dHMgdG8gd2FpdC4NClttc10gTXkgcG9pbnQgaXMgZGlmZmVyZW50OiBUaGVyZSBzZWVtIHRvIGJl IG90aGVyIHdvcmtpbmcgZ3JvdXBzIGluIHRoZSBJRVRGIHRoYXQgZG8gdGFsayBhYm91dCDigJxs b3cgbGF0ZW5jeeKAnSBhcyB3ZWxsIGJ1dCBhcHBhcmVudGx5IHRoZXkgYWxzbyBkbyBuZWVkIGlu LW9yZGVyIGRlbGl2ZXJ5IG9mIHBhY2tldHMsIHRvby4gU28gdGhlIGFzc3VtcHRpb24gdGhhdCBl LmcuIGEgbGluayBsYXllciB0ZWNobm9sb2d5IGNhbiBzaW1wbHkgZGlzYWJsZSBpbi1vcmRlciBk ZWxpdmVyeSBmb3IgYWxsIOKAnGxvdyBsYXRlbmN54oCdIGFwcGxpY2F0aW9ucyBzZWVtcyBub3Qg Y29ycmVjdC4gVGhlIHJlYWxpdHkgbWF5IGJlIGEgYml0IG1vcmUgY29tcGxleC4NClRoZSAzIER1 cEFDSyBydWxlIGluIFRDUCBsZWQgdGhlIEludGVybmV0IG5vdCB0byBmb2xsb3cgdGhlIGVuZC10 by1lbmQgcHJpbmNpcGxlIG9uIHJlLXNlcXVlbmNpbmcuIE5vdyB3ZSdyZSByZW1vdmluZyB0aGUg MyBEdXBBQ0sgcnVsZSwgd2UgY2FuIHRha2UgYWR2YW50YWdlIG9mIHRoZSBlMmUgcHJpbmNpcGxl Lg0KW21zXSBGb3IgVENQLCB0aHJlZSBEdXBBQ0tTIGFyZSBhIFNIT1VMRCBpbiBSRkMgNTY4MSBh bmQgUkZDIDU2ODEgaXMgc3RhbmRhcmRzIHRyYWNrLiBTbyB0aGUgYmFyIGZvciDigJxyZW1vdmlu Z+KAnSB0aGF0IHJ1bGUgZm9yIFRDUCBpcyBub3QgbG934oCmDQpbbXNdIEFsc28sIHRoZSBlbmQt dG8tZW5kIHByaW5jaXBsZSBjb21lcyB3aXRoIHRyYWRlb2Zmcy4gRm9yIGluc3RhbmNlLCByZWx5 aW5nIG9uIHRoZSBlbmQtdG8tZW5kIHByaW5jaXBsZSBmb3IgcmVjb3Zlcnkgb2YgYml0IGVycm9y cyBpcyBub3QgZWZmaWNpZW50LiBGb3IgaW4tb3JkZXIgZGVsaXZlcnkgdGhlcmUgYXJlIHRyYWRl b2ZmcyBhcyB3ZWxsLCBzZWUgZS5nLiBTZWN0aW9uIDQgaW4gZHJhZnQtaWV0Zi10Y3BtLXJhY2st MDQuIFRoZXJlIG1heSBiZSBubyBmcmVlIGx1bmNoLg0KT2YgY291cnNlLCBhbiBhcHBsaWNhdGlv biBtaWdodCBjaG9vc2UgdG8gdXNlIFRDUCBhbmQgTDRTLCByYXRoZXIgdGhhbiBVRFAgYW5kIEw0 UyAoZS5nIFFVSUMpLiBUaGVuIHRoZXJlIGNvdWxkIHN0aWxsIGJlIEhvTCBibG9ja2luZyBpbiB0 aGUgcmVjZWl2aW5nIFRDUCBzdGFjay4gQnV0IGF0IGxlYXN0IHRoZXJlJ3Mgbm8gSG9MIGJsb2Nr aW5nIGluIHRoZSBuZXR3b3JrLCBhbmQgdGhlIGFwcCBjYW4gY2hvb3NlIGJldHdlZW4gc3RyZWFt IChUQ1ApIG9yIGRhdGFncmFtIChVRFApLg0KW21zXSBJZiBMUk8vR1JPIGluIHRoZSByZWNlaXZp bmcgVENQIHN0YWNrIGdldHMgbWVzc2VkIHVwLCBJIGZhaWwgdG8gc2VlIHRoZSBiZW5lZml0IChz ZWUgZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDQpLg0KTWljaGFlbA0KDQoNCkJvYg0KT24gMDYvMTEv MjAxOCAxOToyMCwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KDQpBIGNvbW1lbnQgb24gdGhlIFRD UE0gcHJlc2VudGF0aW9uICJMNFMgYW5kIFJBQ0siOg0KDQoNCg0KQXMgZmFyIGFzIEkgdW5kZXJz dGFuZCwgdGhlIERFVE5FVCBXRyBpbiBSVEcgYXJlYSBoYXMgcXVpdGUgc29tZSB1c2VzIGNhc2Vz IGZvciB1bHRyYS1sb3cgbGF0ZW5jeSB0cmFuc3BvcnQgLSBpbiBwYXJ0aWN1bGFyIGFsc28gd2l0 aCBib3VuZGVkIGppdHRlci4gQW5kIHNvbWUgb2YgdGhlc2UgYXBwbGljYXRpb25zIChlLmcuIHVz aW5nIFVEUCkgYXBwYXJlbnRseSBtYXkgbm90IGJlIGFibGUgdG8gdG9sZXJhdGUgKmFueSogb3V0 LW9mLW9yZGVyIHBhY2tldCBkZWxpdmVyeS4NCg0KDQoNClNvIHBlcmhhcHMgc29tZSBjcm9zcy1h cmVhIGFsaWdubWVudCBvbiB1bHRhLWxvdy1sYXRlbmN5IGFwcGxpY2F0aW9uIHJlcXVpcmVtZW50 cyB3b3VsZCBiZSB1c2VmdWw/DQoNCg0KDQpNaWNoYWVsDQoNCih3aG8gcmVjZW50bHkgaGFkIHRv IHJldmlldyBkcmFmdC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUpDQoNCg0KDQoNCg0KDQoNCg0K LS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlz Y29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8N Cg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D152905rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxWb3Jmb3JtYXRpZXJ0WmNo bg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IjsNCglm b250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkUtTWFpbEZvcm1hdHZv cmxhZ2UxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3Js YWdlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcw Ljg1cHQgMi4wY20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjMx Mjg3OTMxODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5NTkzODYwNTA7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoz NDUyMDk4MDM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMTY2NDUwOTQ7fQ0KQGxpc3QgbDE6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo1 MjE0MzEyNjU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDEzNDQ2NDA4O30NCkBsaXN0IGwy OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1s ZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC10YWIt c3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwy OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDgN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1s ZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjIxMjE4NzA3 Mzc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTkzMTUwMDEyO30NCkBsaXN0IGwzOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC10 YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDox MDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDM6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVs Nw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC10 YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdp bi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJE RSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgc2VlIHRoZSBmdW5kYW1lbnRhbCBkaWZm ZXJlbmNlIGJldHdlZW4gYSBsaW5rIHRlY2hub2xvZ3kgdGhhdCBndWFyYW50ZWVzIGluLW9yZGVy IGRlbGl2ZXJ5IHdpdGhpbiBhIGZsb3cgKHNheSBieSBmbG93IGhhc2hpbmcsIHNlZSBFQ01QKQ0K IHZzLiBzb21lIGxpbmsgc2NoZW1lIHRoYXQgZ3VhcmFudGVlcyBpbi1vcmRlciBkZWxpdmVyeSwg c2F5LCBvbmx5IGZvciBzb21lIGZyYWN0aW9uIG9mIHRoZSB0cmFmZmljIGNoYXJhY3Rlcml6ZWQg Ynkgc29tZSBvdGhlciBtZWFucyAoc2F5LCBvdGhlciBoZWFkZXIgYml0cykuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNsZWFybHksIHJlb3JkZXJpbmcgaXMgYSBwcm9ibGVt IHRoYXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBJRVRGIGFzIGEgd2hvbGUuIEFuZCB3 ZSBjb3VsZCBkaXNjdXNzIHdoZXRoZXIgYSByZXZpc2lvbiBvZiBSRkMgMzM2NiBpcyBuZWVkZWQu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IEkgYW0gbm90IGNvbnZp bmNlZCB0aGF0IHRoaXMgdG9waWMgaGFzIHRvIGJlIHRpZWQgaW50byBhbiBleHBlcmltZW50IHN1 Y2ggYXMgTDRTLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5NaWNoYWVsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgW21haWx0bzppbkBi b2JicmlzY29lLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDksIDIw MTggNjo0MiBBTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsOyB0Y3BtQGlldGYub3Jn PGJyPg0KPGI+Q2M6PC9iPiB0c3Z3Z0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAmcXVvdDtMNFMgYW5kIFJBQ0smcXVvdDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPk1pY2hhZWwsPGJyPg0KPGJyPg0KVGhhdCBpcyB0aGUgcG9pbnQg SSB0aG91Z2h0IHlvdSB3ZXJlIG1ha2luZywgYW5kIG15IHBvaW50IC9pcy8gYWJvdXQgdGhhdC48 YnI+DQo8YnI+DQpJZiBhbiBhcHBsaWNhdGlvbiBuZWVkcyBhbGwgdGhlIHBhY2tldHMgKGkuZS4g YSByZWxpYWJsZSBwcm90b2NvbCksIGl0J3Mgbm90IHVzZWZ1bCB0byByZWR1Y2UgdGhlIGxhdGVu Y3kgb2Ygc29tZSBwYWNrZXRzIGJ1dCBub3QgYWxsLiBUaGF0J3Mgd2hlcmUgdGhlIGluLW9yZGVy IHJlcXVpcmVtZW50IGNvbWVzIGZyb20uPGJyPg0KPGJyPg0KSG93ZXZlciwgaWYgYSBzdHJlYW0t YmFzZWQgdHJhbnNwb3J0IGlzIHVzZWQgKGkuZS4gVENQKSB0aGUgL2FwcGxpY2F0aW9uLyBzdGls bCBnZXRzIGluLW9yZGVyIGRlbGl2ZXJ5IGZyb20gVENQLiBJdCBqdXN0IGRvZXNuJ3QgaGF2ZSB0 byByZXF1aXJlIGxpbmtzIHRvIHByb3ZpZGUgaW4gb3JkZXIgZGVsaXZlcnkgYXMgd2VsbC48YnI+ DQo8YnI+DQpOb3RlIHRoYXQgdGhlcmUgY2FuIGJlIG11bHRpcGxlIGZsb3dzIG92ZXIgb25lIGxp bmsuIFNvICdpbi1vcmRlciBkZWxpdmVyeScgZm9yIGEgbGluayBkb2VzIG5vdCBtZWFuIGluIG9y ZGVyIG9mIFRDUCBzZXF1ZW5jZSBudW1iZXIuIEl0IG1lYW5zICdkZWxpdmVyZWQgaW4gdGhlIG9y ZGVyIHRoYXQgcGFja2V0cyBhcnJpdmVkIGF0IHRoZSBsaW5rJyAodGhlIGxpbmsgaW5ncmVzcyBh ZGRzIGl0cyBvd24gc2VxdWVuY2UgbnVtYmVycywgYW5kIHRoZQ0KIGxpbmsgZWdyZXNzIGJ1ZmZl cnMgdGhlbSB1bnRpbCBpdCBjYW4gc2VuZCBvdXQgaW4gdGhlIHNhbWUgb3JkZXIsIG9yIHVudGls IGEgdGltZS1vdXQgb3IgbWF4IG5vLiBvZiBsaW5rIHJldHJhbnNtaXNzaW9ucykuPGJyPg0KPGJy Pg0KU28sIGlmIHRoZSBsaW5rIGxvc2VzIGEgcGFja2V0IGZyb20gZmxvdyBBICh0aGUgbGluayBp c24ndCBhd2FyZSBvZiBtaWNyb2Zsb3dzLCBJJ20ganVzdCBzYXlpbmcgdGhlIHBhY2tldCBoYXBw ZW5zIHRvIGJlIGZyb20gZmxvdyBBKSwgbGluay1sYXllciBpbi1vcmRlciBkZWxpdmVyeSB3aWxs IGhvbGQgYmFjayBhbGwgcGFja2V0cyBzZW50IGFmdGVyIHRoYXQgcGFja2V0IChmcm9tIGFsbCBm bG93cywgbm90IGp1c3QgZmxvdyBBKSB1bnRpbCB0aGUNCiBsaW5rIHJlcGFpcnMgdGhlIGdhcCBv ciBnaXZlcyB1cC4gPGJyPg0KPGJyPg0KU28gaG9wLWJ5LWhvcCBpbi1vcmRlciBkZWxpdmVyeSBn aXZlcyBldmVyeSBmbG93IHRoZSBzYW1lIGRlbGF5IGFzIHRoZSB3b3JzdCBkZWxheWVkIGZsb3cu PGJyPg0KPGJyPg0KT2YgY291cnNlLCBzb21lb25lIGJ1aWxkaW5nIGEgbmV0d29yayBmb3IgREVU TkVUIHdvdWxkIGF2b2lkIGxpbmsgdGVjaG5vbG9naWVzIGxpa2UgV2lGaSBvciBMVEUgdGhhdCBm cmVxdWVudGx5IGxvc2UgYW5kIHJldHJhbnNtaXQgcGFja2V0cy4gQnV0IHdoZXJldmVyIHRoZXJl IGlzIHZhcmlhYmxlIGRlbGF5IGluIGEgbGluaywgZ3VhcmFudGVlZCBpbi1vcmRlciBkZWxpdmVy eSBwZXItaG9wIG1lYW5zIGV2ZXJ5IGZsb3cgaXMgZ3VhcmFudGVlZA0KIHRvIGFsd2F5cyBnZXQg dGhlIHdvcnN0IGRlbGF5IGZyb20gZXZlcnkgbGluaywgd2hpY2ggd291bGQgaGF2ZSBiZWVuIGV4 cGVyaWVuY2VkIGJ5IG9ubHkgb25lIGZsb3cgd2l0aG91dCBwZXItaG9wIGluLW9yZGVyIGRlbGl2 ZXJ5Lg0KPGJyPg0KPGJyPg0KQW5kIG1hbnkgb2YgdGhlIGFwcGxpY2F0aW9ucyBvZiBERVRORVQg aW52b2x2ZSBkdW1iIGluZHVzdHJpYWwgbWFjaGluZXJ5IHRoYXQganVzdCBleHBlY3RzIGV2ZXJ5 dGhpbmcgdG8gYXJyaXZlIGluIG9yZGVyIGFuZCB0byBhIGNsb2NrZWQgc2NoZWR1bGUuIEJ1dCBp dCdzIGFsd2F5cyBhcyBlZmZlY3RpdmUgdG8gZGVwbG95IGEgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBh cyB0aGUgcGVudWx0aW1hdGUgaG9wLCBzY3Jld2VkIG9udG8gdGhlIHJlY2VpdmluZw0KIG1hY2hp bmUgaWYgbmVjZXNzYXJ5LCByYXRoZXIgdGhhbiByZXF1aXJlIHBlci1ob3AgcmVzZXF1ZW5jaW5n IGluIHRoZSBuZXR3b3JrLjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX188YnI+DQpTbywgd2h5 IGRvIEludGVybmV0IGxpbmtzIG9mdGVuIGVuc3VyZSBpbi1vcmRlciBkZWxpdmVyeSBldmVuIHRo b3VnaCBUQ1AgcHV0cyBldmVyeXRoaW5nIGluIG9yZGVyIGZvciB0aGUgYXBwbGljYXRpb24/DQo8 YnI+DQo8YnI+DQpTaG9ydCBhbnN3ZXI6IHRoZSAzIER1cEFDSyBydWxlICh3aGljaCBpcyB0byBk byB3aXRoIGxvc3MtcmVjb3ZlcnksIGEgZGlmZmVyZW50IGlzc3VlIGZyb20gdGhlIGRpc2N1c3Np b24gYWJvdmUpLjxicj4NCjxicj4NCkxvbmcgYW5zd2VyOiBBcyBmbG93IHJhdGVzIGhhdmUgc2Nh bGVkIHVwLCB0aGUgdHlwaWNhbCB0aW1lIGJldHdlZW4gMyBwYWNrZXQgYXJyaXZhbHMgaGFzIGJl Y29tZSBzbyBzbWFsbCB0aGF0IFRDUCdzIDMtRHVwQUNLIHJ1bGUgbWFrZXMgbGlua3MgaGF2ZSB0 byBwcm92aWRlIGRlbGl2ZXJ5IHdpdGggb25seSBhIHZlcnkgc21hbGwgcmUtb3JkZXJpbmcgZGVn cmVlIC0gc28gc21hbGwgdGhhdCBpdCdzIGVhc2llciBmb3IgYSBsaW5rIHRvIGp1c3QNCiBkZWxp dmVyIGV2ZXJ5dGhpbmcgaW4gdGhlIG9yZGVyIGl0IHJlY2VpdmVkIGl0OyBub3QgYmVjYXVzZSBU Q1AgZG9lc24ndCBwdXQgcGFja2V0cyBiYWNrIGluIG9yZGVyLCBidXQganVzdCBzbyBhcyBub3Qg dG8gdHJpZ2dlciBUQ1AgaW50byBnZW5lcmF0aW5nIHNwdXJpb3VzIHJldHJhbnNtaXNzaW9ucy48 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpCb2I8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiAwOC8xMS8yMDE4IDE2OjM1LCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklubGluZSBbbXNdPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp bmRvd3RleHQiPiBCb2IgQnJpc2NvZSBbPGEgaHJlZj0ibWFpbHRvOmluQGJvYmJyaXNjb2UubmV0 Ij5tYWlsdG86aW5AYm9iYnJpc2NvZS5uZXQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBOb3ZlbWJlciA4LCAyMDE4IDEyOjU2IFBNPGJyPg0KPGI+VG86PC9iPiBTY2hhcmYsIE1p Y2hhZWw7IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGlldGYub3JnPC9hPjxi cj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRzdndnQGlldGYub3JnIj50c3Z3Z0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGln bm1lbnQgb24gJnF1b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NaWNo YWVsLDxicj4NCjxicj4NClRoaXMgaXMgbWVyZWx5IGEgc3ltcHRvbSBvZiBhIGRpZmZlcmVuY2Ug aW4gb3BpbmlvbiBvbiB3aGVyZSB0aGUgcmVzZXF1ZW5jaW5nIGZ1bmN0aW9uIHNob3VsZCBiZSBs b2NhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+DQpMNFMgdGFrZXMgdGhlIGVuZC10by1l bmQgYXBwcm9hY2ggc2F5aW5nIHRoYXQgaXQgaXMgc3VmZmljaWVudCB0byBkbyByZXNlcXVlbmNp bmcgaW4gb25lIHBsYWNlICh0aGUgcmVjZWl2aW5nIGhvc3QpIGlmIGl0IGlzIG5lZWRlZC4gVGhl biBhbnkgcmVzZXF1ZW5jaW5nIGRlbGF5IG9ubHkgYWZmZWN0cyB0aGF0IGZsb3cuPG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzMiPg0K VGhlIERFVE5FVCBhcHByb2FjaCBpcyBzYXlpbmcgdGhlIHJlc2VxdWVuY2luZyBtdXN0IGJlIGRv bmUgaG9wLWJ5LWhvcC4gVGhpcyBtZWFucyB0aGVyZSBhcHBlYXJzIHRvIGJlIG5vIHJlc2VxdWVu Y2luZyBuZWVkZWQgb24gdGhlIHJlY2VpdmVyIChleGNlcHQgaWYgdGhlcmUncyByZS1vcmRlcmlu ZyBvbiB0aGUgZmluYWwgaG9wKS4NCjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm82Ij4NCkluIG9yZGVyIHRvIGd1 YXJhbnRlZSBubyByZXNlcXVlbmNpbmcgaW4gdGhlIG5ldHdvcmsgKERFVE5FVCBhcHByb2FjaCks IG9ubHkgdGhlIHRoZSB3b3JzdCBjYXNlIGxhdGVuY3kgY2FuIGJlIGd1YXJhbnRlZWQsIGFuZCBl dmVyeSBwYWNrZXQgaGFzIHRvIGhhdmUgdGhhdCBzYW1lIHdvcnN0LWNhc2UgbGF0ZW5jeS48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZv NiI+DQpXaGVuIHlvdSBsZWF2ZSByZXNlcXVlbmNpbmcgdG8gdGhlIHJlY2VpdmVyIChlbmQtdG8t ZW5kIGFwcHJvYWNoKSwgbW9zdCBvZiB0aGUgcGFja2V0cyBhcnJpdmUgZWFybGllciB0aGFuIHRo ZXkgd291bGQgd2l0aCBERVRORVQsIGJ1dCBvdXQgb2Ygb3JkZXIgb25lcyBtaWdodCBub3QuIFRo ZW4gdGhlIGFwcGxpY2F0aW9uIGNob29zZXMgd2hldGhlciBpdCB3YW50cyB0byB3YWl0LjxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlttc10g TXkgcG9pbnQgaXMgZGlmZmVyZW50OiBUaGVyZSBzZWVtIHRvIGJlIG90aGVyIHdvcmtpbmcgZ3Jv dXBzIGluIHRoZSBJRVRGIHRoYXQgZG8gdGFsayBhYm91dCDigJxsb3cgbGF0ZW5jeeKAnSBhcyB3 ZWxsIGJ1dCBhcHBhcmVudGx5IHRoZXkgYWxzbyBkbyBuZWVkIGluLW9yZGVyIGRlbGl2ZXJ5DQog b2YgcGFja2V0cywgdG9vLiBTbyB0aGUgYXNzdW1wdGlvbiB0aGF0IGUuZy4gYSBsaW5rIGxheWVy IHRlY2hub2xvZ3kgY2FuIHNpbXBseSBkaXNhYmxlIGluLW9yZGVyIGRlbGl2ZXJ5IGZvciBhbGwg 4oCcbG93IGxhdGVuY3nigJ0gYXBwbGljYXRpb25zIHNlZW1zIG5vdCBjb3JyZWN0LiBUaGUgcmVh bGl0eSBtYXkgYmUgYSBiaXQgbW9yZSBjb21wbGV4Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRoZSAzIER1cEFDSyBydWxlIGluIFRDUCBsZWQgdGhlIEludGVybmV0IG5vdCB0 byBmb2xsb3cgdGhlIGVuZC10by1lbmQgcHJpbmNpcGxlIG9uIHJlLXNlcXVlbmNpbmcuDQo8L3Nw YW4+Tm93IHdlJ3JlIHJlbW92aW5nIHRoZSAzIER1cEFDSyBydWxlLCB3ZSBjYW4gdGFrZSBhZHZh bnRhZ2Ugb2YgdGhlIGUyZSBwcmluY2lwbGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W21zXSBGb3IgVENQLCB0aHJlZSBE dXBBQ0tTIGFyZSBhIFNIT1VMRCBpbiBSRkMgNTY4MSBhbmQgUkZDIDU2ODEgaXMgc3RhbmRhcmRz IHRyYWNrLiBTbyB0aGUgYmFyIGZvciDigJxyZW1vdmluZ+KAnSB0aGF0DQogcnVsZSBmb3IgVENQ IGlzIG5vdCBsb3figKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W21zXSBBbHNvLCB0aGUgZW5kLXRvLWVuZCBw cmluY2lwbGUgY29tZXMgd2l0aCB0cmFkZW9mZnMuIEZvciBpbnN0YW5jZSwgcmVseWluZyBvbiB0 aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUgZm9yIHJlY292ZXJ5DQogb2YgYml0IGVycm9ycyBpcyBu b3QgZWZmaWNpZW50LiBGb3IgaW4tb3JkZXIgZGVsaXZlcnkgdGhlcmUgYXJlIHRyYWRlb2ZmcyBh cyB3ZWxsLCBzZWUgZS5nLiBTZWN0aW9uIDQgaW4gZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDQuIFRo ZXJlIG1heSBiZSBubyBmcmVlIGx1bmNoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPk9mIGNvdXJzZSwgYW4gYXBwbGljYXRpb24gbWlnaHQgY2hvb3NlIHRvIHVzZSBUQ1AgYW5k IEw0UywgcmF0aGVyIHRoYW4gVURQIGFuZCBMNFMgKGUuZyBRVUlDKS4NCjwvc3Bhbj5UaGVuIHRo ZXJlIGNvdWxkIHN0aWxsIGJlIEhvTCBibG9ja2luZyBpbiB0aGUgcmVjZWl2aW5nIFRDUCBzdGFj ay4gQnV0IGF0IGxlYXN0IHRoZXJlJ3Mgbm8gSG9MIGJsb2NraW5nIGluIHRoZSBuZXR3b3JrLCBh bmQgdGhlIGFwcCBjYW4gY2hvb3NlIGJldHdlZW4gc3RyZWFtIChUQ1ApIG9yIGRhdGFncmFtIChV RFApLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlttc10gSWYgTFJPL0dSTyBpbiB0aGUgcmVjZWl2aW5nIFRDUCBzdGFjayBn ZXRzIG1lc3NlZCB1cCwgSSBmYWlsIHRvIHNlZSB0aGUgYmVuZWZpdCAoc2VlIGRyYWZ0LWlldGYt dGNwbS1yYWNrLTA0KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PGJyPg0KPGJyPg0KPGJyPg0KQm9iPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA2LzExLzIwMTggMTk6MjAsIFNjaGFyZiwgTWljaGFl bCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkEgY29tbWVudCBvbiB0aGUg VENQTSBwcmVzZW50YXRpb24gJnF1b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7OjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGZhciBhcyBJIHVuZGVy c3RhbmQsIHRoZSBERVRORVQgV0cgaW4gUlRHIGFyZWEgaGFzIHF1aXRlIHNvbWUgdXNlcyBjYXNl cyBmb3IgdWx0cmEtbG93IGxhdGVuY3kgdHJhbnNwb3J0IC0gaW4gcGFydGljdWxhciBhbHNvIHdp dGggYm91bmRlZCBqaXR0ZXIuIEFuZCBzb21lIG9mIHRoZXNlIGFwcGxpY2F0aW9ucyAoZS5nLiB1 c2luZyBVRFApIGFwcGFyZW50bHkgbWF5IG5vdCBiZSBhYmxlIHRvIHRvbGVyYXRlICphbnkqIG91 dC1vZi1vcmRlciBwYWNrZXQgZGVsaXZlcnkuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 PG86cD48L286cD48L3ByZT4NCjxwcmU+U28gcGVyaGFwcyBzb21lIGNyb3NzLWFyZWEgYWxpZ25t ZW50IG9uIHVsdGEtbG93LWxhdGVuY3kgYXBwbGljYXRpb24gcmVxdWlyZW1lbnRzIHdvdWxkIGJl IHVzZWZ1bD88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5NaWNoYWVsPG86cD48L286cD48L3ByZT4NCjxwcmU+KHdobyByZWNlbnRseSBoYWQgdG8g cmV2aWV3IGRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZSk8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRw Oi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJl Zj0iaHR0cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D152905rznt8114rzntrzd_-- From nobody Thu Nov 8 22:57:30 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F635130DF7; Thu, 8 Nov 2018 22:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vshYYGF4shvE; Thu, 8 Nov 2018 22:57:14 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027EC130DF5; Thu, 8 Nov 2018 22:57:14 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id y4so445527pgc.12; Thu, 08 Nov 2018 22:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PeF/kQ9lo00fzJnb162IGp80hqUcQDzH6v+n4IBTNm4=; b=es3TpsoAOI+V4XZXI7rT6jhXPq2V4DingmMfn2A39f7nHnEVEwFTggyHzJ8xgTbm8v D7z5LLdTc7Mn3YZ2S8ScaFuRWM2LYCsdTbqQMhZt0OieyhKx1R9YY9DiOyfRt50VXURy bqZSnk1vLeeB3BWeYu8DL601oYXSFyHUQvINVFx3YrlHBv56vCiM4CY9R2uVlLvLsdMD VjZtTvowZyupgiR/RGnnI/JrtlcEHUH3LTWXXVuM/AMbvXruf2jLsT2LRz18l/uFxZ0k EtaZGUd7Rg/kteWoxSdlw6WL1Wx5Q+QAxgGj7w6yacpzEQsG8uVt2FHxfn6GM/LNVt7S jiJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PeF/kQ9lo00fzJnb162IGp80hqUcQDzH6v+n4IBTNm4=; b=Eh0T6a+xtmgLbk8AhJP6XVEbr86pFDBRxLL3xTQyqFUJE13j29/NsFUqo/Ay82wOjM 4KHTR7QwpYCUv6EXW7NmMkmfDlVg30MUiut2m/9x2MjfHRHfDuahq2ZJIW6nNY6Py4nb seVAkvK+DRwlBQu9CICtjPSCszZTNNf6YbscG4qOR4XE8wZvcOUOUV7cMgFpFpjpbYKN HZlJClaroDfqUoP3finpK61AdW/U3e1gPTb6wj6yv4qEKQ+4LkHjPx3gpPYkUIWN7ypk cR1Li+iwLoqNrI97JyGjYE3eRmWRqBCVdU8b1BiZn/TXE5PsDPZKaF0T2cjqPGAAvkI8 x/Qw== X-Gm-Message-State: AGRZ1gLUIMEhzHvoxSryCBKWffE9s56qwFJbzlunwXi5f69M+YITewOA hkBykNruGr52AfkSA/Mak8eD5cP+F4Y= X-Google-Smtp-Source: AJdET5dzIo16QVSMBRzP61Z2NnaCV/InBOtvulsd7COtts2o4HwXo1hUBzuV02ShNEBEqSPXvHvQtA== X-Received: by 2002:a65:520a:: with SMTP id o10mr6716259pgp.276.1541746633531; Thu, 08 Nov 2018 22:57:13 -0800 (PST) Received: from [192.168.1.89] (static-222-229-224-101.adsl8.svips.gol.ne.jp. [222.229.224.101]) by smtp.gmail.com with ESMTPSA id f18-v6sm15966481pfh.0.2018.11.08.22.57.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 22:57:12 -0800 (PST) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_26158937-70C1-456F-950C-41B3C7F89914"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 9 Nov 2018 13:57:09 +0700 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> Cc: Bob Briscoe , "tcpm@ietf.org" , "tsvwg@ietf.org" To: "Scharf, Michael" References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 06:57:16 -0000 --Apple-Mail=_26158937-70C1-456F-950C-41B3C7F89914 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 9, 2018, at 1:21 PM, Scharf, Michael = wrote: >=20 > I don=E2=80=99t see the fundamental difference between a link = technology that guarantees in-order delivery within a flow (say by flow = hashing, see ECMP) vs. some link scheme that guarantees in-order = delivery, say, only for some fraction of the traffic characterized by = some other means (say, other header bits). A comment on ECMP via hashing; it doesn't guarantee in-order delivery. = It does support-if-not-quite-guarantee in-order delivery as long as = nothing changes. However, if relevant routing changes, sequence can be = affected until routing stabilizes. A lawyer told me once that "guarantee" is a word freighted with money... = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_26158937-70C1-456F-950C-41B3C7F89914 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlvlL8UACgkQEhdRnd2G P+DhzQ/9EZaL5jlPv/QSKqAuK3ZI4pqOS3sb42fOO7DEGI8kPyeyc0mY0RnBqgTU lWgl+J+4B682SHXGlfgvMwDORqiaH0PJw9zwghfxpPx/7akYVoB2x9cn8n0zuPJ4 +leV0KzCuXBXudXSvQlnzwPjwkmJ6QilDyd4oXw/8bF4t4RnjyFDls6lXlc7UO5Y mAzyRfiX8U4zjXwFbgdJuIPjXrFLG+Rs9L8A1kEYrn93qxNwiNF1CSy5b8Lt6efA +5kiSiEpWx96ccUuJqDV9eencJCEUigYgJdju91pk0OeM5Y4y2o1YRUUwLcBGQIW 0DDAhcML66bUl831tBzk3w2CGa2uyQAerQOqzQIN/Oli5oxhDfQdG+Bfe8s4amRK o9o+sz+vOZCmoKBTzOL/Yr/Kp7+4FpPAI60zgKuPICTMsfahumwaqonSes4dFeBQ liMgjWQ1k3Ijq/zylJvG9dXgYPyMto1spWYebZMjmYlWoF/mIoqTZV2ZLIUA8q/r 10JGi/jw5uVckNDxSm2kHB3glUL0kw+uCkXhc627xHNbrjRMT7+7eARZ30rVor0V NFoLSrMfkLyQVPUlhlyZot0LOFywUwPqGTVSr1F+y6ys7gq/YALQWg0XncGgGT+i RPttQPlv96xCKDaInaNL2qaWBXgOqkpHClRgNJ6rnXdG8i5W2fU= =0+hA -----END PGP SIGNATURE----- --Apple-Mail=_26158937-70C1-456F-950C-41B3C7F89914-- From nobody Fri Nov 9 02:08:49 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F018A12777C; Fri, 9 Nov 2018 02:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MI9QnEJ_Y8Qv; Fri, 9 Nov 2018 02:08:37 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A5C12007C; Fri, 9 Nov 2018 02:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=b9amIgq49JPEiP/GBOsu4T46ApgvNaIvGPl1rYhzHaQ=; b=itmkkf+uMxoq5+f36/f3ejP0b CJ5QYDz2EgnCEM25Rq7ZLkfFm42iBVKOSgpAKuMi/lId3/aDSZ6syuYf1j1ZgSd8hTxVb2x4OAba2 kdAFaYKG3Vd8wgeyL5HOEhArCNc2riHJsvIT8JvR++hy70whAgE8yztZAanFwgPkxPDohqUx+dQ43 SxbAMuXRtOrsJ6nJjeiKWOwqrNm7mQm146rVrUfFg4QMa2lEDhoVo+9hVnshc3aT++HSRHVD3afri 8VJ6SMNVl5v4Uqek1NPW6g3XpAakE9So+hgvFIRsWvnybygTOUtnihvOp6LTGcsC6kGZ2jN6svzDI lGNm951OA==; Received: from dhcp-995f.meeting.ietf.org ([31.133.153.95]:36236) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gL3iJ-0007zI-PW; Fri, 09 Nov 2018 10:08:33 +0000 To: "Scharf, Michael" , "tcpm@ietf.org" Cc: "tsvwg@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> Date: Fri, 9 Nov 2018 10:08:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------51A1A3204F8D85971AB682C1" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 10:08:41 -0000 This is a multi-part message in MIME format. --------------51A1A3204F8D85971AB682C1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael, On 09/11/2018 06:21, Scharf, Michael wrote: > > I don’t see the fundamental difference between a link technology that > guarantees in-order delivery within a flow (say by flow hashing, see > ECMP) vs. some link scheme that guarantees in-order delivery, say, > only for some fraction of the traffic characterized by some other > means (say, other header bits). > [The "other means" and "other bits" wording is pretty ambiguous here. I reckon I can guess what you mean but then I don't know why you're saying this, 'cos I don't think I've disagreed with you on this. So perhaps you could be more specific and we might be able to see why you've brought this up.] Also I wasn't really talking about all "link technology that guarantees in-order delivery within a flow". {Note 1} I was talking about link technology where all flows are blocked while waiting to get the aggregate back in order that it was in when it arrived. I specifically said: > Note that there can be multiple flows over one link. So 'in-order > delivery' for a link does not mean in order of TCP sequence number. It > means 'delivered in the order that packets arrived at the link' (the > link ingress adds its own sequence numbers, and the link egress > buffers them until it can send out in the same order, or until a > time-out or max no. of link retransmissions). For example: * A packet resequencing buffer after allowing for link-layer retransmissions is common for radio link technologies such as LTE (PDCP layer) and 802.11 WiFi. * A packet resequencing buffer after merging multiple bonded link channels is common for other access link technologies such as downstream DOCSIS bonded channels. > Clearly, reordering is a problem that needs to be discussed in the > IETF as a whole. And we could discuss whether a revision of RFC 3366 > is needed. > No. There is no proposal to alter general guidance for all links like RFC 3366. No-one is saying this. There is not even a proposal to require or even recommend that L4S-specific links do anything. The specific proposal is to require L4S /sources/ to use a RACK-like scheme, as a condition for setting the ECT(1) codepoint. See the last bullet in S.4.3 of draft-ietf-tsvwg-ecn-l4s-id-05 . This says nothing about what L4S links MUST, SHOULD or MAY do. It just gives an L4S link an opportunity not to have to do resequencing. > But I am not convinced that this topic has to be tied into an > experiment such as L4S. > It is an opportunity that currently only applies to L4S. L4S is merely an example of a case where we can mandate that there will be no non-RACK traffic in a link, which creates an opportunity for those who are implementing the L4S DualQ Coupled AQM to ignore the RFC3366 resequencing advice for the L4S queue (but we are not changing the advice, because L4S is only an experiment). The prize is to remove the head-of-line blocking problem for their users. This is not L4S-specific, altho there are no other examples at the moment where this opportunity is possible (so in that sense it is /currently/ L4S-specific). The message has to be handled really carefully, because the opportunities for misunderstanding are enormous (as evidenced by this thread, and we haven't even started talking to non-transport people yet). So Gorry and David B want me to draft a short I-D that they will word-smith and author as tsvwg chairs to make the situation clear. I have said I don't want this discussion to be officially raised outside the transport area until we are sure that a variant of RACK is even feasible without any packet counting at all (i.e. without the initial 3-DupACK rule in current RACK). So I'll prioritize working that out for the next week or so, rather than drafting anything. Bob {Note 1}: I hadn't considered that this would affect technologies like ECMP that maintain order without a resequencing buffer and without introducing HoL blocking. But actually, the consequence there would be that L4S traffic could be sprayed by ECMP without per-flow hashing. > Michael > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 6:42 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > That is the point I thought you were making, and my point /is/ about that. > > If an application needs all the packets (i.e. a reliable protocol), > it's not useful to reduce the latency of some packets but not all. > That's where the in-order requirement comes from. > > However, if a stream-based transport is used (i.e. TCP) the > /application/ still gets in-order delivery from TCP. It just doesn't > have to require links to provide in order delivery as well. > > Note that there can be multiple flows over one link. So 'in-order > delivery' for a link does not mean in order of TCP sequence number. It > means 'delivered in the order that packets arrived at the link' (the > link ingress adds its own sequence numbers, and the link egress > buffers them until it can send out in the same order, or until a > time-out or max no. of link retransmissions). > > So, if the link loses a packet from flow A (the link isn't aware of > microflows, I'm just saying the packet happens to be from flow A), > link-layer in-order delivery will hold back all packets sent after > that packet (from all flows, not just flow A) until the link repairs > the gap or gives up. > > So hop-by-hop in-order delivery gives every flow the same delay as the > worst delayed flow. > > Of course, someone building a network for DETNET would avoid link > technologies like WiFi or LTE that frequently lose and retransmit > packets. But wherever there is variable delay in a link, guaranteed > in-order delivery per-hop means every flow is guaranteed to always get > the worst delay from every link, which would have been experienced by > only one flow without per-hop in-order delivery. > > And many of the applications of DETNET involve dumb industrial > machinery that just expects everything to arrive in order and to a > clocked schedule. But it's always as effective to deploy a > resequencing buffer as the penultimate hop, screwed onto the receiving > machine if necessary, rather than require per-hop resequencing in the > network. > > ________________ > So, why do Internet links often ensure in-order delivery even though > TCP puts everything in order for the application? > > Short answer: the 3 DupACK rule (which is to do with loss-recovery, a > different issue from the discussion above). > > Long answer: As flow rates have scaled up, the typical time between 3 > packet arrivals has become so small that TCP's 3-DupACK rule makes > links have to provide delivery with only a very small re-ordering > degree - so small that it's easier for a link to just deliver > everything in the order it received it; not because TCP doesn't put > packets back in order, but just so as not to trigger TCP into > generating spurious retransmissions. > > > > Bob > > On 08/11/2018 16:35, Scharf, Michael wrote: > > Inline [ms] > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Thursday, November 8, 2018 12:56 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > This is merely a symptom of a difference in opinion on where the > resequencing function should be located. > > * L4S takes the end-to-end approach saying that it is sufficient > to do resequencing in one place (the receiving host) if it is > needed. Then any resequencing delay only affects that flow. > * The DETNET approach is saying the resequencing must be done > hop-by-hop. This means there appears to be no resequencing > needed on the receiver (except if there's re-ordering on the > final hop). > > * In order to guarantee no resequencing in the network (DETNET > approach), only the the worst case latency can be guaranteed, > and every packet has to have that same worst-case latency. > * When you leave resequencing to the receiver (end-to-end > approach), most of the packets arrive earlier than they would > with DETNET, but out of order ones might not. Then the > application chooses whether it wants to wait. > > [ms] My point is different: There seem to be other working groups > in the IETF that do talk about “low latency” as well but > apparently they also do need in-order delivery of packets, too. So > the assumption that e.g. a link layer technology can simply > disable in-order delivery for all “low latency” applications seems > not correct. The reality may be a bit more complex. > > The 3 DupACK rule in TCP led the Internet not to follow the > end-to-end principle on re-sequencing. Now we're removing the 3 > DupACK rule, we can take advantage of the e2e principle. > > [ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 > is standards track. So the bar for “removing” that rule for TCP is > not low… > > [ms] Also, the end-to-end principle comes with tradeoffs. For > instance, relying on the end-to-end principle for recovery of bit > errors is not efficient. For in-order delivery there are tradeoffs > as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may > be no free lunch. > > Of course, an application might choose to use TCP and L4S, rather > than UDP and L4S (e.g QUIC). Then there could still be HoL > blocking in the receiving TCP stack. But at least there's no HoL > blocking in the network, and the app can choose between stream > (TCP) or datagram (UDP). > > [ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail > to see the benefit (see draft-ietf-tcpm-rack-04). > > Michael > > > Bob > > On 06/11/2018 19:20, Scharf, Michael wrote: > > A comment on the TCPM presentation "L4S and RACK": > > > > As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery. > > > > So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful? > > > > Michael > > (who recently had to review draft-ietf-detnet-architecture) > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------51A1A3204F8D85971AB682C1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael,

On 09/11/2018 06:21, Scharf, Michael wrote:

I don’t see the fundamental difference between a link technology that guarantees in-order delivery within a flow (say by flow hashing, see ECMP) vs. some link scheme that guarantees in-order delivery, say, only for some fraction of the traffic characterized by some other means (say, other header bits).

[The "other means" and "other bits" wording is pretty ambiguous here. I reckon I can guess what you mean but then I don't know why you're saying this, 'cos I don't think I've disagreed with you on this. So perhaps you could be more specific and we might be able to see why you've brought this up.]

Also I wasn't really talking about all "link technology that guarantees in-order delivery within a flow". {Note 1} I was talking about link technology where all flows are blocked while waiting to get the aggregate back in order that it was in when it arrived. I specifically said:
Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).
For example:
  • A packet resequencing buffer after allowing for link-layer retransmissions is common for radio link technologies such as LTE (PDCP layer) and 802.11 WiFi.
  • A packet resequencing buffer after merging multiple bonded link channels is common for other access link technologies such as downstream DOCSIS bonded channels.

 

Clearly, reordering is a problem that needs to be discussed in the IETF as a whole. And we could discuss whether a revision of RFC 3366 is needed.

No. There is no proposal to alter general guidance for all links like RFC 3366. No-one is saying this.

There is not even a proposal to require or even recommend that L4S-specific links do anything.

The specific proposal is to require L4S sources to use a RACK-like scheme, as a condition for setting the ECT(1) codepoint. See the last bullet in S.4.3 of draft-ietf-tsvwg-ecn-l4s-id-05.

This says nothing about what L4S links MUST, SHOULD or MAY do. It just gives an L4S link an opportunity not to have to do resequencing.

 

But I am not convinced that this topic has to be tied into an experiment such as L4S.

It is an opportunity that currently only applies to L4S.

L4S is merely an example of a case where we can mandate that there will be no non-RACK traffic in a link, which creates an opportunity for those who are implementing the L4S DualQ Coupled AQM to ignore the RFC3366 resequencing advice for the L4S queue (but we are not changing the advice, because L4S is only an experiment). The prize is to remove the head-of-line blocking problem for their users.

This is not L4S-specific, altho there are no other examples at the moment where this opportunity is possible (so in that sense it is currently L4S-specific).


The message has to be handled really carefully, because the opportunities for misunderstanding are enormous (as evidenced by this thread, and we haven't even started talking to non-transport people yet).

So Gorry and David B want me to draft a short I-D that they will word-smith and author as tsvwg chairs to make the situation clear.

I have said I don't want this discussion to be officially raised outside the transport area until we are sure that a variant of RACK is even feasible without any packet counting at all (i.e. without the initial 3-DupACK rule in current RACK). So I'll prioritize working that out for the next week or so, rather than drafting anything.



Bob

{Note 1}: I hadn't considered that this would affect technologies like ECMP that maintain order without a resequencing buffer and without introducing HoL blocking. But actually, the consequence there would be that L4S traffic could be sprayed by ECMP without per-flow hashing.

 

Michael

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Friday, November 9, 2018 6:42 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

That is the point I thought you were making, and my point /is/ about that.

If an application needs all the packets (i.e. a reliable protocol), it's not useful to reduce the latency of some packets but not all. That's where the in-order requirement comes from.

However, if a stream-based transport is used (i.e. TCP) the /application/ still gets in-order delivery from TCP. It just doesn't have to require links to provide in order delivery as well.

Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

So, if the link loses a packet from flow A (the link isn't aware of microflows, I'm just saying the packet happens to be from flow A), link-layer in-order delivery will hold back all packets sent after that packet (from all flows, not just flow A) until the link repairs the gap or gives up.

So hop-by-hop in-order delivery gives every flow the same delay as the worst delayed flow.

Of course, someone building a network for DETNET would avoid link technologies like WiFi or LTE that frequently lose and retransmit packets. But wherever there is variable delay in a link, guaranteed in-order delivery per-hop means every flow is guaranteed to always get the worst delay from every link, which would have been experienced by only one flow without per-hop in-order delivery.

And many of the applications of DETNET involve dumb industrial machinery that just expects everything to arrive in order and to a clocked schedule. But it's always as effective to deploy a resequencing buffer as the penultimate hop, screwed onto the receiving machine if necessary, rather than require per-hop resequencing in the network.

________________
So, why do Internet links often ensure in-order delivery even though TCP puts everything in order for the application?

Short answer: the 3 DupACK rule (which is to do with loss-recovery, a different issue from the discussion above).

Long answer: As flow rates have scaled up, the typical time between 3 packet arrivals has become so small that TCP's 3-DupACK rule makes links have to provide delivery with only a very small re-ordering degree - so small that it's easier for a link to just deliver everything in the order it received it; not because TCP doesn't put packets back in order, but just so as not to trigger TCP into generating spurious retransmissions.



Bob

On 08/11/2018 16:35, Scharf, Michael wrote:

Inline [ms]

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Thursday, November 8, 2018 12:56 PM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

This is merely a symptom of a difference in opinion on where the resequencing function should be located.

  • L4S takes the end-to-end approach saying that it is sufficient to do resequencing in one place (the receiving host) if it is needed. Then any resequencing delay only affects that flow.
  • The DETNET approach is saying the resequencing must be done hop-by-hop. This means there appears to be no resequencing needed on the receiver (except if there's re-ordering on the final hop).

 

  • In order to guarantee no resequencing in the network (DETNET approach), only the the worst case latency can be guaranteed, and every packet has to have that same worst-case latency.
  • When you leave resequencing to the receiver (end-to-end approach), most of the packets arrive earlier than they would with DETNET, but out of order ones might not. Then the application chooses whether it wants to wait.

[ms] My point is different: There seem to be other working groups in the IETF that do talk about “low latency” as well but apparently they also do need in-order delivery of packets, too. So the assumption that e.g. a link layer technology can simply disable in-order delivery for all “low latency” applications seems not correct. The reality may be a bit more complex.

The 3 DupACK rule in TCP led the Internet not to follow the end-to-end principle on re-sequencing. Now we're removing the 3 DupACK rule, we can take advantage of the e2e principle.

[ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 is standards track. So the bar for “removing” that rule for TCP is not low…

[ms] Also, the end-to-end principle comes with tradeoffs. For instance, relying on the end-to-end principle for recovery of bit errors is not efficient. For in-order delivery there are tradeoffs as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may be no free lunch.

Of course, an application might choose to use TCP and L4S, rather than UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the receiving TCP stack. But at least there's no HoL blocking in the network, and the app can choose between stream (TCP) or datagram (UDP).

[ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail to see the benefit (see draft-ietf-tcpm-rack-04).

Michael


Bob

On 06/11/2018 19:20, Scharf, Michael wrote:

A comment on the TCPM presentation "L4S and RACK":
 
As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery.
 
So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful?
 
Michael
(who recently had to review draft-ietf-detnet-architecture)
 
 




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------51A1A3204F8D85971AB682C1-- From nobody Fri Nov 9 04:45:11 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B37C0130DE2 for ; Fri, 9 Nov 2018 04:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXcknA8L7wTC for ; Fri, 9 Nov 2018 04:45:06 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15695130DD8 for ; Fri, 9 Nov 2018 04:45:05 -0800 (PST) Received: from mail-it1-f169.google.com (mail-it1-f169.google.com [209.85.166.169]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D0B4E2786BA for ; Fri, 9 Nov 2018 21:45:03 +0900 (JST) Received: by mail-it1-f169.google.com with SMTP id p11-v6so4364809itf.0 for ; Fri, 09 Nov 2018 04:45:03 -0800 (PST) X-Gm-Message-State: AGRZ1gJbxJBIlYC/CDqUiqn8tM2K2T+pccGW/FKYLbwzla6KWApWxf+7 hZsNkJC0k8UWQVX/OtVcz0E5++Th7Ej/6SzUyPg= X-Google-Smtp-Source: AJdET5c+F/ERrG2sHcmM84PCPA5r7O39bj3B3RgniCwXUgR9O62POWNL1rcH79JkR5aemK+viw93/NehUz4XVw/NxC4= X-Received: by 2002:a24:6541:: with SMTP id u62-v6mr2239665itb.25.1541767502224; Fri, 09 Nov 2018 04:45:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yoshifumi Nishida Date: Fri, 9 Nov 2018 04:44:50 -0800 X-Gmail-Original-Message-ID: Message-ID: To: ycheng=40google.com@dmarc.ietf.org Cc: Bob Briscoe , ianswett@google.com, "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004becca057a3ab8c2" Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 12:45:09 -0000 --0000000000004becca057a3ab8c2 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 8, 2018 at 4:37 PM Yuchung Cheng wrote: > On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe wrote: > > > > I just wanted to thank Jana for explaining QUIC loss recovery to us (and > QUIC CC as far as it goes). > > And thank you Jana, Ian, the chairs of both WGs (and anyone else > involved) for setting it up. > > > > If one is not full-time on QUIC, it's very difficult to keep up with all > the changes. But now we have a checkpoint to start from, I feel I will not > be wasting people's time if I try to get involved - at least I only might > say something un-QUIC occasionally, rather than nearly always. This has > allowed people who understand how TCP cold be improved to help with QUIC, > when working on QUIC isn't their day job. > > > > Again, Thank you. > I like particularly that QUIC only reduces cwnd to 1 after the loss is > confirmed not upon RTO fires. It should be very feasible for TCP (at > least Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd > reductions! > +1 > > Also IMHO TCP w/ quality timestamps are almost as good as QUIC > pkt-ids. Google internally uses usec. We wish we could upstream it but > RFC needs to be updated. > I agree using timestamp for the purpose. But, if we try to utilize the TS like pkt-id, I personally think it'll be similar to use it as extend seqno like draft-bagnulo-tcpm-esn-00 rather than fine grade TS. :) In any cases, it seems to me that many people think 7232 TS is not being very efficient for today's internet. it might be good time to think about extending TS option just like what we're doing on ECN.. TS++? -- Yoshi --0000000000004becca057a3ab8c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Nov 8, 2018 at 4:37 PM Yuchung Cheng <ycheng=3D40google.com@dmar= c.ietf.org> wrote:
On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:=
>
> I just wanted to thank Jana for explaining QUIC loss recovery to us (a= nd QUIC CC as far as it goes).
> And thank you Jana, Ian, the chairs of both WGs (and anyone else invol= ved) for setting it up.
>
> If one is not full-time on QUIC, it's very difficult to keep up wi= th all the changes. But now we have a checkpoint to start from, I feel I wi= ll not be wasting people's time if I try to get involved - at least I o= nly might say something un-QUIC occasionally, rather than nearly always. Th= is has allowed people who understand how TCP cold be improved to help with = QUIC, when working on QUIC isn't their day job.
>
> Again, Thank you.
I like particularly that QUIC only reduces cwnd to 1 after the loss is
confirmed not upon RTO fires. It should be very feasible for TCP (at
least Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd
reductions!

+1=C2=A0=C2=A0

Also IMHO TCP w/ quality timestamps are almost as good as QUIC
pkt-ids. Google internally uses usec. We wish we could upstream it but
RFC needs to be updated.

I agree using = timestamp for the purpose.=C2=A0
But, if we try to utilize the TS= like pkt-id, I personally think it'll be similar to use it as extend s= eqno like draft-bagnulo-tcpm-esn-00 rather than fine grade TS. :)

In any cases, it seems to me that many people think 7232 TS= is not being very efficient for today's internet.
it might b= e good time to think about extending TS option just like what we're doi= ng on ECN..=C2=A0 TS++?
--
Yoshi


--0000000000004becca057a3ab8c2-- From nobody Fri Nov 9 09:44:20 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDFF130DC0; Fri, 9 Nov 2018 09:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy0hPvVP1FV6; Fri, 9 Nov 2018 09:44:08 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EA8412D4EE; Fri, 9 Nov 2018 09:44:07 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 0453125A20; Fri, 9 Nov 2018 18:44:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1541785445; bh=VSBgFaJFU/9s56XqJm+mu4GKMk8GHHoELcOEhbqgOVc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=pODfFzYQjLHLs4HRakXVL3ppScEydzuzMXrg99Lg5wsXcLy/KIf8O/ic6WjAm7HXa SUfrl0MqxWVm09ag+FGWmh4yvXyJ7qQKr3oUZsBld327Z32k71Pu5kNTB46mZSoJeV S9SA2dLV5ImdmtEeygbbJuAta5t2K8i1ta6jo23g= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7bD0pwY9VGM; Fri, 9 Nov 2018 18:44:04 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.hs-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 9 Nov 2018 18:44:04 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.25]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Fri, 9 Nov 2018 18:44:04 +0100 From: "Scharf, Michael" To: Bob Briscoe , "tcpm@ietf.org" CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Cross-area alignment on "L4S and RACK" Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFgBS9LuAAAnyRqAAG025AAACx04QAAaGWYAAD7CAQA== Date: Fri, 9 Nov 2018 17:44:04 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> In-Reply-To: <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D1536B3rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 17:44:13 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D1536B3rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWxsIG5vdCBjb21tZW50IG9uIGxpbmsgdGVjaG5vbG9neSBpbXBsZW1lbnRhdGlvbiwgc2No ZWR1bGVyIGFuZCBxdWV1ZSBkZXNpZ24gYXNzdW1wdGlvbnMgaW4gQXBwZW5kaXggQS4xLjcgb2Yg ZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA1LiBQZW9wbGUgZS5nLiBpbiBSVEcgYXJlYSBt YXkgYmUgbW9yZSBmYW1pbGlhciB3aXRoIHRoZSBpbXBsaWNhdGlvbnMgb2YgaW50ZXJuYWwgZGVz aWducyBlLmcuIGluc2lkZSBhIHJvdXRlci4gSU1ITyB0aGUgYmVzdCB3YXkgdG8gZ2V0IHJvdXRp bmcgZXhwZXJ0cyBpbnRvIHRoZSBsb29wIGJlZm9yZSBmdXJ0aGVyIGRpc2N1c3Npbmcgd2hhdCBp cyBjdXJyZW50bHkgbGlzdGVkIGluIEFwcGVuZGl4IEEuMS43Lg0KDQpUaHVzLCBJIGxpbWl0IG15 IHJlc3BvbnNlIHRvIHRoZSBhY3R1YWwgd29yZGluZyBpbiB0aGUgbWFpbiBwYXJ0IG9mIGRyYWZ0 LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNToNCg0KICAgIG8gIEEgc2NhbGFibGUgY29uZ2VzdGlv biBjb250cm9sIE1VU1QgZGV0ZWN0IGxvc3MgYnkgY291bnRpbmcgaW4NCiAgICAgIHVuaXRzIG9m IHRpbWUsIHdoaWNoIGlzIHNjYWxhYmxlLCBhbmQgTVVTVCBOT1QgY291bnQgaW4gdW5pdHMgb2YN CiAgICAgIHBhY2tldHMgKGFzIGluIHRoZSAzIER1cEFDSyBydWxlIG9mIHRyYWRpdGlvbmFsIFRD UCksIHdoaWNoIGlzIG5vdA0KICAgICAgc2NhbGFibGUgKHNlZSBBcHBlbmRpeCBBLjEuNzxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA1I2Fw cGVuZGl4LUEuMS43PiBmb3IgcmF0aW9uYWxlKS4NCg0KQXMgaW5kaXZpZHVhbCBjb250cmlidXRv ciwgSSBkaXNhZ3JlZSB3aXRoIHRoaXMgcmVxdWlyZW1lbnQuIEkgd291bGQgcHJvYmFibHkgYmUg T0sgd2l0aCBhIHdvcmRpbmcgdGhhdCBhIFRDUCBzZW5kZXIgbXVzdCBiZSBhYmxlIHRvIHRvbGVy YXRlIHJlb3JkZXJpbmcgYmV5b25kIDMgRHVwbGljYXRlIEFDS3MuIEkgYmVsaWV2ZSBpdCBkb2Vz IG5vdCBtYXR0ZXIgaG93IGEgc2VuZGVyIHJlYWxpemVzIHRoaXMgaW50ZXJuYWxseS4NCg0KQW5k IGlmIHRoYXQgcmVxdWlyZW1lbnQgaXMgbm90IGp1c3QgcmVtb3ZlZCwgSSBiZWxpZXZlIHRoZSB3 b3JkaW5nIOKAnHRyYWRpdGlvbmFsIFRDUOKAnSBoYXMgdG8gYmUgcmVwbGFjZWQgYnkg4oCcc3Rh bmRhcmQgVENQ4oCdLg0KDQpCVFcsIGFsc28sIGluIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCB0 aGVyZSBoYXMgdG8gYmUgYSBjbGVhciBkaXN0aW5jdGlvbiBiZXR3ZWVuIGV4cGVyaW1lbnRzIGFu ZCBzdGFuZGFyZHMuIEhpc3RvcnkgdGVsbHMgdXMgdGhhdCBzb21lIGV4cGVyaW1lbnRzIGNhbiBl dm9sdmUgaW50byBzdGFuZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbnMsIHdoaWxlIG90aGVyIGV4 cGVyaW1lbnRzIG1heSBmYWlsLiBBbmQgdGhlcmUgaXMgbm8gd2F5IG9mIGtub3dpbmcgdGhhdCBp biBhZHZhbmNlLg0KDQpNaWNoYWVsDQoNCkZyb206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBi b2JicmlzY29lLm5ldF0NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgOSwgMjAxOCAxMTowOCBBTQ0K VG86IFNjaGFyZiwgTWljaGFlbDsgdGNwbUBpZXRmLm9yZw0KQ2M6IHRzdndnQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAiTDRTIGFuZCBSQUNL Ig0KDQpNaWNoYWVsLA0KT24gMDkvMTEvMjAxOCAwNjoyMSwgU2NoYXJmLCBNaWNoYWVsIHdyb3Rl Og0KSSBkb27igJl0IHNlZSB0aGUgZnVuZGFtZW50YWwgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgbGlu ayB0ZWNobm9sb2d5IHRoYXQgZ3VhcmFudGVlcyBpbi1vcmRlciBkZWxpdmVyeSB3aXRoaW4gYSBm bG93IChzYXkgYnkgZmxvdyBoYXNoaW5nLCBzZWUgRUNNUCkgdnMuIHNvbWUgbGluayBzY2hlbWUg dGhhdCBndWFyYW50ZWVzIGluLW9yZGVyIGRlbGl2ZXJ5LCBzYXksIG9ubHkgZm9yIHNvbWUgZnJh Y3Rpb24gb2YgdGhlIHRyYWZmaWMgY2hhcmFjdGVyaXplZCBieSBzb21lIG90aGVyIG1lYW5zIChz YXksIG90aGVyIGhlYWRlciBiaXRzKS4NCltUaGUgIm90aGVyIG1lYW5zIiBhbmQgIm90aGVyIGJp dHMiIHdvcmRpbmcgaXMgcHJldHR5IGFtYmlndW91cyBoZXJlLiBJIHJlY2tvbiBJIGNhbiBndWVz cyB3aGF0IHlvdSBtZWFuIGJ1dCB0aGVuIEkgZG9uJ3Qga25vdyB3aHkgeW91J3JlIHNheWluZyB0 aGlzLCAnY29zIEkgZG9uJ3QgdGhpbmsgSSd2ZSBkaXNhZ3JlZWQgd2l0aCB5b3Ugb24gdGhpcy4g U28gcGVyaGFwcyB5b3UgY291bGQgYmUgbW9yZSBzcGVjaWZpYyBhbmQgd2UgbWlnaHQgYmUgYWJs ZSB0byBzZWUgd2h5IHlvdSd2ZSBicm91Z2h0IHRoaXMgdXAuXQ0KDQpBbHNvIEkgd2Fzbid0IHJl YWxseSB0YWxraW5nIGFib3V0IGFsbCAibGluayB0ZWNobm9sb2d5IHRoYXQgZ3VhcmFudGVlcyBp bi1vcmRlciBkZWxpdmVyeSB3aXRoaW4gYSBmbG93Ii4ge05vdGUgMX0gSSB3YXMgdGFsa2luZyBh Ym91dCBsaW5rIHRlY2hub2xvZ3kgd2hlcmUgYWxsIGZsb3dzIGFyZSBibG9ja2VkIHdoaWxlIHdh aXRpbmcgdG8gZ2V0IHRoZSBhZ2dyZWdhdGUgYmFjayBpbiBvcmRlciB0aGF0IGl0IHdhcyBpbiB3 aGVuIGl0IGFycml2ZWQuIEkgc3BlY2lmaWNhbGx5IHNhaWQ6DQoNCk5vdGUgdGhhdCB0aGVyZSBj YW4gYmUgbXVsdGlwbGUgZmxvd3Mgb3ZlciBvbmUgbGluay4gU28gJ2luLW9yZGVyIGRlbGl2ZXJ5 JyBmb3IgYSBsaW5rIGRvZXMgbm90IG1lYW4gaW4gb3JkZXIgb2YgVENQIHNlcXVlbmNlIG51bWJl ci4gSXQgbWVhbnMgJ2RlbGl2ZXJlZCBpbiB0aGUgb3JkZXIgdGhhdCBwYWNrZXRzIGFycml2ZWQg YXQgdGhlIGxpbmsnICh0aGUgbGluayBpbmdyZXNzIGFkZHMgaXRzIG93biBzZXF1ZW5jZSBudW1i ZXJzLCBhbmQgdGhlIGxpbmsgZWdyZXNzIGJ1ZmZlcnMgdGhlbSB1bnRpbCBpdCBjYW4gc2VuZCBv dXQgaW4gdGhlIHNhbWUgb3JkZXIsIG9yIHVudGlsIGEgdGltZS1vdXQgb3IgbWF4IG5vLiBvZiBs aW5rIHJldHJhbnNtaXNzaW9ucykuDQpGb3IgZXhhbXBsZToNCg0KICAqICAgQSBwYWNrZXQgcmVz ZXF1ZW5jaW5nIGJ1ZmZlciBhZnRlciBhbGxvd2luZyBmb3IgbGluay1sYXllciByZXRyYW5zbWlz c2lvbnMgaXMgY29tbW9uIGZvciByYWRpbyBsaW5rIHRlY2hub2xvZ2llcyBzdWNoIGFzIExURSAo UERDUCBsYXllcikgYW5kIDgwMi4xMSBXaUZpLg0KICAqICAgQSBwYWNrZXQgcmVzZXF1ZW5jaW5n IGJ1ZmZlciBhZnRlciBtZXJnaW5nIG11bHRpcGxlIGJvbmRlZCBsaW5rIGNoYW5uZWxzIGlzIGNv bW1vbiBmb3Igb3RoZXIgYWNjZXNzIGxpbmsgdGVjaG5vbG9naWVzIHN1Y2ggYXMgZG93bnN0cmVh bSBET0NTSVMgYm9uZGVkIGNoYW5uZWxzLg0KDQoNCg0KQ2xlYXJseSwgcmVvcmRlcmluZyBpcyBh IHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgaW4gdGhlIElFVEYgYXMgYSB3aG9s ZS4gQW5kIHdlIGNvdWxkIGRpc2N1c3Mgd2hldGhlciBhIHJldmlzaW9uIG9mIFJGQyAzMzY2IGlz IG5lZWRlZC4NCk5vLiBUaGVyZSBpcyBubyBwcm9wb3NhbCB0byBhbHRlciBnZW5lcmFsIGd1aWRh bmNlIGZvciBhbGwgbGlua3MgbGlrZSBSRkMgMzM2Ni4gTm8tb25lIGlzIHNheWluZyB0aGlzLg0K DQpUaGVyZSBpcyBub3QgZXZlbiBhIHByb3Bvc2FsIHRvIHJlcXVpcmUgb3IgZXZlbiByZWNvbW1l bmQgdGhhdCBMNFMtc3BlY2lmaWMgbGlua3MgZG8gYW55dGhpbmcuDQoNClRoZSBzcGVjaWZpYyBw cm9wb3NhbCBpcyB0byByZXF1aXJlIEw0UyBzb3VyY2VzIHRvIHVzZSBhIFJBQ0stbGlrZSBzY2hl bWUsIGFzIGEgY29uZGl0aW9uIGZvciBzZXR0aW5nIHRoZSBFQ1QoMSkgY29kZXBvaW50LiBTZWUg dGhlIGxhc3QgYnVsbGV0IGluIFMuNC4zIG9mIGRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0w NTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlk LTA1I3NlY3Rpb24tNC4zPi4NCg0KVGhpcyBzYXlzIG5vdGhpbmcgYWJvdXQgd2hhdCBMNFMgbGlu a3MgTVVTVCwgU0hPVUxEIG9yIE1BWSBkby4gSXQganVzdCBnaXZlcyBhbiBMNFMgbGluayBhbiBv cHBvcnR1bml0eSBub3QgdG8gaGF2ZSB0byBkbyByZXNlcXVlbmNpbmcuDQoNCg0KDQpCdXQgSSBh bSBub3QgY29udmluY2VkIHRoYXQgdGhpcyB0b3BpYyBoYXMgdG8gYmUgdGllZCBpbnRvIGFuIGV4 cGVyaW1lbnQgc3VjaCBhcyBMNFMuDQpJdCBpcyBhbiBvcHBvcnR1bml0eSB0aGF0IGN1cnJlbnRs eSBvbmx5IGFwcGxpZXMgdG8gTDRTLg0KDQpMNFMgaXMgbWVyZWx5IGFuIGV4YW1wbGUgb2YgYSBj YXNlIHdoZXJlIHdlIGNhbiBtYW5kYXRlIHRoYXQgdGhlcmUgd2lsbCBiZSBubyBub24tUkFDSyB0 cmFmZmljIGluIGEgbGluaywgd2hpY2ggY3JlYXRlcyBhbiBvcHBvcnR1bml0eSBmb3IgdGhvc2Ug d2hvIGFyZSBpbXBsZW1lbnRpbmcgdGhlIEw0UyBEdWFsUSBDb3VwbGVkIEFRTSB0byBpZ25vcmUg dGhlIFJGQzMzNjYgcmVzZXF1ZW5jaW5nIGFkdmljZSBmb3IgdGhlIEw0UyBxdWV1ZSAoYnV0IHdl IGFyZSBub3QgY2hhbmdpbmcgdGhlIGFkdmljZSwgYmVjYXVzZSBMNFMgaXMgb25seSBhbiBleHBl cmltZW50KS4gVGhlIHByaXplIGlzIHRvIHJlbW92ZSB0aGUgaGVhZC1vZi1saW5lIGJsb2NraW5n IHByb2JsZW0gZm9yIHRoZWlyIHVzZXJzLg0KDQpUaGlzIGlzIG5vdCBMNFMtc3BlY2lmaWMsIGFs dGhvIHRoZXJlIGFyZSBubyBvdGhlciBleGFtcGxlcyBhdCB0aGUgbW9tZW50IHdoZXJlIHRoaXMg b3Bwb3J0dW5pdHkgaXMgcG9zc2libGUgKHNvIGluIHRoYXQgc2Vuc2UgaXQgaXMgY3VycmVudGx5 IEw0Uy1zcGVjaWZpYykuDQoNCg0KVGhlIG1lc3NhZ2UgaGFzIHRvIGJlIGhhbmRsZWQgcmVhbGx5 IGNhcmVmdWxseSwgYmVjYXVzZSB0aGUgb3Bwb3J0dW5pdGllcyBmb3IgbWlzdW5kZXJzdGFuZGlu ZyBhcmUgZW5vcm1vdXMgKGFzIGV2aWRlbmNlZCBieSB0aGlzIHRocmVhZCwgYW5kIHdlIGhhdmVu J3QgZXZlbiBzdGFydGVkIHRhbGtpbmcgdG8gbm9uLXRyYW5zcG9ydCBwZW9wbGUgeWV0KS4NCg0K U28gR29ycnkgYW5kIERhdmlkIEIgd2FudCBtZSB0byBkcmFmdCBhIHNob3J0IEktRCB0aGF0IHRo ZXkgd2lsbCB3b3JkLXNtaXRoIGFuZCBhdXRob3IgYXMgdHN2d2cgY2hhaXJzIHRvIG1ha2UgdGhl IHNpdHVhdGlvbiBjbGVhci4NCg0KSSBoYXZlIHNhaWQgSSBkb24ndCB3YW50IHRoaXMgZGlzY3Vz c2lvbiB0byBiZSBvZmZpY2lhbGx5IHJhaXNlZCBvdXRzaWRlIHRoZSB0cmFuc3BvcnQgYXJlYSB1 bnRpbCB3ZSBhcmUgc3VyZSB0aGF0IGEgdmFyaWFudCBvZiBSQUNLIGlzIGV2ZW4gZmVhc2libGUg d2l0aG91dCBhbnkgcGFja2V0IGNvdW50aW5nIGF0IGFsbCAoaS5lLiB3aXRob3V0IHRoZSBpbml0 aWFsIDMtRHVwQUNLIHJ1bGUgaW4gY3VycmVudCBSQUNLKS4gU28gSSdsbCBwcmlvcml0aXplIHdv cmtpbmcgdGhhdCBvdXQgZm9yIHRoZSBuZXh0IHdlZWsgb3Igc28sIHJhdGhlciB0aGFuIGRyYWZ0 aW5nIGFueXRoaW5nLg0KDQoNCg0KQm9iDQoNCntOb3RlIDF9OiBJIGhhZG4ndCBjb25zaWRlcmVk IHRoYXQgdGhpcyB3b3VsZCBhZmZlY3QgdGVjaG5vbG9naWVzIGxpa2UgRUNNUCB0aGF0IG1haW50 YWluIG9yZGVyIHdpdGhvdXQgYSByZXNlcXVlbmNpbmcgYnVmZmVyIGFuZCB3aXRob3V0IGludHJv ZHVjaW5nIEhvTCBibG9ja2luZy4gQnV0IGFjdHVhbGx5LCB0aGUgY29uc2VxdWVuY2UgdGhlcmUg d291bGQgYmUgdGhhdCBMNFMgdHJhZmZpYyBjb3VsZCBiZSBzcHJheWVkIGJ5IEVDTVAgd2l0aG91 dCBwZXItZmxvdyBoYXNoaW5nLg0KDQoNCg0KTWljaGFlbA0KDQpGcm9tOiBCb2IgQnJpc2NvZSBb bWFpbHRvOmluQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4 IDY6NDIgQU0NClRvOiBTY2hhcmYsIE1pY2hhZWw7IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1A aWV0Zi5vcmc+DQpDYzogdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gIkw0UyBhbmQgUkFDSyIN Cg0KTWljaGFlbCwNCg0KVGhhdCBpcyB0aGUgcG9pbnQgSSB0aG91Z2h0IHlvdSB3ZXJlIG1ha2lu ZywgYW5kIG15IHBvaW50IC9pcy8gYWJvdXQgdGhhdC4NCg0KSWYgYW4gYXBwbGljYXRpb24gbmVl ZHMgYWxsIHRoZSBwYWNrZXRzIChpLmUuIGEgcmVsaWFibGUgcHJvdG9jb2wpLCBpdCdzIG5vdCB1 c2VmdWwgdG8gcmVkdWNlIHRoZSBsYXRlbmN5IG9mIHNvbWUgcGFja2V0cyBidXQgbm90IGFsbC4g VGhhdCdzIHdoZXJlIHRoZSBpbi1vcmRlciByZXF1aXJlbWVudCBjb21lcyBmcm9tLg0KDQpIb3dl dmVyLCBpZiBhIHN0cmVhbS1iYXNlZCB0cmFuc3BvcnQgaXMgdXNlZCAoaS5lLiBUQ1ApIHRoZSAv YXBwbGljYXRpb24vIHN0aWxsIGdldHMgaW4tb3JkZXIgZGVsaXZlcnkgZnJvbSBUQ1AuIEl0IGp1 c3QgZG9lc24ndCBoYXZlIHRvIHJlcXVpcmUgbGlua3MgdG8gcHJvdmlkZSBpbiBvcmRlciBkZWxp dmVyeSBhcyB3ZWxsLg0KDQpOb3RlIHRoYXQgdGhlcmUgY2FuIGJlIG11bHRpcGxlIGZsb3dzIG92 ZXIgb25lIGxpbmsuIFNvICdpbi1vcmRlciBkZWxpdmVyeScgZm9yIGEgbGluayBkb2VzIG5vdCBt ZWFuIGluIG9yZGVyIG9mIFRDUCBzZXF1ZW5jZSBudW1iZXIuIEl0IG1lYW5zICdkZWxpdmVyZWQg aW4gdGhlIG9yZGVyIHRoYXQgcGFja2V0cyBhcnJpdmVkIGF0IHRoZSBsaW5rJyAodGhlIGxpbmsg aW5ncmVzcyBhZGRzIGl0cyBvd24gc2VxdWVuY2UgbnVtYmVycywgYW5kIHRoZSBsaW5rIGVncmVz cyBidWZmZXJzIHRoZW0gdW50aWwgaXQgY2FuIHNlbmQgb3V0IGluIHRoZSBzYW1lIG9yZGVyLCBv ciB1bnRpbCBhIHRpbWUtb3V0IG9yIG1heCBuby4gb2YgbGluayByZXRyYW5zbWlzc2lvbnMpLg0K DQpTbywgaWYgdGhlIGxpbmsgbG9zZXMgYSBwYWNrZXQgZnJvbSBmbG93IEEgKHRoZSBsaW5rIGlz bid0IGF3YXJlIG9mIG1pY3JvZmxvd3MsIEknbSBqdXN0IHNheWluZyB0aGUgcGFja2V0IGhhcHBl bnMgdG8gYmUgZnJvbSBmbG93IEEpLCBsaW5rLWxheWVyIGluLW9yZGVyIGRlbGl2ZXJ5IHdpbGwg aG9sZCBiYWNrIGFsbCBwYWNrZXRzIHNlbnQgYWZ0ZXIgdGhhdCBwYWNrZXQgKGZyb20gYWxsIGZs b3dzLCBub3QganVzdCBmbG93IEEpIHVudGlsIHRoZSBsaW5rIHJlcGFpcnMgdGhlIGdhcCBvciBn aXZlcyB1cC4NCg0KU28gaG9wLWJ5LWhvcCBpbi1vcmRlciBkZWxpdmVyeSBnaXZlcyBldmVyeSBm bG93IHRoZSBzYW1lIGRlbGF5IGFzIHRoZSB3b3JzdCBkZWxheWVkIGZsb3cuDQoNCk9mIGNvdXJz ZSwgc29tZW9uZSBidWlsZGluZyBhIG5ldHdvcmsgZm9yIERFVE5FVCB3b3VsZCBhdm9pZCBsaW5r IHRlY2hub2xvZ2llcyBsaWtlIFdpRmkgb3IgTFRFIHRoYXQgZnJlcXVlbnRseSBsb3NlIGFuZCBy ZXRyYW5zbWl0IHBhY2tldHMuIEJ1dCB3aGVyZXZlciB0aGVyZSBpcyB2YXJpYWJsZSBkZWxheSBp biBhIGxpbmssIGd1YXJhbnRlZWQgaW4tb3JkZXIgZGVsaXZlcnkgcGVyLWhvcCBtZWFucyBldmVy eSBmbG93IGlzIGd1YXJhbnRlZWQgdG8gYWx3YXlzIGdldCB0aGUgd29yc3QgZGVsYXkgZnJvbSBl dmVyeSBsaW5rLCB3aGljaCB3b3VsZCBoYXZlIGJlZW4gZXhwZXJpZW5jZWQgYnkgb25seSBvbmUg ZmxvdyB3aXRob3V0IHBlci1ob3AgaW4tb3JkZXIgZGVsaXZlcnkuDQoNCkFuZCBtYW55IG9mIHRo ZSBhcHBsaWNhdGlvbnMgb2YgREVUTkVUIGludm9sdmUgZHVtYiBpbmR1c3RyaWFsIG1hY2hpbmVy eSB0aGF0IGp1c3QgZXhwZWN0cyBldmVyeXRoaW5nIHRvIGFycml2ZSBpbiBvcmRlciBhbmQgdG8g YSBjbG9ja2VkIHNjaGVkdWxlLiBCdXQgaXQncyBhbHdheXMgYXMgZWZmZWN0aXZlIHRvIGRlcGxv eSBhIHJlc2VxdWVuY2luZyBidWZmZXIgYXMgdGhlIHBlbnVsdGltYXRlIGhvcCwgc2NyZXdlZCBv bnRvIHRoZSByZWNlaXZpbmcgbWFjaGluZSBpZiBuZWNlc3NhcnksIHJhdGhlciB0aGFuIHJlcXVp cmUgcGVyLWhvcCByZXNlcXVlbmNpbmcgaW4gdGhlIG5ldHdvcmsuDQoNCl9fX19fX19fX19fX19f X18NClNvLCB3aHkgZG8gSW50ZXJuZXQgbGlua3Mgb2Z0ZW4gZW5zdXJlIGluLW9yZGVyIGRlbGl2 ZXJ5IGV2ZW4gdGhvdWdoIFRDUCBwdXRzIGV2ZXJ5dGhpbmcgaW4gb3JkZXIgZm9yIHRoZSBhcHBs aWNhdGlvbj8NCg0KU2hvcnQgYW5zd2VyOiB0aGUgMyBEdXBBQ0sgcnVsZSAod2hpY2ggaXMgdG8g ZG8gd2l0aCBsb3NzLXJlY292ZXJ5LCBhIGRpZmZlcmVudCBpc3N1ZSBmcm9tIHRoZSBkaXNjdXNz aW9uIGFib3ZlKS4NCg0KTG9uZyBhbnN3ZXI6IEFzIGZsb3cgcmF0ZXMgaGF2ZSBzY2FsZWQgdXAs IHRoZSB0eXBpY2FsIHRpbWUgYmV0d2VlbiAzIHBhY2tldCBhcnJpdmFscyBoYXMgYmVjb21lIHNv IHNtYWxsIHRoYXQgVENQJ3MgMy1EdXBBQ0sgcnVsZSBtYWtlcyBsaW5rcyBoYXZlIHRvIHByb3Zp ZGUgZGVsaXZlcnkgd2l0aCBvbmx5IGEgdmVyeSBzbWFsbCByZS1vcmRlcmluZyBkZWdyZWUgLSBz byBzbWFsbCB0aGF0IGl0J3MgZWFzaWVyIGZvciBhIGxpbmsgdG8ganVzdCBkZWxpdmVyIGV2ZXJ5 dGhpbmcgaW4gdGhlIG9yZGVyIGl0IHJlY2VpdmVkIGl0OyBub3QgYmVjYXVzZSBUQ1AgZG9lc24n dCBwdXQgcGFja2V0cyBiYWNrIGluIG9yZGVyLCBidXQganVzdCBzbyBhcyBub3QgdG8gdHJpZ2dl ciBUQ1AgaW50byBnZW5lcmF0aW5nIHNwdXJpb3VzIHJldHJhbnNtaXNzaW9ucy4NCg0KDQoNCkJv Yg0KT24gMDgvMTEvMjAxOCAxNjozNSwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KSW5saW5lIFtt c10NCg0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0bzppbkBib2JicmlzY29lLm5ldF0NClNlbnQ6 IFRodXJzZGF5LCBOb3ZlbWJlciA4LCAyMDE4IDEyOjU2IFBNDQpUbzogU2NoYXJmLCBNaWNoYWVs OyB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KQ2M6IHRzdndnQGlldGYub3Jn PG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHN2d2ddIENyb3NzLWFyZWEg YWxpZ25tZW50IG9uICJMNFMgYW5kIFJBQ0siDQoNCk1pY2hhZWwsDQoNClRoaXMgaXMgbWVyZWx5 IGEgc3ltcHRvbSBvZiBhIGRpZmZlcmVuY2UgaW4gb3BpbmlvbiBvbiB3aGVyZSB0aGUgcmVzZXF1 ZW5jaW5nIGZ1bmN0aW9uIHNob3VsZCBiZSBsb2NhdGVkLg0KDQogICogICBMNFMgdGFrZXMgdGhl IGVuZC10by1lbmQgYXBwcm9hY2ggc2F5aW5nIHRoYXQgaXQgaXMgc3VmZmljaWVudCB0byBkbyBy ZXNlcXVlbmNpbmcgaW4gb25lIHBsYWNlICh0aGUgcmVjZWl2aW5nIGhvc3QpIGlmIGl0IGlzIG5l ZWRlZC4gVGhlbiBhbnkgcmVzZXF1ZW5jaW5nIGRlbGF5IG9ubHkgYWZmZWN0cyB0aGF0IGZsb3cu DQogICogICBUaGUgREVUTkVUIGFwcHJvYWNoIGlzIHNheWluZyB0aGUgcmVzZXF1ZW5jaW5nIG11 c3QgYmUgZG9uZSBob3AtYnktaG9wLiBUaGlzIG1lYW5zIHRoZXJlIGFwcGVhcnMgdG8gYmUgbm8g cmVzZXF1ZW5jaW5nIG5lZWRlZCBvbiB0aGUgcmVjZWl2ZXIgKGV4Y2VwdCBpZiB0aGVyZSdzIHJl LW9yZGVyaW5nIG9uIHRoZSBmaW5hbCBob3ApLg0KDQoNCiAgKiAgIEluIG9yZGVyIHRvIGd1YXJh bnRlZSBubyByZXNlcXVlbmNpbmcgaW4gdGhlIG5ldHdvcmsgKERFVE5FVCBhcHByb2FjaCksIG9u bHkgdGhlIHRoZSB3b3JzdCBjYXNlIGxhdGVuY3kgY2FuIGJlIGd1YXJhbnRlZWQsIGFuZCBldmVy eSBwYWNrZXQgaGFzIHRvIGhhdmUgdGhhdCBzYW1lIHdvcnN0LWNhc2UgbGF0ZW5jeS4NCiAgKiAg IFdoZW4geW91IGxlYXZlIHJlc2VxdWVuY2luZyB0byB0aGUgcmVjZWl2ZXIgKGVuZC10by1lbmQg YXBwcm9hY2gpLCBtb3N0IG9mIHRoZSBwYWNrZXRzIGFycml2ZSBlYXJsaWVyIHRoYW4gdGhleSB3 b3VsZCB3aXRoIERFVE5FVCwgYnV0IG91dCBvZiBvcmRlciBvbmVzIG1pZ2h0IG5vdC4gVGhlbiB0 aGUgYXBwbGljYXRpb24gY2hvb3NlcyB3aGV0aGVyIGl0IHdhbnRzIHRvIHdhaXQuDQpbbXNdIE15 IHBvaW50IGlzIGRpZmZlcmVudDogVGhlcmUgc2VlbSB0byBiZSBvdGhlciB3b3JraW5nIGdyb3Vw cyBpbiB0aGUgSUVURiB0aGF0IGRvIHRhbGsgYWJvdXQg4oCcbG93IGxhdGVuY3nigJ0gYXMgd2Vs bCBidXQgYXBwYXJlbnRseSB0aGV5IGFsc28gZG8gbmVlZCBpbi1vcmRlciBkZWxpdmVyeSBvZiBw YWNrZXRzLCB0b28uIFNvIHRoZSBhc3N1bXB0aW9uIHRoYXQgZS5nLiBhIGxpbmsgbGF5ZXIgdGVj aG5vbG9neSBjYW4gc2ltcGx5IGRpc2FibGUgaW4tb3JkZXIgZGVsaXZlcnkgZm9yIGFsbCDigJxs b3cgbGF0ZW5jeeKAnSBhcHBsaWNhdGlvbnMgc2VlbXMgbm90IGNvcnJlY3QuIFRoZSByZWFsaXR5 IG1heSBiZSBhIGJpdCBtb3JlIGNvbXBsZXguDQpUaGUgMyBEdXBBQ0sgcnVsZSBpbiBUQ1AgbGVk IHRoZSBJbnRlcm5ldCBub3QgdG8gZm9sbG93IHRoZSBlbmQtdG8tZW5kIHByaW5jaXBsZSBvbiBy ZS1zZXF1ZW5jaW5nLiBOb3cgd2UncmUgcmVtb3ZpbmcgdGhlIDMgRHVwQUNLIHJ1bGUsIHdlIGNh biB0YWtlIGFkdmFudGFnZSBvZiB0aGUgZTJlIHByaW5jaXBsZS4NClttc10gRm9yIFRDUCwgdGhy ZWUgRHVwQUNLUyBhcmUgYSBTSE9VTEQgaW4gUkZDIDU2ODEgYW5kIFJGQyA1NjgxIGlzIHN0YW5k YXJkcyB0cmFjay4gU28gdGhlIGJhciBmb3Ig4oCccmVtb3ZpbmfigJ0gdGhhdCBydWxlIGZvciBU Q1AgaXMgbm90IGxvd+KApg0KW21zXSBBbHNvLCB0aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUgY29t ZXMgd2l0aCB0cmFkZW9mZnMuIEZvciBpbnN0YW5jZSwgcmVseWluZyBvbiB0aGUgZW5kLXRvLWVu ZCBwcmluY2lwbGUgZm9yIHJlY292ZXJ5IG9mIGJpdCBlcnJvcnMgaXMgbm90IGVmZmljaWVudC4g Rm9yIGluLW9yZGVyIGRlbGl2ZXJ5IHRoZXJlIGFyZSB0cmFkZW9mZnMgYXMgd2VsbCwgc2VlIGUu Zy4gU2VjdGlvbiA0IGluIGRyYWZ0LWlldGYtdGNwbS1yYWNrLTA0LiBUaGVyZSBtYXkgYmUgbm8g ZnJlZSBsdW5jaC4NCk9mIGNvdXJzZSwgYW4gYXBwbGljYXRpb24gbWlnaHQgY2hvb3NlIHRvIHVz ZSBUQ1AgYW5kIEw0UywgcmF0aGVyIHRoYW4gVURQIGFuZCBMNFMgKGUuZyBRVUlDKS4gVGhlbiB0 aGVyZSBjb3VsZCBzdGlsbCBiZSBIb0wgYmxvY2tpbmcgaW4gdGhlIHJlY2VpdmluZyBUQ1Agc3Rh Y2suIEJ1dCBhdCBsZWFzdCB0aGVyZSdzIG5vIEhvTCBibG9ja2luZyBpbiB0aGUgbmV0d29yaywg YW5kIHRoZSBhcHAgY2FuIGNob29zZSBiZXR3ZWVuIHN0cmVhbSAoVENQKSBvciBkYXRhZ3JhbSAo VURQKS4NClttc10gSWYgTFJPL0dSTyBpbiB0aGUgcmVjZWl2aW5nIFRDUCBzdGFjayBnZXRzIG1l c3NlZCB1cCwgSSBmYWlsIHRvIHNlZSB0aGUgYmVuZWZpdCAoc2VlIGRyYWZ0LWlldGYtdGNwbS1y YWNrLTA0KS4NCk1pY2hhZWwNCg0KDQpCb2INCk9uIDA2LzExLzIwMTggMTk6MjAsIFNjaGFyZiwg TWljaGFlbCB3cm90ZToNCg0KQSBjb21tZW50IG9uIHRoZSBUQ1BNIHByZXNlbnRhdGlvbiAiTDRT IGFuZCBSQUNLIjoNCg0KDQoNCkFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZSBERVRORVQgV0cg aW4gUlRHIGFyZWEgaGFzIHF1aXRlIHNvbWUgdXNlcyBjYXNlcyBmb3IgdWx0cmEtbG93IGxhdGVu Y3kgdHJhbnNwb3J0IC0gaW4gcGFydGljdWxhciBhbHNvIHdpdGggYm91bmRlZCBqaXR0ZXIuIEFu ZCBzb21lIG9mIHRoZXNlIGFwcGxpY2F0aW9ucyAoZS5nLiB1c2luZyBVRFApIGFwcGFyZW50bHkg bWF5IG5vdCBiZSBhYmxlIHRvIHRvbGVyYXRlICphbnkqIG91dC1vZi1vcmRlciBwYWNrZXQgZGVs aXZlcnkuDQoNCg0KDQpTbyBwZXJoYXBzIHNvbWUgY3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gdWx0 YS1sb3ctbGF0ZW5jeSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudHMgd291bGQgYmUgdXNlZnVsPw0K DQoNCg0KTWljaGFlbA0KDQood2hvIHJlY2VudGx5IGhhZCB0byByZXZpZXcgZHJhZnQtaWV0Zi1k ZXRuZXQtYXJjaGl0ZWN0dXJlKQ0KDQoNCg0KDQoNCg0KDQoNCg0KLS0NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpC b2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2Nv ZS5uZXQvDQoNCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQoNCg0KLS0NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8v Ym9iYnJpc2NvZS5uZXQvDQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D1536B3rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNobiI7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MVm9yZm9ybWF0aWVydFpj aG4NCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgVm9yZm9ybWF0aWVydCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2 b3JsYWdlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9y bGFnZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxh Z2UyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjU5 OTIwMzk2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY1NjI4NzMyO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NTIx NDMxMjY1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQxMzQ0NjQwODt9DQpAbGlzdCBsMTps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTps ZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJ e21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo2NDEwMzk0NzA7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEzOTEwOTQ4 MjYgLTE1MzA2MTk0MiA2NzU2NzY0MSA2NzU2NzY0MyA2NzU2NzYzMSA2NzU2NzY0MSA2NzU2NzY0 MyA2NzU2NzYzMSA2NzU2NzY0MSA2NzU2NzY0Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tdXBwZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgltYXJnaW4tbGVmdDo1NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTM2LjBwdDt9DQpAbGlzdCBs Mw0KCXttc28tbGlzdC1pZDo5MjUxMTU1Mzc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02OTMy NzgzNjt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0 DQoJe21zby1saXN0LWlkOjE5NzYzMzM3OTQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE4NDk0 NDg4MjY7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NQ0KCXttc28tbGlzdC1pZDoyMTIxODcwNzM3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTU5 MzE1MDAxMjt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw1OmxldmVs Mw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWw1DQoJe21zby1sZXZlbC10 YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWxsIG5v dCBjb21tZW50IG9uIGxpbmsgdGVjaG5vbG9neSBpbXBsZW1lbnRhdGlvbiwgc2NoZWR1bGVyIGFu ZCBxdWV1ZSBkZXNpZ24gYXNzdW1wdGlvbnMgaW4gQXBwZW5kaXggQS4xLjcgb2YgZHJhZnQtaWV0 Zi10c3Z3Zy1lY24tbDRzLWlkLTA1Lg0KIFBlb3BsZSBlLmcuIGluIFJURyBhcmVhIG1heSBiZSBt b3JlIGZhbWlsaWFyIHdpdGggdGhlIGltcGxpY2F0aW9ucyBvZiBpbnRlcm5hbCBkZXNpZ25zIGUu Zy4gaW5zaWRlIGEgcm91dGVyLiBJTUhPIHRoZSBiZXN0IHdheSB0byBnZXQgcm91dGluZyBleHBl cnRzIGludG8gdGhlIGxvb3AgYmVmb3JlIGZ1cnRoZXIgZGlzY3Vzc2luZyB3aGF0IGlzIGN1cnJl bnRseSBsaXN0ZWQgaW4gQXBwZW5kaXggQS4xLjcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlRodXMsIEkgbGltaXQgbXkgcmVzcG9uc2UgdG8gdGhlIGFjdHVhbCB3b3JkaW5n IGluIHRoZSBtYWluIHBhcnQgb2YgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA1OjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBIHNjYWxhYmxlIGNvbmdlc3Rpb24gY29udHJvbCBN VVNUIGRldGVjdCBsb3NzIGJ5IGNvdW50aW5nIGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgdW5pdHMgb2YgdGltZSwgd2hpY2ggaXMgc2NhbGFibGUsIGFuZCBNVVNU IE5PVCBjb3VudCBpbiB1bml0cyBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHBhY2tldHMgKGFzIGluIHRoZSAzIER1cEFDSyBydWxlIG9mIHRyYWRpdGlvbmFsIFRD UCksIHdoaWNoIGlzIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHNjYWxhYmxlIChzZWUNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWw0 cy1pZC0wNSNhcHBlbmRpeC1BLjEuNyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BcHBlbmRpeCBB LjEuNzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQogZm9yIHJhdGlv bmFsZSkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGluZGl2 aWR1YWwgY29udHJpYnV0b3IsIEkgZGlzYWdyZWUgd2l0aCB0aGlzIHJlcXVpcmVtZW50LiBJIHdv dWxkIHByb2JhYmx5IGJlIE9LIHdpdGggYSB3b3JkaW5nIHRoYXQgYSBUQ1Agc2VuZGVyIG11c3Qg YmUgYWJsZSB0byB0b2xlcmF0ZSByZW9yZGVyaW5nDQogYmV5b25kIDMgRHVwbGljYXRlIEFDS3Mu IEkgYmVsaWV2ZSBpdCBkb2VzIG5vdCBtYXR0ZXIgaG93IGEgc2VuZGVyIHJlYWxpemVzIHRoaXMg aW50ZXJuYWxseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIGlmIHRo YXQgcmVxdWlyZW1lbnQgaXMgbm90IGp1c3QgcmVtb3ZlZCwgSSBiZWxpZXZlIHRoZSB3b3JkaW5n IOKAnHRyYWRpdGlvbmFsIFRDUOKAnSBoYXMgdG8gYmUgcmVwbGFjZWQgYnkg4oCcc3RhbmRhcmQg VENQ4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CVFcsIGFsc28sIGlu IHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCB0aGVyZSBoYXMgdG8gYmUgYSBjbGVhciBkaXN0aW5j dGlvbiBiZXR3ZWVuIGV4cGVyaW1lbnRzIGFuZCBzdGFuZGFyZHMuIEhpc3RvcnkgdGVsbHMgdXMg dGhhdCBzb21lIGV4cGVyaW1lbnRzDQogY2FuIGV2b2x2ZSBpbnRvIHN0YW5kYXJkcyB0cmFjayBz cGVjaWZpY2F0aW9ucywgd2hpbGUgb3RoZXIgZXhwZXJpbWVudHMgbWF5IGZhaWwuIEFuZCB0aGVy ZSBpcyBubyB3YXkgb2Yga25vd2luZyB0aGF0IGluIGFkdmFuY2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlz Y29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIE5vdmVtYmVyIDksIDIwMTggMTE6MDggQU08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWlj aGFlbDsgdGNwbUBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gdHN2d2dAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gJnF1b3Q7 TDRTIGFuZCBSQUNLJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NaWNoYWVsLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA5LzExLzIwMTggMDY6MjEsIFNj aGFyZiwgTWljaGFlbCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkkgZG9u4oCZdCBzZWUgdGhlIGZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgYmV0d2Vl biBhIGxpbmsgdGVjaG5vbG9neSB0aGF0IGd1YXJhbnRlZXMgaW4tb3JkZXIgZGVsaXZlcnkgd2l0 aGluIGEgZmxvdyAoc2F5IGJ5IGZsb3cgaGFzaGluZywgc2VlIEVDTVApDQogdnMuIHNvbWUgbGlu ayBzY2hlbWUgdGhhdCBndWFyYW50ZWVzIGluLW9yZGVyIGRlbGl2ZXJ5LCBzYXksIG9ubHkgZm9y IHNvbWUgZnJhY3Rpb24gb2YgdGhlIHRyYWZmaWMgY2hhcmFjdGVyaXplZCBieSBzb21lIG90aGVy IG1lYW5zIChzYXksIG90aGVyIGhlYWRlciBiaXRzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bVGhlICZxdW90O290aGVyIG1lYW5z JnF1b3Q7IGFuZCAmcXVvdDtvdGhlciBiaXRzJnF1b3Q7IHdvcmRpbmcgaXMgcHJldHR5IGFtYmln dW91cyBoZXJlLiBJIHJlY2tvbiBJIGNhbiBndWVzcyB3aGF0IHlvdSBtZWFuIGJ1dCB0aGVuIEkg ZG9uJ3Qga25vdyB3aHkgeW91J3JlIHNheWluZyB0aGlzLCAnY29zIEkgZG9uJ3QgdGhpbmsgSSd2 ZSBkaXNhZ3JlZWQgd2l0aCB5b3Ugb24gdGhpcy4gU28gcGVyaGFwcyB5b3UgY291bGQgYmUgbW9y ZSBzcGVjaWZpYw0KIGFuZCB3ZSBtaWdodCBiZSBhYmxlIHRvIHNlZSB3aHkgeW91J3ZlIGJyb3Vn aHQgdGhpcyB1cC5dPGJyPg0KPGJyPg0KQWxzbyBJIHdhc24ndCByZWFsbHkgdGFsa2luZyBhYm91 dCBhbGwgJnF1b3Q7PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5saW5rIHRlY2hub2xvZ3kgdGhhdCBndWFyYW50ZWVzIGluLW9yZGVyIGRlbGl2 ZXJ5IHdpdGhpbiBhIGZsb3c8L3NwYW4+JnF1b3Q7LiB7Tm90ZSAxfSBJIHdhcyB0YWxraW5nIGFi b3V0IGxpbmsgdGVjaG5vbG9neSB3aGVyZQ0KIGFsbCBmbG93cyBhcmUgYmxvY2tlZCB3aGlsZSB3 YWl0aW5nIHRvIGdldCB0aGUgYWdncmVnYXRlIGJhY2sgaW4gb3JkZXIgdGhhdCBpdCB3YXMgaW4g d2hlbiBpdCBhcnJpdmVkLiBJIHNwZWNpZmljYWxseSBzYWlkOjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSB0aGF0IHRoZXJlIGNhbiBiZSBtdWx0 aXBsZSBmbG93cyBvdmVyIG9uZSBsaW5rLiBTbyAnaW4tb3JkZXIgZGVsaXZlcnknIGZvciBhIGxp bmsgZG9lcyBub3QgbWVhbiBpbiBvcmRlciBvZiBUQ1Agc2VxdWVuY2UgbnVtYmVyLiBJdCBtZWFu cyAnZGVsaXZlcmVkIGluIHRoZSBvcmRlciB0aGF0IHBhY2tldHMgYXJyaXZlZCBhdCB0aGUgbGlu aycgKHRoZSBsaW5rIGluZ3Jlc3MgYWRkcyBpdHMgb3duIHNlcXVlbmNlDQogbnVtYmVycywgYW5k IHRoZSBsaW5rIGVncmVzcyBidWZmZXJzIHRoZW0gdW50aWwgaXQgY2FuIHNlbmQgb3V0IGluIHRo ZSBzYW1lIG9yZGVyLCBvciB1bnRpbCBhIHRpbWUtb3V0IG9yIG1heCBuby4gb2YgbGluayByZXRy YW5zbWlzc2lvbnMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4 YW1wbGU6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkEgcGFja2V0IHJlc2VxdWVuY2luZyBi dWZmZXIgYWZ0ZXIgYWxsb3dpbmcgZm9yIGxpbmstbGF5ZXIgcmV0cmFuc21pc3Npb25zIGlzIGNv bW1vbiBmb3IgcmFkaW8gbGluayB0ZWNobm9sb2dpZXMgc3VjaCBhcyBMVEUgKFBEQ1AgbGF5ZXIp IGFuZCA4MDIuMTEgV2lGaS4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkEgcGFja2V0IHJlc2VxdWVuY2luZyBidWZmZXIg YWZ0ZXIgbWVyZ2luZyBtdWx0aXBsZSBib25kZWQgbGluayBjaGFubmVscyBpcyBjb21tb24gZm9y IG90aGVyIGFjY2VzcyBsaW5rIHRlY2hub2xvZ2llcyBzdWNoIGFzIGRvd25zdHJlYW0gRE9DU0lT IGJvbmRlZCBjaGFubmVscy4NCjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2xlYXJseSwg cmVvcmRlcmluZyBpcyBhIHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgaW4gdGhl IElFVEYgYXMgYSB3aG9sZS4gQW5kIHdlIGNvdWxkIGRpc2N1c3Mgd2hldGhlciBhIHJldmlzaW9u IG9mIFJGQyAzMzY2IGlzIG5lZWRlZC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk5vLiBUaGVyZSBpcyBubyBwcm9wb3NhbCB0byBhbHRlciBnZW5lcmFsIGd1 aWRhbmNlIGZvciBhbGwgbGlua3MgbGlrZSBSRkMgMzM2Ni4gTm8tb25lIGlzIHNheWluZyB0aGlz Ljxicj4NCjxicj4NClRoZXJlIGlzIG5vdCBldmVuIGEgcHJvcG9zYWwgdG8gcmVxdWlyZSBvciBl dmVuIHJlY29tbWVuZCB0aGF0IEw0Uy1zcGVjaWZpYyBsaW5rcyBkbyBhbnl0aGluZy4NCjxicj4N Cjxicj4NClRoZSBzcGVjaWZpYyBwcm9wb3NhbCBpcyB0byByZXF1aXJlIEw0UyA8aT5zb3VyY2Vz PC9pPiB0byB1c2UgYSBSQUNLLWxpa2Ugc2NoZW1lLCBhcyBhIGNvbmRpdGlvbiBmb3Igc2V0dGlu ZyB0aGUgRUNUKDEpIGNvZGVwb2ludC4gU2VlIHRoZSBsYXN0IGJ1bGxldCBpbg0KPGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0w NSNzZWN0aW9uLTQuMyI+DQpTLjQuMyBvZiBkcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQtMDU8 L2E+LiA8YnI+DQo8YnI+DQpUaGlzIHNheXMgbm90aGluZyBhYm91dCB3aGF0IEw0UyBsaW5rcyBN VVNULCBTSE9VTEQgb3IgTUFZIGRvLiBJdCBqdXN0IGdpdmVzIGFuIEw0UyBsaW5rIGFuIG9wcG9y dHVuaXR5IG5vdCB0byBoYXZlIHRvIGRvIHJlc2VxdWVuY2luZy48YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CdXQgSSBhbSBub3QgY29udmluY2VkIHRoYXQg dGhpcyB0b3BpYyBoYXMgdG8gYmUgdGllZCBpbnRvIGFuIGV4cGVyaW1lbnQgc3VjaCBhcyBMNFMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgYW4gb3Bw b3J0dW5pdHkgdGhhdCBjdXJyZW50bHkgb25seSBhcHBsaWVzIHRvIEw0Uy4gPGJyPg0KPGJyPg0K TDRTIGlzIG1lcmVseSBhbiBleGFtcGxlIG9mIGEgY2FzZSB3aGVyZSB3ZSBjYW4gbWFuZGF0ZSB0 aGF0IHRoZXJlIHdpbGwgYmUgbm8gbm9uLVJBQ0sgdHJhZmZpYyBpbiBhIGxpbmssIHdoaWNoIGNy ZWF0ZXMgYW4gb3Bwb3J0dW5pdHkgZm9yIHRob3NlIHdobyBhcmUgaW1wbGVtZW50aW5nIHRoZSBM NFMgRHVhbFEgQ291cGxlZCBBUU0gdG8gaWdub3JlIHRoZSBSRkMzMzY2IHJlc2VxdWVuY2luZyBh ZHZpY2UgZm9yIHRoZSBMNFMgcXVldWUgKGJ1dA0KIHdlIGFyZSBub3QgY2hhbmdpbmcgdGhlIGFk dmljZSwgYmVjYXVzZSBMNFMgaXMgb25seSBhbiBleHBlcmltZW50KS4gVGhlIHByaXplIGlzIHRv IHJlbW92ZSB0aGUgaGVhZC1vZi1saW5lIGJsb2NraW5nIHByb2JsZW0gZm9yIHRoZWlyIHVzZXJz Lg0KPGJyPg0KPGJyPg0KVGhpcyBpcyBub3QgTDRTLXNwZWNpZmljLCBhbHRobyB0aGVyZSBhcmUg bm8gb3RoZXIgZXhhbXBsZXMgYXQgdGhlIG1vbWVudCB3aGVyZSB0aGlzIG9wcG9ydHVuaXR5IGlz IHBvc3NpYmxlIChzbyBpbiB0aGF0IHNlbnNlIGl0IGlzDQo8aT5jdXJyZW50bHk8L2k+IEw0Uy1z cGVjaWZpYykuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIG1lc3NhZ2UgaGFzIHRvIGJlIGhhbmRsZWQg cmVhbGx5IGNhcmVmdWxseSwgYmVjYXVzZSB0aGUgb3Bwb3J0dW5pdGllcyBmb3IgbWlzdW5kZXJz dGFuZGluZyBhcmUgZW5vcm1vdXMgKGFzIGV2aWRlbmNlZCBieSB0aGlzIHRocmVhZCwgYW5kIHdl IGhhdmVuJ3QgZXZlbiBzdGFydGVkIHRhbGtpbmcgdG8gbm9uLXRyYW5zcG9ydCBwZW9wbGUgeWV0 KS48YnI+DQo8YnI+DQpTbyBHb3JyeSBhbmQgRGF2aWQgQiB3YW50IG1lIHRvIGRyYWZ0IGEgc2hv cnQgSS1EIHRoYXQgdGhleSB3aWxsIHdvcmQtc21pdGggYW5kIGF1dGhvciBhcyB0c3Z3ZyBjaGFp cnMgdG8gbWFrZSB0aGUgc2l0dWF0aW9uIGNsZWFyLjxicj4NCjxicj4NCkkgaGF2ZSBzYWlkIEkg ZG9uJ3Qgd2FudCB0aGlzIGRpc2N1c3Npb24gdG8gYmUgb2ZmaWNpYWxseSByYWlzZWQgb3V0c2lk ZSB0aGUgdHJhbnNwb3J0IGFyZWEgdW50aWwgd2UgYXJlIHN1cmUgdGhhdCBhIHZhcmlhbnQgb2Yg UkFDSyBpcyBldmVuIGZlYXNpYmxlIHdpdGhvdXQgYW55IHBhY2tldCBjb3VudGluZyBhdCBhbGwg KGkuZS4gd2l0aG91dCB0aGUgaW5pdGlhbCAzLUR1cEFDSyBydWxlIGluIGN1cnJlbnQgUkFDSyku IFNvIEknbGwgcHJpb3JpdGl6ZQ0KIHdvcmtpbmcgdGhhdCBvdXQgZm9yIHRoZSBuZXh0IHdlZWsg b3Igc28sIHJhdGhlciB0aGFuIGRyYWZ0aW5nIGFueXRoaW5nLjxicj4NCjxicj4NCjxicj4NCjxi cj4NCkJvYjxicj4NCjxicj4NCntOb3RlIDF9OiBJIGhhZG4ndCBjb25zaWRlcmVkIHRoYXQgdGhp cyB3b3VsZCBhZmZlY3QgdGVjaG5vbG9naWVzIGxpa2UgRUNNUCB0aGF0IG1haW50YWluIG9yZGVy IHdpdGhvdXQgYSByZXNlcXVlbmNpbmcgYnVmZmVyIGFuZCB3aXRob3V0IGludHJvZHVjaW5nIEhv TCBibG9ja2luZy4gQnV0IGFjdHVhbGx5LCB0aGUgY29uc2VxdWVuY2UgdGhlcmUgd291bGQgYmUg dGhhdCBMNFMgdHJhZmZpYyBjb3VsZCBiZSBzcHJheWVkIGJ5IEVDTVAgd2l0aG91dA0KIHBlci1m bG93IGhhc2hpbmcuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+TWljaGFlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29l IFs8YSBocmVmPSJtYWlsdG86aW5AYm9iYnJpc2NvZS5uZXQiPm1haWx0bzppbkBib2JicmlzY29l Lm5ldDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IDY6 NDIgQU08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbDsgPGEgaHJlZj0ibWFpbHRvOnRj cG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt YWlsdG86dHN2d2dAaWV0Zi5vcmciPnRzdndnQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAmcXVvdDtMNFMgYW5kIFJB Q0smcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk1pY2hhZWwsPGJyPg0KPGJyPg0KVGhhdCBpcyB0 aGUgcG9pbnQgSSB0aG91Z2h0IHlvdSB3ZXJlIG1ha2luZywgYW5kIG15IHBvaW50IC9pcy8gYWJv dXQgdGhhdC48YnI+DQo8YnI+DQpJZiBhbiBhcHBsaWNhdGlvbiBuZWVkcyBhbGwgdGhlIHBhY2tl dHMgKGkuZS4gYSByZWxpYWJsZSBwcm90b2NvbCksIGl0J3Mgbm90IHVzZWZ1bCB0byByZWR1Y2Ug dGhlIGxhdGVuY3kgb2Ygc29tZSBwYWNrZXRzIGJ1dCBub3QgYWxsLiBUaGF0J3Mgd2hlcmUgdGhl IGluLW9yZGVyIHJlcXVpcmVtZW50IGNvbWVzIGZyb20uPGJyPg0KPGJyPg0KSG93ZXZlciwgaWYg YSBzdHJlYW0tYmFzZWQgdHJhbnNwb3J0IGlzIHVzZWQgKGkuZS4gVENQKSB0aGUgL2FwcGxpY2F0 aW9uLyBzdGlsbCBnZXRzIGluLW9yZGVyIGRlbGl2ZXJ5IGZyb20gVENQLiBJdCBqdXN0IGRvZXNu J3QgaGF2ZSB0byByZXF1aXJlIGxpbmtzIHRvIHByb3ZpZGUgaW4gb3JkZXIgZGVsaXZlcnkgYXMg d2VsbC48YnI+DQo8YnI+DQpOb3RlIHRoYXQgdGhlcmUgY2FuIGJlIG11bHRpcGxlIGZsb3dzIG92 ZXIgb25lIGxpbmsuIFNvICdpbi1vcmRlciBkZWxpdmVyeScgZm9yIGEgbGluayBkb2VzIG5vdCBt ZWFuIGluIG9yZGVyIG9mIFRDUCBzZXF1ZW5jZSBudW1iZXIuIEl0IG1lYW5zICdkZWxpdmVyZWQg aW4gdGhlIG9yZGVyIHRoYXQgcGFja2V0cyBhcnJpdmVkIGF0IHRoZSBsaW5rJyAodGhlIGxpbmsg aW5ncmVzcyBhZGRzIGl0cyBvd24gc2VxdWVuY2UgbnVtYmVycywgYW5kIHRoZQ0KIGxpbmsgZWdy ZXNzIGJ1ZmZlcnMgdGhlbSB1bnRpbCBpdCBjYW4gc2VuZCBvdXQgaW4gdGhlIHNhbWUgb3JkZXIs IG9yIHVudGlsIGEgdGltZS1vdXQgb3IgbWF4IG5vLiBvZiBsaW5rIHJldHJhbnNtaXNzaW9ucyku PGJyPg0KPGJyPg0KU28sIGlmIHRoZSBsaW5rIGxvc2VzIGEgcGFja2V0IGZyb20gZmxvdyBBICh0 aGUgbGluayBpc24ndCBhd2FyZSBvZiBtaWNyb2Zsb3dzLCBJJ20ganVzdCBzYXlpbmcgdGhlIHBh Y2tldCBoYXBwZW5zIHRvIGJlIGZyb20gZmxvdyBBKSwgbGluay1sYXllciBpbi1vcmRlciBkZWxp dmVyeSB3aWxsIGhvbGQgYmFjayBhbGwgcGFja2V0cyBzZW50IGFmdGVyIHRoYXQgcGFja2V0IChm cm9tIGFsbCBmbG93cywgbm90IGp1c3QgZmxvdyBBKSB1bnRpbCB0aGUNCiBsaW5rIHJlcGFpcnMg dGhlIGdhcCBvciBnaXZlcyB1cC4gPGJyPg0KPGJyPg0KU28gaG9wLWJ5LWhvcCBpbi1vcmRlciBk ZWxpdmVyeSBnaXZlcyBldmVyeSBmbG93IHRoZSBzYW1lIGRlbGF5IGFzIHRoZSB3b3JzdCBkZWxh eWVkIGZsb3cuPGJyPg0KPGJyPg0KT2YgY291cnNlLCBzb21lb25lIGJ1aWxkaW5nIGEgbmV0d29y ayBmb3IgREVUTkVUIHdvdWxkIGF2b2lkIGxpbmsgdGVjaG5vbG9naWVzIGxpa2UgV2lGaSBvciBM VEUgdGhhdCBmcmVxdWVudGx5IGxvc2UgYW5kIHJldHJhbnNtaXQgcGFja2V0cy4gQnV0IHdoZXJl dmVyIHRoZXJlIGlzIHZhcmlhYmxlIGRlbGF5IGluIGEgbGluaywgZ3VhcmFudGVlZCBpbi1vcmRl ciBkZWxpdmVyeSBwZXItaG9wIG1lYW5zIGV2ZXJ5IGZsb3cgaXMgZ3VhcmFudGVlZA0KIHRvIGFs d2F5cyBnZXQgdGhlIHdvcnN0IGRlbGF5IGZyb20gZXZlcnkgbGluaywgd2hpY2ggd291bGQgaGF2 ZSBiZWVuIGV4cGVyaWVuY2VkIGJ5IG9ubHkgb25lIGZsb3cgd2l0aG91dCBwZXItaG9wIGluLW9y ZGVyIGRlbGl2ZXJ5Lg0KPGJyPg0KPGJyPg0KQW5kIG1hbnkgb2YgdGhlIGFwcGxpY2F0aW9ucyBv ZiBERVRORVQgaW52b2x2ZSBkdW1iIGluZHVzdHJpYWwgbWFjaGluZXJ5IHRoYXQganVzdCBleHBl Y3RzIGV2ZXJ5dGhpbmcgdG8gYXJyaXZlIGluIG9yZGVyIGFuZCB0byBhIGNsb2NrZWQgc2NoZWR1 bGUuIEJ1dCBpdCdzIGFsd2F5cyBhcyBlZmZlY3RpdmUgdG8gZGVwbG95IGEgcmVzZXF1ZW5jaW5n IGJ1ZmZlciBhcyB0aGUgcGVudWx0aW1hdGUgaG9wLCBzY3Jld2VkIG9udG8gdGhlIHJlY2Vpdmlu Zw0KIG1hY2hpbmUgaWYgbmVjZXNzYXJ5LCByYXRoZXIgdGhhbiByZXF1aXJlIHBlci1ob3AgcmVz ZXF1ZW5jaW5nIGluIHRoZSBuZXR3b3JrLjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX188YnI+ DQpTbywgd2h5IGRvIEludGVybmV0IGxpbmtzIG9mdGVuIGVuc3VyZSBpbi1vcmRlciBkZWxpdmVy eSBldmVuIHRob3VnaCBUQ1AgcHV0cyBldmVyeXRoaW5nIGluIG9yZGVyIGZvciB0aGUgYXBwbGlj YXRpb24/DQo8YnI+DQo8YnI+DQpTaG9ydCBhbnN3ZXI6IHRoZSAzIER1cEFDSyBydWxlICh3aGlj aCBpcyB0byBkbyB3aXRoIGxvc3MtcmVjb3ZlcnksIGEgZGlmZmVyZW50IGlzc3VlIGZyb20gdGhl IGRpc2N1c3Npb24gYWJvdmUpLjxicj4NCjxicj4NCkxvbmcgYW5zd2VyOiBBcyBmbG93IHJhdGVz IGhhdmUgc2NhbGVkIHVwLCB0aGUgdHlwaWNhbCB0aW1lIGJldHdlZW4gMyBwYWNrZXQgYXJyaXZh bHMgaGFzIGJlY29tZSBzbyBzbWFsbCB0aGF0IFRDUCdzIDMtRHVwQUNLIHJ1bGUgbWFrZXMgbGlu a3MgaGF2ZSB0byBwcm92aWRlIGRlbGl2ZXJ5IHdpdGggb25seSBhIHZlcnkgc21hbGwgcmUtb3Jk ZXJpbmcgZGVncmVlIC0gc28gc21hbGwgdGhhdCBpdCdzIGVhc2llciBmb3IgYSBsaW5rIHRvIGp1 c3QNCiBkZWxpdmVyIGV2ZXJ5dGhpbmcgaW4gdGhlIG9yZGVyIGl0IHJlY2VpdmVkIGl0OyBub3Qg YmVjYXVzZSBUQ1AgZG9lc24ndCBwdXQgcGFja2V0cyBiYWNrIGluIG9yZGVyLCBidXQganVzdCBz byBhcyBub3QgdG8gdHJpZ2dlciBUQ1AgaW50byBnZW5lcmF0aW5nIHNwdXJpb3VzIHJldHJhbnNt aXNzaW9ucy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpCb2I8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwOC8xMS8yMDE4IDE2OjM1LCBTY2hhcmYsIE1pY2hh ZWwgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklubGluZSBbbXNdPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPiBCb2IgQnJpc2NvZSBbPGEgaHJlZj0ibWFpbHRvOmluQGJvYmJy aXNjb2UubmV0Ij5tYWlsdG86aW5AYm9iYnJpc2NvZS5uZXQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBOb3ZlbWJlciA4LCAyMDE4IDEyOjU2IFBNPGJyPg0KPGI+VG86PC9iPiBT Y2hhcmYsIE1pY2hhZWw7IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGlldGYu b3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRzdndnQGlldGYub3JnIj50 c3Z3Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gQ3Jvc3Mt YXJlYSBhbGlnbm1lbnQgb24gJnF1b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5NaWNoYWVsLDxicj4NCjxicj4NClRoaXMgaXMgbWVyZWx5IGEgc3ltcHRvbSBvZiBhIGRp ZmZlcmVuY2UgaW4gb3BpbmlvbiBvbiB3aGVyZSB0aGUgcmVzZXF1ZW5jaW5nIGZ1bmN0aW9uIHNo b3VsZCBiZSBsb2NhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNSBsZXZlbDEgbGZvNCI+DQpMNFMgdGFrZXMgdGhl IGVuZC10by1lbmQgYXBwcm9hY2ggc2F5aW5nIHRoYXQgaXQgaXMgc3VmZmljaWVudCB0byBkbyBy ZXNlcXVlbmNpbmcgaW4gb25lIHBsYWNlICh0aGUgcmVjZWl2aW5nIGhvc3QpIGlmIGl0IGlzIG5l ZWRlZC4gVGhlbiBhbnkgcmVzZXF1ZW5jaW5nIGRlbGF5IG9ubHkgYWZmZWN0cyB0aGF0IGZsb3cu PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDUgbGV2ZWwx IGxmbzQiPg0KVGhlIERFVE5FVCBhcHByb2FjaCBpcyBzYXlpbmcgdGhlIHJlc2VxdWVuY2luZyBt dXN0IGJlIGRvbmUgaG9wLWJ5LWhvcC4gVGhpcyBtZWFucyB0aGVyZSBhcHBlYXJzIHRvIGJlIG5v IHJlc2VxdWVuY2luZyBuZWVkZWQgb24gdGhlIHJlY2VpdmVyIChleGNlcHQgaWYgdGhlcmUncyBy ZS1vcmRlcmluZyBvbiB0aGUgZmluYWwgaG9wKS4NCjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm83Ij4NCkluIG9y ZGVyIHRvIGd1YXJhbnRlZSBubyByZXNlcXVlbmNpbmcgaW4gdGhlIG5ldHdvcmsgKERFVE5FVCBh cHByb2FjaCksIG9ubHkgdGhlIHRoZSB3b3JzdCBjYXNlIGxhdGVuY3kgY2FuIGJlIGd1YXJhbnRl ZWQsIGFuZCBldmVyeSBwYWNrZXQgaGFzIHRvIGhhdmUgdGhhdCBzYW1lIHdvcnN0LWNhc2UgbGF0 ZW5jeS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBs ZXZlbDEgbGZvNyI+DQpXaGVuIHlvdSBsZWF2ZSByZXNlcXVlbmNpbmcgdG8gdGhlIHJlY2VpdmVy IChlbmQtdG8tZW5kIGFwcHJvYWNoKSwgbW9zdCBvZiB0aGUgcGFja2V0cyBhcnJpdmUgZWFybGll ciB0aGFuIHRoZXkgd291bGQgd2l0aCBERVRORVQsIGJ1dCBvdXQgb2Ygb3JkZXIgb25lcyBtaWdo dCBub3QuIFRoZW4gdGhlIGFwcGxpY2F0aW9uIGNob29zZXMgd2hldGhlciBpdCB3YW50cyB0byB3 YWl0LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlttc10gTXkgcG9pbnQgaXMgZGlmZmVyZW50OiBUaGVyZSBzZWVtIHRvIGJlIG90aGVyIHdv cmtpbmcgZ3JvdXBzIGluIHRoZSBJRVRGIHRoYXQgZG8gdGFsayBhYm91dCDigJxsb3cgbGF0ZW5j eeKAnSBhcyB3ZWxsIGJ1dCBhcHBhcmVudGx5IHRoZXkgYWxzbyBkbyBuZWVkIGluLW9yZGVyIGRl bGl2ZXJ5DQogb2YgcGFja2V0cywgdG9vLiBTbyB0aGUgYXNzdW1wdGlvbiB0aGF0IGUuZy4gYSBs aW5rIGxheWVyIHRlY2hub2xvZ3kgY2FuIHNpbXBseSBkaXNhYmxlIGluLW9yZGVyIGRlbGl2ZXJ5 IGZvciBhbGwg4oCcbG93IGxhdGVuY3nigJ0gYXBwbGljYXRpb25zIHNlZW1zIG5vdCBjb3JyZWN0 LiBUaGUgcmVhbGl0eSBtYXkgYmUgYSBiaXQgbW9yZSBjb21wbGV4Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSAzIER1cEFDSyBydWxlIGluIFRDUCBsZWQgdGhlIEludGVy bmV0IG5vdCB0byBmb2xsb3cgdGhlIGVuZC10by1lbmQgcHJpbmNpcGxlIG9uIHJlLXNlcXVlbmNp bmcuDQo8L3NwYW4+Tm93IHdlJ3JlIHJlbW92aW5nIHRoZSAzIER1cEFDSyBydWxlLCB3ZSBjYW4g dGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGUyZSBwcmluY2lwbGUuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W21zXSBGb3IgVENQ LCB0aHJlZSBEdXBBQ0tTIGFyZSBhIFNIT1VMRCBpbiBSRkMgNTY4MSBhbmQgUkZDIDU2ODEgaXMg c3RhbmRhcmRzIHRyYWNrLiBTbyB0aGUgYmFyIGZvciDigJxyZW1vdmluZ+KAnSB0aGF0DQogcnVs ZSBmb3IgVENQIGlzIG5vdCBsb3figKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W21zXSBBbHNvLCB0aGUgZW5k LXRvLWVuZCBwcmluY2lwbGUgY29tZXMgd2l0aCB0cmFkZW9mZnMuIEZvciBpbnN0YW5jZSwgcmVs eWluZyBvbiB0aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUgZm9yIHJlY292ZXJ5DQogb2YgYml0IGVy cm9ycyBpcyBub3QgZWZmaWNpZW50LiBGb3IgaW4tb3JkZXIgZGVsaXZlcnkgdGhlcmUgYXJlIHRy YWRlb2ZmcyBhcyB3ZWxsLCBzZWUgZS5nLiBTZWN0aW9uIDQgaW4gZHJhZnQtaWV0Zi10Y3BtLXJh Y2stMDQuIFRoZXJlIG1heSBiZSBubyBmcmVlIGx1bmNoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPk9mIGNvdXJzZSwgYW4gYXBwbGljYXRpb24gbWlnaHQgY2hvb3NlIHRvIHVz ZSBUQ1AgYW5kIEw0UywgcmF0aGVyIHRoYW4gVURQIGFuZCBMNFMgKGUuZyBRVUlDKS4NCjwvc3Bh bj5UaGVuIHRoZXJlIGNvdWxkIHN0aWxsIGJlIEhvTCBibG9ja2luZyBpbiB0aGUgcmVjZWl2aW5n IFRDUCBzdGFjay4gQnV0IGF0IGxlYXN0IHRoZXJlJ3Mgbm8gSG9MIGJsb2NraW5nIGluIHRoZSBu ZXR3b3JrLCBhbmQgdGhlIGFwcCBjYW4gY2hvb3NlIGJldHdlZW4gc3RyZWFtIChUQ1ApIG9yIGRh dGFncmFtIChVRFApLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlttc10gSWYgTFJPL0dSTyBpbiB0aGUgcmVjZWl2aW5nIFRD UCBzdGFjayBnZXRzIG1lc3NlZCB1cCwgSSBmYWlsIHRvIHNlZSB0aGUgYmVuZWZpdCAoc2VlIGRy YWZ0LWlldGYtdGNwbS1yYWNrLTA0KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPGJyPg0KQm9iPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA2LzExLzIwMTggMTk6MjAsIFNjaGFy ZiwgTWljaGFlbCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkEgY29tbWVu dCBvbiB0aGUgVENQTSBwcmVzZW50YXRpb24gJnF1b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7OjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGZhciBh cyBJIHVuZGVyc3RhbmQsIHRoZSBERVRORVQgV0cgaW4gUlRHIGFyZWEgaGFzIHF1aXRlIHNvbWUg dXNlcyBjYXNlcyBmb3IgdWx0cmEtbG93IGxhdGVuY3kgdHJhbnNwb3J0IC0gaW4gcGFydGljdWxh ciBhbHNvIHdpdGggYm91bmRlZCBqaXR0ZXIuIEFuZCBzb21lIG9mIHRoZXNlIGFwcGxpY2F0aW9u cyAoZS5nLiB1c2luZyBVRFApIGFwcGFyZW50bHkgbWF5IG5vdCBiZSBhYmxlIHRvIHRvbGVyYXRl ICphbnkqIG91dC1vZi1vcmRlciBwYWNrZXQgZGVsaXZlcnkuPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+U28gcGVyaGFwcyBzb21lIGNyb3NzLWFy ZWEgYWxpZ25tZW50IG9uIHVsdGEtbG93LWxhdGVuY3kgYXBwbGljYXRpb24gcmVxdWlyZW1lbnRz IHdvdWxkIGJlIHVzZWZ1bD88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5NaWNoYWVsPG86cD48L286cD48L3ByZT4NCjxwcmU+KHdobyByZWNlbnRs eSBoYWQgdG8gcmV2aWV3IGRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZSk8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv bzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQv PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+Qm9iIEJy aXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0cDovL2Jv YmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48 L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlzY29lJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29l Lm5ldC88L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2D1536B3rznt8114rzntrzd_-- From nobody Fri Nov 9 10:04:03 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD0712EB11; Fri, 9 Nov 2018 10:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QI9eUURed7AB; Fri, 9 Nov 2018 10:03:50 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF128128CE4; Fri, 9 Nov 2018 10:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iIGuFUxJPq7CO3VNCaUDJYSrhtl+yVfB2LVF4ffHnKk=; b=ab0QkWNUx3eqSqT9ZPeXzCDot 0xUq0yYPbMkAXbQ3MVcFS0OiFVngrr55gzhrcqBN/J2N9jgVcg44cYK2/Uw2CY8QYML3QtiIRS4xv S6rw6gT5PxANJc8AYt5DLiaH0M6sdh5vLDiUxrWapTrcgXT2l8jIsRICr/HNk2HmAUE6OT6+2gnvP 0VmyLpHnoliOfg9t8vluBrYtyGyqDFusUFPSLKEAwfgTDY4R5uB8eDD3MWp0MHmsdDudXWtQQANVT 7jzaR0680m1QdIBqs9cGtXFVTb4D9LzSZw7DfhvxEDPkwC+5cXqFuYEmJVyUcVJx/sRxBW3uBy96J gOgOMmASA==; Received: from ppp-171-96-190-43.revip8.asianet.co.th ([171.96.190.43]:54844 helo=[192.168.1.48]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gLB8F-0003hR-Cb; Fri, 09 Nov 2018 18:03:48 +0000 To: "Scharf, Michael" , "tcpm@ietf.org" Cc: "tsvwg@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: Date: Fri, 9 Nov 2018 18:03:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------F2AEB342E3E00FC65BCD3115" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 18:03:55 -0000 This is a multi-part message in MIME format. --------------F2AEB342E3E00FC65BCD3115 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael, Please address the scaling rationale in the appendix for why it does matter how a sender realizes this internally. The list of access links types I mentioned are rarely connected directly to routers. Bob On 09/11/2018 17:44, Scharf, Michael wrote: > > I’ll not comment on link technology implementation, scheduler and > queue design assumptions in Appendix A.1.7 of > draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area may be more > familiar with the implications of internal designs e.g. inside a > router. IMHO the best way to get routing experts into the loop before > further discussing what is currently listed in Appendix A.1.7. > > Thus, I limit my response to the actual wording in the main part of > draft-ietf-tsvwg-ecn-l4s-id-05: > >     o  A scalable congestion control MUST detect loss by counting in > >       units of time, which is scalable, and MUST NOT count in units of > >       packets (as in the 3 DupACK rule of traditional TCP), which is not > >       scalable (see Appendix A.1.7 > for > rationale). > > As individual contributor, I disagree with this requirement. I would > probably be OK with a wording that a TCP sender must be able to > tolerate reordering beyond 3 Duplicate ACKs. I believe it does not > matter how a sender realizes this internally. > > And if that requirement is not just removed, I believe the wording > “traditional TCP” has to be replaced by “standard TCP”. > > BTW, also, in the rest of the document there has to be a clear > distinction between experiments and standards. History tells us that > some experiments can evolve into standards track specifications, while > other experiments may fail. And there is no way of knowing that in > advance. > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 11:08 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > On 09/11/2018 06:21, Scharf, Michael wrote: > > I don’t see the fundamental difference between a link technology > that guarantees in-order delivery within a flow (say by flow > hashing, see ECMP) vs. some link scheme that guarantees in-order > delivery, say, only for some fraction of the traffic characterized > by some other means (say, other header bits). > > [The "other means" and "other bits" wording is pretty ambiguous here. > I reckon I can guess what you mean but then I don't know why you're > saying this, 'cos I don't think I've disagreed with you on this. So > perhaps you could be more specific and we might be able to see why > you've brought this up.] > > Also I wasn't really talking about all "link technology that > guarantees in-order delivery within a flow". {Note 1} I was talking > about link technology where all flows are blocked while waiting to get > the aggregate back in order that it was in when it arrived. I > specifically said: > > Note that there can be multiple flows over one link. So 'in-order > delivery' for a link does not mean in order of TCP sequence number. It > means 'delivered in the order that packets arrived at the link' (the > link ingress adds its own sequence numbers, and the link egress > buffers them until it can send out in the same order, or until a > time-out or max no. of link retransmissions). > > For example: > > * A packet resequencing buffer after allowing for link-layer > retransmissions is common for radio link technologies such as LTE > (PDCP layer) and 802.11 WiFi. > * A packet resequencing buffer after merging multiple bonded link > channels is common for other access link technologies such as > downstream DOCSIS bonded channels. > > > > Clearly, reordering is a problem that needs to be discussed in the > IETF as a whole. And we could discuss whether a revision of RFC 3366 > is needed. > > No. There is no proposal to alter general guidance for all links like > RFC 3366. No-one is saying this. > > There is not even a proposal to require or even recommend that > L4S-specific links do anything. > > The specific proposal is to require L4S /sources/ to use a RACK-like > scheme, as a condition for setting the ECT(1) codepoint. See the last > bullet in S.4.3 of draft-ietf-tsvwg-ecn-l4s-id-05 > . > > This says nothing about what L4S links MUST, SHOULD or MAY do. It just > gives an L4S link an opportunity not to have to do resequencing. > > > But I am not convinced that this topic has to be tied into an > experiment such as L4S. > > It is an opportunity that currently only applies to L4S. > > L4S is merely an example of a case where we can mandate that there > will be no non-RACK traffic in a link, which creates an opportunity > for those who are implementing the L4S DualQ Coupled AQM to ignore the > RFC3366 resequencing advice for the L4S queue (but we are not changing > the advice, because L4S is only an experiment). The prize is to remove > the head-of-line blocking problem for their users. > > This is not L4S-specific, altho there are no other examples at the > moment where this opportunity is possible (so in that sense it is > /currently/ L4S-specific). > > > The message has to be handled really carefully, because the > opportunities for misunderstanding are enormous (as evidenced by this > thread, and we haven't even started talking to non-transport people yet). > > So Gorry and David B want me to draft a short I-D that they will > word-smith and author as tsvwg chairs to make the situation clear. > > I have said I don't want this discussion to be officially raised > outside the transport area until we are sure that a variant of RACK is > even feasible without any packet counting at all (i.e. without the > initial 3-DupACK rule in current RACK). So I'll prioritize working > that out for the next week or so, rather than drafting anything. > > > > Bob > > {Note 1}: I hadn't considered that this would affect technologies like > ECMP that maintain order without a resequencing buffer and without > introducing HoL blocking. But actually, the consequence there would be > that L4S traffic could be sprayed by ECMP without per-flow hashing. > > > Michael > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 6:42 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > That is the point I thought you were making, and my point /is/ about that. > > If an application needs all the packets (i.e. a reliable protocol), > it's not useful to reduce the latency of some packets but not all. > That's where the in-order requirement comes from. > > However, if a stream-based transport is used (i.e. TCP) the > /application/ still gets in-order delivery from TCP. It just doesn't > have to require links to provide in order delivery as well. > > Note that there can be multiple flows over one link. So 'in-order > delivery' for a link does not mean in order of TCP sequence number. It > means 'delivered in the order that packets arrived at the link' (the > link ingress adds its own sequence numbers, and the link egress > buffers them until it can send out in the same order, or until a > time-out or max no. of link retransmissions). > > So, if the link loses a packet from flow A (the link isn't aware of > microflows, I'm just saying the packet happens to be from flow A), > link-layer in-order delivery will hold back all packets sent after > that packet (from all flows, not just flow A) until the link repairs > the gap or gives up. > > So hop-by-hop in-order delivery gives every flow the same delay as the > worst delayed flow. > > Of course, someone building a network for DETNET would avoid link > technologies like WiFi or LTE that frequently lose and retransmit > packets. But wherever there is variable delay in a link, guaranteed > in-order delivery per-hop means every flow is guaranteed to always get > the worst delay from every link, which would have been experienced by > only one flow without per-hop in-order delivery. > > And many of the applications of DETNET involve dumb industrial > machinery that just expects everything to arrive in order and to a > clocked schedule. But it's always as effective to deploy a > resequencing buffer as the penultimate hop, screwed onto the receiving > machine if necessary, rather than require per-hop resequencing in the > network. > > ________________ > So, why do Internet links often ensure in-order delivery even though > TCP puts everything in order for the application? > > Short answer: the 3 DupACK rule (which is to do with loss-recovery, a > different issue from the discussion above). > > Long answer: As flow rates have scaled up, the typical time between 3 > packet arrivals has become so small that TCP's 3-DupACK rule makes > links have to provide delivery with only a very small re-ordering > degree - so small that it's easier for a link to just deliver > everything in the order it received it; not because TCP doesn't put > packets back in order, but just so as not to trigger TCP into > generating spurious retransmissions. > > > > Bob > > On 08/11/2018 16:35, Scharf, Michael wrote: > > Inline [ms] > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Thursday, November 8, 2018 12:56 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > This is merely a symptom of a difference in opinion on where the > resequencing function should be located. > > * L4S takes the end-to-end approach saying that it is sufficient > to do resequencing in one place (the receiving host) if it is > needed. Then any resequencing delay only affects that flow. > * The DETNET approach is saying the resequencing must be done > hop-by-hop. This means there appears to be no resequencing > needed on the receiver (except if there's re-ordering on the > final hop). > > * In order to guarantee no resequencing in the network (DETNET > approach), only the the worst case latency can be guaranteed, > and every packet has to have that same worst-case latency. > * When you leave resequencing to the receiver (end-to-end > approach), most of the packets arrive earlier than they would > with DETNET, but out of order ones might not. Then the > application chooses whether it wants to wait. > > [ms] My point is different: There seem to be other working groups > in the IETF that do talk about “low latency” as well but > apparently they also do need in-order delivery of packets, too. So > the assumption that e.g. a link layer technology can simply > disable in-order delivery for all “low latency” applications seems > not correct. The reality may be a bit more complex. > > The 3 DupACK rule in TCP led the Internet not to follow the > end-to-end principle on re-sequencing. Now we're removing the 3 > DupACK rule, we can take advantage of the e2e principle. > > [ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 > is standards track. So the bar for “removing” that rule for TCP is > not low… > > [ms] Also, the end-to-end principle comes with tradeoffs. For > instance, relying on the end-to-end principle for recovery of bit > errors is not efficient. For in-order delivery there are tradeoffs > as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may > be no free lunch. > > Of course, an application might choose to use TCP and L4S, rather > than UDP and L4S (e.g QUIC). Then there could still be HoL > blocking in the receiving TCP stack. But at least there's no HoL > blocking in the network, and the app can choose between stream > (TCP) or datagram (UDP). > > [ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail > to see the benefit (see draft-ietf-tcpm-rack-04). > > Michael > > > Bob > > On 06/11/2018 19:20, Scharf, Michael wrote: > > A comment on the TCPM presentation "L4S and RACK": > > > > As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery. > > > > So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful? > > > > Michael > > (who recently had to review draft-ietf-detnet-architecture) > > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------F2AEB342E3E00FC65BCD3115 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael,

Please address the scaling rationale in the appendix for why it does matter how a sender realizes this internally.

The list of access links types I mentioned are rarely connected directly to routers.



Bob

On 09/11/2018 17:44, Scharf, Michael wrote:

I’ll not comment on link technology implementation, scheduler and queue design assumptions in Appendix A.1.7 of draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area may be more familiar with the implications of internal designs e.g. inside a router. IMHO the best way to get routing experts into the loop before further discussing what is currently listed in Appendix A.1.7.

 

Thus, I limit my response to the actual wording in the main part of draft-ietf-tsvwg-ecn-l4s-id-05:

 

    o  A scalable congestion control MUST detect loss by counting in

      units of time, which is scalable, and MUST NOT count in units of

      packets (as in the 3 DupACK rule of traditional TCP), which is not

      scalable (see Appendix A.1.7 for rationale).

 

As individual contributor, I disagree with this requirement. I would probably be OK with a wording that a TCP sender must be able to tolerate reordering beyond 3 Duplicate ACKs. I believe it does not matter how a sender realizes this internally.

 

And if that requirement is not just removed, I believe the wording “traditional TCP” has to be replaced by “standard TCP”.

 

BTW, also, in the rest of the document there has to be a clear distinction between experiments and standards. History tells us that some experiments can evolve into standards track specifications, while other experiments may fail. And there is no way of knowing that in advance.

 

Michael

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, November 9, 2018 11:08 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

On 09/11/2018 06:21, Scharf, Michael wrote:

I don’t see the fundamental difference between a link technology that guarantees in-order delivery within a flow (say by flow hashing, see ECMP) vs. some link scheme that guarantees in-order delivery, say, only for some fraction of the traffic characterized by some other means (say, other header bits).

[The "other means" and "other bits" wording is pretty ambiguous here. I reckon I can guess what you mean but then I don't know why you're saying this, 'cos I don't think I've disagreed with you on this. So perhaps you could be more specific and we might be able to see why you've brought this up.]

Also I wasn't really talking about all "link technology that guarantees in-order delivery within a flow". {Note 1} I was talking about link technology where all flows are blocked while waiting to get the aggregate back in order that it was in when it arrived. I specifically said:

Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

For example:

  • A packet resequencing buffer after allowing for link-layer retransmissions is common for radio link technologies such as LTE (PDCP layer) and 802.11 WiFi.
  • A packet resequencing buffer after merging multiple bonded link channels is common for other access link technologies such as downstream DOCSIS bonded channels.



 

Clearly, reordering is a problem that needs to be discussed in the IETF as a whole. And we could discuss whether a revision of RFC 3366 is needed.

No. There is no proposal to alter general guidance for all links like RFC 3366. No-one is saying this.

There is not even a proposal to require or even recommend that L4S-specific links do anything.

The specific proposal is to require L4S sources to use a RACK-like scheme, as a condition for setting the ECT(1) codepoint. See the last bullet in S.4.3 of draft-ietf-tsvwg-ecn-l4s-id-05.

This says nothing about what L4S links MUST, SHOULD or MAY do. It just gives an L4S link an opportunity not to have to do resequencing.


 

But I am not convinced that this topic has to be tied into an experiment such as L4S.

It is an opportunity that currently only applies to L4S.

L4S is merely an example of a case where we can mandate that there will be no non-RACK traffic in a link, which creates an opportunity for those who are implementing the L4S DualQ Coupled AQM to ignore the RFC3366 resequencing advice for the L4S queue (but we are not changing the advice, because L4S is only an experiment). The prize is to remove the head-of-line blocking problem for their users.

This is not L4S-specific, altho there are no other examples at the moment where this opportunity is possible (so in that sense it is currently L4S-specific).


The message has to be handled really carefully, because the opportunities for misunderstanding are enormous (as evidenced by this thread, and we haven't even started talking to non-transport people yet).

So Gorry and David B want me to draft a short I-D that they will word-smith and author as tsvwg chairs to make the situation clear.

I have said I don't want this discussion to be officially raised outside the transport area until we are sure that a variant of RACK is even feasible without any packet counting at all (i.e. without the initial 3-DupACK rule in current RACK). So I'll prioritize working that out for the next week or so, rather than drafting anything.



Bob

{Note 1}: I hadn't considered that this would affect technologies like ECMP that maintain order without a resequencing buffer and without introducing HoL blocking. But actually, the consequence there would be that L4S traffic could be sprayed by ECMP without per-flow hashing.


 

Michael

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Friday, November 9, 2018 6:42 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

That is the point I thought you were making, and my point /is/ about that.

If an application needs all the packets (i.e. a reliable protocol), it's not useful to reduce the latency of some packets but not all. That's where the in-order requirement comes from.

However, if a stream-based transport is used (i.e. TCP) the /application/ still gets in-order delivery from TCP. It just doesn't have to require links to provide in order delivery as well.

Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

So, if the link loses a packet from flow A (the link isn't aware of microflows, I'm just saying the packet happens to be from flow A), link-layer in-order delivery will hold back all packets sent after that packet (from all flows, not just flow A) until the link repairs the gap or gives up.

So hop-by-hop in-order delivery gives every flow the same delay as the worst delayed flow.

Of course, someone building a network for DETNET would avoid link technologies like WiFi or LTE that frequently lose and retransmit packets. But wherever there is variable delay in a link, guaranteed in-order delivery per-hop means every flow is guaranteed to always get the worst delay from every link, which would have been experienced by only one flow without per-hop in-order delivery.

And many of the applications of DETNET involve dumb industrial machinery that just expects everything to arrive in order and to a clocked schedule. But it's always as effective to deploy a resequencing buffer as the penultimate hop, screwed onto the receiving machine if necessary, rather than require per-hop resequencing in the network.

________________
So, why do Internet links often ensure in-order delivery even though TCP puts everything in order for the application?

Short answer: the 3 DupACK rule (which is to do with loss-recovery, a different issue from the discussion above).

Long answer: As flow rates have scaled up, the typical time between 3 packet arrivals has become so small that TCP's 3-DupACK rule makes links have to provide delivery with only a very small re-ordering degree - so small that it's easier for a link to just deliver everything in the order it received it; not because TCP doesn't put packets back in order, but just so as not to trigger TCP into generating spurious retransmissions.



Bob

On 08/11/2018 16:35, Scharf, Michael wrote:

Inline [ms]

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Thursday, November 8, 2018 12:56 PM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

This is merely a symptom of a difference in opinion on where the resequencing function should be located.

  • L4S takes the end-to-end approach saying that it is sufficient to do resequencing in one place (the receiving host) if it is needed. Then any resequencing delay only affects that flow.
  • The DETNET approach is saying the resequencing must be done hop-by-hop. This means there appears to be no resequencing needed on the receiver (except if there's re-ordering on the final hop).

 

  • In order to guarantee no resequencing in the network (DETNET approach), only the the worst case latency can be guaranteed, and every packet has to have that same worst-case latency.
  • When you leave resequencing to the receiver (end-to-end approach), most of the packets arrive earlier than they would with DETNET, but out of order ones might not. Then the application chooses whether it wants to wait.

[ms] My point is different: There seem to be other working groups in the IETF that do talk about “low latency” as well but apparently they also do need in-order delivery of packets, too. So the assumption that e.g. a link layer technology can simply disable in-order delivery for all “low latency” applications seems not correct. The reality may be a bit more complex.

The 3 DupACK rule in TCP led the Internet not to follow the end-to-end principle on re-sequencing. Now we're removing the 3 DupACK rule, we can take advantage of the e2e principle.

[ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 is standards track. So the bar for “removing” that rule for TCP is not low…

[ms] Also, the end-to-end principle comes with tradeoffs. For instance, relying on the end-to-end principle for recovery of bit errors is not efficient. For in-order delivery there are tradeoffs as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may be no free lunch.

Of course, an application might choose to use TCP and L4S, rather than UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the receiving TCP stack. But at least there's no HoL blocking in the network, and the app can choose between stream (TCP) or datagram (UDP).

[ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail to see the benefit (see draft-ietf-tcpm-rack-04).

Michael


Bob

On 06/11/2018 19:20, Scharf, Michael wrote:

A comment on the TCPM presentation "L4S and RACK":
 
As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery.
 
So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful?
 
Michael
(who recently had to review draft-ietf-detnet-architecture)
 
 





-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------F2AEB342E3E00FC65BCD3115-- From nobody Fri Nov 9 10:19:20 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A5712F1A5; Fri, 9 Nov 2018 10:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHkIbKDudH38; Fri, 9 Nov 2018 10:19:09 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68CD312D4EE; Fri, 9 Nov 2018 10:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:References:Cc:To:From:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=A1cQBHibKDSB3c4QHL/E2N+9q2oBVHDb7ijOn6sDrXQ=; b=tn3DjdDFwUMK25qtznfoHAJ0Q ckKqALTOmws2BS5oexdfkiuUErMcHMSrcCjmnJfhvf6K3/495OmGbfOG1w0cbIz3DCkejwWOBDrBt xVju3IiBYdMUz9qRhCRAnj7FI5q5yzpazggRXZ5yCgK+znY4wp5vLLm1X4aJHKVfvRdPNfvCsNe55 qeuc1xDvg2pzdhaK3SOCTubsL2kxu40WsOMCabdvFgrSVDApRWIoNvWv9y9SkW+KHaIi/auhVbINv qHVErHCYsk3axoXjPYEsFuXyUKzE1G00CnzMTmNEowLJkyJjakpWzV2NO3IA+20/8dOMpjlQtGM3b kGN7oc+pw==; Received: from ppp-171-96-190-43.revip8.asianet.co.th ([171.96.190.43]:54950 helo=[192.168.1.48]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gLBN4-00053W-Vi; Fri, 09 Nov 2018 18:19:07 +0000 From: Bob Briscoe To: "Scharf, Michael" , "tcpm@ietf.org" Cc: "tsvwg@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> Message-ID: <07172d9e-ca4c-f20a-c1d0-6b6ef617ab31@bobbriscoe.net> Date: Fri, 9 Nov 2018 18:19:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8602BBA0E0DF1CC11A42C83E" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 18:19:14 -0000 This is a multi-part message in MIME format. --------------8602BBA0E0DF1CC11A42C83E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael, On 09/11/2018 18:03, Bob Briscoe wrote: > Michael, > > Please address the scaling rationale in the appendix for why it does > matter how a sender realizes this internally. > > The list of access links types I mentioned are rarely connected > directly to routers. Correction to my own statement: Only LTE links are rarely connected to routers , WiFi are, and DOCSIS are (the CMTS). The radio link (ARQ) issue is not to do with routing. One can think of bonded links as a form of L2 multipath, and therefore broadly related to routing. But it's access link expertise that's needed here, not routing expertise, I would say. Bob > > > > Bob > > On 09/11/2018 17:44, Scharf, Michael wrote: >> >> I’ll not comment on link technology implementation, scheduler and >> queue design assumptions in Appendix A.1.7 of >> draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area may be more >> familiar with the implications of internal designs e.g. inside a >> router. IMHO the best way to get routing experts into the loop before >> further discussing what is currently listed in Appendix A.1.7. >> >> Thus, I limit my response to the actual wording in the main part of >> draft-ietf-tsvwg-ecn-l4s-id-05: >> >>     o  A scalable congestion control MUST detect loss by counting in >> >>       units of time, which is scalable, and MUST NOT count in units of >> >>       packets (as in the 3 DupACK rule of traditional TCP), which is not >> >>       scalable (see Appendix A.1.7 >> for >> rationale). >> >> As individual contributor, I disagree with this requirement. I would >> probably be OK with a wording that a TCP sender must be able to >> tolerate reordering beyond 3 Duplicate ACKs. I believe it does not >> matter how a sender realizes this internally. >> >> And if that requirement is not just removed, I believe the wording >> “traditional TCP” has to be replaced by “standard TCP”. >> >> BTW, also, in the rest of the document there has to be a clear >> distinction between experiments and standards. History tells us that >> some experiments can evolve into standards track specifications, >> while other experiments may fail. And there is no way of knowing that >> in advance. >> >> Michael >> >> *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] >> *Sent:* Friday, November 9, 2018 11:08 AM >> *To:* Scharf, Michael; tcpm@ietf.org >> *Cc:* tsvwg@ietf.org >> *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" >> >> Michael, >> >> On 09/11/2018 06:21, Scharf, Michael wrote: >> >> I don’t see the fundamental difference between a link technology >> that guarantees in-order delivery within a flow (say by flow >> hashing, see ECMP) vs. some link scheme that guarantees in-order >> delivery, say, only for some fraction of the traffic >> characterized by some other means (say, other header bits). >> >> [The "other means" and "other bits" wording is pretty ambiguous here. >> I reckon I can guess what you mean but then I don't know why you're >> saying this, 'cos I don't think I've disagreed with you on this. So >> perhaps you could be more specific and we might be able to see why >> you've brought this up.] >> >> Also I wasn't really talking about all "link technology that >> guarantees in-order delivery within a flow". {Note 1} I was talking >> about link technology where all flows are blocked while waiting to >> get the aggregate back in order that it was in when it arrived. I >> specifically said: >> >> Note that there can be multiple flows over one link. So 'in-order >> delivery' for a link does not mean in order of TCP sequence number. >> It means 'delivered in the order that packets arrived at the link' >> (the link ingress adds its own sequence numbers, and the link egress >> buffers them until it can send out in the same order, or until a >> time-out or max no. of link retransmissions). >> >> For example: >> >> * A packet resequencing buffer after allowing for link-layer >> retransmissions is common for radio link technologies such as LTE >> (PDCP layer) and 802.11 WiFi. >> * A packet resequencing buffer after merging multiple bonded link >> channels is common for other access link technologies such as >> downstream DOCSIS bonded channels. >> >> >> >> Clearly, reordering is a problem that needs to be discussed in the >> IETF as a whole. And we could discuss whether a revision of RFC 3366 >> is needed. >> >> No. There is no proposal to alter general guidance for all links like >> RFC 3366. No-one is saying this. >> >> There is not even a proposal to require or even recommend that >> L4S-specific links do anything. >> >> The specific proposal is to require L4S /sources/ to use a RACK-like >> scheme, as a condition for setting the ECT(1) codepoint. See the last >> bullet in S.4.3 of draft-ietf-tsvwg-ecn-l4s-id-05 >> . >> >> >> This says nothing about what L4S links MUST, SHOULD or MAY do. It >> just gives an L4S link an opportunity not to have to do resequencing. >> >> >> But I am not convinced that this topic has to be tied into an >> experiment such as L4S. >> >> It is an opportunity that currently only applies to L4S. >> >> L4S is merely an example of a case where we can mandate that there >> will be no non-RACK traffic in a link, which creates an opportunity >> for those who are implementing the L4S DualQ Coupled AQM to ignore >> the RFC3366 resequencing advice for the L4S queue (but we are not >> changing the advice, because L4S is only an experiment). The prize is >> to remove the head-of-line blocking problem for their users. >> >> This is not L4S-specific, altho there are no other examples at the >> moment where this opportunity is possible (so in that sense it is >> /currently/ L4S-specific). >> >> >> The message has to be handled really carefully, because the >> opportunities for misunderstanding are enormous (as evidenced by this >> thread, and we haven't even started talking to non-transport people yet). >> >> So Gorry and David B want me to draft a short I-D that they will >> word-smith and author as tsvwg chairs to make the situation clear. >> >> I have said I don't want this discussion to be officially raised >> outside the transport area until we are sure that a variant of RACK >> is even feasible without any packet counting at all (i.e. without the >> initial 3-DupACK rule in current RACK). So I'll prioritize working >> that out for the next week or so, rather than drafting anything. >> >> >> >> Bob >> >> {Note 1}: I hadn't considered that this would affect technologies >> like ECMP that maintain order without a resequencing buffer and >> without introducing HoL blocking. But actually, the consequence there >> would be that L4S traffic could be sprayed by ECMP without per-flow >> hashing. >> >> >> Michael >> >> *From:*Bob Briscoe [mailto:in@bobbriscoe.net] >> *Sent:* Friday, November 9, 2018 6:42 AM >> *To:* Scharf, Michael; tcpm@ietf.org >> *Cc:* tsvwg@ietf.org >> *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" >> >> Michael, >> >> That is the point I thought you were making, and my point /is/ about >> that. >> >> If an application needs all the packets (i.e. a reliable protocol), >> it's not useful to reduce the latency of some packets but not all. >> That's where the in-order requirement comes from. >> >> However, if a stream-based transport is used (i.e. TCP) the >> /application/ still gets in-order delivery from TCP. It just doesn't >> have to require links to provide in order delivery as well. >> >> Note that there can be multiple flows over one link. So 'in-order >> delivery' for a link does not mean in order of TCP sequence number. >> It means 'delivered in the order that packets arrived at the link' >> (the link ingress adds its own sequence numbers, and the link egress >> buffers them until it can send out in the same order, or until a >> time-out or max no. of link retransmissions). >> >> So, if the link loses a packet from flow A (the link isn't aware of >> microflows, I'm just saying the packet happens to be from flow A), >> link-layer in-order delivery will hold back all packets sent after >> that packet (from all flows, not just flow A) until the link repairs >> the gap or gives up. >> >> So hop-by-hop in-order delivery gives every flow the same delay as >> the worst delayed flow. >> >> Of course, someone building a network for DETNET would avoid link >> technologies like WiFi or LTE that frequently lose and retransmit >> packets. But wherever there is variable delay in a link, guaranteed >> in-order delivery per-hop means every flow is guaranteed to always >> get the worst delay from every link, which would have been >> experienced by only one flow without per-hop in-order delivery. >> >> And many of the applications of DETNET involve dumb industrial >> machinery that just expects everything to arrive in order and to a >> clocked schedule. But it's always as effective to deploy a >> resequencing buffer as the penultimate hop, screwed onto the >> receiving machine if necessary, rather than require per-hop >> resequencing in the network. >> >> ________________ >> So, why do Internet links often ensure in-order delivery even though >> TCP puts everything in order for the application? >> >> Short answer: the 3 DupACK rule (which is to do with loss-recovery, a >> different issue from the discussion above). >> >> Long answer: As flow rates have scaled up, the typical time between 3 >> packet arrivals has become so small that TCP's 3-DupACK rule makes >> links have to provide delivery with only a very small re-ordering >> degree - so small that it's easier for a link to just deliver >> everything in the order it received it; not because TCP doesn't put >> packets back in order, but just so as not to trigger TCP into >> generating spurious retransmissions. >> >> >> >> Bob >> >> On 08/11/2018 16:35, Scharf, Michael wrote: >> >> Inline [ms] >> >> *From:*Bob Briscoe [mailto:in@bobbriscoe.net] >> *Sent:* Thursday, November 8, 2018 12:56 PM >> *To:* Scharf, Michael; tcpm@ietf.org >> *Cc:* tsvwg@ietf.org >> *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" >> >> Michael, >> >> This is merely a symptom of a difference in opinion on where the >> resequencing function should be located. >> >> * L4S takes the end-to-end approach saying that it is >> sufficient to do resequencing in one place (the receiving >> host) if it is needed. Then any resequencing delay only >> affects that flow. >> * The DETNET approach is saying the resequencing must be done >> hop-by-hop. This means there appears to be no resequencing >> needed on the receiver (except if there's re-ordering on the >> final hop). >> >> * In order to guarantee no resequencing in the network (DETNET >> approach), only the the worst case latency can be guaranteed, >> and every packet has to have that same worst-case latency. >> * When you leave resequencing to the receiver (end-to-end >> approach), most of the packets arrive earlier than they would >> with DETNET, but out of order ones might not. Then the >> application chooses whether it wants to wait. >> >> [ms] My point is different: There seem to be other working groups >> in the IETF that do talk about “low latency” as well but >> apparently they also do need in-order delivery of packets, too. >> So the assumption that e.g. a link layer technology can simply >> disable in-order delivery for all “low latency” applications >> seems not correct. The reality may be a bit more complex. >> >> The 3 DupACK rule in TCP led the Internet not to follow the >> end-to-end principle on re-sequencing. Now we're removing the 3 >> DupACK rule, we can take advantage of the e2e principle. >> >> [ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 >> is standards track. So the bar for “removing” that rule for TCP >> is not low… >> >> [ms] Also, the end-to-end principle comes with tradeoffs. For >> instance, relying on the end-to-end principle for recovery of bit >> errors is not efficient. For in-order delivery there are >> tradeoffs as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. >> There may be no free lunch. >> >> Of course, an application might choose to use TCP and L4S, rather >> than UDP and L4S (e.g QUIC). Then there could still be HoL >> blocking in the receiving TCP stack. But at least there's no HoL >> blocking in the network, and the app can choose between stream >> (TCP) or datagram (UDP). >> >> [ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail >> to see the benefit (see draft-ietf-tcpm-rack-04). >> >> Michael >> >> >> Bob >> >> On 06/11/2018 19:20, Scharf, Michael wrote: >> >> A comment on the TCPM presentation "L4S and RACK": >> >> >> >> As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery. >> >> >> >> So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful? >> >> >> >> Michael >> >> (who recently had to review draft-ietf-detnet-architecture) >> >> >> >> >> >> >> >> >> >> -- >> >> ________________________________________________________________ >> >> Bob Briscoehttp://bobbriscoe.net/ >> >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ >> >> >> >> -- >> ________________________________________________________________ >> Bob Briscoehttp://bobbriscoe.net/ > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------8602BBA0E0DF1CC11A42C83E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael,

On 09/11/2018 18:03, Bob Briscoe wrote:
Michael,

Please address the scaling rationale in the appendix for why it does matter how a sender realizes this internally.

The list of access links types I mentioned are rarely connected directly to routers.
Correction to my own statement: Only LTE links are rarely connected to routers , WiFi are, and DOCSIS are (the CMTS).

The radio link (ARQ) issue is not to do with routing.
One can think of bonded links as a form of L2 multipath, and therefore broadly related to routing.
But it's access link expertise that's needed here, not routing expertise, I would say.


Bob




Bob

On 09/11/2018 17:44, Scharf, Michael wrote:

I’ll not comment on link technology implementation, scheduler and queue design assumptions in Appendix A.1.7 of draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area may be more familiar with the implications of internal designs e.g. inside a router. IMHO the best way to get routing experts into the loop before further discussing what is currently listed in Appendix A.1.7.

 

Thus, I limit my response to the actual wording in the main part of draft-ietf-tsvwg-ecn-l4s-id-05:

 

    o  A scalable congestion control MUST detect loss by counting in

      units of time, which is scalable, and MUST NOT count in units of

      packets (as in the 3 DupACK rule of traditional TCP), which is not

      scalable (see Appendix A.1.7 for rationale).

 

As individual contributor, I disagree with this requirement. I would probably be OK with a wording that a TCP sender must be able to tolerate reordering beyond 3 Duplicate ACKs. I believe it does not matter how a sender realizes this internally.

 

And if that requirement is not just removed, I believe the wording “traditional TCP” has to be replaced by “standard TCP”.

 

BTW, also, in the rest of the document there has to be a clear distinction between experiments and standards. History tells us that some experiments can evolve into standards track specifications, while other experiments may fail. And there is no way of knowing that in advance.

 

Michael

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, November 9, 2018 11:08 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

On 09/11/2018 06:21, Scharf, Michael wrote:

I don’t see the fundamental difference between a link technology that guarantees in-order delivery within a flow (say by flow hashing, see ECMP) vs. some link scheme that guarantees in-order delivery, say, only for some fraction of the traffic characterized by some other means (say, other header bits).

[The "other means" and "other bits" wording is pretty ambiguous here. I reckon I can guess what you mean but then I don't know why you're saying this, 'cos I don't think I've disagreed with you on this. So perhaps you could be more specific and we might be able to see why you've brought this up.]

Also I wasn't really talking about all "link technology that guarantees in-order delivery within a flow". {Note 1} I was talking about link technology where all flows are blocked while waiting to get the aggregate back in order that it was in when it arrived. I specifically said:

Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

For example:

  • A packet resequencing buffer after allowing for link-layer retransmissions is common for radio link technologies such as LTE (PDCP layer) and 802.11 WiFi.
  • A packet resequencing buffer after merging multiple bonded link channels is common for other access link technologies such as downstream DOCSIS bonded channels.



 

Clearly, reordering is a problem that needs to be discussed in the IETF as a whole. And we could discuss whether a revision of RFC 3366 is needed.

No. There is no proposal to alter general guidance for all links like RFC 3366. No-one is saying this.

There is not even a proposal to require or even recommend that L4S-specific links do anything.

The specific proposal is to require L4S sources to use a RACK-like scheme, as a condition for setting the ECT(1) codepoint. See the last bullet in S.4.3 of draft-ietf-tsvwg-ecn-l4s-id-05.

This says nothing about what L4S links MUST, SHOULD or MAY do. It just gives an L4S link an opportunity not to have to do resequencing.


 

But I am not convinced that this topic has to be tied into an experiment such as L4S.

It is an opportunity that currently only applies to L4S.

L4S is merely an example of a case where we can mandate that there will be no non-RACK traffic in a link, which creates an opportunity for those who are implementing the L4S DualQ Coupled AQM to ignore the RFC3366 resequencing advice for the L4S queue (but we are not changing the advice, because L4S is only an experiment). The prize is to remove the head-of-line blocking problem for their users.

This is not L4S-specific, altho there are no other examples at the moment where this opportunity is possible (so in that sense it is currently L4S-specific).


The message has to be handled really carefully, because the opportunities for misunderstanding are enormous (as evidenced by this thread, and we haven't even started talking to non-transport people yet).

So Gorry and David B want me to draft a short I-D that they will word-smith and author as tsvwg chairs to make the situation clear.

I have said I don't want this discussion to be officially raised outside the transport area until we are sure that a variant of RACK is even feasible without any packet counting at all (i.e. without the initial 3-DupACK rule in current RACK). So I'll prioritize working that out for the next week or so, rather than drafting anything.



Bob

{Note 1}: I hadn't considered that this would affect technologies like ECMP that maintain order without a resequencing buffer and without introducing HoL blocking. But actually, the consequence there would be that L4S traffic could be sprayed by ECMP without per-flow hashing.


 

Michael

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Friday, November 9, 2018 6:42 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

That is the point I thought you were making, and my point /is/ about that.

If an application needs all the packets (i.e. a reliable protocol), it's not useful to reduce the latency of some packets but not all. That's where the in-order requirement comes from.

However, if a stream-based transport is used (i.e. TCP) the /application/ still gets in-order delivery from TCP. It just doesn't have to require links to provide in order delivery as well.

Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

So, if the link loses a packet from flow A (the link isn't aware of microflows, I'm just saying the packet happens to be from flow A), link-layer in-order delivery will hold back all packets sent after that packet (from all flows, not just flow A) until the link repairs the gap or gives up.

So hop-by-hop in-order delivery gives every flow the same delay as the worst delayed flow.

Of course, someone building a network for DETNET would avoid link technologies like WiFi or LTE that frequently lose and retransmit packets. But wherever there is variable delay in a link, guaranteed in-order delivery per-hop means every flow is guaranteed to always get the worst delay from every link, which would have been experienced by only one flow without per-hop in-order delivery.

And many of the applications of DETNET involve dumb industrial machinery that just expects everything to arrive in order and to a clocked schedule. But it's always as effective to deploy a resequencing buffer as the penultimate hop, screwed onto the receiving machine if necessary, rather than require per-hop resequencing in the network.

________________
So, why do Internet links often ensure in-order delivery even though TCP puts everything in order for the application?

Short answer: the 3 DupACK rule (which is to do with loss-recovery, a different issue from the discussion above).

Long answer: As flow rates have scaled up, the typical time between 3 packet arrivals has become so small that TCP's 3-DupACK rule makes links have to provide delivery with only a very small re-ordering degree - so small that it's easier for a link to just deliver everything in the order it received it; not because TCP doesn't put packets back in order, but just so as not to trigger TCP into generating spurious retransmissions.



Bob

On 08/11/2018 16:35, Scharf, Michael wrote:

Inline [ms]

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Thursday, November 8, 2018 12:56 PM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

This is merely a symptom of a difference in opinion on where the resequencing function should be located.

  • L4S takes the end-to-end approach saying that it is sufficient to do resequencing in one place (the receiving host) if it is needed. Then any resequencing delay only affects that flow.
  • The DETNET approach is saying the resequencing must be done hop-by-hop. This means there appears to be no resequencing needed on the receiver (except if there's re-ordering on the final hop).

 

  • In order to guarantee no resequencing in the network (DETNET approach), only the the worst case latency can be guaranteed, and every packet has to have that same worst-case latency.
  • When you leave resequencing to the receiver (end-to-end approach), most of the packets arrive earlier than they would with DETNET, but out of order ones might not. Then the application chooses whether it wants to wait.

[ms] My point is different: There seem to be other working groups in the IETF that do talk about “low latency” as well but apparently they also do need in-order delivery of packets, too. So the assumption that e.g. a link layer technology can simply disable in-order delivery for all “low latency” applications seems not correct. The reality may be a bit more complex.

The 3 DupACK rule in TCP led the Internet not to follow the end-to-end principle on re-sequencing. Now we're removing the 3 DupACK rule, we can take advantage of the e2e principle.

[ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 is standards track. So the bar for “removing” that rule for TCP is not low…

[ms] Also, the end-to-end principle comes with tradeoffs. For instance, relying on the end-to-end principle for recovery of bit errors is not efficient. For in-order delivery there are tradeoffs as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may be no free lunch.

Of course, an application might choose to use TCP and L4S, rather than UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the receiving TCP stack. But at least there's no HoL blocking in the network, and the app can choose between stream (TCP) or datagram (UDP).

[ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail to see the benefit (see draft-ietf-tcpm-rack-04).

Michael


Bob

On 06/11/2018 19:20, Scharf, Michael wrote:

A comment on the TCPM presentation "L4S and RACK":
 
As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery.
 
So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful?
 
Michael
(who recently had to review draft-ietf-detnet-architecture)
 
 





-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------8602BBA0E0DF1CC11A42C83E-- From nobody Fri Nov 9 10:28:36 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CBD130DC0; Fri, 9 Nov 2018 10:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeU3y0fJsBaY; Fri, 9 Nov 2018 10:28:30 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0D8128CF3; Fri, 9 Nov 2018 10:28:29 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 1E70925A20; Fri, 9 Nov 2018 19:28:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1541788108; bh=j4bAmorkHjmz5ChLjO1EY1vVDScpXv3kk/k7yvTkVvw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=UIXpvCXnaTRlkl/fAZK8/kJ3mpNW3nYn3ll9pSfCAexgxtcjjmG2y6DQ+2zHSNbN7 Y84tyMJV8JTPLRbOsPH9t7cGHdhiU1PtdLn81ujey07Na5xyOebpq2KjYekWgpQFA4 ulsn5YWL0HRvpYfzMO6cCdjYfFUZOmzErEueQaz8= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VM_VIuVX9e2E; Fri, 9 Nov 2018 19:28:27 +0100 (CET) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.hs-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 9 Nov 2018 19:28:27 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.25]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0415.000; Fri, 9 Nov 2018 19:28:27 +0100 From: "Scharf, Michael" To: Bob Briscoe , "tcpm@ietf.org" CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Cross-area alignment on "L4S and RACK" Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFgBS9LuAAAnyRqAAG025AAACx04QAAaGWYAAD7CAQAAA6LeAAAIdXNA= Date: Fri, 9 Nov 2018 18:28:27 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D1537CD@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D1537CDrznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 18:28:34 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D1537CDrznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBtYXkgbWlzcyBzb21ldGhpbmcsIGJ1dCBJIHJlYWQgdGhlIG91dGNvbWUgb2YgdGhlIGFwcGVu ZGl4IGFzIGEgcmVxdWlyZW1lbnQg4oCcbXVzdCBiZSBtb3JlIHJvYnVzdCB0byByZW9yZGVyaW5n 4oCdLiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGF0IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiBk aWZmZXJlbnQgd2F5cy4NCg0KQW5kIEkgbWF5IGJlIHdyb25nLCBidXQgdGhvc2UgbGluayB0ZWNo bm9sb2dpZXMgY291bGQgYmUgd2VsbCBpbXBsZW1lbnRlZCBpbiBhIHJvdXRlciBhbmQgdGhlbiBv bmUgbmVlZHMgdG8gYW5hbHl6ZSBob3cgdGhhdCB3aG9sZSBhcmNoaXRlY3R1cmUgZml0cyBpbnRv IHRoZSBzY2hlZHVsZXIsIHF1ZXVlLCBwb2xpY2VyLCBhbmQgbGluZSBjYXJkIGhhcmR3YXJlIGRl c2lnbiBvZiBhIHJvdXRlci4gQnV0IHRoYXQgaXMgc29tZXRoaW5nIHJvdXRpbmcgcGVvcGxlIGtu b3cgYmV0dGVyIHRoYW4gbWUuIE15IHBvaW50IGlzIGp1c3QgdG8gZ2V0IHRoZSBleHBlcnRzIGlu dG8gdGhlIGxvb3AgZWFybHkuDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFp bHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDksIDIwMTgg NzowNCBQTQ0KVG86IFNjaGFyZiwgTWljaGFlbDsgdGNwbUBpZXRmLm9yZw0KQ2M6IHRzdndnQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAiTDRT IGFuZCBSQUNLIg0KDQpNaWNoYWVsLA0KDQpQbGVhc2UgYWRkcmVzcyB0aGUgc2NhbGluZyByYXRp b25hbGUgaW4gdGhlIGFwcGVuZGl4IGZvciB3aHkgaXQgZG9lcyBtYXR0ZXIgaG93IGEgc2VuZGVy IHJlYWxpemVzIHRoaXMgaW50ZXJuYWxseS4NCg0KVGhlIGxpc3Qgb2YgYWNjZXNzIGxpbmtzIHR5 cGVzIEkgbWVudGlvbmVkIGFyZSByYXJlbHkgY29ubmVjdGVkIGRpcmVjdGx5IHRvIHJvdXRlcnMu DQoNCg0KDQpCb2INCk9uIDA5LzExLzIwMTggMTc6NDQsIFNjaGFyZiwgTWljaGFlbCB3cm90ZToN CknigJlsbCBub3QgY29tbWVudCBvbiBsaW5rIHRlY2hub2xvZ3kgaW1wbGVtZW50YXRpb24sIHNj aGVkdWxlciBhbmQgcXVldWUgZGVzaWduIGFzc3VtcHRpb25zIGluIEFwcGVuZGl4IEEuMS43IG9m IGRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNS4gUGVvcGxlIGUuZy4gaW4gUlRHIGFyZWEg bWF5IGJlIG1vcmUgZmFtaWxpYXIgd2l0aCB0aGUgaW1wbGljYXRpb25zIG9mIGludGVybmFsIGRl c2lnbnMgZS5nLiBpbnNpZGUgYSByb3V0ZXIuIElNSE8gdGhlIGJlc3Qgd2F5IHRvIGdldCByb3V0 aW5nIGV4cGVydHMgaW50byB0aGUgbG9vcCBiZWZvcmUgZnVydGhlciBkaXNjdXNzaW5nIHdoYXQg aXMgY3VycmVudGx5IGxpc3RlZCBpbiBBcHBlbmRpeCBBLjEuNy4NCg0KVGh1cywgSSBsaW1pdCBt eSByZXNwb25zZSB0byB0aGUgYWN0dWFsIHdvcmRpbmcgaW4gdGhlIG1haW4gcGFydCBvZiBkcmFm dC1pZXRmLXRzdndnLWVjbi1sNHMtaWQtMDU6DQoNCiAgICBvICBBIHNjYWxhYmxlIGNvbmdlc3Rp b24gY29udHJvbCBNVVNUIGRldGVjdCBsb3NzIGJ5IGNvdW50aW5nIGluDQogICAgICB1bml0cyBv ZiB0aW1lLCB3aGljaCBpcyBzY2FsYWJsZSwgYW5kIE1VU1QgTk9UIGNvdW50IGluIHVuaXRzIG9m DQogICAgICBwYWNrZXRzIChhcyBpbiB0aGUgMyBEdXBBQ0sgcnVsZSBvZiB0cmFkaXRpb25hbCBU Q1ApLCB3aGljaCBpcyBub3QNCiAgICAgIHNjYWxhYmxlIChzZWUgQXBwZW5kaXggQS4xLjc8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNSNh cHBlbmRpeC1BLjEuNz4gZm9yIHJhdGlvbmFsZSkuDQoNCkFzIGluZGl2aWR1YWwgY29udHJpYnV0 b3IsIEkgZGlzYWdyZWUgd2l0aCB0aGlzIHJlcXVpcmVtZW50LiBJIHdvdWxkIHByb2JhYmx5IGJl IE9LIHdpdGggYSB3b3JkaW5nIHRoYXQgYSBUQ1Agc2VuZGVyIG11c3QgYmUgYWJsZSB0byB0b2xl cmF0ZSByZW9yZGVyaW5nIGJleW9uZCAzIER1cGxpY2F0ZSBBQ0tzLiBJIGJlbGlldmUgaXQgZG9l cyBub3QgbWF0dGVyIGhvdyBhIHNlbmRlciByZWFsaXplcyB0aGlzIGludGVybmFsbHkuDQoNCkFu ZCBpZiB0aGF0IHJlcXVpcmVtZW50IGlzIG5vdCBqdXN0IHJlbW92ZWQsIEkgYmVsaWV2ZSB0aGUg d29yZGluZyDigJx0cmFkaXRpb25hbCBUQ1DigJ0gaGFzIHRvIGJlIHJlcGxhY2VkIGJ5IOKAnHN0 YW5kYXJkIFRDUOKAnS4NCg0KQlRXLCBhbHNvLCBpbiB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQg dGhlcmUgaGFzIHRvIGJlIGEgY2xlYXIgZGlzdGluY3Rpb24gYmV0d2VlbiBleHBlcmltZW50cyBh bmQgc3RhbmRhcmRzLiBIaXN0b3J5IHRlbGxzIHVzIHRoYXQgc29tZSBleHBlcmltZW50cyBjYW4g ZXZvbHZlIGludG8gc3RhbmRhcmRzIHRyYWNrIHNwZWNpZmljYXRpb25zLCB3aGlsZSBvdGhlciBl eHBlcmltZW50cyBtYXkgZmFpbC4gQW5kIHRoZXJlIGlzIG5vIHdheSBvZiBrbm93aW5nIHRoYXQg aW4gYWR2YW5jZS4NCg0KTWljaGFlbA0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmlldGZA Ym9iYnJpc2NvZS5uZXRdDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDksIDIwMTggMTE6MDggQU0N ClRvOiBTY2hhcmYsIE1pY2hhZWw7IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+ DQpDYzogdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gIkw0UyBhbmQgUkFDSyINCg0KTWljaGFl bCwNCk9uIDA5LzExLzIwMTggMDY6MjEsIFNjaGFyZiwgTWljaGFlbCB3cm90ZToNCkkgZG9u4oCZ dCBzZWUgdGhlIGZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgYmV0d2VlbiBhIGxpbmsgdGVjaG5vbG9n eSB0aGF0IGd1YXJhbnRlZXMgaW4tb3JkZXIgZGVsaXZlcnkgd2l0aGluIGEgZmxvdyAoc2F5IGJ5 IGZsb3cgaGFzaGluZywgc2VlIEVDTVApIHZzLiBzb21lIGxpbmsgc2NoZW1lIHRoYXQgZ3VhcmFu dGVlcyBpbi1vcmRlciBkZWxpdmVyeSwgc2F5LCBvbmx5IGZvciBzb21lIGZyYWN0aW9uIG9mIHRo ZSB0cmFmZmljIGNoYXJhY3Rlcml6ZWQgYnkgc29tZSBvdGhlciBtZWFucyAoc2F5LCBvdGhlciBo ZWFkZXIgYml0cykuDQpbVGhlICJvdGhlciBtZWFucyIgYW5kICJvdGhlciBiaXRzIiB3b3JkaW5n IGlzIHByZXR0eSBhbWJpZ3VvdXMgaGVyZS4gSSByZWNrb24gSSBjYW4gZ3Vlc3Mgd2hhdCB5b3Ug bWVhbiBidXQgdGhlbiBJIGRvbid0IGtub3cgd2h5IHlvdSdyZSBzYXlpbmcgdGhpcywgJ2NvcyBJ IGRvbid0IHRoaW5rIEkndmUgZGlzYWdyZWVkIHdpdGggeW91IG9uIHRoaXMuIFNvIHBlcmhhcHMg eW91IGNvdWxkIGJlIG1vcmUgc3BlY2lmaWMgYW5kIHdlIG1pZ2h0IGJlIGFibGUgdG8gc2VlIHdo eSB5b3UndmUgYnJvdWdodCB0aGlzIHVwLl0NCg0KQWxzbyBJIHdhc24ndCByZWFsbHkgdGFsa2lu ZyBhYm91dCBhbGwgImxpbmsgdGVjaG5vbG9neSB0aGF0IGd1YXJhbnRlZXMgaW4tb3JkZXIgZGVs aXZlcnkgd2l0aGluIGEgZmxvdyIuIHtOb3RlIDF9IEkgd2FzIHRhbGtpbmcgYWJvdXQgbGluayB0 ZWNobm9sb2d5IHdoZXJlIGFsbCBmbG93cyBhcmUgYmxvY2tlZCB3aGlsZSB3YWl0aW5nIHRvIGdl dCB0aGUgYWdncmVnYXRlIGJhY2sgaW4gb3JkZXIgdGhhdCBpdCB3YXMgaW4gd2hlbiBpdCBhcnJp dmVkLiBJIHNwZWNpZmljYWxseSBzYWlkOg0KDQoNCk5vdGUgdGhhdCB0aGVyZSBjYW4gYmUgbXVs dGlwbGUgZmxvd3Mgb3ZlciBvbmUgbGluay4gU28gJ2luLW9yZGVyIGRlbGl2ZXJ5JyBmb3IgYSBs aW5rIGRvZXMgbm90IG1lYW4gaW4gb3JkZXIgb2YgVENQIHNlcXVlbmNlIG51bWJlci4gSXQgbWVh bnMgJ2RlbGl2ZXJlZCBpbiB0aGUgb3JkZXIgdGhhdCBwYWNrZXRzIGFycml2ZWQgYXQgdGhlIGxp bmsnICh0aGUgbGluayBpbmdyZXNzIGFkZHMgaXRzIG93biBzZXF1ZW5jZSBudW1iZXJzLCBhbmQg dGhlIGxpbmsgZWdyZXNzIGJ1ZmZlcnMgdGhlbSB1bnRpbCBpdCBjYW4gc2VuZCBvdXQgaW4gdGhl IHNhbWUgb3JkZXIsIG9yIHVudGlsIGEgdGltZS1vdXQgb3IgbWF4IG5vLiBvZiBsaW5rIHJldHJh bnNtaXNzaW9ucykuDQpGb3IgZXhhbXBsZToNCg0KICAqICAgQSBwYWNrZXQgcmVzZXF1ZW5jaW5n IGJ1ZmZlciBhZnRlciBhbGxvd2luZyBmb3IgbGluay1sYXllciByZXRyYW5zbWlzc2lvbnMgaXMg Y29tbW9uIGZvciByYWRpbyBsaW5rIHRlY2hub2xvZ2llcyBzdWNoIGFzIExURSAoUERDUCBsYXll cikgYW5kIDgwMi4xMSBXaUZpLg0KICAqICAgQSBwYWNrZXQgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBh ZnRlciBtZXJnaW5nIG11bHRpcGxlIGJvbmRlZCBsaW5rIGNoYW5uZWxzIGlzIGNvbW1vbiBmb3Ig b3RoZXIgYWNjZXNzIGxpbmsgdGVjaG5vbG9naWVzIHN1Y2ggYXMgZG93bnN0cmVhbSBET0NTSVMg Ym9uZGVkIGNoYW5uZWxzLg0KDQoNCg0KDQpDbGVhcmx5LCByZW9yZGVyaW5nIGlzIGEgcHJvYmxl bSB0aGF0IG5lZWRzIHRvIGJlIGRpc2N1c3NlZCBpbiB0aGUgSUVURiBhcyBhIHdob2xlLiBBbmQg d2UgY291bGQgZGlzY3VzcyB3aGV0aGVyIGEgcmV2aXNpb24gb2YgUkZDIDMzNjYgaXMgbmVlZGVk Lg0KTm8uIFRoZXJlIGlzIG5vIHByb3Bvc2FsIHRvIGFsdGVyIGdlbmVyYWwgZ3VpZGFuY2UgZm9y IGFsbCBsaW5rcyBsaWtlIFJGQyAzMzY2LiBOby1vbmUgaXMgc2F5aW5nIHRoaXMuDQoNClRoZXJl IGlzIG5vdCBldmVuIGEgcHJvcG9zYWwgdG8gcmVxdWlyZSBvciBldmVuIHJlY29tbWVuZCB0aGF0 IEw0Uy1zcGVjaWZpYyBsaW5rcyBkbyBhbnl0aGluZy4NCg0KVGhlIHNwZWNpZmljIHByb3Bvc2Fs IGlzIHRvIHJlcXVpcmUgTDRTIHNvdXJjZXMgdG8gdXNlIGEgUkFDSy1saWtlIHNjaGVtZSwgYXMg YSBjb25kaXRpb24gZm9yIHNldHRpbmcgdGhlIEVDVCgxKSBjb2RlcG9pbnQuIFNlZSB0aGUgbGFz dCBidWxsZXQgaW4gUy40LjMgb2YgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA1PGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQtMDUjc2Vj dGlvbi00LjM+Lg0KDQpUaGlzIHNheXMgbm90aGluZyBhYm91dCB3aGF0IEw0UyBsaW5rcyBNVVNU LCBTSE9VTEQgb3IgTUFZIGRvLiBJdCBqdXN0IGdpdmVzIGFuIEw0UyBsaW5rIGFuIG9wcG9ydHVu aXR5IG5vdCB0byBoYXZlIHRvIGRvIHJlc2VxdWVuY2luZy4NCg0KDQoNCg0KQnV0IEkgYW0gbm90 IGNvbnZpbmNlZCB0aGF0IHRoaXMgdG9waWMgaGFzIHRvIGJlIHRpZWQgaW50byBhbiBleHBlcmlt ZW50IHN1Y2ggYXMgTDRTLg0KSXQgaXMgYW4gb3Bwb3J0dW5pdHkgdGhhdCBjdXJyZW50bHkgb25s eSBhcHBsaWVzIHRvIEw0Uy4NCg0KTDRTIGlzIG1lcmVseSBhbiBleGFtcGxlIG9mIGEgY2FzZSB3 aGVyZSB3ZSBjYW4gbWFuZGF0ZSB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gbm9uLVJBQ0sgdHJhZmZp YyBpbiBhIGxpbmssIHdoaWNoIGNyZWF0ZXMgYW4gb3Bwb3J0dW5pdHkgZm9yIHRob3NlIHdobyBh cmUgaW1wbGVtZW50aW5nIHRoZSBMNFMgRHVhbFEgQ291cGxlZCBBUU0gdG8gaWdub3JlIHRoZSBS RkMzMzY2IHJlc2VxdWVuY2luZyBhZHZpY2UgZm9yIHRoZSBMNFMgcXVldWUgKGJ1dCB3ZSBhcmUg bm90IGNoYW5naW5nIHRoZSBhZHZpY2UsIGJlY2F1c2UgTDRTIGlzIG9ubHkgYW4gZXhwZXJpbWVu dCkuIFRoZSBwcml6ZSBpcyB0byByZW1vdmUgdGhlIGhlYWQtb2YtbGluZSBibG9ja2luZyBwcm9i bGVtIGZvciB0aGVpciB1c2Vycy4NCg0KVGhpcyBpcyBub3QgTDRTLXNwZWNpZmljLCBhbHRobyB0 aGVyZSBhcmUgbm8gb3RoZXIgZXhhbXBsZXMgYXQgdGhlIG1vbWVudCB3aGVyZSB0aGlzIG9wcG9y dHVuaXR5IGlzIHBvc3NpYmxlIChzbyBpbiB0aGF0IHNlbnNlIGl0IGlzIGN1cnJlbnRseSBMNFMt c3BlY2lmaWMpLg0KDQoNClRoZSBtZXNzYWdlIGhhcyB0byBiZSBoYW5kbGVkIHJlYWxseSBjYXJl ZnVsbHksIGJlY2F1c2UgdGhlIG9wcG9ydHVuaXRpZXMgZm9yIG1pc3VuZGVyc3RhbmRpbmcgYXJl IGVub3Jtb3VzIChhcyBldmlkZW5jZWQgYnkgdGhpcyB0aHJlYWQsIGFuZCB3ZSBoYXZlbid0IGV2 ZW4gc3RhcnRlZCB0YWxraW5nIHRvIG5vbi10cmFuc3BvcnQgcGVvcGxlIHlldCkuDQoNClNvIEdv cnJ5IGFuZCBEYXZpZCBCIHdhbnQgbWUgdG8gZHJhZnQgYSBzaG9ydCBJLUQgdGhhdCB0aGV5IHdp bGwgd29yZC1zbWl0aCBhbmQgYXV0aG9yIGFzIHRzdndnIGNoYWlycyB0byBtYWtlIHRoZSBzaXR1 YXRpb24gY2xlYXIuDQoNCkkgaGF2ZSBzYWlkIEkgZG9uJ3Qgd2FudCB0aGlzIGRpc2N1c3Npb24g dG8gYmUgb2ZmaWNpYWxseSByYWlzZWQgb3V0c2lkZSB0aGUgdHJhbnNwb3J0IGFyZWEgdW50aWwg d2UgYXJlIHN1cmUgdGhhdCBhIHZhcmlhbnQgb2YgUkFDSyBpcyBldmVuIGZlYXNpYmxlIHdpdGhv dXQgYW55IHBhY2tldCBjb3VudGluZyBhdCBhbGwgKGkuZS4gd2l0aG91dCB0aGUgaW5pdGlhbCAz LUR1cEFDSyBydWxlIGluIGN1cnJlbnQgUkFDSykuIFNvIEknbGwgcHJpb3JpdGl6ZSB3b3JraW5n IHRoYXQgb3V0IGZvciB0aGUgbmV4dCB3ZWVrIG9yIHNvLCByYXRoZXIgdGhhbiBkcmFmdGluZyBh bnl0aGluZy4NCg0KDQoNCkJvYg0KDQp7Tm90ZSAxfTogSSBoYWRuJ3QgY29uc2lkZXJlZCB0aGF0 IHRoaXMgd291bGQgYWZmZWN0IHRlY2hub2xvZ2llcyBsaWtlIEVDTVAgdGhhdCBtYWludGFpbiBv cmRlciB3aXRob3V0IGEgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBhbmQgd2l0aG91dCBpbnRyb2R1Y2lu ZyBIb0wgYmxvY2tpbmcuIEJ1dCBhY3R1YWxseSwgdGhlIGNvbnNlcXVlbmNlIHRoZXJlIHdvdWxk IGJlIHRoYXQgTDRTIHRyYWZmaWMgY291bGQgYmUgc3ByYXllZCBieSBFQ01QIHdpdGhvdXQgcGVy LWZsb3cgaGFzaGluZy4NCg0KDQoNCg0KTWljaGFlbA0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFp bHRvOmluQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IDY6 NDIgQU0NClRvOiBTY2hhcmYsIE1pY2hhZWw7IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0 Zi5vcmc+DQpDYzogdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gIkw0UyBhbmQgUkFDSyINCg0K TWljaGFlbCwNCg0KVGhhdCBpcyB0aGUgcG9pbnQgSSB0aG91Z2h0IHlvdSB3ZXJlIG1ha2luZywg YW5kIG15IHBvaW50IC9pcy8gYWJvdXQgdGhhdC4NCg0KSWYgYW4gYXBwbGljYXRpb24gbmVlZHMg YWxsIHRoZSBwYWNrZXRzIChpLmUuIGEgcmVsaWFibGUgcHJvdG9jb2wpLCBpdCdzIG5vdCB1c2Vm dWwgdG8gcmVkdWNlIHRoZSBsYXRlbmN5IG9mIHNvbWUgcGFja2V0cyBidXQgbm90IGFsbC4gVGhh dCdzIHdoZXJlIHRoZSBpbi1vcmRlciByZXF1aXJlbWVudCBjb21lcyBmcm9tLg0KDQpIb3dldmVy LCBpZiBhIHN0cmVhbS1iYXNlZCB0cmFuc3BvcnQgaXMgdXNlZCAoaS5lLiBUQ1ApIHRoZSAvYXBw bGljYXRpb24vIHN0aWxsIGdldHMgaW4tb3JkZXIgZGVsaXZlcnkgZnJvbSBUQ1AuIEl0IGp1c3Qg ZG9lc24ndCBoYXZlIHRvIHJlcXVpcmUgbGlua3MgdG8gcHJvdmlkZSBpbiBvcmRlciBkZWxpdmVy eSBhcyB3ZWxsLg0KDQpOb3RlIHRoYXQgdGhlcmUgY2FuIGJlIG11bHRpcGxlIGZsb3dzIG92ZXIg b25lIGxpbmsuIFNvICdpbi1vcmRlciBkZWxpdmVyeScgZm9yIGEgbGluayBkb2VzIG5vdCBtZWFu IGluIG9yZGVyIG9mIFRDUCBzZXF1ZW5jZSBudW1iZXIuIEl0IG1lYW5zICdkZWxpdmVyZWQgaW4g dGhlIG9yZGVyIHRoYXQgcGFja2V0cyBhcnJpdmVkIGF0IHRoZSBsaW5rJyAodGhlIGxpbmsgaW5n cmVzcyBhZGRzIGl0cyBvd24gc2VxdWVuY2UgbnVtYmVycywgYW5kIHRoZSBsaW5rIGVncmVzcyBi dWZmZXJzIHRoZW0gdW50aWwgaXQgY2FuIHNlbmQgb3V0IGluIHRoZSBzYW1lIG9yZGVyLCBvciB1 bnRpbCBhIHRpbWUtb3V0IG9yIG1heCBuby4gb2YgbGluayByZXRyYW5zbWlzc2lvbnMpLg0KDQpT bywgaWYgdGhlIGxpbmsgbG9zZXMgYSBwYWNrZXQgZnJvbSBmbG93IEEgKHRoZSBsaW5rIGlzbid0 IGF3YXJlIG9mIG1pY3JvZmxvd3MsIEknbSBqdXN0IHNheWluZyB0aGUgcGFja2V0IGhhcHBlbnMg dG8gYmUgZnJvbSBmbG93IEEpLCBsaW5rLWxheWVyIGluLW9yZGVyIGRlbGl2ZXJ5IHdpbGwgaG9s ZCBiYWNrIGFsbCBwYWNrZXRzIHNlbnQgYWZ0ZXIgdGhhdCBwYWNrZXQgKGZyb20gYWxsIGZsb3dz LCBub3QganVzdCBmbG93IEEpIHVudGlsIHRoZSBsaW5rIHJlcGFpcnMgdGhlIGdhcCBvciBnaXZl cyB1cC4NCg0KU28gaG9wLWJ5LWhvcCBpbi1vcmRlciBkZWxpdmVyeSBnaXZlcyBldmVyeSBmbG93 IHRoZSBzYW1lIGRlbGF5IGFzIHRoZSB3b3JzdCBkZWxheWVkIGZsb3cuDQoNCk9mIGNvdXJzZSwg c29tZW9uZSBidWlsZGluZyBhIG5ldHdvcmsgZm9yIERFVE5FVCB3b3VsZCBhdm9pZCBsaW5rIHRl Y2hub2xvZ2llcyBsaWtlIFdpRmkgb3IgTFRFIHRoYXQgZnJlcXVlbnRseSBsb3NlIGFuZCByZXRy YW5zbWl0IHBhY2tldHMuIEJ1dCB3aGVyZXZlciB0aGVyZSBpcyB2YXJpYWJsZSBkZWxheSBpbiBh IGxpbmssIGd1YXJhbnRlZWQgaW4tb3JkZXIgZGVsaXZlcnkgcGVyLWhvcCBtZWFucyBldmVyeSBm bG93IGlzIGd1YXJhbnRlZWQgdG8gYWx3YXlzIGdldCB0aGUgd29yc3QgZGVsYXkgZnJvbSBldmVy eSBsaW5rLCB3aGljaCB3b3VsZCBoYXZlIGJlZW4gZXhwZXJpZW5jZWQgYnkgb25seSBvbmUgZmxv dyB3aXRob3V0IHBlci1ob3AgaW4tb3JkZXIgZGVsaXZlcnkuDQoNCkFuZCBtYW55IG9mIHRoZSBh cHBsaWNhdGlvbnMgb2YgREVUTkVUIGludm9sdmUgZHVtYiBpbmR1c3RyaWFsIG1hY2hpbmVyeSB0 aGF0IGp1c3QgZXhwZWN0cyBldmVyeXRoaW5nIHRvIGFycml2ZSBpbiBvcmRlciBhbmQgdG8gYSBj bG9ja2VkIHNjaGVkdWxlLiBCdXQgaXQncyBhbHdheXMgYXMgZWZmZWN0aXZlIHRvIGRlcGxveSBh IHJlc2VxdWVuY2luZyBidWZmZXIgYXMgdGhlIHBlbnVsdGltYXRlIGhvcCwgc2NyZXdlZCBvbnRv IHRoZSByZWNlaXZpbmcgbWFjaGluZSBpZiBuZWNlc3NhcnksIHJhdGhlciB0aGFuIHJlcXVpcmUg cGVyLWhvcCByZXNlcXVlbmNpbmcgaW4gdGhlIG5ldHdvcmsuDQoNCl9fX19fX19fX19fX19fX18N ClNvLCB3aHkgZG8gSW50ZXJuZXQgbGlua3Mgb2Z0ZW4gZW5zdXJlIGluLW9yZGVyIGRlbGl2ZXJ5 IGV2ZW4gdGhvdWdoIFRDUCBwdXRzIGV2ZXJ5dGhpbmcgaW4gb3JkZXIgZm9yIHRoZSBhcHBsaWNh dGlvbj8NCg0KU2hvcnQgYW5zd2VyOiB0aGUgMyBEdXBBQ0sgcnVsZSAod2hpY2ggaXMgdG8gZG8g d2l0aCBsb3NzLXJlY292ZXJ5LCBhIGRpZmZlcmVudCBpc3N1ZSBmcm9tIHRoZSBkaXNjdXNzaW9u IGFib3ZlKS4NCg0KTG9uZyBhbnN3ZXI6IEFzIGZsb3cgcmF0ZXMgaGF2ZSBzY2FsZWQgdXAsIHRo ZSB0eXBpY2FsIHRpbWUgYmV0d2VlbiAzIHBhY2tldCBhcnJpdmFscyBoYXMgYmVjb21lIHNvIHNt YWxsIHRoYXQgVENQJ3MgMy1EdXBBQ0sgcnVsZSBtYWtlcyBsaW5rcyBoYXZlIHRvIHByb3ZpZGUg ZGVsaXZlcnkgd2l0aCBvbmx5IGEgdmVyeSBzbWFsbCByZS1vcmRlcmluZyBkZWdyZWUgLSBzbyBz bWFsbCB0aGF0IGl0J3MgZWFzaWVyIGZvciBhIGxpbmsgdG8ganVzdCBkZWxpdmVyIGV2ZXJ5dGhp bmcgaW4gdGhlIG9yZGVyIGl0IHJlY2VpdmVkIGl0OyBub3QgYmVjYXVzZSBUQ1AgZG9lc24ndCBw dXQgcGFja2V0cyBiYWNrIGluIG9yZGVyLCBidXQganVzdCBzbyBhcyBub3QgdG8gdHJpZ2dlciBU Q1AgaW50byBnZW5lcmF0aW5nIHNwdXJpb3VzIHJldHJhbnNtaXNzaW9ucy4NCg0KDQoNCkJvYg0K T24gMDgvMTEvMjAxOCAxNjozNSwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KSW5saW5lIFttc10N Cg0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0bzppbkBib2JicmlzY29lLm5ldF0NClNlbnQ6IFRo dXJzZGF5LCBOb3ZlbWJlciA4LCAyMDE4IDEyOjU2IFBNDQpUbzogU2NoYXJmLCBNaWNoYWVsOyB0 Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KQ2M6IHRzdndnQGlldGYub3JnPG1h aWx0bzp0c3Z3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHN2d2ddIENyb3NzLWFyZWEgYWxp Z25tZW50IG9uICJMNFMgYW5kIFJBQ0siDQoNCk1pY2hhZWwsDQoNClRoaXMgaXMgbWVyZWx5IGEg c3ltcHRvbSBvZiBhIGRpZmZlcmVuY2UgaW4gb3BpbmlvbiBvbiB3aGVyZSB0aGUgcmVzZXF1ZW5j aW5nIGZ1bmN0aW9uIHNob3VsZCBiZSBsb2NhdGVkLg0KDQogICogICBMNFMgdGFrZXMgdGhlIGVu ZC10by1lbmQgYXBwcm9hY2ggc2F5aW5nIHRoYXQgaXQgaXMgc3VmZmljaWVudCB0byBkbyByZXNl cXVlbmNpbmcgaW4gb25lIHBsYWNlICh0aGUgcmVjZWl2aW5nIGhvc3QpIGlmIGl0IGlzIG5lZWRl ZC4gVGhlbiBhbnkgcmVzZXF1ZW5jaW5nIGRlbGF5IG9ubHkgYWZmZWN0cyB0aGF0IGZsb3cuDQog ICogICBUaGUgREVUTkVUIGFwcHJvYWNoIGlzIHNheWluZyB0aGUgcmVzZXF1ZW5jaW5nIG11c3Qg YmUgZG9uZSBob3AtYnktaG9wLiBUaGlzIG1lYW5zIHRoZXJlIGFwcGVhcnMgdG8gYmUgbm8gcmVz ZXF1ZW5jaW5nIG5lZWRlZCBvbiB0aGUgcmVjZWl2ZXIgKGV4Y2VwdCBpZiB0aGVyZSdzIHJlLW9y ZGVyaW5nIG9uIHRoZSBmaW5hbCBob3ApLg0KDQoNCiAgKiAgIEluIG9yZGVyIHRvIGd1YXJhbnRl ZSBubyByZXNlcXVlbmNpbmcgaW4gdGhlIG5ldHdvcmsgKERFVE5FVCBhcHByb2FjaCksIG9ubHkg dGhlIHRoZSB3b3JzdCBjYXNlIGxhdGVuY3kgY2FuIGJlIGd1YXJhbnRlZWQsIGFuZCBldmVyeSBw YWNrZXQgaGFzIHRvIGhhdmUgdGhhdCBzYW1lIHdvcnN0LWNhc2UgbGF0ZW5jeS4NCiAgKiAgIFdo ZW4geW91IGxlYXZlIHJlc2VxdWVuY2luZyB0byB0aGUgcmVjZWl2ZXIgKGVuZC10by1lbmQgYXBw cm9hY2gpLCBtb3N0IG9mIHRoZSBwYWNrZXRzIGFycml2ZSBlYXJsaWVyIHRoYW4gdGhleSB3b3Vs ZCB3aXRoIERFVE5FVCwgYnV0IG91dCBvZiBvcmRlciBvbmVzIG1pZ2h0IG5vdC4gVGhlbiB0aGUg YXBwbGljYXRpb24gY2hvb3NlcyB3aGV0aGVyIGl0IHdhbnRzIHRvIHdhaXQuDQpbbXNdIE15IHBv aW50IGlzIGRpZmZlcmVudDogVGhlcmUgc2VlbSB0byBiZSBvdGhlciB3b3JraW5nIGdyb3VwcyBp biB0aGUgSUVURiB0aGF0IGRvIHRhbGsgYWJvdXQg4oCcbG93IGxhdGVuY3nigJ0gYXMgd2VsbCBi dXQgYXBwYXJlbnRseSB0aGV5IGFsc28gZG8gbmVlZCBpbi1vcmRlciBkZWxpdmVyeSBvZiBwYWNr ZXRzLCB0b28uIFNvIHRoZSBhc3N1bXB0aW9uIHRoYXQgZS5nLiBhIGxpbmsgbGF5ZXIgdGVjaG5v bG9neSBjYW4gc2ltcGx5IGRpc2FibGUgaW4tb3JkZXIgZGVsaXZlcnkgZm9yIGFsbCDigJxsb3cg bGF0ZW5jeeKAnSBhcHBsaWNhdGlvbnMgc2VlbXMgbm90IGNvcnJlY3QuIFRoZSByZWFsaXR5IG1h eSBiZSBhIGJpdCBtb3JlIGNvbXBsZXguDQpUaGUgMyBEdXBBQ0sgcnVsZSBpbiBUQ1AgbGVkIHRo ZSBJbnRlcm5ldCBub3QgdG8gZm9sbG93IHRoZSBlbmQtdG8tZW5kIHByaW5jaXBsZSBvbiByZS1z ZXF1ZW5jaW5nLiBOb3cgd2UncmUgcmVtb3ZpbmcgdGhlIDMgRHVwQUNLIHJ1bGUsIHdlIGNhbiB0 YWtlIGFkdmFudGFnZSBvZiB0aGUgZTJlIHByaW5jaXBsZS4NClttc10gRm9yIFRDUCwgdGhyZWUg RHVwQUNLUyBhcmUgYSBTSE9VTEQgaW4gUkZDIDU2ODEgYW5kIFJGQyA1NjgxIGlzIHN0YW5kYXJk cyB0cmFjay4gU28gdGhlIGJhciBmb3Ig4oCccmVtb3ZpbmfigJ0gdGhhdCBydWxlIGZvciBUQ1Ag aXMgbm90IGxvd+KApg0KW21zXSBBbHNvLCB0aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUgY29tZXMg d2l0aCB0cmFkZW9mZnMuIEZvciBpbnN0YW5jZSwgcmVseWluZyBvbiB0aGUgZW5kLXRvLWVuZCBw cmluY2lwbGUgZm9yIHJlY292ZXJ5IG9mIGJpdCBlcnJvcnMgaXMgbm90IGVmZmljaWVudC4gRm9y IGluLW9yZGVyIGRlbGl2ZXJ5IHRoZXJlIGFyZSB0cmFkZW9mZnMgYXMgd2VsbCwgc2VlIGUuZy4g U2VjdGlvbiA0IGluIGRyYWZ0LWlldGYtdGNwbS1yYWNrLTA0LiBUaGVyZSBtYXkgYmUgbm8gZnJl ZSBsdW5jaC4NCk9mIGNvdXJzZSwgYW4gYXBwbGljYXRpb24gbWlnaHQgY2hvb3NlIHRvIHVzZSBU Q1AgYW5kIEw0UywgcmF0aGVyIHRoYW4gVURQIGFuZCBMNFMgKGUuZyBRVUlDKS4gVGhlbiB0aGVy ZSBjb3VsZCBzdGlsbCBiZSBIb0wgYmxvY2tpbmcgaW4gdGhlIHJlY2VpdmluZyBUQ1Agc3RhY2su IEJ1dCBhdCBsZWFzdCB0aGVyZSdzIG5vIEhvTCBibG9ja2luZyBpbiB0aGUgbmV0d29yaywgYW5k IHRoZSBhcHAgY2FuIGNob29zZSBiZXR3ZWVuIHN0cmVhbSAoVENQKSBvciBkYXRhZ3JhbSAoVURQ KS4NClttc10gSWYgTFJPL0dSTyBpbiB0aGUgcmVjZWl2aW5nIFRDUCBzdGFjayBnZXRzIG1lc3Nl ZCB1cCwgSSBmYWlsIHRvIHNlZSB0aGUgYmVuZWZpdCAoc2VlIGRyYWZ0LWlldGYtdGNwbS1yYWNr LTA0KS4NCk1pY2hhZWwNCg0KDQpCb2INCk9uIDA2LzExLzIwMTggMTk6MjAsIFNjaGFyZiwgTWlj aGFlbCB3cm90ZToNCg0KQSBjb21tZW50IG9uIHRoZSBUQ1BNIHByZXNlbnRhdGlvbiAiTDRTIGFu ZCBSQUNLIjoNCg0KDQoNCkFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZSBERVRORVQgV0cgaW4g UlRHIGFyZWEgaGFzIHF1aXRlIHNvbWUgdXNlcyBjYXNlcyBmb3IgdWx0cmEtbG93IGxhdGVuY3kg dHJhbnNwb3J0IC0gaW4gcGFydGljdWxhciBhbHNvIHdpdGggYm91bmRlZCBqaXR0ZXIuIEFuZCBz b21lIG9mIHRoZXNlIGFwcGxpY2F0aW9ucyAoZS5nLiB1c2luZyBVRFApIGFwcGFyZW50bHkgbWF5 IG5vdCBiZSBhYmxlIHRvIHRvbGVyYXRlICphbnkqIG91dC1vZi1vcmRlciBwYWNrZXQgZGVsaXZl cnkuDQoNCg0KDQpTbyBwZXJoYXBzIHNvbWUgY3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gdWx0YS1s b3ctbGF0ZW5jeSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudHMgd291bGQgYmUgdXNlZnVsPw0KDQoN Cg0KTWljaGFlbA0KDQood2hvIHJlY2VudGx5IGhhZCB0byByZXZpZXcgZHJhZnQtaWV0Zi1kZXRu ZXQtYXJjaGl0ZWN0dXJlKQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJv YiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29l Lm5ldC8NCg0KDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0KDQoNCg0KLS0NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRw Oi8vYm9iYnJpc2NvZS5uZXQvDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D1537CDrznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFy Z2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MVm9yZm9ybWF0aWVydFpjaG4NCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgVm9yZm9ybWF0aWVydCBaY2huIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgVm9yZm9ybWF0aWVydCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdl MjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UyMg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMjMNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4w Y20gNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM2NzAyNjczOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMTUxOTg5NjgyMjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjI1OTkyMDM5NjsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2NTYyODczMjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxl dmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo0OTIzODAxMTc7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi00NjE1NzIwNzI7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDo1MjE0MzEyNjU7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xNDEzNDQ2NDA4O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzps ZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJ e21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjE4Nzg1NDI1MzM7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi02NzEwODY2MDg7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1pZDoyMTIxODcwNzM3Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotMTU5MzE1MDAxMjt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs NTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWw1 DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoy ODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSBtYXkgbWlzcyBzb21ldGhpbmcsIGJ1dCBJIHJlYWQgdGhlIG91dGNvbWUgb2YgdGhl IGFwcGVuZGl4IGFzIGEgcmVxdWlyZW1lbnQg4oCcbXVzdCBiZSBtb3JlIHJvYnVzdCB0byByZW9y ZGVyaW5n4oCdLiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGF0DQogY2FuIGJlIGltcGxlbWVu dGVkIGluIGRpZmZlcmVudCB3YXlzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QW5kIEkgbWF5IGJlIHdyb25nLCBidXQgdGhvc2UgbGluayB0ZWNobm9sb2dpZXMgY291bGQg YmUgd2VsbCBpbXBsZW1lbnRlZCBpbiBhIHJvdXRlciBhbmQgdGhlbiBvbmUgbmVlZHMgdG8gYW5h bHl6ZSBob3cgdGhhdCB3aG9sZSBhcmNoaXRlY3R1cmUNCiBmaXRzIGludG8gdGhlIHNjaGVkdWxl ciwgcXVldWUsIHBvbGljZXIsIGFuZCBsaW5lIGNhcmQgaGFyZHdhcmUgZGVzaWduIG9mIGEgcm91 dGVyLiBCdXQgdGhhdCBpcyBzb21ldGhpbmcgcm91dGluZyBwZW9wbGUga25vdyBiZXR0ZXIgdGhh biBtZS4gTXkgcG9pbnQgaXMganVzdCB0byBnZXQgdGhlIGV4cGVydHMgaW50byB0aGUgbG9vcCBl YXJseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBCb2IgQnJpc2Nv ZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBOb3ZlbWJlciA5LCAyMDE4IDc6MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFl bDsgdGNwbUBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gdHN2d2dAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gJnF1b3Q7TDRT IGFuZCBSQUNLJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPk1pY2hhZWwsPGJyPg0KPGJyPg0KUGxlYXNlIGFkZHJlc3MgdGhlIHNjYWxpbmcgcmF0aW9u YWxlIGluIHRoZSBhcHBlbmRpeCBmb3Igd2h5IGl0IGRvZXMgbWF0dGVyIGhvdyBhIHNlbmRlciBy ZWFsaXplcyB0aGlzIGludGVybmFsbHkuPGJyPg0KPGJyPg0KVGhlIGxpc3Qgb2YgYWNjZXNzIGxp bmtzIHR5cGVzIEkgbWVudGlvbmVkIGFyZSByYXJlbHkgY29ubmVjdGVkIGRpcmVjdGx5IHRvIHJv dXRlcnMuDQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpCb2I8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwOS8xMS8yMDE4IDE3OjQ0LCBTY2hhcmYsIE1pY2hh ZWwgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J 4oCZbGwgbm90IGNvbW1lbnQgb24gbGluayB0ZWNobm9sb2d5IGltcGxlbWVudGF0aW9uLCBzY2hl ZHVsZXIgYW5kIHF1ZXVlIGRlc2lnbiBhc3N1bXB0aW9ucyBpbiBBcHBlbmRpeCBBLjEuNyBvZiBk cmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQtMDUuDQogUGVvcGxlIGUuZy4gaW4gUlRHIGFyZWEg bWF5IGJlIG1vcmUgZmFtaWxpYXIgd2l0aCB0aGUgaW1wbGljYXRpb25zIG9mIGludGVybmFsIGRl c2lnbnMgZS5nLiBpbnNpZGUgYSByb3V0ZXIuIElNSE8gdGhlIGJlc3Qgd2F5IHRvIGdldCByb3V0 aW5nIGV4cGVydHMgaW50byB0aGUgbG9vcCBiZWZvcmUgZnVydGhlciBkaXNjdXNzaW5nIHdoYXQg aXMgY3VycmVudGx5IGxpc3RlZCBpbiBBcHBlbmRpeCBBLjEuNy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGh1cywgSSBsaW1pdCBteSByZXNwb25zZSB0byB0aGUgYWN0dWFs IHdvcmRpbmcgaW4gdGhlIG1haW4gcGFydCBvZiBkcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQt MDU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEEgc2Nh bGFibGUgY29uZ2VzdGlvbiBjb250cm9sIE1VU1QgZGV0ZWN0IGxvc3MgYnkgY291bnRpbmcgaW48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB1bml0cyBvZiB0aW1lLCB3aGljaCBpcyBzY2FsYWJsZSwgYW5kIE1VU1QgTk9UIGNvdW50IGlu IHVuaXRzIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgcGFja2V0cyAoYXMgaW4gdGhlIDMgRHVwQUNLIHJ1bGUgb2YgdHJhZGl0aW9u YWwgVENQKSwgd2hpY2ggaXMgbm90PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2NhbGFibGUgKHNlZQ0KPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0Ij48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA1I2FwcGVuZGl4LUEuMS43Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFwcGVuZGl4IEEuMS43PC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4NCiBmb3IgcmF0 aW9uYWxlKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgaW5kaXZpZHVh bCBjb250cmlidXRvciwgSSBkaXNhZ3JlZSB3aXRoIHRoaXMgcmVxdWlyZW1lbnQuIEkgd291bGQg cHJvYmFibHkgYmUgT0sgd2l0aCBhIHdvcmRpbmcgdGhhdCBhIFRDUCBzZW5kZXIgbXVzdCBiZSBh YmxlIHRvIHRvbGVyYXRlIHJlb3JkZXJpbmcNCiBiZXlvbmQgMyBEdXBsaWNhdGUgQUNLcy4gSSBi ZWxpZXZlIGl0IGRvZXMgbm90IG1hdHRlciBob3cgYSBzZW5kZXIgcmVhbGl6ZXMgdGhpcyBpbnRl cm5hbGx5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmQgaWYgdGhhdCBy ZXF1aXJlbWVudCBpcyBub3QganVzdCByZW1vdmVkLCBJIGJlbGlldmUgdGhlIHdvcmRpbmcg4oCc dHJhZGl0aW9uYWwgVENQ4oCdIGhhcyB0byBiZSByZXBsYWNlZCBieSDigJxzdGFuZGFyZCBUQ1Di gJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJUVywgYWxzbywgaW4gdGhl IHJlc3Qgb2YgdGhlIGRvY3VtZW50IHRoZXJlIGhhcyB0byBiZSBhIGNsZWFyIGRpc3RpbmN0aW9u IGJldHdlZW4gZXhwZXJpbWVudHMgYW5kIHN0YW5kYXJkcy4gSGlzdG9yeSB0ZWxscyB1cyB0aGF0 IHNvbWUgZXhwZXJpbWVudHMNCiBjYW4gZXZvbHZlIGludG8gc3RhbmRhcmRzIHRyYWNrIHNwZWNp ZmljYXRpb25zLCB3aGlsZSBvdGhlciBleHBlcmltZW50cyBtYXkgZmFpbC4gQW5kIHRoZXJlIGlz IG5vIHdheSBvZiBrbm93aW5nIHRoYXQgaW4gYWR2YW5jZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+ IEJvYiBCcmlzY29lIFs8YSBocmVmPSJtYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldCI+bWFpbHRv OmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTm92 ZW1iZXIgOSwgMjAxOCAxMTowOCBBTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsOyA8 YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5D Yzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+dHN2d2dAaWV0Zi5vcmc8L2E+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHN2d2ddIENyb3NzLWFyZWEgYWxpZ25tZW50IG9u ICZxdW90O0w0UyBhbmQgUkFDSyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TWljaGFlbCw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwOS8xMS8yMDE4IDA2 OjIxLCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgc2VlIHRoZSBmdW5kYW1lbnRhbCBkaWZmZXJlbmNl IGJldHdlZW4gYSBsaW5rIHRlY2hub2xvZ3kgdGhhdCBndWFyYW50ZWVzIGluLW9yZGVyIGRlbGl2 ZXJ5IHdpdGhpbiBhIGZsb3cgKHNheSBieSBmbG93IGhhc2hpbmcsIHNlZSBFQ01QKQ0KIHZzLiBz b21lIGxpbmsgc2NoZW1lIHRoYXQgZ3VhcmFudGVlcyBpbi1vcmRlciBkZWxpdmVyeSwgc2F5LCBv bmx5IGZvciBzb21lIGZyYWN0aW9uIG9mIHRoZSB0cmFmZmljIGNoYXJhY3Rlcml6ZWQgYnkgc29t ZSBvdGhlciBtZWFucyAoc2F5LCBvdGhlciBoZWFkZXIgYml0cykuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1RoZSAmcXVvdDtvdGhl ciBtZWFucyZxdW90OyBhbmQgJnF1b3Q7b3RoZXIgYml0cyZxdW90OyB3b3JkaW5nIGlzIHByZXR0 eSBhbWJpZ3VvdXMgaGVyZS4gSSByZWNrb24gSSBjYW4gZ3Vlc3Mgd2hhdCB5b3UgbWVhbiBidXQg dGhlbiBJIGRvbid0IGtub3cgd2h5IHlvdSdyZSBzYXlpbmcgdGhpcywgJ2NvcyBJIGRvbid0IHRo aW5rIEkndmUgZGlzYWdyZWVkIHdpdGggeW91IG9uIHRoaXMuIFNvIHBlcmhhcHMgeW91IGNvdWxk IGJlIG1vcmUgc3BlY2lmaWMNCiBhbmQgd2UgbWlnaHQgYmUgYWJsZSB0byBzZWUgd2h5IHlvdSd2 ZSBicm91Z2h0IHRoaXMgdXAuXTxicj4NCjxicj4NCkFsc28gSSB3YXNuJ3QgcmVhbGx5IHRhbGtp bmcgYWJvdXQgYWxsICZxdW90OzxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+bGluayB0ZWNobm9sb2d5IHRoYXQgZ3VhcmFudGVlcyBpbi1vcmRl ciBkZWxpdmVyeSB3aXRoaW4gYSBmbG93PC9zcGFuPiZxdW90Oy4ge05vdGUgMX0gSSB3YXMgdGFs a2luZyBhYm91dCBsaW5rIHRlY2hub2xvZ3kgd2hlcmUNCiBhbGwgZmxvd3MgYXJlIGJsb2NrZWQg d2hpbGUgd2FpdGluZyB0byBnZXQgdGhlIGFnZ3JlZ2F0ZSBiYWNrIGluIG9yZGVyIHRoYXQgaXQg d2FzIGluIHdoZW4gaXQgYXJyaXZlZC4gSSBzcGVjaWZpY2FsbHkgc2FpZDo8YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhhdCB0aGVy ZSBjYW4gYmUgbXVsdGlwbGUgZmxvd3Mgb3ZlciBvbmUgbGluay4gU28gJ2luLW9yZGVyIGRlbGl2 ZXJ5JyBmb3IgYSBsaW5rIGRvZXMgbm90IG1lYW4gaW4gb3JkZXIgb2YgVENQIHNlcXVlbmNlIG51 bWJlci4gSXQgbWVhbnMgJ2RlbGl2ZXJlZCBpbiB0aGUgb3JkZXIgdGhhdCBwYWNrZXRzIGFycml2 ZWQgYXQgdGhlIGxpbmsnICh0aGUgbGluayBpbmdyZXNzIGFkZHMgaXRzIG93biBzZXF1ZW5jZQ0K IG51bWJlcnMsIGFuZCB0aGUgbGluayBlZ3Jlc3MgYnVmZmVycyB0aGVtIHVudGlsIGl0IGNhbiBz ZW5kIG91dCBpbiB0aGUgc2FtZSBvcmRlciwgb3IgdW50aWwgYSB0aW1lLW91dCBvciBtYXggbm8u IG9mIGxpbmsgcmV0cmFuc21pc3Npb25zKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZvciBleGFtcGxlOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpBIHBhY2tldCBy ZXNlcXVlbmNpbmcgYnVmZmVyIGFmdGVyIGFsbG93aW5nIGZvciBsaW5rLWxheWVyIHJldHJhbnNt aXNzaW9ucyBpcyBjb21tb24gZm9yIHJhZGlvIGxpbmsgdGVjaG5vbG9naWVzIHN1Y2ggYXMgTFRF IChQRENQIGxheWVyKSBhbmQgODAyLjExIFdpRmkuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpBIHBhY2tldCByZXNlcXVl bmNpbmcgYnVmZmVyIGFmdGVyIG1lcmdpbmcgbXVsdGlwbGUgYm9uZGVkIGxpbmsgY2hhbm5lbHMg aXMgY29tbW9uIGZvciBvdGhlciBhY2Nlc3MgbGluayB0ZWNobm9sb2dpZXMgc3VjaCBhcyBkb3du c3RyZWFtIERPQ1NJUyBib25kZWQgY2hhbm5lbHMuDQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkNsZWFybHksIHJlb3JkZXJpbmcgaXMgYSBwcm9ibGVtIHRoYXQgbmVlZHMgdG8g YmUgZGlzY3Vzc2VkIGluIHRoZSBJRVRGIGFzIGEgd2hvbGUuIEFuZCB3ZSBjb3VsZCBkaXNjdXNz IHdoZXRoZXIgYSByZXZpc2lvbiBvZiBSRkMgMzM2NiBpcyBuZWVkZWQuDQo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Oby4gVGhlcmUgaXMgbm8gcHJvcG9zYWwg dG8gYWx0ZXIgZ2VuZXJhbCBndWlkYW5jZSBmb3IgYWxsIGxpbmtzIGxpa2UgUkZDIDMzNjYuIE5v LW9uZSBpcyBzYXlpbmcgdGhpcy48YnI+DQo8YnI+DQpUaGVyZSBpcyBub3QgZXZlbiBhIHByb3Bv c2FsIHRvIHJlcXVpcmUgb3IgZXZlbiByZWNvbW1lbmQgdGhhdCBMNFMtc3BlY2lmaWMgbGlua3Mg ZG8gYW55dGhpbmcuDQo8YnI+DQo8YnI+DQpUaGUgc3BlY2lmaWMgcHJvcG9zYWwgaXMgdG8gcmVx dWlyZSBMNFMgPGk+c291cmNlczwvaT4gdG8gdXNlIGEgUkFDSy1saWtlIHNjaGVtZSwgYXMgYSBj b25kaXRpb24gZm9yIHNldHRpbmcgdGhlIEVDVCgxKSBjb2RlcG9pbnQuIFNlZSB0aGUgbGFzdCBi dWxsZXQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXRzdndnLWVjbi1sNHMtaWQtMDUjc2VjdGlvbi00LjMiPg0KUy40LjMgb2YgZHJhZnQtaWV0Zi10 c3Z3Zy1lY24tbDRzLWlkLTA1PC9hPi4gPGJyPg0KPGJyPg0KVGhpcyBzYXlzIG5vdGhpbmcgYWJv dXQgd2hhdCBMNFMgbGlua3MgTVVTVCwgU0hPVUxEIG9yIE1BWSBkby4gSXQganVzdCBnaXZlcyBh biBMNFMgbGluayBhbiBvcHBvcnR1bml0eSBub3QgdG8gaGF2ZSB0byBkbyByZXNlcXVlbmNpbmcu PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0 IEkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IHRoaXMgdG9waWMgaGFzIHRvIGJlIHRpZWQgaW50byBh biBleHBlcmltZW50IHN1Y2ggYXMgTDRTLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkl0IGlzIGFuIG9wcG9ydHVuaXR5IHRoYXQgY3VycmVudGx5IG9ubHkgYXBw bGllcyB0byBMNFMuIDxicj4NCjxicj4NCkw0UyBpcyBtZXJlbHkgYW4gZXhhbXBsZSBvZiBhIGNh c2Ugd2hlcmUgd2UgY2FuIG1hbmRhdGUgdGhhdCB0aGVyZSB3aWxsIGJlIG5vIG5vbi1SQUNLIHRy YWZmaWMgaW4gYSBsaW5rLCB3aGljaCBjcmVhdGVzIGFuIG9wcG9ydHVuaXR5IGZvciB0aG9zZSB3 aG8gYXJlIGltcGxlbWVudGluZyB0aGUgTDRTIER1YWxRIENvdXBsZWQgQVFNIHRvIGlnbm9yZSB0 aGUgUkZDMzM2NiByZXNlcXVlbmNpbmcgYWR2aWNlIGZvciB0aGUgTDRTIHF1ZXVlIChidXQNCiB3 ZSBhcmUgbm90IGNoYW5naW5nIHRoZSBhZHZpY2UsIGJlY2F1c2UgTDRTIGlzIG9ubHkgYW4gZXhw ZXJpbWVudCkuIFRoZSBwcml6ZSBpcyB0byByZW1vdmUgdGhlIGhlYWQtb2YtbGluZSBibG9ja2lu ZyBwcm9ibGVtIGZvciB0aGVpciB1c2Vycy4NCjxicj4NCjxicj4NClRoaXMgaXMgbm90IEw0Uy1z cGVjaWZpYywgYWx0aG8gdGhlcmUgYXJlIG5vIG90aGVyIGV4YW1wbGVzIGF0IHRoZSBtb21lbnQg d2hlcmUgdGhpcyBvcHBvcnR1bml0eSBpcyBwb3NzaWJsZSAoc28gaW4gdGhhdCBzZW5zZSBpdCBp cw0KPGk+Y3VycmVudGx5PC9pPiBMNFMtc3BlY2lmaWMpLjxicj4NCjxicj4NCjxicj4NClRoZSBt ZXNzYWdlIGhhcyB0byBiZSBoYW5kbGVkIHJlYWxseSBjYXJlZnVsbHksIGJlY2F1c2UgdGhlIG9w cG9ydHVuaXRpZXMgZm9yIG1pc3VuZGVyc3RhbmRpbmcgYXJlIGVub3Jtb3VzIChhcyBldmlkZW5j ZWQgYnkgdGhpcyB0aHJlYWQsIGFuZCB3ZSBoYXZlbid0IGV2ZW4gc3RhcnRlZCB0YWxraW5nIHRv IG5vbi10cmFuc3BvcnQgcGVvcGxlIHlldCkuPGJyPg0KPGJyPg0KU28gR29ycnkgYW5kIERhdmlk IEIgd2FudCBtZSB0byBkcmFmdCBhIHNob3J0IEktRCB0aGF0IHRoZXkgd2lsbCB3b3JkLXNtaXRo IGFuZCBhdXRob3IgYXMgdHN2d2cgY2hhaXJzIHRvIG1ha2UgdGhlIHNpdHVhdGlvbiBjbGVhci48 YnI+DQo8YnI+DQpJIGhhdmUgc2FpZCBJIGRvbid0IHdhbnQgdGhpcyBkaXNjdXNzaW9uIHRvIGJl IG9mZmljaWFsbHkgcmFpc2VkIG91dHNpZGUgdGhlIHRyYW5zcG9ydCBhcmVhIHVudGlsIHdlIGFy ZSBzdXJlIHRoYXQgYSB2YXJpYW50IG9mIFJBQ0sgaXMgZXZlbiBmZWFzaWJsZSB3aXRob3V0IGFu eSBwYWNrZXQgY291bnRpbmcgYXQgYWxsIChpLmUuIHdpdGhvdXQgdGhlIGluaXRpYWwgMy1EdXBB Q0sgcnVsZSBpbiBjdXJyZW50IFJBQ0spLiBTbyBJJ2xsIHByaW9yaXRpemUNCiB3b3JraW5nIHRo YXQgb3V0IGZvciB0aGUgbmV4dCB3ZWVrIG9yIHNvLCByYXRoZXIgdGhhbiBkcmFmdGluZyBhbnl0 aGluZy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQp7Tm90ZSAxfTogSSBo YWRuJ3QgY29uc2lkZXJlZCB0aGF0IHRoaXMgd291bGQgYWZmZWN0IHRlY2hub2xvZ2llcyBsaWtl IEVDTVAgdGhhdCBtYWludGFpbiBvcmRlciB3aXRob3V0IGEgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBh bmQgd2l0aG91dCBpbnRyb2R1Y2luZyBIb0wgYmxvY2tpbmcuIEJ1dCBhY3R1YWxseSwgdGhlIGNv bnNlcXVlbmNlIHRoZXJlIHdvdWxkIGJlIHRoYXQgTDRTIHRyYWZmaWMgY291bGQgYmUgc3ByYXll ZCBieSBFQ01QIHdpdGhvdXQNCiBwZXItZmxvdyBoYXNoaW5nLjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPiBCb2IgQnJpc2NvZSBbPGEgaHJlZj0ibWFpbHRvOmluQGJvYmJy aXNjb2UubmV0Ij5tYWlsdG86aW5AYm9iYnJpc2NvZS5uZXQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgTm92ZW1iZXIgOSwgMjAxOCA2OjQyIEFNPGJyPg0KPGI+VG86PC9iPiBTY2hh cmYsIE1pY2hhZWw7IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGlldGYub3Jn PC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRzdndnQGlldGYub3JnIj50c3Z3 Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gQ3Jvc3MtYXJl YSBhbGlnbm1lbnQgb24gJnF1b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5NaWNoYWVsLDxicj4NCjxicj4NClRoYXQgaXMgdGhlIHBvaW50IEkgdGhvdWdodCB5b3Ugd2Vy ZSBtYWtpbmcsIGFuZCBteSBwb2ludCAvaXMvIGFib3V0IHRoYXQuPGJyPg0KPGJyPg0KSWYgYW4g YXBwbGljYXRpb24gbmVlZHMgYWxsIHRoZSBwYWNrZXRzIChpLmUuIGEgcmVsaWFibGUgcHJvdG9j b2wpLCBpdCdzIG5vdCB1c2VmdWwgdG8gcmVkdWNlIHRoZSBsYXRlbmN5IG9mIHNvbWUgcGFja2V0 cyBidXQgbm90IGFsbC4gVGhhdCdzIHdoZXJlIHRoZSBpbi1vcmRlciByZXF1aXJlbWVudCBjb21l cyBmcm9tLjxicj4NCjxicj4NCkhvd2V2ZXIsIGlmIGEgc3RyZWFtLWJhc2VkIHRyYW5zcG9ydCBp cyB1c2VkIChpLmUuIFRDUCkgdGhlIC9hcHBsaWNhdGlvbi8gc3RpbGwgZ2V0cyBpbi1vcmRlciBk ZWxpdmVyeSBmcm9tIFRDUC4gSXQganVzdCBkb2Vzbid0IGhhdmUgdG8gcmVxdWlyZSBsaW5rcyB0 byBwcm92aWRlIGluIG9yZGVyIGRlbGl2ZXJ5IGFzIHdlbGwuPGJyPg0KPGJyPg0KTm90ZSB0aGF0 IHRoZXJlIGNhbiBiZSBtdWx0aXBsZSBmbG93cyBvdmVyIG9uZSBsaW5rLiBTbyAnaW4tb3JkZXIg ZGVsaXZlcnknIGZvciBhIGxpbmsgZG9lcyBub3QgbWVhbiBpbiBvcmRlciBvZiBUQ1Agc2VxdWVu Y2UgbnVtYmVyLiBJdCBtZWFucyAnZGVsaXZlcmVkIGluIHRoZSBvcmRlciB0aGF0IHBhY2tldHMg YXJyaXZlZCBhdCB0aGUgbGluaycgKHRoZSBsaW5rIGluZ3Jlc3MgYWRkcyBpdHMgb3duIHNlcXVl bmNlIG51bWJlcnMsIGFuZCB0aGUNCiBsaW5rIGVncmVzcyBidWZmZXJzIHRoZW0gdW50aWwgaXQg Y2FuIHNlbmQgb3V0IGluIHRoZSBzYW1lIG9yZGVyLCBvciB1bnRpbCBhIHRpbWUtb3V0IG9yIG1h eCBuby4gb2YgbGluayByZXRyYW5zbWlzc2lvbnMpLjxicj4NCjxicj4NClNvLCBpZiB0aGUgbGlu ayBsb3NlcyBhIHBhY2tldCBmcm9tIGZsb3cgQSAodGhlIGxpbmsgaXNuJ3QgYXdhcmUgb2YgbWlj cm9mbG93cywgSSdtIGp1c3Qgc2F5aW5nIHRoZSBwYWNrZXQgaGFwcGVucyB0byBiZSBmcm9tIGZs b3cgQSksIGxpbmstbGF5ZXIgaW4tb3JkZXIgZGVsaXZlcnkgd2lsbCBob2xkIGJhY2sgYWxsIHBh Y2tldHMgc2VudCBhZnRlciB0aGF0IHBhY2tldCAoZnJvbSBhbGwgZmxvd3MsIG5vdCBqdXN0IGZs b3cgQSkgdW50aWwgdGhlDQogbGluayByZXBhaXJzIHRoZSBnYXAgb3IgZ2l2ZXMgdXAuIDxicj4N Cjxicj4NClNvIGhvcC1ieS1ob3AgaW4tb3JkZXIgZGVsaXZlcnkgZ2l2ZXMgZXZlcnkgZmxvdyB0 aGUgc2FtZSBkZWxheSBhcyB0aGUgd29yc3QgZGVsYXllZCBmbG93Ljxicj4NCjxicj4NCk9mIGNv dXJzZSwgc29tZW9uZSBidWlsZGluZyBhIG5ldHdvcmsgZm9yIERFVE5FVCB3b3VsZCBhdm9pZCBs aW5rIHRlY2hub2xvZ2llcyBsaWtlIFdpRmkgb3IgTFRFIHRoYXQgZnJlcXVlbnRseSBsb3NlIGFu ZCByZXRyYW5zbWl0IHBhY2tldHMuIEJ1dCB3aGVyZXZlciB0aGVyZSBpcyB2YXJpYWJsZSBkZWxh eSBpbiBhIGxpbmssIGd1YXJhbnRlZWQgaW4tb3JkZXIgZGVsaXZlcnkgcGVyLWhvcCBtZWFucyBl dmVyeSBmbG93IGlzIGd1YXJhbnRlZWQNCiB0byBhbHdheXMgZ2V0IHRoZSB3b3JzdCBkZWxheSBm cm9tIGV2ZXJ5IGxpbmssIHdoaWNoIHdvdWxkIGhhdmUgYmVlbiBleHBlcmllbmNlZCBieSBvbmx5 IG9uZSBmbG93IHdpdGhvdXQgcGVyLWhvcCBpbi1vcmRlciBkZWxpdmVyeS4NCjxicj4NCjxicj4N CkFuZCBtYW55IG9mIHRoZSBhcHBsaWNhdGlvbnMgb2YgREVUTkVUIGludm9sdmUgZHVtYiBpbmR1 c3RyaWFsIG1hY2hpbmVyeSB0aGF0IGp1c3QgZXhwZWN0cyBldmVyeXRoaW5nIHRvIGFycml2ZSBp biBvcmRlciBhbmQgdG8gYSBjbG9ja2VkIHNjaGVkdWxlLiBCdXQgaXQncyBhbHdheXMgYXMgZWZm ZWN0aXZlIHRvIGRlcGxveSBhIHJlc2VxdWVuY2luZyBidWZmZXIgYXMgdGhlIHBlbnVsdGltYXRl IGhvcCwgc2NyZXdlZCBvbnRvIHRoZSByZWNlaXZpbmcNCiBtYWNoaW5lIGlmIG5lY2Vzc2FyeSwg cmF0aGVyIHRoYW4gcmVxdWlyZSBwZXItaG9wIHJlc2VxdWVuY2luZyBpbiB0aGUgbmV0d29yay48 YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fPGJyPg0KU28sIHdoeSBkbyBJbnRlcm5ldCBsaW5r cyBvZnRlbiBlbnN1cmUgaW4tb3JkZXIgZGVsaXZlcnkgZXZlbiB0aG91Z2ggVENQIHB1dHMgZXZl cnl0aGluZyBpbiBvcmRlciBmb3IgdGhlIGFwcGxpY2F0aW9uPw0KPGJyPg0KPGJyPg0KU2hvcnQg YW5zd2VyOiB0aGUgMyBEdXBBQ0sgcnVsZSAod2hpY2ggaXMgdG8gZG8gd2l0aCBsb3NzLXJlY292 ZXJ5LCBhIGRpZmZlcmVudCBpc3N1ZSBmcm9tIHRoZSBkaXNjdXNzaW9uIGFib3ZlKS48YnI+DQo8 YnI+DQpMb25nIGFuc3dlcjogQXMgZmxvdyByYXRlcyBoYXZlIHNjYWxlZCB1cCwgdGhlIHR5cGlj YWwgdGltZSBiZXR3ZWVuIDMgcGFja2V0IGFycml2YWxzIGhhcyBiZWNvbWUgc28gc21hbGwgdGhh dCBUQ1AncyAzLUR1cEFDSyBydWxlIG1ha2VzIGxpbmtzIGhhdmUgdG8gcHJvdmlkZSBkZWxpdmVy eSB3aXRoIG9ubHkgYSB2ZXJ5IHNtYWxsIHJlLW9yZGVyaW5nIGRlZ3JlZSAtIHNvIHNtYWxsIHRo YXQgaXQncyBlYXNpZXIgZm9yIGEgbGluayB0byBqdXN0DQogZGVsaXZlciBldmVyeXRoaW5nIGlu IHRoZSBvcmRlciBpdCByZWNlaXZlZCBpdDsgbm90IGJlY2F1c2UgVENQIGRvZXNuJ3QgcHV0IHBh Y2tldHMgYmFjayBpbiBvcmRlciwgYnV0IGp1c3Qgc28gYXMgbm90IHRvIHRyaWdnZXIgVENQIGlu dG8gZ2VuZXJhdGluZyBzcHVyaW91cyByZXRyYW5zbWlzc2lvbnMuPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KQm9iPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g MDgvMTEvMjAxOCAxNjozNSwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JbmxpbmUgW21zXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJy aXNjb2UgWzxhIGhyZWY9Im1haWx0bzppbkBib2JicmlzY29lLm5ldCI+bWFpbHRvOmluQGJvYmJy aXNjb2UubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTm92ZW1iZXIgOCwg MjAxOCAxMjo1NiBQTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsOyA8YSBocmVmPSJt YWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+dHN2d2dAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbdHN2d2ddIENyb3NzLWFyZWEgYWxpZ25tZW50IG9uICZxdW90O0w0 UyBhbmQgUkFDSyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TWljaGFlbCw8YnI+DQo8YnI+DQpU aGlzIGlzIG1lcmVseSBhIHN5bXB0b20gb2YgYSBkaWZmZXJlbmNlIGluIG9waW5pb24gb24gd2hl cmUgdGhlIHJlc2VxdWVuY2luZyBmdW5jdGlvbiBzaG91bGQgYmUgbG9jYXRlZC48bzpwPjwvbzpw PjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDUgbGV2ZWwxIGxmbzYiPg0KTDRTIHRha2VzIHRoZSBlbmQtdG8tZW5kIGFwcHJvYWNoIHNheWlu ZyB0aGF0IGl0IGlzIHN1ZmZpY2llbnQgdG8gZG8gcmVzZXF1ZW5jaW5nIGluIG9uZSBwbGFjZSAo dGhlIHJlY2VpdmluZyBob3N0KSBpZiBpdCBpcyBuZWVkZWQuIFRoZW4gYW55IHJlc2VxdWVuY2lu ZyBkZWxheSBvbmx5IGFmZmVjdHMgdGhhdCBmbG93LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0Omw1IGxldmVsMSBsZm82Ij4NClRoZSBERVRORVQgYXBwcm9h Y2ggaXMgc2F5aW5nIHRoZSByZXNlcXVlbmNpbmcgbXVzdCBiZSBkb25lIGhvcC1ieS1ob3AuIFRo aXMgbWVhbnMgdGhlcmUgYXBwZWFycyB0byBiZSBubyByZXNlcXVlbmNpbmcgbmVlZGVkIG9uIHRo ZSByZWNlaXZlciAoZXhjZXB0IGlmIHRoZXJlJ3MgcmUtb3JkZXJpbmcgb24gdGhlIGZpbmFsIGhv cCkuDQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMyBsZXZlbDEgbGZvOSI+DQpJbiBvcmRlciB0byBndWFyYW50ZWUgbm8gcmVzZXF1 ZW5jaW5nIGluIHRoZSBuZXR3b3JrIChERVRORVQgYXBwcm9hY2gpLCBvbmx5IHRoZSB0aGUgd29y c3QgY2FzZSBsYXRlbmN5IGNhbiBiZSBndWFyYW50ZWVkLCBhbmQgZXZlcnkgcGFja2V0IGhhcyB0 byBoYXZlIHRoYXQgc2FtZSB3b3JzdC1jYXNlIGxhdGVuY3kuPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzkiPg0KV2hlbiB5b3UgbGVh dmUgcmVzZXF1ZW5jaW5nIHRvIHRoZSByZWNlaXZlciAoZW5kLXRvLWVuZCBhcHByb2FjaCksIG1v c3Qgb2YgdGhlIHBhY2tldHMgYXJyaXZlIGVhcmxpZXIgdGhhbiB0aGV5IHdvdWxkIHdpdGggREVU TkVULCBidXQgb3V0IG9mIG9yZGVyIG9uZXMgbWlnaHQgbm90LiBUaGVuIHRoZSBhcHBsaWNhdGlv biBjaG9vc2VzIHdoZXRoZXIgaXQgd2FudHMgdG8gd2FpdC48bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bbXNdIE15IHBvaW50IGlzIGRpZmZl cmVudDogVGhlcmUgc2VlbSB0byBiZSBvdGhlciB3b3JraW5nIGdyb3VwcyBpbiB0aGUgSUVURiB0 aGF0IGRvIHRhbGsgYWJvdXQg4oCcbG93IGxhdGVuY3nigJ0gYXMgd2VsbCBidXQgYXBwYXJlbnRs eSB0aGV5IGFsc28gZG8gbmVlZCBpbi1vcmRlciBkZWxpdmVyeQ0KIG9mIHBhY2tldHMsIHRvby4g U28gdGhlIGFzc3VtcHRpb24gdGhhdCBlLmcuIGEgbGluayBsYXllciB0ZWNobm9sb2d5IGNhbiBz aW1wbHkgZGlzYWJsZSBpbi1vcmRlciBkZWxpdmVyeSBmb3IgYWxsIOKAnGxvdyBsYXRlbmN54oCd IGFwcGxpY2F0aW9ucyBzZWVtcyBub3QgY29ycmVjdC4gVGhlIHJlYWxpdHkgbWF5IGJlIGEgYml0 IG1vcmUgY29tcGxleC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgMyBE dXBBQ0sgcnVsZSBpbiBUQ1AgbGVkIHRoZSBJbnRlcm5ldCBub3QgdG8gZm9sbG93IHRoZSBlbmQt dG8tZW5kIHByaW5jaXBsZSBvbiByZS1zZXF1ZW5jaW5nLg0KPC9zcGFuPk5vdyB3ZSdyZSByZW1v dmluZyB0aGUgMyBEdXBBQ0sgcnVsZSwgd2UgY2FuIHRha2UgYWR2YW50YWdlIG9mIHRoZSBlMmUg cHJpbmNpcGxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlttc10gRm9yIFRDUCwgdGhyZWUgRHVwQUNLUyBhcmUgYSBTSE9V TEQgaW4gUkZDIDU2ODEgYW5kIFJGQyA1NjgxIGlzIHN0YW5kYXJkcyB0cmFjay4gU28gdGhlIGJh ciBmb3Ig4oCccmVtb3ZpbmfigJ0gdGhhdA0KIHJ1bGUgZm9yIFRDUCBpcyBub3QgbG934oCmPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlttc10gQWxzbywgdGhlIGVuZC10by1lbmQgcHJpbmNpcGxlIGNvbWVzIHdp dGggdHJhZGVvZmZzLiBGb3IgaW5zdGFuY2UsIHJlbHlpbmcgb24gdGhlIGVuZC10by1lbmQgcHJp bmNpcGxlIGZvciByZWNvdmVyeQ0KIG9mIGJpdCBlcnJvcnMgaXMgbm90IGVmZmljaWVudC4gRm9y IGluLW9yZGVyIGRlbGl2ZXJ5IHRoZXJlIGFyZSB0cmFkZW9mZnMgYXMgd2VsbCwgc2VlIGUuZy4g U2VjdGlvbiA0IGluIGRyYWZ0LWlldGYtdGNwbS1yYWNrLTA0LiBUaGVyZSBtYXkgYmUgbm8gZnJl ZSBsdW5jaC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5PZiBjb3Vyc2UsIGFu IGFwcGxpY2F0aW9uIG1pZ2h0IGNob29zZSB0byB1c2UgVENQIGFuZCBMNFMsIHJhdGhlciB0aGFu IFVEUCBhbmQgTDRTIChlLmcgUVVJQykuDQo8L3NwYW4+VGhlbiB0aGVyZSBjb3VsZCBzdGlsbCBi ZSBIb0wgYmxvY2tpbmcgaW4gdGhlIHJlY2VpdmluZyBUQ1Agc3RhY2suIEJ1dCBhdCBsZWFzdCB0 aGVyZSdzIG5vIEhvTCBibG9ja2luZyBpbiB0aGUgbmV0d29yaywgYW5kIHRoZSBhcHAgY2FuIGNo b29zZSBiZXR3ZWVuIHN0cmVhbSAoVENQKSBvciBkYXRhZ3JhbSAoVURQKS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bbXNd IElmIExSTy9HUk8gaW4gdGhlIHJlY2VpdmluZyBUQ1Agc3RhY2sgZ2V0cyBtZXNzZWQgdXAsIEkg ZmFpbCB0byBzZWUgdGhlIGJlbmVmaXQgKHNlZSBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNCkuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4N Cjxicj4NCkJvYjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAwNi8xMS8yMDE4IDE5OjIwLCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHByZT5BIGNvbW1lbnQgb24gdGhlIFRDUE0gcHJlc2VudGF0aW9u ICZxdW90O0w0UyBhbmQgUkFDSyZxdW90Ozo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGUgREVUTkVU IFdHIGluIFJURyBhcmVhIGhhcyBxdWl0ZSBzb21lIHVzZXMgY2FzZXMgZm9yIHVsdHJhLWxvdyBs YXRlbmN5IHRyYW5zcG9ydCAtIGluIHBhcnRpY3VsYXIgYWxzbyB3aXRoIGJvdW5kZWQgaml0dGVy LiBBbmQgc29tZSBvZiB0aGVzZSBhcHBsaWNhdGlvbnMgKGUuZy4gdXNpbmcgVURQKSBhcHBhcmVu dGx5IG1heSBub3QgYmUgYWJsZSB0byB0b2xlcmF0ZSAqYW55KiBvdXQtb2Ytb3JkZXIgcGFja2V0 IGRlbGl2ZXJ5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPlNvIHBlcmhhcHMgc29tZSBjcm9zcy1hcmVhIGFsaWdubWVudCBvbiB1bHRhLWxvdy1s YXRlbmN5IGFwcGxpY2F0aW9uIHJlcXVpcmVtZW50cyB3b3VsZCBiZSB1c2VmdWw/PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+TWljaGFlbDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPih3aG8gcmVjZW50bHkgaGFkIHRvIHJldmlldyBkcmFmdC1pZXRm LWRldG5ldC1hcmNoaXRlY3R1cmUpPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3ByZT4NCjxwcmU+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2Jv YmJyaXNjb2UubmV0LyI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4N CjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8iPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88 L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9h PjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+Qm9iIEJyaXNjb2UmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0cDovL2JvYmJyaXNjb2Uu bmV0LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D1537CDrznt8114rzntrzd_-- From nobody Fri Nov 9 10:52:43 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D935B130DC7; Fri, 9 Nov 2018 10:52:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4gf_5CRnkMP; Fri, 9 Nov 2018 10:52:30 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1496130DC3; Fri, 9 Nov 2018 10:52:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HeNnqnXREt7k2uj1bpXr6N4es/OaPEduAQVy5HjZ1E0=; b=y0tqhw8jt7NDCsGHG6bKsMvWG eRGABnn0tebyNEUgMTmG8R4L8e3hzx3DXxbfsXEBw4TdQIVr8IqrHuvdTq7s92uiV+++CKynuhnMQ +xULce0feHe1s4R+1EGJVutXgbKM4OyHkWZAGvVKhrj9cDegwx47e8KTKj/99G9cJUlMFcxAOw3vY sULLWBEQOd0JUn6XambO+JpzMotjLp6oWwS2bPronWnQPNrBB0ueVzXu3TaGIuSCzScIU80B+Sqrx lJ4FuDA/DdQ34yKGfhULgR7WdB435J3t1u2PG/u4KtuDK3YDS38TC+pGjncNC1UxeIeSgML24FS/Z f3wCJBUJA==; Received: from ppp-171-96-190-43.revip8.asianet.co.th ([171.96.190.43]:55104 helo=[192.168.1.48]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gLBtJ-0007A0-IL; Fri, 09 Nov 2018 18:52:26 +0000 To: "Scharf, Michael" , "tcpm@ietf.org" Cc: "tsvwg@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D1537CD@rznt8114.rznt.rzdir.fht-esslingen.de> From: Bob Briscoe Message-ID: <45512894-fc71-a4a8-4043-3feb06f9e347@bobbriscoe.net> Date: Fri, 9 Nov 2018 18:52:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D1537CD@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: multipart/alternative; boundary="------------6E376267E36D7E22BB67F24C" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 18:52:34 -0000 This is a multi-part message in MIME format. --------------6E376267E36D7E22BB67F24C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael, The idea is that (as now in the RACK draft since discussion on the tcpm list earlier this year under a subject something like vicious circle or virtuous circle) there will be a limit on the initial RACK reordering window expressed in fractional RTT units. Link vendors know the min e2e RTT of the paths that their links are usually deployed over. Therefore they can estimate the max reordering they allow their links to introduce. I don't expect this limit to be set in stone while both RACK and L4S are experimental. But as both these experiments progress, I think the industry will get a better idea of where the limit should lie. It was the realization that, if TCP adapted its reordering window to the measured reordering degree without bound, the L2 world would continually increase the reordering degree of their links (the vicious circle). If there is any aspect of this limit expressed in units of packets, the limit will decrease in time as flow rates increase, and therefore not serve to give the L2 world any clear guidance - no de facto limit agreed between the L4 world and the L2 world. If we keep the limit in units of RTT, hopefully then we have a virtuous circle, not a vicious circle. Bob On 09/11/2018 18:28, Scharf, Michael wrote: > > I may miss something, but I read the outcome of the appendix as a > requirement “must be more robust to reordering”. As far as I > understand, that can be implemented in different ways. > > And I may be wrong, but those link technologies could be well > implemented in a router and then one needs to analyze how that whole > architecture fits into the scheduler, queue, policer, and line card > hardware design of a router. But that is something routing people know > better than me. My point is just to get the experts into the loop early. > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 7:04 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > Please address the scaling rationale in the appendix for why it does > matter how a sender realizes this internally. > > The list of access links types I mentioned are rarely connected > directly to routers. > > > > Bob > > On 09/11/2018 17:44, Scharf, Michael wrote: > > I’ll not comment on link technology implementation, scheduler and > queue design assumptions in Appendix A.1.7 of > draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area may be > more familiar with the implications of internal designs e.g. > inside a router. IMHO the best way to get routing experts into the > loop before further discussing what is currently listed in > Appendix A.1.7. > > Thus, I limit my response to the actual wording in the main part > of draft-ietf-tsvwg-ecn-l4s-id-05: > >     o  A scalable congestion control MUST detect loss by counting in > >       units of time, which is scalable, and MUST NOT count in units of > >       packets (as in the 3 DupACK rule of traditional TCP), which > is not > >       scalable (see Appendix A.1.7 > for > rationale). > > As individual contributor, I disagree with this requirement. I > would probably be OK with a wording that a TCP sender must be able > to tolerate reordering beyond 3 Duplicate ACKs. I believe it does > not matter how a sender realizes this internally. > > And if that requirement is not just removed, I believe the wording > “traditional TCP” has to be replaced by “standard TCP”. > > BTW, also, in the rest of the document there has to be a clear > distinction between experiments and standards. History tells us > that some experiments can evolve into standards track > specifications, while other experiments may fail. And there is no > way of knowing that in advance. > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 11:08 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > On 09/11/2018 06:21, Scharf, Michael wrote: > > I don’t see the fundamental difference between a link > technology that guarantees in-order delivery within a flow > (say by flow hashing, see ECMP) vs. some link scheme that > guarantees in-order delivery, say, only for some fraction of > the traffic characterized by some other means (say, other > header bits). > > [The "other means" and "other bits" wording is pretty ambiguous > here. I reckon I can guess what you mean but then I don't know why > you're saying this, 'cos I don't think I've disagreed with you on > this. So perhaps you could be more specific and we might be able > to see why you've brought this up.] > > Also I wasn't really talking about all "link technology that > guarantees in-order delivery within a flow". {Note 1} I was > talking about link technology where all flows are blocked while > waiting to get the aggregate back in order that it was in when it > arrived. I specifically said: > > > Note that there can be multiple flows over one link. So 'in-order > delivery' for a link does not mean in order of TCP sequence > number. It means 'delivered in the order that packets arrived at > the link' (the link ingress adds its own sequence numbers, and the > link egress buffers them until it can send out in the same order, > or until a time-out or max no. of link retransmissions). > > For example: > > * A packet resequencing buffer after allowing for link-layer > retransmissions is common for radio link technologies such as > LTE (PDCP layer) and 802.11 WiFi. > * A packet resequencing buffer after merging multiple bonded > link channels is common for other access link technologies > such as downstream DOCSIS bonded channels. > > > > > Clearly, reordering is a problem that needs to be discussed in the > IETF as a whole. And we could discuss whether a revision of RFC > 3366 is needed. > > No. There is no proposal to alter general guidance for all links > like RFC 3366. No-one is saying this. > > There is not even a proposal to require or even recommend that > L4S-specific links do anything. > > The specific proposal is to require L4S /sources/ to use a > RACK-like scheme, as a condition for setting the ECT(1) codepoint. > See the last bullet in S.4.3 of draft-ietf-tsvwg-ecn-l4s-id-05 > . > > > This says nothing about what L4S links MUST, SHOULD or MAY do. It > just gives an L4S link an opportunity not to have to do resequencing. > > > > But I am not convinced that this topic has to be tied into an > experiment such as L4S. > > It is an opportunity that currently only applies to L4S. > > L4S is merely an example of a case where we can mandate that there > will be no non-RACK traffic in a link, which creates an > opportunity for those who are implementing the L4S DualQ Coupled > AQM to ignore the RFC3366 resequencing advice for the L4S queue > (but we are not changing the advice, because L4S is only an > experiment). The prize is to remove the head-of-line blocking > problem for their users. > > This is not L4S-specific, altho there are no other examples at the > moment where this opportunity is possible (so in that sense it is > /currently/ L4S-specific). > > > The message has to be handled really carefully, because the > opportunities for misunderstanding are enormous (as evidenced by > this thread, and we haven't even started talking to non-transport > people yet). > > So Gorry and David B want me to draft a short I-D that they will > word-smith and author as tsvwg chairs to make the situation clear. > > I have said I don't want this discussion to be officially raised > outside the transport area until we are sure that a variant of > RACK is even feasible without any packet counting at all (i.e. > without the initial 3-DupACK rule in current RACK). So I'll > prioritize working that out for the next week or so, rather than > drafting anything. > > > > Bob > > {Note 1}: I hadn't considered that this would affect technologies > like ECMP that maintain order without a resequencing buffer and > without introducing HoL blocking. But actually, the consequence > there would be that L4S traffic could be sprayed by ECMP without > per-flow hashing. > > > > Michael > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 6:42 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > That is the point I thought you were making, and my point /is/ > about that. > > If an application needs all the packets (i.e. a reliable > protocol), it's not useful to reduce the latency of some packets > but not all. That's where the in-order requirement comes from. > > However, if a stream-based transport is used (i.e. TCP) the > /application/ still gets in-order delivery from TCP. It just > doesn't have to require links to provide in order delivery as well. > > Note that there can be multiple flows over one link. So 'in-order > delivery' for a link does not mean in order of TCP sequence > number. It means 'delivered in the order that packets arrived at > the link' (the link ingress adds its own sequence numbers, and the > link egress buffers them until it can send out in the same order, > or until a time-out or max no. of link retransmissions). > > So, if the link loses a packet from flow A (the link isn't aware > of microflows, I'm just saying the packet happens to be from flow > A), link-layer in-order delivery will hold back all packets sent > after that packet (from all flows, not just flow A) until the link > repairs the gap or gives up. > > So hop-by-hop in-order delivery gives every flow the same delay as > the worst delayed flow. > > Of course, someone building a network for DETNET would avoid link > technologies like WiFi or LTE that frequently lose and retransmit > packets. But wherever there is variable delay in a link, > guaranteed in-order delivery per-hop means every flow is > guaranteed to always get the worst delay from every link, which > would have been experienced by only one flow without per-hop > in-order delivery. > > And many of the applications of DETNET involve dumb industrial > machinery that just expects everything to arrive in order and to a > clocked schedule. But it's always as effective to deploy a > resequencing buffer as the penultimate hop, screwed onto the > receiving machine if necessary, rather than require per-hop > resequencing in the network. > > ________________ > So, why do Internet links often ensure in-order delivery even > though TCP puts everything in order for the application? > > Short answer: the 3 DupACK rule (which is to do with > loss-recovery, a different issue from the discussion above). > > Long answer: As flow rates have scaled up, the typical time > between 3 packet arrivals has become so small that TCP's 3-DupACK > rule makes links have to provide delivery with only a very small > re-ordering degree - so small that it's easier for a link to just > deliver everything in the order it received it; not because TCP > doesn't put packets back in order, but just so as not to trigger > TCP into generating spurious retransmissions. > > > > Bob > > On 08/11/2018 16:35, Scharf, Michael wrote: > > Inline [ms] > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Thursday, November 8, 2018 12:56 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > This is merely a symptom of a difference in opinion on where > the resequencing function should be located. > > * L4S takes the end-to-end approach saying that it is > sufficient to do resequencing in one place (the receiving > host) if it is needed. Then any resequencing delay only > affects that flow. > * The DETNET approach is saying the resequencing must be > done hop-by-hop. This means there appears to be no > resequencing needed on the receiver (except if there's > re-ordering on the final hop). > > * In order to guarantee no resequencing in the network > (DETNET approach), only the the worst case latency can be > guaranteed, and every packet has to have that same > worst-case latency. > * When you leave resequencing to the receiver (end-to-end > approach), most of the packets arrive earlier than they > would with DETNET, but out of order ones might not. Then > the application chooses whether it wants to wait. > > [ms] My point is different: There seem to be other working > groups in the IETF that do talk about “low latency” as well > but apparently they also do need in-order delivery of packets, > too. So the assumption that e.g. a link layer technology can > simply disable in-order delivery for all “low latency” > applications seems not correct. The reality may be a bit more > complex. > > The 3 DupACK rule in TCP led the Internet not to follow the > end-to-end principle on re-sequencing. Now we're removing the > 3 DupACK rule, we can take advantage of the e2e principle. > > [ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC > 5681 is standards track. So the bar for “removing” that rule > for TCP is not low… > > [ms] Also, the end-to-end principle comes with tradeoffs. For > instance, relying on the end-to-end principle for recovery of > bit errors is not efficient. For in-order delivery there are > tradeoffs as well, see e.g. Section 4 in > draft-ietf-tcpm-rack-04. There may be no free lunch. > > Of course, an application might choose to use TCP and L4S, > rather than UDP and L4S (e.g QUIC). Then there could still be > HoL blocking in the receiving TCP stack. But at least there's > no HoL blocking in the network, and the app can choose between > stream (TCP) or datagram (UDP). > > [ms] If LRO/GRO in the receiving TCP stack gets messed up, I > fail to see the benefit (see draft-ietf-tcpm-rack-04). > > Michael > > > Bob > > On 06/11/2018 19:20, Scharf, Michael wrote: > > A comment on the TCPM presentation "L4S and RACK": > > > > As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery. > > > > So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful? > > > > Michael > > (who recently had to review draft-ietf-detnet-architecture) > > > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------6E376267E36D7E22BB67F24C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael,

The idea is that (as now in the RACK draft since discussion on the tcpm list earlier this year under a subject something like vicious circle or virtuous circle) there will be a limit on the initial RACK reordering window expressed in fractional RTT units.

Link vendors know the min e2e RTT of the paths that their links are usually deployed over. Therefore they can estimate the max reordering they allow their links to introduce.

I don't expect this limit to be set in stone while both RACK and L4S are experimental. But as both these experiments progress, I think the industry will get a better idea of where the limit should lie.

It was the realization that, if TCP adapted its reordering window to the measured reordering degree without bound, the L2 world would continually increase the reordering degree of their links (the vicious circle).

If there is any aspect of this limit expressed in units of packets, the limit will decrease in time as flow rates increase, and therefore not serve to give the L2 world any clear guidance - no de facto limit agreed between the L4 world and the L2 world.

If we keep the limit in units of RTT, hopefully then we have a virtuous circle, not a vicious circle.



Bob


On 09/11/2018 18:28, Scharf, Michael wrote:

I may miss something, but I read the outcome of the appendix as a requirement “must be more robust to reordering”. As far as I understand, that can be implemented in different ways.

 

And I may be wrong, but those link technologies could be well implemented in a router and then one needs to analyze how that whole architecture fits into the scheduler, queue, policer, and line card hardware design of a router. But that is something routing people know better than me. My point is just to get the experts into the loop early.

 

Michael

 

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, November 9, 2018 7:04 PM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

Please address the scaling rationale in the appendix for why it does matter how a sender realizes this internally.

The list of access links types I mentioned are rarely connected directly to routers.



Bob

On 09/11/2018 17:44, Scharf, Michael wrote:

I’ll not comment on link technology implementation, scheduler and queue design assumptions in Appendix A.1.7 of draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area may be more familiar with the implications of internal designs e.g. inside a router. IMHO the best way to get routing experts into the loop before further discussing what is currently listed in Appendix A.1.7.

 

Thus, I limit my response to the actual wording in the main part of draft-ietf-tsvwg-ecn-l4s-id-05:

 

    o  A scalable congestion control MUST detect loss by counting in

      units of time, which is scalable, and MUST NOT count in units of

      packets (as in the 3 DupACK rule of traditional TCP), which is not

      scalable (see Appendix A.1.7 for rationale).

 

As individual contributor, I disagree with this requirement. I would probably be OK with a wording that a TCP sender must be able to tolerate reordering beyond 3 Duplicate ACKs. I believe it does not matter how a sender realizes this internally.

 

And if that requirement is not just removed, I believe the wording “traditional TCP” has to be replaced by “standard TCP”.

 

BTW, also, in the rest of the document there has to be a clear distinction between experiments and standards. History tells us that some experiments can evolve into standards track specifications, while other experiments may fail. And there is no way of knowing that in advance.

 

Michael

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, November 9, 2018 11:08 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

On 09/11/2018 06:21, Scharf, Michael wrote:

I don’t see the fundamental difference between a link technology that guarantees in-order delivery within a flow (say by flow hashing, see ECMP) vs. some link scheme that guarantees in-order delivery, say, only for some fraction of the traffic characterized by some other means (say, other header bits).

[The "other means" and "other bits" wording is pretty ambiguous here. I reckon I can guess what you mean but then I don't know why you're saying this, 'cos I don't think I've disagreed with you on this. So perhaps you could be more specific and we might be able to see why you've brought this up.]

Also I wasn't really talking about all "link technology that guarantees in-order delivery within a flow". {Note 1} I was talking about link technology where all flows are blocked while waiting to get the aggregate back in order that it was in when it arrived. I specifically said:


Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

For example:

  • A packet resequencing buffer after allowing for link-layer retransmissions is common for radio link technologies such as LTE (PDCP layer) and 802.11 WiFi.
  • A packet resequencing buffer after merging multiple bonded link channels is common for other access link technologies such as downstream DOCSIS bonded channels.




 

Clearly, reordering is a problem that needs to be discussed in the IETF as a whole. And we could discuss whether a revision of RFC 3366 is needed.

No. There is no proposal to alter general guidance for all links like RFC 3366. No-one is saying this.

There is not even a proposal to require or even recommend that L4S-specific links do anything.

The specific proposal is to require L4S sources to use a RACK-like scheme, as a condition for setting the ECT(1) codepoint. See the last bullet in S.4.3 of draft-ietf-tsvwg-ecn-l4s-id-05.

This says nothing about what L4S links MUST, SHOULD or MAY do. It just gives an L4S link an opportunity not to have to do resequencing.



 

But I am not convinced that this topic has to be tied into an experiment such as L4S.

It is an opportunity that currently only applies to L4S.

L4S is merely an example of a case where we can mandate that there will be no non-RACK traffic in a link, which creates an opportunity for those who are implementing the L4S DualQ Coupled AQM to ignore the RFC3366 resequencing advice for the L4S queue (but we are not changing the advice, because L4S is only an experiment). The prize is to remove the head-of-line blocking problem for their users.

This is not L4S-specific, altho there are no other examples at the moment where this opportunity is possible (so in that sense it is currently L4S-specific).


The message has to be handled really carefully, because the opportunities for misunderstanding are enormous (as evidenced by this thread, and we haven't even started talking to non-transport people yet).

So Gorry and David B want me to draft a short I-D that they will word-smith and author as tsvwg chairs to make the situation clear.

I have said I don't want this discussion to be officially raised outside the transport area until we are sure that a variant of RACK is even feasible without any packet counting at all (i.e. without the initial 3-DupACK rule in current RACK). So I'll prioritize working that out for the next week or so, rather than drafting anything.



Bob

{Note 1}: I hadn't considered that this would affect technologies like ECMP that maintain order without a resequencing buffer and without introducing HoL blocking. But actually, the consequence there would be that L4S traffic could be sprayed by ECMP without per-flow hashing.



 

Michael

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Friday, November 9, 2018 6:42 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

That is the point I thought you were making, and my point /is/ about that.

If an application needs all the packets (i.e. a reliable protocol), it's not useful to reduce the latency of some packets but not all. That's where the in-order requirement comes from.

However, if a stream-based transport is used (i.e. TCP) the /application/ still gets in-order delivery from TCP. It just doesn't have to require links to provide in order delivery as well.

Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

So, if the link loses a packet from flow A (the link isn't aware of microflows, I'm just saying the packet happens to be from flow A), link-layer in-order delivery will hold back all packets sent after that packet (from all flows, not just flow A) until the link repairs the gap or gives up.

So hop-by-hop in-order delivery gives every flow the same delay as the worst delayed flow.

Of course, someone building a network for DETNET would avoid link technologies like WiFi or LTE that frequently lose and retransmit packets. But wherever there is variable delay in a link, guaranteed in-order delivery per-hop means every flow is guaranteed to always get the worst delay from every link, which would have been experienced by only one flow without per-hop in-order delivery.

And many of the applications of DETNET involve dumb industrial machinery that just expects everything to arrive in order and to a clocked schedule. But it's always as effective to deploy a resequencing buffer as the penultimate hop, screwed onto the receiving machine if necessary, rather than require per-hop resequencing in the network.

________________
So, why do Internet links often ensure in-order delivery even though TCP puts everything in order for the application?

Short answer: the 3 DupACK rule (which is to do with loss-recovery, a different issue from the discussion above).

Long answer: As flow rates have scaled up, the typical time between 3 packet arrivals has become so small that TCP's 3-DupACK rule makes links have to provide delivery with only a very small re-ordering degree - so small that it's easier for a link to just deliver everything in the order it received it; not because TCP doesn't put packets back in order, but just so as not to trigger TCP into generating spurious retransmissions.



Bob

On 08/11/2018 16:35, Scharf, Michael wrote:

Inline [ms]

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Thursday, November 8, 2018 12:56 PM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

This is merely a symptom of a difference in opinion on where the resequencing function should be located.

  • L4S takes the end-to-end approach saying that it is sufficient to do resequencing in one place (the receiving host) if it is needed. Then any resequencing delay only affects that flow.
  • The DETNET approach is saying the resequencing must be done hop-by-hop. This means there appears to be no resequencing needed on the receiver (except if there's re-ordering on the final hop).

 

  • In order to guarantee no resequencing in the network (DETNET approach), only the the worst case latency can be guaranteed, and every packet has to have that same worst-case latency.
  • When you leave resequencing to the receiver (end-to-end approach), most of the packets arrive earlier than they would with DETNET, but out of order ones might not. Then the application chooses whether it wants to wait.

[ms] My point is different: There seem to be other working groups in the IETF that do talk about “low latency” as well but apparently they also do need in-order delivery of packets, too. So the assumption that e.g. a link layer technology can simply disable in-order delivery for all “low latency” applications seems not correct. The reality may be a bit more complex.

The 3 DupACK rule in TCP led the Internet not to follow the end-to-end principle on re-sequencing. Now we're removing the 3 DupACK rule, we can take advantage of the e2e principle.

[ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 is standards track. So the bar for “removing” that rule for TCP is not low…

[ms] Also, the end-to-end principle comes with tradeoffs. For instance, relying on the end-to-end principle for recovery of bit errors is not efficient. For in-order delivery there are tradeoffs as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may be no free lunch.

Of course, an application might choose to use TCP and L4S, rather than UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the receiving TCP stack. But at least there's no HoL blocking in the network, and the app can choose between stream (TCP) or datagram (UDP).

[ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail to see the benefit (see draft-ietf-tcpm-rack-04).

Michael


Bob

On 06/11/2018 19:20, Scharf, Michael wrote:

A comment on the TCPM presentation "L4S and RACK":
 
As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery.
 
So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful?
 
Michael
(who recently had to review draft-ietf-detnet-architecture)
 
 






-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/





-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------6E376267E36D7E22BB67F24C-- From nobody Fri Nov 9 11:10:25 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8FB130DC3; Fri, 9 Nov 2018 11:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94JQSfS1qbCv; Fri, 9 Nov 2018 11:10:18 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820133.outbound.protection.outlook.com [40.107.82.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A96C128BCC; Fri, 9 Nov 2018 11:10:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DXdSgZGiaI3Vt0pKjMEHa3bn4wlMHtCCtZ0SH8pMj4s=; b=LnL7EJkH3wsNhGs4/pbUWz9PSILKsaHC53ayfeNR5slzbKpOTyl2NEVYjWcB47NaCNLl//zm8KxVA4lOjfiPJNH5dXDo6QTflS9E+weSrGldWCfRskUUQE47tbftCj9FxGpWYibXZ3oYteUl9tVGSZ47VSVSpMpP6Qq+bDF7VcU= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB0921.namprd21.prod.outlook.com (52.132.152.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.7; Fri, 9 Nov 2018 19:10:16 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a%4]) with mapi id 15.20.1361.000; Fri, 9 Nov 2018 19:10:16 +0000 From: Praveen Balasubramanian To: Bob Briscoe , "Scharf, Michael" , "tcpm@ietf.org" CC: "tsvwg@ietf.org" Thread-Topic: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" Thread-Index: AQHUeFoRUcF4FbF2VEiRhV7P88hfI6VHyf6AgAACKBA= Date: Fri, 9 Nov 2018 19:10:16 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D1537CD@rznt8114.rznt.rzdir.fht-esslingen.de> <45512894-fc71-a4a8-4043-3feb06f9e347@bobbriscoe.net> In-Reply-To: <45512894-fc71-a4a8-4043-3feb06f9e347@bobbriscoe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:3:f570:32cd:aba6:c7e2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR2101MB0921; 6:pUdSuzUB72LyQ9N06O0ZYUFXxF5NCE3/ngXHunTvQjcDfzv8eNYedTeJgWFUYLEGA8PT8P0YUeWjBhmN6tyEFD4rgUJkpjXbIOhI4c3TFsTKftovz1RHGd07LoVoxYkHOqtzSA2KotMuejCBDbLJLMPu8jRyc9h4Fdhz8hjtSJ2tgyEv8Ny6jqKYmq0Id1oG6uC9HktMMIOFZZeAJLeovyCvQb0EXeF9ggFHoeo71JPM8SASzucNF5KCMrTr2hpYxhMibrmYT23G+SlMqfZoHgHpm6ejDn/iCDPzUfVqjtYI5N1guYeqLHNKJejr105LkZLBQyAjS6vDxW2V0nPzRoNlbMzF5iChE/Qns/Nu38vj/UCytShlFSrjklzjMM3OLEPmDdrNu73OyreruNo+6hgRPkYGJcCbKWF8JwdTRcoSR75/KoSf8mzsSWQ+nXtofWTbHJv/8bhHrtzypt9elw==; 5:r5Wg+jS+16co1lfFkIeXF52p1PZFhVKwJ2m6Ch+bU7JISG27MD6QZ6v2MetD+kfME8deqQBrbuKLbkXS6rLYPTQWURy1Ui4V5uS2oh4H1vtpdePtJcBsZrL7Xf4bPvtcIi3BFVV30kazfGkh95TsaEoJczPXb++tUqlKvS/g7Tc=; 7:/ZtxSmeHY6d675van/vVpYaEB0Fnor01xrF3bXxIJqS9mPQ1oq3eO/3iZMrZobUWaE96kG8uGdfGGFBocrcwxttJsv+BhBVpD2aRHbc5jB/tN44iGehjUINPq0umFnssvsczdhE4ETQS/wk1MTzNqA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: cb9431dc-6a8e-4efe-0625-08d64676fbcb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MW2PR2101MB0921; x-ms-traffictypediagnostic: MW2PR2101MB0921: x-ms-exchange-purlcount: 14 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(8220035)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231393)(944501410)(4982022)(2018427008)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:MW2PR2101MB0921; BCL:0; PCL:0; RULEID:; SRVR:MW2PR2101MB0921; x-forefront-prvs: 08512C5403 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39860400002)(396003)(376002)(346002)(199004)(189003)(4744004)(486006)(97736004)(6436002)(2900100001)(14444005)(256004)(71200400001)(71190400001)(561944003)(6306002)(476003)(54896002)(8936002)(446003)(55016002)(11346002)(9686003)(8676002)(10090500001)(236005)(53946003)(53936002)(46003)(81156014)(81166006)(6246003)(2501003)(966005)(606006)(53376002)(14454004)(4326008)(68736007)(478600001)(25786009)(86362001)(99286004)(7696005)(74316002)(10290500003)(76176011)(86612001)(790700001)(8990500004)(6116002)(33656002)(53546011)(102836004)(6506007)(7736002)(186003)(106356001)(2906002)(5660300001)(105586002)(229853002)(110136005)(93886005)(22452003)(316002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0921; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2/46DlNtt1uCYzcfu2Ms1aRC/WTmyFXP+5G/mqGe6iHEq83feIy+mAa1KQTcOuyAxPYqDntVn1Juz0nF6dAYtoiIcO8Y5tJiBRLuOjTGtvy9jt+2B5/yr0qnggp9xgcsZBIHlrr1kvwW6IkA8ZquwfHjg2Ou8NwpAm4LZGrALlkhYpPBymEZU2Blec3x2mwISy5CBPAlY3PAAPzSu2yBeEbJZw2hSS/sPkhDDlzkIgZshsTb48dSReM6YuEolzQtxPeY1dISsEs05ntX1aOi68gJ4bikJuUVgh5LD0bgO7bn9SLBvRz5iwwhVGQgiJNPl5B+IS5tGtXYotmoTEuO9CJSksHQzAe7OkB2d4DRiAo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB1049EAF866AFA35983A31167B6C60MW2PR2101MB1049_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb9431dc-6a8e-4efe-0625-08d64676fbcb X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2018 19:10:16.2114 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0921 Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 19:10:23 -0000 --_000_MW2PR2101MB1049EAF866AFA35983A31167B6C60MW2PR2101MB1049_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gVGhlcmVmb3JlIHRoZXkgY2FuIGVzdGltYXRlIHRoZSBtYXggcmVvcmRlcmluZyB0aGV5IGFs bG93IHRoZWlyIGxpbmtzIHRvIGludHJvZHVjZQ0KSU1PIEwyIHNob3VsZG7igJl0IGludHJvZHVj ZSBtb3JlIHJlb3JkZXJpbmcganVzdCBiZWNhdXNlIEw0IGNvbmdlc3Rpb24gY29udHJvbCBpcyBt b3JlIHJlc2lsaWVudCB0byBpdC4gVGhlcmUgaXMgb3RoZXIgcGVyZm9ybWFuY2UgaW1wYWN0IGR1 ZSB0byByZW9yZGVyaW5nOiBMUk8gLyBHUk8gLyBSU0Mgb3Bwb3J0dW5pdHkgd2lsbCBiZSByZWR1 Y2VkLCBtb3JlIG1lbW9yeSBhbmQgQ1BVIGNvc3QgdG8gZG8gcmVhc3NlbWJseSBhdCBMNCAodGhp cyBpcyBhbiBhY3RpdmUgYXJlYSBmb3IgcmVtb3RlIGF0dGFja3MpIGV0Yy4gSU1PIEw0IGd1aWRh bmNlIHNob3VsZCByZW1haW4gdGhhdCBsaW5rIHZlbmRvcnMgbXVzdCBhdm9pZCByZW9yZGVyaW5n IGFzIG11Y2ggYXMgcG9zc2libGUgYW5kIG5vdCBidWlsZCBzb2x1dGlvbnMgdGhhdCBjYXVzZSBm cmVxdWVudCBvciBjb25zaXN0ZW50IHJlb3JkZXJpbmcuDQoNCkZyb206IHRjcG0gPHRjcG0tYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJvYiBCcmlzY29lDQpTZW50OiBGcmlkYXksIE5v dmVtYmVyIDksIDIwMTggMTA6NTIgQU0NClRvOiBTY2hhcmYsIE1pY2hhZWwgPE1pY2hhZWwuU2No YXJmQGhzLWVzc2xpbmdlbi5kZT47IHRjcG1AaWV0Zi5vcmcNCkNjOiB0c3Z3Z0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFt0Y3BtXSBbdHN2d2ddIENyb3NzLWFyZWEgYWxpZ25tZW50IG9uICJMNFMg YW5kIFJBQ0siDQoNCk1pY2hhZWwsDQoNClRoZSBpZGVhIGlzIHRoYXQgKGFzIG5vdyBpbiB0aGUg UkFDSyBkcmFmdCBzaW5jZSBkaXNjdXNzaW9uIG9uIHRoZSB0Y3BtIGxpc3QgZWFybGllciB0aGlz IHllYXIgdW5kZXIgYSBzdWJqZWN0IHNvbWV0aGluZyBsaWtlIHZpY2lvdXMgY2lyY2xlIG9yIHZp cnR1b3VzIGNpcmNsZSkgdGhlcmUgd2lsbCBiZSBhIGxpbWl0IG9uIHRoZSBpbml0aWFsIFJBQ0sg cmVvcmRlcmluZyB3aW5kb3cgZXhwcmVzc2VkIGluIGZyYWN0aW9uYWwgUlRUIHVuaXRzLg0KDQpM aW5rIHZlbmRvcnMga25vdyB0aGUgbWluIGUyZSBSVFQgb2YgdGhlIHBhdGhzIHRoYXQgdGhlaXIg bGlua3MgYXJlIHVzdWFsbHkgZGVwbG95ZWQgb3Zlci4gVGhlcmVmb3JlIHRoZXkgY2FuIGVzdGlt YXRlIHRoZSBtYXggcmVvcmRlcmluZyB0aGV5IGFsbG93IHRoZWlyIGxpbmtzIHRvIGludHJvZHVj ZS4NCg0KSSBkb24ndCBleHBlY3QgdGhpcyBsaW1pdCB0byBiZSBzZXQgaW4gc3RvbmUgd2hpbGUg Ym90aCBSQUNLIGFuZCBMNFMgYXJlIGV4cGVyaW1lbnRhbC4gQnV0IGFzIGJvdGggdGhlc2UgZXhw ZXJpbWVudHMgcHJvZ3Jlc3MsIEkgdGhpbmsgdGhlIGluZHVzdHJ5IHdpbGwgZ2V0IGEgYmV0dGVy IGlkZWEgb2Ygd2hlcmUgdGhlIGxpbWl0IHNob3VsZCBsaWUuDQoNCkl0IHdhcyB0aGUgcmVhbGl6 YXRpb24gdGhhdCwgaWYgVENQIGFkYXB0ZWQgaXRzIHJlb3JkZXJpbmcgd2luZG93IHRvIHRoZSBt ZWFzdXJlZCByZW9yZGVyaW5nIGRlZ3JlZSB3aXRob3V0IGJvdW5kLCB0aGUgTDIgd29ybGQgd291 bGQgY29udGludWFsbHkgaW5jcmVhc2UgdGhlIHJlb3JkZXJpbmcgZGVncmVlIG9mIHRoZWlyIGxp bmtzICh0aGUgdmljaW91cyBjaXJjbGUpLg0KDQpJZiB0aGVyZSBpcyBhbnkgYXNwZWN0IG9mIHRo aXMgbGltaXQgZXhwcmVzc2VkIGluIHVuaXRzIG9mIHBhY2tldHMsIHRoZSBsaW1pdCB3aWxsIGRl Y3JlYXNlIGluIHRpbWUgYXMgZmxvdyByYXRlcyBpbmNyZWFzZSwgYW5kIHRoZXJlZm9yZSBub3Qg c2VydmUgdG8gZ2l2ZSB0aGUgTDIgd29ybGQgYW55IGNsZWFyIGd1aWRhbmNlIC0gbm8gZGUgZmFj dG8gbGltaXQgYWdyZWVkIGJldHdlZW4gdGhlIEw0IHdvcmxkIGFuZCB0aGUgTDIgd29ybGQuDQoN CklmIHdlIGtlZXAgdGhlIGxpbWl0IGluIHVuaXRzIG9mIFJUVCwgaG9wZWZ1bGx5IHRoZW4gd2Ug aGF2ZSBhIHZpcnR1b3VzIGNpcmNsZSwgbm90IGEgdmljaW91cyBjaXJjbGUuDQoNCg0KDQpCb2IN Cg0KT24gMDkvMTEvMjAxOCAxODoyOCwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KSSBtYXkgbWlz cyBzb21ldGhpbmcsIGJ1dCBJIHJlYWQgdGhlIG91dGNvbWUgb2YgdGhlIGFwcGVuZGl4IGFzIGEg cmVxdWlyZW1lbnQg4oCcbXVzdCBiZSBtb3JlIHJvYnVzdCB0byByZW9yZGVyaW5n4oCdLiBBcyBm YXIgYXMgSSB1bmRlcnN0YW5kLCB0aGF0IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiBkaWZmZXJlbnQg d2F5cy4NCg0KQW5kIEkgbWF5IGJlIHdyb25nLCBidXQgdGhvc2UgbGluayB0ZWNobm9sb2dpZXMg Y291bGQgYmUgd2VsbCBpbXBsZW1lbnRlZCBpbiBhIHJvdXRlciBhbmQgdGhlbiBvbmUgbmVlZHMg dG8gYW5hbHl6ZSBob3cgdGhhdCB3aG9sZSBhcmNoaXRlY3R1cmUgZml0cyBpbnRvIHRoZSBzY2hl ZHVsZXIsIHF1ZXVlLCBwb2xpY2VyLCBhbmQgbGluZSBjYXJkIGhhcmR3YXJlIGRlc2lnbiBvZiBh IHJvdXRlci4gQnV0IHRoYXQgaXMgc29tZXRoaW5nIHJvdXRpbmcgcGVvcGxlIGtub3cgYmV0dGVy IHRoYW4gbWUuIE15IHBvaW50IGlzIGp1c3QgdG8gZ2V0IHRoZSBleHBlcnRzIGludG8gdGhlIGxv b3AgZWFybHkuDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmlldGZA Ym9iYnJpc2NvZS5uZXRdDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDksIDIwMTggNzowNCBQTQ0K VG86IFNjaGFyZiwgTWljaGFlbDsgdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4N CkNjOiB0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAiTDRTIGFuZCBSQUNLIg0KDQpNaWNoYWVs LA0KDQpQbGVhc2UgYWRkcmVzcyB0aGUgc2NhbGluZyByYXRpb25hbGUgaW4gdGhlIGFwcGVuZGl4 IGZvciB3aHkgaXQgZG9lcyBtYXR0ZXIgaG93IGEgc2VuZGVyIHJlYWxpemVzIHRoaXMgaW50ZXJu YWxseS4NCg0KVGhlIGxpc3Qgb2YgYWNjZXNzIGxpbmtzIHR5cGVzIEkgbWVudGlvbmVkIGFyZSBy YXJlbHkgY29ubmVjdGVkIGRpcmVjdGx5IHRvIHJvdXRlcnMuDQoNCg0KDQpCb2INCk9uIDA5LzEx LzIwMTggMTc6NDQsIFNjaGFyZiwgTWljaGFlbCB3cm90ZToNCknigJlsbCBub3QgY29tbWVudCBv biBsaW5rIHRlY2hub2xvZ3kgaW1wbGVtZW50YXRpb24sIHNjaGVkdWxlciBhbmQgcXVldWUgZGVz aWduIGFzc3VtcHRpb25zIGluIEFwcGVuZGl4IEEuMS43IG9mIGRyYWZ0LWlldGYtdHN2d2ctZWNu LWw0cy1pZC0wNS4gUGVvcGxlIGUuZy4gaW4gUlRHIGFyZWEgbWF5IGJlIG1vcmUgZmFtaWxpYXIg d2l0aCB0aGUgaW1wbGljYXRpb25zIG9mIGludGVybmFsIGRlc2lnbnMgZS5nLiBpbnNpZGUgYSBy b3V0ZXIuIElNSE8gdGhlIGJlc3Qgd2F5IHRvIGdldCByb3V0aW5nIGV4cGVydHMgaW50byB0aGUg bG9vcCBiZWZvcmUgZnVydGhlciBkaXNjdXNzaW5nIHdoYXQgaXMgY3VycmVudGx5IGxpc3RlZCBp biBBcHBlbmRpeCBBLjEuNy4NCg0KVGh1cywgSSBsaW1pdCBteSByZXNwb25zZSB0byB0aGUgYWN0 dWFsIHdvcmRpbmcgaW4gdGhlIG1haW4gcGFydCBvZiBkcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMt aWQtMDU6DQoNCiAgICBvICBBIHNjYWxhYmxlIGNvbmdlc3Rpb24gY29udHJvbCBNVVNUIGRldGVj dCBsb3NzIGJ5IGNvdW50aW5nIGluDQogICAgICB1bml0cyBvZiB0aW1lLCB3aGljaCBpcyBzY2Fs YWJsZSwgYW5kIE1VU1QgTk9UIGNvdW50IGluIHVuaXRzIG9mDQogICAgICBwYWNrZXRzIChhcyBp biB0aGUgMyBEdXBBQ0sgcnVsZSBvZiB0cmFkaXRpb25hbCBUQ1ApLCB3aGljaCBpcyBub3QNCiAg ICAgIHNjYWxhYmxlIChzZWUgQXBwZW5kaXggQS4xLjc8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUy Rmh0bWwlMkZkcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQtMDUlMjNhcHBlbmRpeC1BLjEuNyZk YXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0M1NDdlNTAzZTIxODU0OTQ4M2Yz MDA4ZDY0Njc0OTViOSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzY3NzM4NjM4OTU0OTY0OTgmc2RhdGE9JTJCZXo5T0NaaTFtNXd4N1RHSGt2Zkc5UXNKZkow Vnhoc1h5bnFXVzJqWEc0JTNEJnJlc2VydmVkPTA+IGZvciByYXRpb25hbGUpLg0KDQpBcyBpbmRp dmlkdWFsIGNvbnRyaWJ1dG9yLCBJIGRpc2FncmVlIHdpdGggdGhpcyByZXF1aXJlbWVudC4gSSB3 b3VsZCBwcm9iYWJseSBiZSBPSyB3aXRoIGEgd29yZGluZyB0aGF0IGEgVENQIHNlbmRlciBtdXN0 IGJlIGFibGUgdG8gdG9sZXJhdGUgcmVvcmRlcmluZyBiZXlvbmQgMyBEdXBsaWNhdGUgQUNLcy4g SSBiZWxpZXZlIGl0IGRvZXMgbm90IG1hdHRlciBob3cgYSBzZW5kZXIgcmVhbGl6ZXMgdGhpcyBp bnRlcm5hbGx5Lg0KDQpBbmQgaWYgdGhhdCByZXF1aXJlbWVudCBpcyBub3QganVzdCByZW1vdmVk LCBJIGJlbGlldmUgdGhlIHdvcmRpbmcg4oCcdHJhZGl0aW9uYWwgVENQ4oCdIGhhcyB0byBiZSBy ZXBsYWNlZCBieSDigJxzdGFuZGFyZCBUQ1DigJ0uDQoNCkJUVywgYWxzbywgaW4gdGhlIHJlc3Qg b2YgdGhlIGRvY3VtZW50IHRoZXJlIGhhcyB0byBiZSBhIGNsZWFyIGRpc3RpbmN0aW9uIGJldHdl ZW4gZXhwZXJpbWVudHMgYW5kIHN0YW5kYXJkcy4gSGlzdG9yeSB0ZWxscyB1cyB0aGF0IHNvbWUg ZXhwZXJpbWVudHMgY2FuIGV2b2x2ZSBpbnRvIHN0YW5kYXJkcyB0cmFjayBzcGVjaWZpY2F0aW9u cywgd2hpbGUgb3RoZXIgZXhwZXJpbWVudHMgbWF5IGZhaWwuIEFuZCB0aGVyZSBpcyBubyB3YXkg b2Yga25vd2luZyB0aGF0IGluIGFkdmFuY2UuDQoNCk1pY2hhZWwNCg0KRnJvbTogQm9iIEJyaXNj b2UgW21haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogRnJpZGF5LCBOb3ZlbWJlciA5 LCAyMDE4IDExOjA4IEFNDQpUbzogU2NoYXJmLCBNaWNoYWVsOyB0Y3BtQGlldGYub3JnPG1haWx0 bzp0Y3BtQGlldGYub3JnPg0KQ2M6IHRzdndnQGlldGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbdHN2d2ddIENyb3NzLWFyZWEgYWxpZ25tZW50IG9uICJMNFMgYW5k IFJBQ0siDQoNCk1pY2hhZWwsDQpPbiAwOS8xMS8yMDE4IDA2OjIxLCBTY2hhcmYsIE1pY2hhZWwg d3JvdGU6DQpJIGRvbuKAmXQgc2VlIHRoZSBmdW5kYW1lbnRhbCBkaWZmZXJlbmNlIGJldHdlZW4g YSBsaW5rIHRlY2hub2xvZ3kgdGhhdCBndWFyYW50ZWVzIGluLW9yZGVyIGRlbGl2ZXJ5IHdpdGhp biBhIGZsb3cgKHNheSBieSBmbG93IGhhc2hpbmcsIHNlZSBFQ01QKSB2cy4gc29tZSBsaW5rIHNj aGVtZSB0aGF0IGd1YXJhbnRlZXMgaW4tb3JkZXIgZGVsaXZlcnksIHNheSwgb25seSBmb3Igc29t ZSBmcmFjdGlvbiBvZiB0aGUgdHJhZmZpYyBjaGFyYWN0ZXJpemVkIGJ5IHNvbWUgb3RoZXIgbWVh bnMgKHNheSwgb3RoZXIgaGVhZGVyIGJpdHMpLg0KW1RoZSAib3RoZXIgbWVhbnMiIGFuZCAib3Ro ZXIgYml0cyIgd29yZGluZyBpcyBwcmV0dHkgYW1iaWd1b3VzIGhlcmUuIEkgcmVja29uIEkgY2Fu IGd1ZXNzIHdoYXQgeW91IG1lYW4gYnV0IHRoZW4gSSBkb24ndCBrbm93IHdoeSB5b3UncmUgc2F5 aW5nIHRoaXMsICdjb3MgSSBkb24ndCB0aGluayBJJ3ZlIGRpc2FncmVlZCB3aXRoIHlvdSBvbiB0 aGlzLiBTbyBwZXJoYXBzIHlvdSBjb3VsZCBiZSBtb3JlIHNwZWNpZmljIGFuZCB3ZSBtaWdodCBi ZSBhYmxlIHRvIHNlZSB3aHkgeW91J3ZlIGJyb3VnaHQgdGhpcyB1cC5dDQoNCkFsc28gSSB3YXNu J3QgcmVhbGx5IHRhbGtpbmcgYWJvdXQgYWxsICJsaW5rIHRlY2hub2xvZ3kgdGhhdCBndWFyYW50 ZWVzIGluLW9yZGVyIGRlbGl2ZXJ5IHdpdGhpbiBhIGZsb3ciLiB7Tm90ZSAxfSBJIHdhcyB0YWxr aW5nIGFib3V0IGxpbmsgdGVjaG5vbG9neSB3aGVyZSBhbGwgZmxvd3MgYXJlIGJsb2NrZWQgd2hp bGUgd2FpdGluZyB0byBnZXQgdGhlIGFnZ3JlZ2F0ZSBiYWNrIGluIG9yZGVyIHRoYXQgaXQgd2Fz IGluIHdoZW4gaXQgYXJyaXZlZC4gSSBzcGVjaWZpY2FsbHkgc2FpZDoNCg0KDQoNCk5vdGUgdGhh dCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgZmxvd3Mgb3ZlciBvbmUgbGluay4gU28gJ2luLW9yZGVy IGRlbGl2ZXJ5JyBmb3IgYSBsaW5rIGRvZXMgbm90IG1lYW4gaW4gb3JkZXIgb2YgVENQIHNlcXVl bmNlIG51bWJlci4gSXQgbWVhbnMgJ2RlbGl2ZXJlZCBpbiB0aGUgb3JkZXIgdGhhdCBwYWNrZXRz IGFycml2ZWQgYXQgdGhlIGxpbmsnICh0aGUgbGluayBpbmdyZXNzIGFkZHMgaXRzIG93biBzZXF1 ZW5jZSBudW1iZXJzLCBhbmQgdGhlIGxpbmsgZWdyZXNzIGJ1ZmZlcnMgdGhlbSB1bnRpbCBpdCBj YW4gc2VuZCBvdXQgaW4gdGhlIHNhbWUgb3JkZXIsIG9yIHVudGlsIGEgdGltZS1vdXQgb3IgbWF4 IG5vLiBvZiBsaW5rIHJldHJhbnNtaXNzaW9ucykuDQpGb3IgZXhhbXBsZToNCg0KICAqICAgQSBw YWNrZXQgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBhZnRlciBhbGxvd2luZyBmb3IgbGluay1sYXllciBy ZXRyYW5zbWlzc2lvbnMgaXMgY29tbW9uIGZvciByYWRpbyBsaW5rIHRlY2hub2xvZ2llcyBzdWNo IGFzIExURSAoUERDUCBsYXllcikgYW5kIDgwMi4xMSBXaUZpLg0KICAqICAgQSBwYWNrZXQgcmVz ZXF1ZW5jaW5nIGJ1ZmZlciBhZnRlciBtZXJnaW5nIG11bHRpcGxlIGJvbmRlZCBsaW5rIGNoYW5u ZWxzIGlzIGNvbW1vbiBmb3Igb3RoZXIgYWNjZXNzIGxpbmsgdGVjaG5vbG9naWVzIHN1Y2ggYXMg ZG93bnN0cmVhbSBET0NTSVMgYm9uZGVkIGNoYW5uZWxzLg0KDQoNCg0KDQoNCkNsZWFybHksIHJl b3JkZXJpbmcgaXMgYSBwcm9ibGVtIHRoYXQgbmVlZHMgdG8gYmUgZGlzY3Vzc2VkIGluIHRoZSBJ RVRGIGFzIGEgd2hvbGUuIEFuZCB3ZSBjb3VsZCBkaXNjdXNzIHdoZXRoZXIgYSByZXZpc2lvbiBv ZiBSRkMgMzM2NiBpcyBuZWVkZWQuDQpOby4gVGhlcmUgaXMgbm8gcHJvcG9zYWwgdG8gYWx0ZXIg Z2VuZXJhbCBndWlkYW5jZSBmb3IgYWxsIGxpbmtzIGxpa2UgUkZDIDMzNjYuIE5vLW9uZSBpcyBz YXlpbmcgdGhpcy4NCg0KVGhlcmUgaXMgbm90IGV2ZW4gYSBwcm9wb3NhbCB0byByZXF1aXJlIG9y IGV2ZW4gcmVjb21tZW5kIHRoYXQgTDRTLXNwZWNpZmljIGxpbmtzIGRvIGFueXRoaW5nLg0KDQpU aGUgc3BlY2lmaWMgcHJvcG9zYWwgaXMgdG8gcmVxdWlyZSBMNFMgc291cmNlcyB0byB1c2UgYSBS QUNLLWxpa2Ugc2NoZW1lLCBhcyBhIGNvbmRpdGlvbiBmb3Igc2V0dGluZyB0aGUgRUNUKDEpIGNv ZGVwb2ludC4gU2VlIHRoZSBsYXN0IGJ1bGxldCBpbiBTLjQuMyBvZiBkcmFmdC1pZXRmLXRzdndn LWVjbi1sNHMtaWQtMDU8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRm LXRzdndnLWVjbi1sNHMtaWQtMDUlMjNzZWN0aW9uLTQuMyZkYXRhPTAyJTdDMDElN0NwcmF2YiU0 MG1pY3Jvc29mdC5jb20lN0M1NDdlNTAzZTIxODU0OTQ4M2YzMDA4ZDY0Njc0OTViOSU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3NzM4NjM4OTU1MDY1MTEm c2RhdGE9bSUyRm42SE5RbkpZYlRQSW8wTVI4Y1RYS2ZjajBEWDU3OUhBeUQ5TE1lNGFRJTNEJnJl c2VydmVkPTA+Lg0KDQpUaGlzIHNheXMgbm90aGluZyBhYm91dCB3aGF0IEw0UyBsaW5rcyBNVVNU LCBTSE9VTEQgb3IgTUFZIGRvLiBJdCBqdXN0IGdpdmVzIGFuIEw0UyBsaW5rIGFuIG9wcG9ydHVu aXR5IG5vdCB0byBoYXZlIHRvIGRvIHJlc2VxdWVuY2luZy4NCg0KDQoNCg0KDQpCdXQgSSBhbSBu b3QgY29udmluY2VkIHRoYXQgdGhpcyB0b3BpYyBoYXMgdG8gYmUgdGllZCBpbnRvIGFuIGV4cGVy aW1lbnQgc3VjaCBhcyBMNFMuDQpJdCBpcyBhbiBvcHBvcnR1bml0eSB0aGF0IGN1cnJlbnRseSBv bmx5IGFwcGxpZXMgdG8gTDRTLg0KDQpMNFMgaXMgbWVyZWx5IGFuIGV4YW1wbGUgb2YgYSBjYXNl IHdoZXJlIHdlIGNhbiBtYW5kYXRlIHRoYXQgdGhlcmUgd2lsbCBiZSBubyBub24tUkFDSyB0cmFm ZmljIGluIGEgbGluaywgd2hpY2ggY3JlYXRlcyBhbiBvcHBvcnR1bml0eSBmb3IgdGhvc2Ugd2hv IGFyZSBpbXBsZW1lbnRpbmcgdGhlIEw0UyBEdWFsUSBDb3VwbGVkIEFRTSB0byBpZ25vcmUgdGhl IFJGQzMzNjYgcmVzZXF1ZW5jaW5nIGFkdmljZSBmb3IgdGhlIEw0UyBxdWV1ZSAoYnV0IHdlIGFy ZSBub3QgY2hhbmdpbmcgdGhlIGFkdmljZSwgYmVjYXVzZSBMNFMgaXMgb25seSBhbiBleHBlcmlt ZW50KS4gVGhlIHByaXplIGlzIHRvIHJlbW92ZSB0aGUgaGVhZC1vZi1saW5lIGJsb2NraW5nIHBy b2JsZW0gZm9yIHRoZWlyIHVzZXJzLg0KDQpUaGlzIGlzIG5vdCBMNFMtc3BlY2lmaWMsIGFsdGhv IHRoZXJlIGFyZSBubyBvdGhlciBleGFtcGxlcyBhdCB0aGUgbW9tZW50IHdoZXJlIHRoaXMgb3Bw b3J0dW5pdHkgaXMgcG9zc2libGUgKHNvIGluIHRoYXQgc2Vuc2UgaXQgaXMgY3VycmVudGx5IEw0 Uy1zcGVjaWZpYykuDQoNCg0KVGhlIG1lc3NhZ2UgaGFzIHRvIGJlIGhhbmRsZWQgcmVhbGx5IGNh cmVmdWxseSwgYmVjYXVzZSB0aGUgb3Bwb3J0dW5pdGllcyBmb3IgbWlzdW5kZXJzdGFuZGluZyBh cmUgZW5vcm1vdXMgKGFzIGV2aWRlbmNlZCBieSB0aGlzIHRocmVhZCwgYW5kIHdlIGhhdmVuJ3Qg ZXZlbiBzdGFydGVkIHRhbGtpbmcgdG8gbm9uLXRyYW5zcG9ydCBwZW9wbGUgeWV0KS4NCg0KU28g R29ycnkgYW5kIERhdmlkIEIgd2FudCBtZSB0byBkcmFmdCBhIHNob3J0IEktRCB0aGF0IHRoZXkg d2lsbCB3b3JkLXNtaXRoIGFuZCBhdXRob3IgYXMgdHN2d2cgY2hhaXJzIHRvIG1ha2UgdGhlIHNp dHVhdGlvbiBjbGVhci4NCg0KSSBoYXZlIHNhaWQgSSBkb24ndCB3YW50IHRoaXMgZGlzY3Vzc2lv biB0byBiZSBvZmZpY2lhbGx5IHJhaXNlZCBvdXRzaWRlIHRoZSB0cmFuc3BvcnQgYXJlYSB1bnRp bCB3ZSBhcmUgc3VyZSB0aGF0IGEgdmFyaWFudCBvZiBSQUNLIGlzIGV2ZW4gZmVhc2libGUgd2l0 aG91dCBhbnkgcGFja2V0IGNvdW50aW5nIGF0IGFsbCAoaS5lLiB3aXRob3V0IHRoZSBpbml0aWFs IDMtRHVwQUNLIHJ1bGUgaW4gY3VycmVudCBSQUNLKS4gU28gSSdsbCBwcmlvcml0aXplIHdvcmtp bmcgdGhhdCBvdXQgZm9yIHRoZSBuZXh0IHdlZWsgb3Igc28sIHJhdGhlciB0aGFuIGRyYWZ0aW5n IGFueXRoaW5nLg0KDQoNCg0KQm9iDQoNCntOb3RlIDF9OiBJIGhhZG4ndCBjb25zaWRlcmVkIHRo YXQgdGhpcyB3b3VsZCBhZmZlY3QgdGVjaG5vbG9naWVzIGxpa2UgRUNNUCB0aGF0IG1haW50YWlu IG9yZGVyIHdpdGhvdXQgYSByZXNlcXVlbmNpbmcgYnVmZmVyIGFuZCB3aXRob3V0IGludHJvZHVj aW5nIEhvTCBibG9ja2luZy4gQnV0IGFjdHVhbGx5LCB0aGUgY29uc2VxdWVuY2UgdGhlcmUgd291 bGQgYmUgdGhhdCBMNFMgdHJhZmZpYyBjb3VsZCBiZSBzcHJheWVkIGJ5IEVDTVAgd2l0aG91dCBw ZXItZmxvdyBoYXNoaW5nLg0KDQoNCg0KDQoNCk1pY2hhZWwNCg0KRnJvbTogQm9iIEJyaXNjb2Ug W21haWx0bzppbkBib2JicmlzY29lLm5ldF0NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgOSwgMjAx OCA2OjQyIEFNDQpUbzogU2NoYXJmLCBNaWNoYWVsOyB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3Bt QGlldGYub3JnPg0KQ2M6IHRzdndnQGlldGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbdHN2d2ddIENyb3NzLWFyZWEgYWxpZ25tZW50IG9uICJMNFMgYW5kIFJBQ0si DQoNCk1pY2hhZWwsDQoNClRoYXQgaXMgdGhlIHBvaW50IEkgdGhvdWdodCB5b3Ugd2VyZSBtYWtp bmcsIGFuZCBteSBwb2ludCAvaXMvIGFib3V0IHRoYXQuDQoNCklmIGFuIGFwcGxpY2F0aW9uIG5l ZWRzIGFsbCB0aGUgcGFja2V0cyAoaS5lLiBhIHJlbGlhYmxlIHByb3RvY29sKSwgaXQncyBub3Qg dXNlZnVsIHRvIHJlZHVjZSB0aGUgbGF0ZW5jeSBvZiBzb21lIHBhY2tldHMgYnV0IG5vdCBhbGwu IFRoYXQncyB3aGVyZSB0aGUgaW4tb3JkZXIgcmVxdWlyZW1lbnQgY29tZXMgZnJvbS4NCg0KSG93 ZXZlciwgaWYgYSBzdHJlYW0tYmFzZWQgdHJhbnNwb3J0IGlzIHVzZWQgKGkuZS4gVENQKSB0aGUg L2FwcGxpY2F0aW9uLyBzdGlsbCBnZXRzIGluLW9yZGVyIGRlbGl2ZXJ5IGZyb20gVENQLiBJdCBq dXN0IGRvZXNuJ3QgaGF2ZSB0byByZXF1aXJlIGxpbmtzIHRvIHByb3ZpZGUgaW4gb3JkZXIgZGVs aXZlcnkgYXMgd2VsbC4NCg0KTm90ZSB0aGF0IHRoZXJlIGNhbiBiZSBtdWx0aXBsZSBmbG93cyBv dmVyIG9uZSBsaW5rLiBTbyAnaW4tb3JkZXIgZGVsaXZlcnknIGZvciBhIGxpbmsgZG9lcyBub3Qg bWVhbiBpbiBvcmRlciBvZiBUQ1Agc2VxdWVuY2UgbnVtYmVyLiBJdCBtZWFucyAnZGVsaXZlcmVk IGluIHRoZSBvcmRlciB0aGF0IHBhY2tldHMgYXJyaXZlZCBhdCB0aGUgbGluaycgKHRoZSBsaW5r IGluZ3Jlc3MgYWRkcyBpdHMgb3duIHNlcXVlbmNlIG51bWJlcnMsIGFuZCB0aGUgbGluayBlZ3Jl c3MgYnVmZmVycyB0aGVtIHVudGlsIGl0IGNhbiBzZW5kIG91dCBpbiB0aGUgc2FtZSBvcmRlciwg b3IgdW50aWwgYSB0aW1lLW91dCBvciBtYXggbm8uIG9mIGxpbmsgcmV0cmFuc21pc3Npb25zKS4N Cg0KU28sIGlmIHRoZSBsaW5rIGxvc2VzIGEgcGFja2V0IGZyb20gZmxvdyBBICh0aGUgbGluayBp c24ndCBhd2FyZSBvZiBtaWNyb2Zsb3dzLCBJJ20ganVzdCBzYXlpbmcgdGhlIHBhY2tldCBoYXBw ZW5zIHRvIGJlIGZyb20gZmxvdyBBKSwgbGluay1sYXllciBpbi1vcmRlciBkZWxpdmVyeSB3aWxs IGhvbGQgYmFjayBhbGwgcGFja2V0cyBzZW50IGFmdGVyIHRoYXQgcGFja2V0IChmcm9tIGFsbCBm bG93cywgbm90IGp1c3QgZmxvdyBBKSB1bnRpbCB0aGUgbGluayByZXBhaXJzIHRoZSBnYXAgb3Ig Z2l2ZXMgdXAuDQoNClNvIGhvcC1ieS1ob3AgaW4tb3JkZXIgZGVsaXZlcnkgZ2l2ZXMgZXZlcnkg ZmxvdyB0aGUgc2FtZSBkZWxheSBhcyB0aGUgd29yc3QgZGVsYXllZCBmbG93Lg0KDQpPZiBjb3Vy c2UsIHNvbWVvbmUgYnVpbGRpbmcgYSBuZXR3b3JrIGZvciBERVRORVQgd291bGQgYXZvaWQgbGlu ayB0ZWNobm9sb2dpZXMgbGlrZSBXaUZpIG9yIExURSB0aGF0IGZyZXF1ZW50bHkgbG9zZSBhbmQg cmV0cmFuc21pdCBwYWNrZXRzLiBCdXQgd2hlcmV2ZXIgdGhlcmUgaXMgdmFyaWFibGUgZGVsYXkg aW4gYSBsaW5rLCBndWFyYW50ZWVkIGluLW9yZGVyIGRlbGl2ZXJ5IHBlci1ob3AgbWVhbnMgZXZl cnkgZmxvdyBpcyBndWFyYW50ZWVkIHRvIGFsd2F5cyBnZXQgdGhlIHdvcnN0IGRlbGF5IGZyb20g ZXZlcnkgbGluaywgd2hpY2ggd291bGQgaGF2ZSBiZWVuIGV4cGVyaWVuY2VkIGJ5IG9ubHkgb25l IGZsb3cgd2l0aG91dCBwZXItaG9wIGluLW9yZGVyIGRlbGl2ZXJ5Lg0KDQpBbmQgbWFueSBvZiB0 aGUgYXBwbGljYXRpb25zIG9mIERFVE5FVCBpbnZvbHZlIGR1bWIgaW5kdXN0cmlhbCBtYWNoaW5l cnkgdGhhdCBqdXN0IGV4cGVjdHMgZXZlcnl0aGluZyB0byBhcnJpdmUgaW4gb3JkZXIgYW5kIHRv IGEgY2xvY2tlZCBzY2hlZHVsZS4gQnV0IGl0J3MgYWx3YXlzIGFzIGVmZmVjdGl2ZSB0byBkZXBs b3kgYSByZXNlcXVlbmNpbmcgYnVmZmVyIGFzIHRoZSBwZW51bHRpbWF0ZSBob3AsIHNjcmV3ZWQg b250byB0aGUgcmVjZWl2aW5nIG1hY2hpbmUgaWYgbmVjZXNzYXJ5LCByYXRoZXIgdGhhbiByZXF1 aXJlIHBlci1ob3AgcmVzZXF1ZW5jaW5nIGluIHRoZSBuZXR3b3JrLg0KDQpfX19fX19fX19fX19f X19fDQpTbywgd2h5IGRvIEludGVybmV0IGxpbmtzIG9mdGVuIGVuc3VyZSBpbi1vcmRlciBkZWxp dmVyeSBldmVuIHRob3VnaCBUQ1AgcHV0cyBldmVyeXRoaW5nIGluIG9yZGVyIGZvciB0aGUgYXBw bGljYXRpb24/DQoNClNob3J0IGFuc3dlcjogdGhlIDMgRHVwQUNLIHJ1bGUgKHdoaWNoIGlzIHRv IGRvIHdpdGggbG9zcy1yZWNvdmVyeSwgYSBkaWZmZXJlbnQgaXNzdWUgZnJvbSB0aGUgZGlzY3Vz c2lvbiBhYm92ZSkuDQoNCkxvbmcgYW5zd2VyOiBBcyBmbG93IHJhdGVzIGhhdmUgc2NhbGVkIHVw LCB0aGUgdHlwaWNhbCB0aW1lIGJldHdlZW4gMyBwYWNrZXQgYXJyaXZhbHMgaGFzIGJlY29tZSBz byBzbWFsbCB0aGF0IFRDUCdzIDMtRHVwQUNLIHJ1bGUgbWFrZXMgbGlua3MgaGF2ZSB0byBwcm92 aWRlIGRlbGl2ZXJ5IHdpdGggb25seSBhIHZlcnkgc21hbGwgcmUtb3JkZXJpbmcgZGVncmVlIC0g c28gc21hbGwgdGhhdCBpdCdzIGVhc2llciBmb3IgYSBsaW5rIHRvIGp1c3QgZGVsaXZlciBldmVy eXRoaW5nIGluIHRoZSBvcmRlciBpdCByZWNlaXZlZCBpdDsgbm90IGJlY2F1c2UgVENQIGRvZXNu J3QgcHV0IHBhY2tldHMgYmFjayBpbiBvcmRlciwgYnV0IGp1c3Qgc28gYXMgbm90IHRvIHRyaWdn ZXIgVENQIGludG8gZ2VuZXJhdGluZyBzcHVyaW91cyByZXRyYW5zbWlzc2lvbnMuDQoNCg0KDQpC b2INCk9uIDA4LzExLzIwMTggMTY6MzUsIFNjaGFyZiwgTWljaGFlbCB3cm90ZToNCklubGluZSBb bXNdDQoNCkZyb206IEJvYiBCcmlzY29lIFttYWlsdG86aW5AYm9iYnJpc2NvZS5uZXRdDQpTZW50 OiBUaHVyc2RheSwgTm92ZW1iZXIgOCwgMjAxOCAxMjo1NiBQTQ0KVG86IFNjaGFyZiwgTWljaGFl bDsgdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCkNjOiB0c3Z3Z0BpZXRmLm9y ZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBDcm9zcy1hcmVh IGFsaWdubWVudCBvbiAiTDRTIGFuZCBSQUNLIg0KDQpNaWNoYWVsLA0KDQpUaGlzIGlzIG1lcmVs eSBhIHN5bXB0b20gb2YgYSBkaWZmZXJlbmNlIGluIG9waW5pb24gb24gd2hlcmUgdGhlIHJlc2Vx dWVuY2luZyBmdW5jdGlvbiBzaG91bGQgYmUgbG9jYXRlZC4NCg0KICAqICAgTDRTIHRha2VzIHRo ZSBlbmQtdG8tZW5kIGFwcHJvYWNoIHNheWluZyB0aGF0IGl0IGlzIHN1ZmZpY2llbnQgdG8gZG8g cmVzZXF1ZW5jaW5nIGluIG9uZSBwbGFjZSAodGhlIHJlY2VpdmluZyBob3N0KSBpZiBpdCBpcyBu ZWVkZWQuIFRoZW4gYW55IHJlc2VxdWVuY2luZyBkZWxheSBvbmx5IGFmZmVjdHMgdGhhdCBmbG93 Lg0KICAqICAgVGhlIERFVE5FVCBhcHByb2FjaCBpcyBzYXlpbmcgdGhlIHJlc2VxdWVuY2luZyBt dXN0IGJlIGRvbmUgaG9wLWJ5LWhvcC4gVGhpcyBtZWFucyB0aGVyZSBhcHBlYXJzIHRvIGJlIG5v IHJlc2VxdWVuY2luZyBuZWVkZWQgb24gdGhlIHJlY2VpdmVyIChleGNlcHQgaWYgdGhlcmUncyBy ZS1vcmRlcmluZyBvbiB0aGUgZmluYWwgaG9wKS4NCg0KDQogICogICBJbiBvcmRlciB0byBndWFy YW50ZWUgbm8gcmVzZXF1ZW5jaW5nIGluIHRoZSBuZXR3b3JrIChERVRORVQgYXBwcm9hY2gpLCBv bmx5IHRoZSB0aGUgd29yc3QgY2FzZSBsYXRlbmN5IGNhbiBiZSBndWFyYW50ZWVkLCBhbmQgZXZl cnkgcGFja2V0IGhhcyB0byBoYXZlIHRoYXQgc2FtZSB3b3JzdC1jYXNlIGxhdGVuY3kuDQogICog ICBXaGVuIHlvdSBsZWF2ZSByZXNlcXVlbmNpbmcgdG8gdGhlIHJlY2VpdmVyIChlbmQtdG8tZW5k IGFwcHJvYWNoKSwgbW9zdCBvZiB0aGUgcGFja2V0cyBhcnJpdmUgZWFybGllciB0aGFuIHRoZXkg d291bGQgd2l0aCBERVRORVQsIGJ1dCBvdXQgb2Ygb3JkZXIgb25lcyBtaWdodCBub3QuIFRoZW4g dGhlIGFwcGxpY2F0aW9uIGNob29zZXMgd2hldGhlciBpdCB3YW50cyB0byB3YWl0Lg0KW21zXSBN eSBwb2ludCBpcyBkaWZmZXJlbnQ6IFRoZXJlIHNlZW0gdG8gYmUgb3RoZXIgd29ya2luZyBncm91 cHMgaW4gdGhlIElFVEYgdGhhdCBkbyB0YWxrIGFib3V0IOKAnGxvdyBsYXRlbmN54oCdIGFzIHdl bGwgYnV0IGFwcGFyZW50bHkgdGhleSBhbHNvIGRvIG5lZWQgaW4tb3JkZXIgZGVsaXZlcnkgb2Yg cGFja2V0cywgdG9vLiBTbyB0aGUgYXNzdW1wdGlvbiB0aGF0IGUuZy4gYSBsaW5rIGxheWVyIHRl Y2hub2xvZ3kgY2FuIHNpbXBseSBkaXNhYmxlIGluLW9yZGVyIGRlbGl2ZXJ5IGZvciBhbGwg4oCc bG93IGxhdGVuY3nigJ0gYXBwbGljYXRpb25zIHNlZW1zIG5vdCBjb3JyZWN0LiBUaGUgcmVhbGl0 eSBtYXkgYmUgYSBiaXQgbW9yZSBjb21wbGV4Lg0KVGhlIDMgRHVwQUNLIHJ1bGUgaW4gVENQIGxl ZCB0aGUgSW50ZXJuZXQgbm90IHRvIGZvbGxvdyB0aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUgb24g cmUtc2VxdWVuY2luZy4gTm93IHdlJ3JlIHJlbW92aW5nIHRoZSAzIER1cEFDSyBydWxlLCB3ZSBj YW4gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGUyZSBwcmluY2lwbGUuDQpbbXNdIEZvciBUQ1AsIHRo cmVlIER1cEFDS1MgYXJlIGEgU0hPVUxEIGluIFJGQyA1NjgxIGFuZCBSRkMgNTY4MSBpcyBzdGFu ZGFyZHMgdHJhY2suIFNvIHRoZSBiYXIgZm9yIOKAnHJlbW92aW5n4oCdIHRoYXQgcnVsZSBmb3Ig VENQIGlzIG5vdCBsb3figKYNClttc10gQWxzbywgdGhlIGVuZC10by1lbmQgcHJpbmNpcGxlIGNv bWVzIHdpdGggdHJhZGVvZmZzLiBGb3IgaW5zdGFuY2UsIHJlbHlpbmcgb24gdGhlIGVuZC10by1l bmQgcHJpbmNpcGxlIGZvciByZWNvdmVyeSBvZiBiaXQgZXJyb3JzIGlzIG5vdCBlZmZpY2llbnQu IEZvciBpbi1vcmRlciBkZWxpdmVyeSB0aGVyZSBhcmUgdHJhZGVvZmZzIGFzIHdlbGwsIHNlZSBl LmcuIFNlY3Rpb24gNCBpbiBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNC4gVGhlcmUgbWF5IGJlIG5v IGZyZWUgbHVuY2guDQpPZiBjb3Vyc2UsIGFuIGFwcGxpY2F0aW9uIG1pZ2h0IGNob29zZSB0byB1 c2UgVENQIGFuZCBMNFMsIHJhdGhlciB0aGFuIFVEUCBhbmQgTDRTIChlLmcgUVVJQykuIFRoZW4g dGhlcmUgY291bGQgc3RpbGwgYmUgSG9MIGJsb2NraW5nIGluIHRoZSByZWNlaXZpbmcgVENQIHN0 YWNrLiBCdXQgYXQgbGVhc3QgdGhlcmUncyBubyBIb0wgYmxvY2tpbmcgaW4gdGhlIG5ldHdvcmss IGFuZCB0aGUgYXBwIGNhbiBjaG9vc2UgYmV0d2VlbiBzdHJlYW0gKFRDUCkgb3IgZGF0YWdyYW0g KFVEUCkuDQpbbXNdIElmIExSTy9HUk8gaW4gdGhlIHJlY2VpdmluZyBUQ1Agc3RhY2sgZ2V0cyBt ZXNzZWQgdXAsIEkgZmFpbCB0byBzZWUgdGhlIGJlbmVmaXQgKHNlZSBkcmFmdC1pZXRmLXRjcG0t cmFjay0wNCkuDQpNaWNoYWVsDQoNCg0KQm9iDQpPbiAwNi8xMS8yMDE4IDE5OjIwLCBTY2hhcmYs IE1pY2hhZWwgd3JvdGU6DQoNCkEgY29tbWVudCBvbiB0aGUgVENQTSBwcmVzZW50YXRpb24gIkw0 UyBhbmQgUkFDSyI6DQoNCg0KDQpBcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGUgREVUTkVUIFdH IGluIFJURyBhcmVhIGhhcyBxdWl0ZSBzb21lIHVzZXMgY2FzZXMgZm9yIHVsdHJhLWxvdyBsYXRl bmN5IHRyYW5zcG9ydCAtIGluIHBhcnRpY3VsYXIgYWxzbyB3aXRoIGJvdW5kZWQgaml0dGVyLiBB bmQgc29tZSBvZiB0aGVzZSBhcHBsaWNhdGlvbnMgKGUuZy4gdXNpbmcgVURQKSBhcHBhcmVudGx5 IG1heSBub3QgYmUgYWJsZSB0byB0b2xlcmF0ZSAqYW55KiBvdXQtb2Ytb3JkZXIgcGFja2V0IGRl bGl2ZXJ5Lg0KDQoNCg0KU28gcGVyaGFwcyBzb21lIGNyb3NzLWFyZWEgYWxpZ25tZW50IG9uIHVs dGEtbG93LWxhdGVuY3kgYXBwbGljYXRpb24gcmVxdWlyZW1lbnRzIHdvdWxkIGJlIHVzZWZ1bD8N Cg0KDQoNCk1pY2hhZWwNCg0KKHdobyByZWNlbnRseSBoYWQgdG8gcmV2aWV3IGRyYWZ0LWlldGYt ZGV0bmV0LWFyY2hpdGVjdHVyZSkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQotLQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2Ji cmlzY29lLm5ldC88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cCUzQSUyRiUyRmJvYmJyaXNjb2UubmV0JTJGJmRhdGE9MDIlN0MwMSU3Q3ByYXZi JTQwbWljcm9zb2Z0LmNvbSU3QzU0N2U1MDNlMjE4NTQ5NDgzZjMwMDhkNjQ2NzQ5NWI5JTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3Mzg2Mzg5NTUwNjUx MSZzZGF0YT0lMkI0WG9sbkt5UG5ZNUN1OGt0dVdYaTJTSjVxYm9ON0JyOSUyQjZETXJDSG5tYyUz RCZyZXNlcnZlZD0wPg0KDQoNCg0KDQoNCg0KLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpCb2IgQnJpc2NvZSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9iYnJpc2NvZS5uZXQvPGh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYl MkZib2JicmlzY29lLm5ldCUyRiZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20l N0M1NDdlNTAzZTIxODU0OTQ4M2YzMDA4ZDY0Njc0OTViOSU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3NzM4NjM4OTU1MTY1MTUmc2RhdGE9eFpQdmRxa1BX dDBCMVJhR2xvMHU1UHZyeWphem1xam05OHBWMDB6T01XdyUzRCZyZXNlcnZlZD0wPg0KDQoNCg0K DQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0LzxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGYm9iYnJpc2NvZS5uZXQlMkYmZGF0 YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDNTQ3ZTUwM2UyMTg1NDk0ODNmMzAw OGQ2NDY3NDk1YjklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM2NzczODYzODk1NTI2NTI0JnNkYXRhPVNwT0olMkZkdXdTRVJEbXNsRHl0d05MTklKNUw0T3h2 cFR6bmNhQXgwb0ZyVSUzRCZyZXNlcnZlZD0wPg0KDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJv YiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29l Lm5ldC88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cCUzQSUyRiUyRmJvYmJyaXNjb2UubmV0JTJGJmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWlj cm9zb2Z0LmNvbSU3QzU0N2U1MDNlMjE4NTQ5NDgzZjMwMDhkNjQ2NzQ5NWI5JTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3Mzg2Mzg5NTUyNjUyNCZzZGF0 YT1TcE9KJTJGZHV3U0VSRG1zbER5dHdOTE5JSjVMNE94dnBUem5jYUF4MG9GclUlM0QmcmVzZXJ2 ZWQ9MD4NCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0LzxodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGYm9iYnJpc2NvZS5u ZXQlMkYmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDNTQ3ZTUwM2UyMTg1 NDk0ODNmMzAwOGQ2NDY3NDk1YjklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 QzElN0MwJTdDNjM2NzczODYzODk1NTM2NTM3JnNkYXRhPWx5QmhjWFU3NFNVNTZzN3FyMU9VU2Z3 YUlMNjhMY2JGN1dKeHRteiUyQlViMCUzRCZyZXNlcnZlZD0wPg0K --_000_MW2PR2101MB1049EAF866AFA35983A31167B6C60MW2PR2101MB1049_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyBcLCBzZXJpZiI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNv bG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCgljb2xvcjpibGFj azt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWww LCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3Jt YWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFj azt9DQpwLkhUTUxWb3Jmb3JtYXRpZXJ0LCBsaS5IVE1MVm9yZm9ybWF0aWVydCwgZGl2LkhUTUxW b3Jmb3JtYXRpZXJ0DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFZvcmZvcm1hdGllcnQiOw0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNobiI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxWb3Jmb3Jt YXRpZXJ0WmNobg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRp ZXJ0IjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWls U3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCA1Ni43cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjI1OTkyMDM5NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2NTYyODczMjt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NTIxNDMxMjY1Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTQxMzQ0NjQwODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6OTQ2MDQx NjQyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotOTQxNDQ1Mzc0O30NCkBsaXN0IGwyOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDMNCgl7bXNvLWxpc3QtaWQ6MTM0MDM1MjkzMTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6Nzgw ODUyMDcwO30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTYyNzUzODE5ODsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTgxNzE2OTM3NDt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1DQoJe21z by1saXN0LWlkOjIxMjE4NzA3Mzc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTkzMTUwMDEy O30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwy DQoJe21zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDU6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNTpsZXZl bDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mZ3Q7 Jmd0Ozwvc3Bhbj4gVGhlcmVmb3JlIHRoZXkgY2FuIGVzdGltYXRlIHRoZSBtYXggcmVvcmRlcmlu ZyB0aGV5IGFsbG93IHRoZWlyIGxpbmtzIHRvIGludHJvZHVjZTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SU1PIEwyIHNob3VsZG7igJl0IDxpPmludHJvZHVjZTwvaT4gbW9y ZSByZW9yZGVyaW5nIGp1c3QgYmVjYXVzZSBMNA0KPGk+Y29uZ2VzdGlvbiBjb250cm9sPC9pPiBp cyBtb3JlIHJlc2lsaWVudCB0byBpdC4gVGhlcmUgaXMgb3RoZXIgcGVyZm9ybWFuY2UgaW1wYWN0 IGR1ZSB0byByZW9yZGVyaW5nOiBMUk8gLyBHUk8gLyBSU0Mgb3Bwb3J0dW5pdHkgd2lsbCBiZSBy ZWR1Y2VkLCBtb3JlIG1lbW9yeSBhbmQgQ1BVIGNvc3QgdG8gZG8gcmVhc3NlbWJseSBhdCBMNCAo dGhpcyBpcyBhbiBhY3RpdmUgYXJlYSBmb3IgcmVtb3RlIGF0dGFja3MpIGV0Yy4gSU1PIEw0IGd1 aWRhbmNlDQogc2hvdWxkIHJlbWFpbiB0aGF0IGxpbmsgdmVuZG9ycyBtdXN0IGF2b2lkIHJlb3Jk ZXJpbmcgYXMgbXVjaCBhcyBwb3NzaWJsZSBhbmQgbm90IGJ1aWxkIHNvbHV0aW9ucyB0aGF0IGNh dXNlIGZyZXF1ZW50IG9yIGNvbnNpc3RlbnQgcmVvcmRlcmluZy4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IHRjcG0gJmx0O3RjcG0t Ym91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+Qm9iIEJyaXNjb2U8YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IDEwOjUyIEFNPGJyPg0KPGI+ VG86PC9iPiBTY2hhcmYsIE1pY2hhZWwgJmx0O01pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5k ZSZndDs7IHRjcG1AaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHRzdndnQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBv biAmcXVvdDtMNFMgYW5kIFJBQ0smcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk1pY2hhZWwsPGJy Pg0KPGJyPg0KVGhlIGlkZWEgaXMgdGhhdCAoYXMgbm93IGluIHRoZSBSQUNLIGRyYWZ0IHNpbmNl IGRpc2N1c3Npb24gb24gdGhlIHRjcG0gbGlzdCBlYXJsaWVyIHRoaXMgeWVhciB1bmRlciBhIHN1 YmplY3Qgc29tZXRoaW5nIGxpa2UgdmljaW91cyBjaXJjbGUgb3IgdmlydHVvdXMgY2lyY2xlKSB0 aGVyZSB3aWxsIGJlIGEgbGltaXQgb24gdGhlIGluaXRpYWwgUkFDSyByZW9yZGVyaW5nIHdpbmRv dyBleHByZXNzZWQgaW4gZnJhY3Rpb25hbCBSVFQgdW5pdHMuPGJyPg0KPGJyPg0KTGluayB2ZW5k b3JzIGtub3cgdGhlIG1pbiBlMmUgUlRUIG9mIHRoZSBwYXRocyB0aGF0IHRoZWlyIGxpbmtzIGFy ZSB1c3VhbGx5IGRlcGxveWVkIG92ZXIuIFRoZXJlZm9yZSB0aGV5IGNhbiBlc3RpbWF0ZSB0aGUg bWF4IHJlb3JkZXJpbmcgdGhleSBhbGxvdyB0aGVpciBsaW5rcyB0byBpbnRyb2R1Y2UuPGJyPg0K PGJyPg0KSSBkb24ndCBleHBlY3QgdGhpcyBsaW1pdCB0byBiZSBzZXQgaW4gc3RvbmUgd2hpbGUg Ym90aCBSQUNLIGFuZCBMNFMgYXJlIGV4cGVyaW1lbnRhbC4gQnV0IGFzIGJvdGggdGhlc2UgZXhw ZXJpbWVudHMgcHJvZ3Jlc3MsIEkgdGhpbmsgdGhlIGluZHVzdHJ5IHdpbGwgZ2V0IGEgYmV0dGVy IGlkZWEgb2Ygd2hlcmUgdGhlIGxpbWl0IHNob3VsZCBsaWUuPGJyPg0KPGJyPg0KSXQgd2FzIHRo ZSByZWFsaXphdGlvbiB0aGF0LCBpZiBUQ1AgYWRhcHRlZCBpdHMgcmVvcmRlcmluZyB3aW5kb3cg dG8gdGhlIG1lYXN1cmVkIHJlb3JkZXJpbmcgZGVncmVlIHdpdGhvdXQgYm91bmQsIHRoZSBMMiB3 b3JsZCB3b3VsZCBjb250aW51YWxseSBpbmNyZWFzZSB0aGUgcmVvcmRlcmluZyBkZWdyZWUgb2Yg dGhlaXIgbGlua3MgKHRoZSB2aWNpb3VzIGNpcmNsZSkuPGJyPg0KPGJyPg0KSWYgdGhlcmUgaXMg YW55IGFzcGVjdCBvZiB0aGlzIGxpbWl0IGV4cHJlc3NlZCBpbiB1bml0cyBvZiBwYWNrZXRzLCB0 aGUgbGltaXQgd2lsbCBkZWNyZWFzZSBpbiB0aW1lIGFzIGZsb3cgcmF0ZXMgaW5jcmVhc2UsIGFu ZCB0aGVyZWZvcmUgbm90IHNlcnZlIHRvIGdpdmUgdGhlIEwyIHdvcmxkIGFueSBjbGVhciBndWlk YW5jZSAtIG5vIGRlIGZhY3RvIGxpbWl0IGFncmVlZCBiZXR3ZWVuIHRoZSBMNCB3b3JsZCBhbmQg dGhlIEwyIHdvcmxkLg0KPGJyPg0KPGJyPg0KSWYgd2Uga2VlcCB0aGUgbGltaXQgaW4gdW5pdHMg b2YgUlRULCBob3BlZnVsbHkgdGhlbiB3ZSBoYXZlIGEgdmlydHVvdXMgY2lyY2xlLCBub3QgYSB2 aWNpb3VzIGNpcmNsZS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA5LzExLzIwMTggMTg6MjgsIFNjaGFyZiwgTWljaGFl bCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBtYXkgbWlzcyBzb21ldGhpbmcsIGJ1dCBJ IHJlYWQgdGhlIG91dGNvbWUgb2YgdGhlIGFwcGVuZGl4IGFzIGEgcmVxdWlyZW1lbnQg4oCcbXVz dCBiZSBtb3JlIHJvYnVzdCB0byByZW9yZGVyaW5n4oCdLiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5k LCB0aGF0IGNhbiBiZSBpbXBsZW1lbnRlZA0KIGluIGRpZmZlcmVudCB3YXlzLiA8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCBJIG1heSBiZSB3cm9uZywgYnV0 IHRob3NlIGxpbmsgdGVjaG5vbG9naWVzIGNvdWxkIGJlIHdlbGwgaW1wbGVtZW50ZWQgaW4gYSBy b3V0ZXIgYW5kIHRoZW4gb25lIG5lZWRzIHRvIGFuYWx5emUgaG93IHRoYXQgd2hvbGUgYXJjaGl0 ZWN0dXJlIGZpdHMgaW50byB0aGUNCiBzY2hlZHVsZXIsIHF1ZXVlLCBwb2xpY2VyLCBhbmQgbGlu ZSBjYXJkIGhhcmR3YXJlIGRlc2lnbiBvZiBhIHJvdXRlci4gQnV0IHRoYXQgaXMgc29tZXRoaW5n IHJvdXRpbmcgcGVvcGxlIGtub3cgYmV0dGVyIHRoYW4gbWUuIE15IHBvaW50IGlzIGp1c3QgdG8g Z2V0IHRoZSBleHBlcnRzIGludG8gdGhlIGxvb3AgZWFybHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NaWNoYWVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgWzxh IGhyZWY9Im1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0Ij5tYWlsdG86aWV0ZkBib2JicmlzY29l Lm5ldDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IDc6 MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbDsgPGEgaHJlZj0ibWFpbHRvOnRj cG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt YWlsdG86dHN2d2dAaWV0Zi5vcmciPnRzdndnQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAmcXVvdDtMNFMgYW5kIFJB Q0smcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk1pY2hhZWwsPGJyPg0KPGJyPg0KUGxlYXNlIGFk ZHJlc3MgdGhlIHNjYWxpbmcgcmF0aW9uYWxlIGluIHRoZSBhcHBlbmRpeCBmb3Igd2h5IGl0IGRv ZXMgbWF0dGVyIGhvdyBhIHNlbmRlciByZWFsaXplcyB0aGlzIGludGVybmFsbHkuPGJyPg0KPGJy Pg0KVGhlIGxpc3Qgb2YgYWNjZXNzIGxpbmtzIHR5cGVzIEkgbWVudGlvbmVkIGFyZSByYXJlbHkg Y29ubmVjdGVkIGRpcmVjdGx5IHRvIHJvdXRlcnMuDQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpC b2I8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwOS8xMS8y MDE4IDE3OjQ0LCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkni gJlsbCBub3QgY29tbWVudCBvbiBsaW5rIHRlY2hub2xvZ3kgaW1wbGVtZW50YXRpb24sIHNjaGVk dWxlciBhbmQgcXVldWUgZGVzaWduIGFzc3VtcHRpb25zIGluIEFwcGVuZGl4IEEuMS43IG9mIGRy YWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNS4gUGVvcGxlIGUuZy4gaW4NCiBSVEcgYXJlYSBt YXkgYmUgbW9yZSBmYW1pbGlhciB3aXRoIHRoZSBpbXBsaWNhdGlvbnMgb2YgaW50ZXJuYWwgZGVz aWducyBlLmcuIGluc2lkZSBhIHJvdXRlci4gSU1ITyB0aGUgYmVzdCB3YXkgdG8gZ2V0IHJvdXRp bmcgZXhwZXJ0cyBpbnRvIHRoZSBsb29wIGJlZm9yZSBmdXJ0aGVyIGRpc2N1c3Npbmcgd2hhdCBp cyBjdXJyZW50bHkgbGlzdGVkIGluIEFwcGVuZGl4IEEuMS43Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGh1cywgSSBsaW1pdCBteSByZXNwb25zZSB0byB0aGUg YWN0dWFsIHdvcmRpbmcgaW4gdGhlIG1haW4gcGFydCBvZiBkcmFmdC1pZXRmLXRzdndnLWVjbi1s NHMtaWQtMDU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyBvJm5ic3A7IEEgc2NhbGFibGUgY29uZ2VzdGlvbiBjb250cm9sIE1VU1QgZGV0ZWN0 IGxvc3MgYnkgY291bnRpbmcgaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyAsIHNlcmlmJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdW5pdHMgb2YgdGltZSwgd2hpY2ggaXMgc2NhbGFibGUsIGFuZCBNVVNUIE5PVCBjb3Vu dCBpbiB1bml0cyBvZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3ICwgc2VyaWYmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBw YWNrZXRzIChhcyBpbiB0aGUgMyBEdXBBQ0sgcnVsZSBvZiB0cmFkaXRpb25hbCBUQ1ApLCB3aGlj aCBpcyBub3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAs IHNlcmlmJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2NhbGFi bGUgKHNlZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48YSBocmVmPSJo dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz QSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1p ZC0wNSUyM2FwcGVuZGl4LUEuMS43JmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29m dC5jb20lN0M1NDdlNTAzZTIxODU0OTQ4M2YzMDA4ZDY0Njc0OTViOSU3QzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3NzM4NjM4OTU0OTY0OTgmYW1wO3NkYXRh PSUyQmV6OU9DWmkxbTV3eDdUR0hrdmZHOVFzSmZKMFZ4aHNYeW5xV1cyalhHNCUzRCZhbXA7cmVz ZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcgLCBzZXJpZiZxdW90OyxzZXJpZiI+QXBwZW5kaXgNCiBBLjEuNzwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssc2VyaWYiPiBmb3IgcmF0aW9uYWxlKS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFzIGluZGl2aWR1YWwgY29udHJp YnV0b3IsIEkgZGlzYWdyZWUgd2l0aCB0aGlzIHJlcXVpcmVtZW50LiBJIHdvdWxkIHByb2JhYmx5 IGJlIE9LIHdpdGggYSB3b3JkaW5nIHRoYXQgYSBUQ1Agc2VuZGVyIG11c3QgYmUgYWJsZSB0byB0 b2xlcmF0ZSByZW9yZGVyaW5nIGJleW9uZA0KIDMgRHVwbGljYXRlIEFDS3MuIEkgYmVsaWV2ZSBp dCBkb2VzIG5vdCBtYXR0ZXIgaG93IGEgc2VuZGVyIHJlYWxpemVzIHRoaXMgaW50ZXJuYWxseS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZCBpZiB0aGF0IHJl cXVpcmVtZW50IGlzIG5vdCBqdXN0IHJlbW92ZWQsIEkgYmVsaWV2ZSB0aGUgd29yZGluZyDigJx0 cmFkaXRpb25hbCBUQ1DigJ0gaGFzIHRvIGJlIHJlcGxhY2VkIGJ5IOKAnHN0YW5kYXJkIFRDUOKA nS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJUVywgYWxzbywg aW4gdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50IHRoZXJlIGhhcyB0byBiZSBhIGNsZWFyIGRpc3Rp bmN0aW9uIGJldHdlZW4gZXhwZXJpbWVudHMgYW5kIHN0YW5kYXJkcy4gSGlzdG9yeSB0ZWxscyB1 cyB0aGF0IHNvbWUgZXhwZXJpbWVudHMgY2FuIGV2b2x2ZQ0KIGludG8gc3RhbmRhcmRzIHRyYWNr IHNwZWNpZmljYXRpb25zLCB3aGlsZSBvdGhlciBleHBlcmltZW50cyBtYXkgZmFpbC4gQW5kIHRo ZXJlIGlzIG5vIHdheSBvZiBrbm93aW5nIHRoYXQgaW4gYWR2YW5jZS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29lIFs8YSBocmVmPSJtYWlsdG86aWV0ZkBi b2JicmlzY29lLm5ldCI+bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgTm92ZW1iZXIgOSwgMjAxOCAxMTowOCBBTTxicj4NCjxiPlRvOjwv Yj4gU2NoYXJmLCBNaWNoYWVsOyA8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBp ZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9y ZyI+dHN2d2dAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHN2d2ddIENy b3NzLWFyZWEgYWxpZ25tZW50IG9uICZxdW90O0w0UyBhbmQgUkFDSyZxdW90Ozwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+TWljaGFlbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAwOS8xMS8yMDE4IDA2OjIxLCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCBzZWUgdGhlIGZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgYmV0 d2VlbiBhIGxpbmsgdGVjaG5vbG9neSB0aGF0IGd1YXJhbnRlZXMgaW4tb3JkZXIgZGVsaXZlcnkg d2l0aGluIGEgZmxvdyAoc2F5IGJ5IGZsb3cgaGFzaGluZywgc2VlIEVDTVApIHZzLiBzb21lIGxp bmsNCiBzY2hlbWUgdGhhdCBndWFyYW50ZWVzIGluLW9yZGVyIGRlbGl2ZXJ5LCBzYXksIG9ubHkg Zm9yIHNvbWUgZnJhY3Rpb24gb2YgdGhlIHRyYWZmaWMgY2hhcmFjdGVyaXplZCBieSBzb21lIG90 aGVyIG1lYW5zIChzYXksIG90aGVyIGhlYWRlciBiaXRzKS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bVGhlICZxdW90O290aGVyIG1l YW5zJnF1b3Q7IGFuZCAmcXVvdDtvdGhlciBiaXRzJnF1b3Q7IHdvcmRpbmcgaXMgcHJldHR5IGFt YmlndW91cyBoZXJlLiBJIHJlY2tvbiBJIGNhbiBndWVzcyB3aGF0IHlvdSBtZWFuIGJ1dCB0aGVu IEkgZG9uJ3Qga25vdyB3aHkgeW91J3JlIHNheWluZyB0aGlzLCAnY29zIEkgZG9uJ3QgdGhpbmsg SSd2ZSBkaXNhZ3JlZWQgd2l0aCB5b3Ugb24gdGhpcy4gU28gcGVyaGFwcyB5b3UgY291bGQgYmUg bW9yZSBzcGVjaWZpYw0KIGFuZCB3ZSBtaWdodCBiZSBhYmxlIHRvIHNlZSB3aHkgeW91J3ZlIGJy b3VnaHQgdGhpcyB1cC5dPGJyPg0KPGJyPg0KQWxzbyBJIHdhc24ndCByZWFsbHkgdGFsa2luZyBh Ym91dCBhbGwgJnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmxpbmsgdGVjaG5v bG9neSB0aGF0IGd1YXJhbnRlZXMgaW4tb3JkZXIgZGVsaXZlcnkgd2l0aGluIGEgZmxvdzwvc3Bh bj4mcXVvdDsuIHtOb3RlIDF9IEkgd2FzIHRhbGtpbmcgYWJvdXQgbGluayB0ZWNobm9sb2d5IHdo ZXJlIGFsbCBmbG93cyBhcmUgYmxvY2tlZA0KIHdoaWxlIHdhaXRpbmcgdG8gZ2V0IHRoZSBhZ2dy ZWdhdGUgYmFjayBpbiBvcmRlciB0aGF0IGl0IHdhcyBpbiB3aGVuIGl0IGFycml2ZWQuIEkgc3Bl Y2lmaWNhbGx5IHNhaWQ6PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RlIHRoYXQgdGhlcmUgY2FuIGJlIG11bHRpcGxlIGZsb3dz IG92ZXIgb25lIGxpbmsuIFNvICdpbi1vcmRlciBkZWxpdmVyeScgZm9yIGEgbGluayBkb2VzIG5v dCBtZWFuIGluIG9yZGVyIG9mIFRDUCBzZXF1ZW5jZSBudW1iZXIuIEl0IG1lYW5zICdkZWxpdmVy ZWQgaW4gdGhlIG9yZGVyIHRoYXQgcGFja2V0cyBhcnJpdmVkIGF0IHRoZSBsaW5rJyAodGhlIGxp bmsgaW5ncmVzcyBhZGRzIGl0cyBvd24gc2VxdWVuY2UNCiBudW1iZXJzLCBhbmQgdGhlIGxpbmsg ZWdyZXNzIGJ1ZmZlcnMgdGhlbSB1bnRpbCBpdCBjYW4gc2VuZCBvdXQgaW4gdGhlIHNhbWUgb3Jk ZXIsIG9yIHVudGlsIGEgdGltZS1vdXQgb3IgbWF4IG5vLiBvZiBsaW5rIHJldHJhbnNtaXNzaW9u cykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZXhhbXBsZTo8bzpw PjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KQSBwYWNrZXQgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBhZnRl ciBhbGxvd2luZyBmb3IgbGluay1sYXllciByZXRyYW5zbWlzc2lvbnMgaXMgY29tbW9uIGZvciBy YWRpbyBsaW5rIHRlY2hub2xvZ2llcyBzdWNoIGFzIExURSAoUERDUCBsYXllcikgYW5kIDgwMi4x MSBXaUZpLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzMiPg0KQSBwYWNrZXQgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBhZnRlciBtZXJn aW5nIG11bHRpcGxlIGJvbmRlZCBsaW5rIGNoYW5uZWxzIGlzIGNvbW1vbiBmb3Igb3RoZXIgYWNj ZXNzIGxpbmsgdGVjaG5vbG9naWVzIHN1Y2ggYXMgZG93bnN0cmVhbSBET0NTSVMgYm9uZGVkIGNo YW5uZWxzLg0KPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Q2xlYXJseSwgcmVvcmRlcmluZyBpcyBhIHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSBkaXNjdXNz ZWQgaW4gdGhlIElFVEYgYXMgYSB3aG9sZS4gQW5kIHdlIGNvdWxkIGRpc2N1c3Mgd2hldGhlciBh IHJldmlzaW9uIG9mIFJGQyAzMzY2IGlzIG5lZWRlZC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLiBUaGVyZSBpcyBubyBwcm9wb3NhbCB0byBhbHRlciBn ZW5lcmFsIGd1aWRhbmNlIGZvciBhbGwgbGlua3MgbGlrZSBSRkMgMzM2Ni4gTm8tb25lIGlzIHNh eWluZyB0aGlzLjxicj4NCjxicj4NClRoZXJlIGlzIG5vdCBldmVuIGEgcHJvcG9zYWwgdG8gcmVx dWlyZSBvciBldmVuIHJlY29tbWVuZCB0aGF0IEw0Uy1zcGVjaWZpYyBsaW5rcyBkbyBhbnl0aGlu Zy4NCjxicj4NCjxicj4NClRoZSBzcGVjaWZpYyBwcm9wb3NhbCBpcyB0byByZXF1aXJlIEw0UyA8 aT5zb3VyY2VzPC9pPiB0byB1c2UgYSBSQUNLLWxpa2Ugc2NoZW1lLCBhcyBhIGNvbmRpdGlvbiBm b3Igc2V0dGluZyB0aGUgRUNUKDEpIGNvZGVwb2ludC4gU2VlIHRoZSBsYXN0IGJ1bGxldCBpbg0K PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1pZXRmLXRzdndn LWVjbi1sNHMtaWQtMDUlMjNzZWN0aW9uLTQuMyZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBt aWNyb3NvZnQuY29tJTdDNTQ3ZTUwM2UyMTg1NDk0ODNmMzAwOGQ2NDY3NDk1YjklN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NzczODYzODk1NTA2NTExJmFt cDtzZGF0YT1tJTJGbjZITlFuSlliVFBJbzBNUjhjVFhLZmNqMERYNTc5SEF5RDlMTWU0YVElM0Qm YW1wO3Jlc2VydmVkPTAiPg0KUy40LjMgb2YgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA1 PC9hPi4gPGJyPg0KPGJyPg0KVGhpcyBzYXlzIG5vdGhpbmcgYWJvdXQgd2hhdCBMNFMgbGlua3Mg TVVTVCwgU0hPVUxEIG9yIE1BWSBkby4gSXQganVzdCBnaXZlcyBhbiBMNFMgbGluayBhbiBvcHBv cnR1bml0eSBub3QgdG8gaGF2ZSB0byBkbyByZXNlcXVlbmNpbmcuPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJ1dCBJIGFt IG5vdCBjb252aW5jZWQgdGhhdCB0aGlzIHRvcGljIGhhcyB0byBiZSB0aWVkIGludG8gYW4gZXhw ZXJpbWVudCBzdWNoIGFzIEw0Uy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JdCBpcyBhbiBvcHBvcnR1bml0eSB0aGF0IGN1cnJlbnRseSBvbmx5IGFwcGxpZXMg dG8gTDRTLiA8YnI+DQo8YnI+DQpMNFMgaXMgbWVyZWx5IGFuIGV4YW1wbGUgb2YgYSBjYXNlIHdo ZXJlIHdlIGNhbiBtYW5kYXRlIHRoYXQgdGhlcmUgd2lsbCBiZSBubyBub24tUkFDSyB0cmFmZmlj IGluIGEgbGluaywgd2hpY2ggY3JlYXRlcyBhbiBvcHBvcnR1bml0eSBmb3IgdGhvc2Ugd2hvIGFy ZSBpbXBsZW1lbnRpbmcgdGhlIEw0UyBEdWFsUSBDb3VwbGVkIEFRTSB0byBpZ25vcmUgdGhlIFJG QzMzNjYgcmVzZXF1ZW5jaW5nIGFkdmljZSBmb3IgdGhlIEw0UyBxdWV1ZSAoYnV0DQogd2UgYXJl IG5vdCBjaGFuZ2luZyB0aGUgYWR2aWNlLCBiZWNhdXNlIEw0UyBpcyBvbmx5IGFuIGV4cGVyaW1l bnQpLiBUaGUgcHJpemUgaXMgdG8gcmVtb3ZlIHRoZSBoZWFkLW9mLWxpbmUgYmxvY2tpbmcgcHJv YmxlbSBmb3IgdGhlaXIgdXNlcnMuDQo8YnI+DQo8YnI+DQpUaGlzIGlzIG5vdCBMNFMtc3BlY2lm aWMsIGFsdGhvIHRoZXJlIGFyZSBubyBvdGhlciBleGFtcGxlcyBhdCB0aGUgbW9tZW50IHdoZXJl IHRoaXMgb3Bwb3J0dW5pdHkgaXMgcG9zc2libGUgKHNvIGluIHRoYXQgc2Vuc2UgaXQgaXMNCjxp PmN1cnJlbnRseTwvaT4gTDRTLXNwZWNpZmljKS48YnI+DQo8YnI+DQo8YnI+DQpUaGUgbWVzc2Fn ZSBoYXMgdG8gYmUgaGFuZGxlZCByZWFsbHkgY2FyZWZ1bGx5LCBiZWNhdXNlIHRoZSBvcHBvcnR1 bml0aWVzIGZvciBtaXN1bmRlcnN0YW5kaW5nIGFyZSBlbm9ybW91cyAoYXMgZXZpZGVuY2VkIGJ5 IHRoaXMgdGhyZWFkLCBhbmQgd2UgaGF2ZW4ndCBldmVuIHN0YXJ0ZWQgdGFsa2luZyB0byBub24t dHJhbnNwb3J0IHBlb3BsZSB5ZXQpLjxicj4NCjxicj4NClNvIEdvcnJ5IGFuZCBEYXZpZCBCIHdh bnQgbWUgdG8gZHJhZnQgYSBzaG9ydCBJLUQgdGhhdCB0aGV5IHdpbGwgd29yZC1zbWl0aCBhbmQg YXV0aG9yIGFzIHRzdndnIGNoYWlycyB0byBtYWtlIHRoZSBzaXR1YXRpb24gY2xlYXIuPGJyPg0K PGJyPg0KSSBoYXZlIHNhaWQgSSBkb24ndCB3YW50IHRoaXMgZGlzY3Vzc2lvbiB0byBiZSBvZmZp Y2lhbGx5IHJhaXNlZCBvdXRzaWRlIHRoZSB0cmFuc3BvcnQgYXJlYSB1bnRpbCB3ZSBhcmUgc3Vy ZSB0aGF0IGEgdmFyaWFudCBvZiBSQUNLIGlzIGV2ZW4gZmVhc2libGUgd2l0aG91dCBhbnkgcGFj a2V0IGNvdW50aW5nIGF0IGFsbCAoaS5lLiB3aXRob3V0IHRoZSBpbml0aWFsIDMtRHVwQUNLIHJ1 bGUgaW4gY3VycmVudCBSQUNLKS4gU28gSSdsbCBwcmlvcml0aXplDQogd29ya2luZyB0aGF0IG91 dCBmb3IgdGhlIG5leHQgd2VlayBvciBzbywgcmF0aGVyIHRoYW4gZHJhZnRpbmcgYW55dGhpbmcu PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQm9iPGJyPg0KPGJyPg0Ke05vdGUgMX06IEkgaGFkbid0 IGNvbnNpZGVyZWQgdGhhdCB0aGlzIHdvdWxkIGFmZmVjdCB0ZWNobm9sb2dpZXMgbGlrZSBFQ01Q IHRoYXQgbWFpbnRhaW4gb3JkZXIgd2l0aG91dCBhIHJlc2VxdWVuY2luZyBidWZmZXIgYW5kIHdp dGhvdXQgaW50cm9kdWNpbmcgSG9MIGJsb2NraW5nLiBCdXQgYWN0dWFsbHksIHRoZSBjb25zZXF1 ZW5jZSB0aGVyZSB3b3VsZCBiZSB0aGF0IEw0UyB0cmFmZmljIGNvdWxkIGJlIHNwcmF5ZWQgYnkg RUNNUCB3aXRob3V0DQogcGVyLWZsb3cgaGFzaGluZy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgWzxhIGhyZWY9 Im1haWx0bzppbkBib2JicmlzY29lLm5ldCI+bWFpbHRvOmluQGJvYmJyaXNjb2UubmV0PC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDksIDIwMTggNjo0MiBBTTxicj4N CjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNoYWVsOyA8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9y ZyI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0c3Z3 Z0BpZXRmLm9yZyI+dHN2d2dAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb dHN2d2ddIENyb3NzLWFyZWEgYWxpZ25tZW50IG9uICZxdW90O0w0UyBhbmQgUkFDSyZxdW90Ozwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+TWljaGFlbCw8YnI+DQo8YnI+DQpUaGF0IGlzIHRoZSBwb2ludCBJ IHRob3VnaHQgeW91IHdlcmUgbWFraW5nLCBhbmQgbXkgcG9pbnQgL2lzLyBhYm91dCB0aGF0Ljxi cj4NCjxicj4NCklmIGFuIGFwcGxpY2F0aW9uIG5lZWRzIGFsbCB0aGUgcGFja2V0cyAoaS5lLiBh IHJlbGlhYmxlIHByb3RvY29sKSwgaXQncyBub3QgdXNlZnVsIHRvIHJlZHVjZSB0aGUgbGF0ZW5j eSBvZiBzb21lIHBhY2tldHMgYnV0IG5vdCBhbGwuIFRoYXQncyB3aGVyZSB0aGUgaW4tb3JkZXIg cmVxdWlyZW1lbnQgY29tZXMgZnJvbS48YnI+DQo8YnI+DQpIb3dldmVyLCBpZiBhIHN0cmVhbS1i YXNlZCB0cmFuc3BvcnQgaXMgdXNlZCAoaS5lLiBUQ1ApIHRoZSAvYXBwbGljYXRpb24vIHN0aWxs IGdldHMgaW4tb3JkZXIgZGVsaXZlcnkgZnJvbSBUQ1AuIEl0IGp1c3QgZG9lc24ndCBoYXZlIHRv IHJlcXVpcmUgbGlua3MgdG8gcHJvdmlkZSBpbiBvcmRlciBkZWxpdmVyeSBhcyB3ZWxsLjxicj4N Cjxicj4NCk5vdGUgdGhhdCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgZmxvd3Mgb3ZlciBvbmUgbGlu ay4gU28gJ2luLW9yZGVyIGRlbGl2ZXJ5JyBmb3IgYSBsaW5rIGRvZXMgbm90IG1lYW4gaW4gb3Jk ZXIgb2YgVENQIHNlcXVlbmNlIG51bWJlci4gSXQgbWVhbnMgJ2RlbGl2ZXJlZCBpbiB0aGUgb3Jk ZXIgdGhhdCBwYWNrZXRzIGFycml2ZWQgYXQgdGhlIGxpbmsnICh0aGUgbGluayBpbmdyZXNzIGFk ZHMgaXRzIG93biBzZXF1ZW5jZSBudW1iZXJzLCBhbmQgdGhlDQogbGluayBlZ3Jlc3MgYnVmZmVy cyB0aGVtIHVudGlsIGl0IGNhbiBzZW5kIG91dCBpbiB0aGUgc2FtZSBvcmRlciwgb3IgdW50aWwg YSB0aW1lLW91dCBvciBtYXggbm8uIG9mIGxpbmsgcmV0cmFuc21pc3Npb25zKS48YnI+DQo8YnI+ DQpTbywgaWYgdGhlIGxpbmsgbG9zZXMgYSBwYWNrZXQgZnJvbSBmbG93IEEgKHRoZSBsaW5rIGlz bid0IGF3YXJlIG9mIG1pY3JvZmxvd3MsIEknbSBqdXN0IHNheWluZyB0aGUgcGFja2V0IGhhcHBl bnMgdG8gYmUgZnJvbSBmbG93IEEpLCBsaW5rLWxheWVyIGluLW9yZGVyIGRlbGl2ZXJ5IHdpbGwg aG9sZCBiYWNrIGFsbCBwYWNrZXRzIHNlbnQgYWZ0ZXIgdGhhdCBwYWNrZXQgKGZyb20gYWxsIGZs b3dzLCBub3QganVzdCBmbG93IEEpIHVudGlsIHRoZQ0KIGxpbmsgcmVwYWlycyB0aGUgZ2FwIG9y IGdpdmVzIHVwLiA8YnI+DQo8YnI+DQpTbyBob3AtYnktaG9wIGluLW9yZGVyIGRlbGl2ZXJ5IGdp dmVzIGV2ZXJ5IGZsb3cgdGhlIHNhbWUgZGVsYXkgYXMgdGhlIHdvcnN0IGRlbGF5ZWQgZmxvdy48 YnI+DQo8YnI+DQpPZiBjb3Vyc2UsIHNvbWVvbmUgYnVpbGRpbmcgYSBuZXR3b3JrIGZvciBERVRO RVQgd291bGQgYXZvaWQgbGluayB0ZWNobm9sb2dpZXMgbGlrZSBXaUZpIG9yIExURSB0aGF0IGZy ZXF1ZW50bHkgbG9zZSBhbmQgcmV0cmFuc21pdCBwYWNrZXRzLiBCdXQgd2hlcmV2ZXIgdGhlcmUg aXMgdmFyaWFibGUgZGVsYXkgaW4gYSBsaW5rLCBndWFyYW50ZWVkIGluLW9yZGVyIGRlbGl2ZXJ5 IHBlci1ob3AgbWVhbnMgZXZlcnkgZmxvdyBpcyBndWFyYW50ZWVkDQogdG8gYWx3YXlzIGdldCB0 aGUgd29yc3QgZGVsYXkgZnJvbSBldmVyeSBsaW5rLCB3aGljaCB3b3VsZCBoYXZlIGJlZW4gZXhw ZXJpZW5jZWQgYnkgb25seSBvbmUgZmxvdyB3aXRob3V0IHBlci1ob3AgaW4tb3JkZXIgZGVsaXZl cnkuDQo8YnI+DQo8YnI+DQpBbmQgbWFueSBvZiB0aGUgYXBwbGljYXRpb25zIG9mIERFVE5FVCBp bnZvbHZlIGR1bWIgaW5kdXN0cmlhbCBtYWNoaW5lcnkgdGhhdCBqdXN0IGV4cGVjdHMgZXZlcnl0 aGluZyB0byBhcnJpdmUgaW4gb3JkZXIgYW5kIHRvIGEgY2xvY2tlZCBzY2hlZHVsZS4gQnV0IGl0 J3MgYWx3YXlzIGFzIGVmZmVjdGl2ZSB0byBkZXBsb3kgYSByZXNlcXVlbmNpbmcgYnVmZmVyIGFz IHRoZSBwZW51bHRpbWF0ZSBob3AsIHNjcmV3ZWQgb250byB0aGUgcmVjZWl2aW5nDQogbWFjaGlu ZSBpZiBuZWNlc3NhcnksIHJhdGhlciB0aGFuIHJlcXVpcmUgcGVyLWhvcCByZXNlcXVlbmNpbmcg aW4gdGhlIG5ldHdvcmsuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fXzxicj4NClNvLCB3aHkg ZG8gSW50ZXJuZXQgbGlua3Mgb2Z0ZW4gZW5zdXJlIGluLW9yZGVyIGRlbGl2ZXJ5IGV2ZW4gdGhv dWdoIFRDUCBwdXRzIGV2ZXJ5dGhpbmcgaW4gb3JkZXIgZm9yIHRoZSBhcHBsaWNhdGlvbj8NCjxi cj4NCjxicj4NClNob3J0IGFuc3dlcjogdGhlIDMgRHVwQUNLIHJ1bGUgKHdoaWNoIGlzIHRvIGRv IHdpdGggbG9zcy1yZWNvdmVyeSwgYSBkaWZmZXJlbnQgaXNzdWUgZnJvbSB0aGUgZGlzY3Vzc2lv biBhYm92ZSkuPGJyPg0KPGJyPg0KTG9uZyBhbnN3ZXI6IEFzIGZsb3cgcmF0ZXMgaGF2ZSBzY2Fs ZWQgdXAsIHRoZSB0eXBpY2FsIHRpbWUgYmV0d2VlbiAzIHBhY2tldCBhcnJpdmFscyBoYXMgYmVj b21lIHNvIHNtYWxsIHRoYXQgVENQJ3MgMy1EdXBBQ0sgcnVsZSBtYWtlcyBsaW5rcyBoYXZlIHRv IHByb3ZpZGUgZGVsaXZlcnkgd2l0aCBvbmx5IGEgdmVyeSBzbWFsbCByZS1vcmRlcmluZyBkZWdy ZWUgLSBzbyBzbWFsbCB0aGF0IGl0J3MgZWFzaWVyIGZvciBhIGxpbmsgdG8ganVzdA0KIGRlbGl2 ZXIgZXZlcnl0aGluZyBpbiB0aGUgb3JkZXIgaXQgcmVjZWl2ZWQgaXQ7IG5vdCBiZWNhdXNlIFRD UCBkb2Vzbid0IHB1dCBwYWNrZXRzIGJhY2sgaW4gb3JkZXIsIGJ1dCBqdXN0IHNvIGFzIG5vdCB0 byB0cmlnZ2VyIFRDUCBpbnRvIGdlbmVyYXRpbmcgc3B1cmlvdXMgcmV0cmFuc21pc3Npb25zLjxi cj4NCjxicj4NCjxicj4NCjxicj4NCkJvYjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDA4LzExLzIwMTggMTY6MzUsIFNjaGFyZiwgTWljaGFlbCB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SW5saW5lIFttc108L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29lIFs8YSBocmVmPSJtYWlsdG86aW5AYm9iYnJp c2NvZS5uZXQiPm1haWx0bzppbkBib2JicmlzY29lLm5ldDwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gVGh1cnNkYXksIE5vdmVtYmVyIDgsIDIwMTggMTI6NTYgUE08YnI+DQo8Yj5Ubzo8L2I+IFNj aGFyZiwgTWljaGFlbDsgPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5v cmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5vcmciPnRz dndnQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RzdndnXSBDcm9zcy1h cmVhIGFsaWdubWVudCBvbiAmcXVvdDtMNFMgYW5kIFJBQ0smcXVvdDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPk1pY2hhZWwsPGJyPg0KPGJyPg0KVGhpcyBpcyBtZXJlbHkgYSBzeW1wdG9tIG9mIGEgZGlm ZmVyZW5jZSBpbiBvcGluaW9uIG9uIHdoZXJlIHRoZSByZXNlcXVlbmNpbmcgZnVuY3Rpb24gc2hv dWxkIGJlIGxvY2F0ZWQuPG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0Omw1IGxldmVsMSBsZm82Ij4NCkw0UyB0YWtlcyB0aGUg ZW5kLXRvLWVuZCBhcHByb2FjaCBzYXlpbmcgdGhhdCBpdCBpcyBzdWZmaWNpZW50IHRvIGRvIHJl c2VxdWVuY2luZyBpbiBvbmUgcGxhY2UgKHRoZSByZWNlaXZpbmcgaG9zdCkgaWYgaXQgaXMgbmVl ZGVkLiBUaGVuIGFueSByZXNlcXVlbmNpbmcgZGVsYXkgb25seSBhZmZlY3RzIHRoYXQgZmxvdy48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNSBsZXZlbDEg bGZvNiI+DQpUaGUgREVUTkVUIGFwcHJvYWNoIGlzIHNheWluZyB0aGUgcmVzZXF1ZW5jaW5nIG11 c3QgYmUgZG9uZSBob3AtYnktaG9wLiBUaGlzIG1lYW5zIHRoZXJlIGFwcGVhcnMgdG8gYmUgbm8g cmVzZXF1ZW5jaW5nIG5lZWRlZCBvbiB0aGUgcmVjZWl2ZXIgKGV4Y2VwdCBpZiB0aGVyZSdzIHJl LW9yZGVyaW5nIG9uIHRoZSBmaW5hbCBob3ApLg0KPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzkiPg0KSW4gb3Jk ZXIgdG8gZ3VhcmFudGVlIG5vIHJlc2VxdWVuY2luZyBpbiB0aGUgbmV0d29yayAoREVUTkVUIGFw cHJvYWNoKSwgb25seSB0aGUgdGhlIHdvcnN0IGNhc2UgbGF0ZW5jeSBjYW4gYmUgZ3VhcmFudGVl ZCwgYW5kIGV2ZXJ5IHBhY2tldCBoYXMgdG8gaGF2ZSB0aGF0IHNhbWUgd29yc3QtY2FzZSBsYXRl bmN5LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxl dmVsMSBsZm85Ij4NCldoZW4geW91IGxlYXZlIHJlc2VxdWVuY2luZyB0byB0aGUgcmVjZWl2ZXIg KGVuZC10by1lbmQgYXBwcm9hY2gpLCBtb3N0IG9mIHRoZSBwYWNrZXRzIGFycml2ZSBlYXJsaWVy IHRoYW4gdGhleSB3b3VsZCB3aXRoIERFVE5FVCwgYnV0IG91dCBvZiBvcmRlciBvbmVzIG1pZ2h0 IG5vdC4gVGhlbiB0aGUgYXBwbGljYXRpb24gY2hvb3NlcyB3aGV0aGVyIGl0IHdhbnRzIHRvIHdh aXQuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bbXNdIE15IHBv aW50IGlzIGRpZmZlcmVudDogVGhlcmUgc2VlbSB0byBiZSBvdGhlciB3b3JraW5nIGdyb3VwcyBp biB0aGUgSUVURiB0aGF0IGRvIHRhbGsgYWJvdXQg4oCcbG93IGxhdGVuY3nigJ0gYXMgd2VsbCBi dXQgYXBwYXJlbnRseSB0aGV5IGFsc28gZG8gbmVlZCBpbi1vcmRlciBkZWxpdmVyeSBvZiBwYWNr ZXRzLA0KIHRvby4gU28gdGhlIGFzc3VtcHRpb24gdGhhdCBlLmcuIGEgbGluayBsYXllciB0ZWNo bm9sb2d5IGNhbiBzaW1wbHkgZGlzYWJsZSBpbi1vcmRlciBkZWxpdmVyeSBmb3IgYWxsIOKAnGxv dyBsYXRlbmN54oCdIGFwcGxpY2F0aW9ucyBzZWVtcyBub3QgY29ycmVjdC4gVGhlIHJlYWxpdHkg bWF5IGJlIGEgYml0IG1vcmUgY29tcGxleC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoZSAzIER1cEFDSyBy dWxlIGluIFRDUCBsZWQgdGhlIEludGVybmV0IG5vdCB0byBmb2xsb3cgdGhlIGVuZC10by1lbmQg cHJpbmNpcGxlIG9uIHJlLXNlcXVlbmNpbmcuIE5vdyB3ZSdyZSByZW1vdmluZyB0aGUgMyBEdXBB Q0sgcnVsZSwgd2UgY2FuIHRha2UgYWR2YW50YWdlIG9mIHRoZSBlMmUgcHJpbmNpcGxlLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W21zXSBGb3IgVENQLCB0aHJlZSBE dXBBQ0tTIGFyZSBhIFNIT1VMRCBpbiBSRkMgNTY4MSBhbmQgUkZDIDU2ODEgaXMgc3RhbmRhcmRz IHRyYWNrLiBTbyB0aGUgYmFyIGZvciDigJxyZW1vdmluZ+KAnSB0aGF0IHJ1bGUgZm9yIFRDUA0K IGlzIG5vdCBsb3figKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5bbXNdIEFsc28sIHRoZSBlbmQtdG8tZW5kIHByaW5jaXBsZSBjb21lcyB3aXRoIHRyYWRl b2Zmcy4gRm9yIGluc3RhbmNlLCByZWx5aW5nIG9uIHRoZSBlbmQtdG8tZW5kIHByaW5jaXBsZSBm b3IgcmVjb3Zlcnkgb2YgYml0IGVycm9ycw0KIGlzIG5vdCBlZmZpY2llbnQuIEZvciBpbi1vcmRl ciBkZWxpdmVyeSB0aGVyZSBhcmUgdHJhZGVvZmZzIGFzIHdlbGwsIHNlZSBlLmcuIFNlY3Rpb24g NCBpbiBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNC4gVGhlcmUgbWF5IGJlIG5vIGZyZWUgbHVuY2gu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5PZiBjb3Vyc2UsIGFuIGFwcGxpY2F0aW9uIG1pZ2h0IGNob29zZSB0 byB1c2UgVENQIGFuZCBMNFMsIHJhdGhlciB0aGFuIFVEUCBhbmQgTDRTIChlLmcgUVVJQykuIFRo ZW4gdGhlcmUgY291bGQgc3RpbGwgYmUgSG9MIGJsb2NraW5nIGluIHRoZSByZWNlaXZpbmcgVENQ IHN0YWNrLiBCdXQgYXQgbGVhc3QgdGhlcmUncyBubyBIb0wgYmxvY2tpbmcgaW4gdGhlIG5ldHdv cmssDQogYW5kIHRoZSBhcHAgY2FuIGNob29zZSBiZXR3ZWVuIHN0cmVhbSAoVENQKSBvciBkYXRh Z3JhbSAoVURQKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlttc10g SWYgTFJPL0dSTyBpbiB0aGUgcmVjZWl2aW5nIFRDUCBzdGFjayBnZXRzIG1lc3NlZCB1cCwgSSBm YWlsIHRvIHNlZSB0aGUgYmVuZWZpdCAoc2VlIGRyYWZ0LWlldGYtdGNwbS1yYWNrLTA0KS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NaWNoYWVsPC9zcGFu Pjxicj4NCjxicj4NCjxicj4NCkJvYjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIDA2LzExLzIwMTggMTk6MjAsIFNjaGFyZiwgTWljaGFlbCB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkEgY29tbWVudCBvbiB0aGUgVENQTSBwcmVzZW50 YXRpb24gJnF1b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoZSBE RVRORVQgV0cgaW4gUlRHIGFyZWEgaGFzIHF1aXRlIHNvbWUgdXNlcyBjYXNlcyBmb3IgdWx0cmEt bG93IGxhdGVuY3kgdHJhbnNwb3J0IC0gaW4gcGFydGljdWxhciBhbHNvIHdpdGggYm91bmRlZCBq aXR0ZXIuIEFuZCBzb21lIG9mIHRoZXNlIGFwcGxpY2F0aW9ucyAoZS5nLiB1c2luZyBVRFApIGFw cGFyZW50bHkgbWF5IG5vdCBiZSBhYmxlIHRvIHRvbGVyYXRlICphbnkqIG91dC1vZi1vcmRlciBw YWNrZXQgZGVsaXZlcnkuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+U28gcGVyaGFwcyBzb21lIGNyb3NzLWFyZWEgYWxpZ25tZW50IG9uIHVsdGEt bG93LWxhdGVuY3kgYXBwbGljYXRpb24gcmVxdWlyZW1lbnRzIHdvdWxkIGJlIHVzZWZ1bD88bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5NaWNoYWVs PG86cD48L286cD48L3ByZT4NCjxwcmU+KHdobyByZWNlbnRseSBoYWQgdG8gcmV2aWV3IGRyYWZ0 LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZSk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVm PSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNBJTJGJTJGYm9iYnJpc2NvZS5uZXQlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWlj cm9zb2Z0LmNvbSU3QzU0N2U1MDNlMjE4NTQ5NDgzZjMwMDhkNjQ2NzQ5NWI5JTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3Mzg2Mzg5NTUwNjUxMSZhbXA7 c2RhdGE9JTJCNFhvbG5LeVBuWTVDdThrdHVXWGkyU0o1cWJvTjdCcjklMkI2RE1yQ0hubWMlM0Qm YW1wO3Jlc2VydmVkPTAiPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3By ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwJTNBJTJGJTJGYm9iYnJpc2NvZS5uZXQlMkYmYW1wO2RhdGE9MDIlN0Mw MSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzU0N2U1MDNlMjE4NTQ5NDgzZjMwMDhkNjQ2NzQ5 NWI5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3Mzg2 Mzg5NTUxNjUxNSZhbXA7c2RhdGE9eFpQdmRxa1BXdDBCMVJhR2xvMHU1UHZyeWphem1xam05OHBW MDB6T01XdyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxw cmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxh IGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHAlM0ElMkYlMkZib2JicmlzY29lLm5ldCUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIl NDBtaWNyb3NvZnQuY29tJTdDNTQ3ZTUwM2UyMTg1NDk0ODNmMzAwOGQ2NDY3NDk1YjklN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NzczODYzODk1NTI2NTI0 JmFtcDtzZGF0YT1TcE9KJTJGZHV3U0VSRG1zbER5dHdOTE5JSjVMNE94dnBUem5jYUF4MG9GclUl M0QmYW1wO3Jlc2VydmVkPTAiPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48 L3ByZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwJTNBJTJGJTJGYm9iYnJpc2NvZS5uZXQlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZi JTQwbWljcm9zb2Z0LmNvbSU3QzU0N2U1MDNlMjE4NTQ5NDgzZjMwMDhkNjQ2NzQ5NWI5JTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3Mzg2Mzg5NTUyNjUy NCZhbXA7c2RhdGE9U3BPSiUyRmR1d1NFUkRtc2xEeXR3TkxOSUo1TDRPeHZwVHpuY2FBeDBvRnJV JTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT4tLSA8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+Qm9i IEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmJvYmJyaXNjb2UubmV0JTJGJmFtcDtk YXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0M1NDdlNTAzZTIxODU0OTQ4M2Yz MDA4ZDY0Njc0OTViOSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzY3NzM4NjM4OTU1MzY1MzcmYW1wO3NkYXRhPWx5QmhjWFU3NFNVNTZzN3FyMU9VU2Z3YUlM NjhMY2JGN1dKeHRteiUyQlViMCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cDovL2JvYmJyaXNjb2Uu bmV0LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MW2PR2101MB1049EAF866AFA35983A31167B6C60MW2PR2101MB1049_-- From nobody Fri Nov 9 11:29:11 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6117F130DC3; Fri, 9 Nov 2018 11:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTOYYM5rNzq2; Fri, 9 Nov 2018 11:29:04 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F2A130DC7; Fri, 9 Nov 2018 11:28:51 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 6B15025A21; Fri, 9 Nov 2018 20:28:49 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1541791729; bh=24jy6+KyIr7Iytk8NaVryCRvRe4floSpz8Yg0d9aiBg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=bQxKsg5H20rDAdNXnbWuz04xXS7tCg0PhWYGCDEuamlVHGEeekFTcW7yevsCF8m/w F58CNJWRQe8kEvrDLXHS+7WKqU6Ej1WSvD6FRMVWVdBMsJUgWHxWs07l53u4AHBrMt 0TGkRip5HVt9Uw24wTrPUCAGPvWFd3BGYsgFWQDQ= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1su91_XyxNFo; Fri, 9 Nov 2018 20:28:49 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.hs-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 9 Nov 2018 20:28:49 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.25]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Fri, 9 Nov 2018 20:28:48 +0100 From: "Scharf, Michael" To: Bob Briscoe , "tcpm@ietf.org" CC: "tsvwg@ietf.org" Thread-Topic: [tsvwg] Cross-area alignment on "L4S and RACK" Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFgBS9LuAAAnyRqAAG025AAACx04QAAaGWYAAD7CAQAAA6LeAAAIdXND///yrgP//7HxA Date: Fri, 9 Nov 2018 19:28:48 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D15394C@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D1537CD@rznt8114.rznt.rzdir.fht-esslingen.de> <45512894-fc71-a4a8-4043-3feb06f9e347@bobbriscoe.net> In-Reply-To: <45512894-fc71-a4a8-4043-3feb06f9e347@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D15394Crznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2018 19:29:09 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D15394Crznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rmlyc3QsIEkgZG9u4oCZdCBrbm93IGlmIHRoZSBjdXJyZW50bHkgZGlzY3Vzc2VkIHBhcmFtZXRl cnMgZm9yIHRoZSBSQUNLIHJlb3JkZXJpbmcgd2luZG93IGFyZSBpbmRlZWQgZnV0dXJlIHByb29m LiBNYXliZSBUQ1Agc3RhY2tzIGNvdWxkIHVzZSBkaWZmZXJlbnQgcGFyYW1ldGVycyBpbiBvbmUg b3IgdHdvIHllYXJzIGZyb20gbm93PyBTbyB3aGF0IGlzIHRoZSByZWFsLXdvcmxkIGJlbmVmaXQg Zm9yIGEgbGluayBkZXNpZ25lciAqbm93KiBpbiByZWx5aW5nIG9uIGFuIHBhcmFtZXRlcnMgdGhh dCBjYW4gY2hhbmdlIGVhc2lseT8gQW5kIEkgd291bGQgYWN0dWFsbHkgYXNzdW1lIHRoYXQgdGhl IGV4YWN0IHBhcmFtZXRlciB2YWx1ZXMgaW4gYSAoaHlwb3RoZXRpY2FsKSBmdXR1cmUgc3RhbmRh cmRzIHRyYWNrIHNwZWNpZmljYXRpb24gb2YgUkFDSyB3b3VsZCBiZSBhIFNIT1VMRC4gRGlmZmVy ZW50IFRDUCBzdGFja3MgbWF5IHBpY2sgZGlmZmVyZW50IHZhbHVlcy4gSG93IHVzZWZ1bCBpcyB0 aGlzIHRoZW4gdG8gYSBsaW5rIGRlc2lnbmVyPw0KDQpTZWNvbmQsIEkgZG9u4oCZdCB1bmRlcnN0 YW5kIHdoeSBvbmUgY2Fubm90IHRyeSB0byBwcm92aWRlIHNvbWUgb3RoZXIgZ3VpZGFuY2UsIHNh eSwgaW4gdGVybXMgb2YgbnVtYmVyIG9mIHRyaWdnZXJlZCBEVVBBQ0tzIG9yIHRoZSBsaWtlLiBM ZXTigJlzIGFzc3VtZSB3ZSBzYWlkIGEgc3RhY2sgbXVzdCBiZSBhYmxlIHRvIGRlYWwgd2l0aCBh IHJlb3JkZXIgZGVncmVlIG9mIDEwPyBGb3Igd2hpY2ggbGluayB0ZWNobm9sb2dpZXMgd291bGQg dGhpcyBub3QgYmUgZ29vZCBlbm91Z2g/DQoNClRoaXJkLCBzb21lIHJlYWwtd29ybGQgZGF0YSB3 b3VsZCBmYWNpbGl0YXRlIHRoaXMgZGlzY3Vzc2lvbiBxdWl0ZSBhIGJpdCwgSU1ITy4gSSBoYXZl IGEgaGFyZCB0aW1lIHRvIGZvbGxvdyB0aGlzIHByb3Bvc2FsIHdpdGhvdXQgZXhhbXBsZXMgZm9y IGRpZmZlcmVudCBSVFRzLCBkaWZmZXJlbnQgbnVtYmVyIG9mIHBhcmFsbGVsIGNvbm5lY3Rpb25z LCBkaWZmZXJlbnQgbWl4dHVyZXMgb2YgdHJhZmZpYywgZXRjLg0KDQpNaWNoYWVsDQoNCg0KDQoN CkZyb206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldF0NClNlbnQ6IEZy aWRheSwgTm92ZW1iZXIgOSwgMjAxOCA3OjUyIFBNDQpUbzogU2NoYXJmLCBNaWNoYWVsOyB0Y3Bt QGlldGYub3JnDQpDYzogdHN2d2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHN2d2ddIENyb3Nz LWFyZWEgYWxpZ25tZW50IG9uICJMNFMgYW5kIFJBQ0siDQoNCk1pY2hhZWwsDQoNClRoZSBpZGVh IGlzIHRoYXQgKGFzIG5vdyBpbiB0aGUgUkFDSyBkcmFmdCBzaW5jZSBkaXNjdXNzaW9uIG9uIHRo ZSB0Y3BtIGxpc3QgZWFybGllciB0aGlzIHllYXIgdW5kZXIgYSBzdWJqZWN0IHNvbWV0aGluZyBs aWtlIHZpY2lvdXMgY2lyY2xlIG9yIHZpcnR1b3VzIGNpcmNsZSkgdGhlcmUgd2lsbCBiZSBhIGxp bWl0IG9uIHRoZSBpbml0aWFsIFJBQ0sgcmVvcmRlcmluZyB3aW5kb3cgZXhwcmVzc2VkIGluIGZy YWN0aW9uYWwgUlRUIHVuaXRzLg0KDQpMaW5rIHZlbmRvcnMga25vdyB0aGUgbWluIGUyZSBSVFQg b2YgdGhlIHBhdGhzIHRoYXQgdGhlaXIgbGlua3MgYXJlIHVzdWFsbHkgZGVwbG95ZWQgb3Zlci4g VGhlcmVmb3JlIHRoZXkgY2FuIGVzdGltYXRlIHRoZSBtYXggcmVvcmRlcmluZyB0aGV5IGFsbG93 IHRoZWlyIGxpbmtzIHRvIGludHJvZHVjZS4NCg0KSSBkb24ndCBleHBlY3QgdGhpcyBsaW1pdCB0 byBiZSBzZXQgaW4gc3RvbmUgd2hpbGUgYm90aCBSQUNLIGFuZCBMNFMgYXJlIGV4cGVyaW1lbnRh bC4gQnV0IGFzIGJvdGggdGhlc2UgZXhwZXJpbWVudHMgcHJvZ3Jlc3MsIEkgdGhpbmsgdGhlIGlu ZHVzdHJ5IHdpbGwgZ2V0IGEgYmV0dGVyIGlkZWEgb2Ygd2hlcmUgdGhlIGxpbWl0IHNob3VsZCBs aWUuDQoNCkl0IHdhcyB0aGUgcmVhbGl6YXRpb24gdGhhdCwgaWYgVENQIGFkYXB0ZWQgaXRzIHJl b3JkZXJpbmcgd2luZG93IHRvIHRoZSBtZWFzdXJlZCByZW9yZGVyaW5nIGRlZ3JlZSB3aXRob3V0 IGJvdW5kLCB0aGUgTDIgd29ybGQgd291bGQgY29udGludWFsbHkgaW5jcmVhc2UgdGhlIHJlb3Jk ZXJpbmcgZGVncmVlIG9mIHRoZWlyIGxpbmtzICh0aGUgdmljaW91cyBjaXJjbGUpLg0KDQpJZiB0 aGVyZSBpcyBhbnkgYXNwZWN0IG9mIHRoaXMgbGltaXQgZXhwcmVzc2VkIGluIHVuaXRzIG9mIHBh Y2tldHMsIHRoZSBsaW1pdCB3aWxsIGRlY3JlYXNlIGluIHRpbWUgYXMgZmxvdyByYXRlcyBpbmNy ZWFzZSwgYW5kIHRoZXJlZm9yZSBub3Qgc2VydmUgdG8gZ2l2ZSB0aGUgTDIgd29ybGQgYW55IGNs ZWFyIGd1aWRhbmNlIC0gbm8gZGUgZmFjdG8gbGltaXQgYWdyZWVkIGJldHdlZW4gdGhlIEw0IHdv cmxkIGFuZCB0aGUgTDIgd29ybGQuDQoNCklmIHdlIGtlZXAgdGhlIGxpbWl0IGluIHVuaXRzIG9m IFJUVCwgaG9wZWZ1bGx5IHRoZW4gd2UgaGF2ZSBhIHZpcnR1b3VzIGNpcmNsZSwgbm90IGEgdmlj aW91cyBjaXJjbGUuDQoNCg0KDQpCb2INCg0KT24gMDkvMTEvMjAxOCAxODoyOCwgU2NoYXJmLCBN aWNoYWVsIHdyb3RlOg0KSSBtYXkgbWlzcyBzb21ldGhpbmcsIGJ1dCBJIHJlYWQgdGhlIG91dGNv bWUgb2YgdGhlIGFwcGVuZGl4IGFzIGEgcmVxdWlyZW1lbnQg4oCcbXVzdCBiZSBtb3JlIHJvYnVz dCB0byByZW9yZGVyaW5n4oCdLiBBcyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGF0IGNhbiBiZSBp bXBsZW1lbnRlZCBpbiBkaWZmZXJlbnQgd2F5cy4NCg0KQW5kIEkgbWF5IGJlIHdyb25nLCBidXQg dGhvc2UgbGluayB0ZWNobm9sb2dpZXMgY291bGQgYmUgd2VsbCBpbXBsZW1lbnRlZCBpbiBhIHJv dXRlciBhbmQgdGhlbiBvbmUgbmVlZHMgdG8gYW5hbHl6ZSBob3cgdGhhdCB3aG9sZSBhcmNoaXRl Y3R1cmUgZml0cyBpbnRvIHRoZSBzY2hlZHVsZXIsIHF1ZXVlLCBwb2xpY2VyLCBhbmQgbGluZSBj YXJkIGhhcmR3YXJlIGRlc2lnbiBvZiBhIHJvdXRlci4gQnV0IHRoYXQgaXMgc29tZXRoaW5nIHJv dXRpbmcgcGVvcGxlIGtub3cgYmV0dGVyIHRoYW4gbWUuIE15IHBvaW50IGlzIGp1c3QgdG8gZ2V0 IHRoZSBleHBlcnRzIGludG8gdGhlIGxvb3AgZWFybHkuDQoNCk1pY2hhZWwNCg0KDQpGcm9tOiBC b2IgQnJpc2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBGcmlkYXksIE5v dmVtYmVyIDksIDIwMTggNzowNCBQTQ0KVG86IFNjaGFyZiwgTWljaGFlbDsgdGNwbUBpZXRmLm9y ZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCkNjOiB0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAi TDRTIGFuZCBSQUNLIg0KDQpNaWNoYWVsLA0KDQpQbGVhc2UgYWRkcmVzcyB0aGUgc2NhbGluZyBy YXRpb25hbGUgaW4gdGhlIGFwcGVuZGl4IGZvciB3aHkgaXQgZG9lcyBtYXR0ZXIgaG93IGEgc2Vu ZGVyIHJlYWxpemVzIHRoaXMgaW50ZXJuYWxseS4NCg0KVGhlIGxpc3Qgb2YgYWNjZXNzIGxpbmtz IHR5cGVzIEkgbWVudGlvbmVkIGFyZSByYXJlbHkgY29ubmVjdGVkIGRpcmVjdGx5IHRvIHJvdXRl cnMuDQoNCg0KDQpCb2INCk9uIDA5LzExLzIwMTggMTc6NDQsIFNjaGFyZiwgTWljaGFlbCB3cm90 ZToNCknigJlsbCBub3QgY29tbWVudCBvbiBsaW5rIHRlY2hub2xvZ3kgaW1wbGVtZW50YXRpb24s IHNjaGVkdWxlciBhbmQgcXVldWUgZGVzaWduIGFzc3VtcHRpb25zIGluIEFwcGVuZGl4IEEuMS43 IG9mIGRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNS4gUGVvcGxlIGUuZy4gaW4gUlRHIGFy ZWEgbWF5IGJlIG1vcmUgZmFtaWxpYXIgd2l0aCB0aGUgaW1wbGljYXRpb25zIG9mIGludGVybmFs IGRlc2lnbnMgZS5nLiBpbnNpZGUgYSByb3V0ZXIuIElNSE8gdGhlIGJlc3Qgd2F5IHRvIGdldCBy b3V0aW5nIGV4cGVydHMgaW50byB0aGUgbG9vcCBiZWZvcmUgZnVydGhlciBkaXNjdXNzaW5nIHdo YXQgaXMgY3VycmVudGx5IGxpc3RlZCBpbiBBcHBlbmRpeCBBLjEuNy4NCg0KVGh1cywgSSBsaW1p dCBteSByZXNwb25zZSB0byB0aGUgYWN0dWFsIHdvcmRpbmcgaW4gdGhlIG1haW4gcGFydCBvZiBk cmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQtMDU6DQoNCiAgICBvICBBIHNjYWxhYmxlIGNvbmdl c3Rpb24gY29udHJvbCBNVVNUIGRldGVjdCBsb3NzIGJ5IGNvdW50aW5nIGluDQogICAgICB1bml0 cyBvZiB0aW1lLCB3aGljaCBpcyBzY2FsYWJsZSwgYW5kIE1VU1QgTk9UIGNvdW50IGluIHVuaXRz IG9mDQogICAgICBwYWNrZXRzIChhcyBpbiB0aGUgMyBEdXBBQ0sgcnVsZSBvZiB0cmFkaXRpb25h bCBUQ1ApLCB3aGljaCBpcyBub3QNCiAgICAgIHNjYWxhYmxlIChzZWUgQXBwZW5kaXggQS4xLjc8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0w NSNhcHBlbmRpeC1BLjEuNz4gZm9yIHJhdGlvbmFsZSkuDQoNCkFzIGluZGl2aWR1YWwgY29udHJp YnV0b3IsIEkgZGlzYWdyZWUgd2l0aCB0aGlzIHJlcXVpcmVtZW50LiBJIHdvdWxkIHByb2JhYmx5 IGJlIE9LIHdpdGggYSB3b3JkaW5nIHRoYXQgYSBUQ1Agc2VuZGVyIG11c3QgYmUgYWJsZSB0byB0 b2xlcmF0ZSByZW9yZGVyaW5nIGJleW9uZCAzIER1cGxpY2F0ZSBBQ0tzLiBJIGJlbGlldmUgaXQg ZG9lcyBub3QgbWF0dGVyIGhvdyBhIHNlbmRlciByZWFsaXplcyB0aGlzIGludGVybmFsbHkuDQoN CkFuZCBpZiB0aGF0IHJlcXVpcmVtZW50IGlzIG5vdCBqdXN0IHJlbW92ZWQsIEkgYmVsaWV2ZSB0 aGUgd29yZGluZyDigJx0cmFkaXRpb25hbCBUQ1DigJ0gaGFzIHRvIGJlIHJlcGxhY2VkIGJ5IOKA nHN0YW5kYXJkIFRDUOKAnS4NCg0KQlRXLCBhbHNvLCBpbiB0aGUgcmVzdCBvZiB0aGUgZG9jdW1l bnQgdGhlcmUgaGFzIHRvIGJlIGEgY2xlYXIgZGlzdGluY3Rpb24gYmV0d2VlbiBleHBlcmltZW50 cyBhbmQgc3RhbmRhcmRzLiBIaXN0b3J5IHRlbGxzIHVzIHRoYXQgc29tZSBleHBlcmltZW50cyBj YW4gZXZvbHZlIGludG8gc3RhbmRhcmRzIHRyYWNrIHNwZWNpZmljYXRpb25zLCB3aGlsZSBvdGhl ciBleHBlcmltZW50cyBtYXkgZmFpbC4gQW5kIHRoZXJlIGlzIG5vIHdheSBvZiBrbm93aW5nIHRo YXQgaW4gYWR2YW5jZS4NCg0KTWljaGFlbA0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmll dGZAYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDksIDIwMTggMTE6MDgg QU0NClRvOiBTY2hhcmYsIE1pY2hhZWw7IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5v cmc+DQpDYzogdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gIkw0UyBhbmQgUkFDSyINCg0KTWlj aGFlbCwNCk9uIDA5LzExLzIwMTggMDY6MjEsIFNjaGFyZiwgTWljaGFlbCB3cm90ZToNCkkgZG9u 4oCZdCBzZWUgdGhlIGZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgYmV0d2VlbiBhIGxpbmsgdGVjaG5v bG9neSB0aGF0IGd1YXJhbnRlZXMgaW4tb3JkZXIgZGVsaXZlcnkgd2l0aGluIGEgZmxvdyAoc2F5 IGJ5IGZsb3cgaGFzaGluZywgc2VlIEVDTVApIHZzLiBzb21lIGxpbmsgc2NoZW1lIHRoYXQgZ3Vh cmFudGVlcyBpbi1vcmRlciBkZWxpdmVyeSwgc2F5LCBvbmx5IGZvciBzb21lIGZyYWN0aW9uIG9m IHRoZSB0cmFmZmljIGNoYXJhY3Rlcml6ZWQgYnkgc29tZSBvdGhlciBtZWFucyAoc2F5LCBvdGhl ciBoZWFkZXIgYml0cykuDQpbVGhlICJvdGhlciBtZWFucyIgYW5kICJvdGhlciBiaXRzIiB3b3Jk aW5nIGlzIHByZXR0eSBhbWJpZ3VvdXMgaGVyZS4gSSByZWNrb24gSSBjYW4gZ3Vlc3Mgd2hhdCB5 b3UgbWVhbiBidXQgdGhlbiBJIGRvbid0IGtub3cgd2h5IHlvdSdyZSBzYXlpbmcgdGhpcywgJ2Nv cyBJIGRvbid0IHRoaW5rIEkndmUgZGlzYWdyZWVkIHdpdGggeW91IG9uIHRoaXMuIFNvIHBlcmhh cHMgeW91IGNvdWxkIGJlIG1vcmUgc3BlY2lmaWMgYW5kIHdlIG1pZ2h0IGJlIGFibGUgdG8gc2Vl IHdoeSB5b3UndmUgYnJvdWdodCB0aGlzIHVwLl0NCg0KQWxzbyBJIHdhc24ndCByZWFsbHkgdGFs a2luZyBhYm91dCBhbGwgImxpbmsgdGVjaG5vbG9neSB0aGF0IGd1YXJhbnRlZXMgaW4tb3JkZXIg ZGVsaXZlcnkgd2l0aGluIGEgZmxvdyIuIHtOb3RlIDF9IEkgd2FzIHRhbGtpbmcgYWJvdXQgbGlu ayB0ZWNobm9sb2d5IHdoZXJlIGFsbCBmbG93cyBhcmUgYmxvY2tlZCB3aGlsZSB3YWl0aW5nIHRv IGdldCB0aGUgYWdncmVnYXRlIGJhY2sgaW4gb3JkZXIgdGhhdCBpdCB3YXMgaW4gd2hlbiBpdCBh cnJpdmVkLiBJIHNwZWNpZmljYWxseSBzYWlkOg0KDQoNCg0KTm90ZSB0aGF0IHRoZXJlIGNhbiBi ZSBtdWx0aXBsZSBmbG93cyBvdmVyIG9uZSBsaW5rLiBTbyAnaW4tb3JkZXIgZGVsaXZlcnknIGZv ciBhIGxpbmsgZG9lcyBub3QgbWVhbiBpbiBvcmRlciBvZiBUQ1Agc2VxdWVuY2UgbnVtYmVyLiBJ dCBtZWFucyAnZGVsaXZlcmVkIGluIHRoZSBvcmRlciB0aGF0IHBhY2tldHMgYXJyaXZlZCBhdCB0 aGUgbGluaycgKHRoZSBsaW5rIGluZ3Jlc3MgYWRkcyBpdHMgb3duIHNlcXVlbmNlIG51bWJlcnMs IGFuZCB0aGUgbGluayBlZ3Jlc3MgYnVmZmVycyB0aGVtIHVudGlsIGl0IGNhbiBzZW5kIG91dCBp biB0aGUgc2FtZSBvcmRlciwgb3IgdW50aWwgYSB0aW1lLW91dCBvciBtYXggbm8uIG9mIGxpbmsg cmV0cmFuc21pc3Npb25zKS4NCkZvciBleGFtcGxlOg0KDQogICogICBBIHBhY2tldCByZXNlcXVl bmNpbmcgYnVmZmVyIGFmdGVyIGFsbG93aW5nIGZvciBsaW5rLWxheWVyIHJldHJhbnNtaXNzaW9u cyBpcyBjb21tb24gZm9yIHJhZGlvIGxpbmsgdGVjaG5vbG9naWVzIHN1Y2ggYXMgTFRFIChQRENQ IGxheWVyKSBhbmQgODAyLjExIFdpRmkuDQogICogICBBIHBhY2tldCByZXNlcXVlbmNpbmcgYnVm ZmVyIGFmdGVyIG1lcmdpbmcgbXVsdGlwbGUgYm9uZGVkIGxpbmsgY2hhbm5lbHMgaXMgY29tbW9u IGZvciBvdGhlciBhY2Nlc3MgbGluayB0ZWNobm9sb2dpZXMgc3VjaCBhcyBkb3duc3RyZWFtIERP Q1NJUyBib25kZWQgY2hhbm5lbHMuDQoNCg0KDQoNCg0KQ2xlYXJseSwgcmVvcmRlcmluZyBpcyBh IHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgaW4gdGhlIElFVEYgYXMgYSB3aG9s ZS4gQW5kIHdlIGNvdWxkIGRpc2N1c3Mgd2hldGhlciBhIHJldmlzaW9uIG9mIFJGQyAzMzY2IGlz IG5lZWRlZC4NCk5vLiBUaGVyZSBpcyBubyBwcm9wb3NhbCB0byBhbHRlciBnZW5lcmFsIGd1aWRh bmNlIGZvciBhbGwgbGlua3MgbGlrZSBSRkMgMzM2Ni4gTm8tb25lIGlzIHNheWluZyB0aGlzLg0K DQpUaGVyZSBpcyBub3QgZXZlbiBhIHByb3Bvc2FsIHRvIHJlcXVpcmUgb3IgZXZlbiByZWNvbW1l bmQgdGhhdCBMNFMtc3BlY2lmaWMgbGlua3MgZG8gYW55dGhpbmcuDQoNClRoZSBzcGVjaWZpYyBw cm9wb3NhbCBpcyB0byByZXF1aXJlIEw0UyBzb3VyY2VzIHRvIHVzZSBhIFJBQ0stbGlrZSBzY2hl bWUsIGFzIGEgY29uZGl0aW9uIGZvciBzZXR0aW5nIHRoZSBFQ1QoMSkgY29kZXBvaW50LiBTZWUg dGhlIGxhc3QgYnVsbGV0IGluIFMuNC4zIG9mIGRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0w NTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlk LTA1I3NlY3Rpb24tNC4zPi4NCg0KVGhpcyBzYXlzIG5vdGhpbmcgYWJvdXQgd2hhdCBMNFMgbGlu a3MgTVVTVCwgU0hPVUxEIG9yIE1BWSBkby4gSXQganVzdCBnaXZlcyBhbiBMNFMgbGluayBhbiBv cHBvcnR1bml0eSBub3QgdG8gaGF2ZSB0byBkbyByZXNlcXVlbmNpbmcuDQoNCg0KDQoNCg0KQnV0 IEkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IHRoaXMgdG9waWMgaGFzIHRvIGJlIHRpZWQgaW50byBh biBleHBlcmltZW50IHN1Y2ggYXMgTDRTLg0KSXQgaXMgYW4gb3Bwb3J0dW5pdHkgdGhhdCBjdXJy ZW50bHkgb25seSBhcHBsaWVzIHRvIEw0Uy4NCg0KTDRTIGlzIG1lcmVseSBhbiBleGFtcGxlIG9m IGEgY2FzZSB3aGVyZSB3ZSBjYW4gbWFuZGF0ZSB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gbm9uLVJB Q0sgdHJhZmZpYyBpbiBhIGxpbmssIHdoaWNoIGNyZWF0ZXMgYW4gb3Bwb3J0dW5pdHkgZm9yIHRo b3NlIHdobyBhcmUgaW1wbGVtZW50aW5nIHRoZSBMNFMgRHVhbFEgQ291cGxlZCBBUU0gdG8gaWdu b3JlIHRoZSBSRkMzMzY2IHJlc2VxdWVuY2luZyBhZHZpY2UgZm9yIHRoZSBMNFMgcXVldWUgKGJ1 dCB3ZSBhcmUgbm90IGNoYW5naW5nIHRoZSBhZHZpY2UsIGJlY2F1c2UgTDRTIGlzIG9ubHkgYW4g ZXhwZXJpbWVudCkuIFRoZSBwcml6ZSBpcyB0byByZW1vdmUgdGhlIGhlYWQtb2YtbGluZSBibG9j a2luZyBwcm9ibGVtIGZvciB0aGVpciB1c2Vycy4NCg0KVGhpcyBpcyBub3QgTDRTLXNwZWNpZmlj LCBhbHRobyB0aGVyZSBhcmUgbm8gb3RoZXIgZXhhbXBsZXMgYXQgdGhlIG1vbWVudCB3aGVyZSB0 aGlzIG9wcG9ydHVuaXR5IGlzIHBvc3NpYmxlIChzbyBpbiB0aGF0IHNlbnNlIGl0IGlzIGN1cnJl bnRseSBMNFMtc3BlY2lmaWMpLg0KDQoNClRoZSBtZXNzYWdlIGhhcyB0byBiZSBoYW5kbGVkIHJl YWxseSBjYXJlZnVsbHksIGJlY2F1c2UgdGhlIG9wcG9ydHVuaXRpZXMgZm9yIG1pc3VuZGVyc3Rh bmRpbmcgYXJlIGVub3Jtb3VzIChhcyBldmlkZW5jZWQgYnkgdGhpcyB0aHJlYWQsIGFuZCB3ZSBo YXZlbid0IGV2ZW4gc3RhcnRlZCB0YWxraW5nIHRvIG5vbi10cmFuc3BvcnQgcGVvcGxlIHlldCku DQoNClNvIEdvcnJ5IGFuZCBEYXZpZCBCIHdhbnQgbWUgdG8gZHJhZnQgYSBzaG9ydCBJLUQgdGhh dCB0aGV5IHdpbGwgd29yZC1zbWl0aCBhbmQgYXV0aG9yIGFzIHRzdndnIGNoYWlycyB0byBtYWtl IHRoZSBzaXR1YXRpb24gY2xlYXIuDQoNCkkgaGF2ZSBzYWlkIEkgZG9uJ3Qgd2FudCB0aGlzIGRp c2N1c3Npb24gdG8gYmUgb2ZmaWNpYWxseSByYWlzZWQgb3V0c2lkZSB0aGUgdHJhbnNwb3J0IGFy ZWEgdW50aWwgd2UgYXJlIHN1cmUgdGhhdCBhIHZhcmlhbnQgb2YgUkFDSyBpcyBldmVuIGZlYXNp YmxlIHdpdGhvdXQgYW55IHBhY2tldCBjb3VudGluZyBhdCBhbGwgKGkuZS4gd2l0aG91dCB0aGUg aW5pdGlhbCAzLUR1cEFDSyBydWxlIGluIGN1cnJlbnQgUkFDSykuIFNvIEknbGwgcHJpb3JpdGl6 ZSB3b3JraW5nIHRoYXQgb3V0IGZvciB0aGUgbmV4dCB3ZWVrIG9yIHNvLCByYXRoZXIgdGhhbiBk cmFmdGluZyBhbnl0aGluZy4NCg0KDQoNCkJvYg0KDQp7Tm90ZSAxfTogSSBoYWRuJ3QgY29uc2lk ZXJlZCB0aGF0IHRoaXMgd291bGQgYWZmZWN0IHRlY2hub2xvZ2llcyBsaWtlIEVDTVAgdGhhdCBt YWludGFpbiBvcmRlciB3aXRob3V0IGEgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBhbmQgd2l0aG91dCBp bnRyb2R1Y2luZyBIb0wgYmxvY2tpbmcuIEJ1dCBhY3R1YWxseSwgdGhlIGNvbnNlcXVlbmNlIHRo ZXJlIHdvdWxkIGJlIHRoYXQgTDRTIHRyYWZmaWMgY291bGQgYmUgc3ByYXllZCBieSBFQ01QIHdp dGhvdXQgcGVyLWZsb3cgaGFzaGluZy4NCg0KDQoNCg0KDQpNaWNoYWVsDQoNCkZyb206IEJvYiBC cmlzY29lIFttYWlsdG86aW5AYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBGcmlkYXksIE5vdmVtYmVy IDksIDIwMTggNjo0MiBBTQ0KVG86IFNjaGFyZiwgTWljaGFlbDsgdGNwbUBpZXRmLm9yZzxtYWls dG86dGNwbUBpZXRmLm9yZz4NCkNjOiB0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAiTDRTIGFu ZCBSQUNLIg0KDQpNaWNoYWVsLA0KDQpUaGF0IGlzIHRoZSBwb2ludCBJIHRob3VnaHQgeW91IHdl cmUgbWFraW5nLCBhbmQgbXkgcG9pbnQgL2lzLyBhYm91dCB0aGF0Lg0KDQpJZiBhbiBhcHBsaWNh dGlvbiBuZWVkcyBhbGwgdGhlIHBhY2tldHMgKGkuZS4gYSByZWxpYWJsZSBwcm90b2NvbCksIGl0 J3Mgbm90IHVzZWZ1bCB0byByZWR1Y2UgdGhlIGxhdGVuY3kgb2Ygc29tZSBwYWNrZXRzIGJ1dCBu b3QgYWxsLiBUaGF0J3Mgd2hlcmUgdGhlIGluLW9yZGVyIHJlcXVpcmVtZW50IGNvbWVzIGZyb20u DQoNCkhvd2V2ZXIsIGlmIGEgc3RyZWFtLWJhc2VkIHRyYW5zcG9ydCBpcyB1c2VkIChpLmUuIFRD UCkgdGhlIC9hcHBsaWNhdGlvbi8gc3RpbGwgZ2V0cyBpbi1vcmRlciBkZWxpdmVyeSBmcm9tIFRD UC4gSXQganVzdCBkb2Vzbid0IGhhdmUgdG8gcmVxdWlyZSBsaW5rcyB0byBwcm92aWRlIGluIG9y ZGVyIGRlbGl2ZXJ5IGFzIHdlbGwuDQoNCk5vdGUgdGhhdCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUg Zmxvd3Mgb3ZlciBvbmUgbGluay4gU28gJ2luLW9yZGVyIGRlbGl2ZXJ5JyBmb3IgYSBsaW5rIGRv ZXMgbm90IG1lYW4gaW4gb3JkZXIgb2YgVENQIHNlcXVlbmNlIG51bWJlci4gSXQgbWVhbnMgJ2Rl bGl2ZXJlZCBpbiB0aGUgb3JkZXIgdGhhdCBwYWNrZXRzIGFycml2ZWQgYXQgdGhlIGxpbmsnICh0 aGUgbGluayBpbmdyZXNzIGFkZHMgaXRzIG93biBzZXF1ZW5jZSBudW1iZXJzLCBhbmQgdGhlIGxp bmsgZWdyZXNzIGJ1ZmZlcnMgdGhlbSB1bnRpbCBpdCBjYW4gc2VuZCBvdXQgaW4gdGhlIHNhbWUg b3JkZXIsIG9yIHVudGlsIGEgdGltZS1vdXQgb3IgbWF4IG5vLiBvZiBsaW5rIHJldHJhbnNtaXNz aW9ucykuDQoNClNvLCBpZiB0aGUgbGluayBsb3NlcyBhIHBhY2tldCBmcm9tIGZsb3cgQSAodGhl IGxpbmsgaXNuJ3QgYXdhcmUgb2YgbWljcm9mbG93cywgSSdtIGp1c3Qgc2F5aW5nIHRoZSBwYWNr ZXQgaGFwcGVucyB0byBiZSBmcm9tIGZsb3cgQSksIGxpbmstbGF5ZXIgaW4tb3JkZXIgZGVsaXZl cnkgd2lsbCBob2xkIGJhY2sgYWxsIHBhY2tldHMgc2VudCBhZnRlciB0aGF0IHBhY2tldCAoZnJv bSBhbGwgZmxvd3MsIG5vdCBqdXN0IGZsb3cgQSkgdW50aWwgdGhlIGxpbmsgcmVwYWlycyB0aGUg Z2FwIG9yIGdpdmVzIHVwLg0KDQpTbyBob3AtYnktaG9wIGluLW9yZGVyIGRlbGl2ZXJ5IGdpdmVz IGV2ZXJ5IGZsb3cgdGhlIHNhbWUgZGVsYXkgYXMgdGhlIHdvcnN0IGRlbGF5ZWQgZmxvdy4NCg0K T2YgY291cnNlLCBzb21lb25lIGJ1aWxkaW5nIGEgbmV0d29yayBmb3IgREVUTkVUIHdvdWxkIGF2 b2lkIGxpbmsgdGVjaG5vbG9naWVzIGxpa2UgV2lGaSBvciBMVEUgdGhhdCBmcmVxdWVudGx5IGxv c2UgYW5kIHJldHJhbnNtaXQgcGFja2V0cy4gQnV0IHdoZXJldmVyIHRoZXJlIGlzIHZhcmlhYmxl IGRlbGF5IGluIGEgbGluaywgZ3VhcmFudGVlZCBpbi1vcmRlciBkZWxpdmVyeSBwZXItaG9wIG1l YW5zIGV2ZXJ5IGZsb3cgaXMgZ3VhcmFudGVlZCB0byBhbHdheXMgZ2V0IHRoZSB3b3JzdCBkZWxh eSBmcm9tIGV2ZXJ5IGxpbmssIHdoaWNoIHdvdWxkIGhhdmUgYmVlbiBleHBlcmllbmNlZCBieSBv bmx5IG9uZSBmbG93IHdpdGhvdXQgcGVyLWhvcCBpbi1vcmRlciBkZWxpdmVyeS4NCg0KQW5kIG1h bnkgb2YgdGhlIGFwcGxpY2F0aW9ucyBvZiBERVRORVQgaW52b2x2ZSBkdW1iIGluZHVzdHJpYWwg bWFjaGluZXJ5IHRoYXQganVzdCBleHBlY3RzIGV2ZXJ5dGhpbmcgdG8gYXJyaXZlIGluIG9yZGVy IGFuZCB0byBhIGNsb2NrZWQgc2NoZWR1bGUuIEJ1dCBpdCdzIGFsd2F5cyBhcyBlZmZlY3RpdmUg dG8gZGVwbG95IGEgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBhcyB0aGUgcGVudWx0aW1hdGUgaG9wLCBz Y3Jld2VkIG9udG8gdGhlIHJlY2VpdmluZyBtYWNoaW5lIGlmIG5lY2Vzc2FyeSwgcmF0aGVyIHRo YW4gcmVxdWlyZSBwZXItaG9wIHJlc2VxdWVuY2luZyBpbiB0aGUgbmV0d29yay4NCg0KX19fX19f X19fX19fX19fXw0KU28sIHdoeSBkbyBJbnRlcm5ldCBsaW5rcyBvZnRlbiBlbnN1cmUgaW4tb3Jk ZXIgZGVsaXZlcnkgZXZlbiB0aG91Z2ggVENQIHB1dHMgZXZlcnl0aGluZyBpbiBvcmRlciBmb3Ig dGhlIGFwcGxpY2F0aW9uPw0KDQpTaG9ydCBhbnN3ZXI6IHRoZSAzIER1cEFDSyBydWxlICh3aGlj aCBpcyB0byBkbyB3aXRoIGxvc3MtcmVjb3ZlcnksIGEgZGlmZmVyZW50IGlzc3VlIGZyb20gdGhl IGRpc2N1c3Npb24gYWJvdmUpLg0KDQpMb25nIGFuc3dlcjogQXMgZmxvdyByYXRlcyBoYXZlIHNj YWxlZCB1cCwgdGhlIHR5cGljYWwgdGltZSBiZXR3ZWVuIDMgcGFja2V0IGFycml2YWxzIGhhcyBi ZWNvbWUgc28gc21hbGwgdGhhdCBUQ1AncyAzLUR1cEFDSyBydWxlIG1ha2VzIGxpbmtzIGhhdmUg dG8gcHJvdmlkZSBkZWxpdmVyeSB3aXRoIG9ubHkgYSB2ZXJ5IHNtYWxsIHJlLW9yZGVyaW5nIGRl Z3JlZSAtIHNvIHNtYWxsIHRoYXQgaXQncyBlYXNpZXIgZm9yIGEgbGluayB0byBqdXN0IGRlbGl2 ZXIgZXZlcnl0aGluZyBpbiB0aGUgb3JkZXIgaXQgcmVjZWl2ZWQgaXQ7IG5vdCBiZWNhdXNlIFRD UCBkb2Vzbid0IHB1dCBwYWNrZXRzIGJhY2sgaW4gb3JkZXIsIGJ1dCBqdXN0IHNvIGFzIG5vdCB0 byB0cmlnZ2VyIFRDUCBpbnRvIGdlbmVyYXRpbmcgc3B1cmlvdXMgcmV0cmFuc21pc3Npb25zLg0K DQoNCg0KQm9iDQpPbiAwOC8xMS8yMDE4IDE2OjM1LCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6DQpJ bmxpbmUgW21zXQ0KDQpGcm9tOiBCb2IgQnJpc2NvZSBbbWFpbHRvOmluQGJvYmJyaXNjb2UubmV0 XQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDgsIDIwMTggMTI6NTYgUE0NClRvOiBTY2hhcmYs IE1pY2hhZWw7IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpDYzogdHN2d2dA aWV0Zi5vcmc8bWFpbHRvOnRzdndnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0c3Z3Z10gQ3Jv c3MtYXJlYSBhbGlnbm1lbnQgb24gIkw0UyBhbmQgUkFDSyINCg0KTWljaGFlbCwNCg0KVGhpcyBp cyBtZXJlbHkgYSBzeW1wdG9tIG9mIGEgZGlmZmVyZW5jZSBpbiBvcGluaW9uIG9uIHdoZXJlIHRo ZSByZXNlcXVlbmNpbmcgZnVuY3Rpb24gc2hvdWxkIGJlIGxvY2F0ZWQuDQoNCiAgKiAgIEw0UyB0 YWtlcyB0aGUgZW5kLXRvLWVuZCBhcHByb2FjaCBzYXlpbmcgdGhhdCBpdCBpcyBzdWZmaWNpZW50 IHRvIGRvIHJlc2VxdWVuY2luZyBpbiBvbmUgcGxhY2UgKHRoZSByZWNlaXZpbmcgaG9zdCkgaWYg aXQgaXMgbmVlZGVkLiBUaGVuIGFueSByZXNlcXVlbmNpbmcgZGVsYXkgb25seSBhZmZlY3RzIHRo YXQgZmxvdy4NCiAgKiAgIFRoZSBERVRORVQgYXBwcm9hY2ggaXMgc2F5aW5nIHRoZSByZXNlcXVl bmNpbmcgbXVzdCBiZSBkb25lIGhvcC1ieS1ob3AuIFRoaXMgbWVhbnMgdGhlcmUgYXBwZWFycyB0 byBiZSBubyByZXNlcXVlbmNpbmcgbmVlZGVkIG9uIHRoZSByZWNlaXZlciAoZXhjZXB0IGlmIHRo ZXJlJ3MgcmUtb3JkZXJpbmcgb24gdGhlIGZpbmFsIGhvcCkuDQoNCg0KICAqICAgSW4gb3JkZXIg dG8gZ3VhcmFudGVlIG5vIHJlc2VxdWVuY2luZyBpbiB0aGUgbmV0d29yayAoREVUTkVUIGFwcHJv YWNoKSwgb25seSB0aGUgdGhlIHdvcnN0IGNhc2UgbGF0ZW5jeSBjYW4gYmUgZ3VhcmFudGVlZCwg YW5kIGV2ZXJ5IHBhY2tldCBoYXMgdG8gaGF2ZSB0aGF0IHNhbWUgd29yc3QtY2FzZSBsYXRlbmN5 Lg0KICAqICAgV2hlbiB5b3UgbGVhdmUgcmVzZXF1ZW5jaW5nIHRvIHRoZSByZWNlaXZlciAoZW5k LXRvLWVuZCBhcHByb2FjaCksIG1vc3Qgb2YgdGhlIHBhY2tldHMgYXJyaXZlIGVhcmxpZXIgdGhh biB0aGV5IHdvdWxkIHdpdGggREVUTkVULCBidXQgb3V0IG9mIG9yZGVyIG9uZXMgbWlnaHQgbm90 LiBUaGVuIHRoZSBhcHBsaWNhdGlvbiBjaG9vc2VzIHdoZXRoZXIgaXQgd2FudHMgdG8gd2FpdC4N Clttc10gTXkgcG9pbnQgaXMgZGlmZmVyZW50OiBUaGVyZSBzZWVtIHRvIGJlIG90aGVyIHdvcmtp bmcgZ3JvdXBzIGluIHRoZSBJRVRGIHRoYXQgZG8gdGFsayBhYm91dCDigJxsb3cgbGF0ZW5jeeKA nSBhcyB3ZWxsIGJ1dCBhcHBhcmVudGx5IHRoZXkgYWxzbyBkbyBuZWVkIGluLW9yZGVyIGRlbGl2 ZXJ5IG9mIHBhY2tldHMsIHRvby4gU28gdGhlIGFzc3VtcHRpb24gdGhhdCBlLmcuIGEgbGluayBs YXllciB0ZWNobm9sb2d5IGNhbiBzaW1wbHkgZGlzYWJsZSBpbi1vcmRlciBkZWxpdmVyeSBmb3Ig YWxsIOKAnGxvdyBsYXRlbmN54oCdIGFwcGxpY2F0aW9ucyBzZWVtcyBub3QgY29ycmVjdC4gVGhl IHJlYWxpdHkgbWF5IGJlIGEgYml0IG1vcmUgY29tcGxleC4NClRoZSAzIER1cEFDSyBydWxlIGlu IFRDUCBsZWQgdGhlIEludGVybmV0IG5vdCB0byBmb2xsb3cgdGhlIGVuZC10by1lbmQgcHJpbmNp cGxlIG9uIHJlLXNlcXVlbmNpbmcuIE5vdyB3ZSdyZSByZW1vdmluZyB0aGUgMyBEdXBBQ0sgcnVs ZSwgd2UgY2FuIHRha2UgYWR2YW50YWdlIG9mIHRoZSBlMmUgcHJpbmNpcGxlLg0KW21zXSBGb3Ig VENQLCB0aHJlZSBEdXBBQ0tTIGFyZSBhIFNIT1VMRCBpbiBSRkMgNTY4MSBhbmQgUkZDIDU2ODEg aXMgc3RhbmRhcmRzIHRyYWNrLiBTbyB0aGUgYmFyIGZvciDigJxyZW1vdmluZ+KAnSB0aGF0IHJ1 bGUgZm9yIFRDUCBpcyBub3QgbG934oCmDQpbbXNdIEFsc28sIHRoZSBlbmQtdG8tZW5kIHByaW5j aXBsZSBjb21lcyB3aXRoIHRyYWRlb2Zmcy4gRm9yIGluc3RhbmNlLCByZWx5aW5nIG9uIHRoZSBl bmQtdG8tZW5kIHByaW5jaXBsZSBmb3IgcmVjb3Zlcnkgb2YgYml0IGVycm9ycyBpcyBub3QgZWZm aWNpZW50LiBGb3IgaW4tb3JkZXIgZGVsaXZlcnkgdGhlcmUgYXJlIHRyYWRlb2ZmcyBhcyB3ZWxs LCBzZWUgZS5nLiBTZWN0aW9uIDQgaW4gZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDQuIFRoZXJlIG1h eSBiZSBubyBmcmVlIGx1bmNoLg0KT2YgY291cnNlLCBhbiBhcHBsaWNhdGlvbiBtaWdodCBjaG9v c2UgdG8gdXNlIFRDUCBhbmQgTDRTLCByYXRoZXIgdGhhbiBVRFAgYW5kIEw0UyAoZS5nIFFVSUMp LiBUaGVuIHRoZXJlIGNvdWxkIHN0aWxsIGJlIEhvTCBibG9ja2luZyBpbiB0aGUgcmVjZWl2aW5n IFRDUCBzdGFjay4gQnV0IGF0IGxlYXN0IHRoZXJlJ3Mgbm8gSG9MIGJsb2NraW5nIGluIHRoZSBu ZXR3b3JrLCBhbmQgdGhlIGFwcCBjYW4gY2hvb3NlIGJldHdlZW4gc3RyZWFtIChUQ1ApIG9yIGRh dGFncmFtIChVRFApLg0KW21zXSBJZiBMUk8vR1JPIGluIHRoZSByZWNlaXZpbmcgVENQIHN0YWNr IGdldHMgbWVzc2VkIHVwLCBJIGZhaWwgdG8gc2VlIHRoZSBiZW5lZml0IChzZWUgZHJhZnQtaWV0 Zi10Y3BtLXJhY2stMDQpLg0KTWljaGFlbA0KDQoNCkJvYg0KT24gMDYvMTEvMjAxOCAxOToyMCwg U2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KDQpBIGNvbW1lbnQgb24gdGhlIFRDUE0gcHJlc2VudGF0 aW9uICJMNFMgYW5kIFJBQ0siOg0KDQoNCg0KQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhlIERF VE5FVCBXRyBpbiBSVEcgYXJlYSBoYXMgcXVpdGUgc29tZSB1c2VzIGNhc2VzIGZvciB1bHRyYS1s b3cgbGF0ZW5jeSB0cmFuc3BvcnQgLSBpbiBwYXJ0aWN1bGFyIGFsc28gd2l0aCBib3VuZGVkIGpp dHRlci4gQW5kIHNvbWUgb2YgdGhlc2UgYXBwbGljYXRpb25zIChlLmcuIHVzaW5nIFVEUCkgYXBw YXJlbnRseSBtYXkgbm90IGJlIGFibGUgdG8gdG9sZXJhdGUgKmFueSogb3V0LW9mLW9yZGVyIHBh Y2tldCBkZWxpdmVyeS4NCg0KDQoNClNvIHBlcmhhcHMgc29tZSBjcm9zcy1hcmVhIGFsaWdubWVu dCBvbiB1bHRhLWxvdy1sYXRlbmN5IGFwcGxpY2F0aW9uIHJlcXVpcmVtZW50cyB3b3VsZCBiZSB1 c2VmdWw/DQoNCg0KDQpNaWNoYWVsDQoNCih3aG8gcmVjZW50bHkgaGFkIHRvIHJldmlldyBkcmFm dC1pZXRmLWRldG5ldC1hcmNoaXRlY3R1cmUpDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KLS0NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRw Oi8vYm9iYnJpc2NvZS5uZXQvDQoNCg0KDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlz Y29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8N Cg0KDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0KDQoNCg0KLS0NCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpCb2IgQnJpc2NvZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBodHRwOi8vYm9i YnJpc2NvZS5uZXQvDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D15394Crznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyBcLCBzZXJpZiI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJ Y29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRp ZXJ0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iiwic2VyaWYiOw0KCWNvbG9y OmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNt Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6 MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh bi5IVE1MVm9yZm9ybWF0aWVydFpjaG4NCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgVm9yZm9ybWF0 aWVydCBaY2huIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgVm9yZm9ybWF0aWVydCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29sb3I6YmxhY2s7 fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh bi5FLU1haWxGb3JtYXR2b3JsYWdlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RS1NYWlsRm9ybWF0dm9ybGFnZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoyMTk0ODYyMjI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTgzNTc1 MzQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0K CXttc28tbGlzdC1pZDoyNTk5MjAzOTY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjU2Mjg3 MzI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl bC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTps ZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxp c3QtaWQ6NDg0NTEzODM5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNTcwODg4NDcyO30NCkBs aXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxp c3QtaWQ6NTIxNDMxMjY1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQxMzQ0NjQwODt9DQpA bGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0K CXttc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoxODAu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6 bGV2ZWw4DQoJe21zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsOQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDox Mzk2NjU4Mjg2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTMwNjUxNTkyMDt9DQpAbGlzdCBs NDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlk OjIxMjE4NzA3Mzc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTkzMTUwMDEyO30NCkBsaXN0 IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJe21z by1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWwzDQoJe21zby1sZXZlbC10 YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDU6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNTpsZXZl bDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21z by1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRl IiBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GaXJzdCwgSSBkb27igJl0IGtub3cgaWYg dGhlIGN1cnJlbnRseSBkaXNjdXNzZWQgcGFyYW1ldGVycyBmb3IgdGhlIFJBQ0sgcmVvcmRlcmlu ZyB3aW5kb3cgYXJlIGluZGVlZCBmdXR1cmUgcHJvb2YuIE1heWJlIFRDUCBzdGFja3MgY291bGQg dXNlIGRpZmZlcmVudA0KIHBhcmFtZXRlcnMgaW4gb25lIG9yIHR3byB5ZWFycyBmcm9tIG5vdz8g U28gd2hhdCBpcyB0aGUgcmVhbC13b3JsZCBiZW5lZml0IGZvciBhIGxpbmsgZGVzaWduZXIgKjxi Pm5vdzwvYj4qIGluIHJlbHlpbmcgb24gYW4gcGFyYW1ldGVycyB0aGF0IGNhbiBjaGFuZ2UgZWFz aWx5PyBBbmQgSSB3b3VsZCBhY3R1YWxseSBhc3N1bWUgdGhhdCB0aGUgZXhhY3QgcGFyYW1ldGVy IHZhbHVlcyBpbiBhIChoeXBvdGhldGljYWwpIGZ1dHVyZSBzdGFuZGFyZHMNCiB0cmFjayBzcGVj aWZpY2F0aW9uIG9mIFJBQ0sgd291bGQgYmUgYSBTSE9VTEQuIERpZmZlcmVudCBUQ1Agc3RhY2tz IG1heSBwaWNrIGRpZmZlcmVudCB2YWx1ZXMuIEhvdyB1c2VmdWwgaXMgdGhpcyB0aGVuIHRvIGEg bGluayBkZXNpZ25lcj8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWNv bmQsIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBvbmUgY2Fubm90IHRyeSB0byBwcm92aWRlIHNv bWUgb3RoZXIgZ3VpZGFuY2UsIHNheSwgaW4gdGVybXMgb2YgbnVtYmVyIG9mIHRyaWdnZXJlZCBE VVBBQ0tzIG9yIHRoZSBsaWtlLiBMZXTigJlzIGFzc3VtZQ0KIHdlIHNhaWQgYSBzdGFjayBtdXN0 IGJlIGFibGUgdG8gZGVhbCB3aXRoIGEgcmVvcmRlciBkZWdyZWUgb2YgMTA/IEZvciB3aGljaCBs aW5rIHRlY2hub2xvZ2llcyB3b3VsZCB0aGlzIG5vdCBiZSBnb29kIGVub3VnaD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcmQsIHNvbWUgcmVhbC13b3JsZCBkYXRhIHdv dWxkIGZhY2lsaXRhdGUgdGhpcyBkaXNjdXNzaW9uIHF1aXRlIGEgYml0LCBJTUhPLiBJIGhhdmUg YSBoYXJkIHRpbWUgdG8gZm9sbG93IHRoaXMgcHJvcG9zYWwgd2l0aG91dCBleGFtcGxlcyBmb3IN CiBkaWZmZXJlbnQgUlRUcywgZGlmZmVyZW50IG51bWJlciBvZiBwYXJhbGxlbCBjb25uZWN0aW9u cywgZGlmZmVyZW50IG1peHR1cmVzIG9mIHRyYWZmaWMsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgW21h aWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTm92 ZW1iZXIgOSwgMjAxOCA3OjUyIFBNPGJyPg0KPGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWw7IHRj cG1AaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IHRzdndnQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdHN2d2ddIENyb3NzLWFyZWEgYWxpZ25tZW50IG9uICZxdW90O0w0UyBhbmQg UkFDSyZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TWljaGFlbCw8YnI+DQo8YnI+DQpUaGUgaWRl YSBpcyB0aGF0IChhcyBub3cgaW4gdGhlIFJBQ0sgZHJhZnQgc2luY2UgZGlzY3Vzc2lvbiBvbiB0 aGUgdGNwbSBsaXN0IGVhcmxpZXIgdGhpcyB5ZWFyIHVuZGVyIGEgc3ViamVjdCBzb21ldGhpbmcg bGlrZSB2aWNpb3VzIGNpcmNsZSBvciB2aXJ0dW91cyBjaXJjbGUpIHRoZXJlIHdpbGwgYmUgYSBs aW1pdCBvbiB0aGUgaW5pdGlhbCBSQUNLIHJlb3JkZXJpbmcgd2luZG93IGV4cHJlc3NlZCBpbiBm cmFjdGlvbmFsIFJUVCB1bml0cy48YnI+DQo8YnI+DQpMaW5rIHZlbmRvcnMga25vdyB0aGUgbWlu IGUyZSBSVFQgb2YgdGhlIHBhdGhzIHRoYXQgdGhlaXIgbGlua3MgYXJlIHVzdWFsbHkgZGVwbG95 ZWQgb3Zlci4gVGhlcmVmb3JlIHRoZXkgY2FuIGVzdGltYXRlIHRoZSBtYXggcmVvcmRlcmluZyB0 aGV5IGFsbG93IHRoZWlyIGxpbmtzIHRvIGludHJvZHVjZS48YnI+DQo8YnI+DQpJIGRvbid0IGV4 cGVjdCB0aGlzIGxpbWl0IHRvIGJlIHNldCBpbiBzdG9uZSB3aGlsZSBib3RoIFJBQ0sgYW5kIEw0 UyBhcmUgZXhwZXJpbWVudGFsLiBCdXQgYXMgYm90aCB0aGVzZSBleHBlcmltZW50cyBwcm9ncmVz cywgSSB0aGluayB0aGUgaW5kdXN0cnkgd2lsbCBnZXQgYSBiZXR0ZXIgaWRlYSBvZiB3aGVyZSB0 aGUgbGltaXQgc2hvdWxkIGxpZS48YnI+DQo8YnI+DQpJdCB3YXMgdGhlIHJlYWxpemF0aW9uIHRo YXQsIGlmIFRDUCBhZGFwdGVkIGl0cyByZW9yZGVyaW5nIHdpbmRvdyB0byB0aGUgbWVhc3VyZWQg cmVvcmRlcmluZyBkZWdyZWUgd2l0aG91dCBib3VuZCwgdGhlIEwyIHdvcmxkIHdvdWxkIGNvbnRp bnVhbGx5IGluY3JlYXNlIHRoZSByZW9yZGVyaW5nIGRlZ3JlZSBvZiB0aGVpciBsaW5rcyAodGhl IHZpY2lvdXMgY2lyY2xlKS48YnI+DQo8YnI+DQpJZiB0aGVyZSBpcyBhbnkgYXNwZWN0IG9mIHRo aXMgbGltaXQgZXhwcmVzc2VkIGluIHVuaXRzIG9mIHBhY2tldHMsIHRoZSBsaW1pdCB3aWxsIGRl Y3JlYXNlIGluIHRpbWUgYXMgZmxvdyByYXRlcyBpbmNyZWFzZSwgYW5kIHRoZXJlZm9yZSBub3Qg c2VydmUgdG8gZ2l2ZSB0aGUgTDIgd29ybGQgYW55IGNsZWFyIGd1aWRhbmNlIC0gbm8gZGUgZmFj dG8gbGltaXQgYWdyZWVkIGJldHdlZW4gdGhlIEw0IHdvcmxkIGFuZCB0aGUgTDIgd29ybGQuDQo8 YnI+DQo8YnI+DQpJZiB3ZSBrZWVwIHRoZSBsaW1pdCBpbiB1bml0cyBvZiBSVFQsIGhvcGVmdWxs eSB0aGVuIHdlIGhhdmUgYSB2aXJ0dW91cyBjaXJjbGUsIG5vdCBhIHZpY2lvdXMgY2lyY2xlLjxi cj4NCjxicj4NCjxicj4NCjxicj4NCkJvYjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA5LzExLzIwMTggMTg6MjgsIFNjaGFyZiwgTWlj aGFlbCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgbWF5IG1pc3Mgc29tZXRoaW5nLCBidXQgSSByZWFkIHRoZSBvdXRjb21lIG9mIHRoZSBhcHBl bmRpeCBhcyBhIHJlcXVpcmVtZW50IOKAnG11c3QgYmUgbW9yZSByb2J1c3QgdG8gcmVvcmRlcmlu Z+KAnS4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhhdA0KIGNhbiBiZSBpbXBsZW1lbnRlZCBp biBkaWZmZXJlbnQgd2F5cy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFu ZCBJIG1heSBiZSB3cm9uZywgYnV0IHRob3NlIGxpbmsgdGVjaG5vbG9naWVzIGNvdWxkIGJlIHdl bGwgaW1wbGVtZW50ZWQgaW4gYSByb3V0ZXIgYW5kIHRoZW4gb25lIG5lZWRzIHRvIGFuYWx5emUg aG93IHRoYXQgd2hvbGUgYXJjaGl0ZWN0dXJlDQogZml0cyBpbnRvIHRoZSBzY2hlZHVsZXIsIHF1 ZXVlLCBwb2xpY2VyLCBhbmQgbGluZSBjYXJkIGhhcmR3YXJlIGRlc2lnbiBvZiBhIHJvdXRlci4g QnV0IHRoYXQgaXMgc29tZXRoaW5nIHJvdXRpbmcgcGVvcGxlIGtub3cgYmV0dGVyIHRoYW4gbWUu IE15IHBvaW50IGlzIGp1c3QgdG8gZ2V0IHRoZSBleHBlcnRzIGludG8gdGhlIGxvb3AgZWFybHku PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgWzxh IGhyZWY9Im1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0Ij5tYWlsdG86aWV0ZkBib2JicmlzY29l Lm5ldDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IDc6 MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IFNjaGFyZiwgTWljaGFlbDsgPGEgaHJlZj0ibWFpbHRvOnRj cG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt YWlsdG86dHN2d2dAaWV0Zi5vcmciPnRzdndnQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAmcXVvdDtMNFMgYW5kIFJB Q0smcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TWlj aGFlbCw8YnI+DQo8YnI+DQpQbGVhc2UgYWRkcmVzcyB0aGUgc2NhbGluZyByYXRpb25hbGUgaW4g dGhlIGFwcGVuZGl4IGZvciB3aHkgaXQgZG9lcyBtYXR0ZXIgaG93IGEgc2VuZGVyIHJlYWxpemVz IHRoaXMgaW50ZXJuYWxseS48YnI+DQo8YnI+DQpUaGUgbGlzdCBvZiBhY2Nlc3MgbGlua3MgdHlw ZXMgSSBtZW50aW9uZWQgYXJlIHJhcmVseSBjb25uZWN0ZWQgZGlyZWN0bHkgdG8gcm91dGVycy4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCkJvYjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDA5LzExLzIwMTggMTc6NDQsIFNjaGFyZiwgTWljaGFlbCB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJlsbCBu b3QgY29tbWVudCBvbiBsaW5rIHRlY2hub2xvZ3kgaW1wbGVtZW50YXRpb24sIHNjaGVkdWxlciBh bmQgcXVldWUgZGVzaWduIGFzc3VtcHRpb25zIGluIEFwcGVuZGl4IEEuMS43IG9mIGRyYWZ0LWll dGYtdHN2d2ctZWNuLWw0cy1pZC0wNS4NCiBQZW9wbGUgZS5nLiBpbiBSVEcgYXJlYSBtYXkgYmUg bW9yZSBmYW1pbGlhciB3aXRoIHRoZSBpbXBsaWNhdGlvbnMgb2YgaW50ZXJuYWwgZGVzaWducyBl LmcuIGluc2lkZSBhIHJvdXRlci4gSU1ITyB0aGUgYmVzdCB3YXkgdG8gZ2V0IHJvdXRpbmcgZXhw ZXJ0cyBpbnRvIHRoZSBsb29wIGJlZm9yZSBmdXJ0aGVyIGRpc2N1c3Npbmcgd2hhdCBpcyBjdXJy ZW50bHkgbGlzdGVkIGluIEFwcGVuZGl4IEEuMS43Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaHVzLCBJIGxpbWl0IG15IHJlc3BvbnNlIHRvIHRoZSBhY3R1YWwgd29yZGlu ZyBpbiB0aGUgbWFpbiBwYXJ0IG9mIGRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNTo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyAsIHNlcmlm JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbyZuYnNwOyBBIHNj YWxhYmxlIGNvbmdlc3Rpb24gY29udHJvbCBNVVNUIGRldGVjdCBsb3NzIGJ5IGNvdW50aW5nIGlu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB1bml0cyBvZiB0aW1lLCB3aGljaCBpcyBzY2FsYWJsZSwgYW5kIE1VU1QgTk9U IGNvdW50IGluIHVuaXRzIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYWNrZXRzIChhcyBpbiB0aGUgMyBEdXBBQ0sg cnVsZSBvZiB0cmFkaXRpb25hbCBUQ1ApLCB3aGljaCBpcyBub3Q8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLCBzZXJpZiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNjYWxhYmxl IChzZWUNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNSNh cHBlbmRpeC1BLjEuNyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwgc2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPkFwcGVuZGl4IEEuMS43PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3ICwg c2VyaWYmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPg0KIGZvciByYXRpb25hbGUpLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BcyBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yLCBJ IGRpc2FncmVlIHdpdGggdGhpcyByZXF1aXJlbWVudC4gSSB3b3VsZCBwcm9iYWJseSBiZSBPSyB3 aXRoIGEgd29yZGluZyB0aGF0IGEgVENQIHNlbmRlciBtdXN0IGJlIGFibGUgdG8gdG9sZXJhdGUg cmVvcmRlcmluZw0KIGJleW9uZCAzIER1cGxpY2F0ZSBBQ0tzLiBJIGJlbGlldmUgaXQgZG9lcyBu b3QgbWF0dGVyIGhvdyBhIHNlbmRlciByZWFsaXplcyB0aGlzIGludGVybmFsbHkuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCBpZiB0aGF0IHJlcXVpcmVtZW50IGlzIG5v dCBqdXN0IHJlbW92ZWQsIEkgYmVsaWV2ZSB0aGUgd29yZGluZyDigJx0cmFkaXRpb25hbCBUQ1Di gJ0gaGFzIHRvIGJlIHJlcGxhY2VkIGJ5IOKAnHN0YW5kYXJkIFRDUOKAnS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlRXLCBhbHNvLCBpbiB0aGUgcmVzdCBvZiB0aGUgZG9j dW1lbnQgdGhlcmUgaGFzIHRvIGJlIGEgY2xlYXIgZGlzdGluY3Rpb24gYmV0d2VlbiBleHBlcmlt ZW50cyBhbmQgc3RhbmRhcmRzLiBIaXN0b3J5IHRlbGxzIHVzIHRoYXQgc29tZSBleHBlcmltZW50 cw0KIGNhbiBldm9sdmUgaW50byBzdGFuZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbnMsIHdoaWxl IG90aGVyIGV4cGVyaW1lbnRzIG1heSBmYWlsLiBBbmQgdGhlcmUgaXMgbm8gd2F5IG9mIGtub3dp bmcgdGhhdCBpbiBhZHZhbmNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5N aWNoYWVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgWzxh IGhyZWY9Im1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0Ij5tYWlsdG86aWV0ZkBib2JicmlzY29l Lm5ldDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IDEx OjA4IEFNPGJyPg0KPGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWw7IDxhIGhyZWY9Im1haWx0bzp0 Y3BtQGlldGYub3JnIj50Y3BtQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0i bWFpbHRvOnRzdndnQGlldGYub3JnIj50c3Z3Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gJnF1b3Q7TDRTIGFuZCBS QUNLJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NaWNoYWVsLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA5LzExLzIwMTggMDY6MjEsIFNjaGFyZiwgTWlj aGFlbCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgZG9u4oCZdCBzZWUgdGhlIGZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgYmV0d2VlbiBhIGxpbmsg dGVjaG5vbG9neSB0aGF0IGd1YXJhbnRlZXMgaW4tb3JkZXIgZGVsaXZlcnkgd2l0aGluIGEgZmxv dyAoc2F5IGJ5IGZsb3cgaGFzaGluZywgc2VlIEVDTVApDQogdnMuIHNvbWUgbGluayBzY2hlbWUg dGhhdCBndWFyYW50ZWVzIGluLW9yZGVyIGRlbGl2ZXJ5LCBzYXksIG9ubHkgZm9yIHNvbWUgZnJh Y3Rpb24gb2YgdGhlIHRyYWZmaWMgY2hhcmFjdGVyaXplZCBieSBzb21lIG90aGVyIG1lYW5zIChz YXksIG90aGVyIGhlYWRlciBiaXRzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bVGhlICZxdW90O290aGVyIG1lYW5zJnF1b3Q7IGFu ZCAmcXVvdDtvdGhlciBiaXRzJnF1b3Q7IHdvcmRpbmcgaXMgcHJldHR5IGFtYmlndW91cyBoZXJl LiBJIHJlY2tvbiBJIGNhbiBndWVzcyB3aGF0IHlvdSBtZWFuIGJ1dCB0aGVuIEkgZG9uJ3Qga25v dyB3aHkgeW91J3JlIHNheWluZyB0aGlzLCAnY29zIEkgZG9uJ3QgdGhpbmsgSSd2ZSBkaXNhZ3Jl ZWQgd2l0aCB5b3Ugb24gdGhpcy4gU28gcGVyaGFwcyB5b3UgY291bGQgYmUgbW9yZSBzcGVjaWZp Yw0KIGFuZCB3ZSBtaWdodCBiZSBhYmxlIHRvIHNlZSB3aHkgeW91J3ZlIGJyb3VnaHQgdGhpcyB1 cC5dPGJyPg0KPGJyPg0KQWxzbyBJIHdhc24ndCByZWFsbHkgdGFsa2luZyBhYm91dCBhbGwgJnF1 b3Q7PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5saW5rIHRlY2hub2xvZ3kgdGhhdCBndWFyYW50ZWVzIGluLW9yZGVyIGRlbGl2ZXJ5IHdpdGhp biBhIGZsb3c8L3NwYW4+JnF1b3Q7LiB7Tm90ZSAxfSBJIHdhcyB0YWxraW5nIGFib3V0IGxpbmsg dGVjaG5vbG9neSB3aGVyZQ0KIGFsbCBmbG93cyBhcmUgYmxvY2tlZCB3aGlsZSB3YWl0aW5nIHRv IGdldCB0aGUgYWdncmVnYXRlIGJhY2sgaW4gb3JkZXIgdGhhdCBpdCB3YXMgaW4gd2hlbiBpdCBh cnJpdmVkLiBJIHNwZWNpZmljYWxseSBzYWlkOjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSB0aGF0IHRoZXJlIGNhbiBiZSBt dWx0aXBsZSBmbG93cyBvdmVyIG9uZSBsaW5rLiBTbyAnaW4tb3JkZXIgZGVsaXZlcnknIGZvciBh IGxpbmsgZG9lcyBub3QgbWVhbiBpbiBvcmRlciBvZiBUQ1Agc2VxdWVuY2UgbnVtYmVyLiBJdCBt ZWFucyAnZGVsaXZlcmVkIGluIHRoZSBvcmRlciB0aGF0IHBhY2tldHMgYXJyaXZlZCBhdCB0aGUg bGluaycgKHRoZSBsaW5rIGluZ3Jlc3MgYWRkcyBpdHMgb3duIHNlcXVlbmNlDQogbnVtYmVycywg YW5kIHRoZSBsaW5rIGVncmVzcyBidWZmZXJzIHRoZW0gdW50aWwgaXQgY2FuIHNlbmQgb3V0IGlu IHRoZSBzYW1lIG9yZGVyLCBvciB1bnRpbCBhIHRpbWUtb3V0IG9yIG1heCBuby4gb2YgbGluayBy ZXRyYW5zbWlzc2lvbnMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9y IGV4YW1wbGU6PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCkEgcGFja2V0IHJlc2VxdWVuY2lu ZyBidWZmZXIgYWZ0ZXIgYWxsb3dpbmcgZm9yIGxpbmstbGF5ZXIgcmV0cmFuc21pc3Npb25zIGlz IGNvbW1vbiBmb3IgcmFkaW8gbGluayB0ZWNobm9sb2dpZXMgc3VjaCBhcyBMVEUgKFBEQ1AgbGF5 ZXIpIGFuZCA4MDIuMTEgV2lGaS4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCkEgcGFja2V0IHJlc2VxdWVuY2luZyBidWZm ZXIgYWZ0ZXIgbWVyZ2luZyBtdWx0aXBsZSBib25kZWQgbGluayBjaGFubmVscyBpcyBjb21tb24g Zm9yIG90aGVyIGFjY2VzcyBsaW5rIHRlY2hub2xvZ2llcyBzdWNoIGFzIGRvd25zdHJlYW0gRE9D U0lTIGJvbmRlZCBjaGFubmVscy4NCjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Q2xlYXJseSwgcmVvcmRlcmluZyBpcyBhIHByb2JsZW0gdGhhdCBuZWVkcyB0byBiZSBk aXNjdXNzZWQgaW4gdGhlIElFVEYgYXMgYSB3aG9sZS4gQW5kIHdlIGNvdWxkIGRpc2N1c3Mgd2hl dGhlciBhIHJldmlzaW9uIG9mIFJGQyAzMzY2IGlzIG5lZWRlZC4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vLiBUaGVyZSBpcyBubyBwcm9wb3NhbCB0byBh bHRlciBnZW5lcmFsIGd1aWRhbmNlIGZvciBhbGwgbGlua3MgbGlrZSBSRkMgMzM2Ni4gTm8tb25l IGlzIHNheWluZyB0aGlzLjxicj4NCjxicj4NClRoZXJlIGlzIG5vdCBldmVuIGEgcHJvcG9zYWwg dG8gcmVxdWlyZSBvciBldmVuIHJlY29tbWVuZCB0aGF0IEw0Uy1zcGVjaWZpYyBsaW5rcyBkbyBh bnl0aGluZy4NCjxicj4NCjxicj4NClRoZSBzcGVjaWZpYyBwcm9wb3NhbCBpcyB0byByZXF1aXJl IEw0UyA8aT5zb3VyY2VzPC9pPiB0byB1c2UgYSBSQUNLLWxpa2Ugc2NoZW1lLCBhcyBhIGNvbmRp dGlvbiBmb3Igc2V0dGluZyB0aGUgRUNUKDEpIGNvZGVwb2ludC4gU2VlIHRoZSBsYXN0IGJ1bGxl dCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHN2 d2ctZWNuLWw0cy1pZC0wNSNzZWN0aW9uLTQuMyI+DQpTLjQuMyBvZiBkcmFmdC1pZXRmLXRzdndn LWVjbi1sNHMtaWQtMDU8L2E+LiA8YnI+DQo8YnI+DQpUaGlzIHNheXMgbm90aGluZyBhYm91dCB3 aGF0IEw0UyBsaW5rcyBNVVNULCBTSE9VTEQgb3IgTUFZIGRvLiBJdCBqdXN0IGdpdmVzIGFuIEw0 UyBsaW5rIGFuIG9wcG9ydHVuaXR5IG5vdCB0byBoYXZlIHRvIGRvIHJlc2VxdWVuY2luZy48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5C dXQgSSBhbSBub3QgY29udmluY2VkIHRoYXQgdGhpcyB0b3BpYyBoYXMgdG8gYmUgdGllZCBpbnRv IGFuIGV4cGVyaW1lbnQgc3VjaCBhcyBMNFMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SXQgaXMgYW4gb3Bwb3J0dW5pdHkgdGhhdCBjdXJyZW50bHkgb25seSBh cHBsaWVzIHRvIEw0Uy4gPGJyPg0KPGJyPg0KTDRTIGlzIG1lcmVseSBhbiBleGFtcGxlIG9mIGEg Y2FzZSB3aGVyZSB3ZSBjYW4gbWFuZGF0ZSB0aGF0IHRoZXJlIHdpbGwgYmUgbm8gbm9uLVJBQ0sg dHJhZmZpYyBpbiBhIGxpbmssIHdoaWNoIGNyZWF0ZXMgYW4gb3Bwb3J0dW5pdHkgZm9yIHRob3Nl IHdobyBhcmUgaW1wbGVtZW50aW5nIHRoZSBMNFMgRHVhbFEgQ291cGxlZCBBUU0gdG8gaWdub3Jl IHRoZSBSRkMzMzY2IHJlc2VxdWVuY2luZyBhZHZpY2UgZm9yIHRoZSBMNFMgcXVldWUgKGJ1dA0K IHdlIGFyZSBub3QgY2hhbmdpbmcgdGhlIGFkdmljZSwgYmVjYXVzZSBMNFMgaXMgb25seSBhbiBl eHBlcmltZW50KS4gVGhlIHByaXplIGlzIHRvIHJlbW92ZSB0aGUgaGVhZC1vZi1saW5lIGJsb2Nr aW5nIHByb2JsZW0gZm9yIHRoZWlyIHVzZXJzLg0KPGJyPg0KPGJyPg0KVGhpcyBpcyBub3QgTDRT LXNwZWNpZmljLCBhbHRobyB0aGVyZSBhcmUgbm8gb3RoZXIgZXhhbXBsZXMgYXQgdGhlIG1vbWVu dCB3aGVyZSB0aGlzIG9wcG9ydHVuaXR5IGlzIHBvc3NpYmxlIChzbyBpbiB0aGF0IHNlbnNlIGl0 IGlzDQo8aT5jdXJyZW50bHk8L2k+IEw0Uy1zcGVjaWZpYykuPGJyPg0KPGJyPg0KPGJyPg0KVGhl IG1lc3NhZ2UgaGFzIHRvIGJlIGhhbmRsZWQgcmVhbGx5IGNhcmVmdWxseSwgYmVjYXVzZSB0aGUg b3Bwb3J0dW5pdGllcyBmb3IgbWlzdW5kZXJzdGFuZGluZyBhcmUgZW5vcm1vdXMgKGFzIGV2aWRl bmNlZCBieSB0aGlzIHRocmVhZCwgYW5kIHdlIGhhdmVuJ3QgZXZlbiBzdGFydGVkIHRhbGtpbmcg dG8gbm9uLXRyYW5zcG9ydCBwZW9wbGUgeWV0KS48YnI+DQo8YnI+DQpTbyBHb3JyeSBhbmQgRGF2 aWQgQiB3YW50IG1lIHRvIGRyYWZ0IGEgc2hvcnQgSS1EIHRoYXQgdGhleSB3aWxsIHdvcmQtc21p dGggYW5kIGF1dGhvciBhcyB0c3Z3ZyBjaGFpcnMgdG8gbWFrZSB0aGUgc2l0dWF0aW9uIGNsZWFy Ljxicj4NCjxicj4NCkkgaGF2ZSBzYWlkIEkgZG9uJ3Qgd2FudCB0aGlzIGRpc2N1c3Npb24gdG8g YmUgb2ZmaWNpYWxseSByYWlzZWQgb3V0c2lkZSB0aGUgdHJhbnNwb3J0IGFyZWEgdW50aWwgd2Ug YXJlIHN1cmUgdGhhdCBhIHZhcmlhbnQgb2YgUkFDSyBpcyBldmVuIGZlYXNpYmxlIHdpdGhvdXQg YW55IHBhY2tldCBjb3VudGluZyBhdCBhbGwgKGkuZS4gd2l0aG91dCB0aGUgaW5pdGlhbCAzLUR1 cEFDSyBydWxlIGluIGN1cnJlbnQgUkFDSykuIFNvIEknbGwgcHJpb3JpdGl6ZQ0KIHdvcmtpbmcg dGhhdCBvdXQgZm9yIHRoZSBuZXh0IHdlZWsgb3Igc28sIHJhdGhlciB0aGFuIGRyYWZ0aW5nIGFu eXRoaW5nLjxicj4NCjxicj4NCjxicj4NCjxicj4NCkJvYjxicj4NCjxicj4NCntOb3RlIDF9OiBJ IGhhZG4ndCBjb25zaWRlcmVkIHRoYXQgdGhpcyB3b3VsZCBhZmZlY3QgdGVjaG5vbG9naWVzIGxp a2UgRUNNUCB0aGF0IG1haW50YWluIG9yZGVyIHdpdGhvdXQgYSByZXNlcXVlbmNpbmcgYnVmZmVy IGFuZCB3aXRob3V0IGludHJvZHVjaW5nIEhvTCBibG9ja2luZy4gQnV0IGFjdHVhbGx5LCB0aGUg Y29uc2VxdWVuY2UgdGhlcmUgd291bGQgYmUgdGhhdCBMNFMgdHJhZmZpYyBjb3VsZCBiZSBzcHJh eWVkIGJ5IEVDTVAgd2l0aG91dA0KIHBlci1mbG93IGhhc2hpbmcuPGJyPg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29lIFs8YSBocmVmPSJtYWlsdG86 aW5AYm9iYnJpc2NvZS5uZXQiPm1haWx0bzppbkBib2JicmlzY29lLm5ldDwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IDY6NDIgQU08YnI+DQo8Yj5Ubzo8 L2I+IFNjaGFyZiwgTWljaGFlbDsgPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1A aWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5v cmciPnRzdndnQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RzdndnXSBD cm9zcy1hcmVhIGFsaWdubWVudCBvbiAmcXVvdDtMNFMgYW5kIFJBQ0smcXVvdDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPk1pY2hhZWwsPGJyPg0KPGJyPg0KVGhhdCBpcyB0aGUgcG9pbnQgSSB0aG91Z2h0 IHlvdSB3ZXJlIG1ha2luZywgYW5kIG15IHBvaW50IC9pcy8gYWJvdXQgdGhhdC48YnI+DQo8YnI+ DQpJZiBhbiBhcHBsaWNhdGlvbiBuZWVkcyBhbGwgdGhlIHBhY2tldHMgKGkuZS4gYSByZWxpYWJs ZSBwcm90b2NvbCksIGl0J3Mgbm90IHVzZWZ1bCB0byByZWR1Y2UgdGhlIGxhdGVuY3kgb2Ygc29t ZSBwYWNrZXRzIGJ1dCBub3QgYWxsLiBUaGF0J3Mgd2hlcmUgdGhlIGluLW9yZGVyIHJlcXVpcmVt ZW50IGNvbWVzIGZyb20uPGJyPg0KPGJyPg0KSG93ZXZlciwgaWYgYSBzdHJlYW0tYmFzZWQgdHJh bnNwb3J0IGlzIHVzZWQgKGkuZS4gVENQKSB0aGUgL2FwcGxpY2F0aW9uLyBzdGlsbCBnZXRzIGlu LW9yZGVyIGRlbGl2ZXJ5IGZyb20gVENQLiBJdCBqdXN0IGRvZXNuJ3QgaGF2ZSB0byByZXF1aXJl IGxpbmtzIHRvIHByb3ZpZGUgaW4gb3JkZXIgZGVsaXZlcnkgYXMgd2VsbC48YnI+DQo8YnI+DQpO b3RlIHRoYXQgdGhlcmUgY2FuIGJlIG11bHRpcGxlIGZsb3dzIG92ZXIgb25lIGxpbmsuIFNvICdp bi1vcmRlciBkZWxpdmVyeScgZm9yIGEgbGluayBkb2VzIG5vdCBtZWFuIGluIG9yZGVyIG9mIFRD UCBzZXF1ZW5jZSBudW1iZXIuIEl0IG1lYW5zICdkZWxpdmVyZWQgaW4gdGhlIG9yZGVyIHRoYXQg cGFja2V0cyBhcnJpdmVkIGF0IHRoZSBsaW5rJyAodGhlIGxpbmsgaW5ncmVzcyBhZGRzIGl0cyBv d24gc2VxdWVuY2UgbnVtYmVycywgYW5kIHRoZQ0KIGxpbmsgZWdyZXNzIGJ1ZmZlcnMgdGhlbSB1 bnRpbCBpdCBjYW4gc2VuZCBvdXQgaW4gdGhlIHNhbWUgb3JkZXIsIG9yIHVudGlsIGEgdGltZS1v dXQgb3IgbWF4IG5vLiBvZiBsaW5rIHJldHJhbnNtaXNzaW9ucykuPGJyPg0KPGJyPg0KU28sIGlm IHRoZSBsaW5rIGxvc2VzIGEgcGFja2V0IGZyb20gZmxvdyBBICh0aGUgbGluayBpc24ndCBhd2Fy ZSBvZiBtaWNyb2Zsb3dzLCBJJ20ganVzdCBzYXlpbmcgdGhlIHBhY2tldCBoYXBwZW5zIHRvIGJl IGZyb20gZmxvdyBBKSwgbGluay1sYXllciBpbi1vcmRlciBkZWxpdmVyeSB3aWxsIGhvbGQgYmFj ayBhbGwgcGFja2V0cyBzZW50IGFmdGVyIHRoYXQgcGFja2V0IChmcm9tIGFsbCBmbG93cywgbm90 IGp1c3QgZmxvdyBBKSB1bnRpbCB0aGUNCiBsaW5rIHJlcGFpcnMgdGhlIGdhcCBvciBnaXZlcyB1 cC4gPGJyPg0KPGJyPg0KU28gaG9wLWJ5LWhvcCBpbi1vcmRlciBkZWxpdmVyeSBnaXZlcyBldmVy eSBmbG93IHRoZSBzYW1lIGRlbGF5IGFzIHRoZSB3b3JzdCBkZWxheWVkIGZsb3cuPGJyPg0KPGJy Pg0KT2YgY291cnNlLCBzb21lb25lIGJ1aWxkaW5nIGEgbmV0d29yayBmb3IgREVUTkVUIHdvdWxk IGF2b2lkIGxpbmsgdGVjaG5vbG9naWVzIGxpa2UgV2lGaSBvciBMVEUgdGhhdCBmcmVxdWVudGx5 IGxvc2UgYW5kIHJldHJhbnNtaXQgcGFja2V0cy4gQnV0IHdoZXJldmVyIHRoZXJlIGlzIHZhcmlh YmxlIGRlbGF5IGluIGEgbGluaywgZ3VhcmFudGVlZCBpbi1vcmRlciBkZWxpdmVyeSBwZXItaG9w IG1lYW5zIGV2ZXJ5IGZsb3cgaXMgZ3VhcmFudGVlZA0KIHRvIGFsd2F5cyBnZXQgdGhlIHdvcnN0 IGRlbGF5IGZyb20gZXZlcnkgbGluaywgd2hpY2ggd291bGQgaGF2ZSBiZWVuIGV4cGVyaWVuY2Vk IGJ5IG9ubHkgb25lIGZsb3cgd2l0aG91dCBwZXItaG9wIGluLW9yZGVyIGRlbGl2ZXJ5Lg0KPGJy Pg0KPGJyPg0KQW5kIG1hbnkgb2YgdGhlIGFwcGxpY2F0aW9ucyBvZiBERVRORVQgaW52b2x2ZSBk dW1iIGluZHVzdHJpYWwgbWFjaGluZXJ5IHRoYXQganVzdCBleHBlY3RzIGV2ZXJ5dGhpbmcgdG8g YXJyaXZlIGluIG9yZGVyIGFuZCB0byBhIGNsb2NrZWQgc2NoZWR1bGUuIEJ1dCBpdCdzIGFsd2F5 cyBhcyBlZmZlY3RpdmUgdG8gZGVwbG95IGEgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBhcyB0aGUgcGVu dWx0aW1hdGUgaG9wLCBzY3Jld2VkIG9udG8gdGhlIHJlY2VpdmluZw0KIG1hY2hpbmUgaWYgbmVj ZXNzYXJ5LCByYXRoZXIgdGhhbiByZXF1aXJlIHBlci1ob3AgcmVzZXF1ZW5jaW5nIGluIHRoZSBu ZXR3b3JrLjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX188YnI+DQpTbywgd2h5IGRvIEludGVy bmV0IGxpbmtzIG9mdGVuIGVuc3VyZSBpbi1vcmRlciBkZWxpdmVyeSBldmVuIHRob3VnaCBUQ1Ag cHV0cyBldmVyeXRoaW5nIGluIG9yZGVyIGZvciB0aGUgYXBwbGljYXRpb24/DQo8YnI+DQo8YnI+ DQpTaG9ydCBhbnN3ZXI6IHRoZSAzIER1cEFDSyBydWxlICh3aGljaCBpcyB0byBkbyB3aXRoIGxv c3MtcmVjb3ZlcnksIGEgZGlmZmVyZW50IGlzc3VlIGZyb20gdGhlIGRpc2N1c3Npb24gYWJvdmUp Ljxicj4NCjxicj4NCkxvbmcgYW5zd2VyOiBBcyBmbG93IHJhdGVzIGhhdmUgc2NhbGVkIHVwLCB0 aGUgdHlwaWNhbCB0aW1lIGJldHdlZW4gMyBwYWNrZXQgYXJyaXZhbHMgaGFzIGJlY29tZSBzbyBz bWFsbCB0aGF0IFRDUCdzIDMtRHVwQUNLIHJ1bGUgbWFrZXMgbGlua3MgaGF2ZSB0byBwcm92aWRl IGRlbGl2ZXJ5IHdpdGggb25seSBhIHZlcnkgc21hbGwgcmUtb3JkZXJpbmcgZGVncmVlIC0gc28g c21hbGwgdGhhdCBpdCdzIGVhc2llciBmb3IgYSBsaW5rIHRvIGp1c3QNCiBkZWxpdmVyIGV2ZXJ5 dGhpbmcgaW4gdGhlIG9yZGVyIGl0IHJlY2VpdmVkIGl0OyBub3QgYmVjYXVzZSBUQ1AgZG9lc24n dCBwdXQgcGFja2V0cyBiYWNrIGluIG9yZGVyLCBidXQganVzdCBzbyBhcyBub3QgdG8gdHJpZ2dl ciBUQ1AgaW50byBnZW5lcmF0aW5nIHNwdXJpb3VzIHJldHJhbnNtaXNzaW9ucy48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQpCb2I8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAwOC8xMS8yMDE4IDE2OjM1LCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklubGluZSBbbXNdPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi PiBCb2IgQnJpc2NvZSBbPGEgaHJlZj0ibWFpbHRvOmluQGJvYmJyaXNjb2UubmV0Ij5tYWlsdG86 aW5AYm9iYnJpc2NvZS5uZXQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBOb3Zl bWJlciA4LCAyMDE4IDEyOjU2IFBNPGJyPg0KPGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWw7IDxh IGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIj50Y3BtQGlldGYub3JnPC9hPjxicj4NCjxiPkNj OjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRzdndnQGlldGYub3JnIj50c3Z3Z0BpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24g JnF1b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NaWNoYWVsLDxicj4N Cjxicj4NClRoaXMgaXMgbWVyZWx5IGEgc3ltcHRvbSBvZiBhIGRpZmZlcmVuY2UgaW4gb3Bpbmlv biBvbiB3aGVyZSB0aGUgcmVzZXF1ZW5jaW5nIGZ1bmN0aW9uIHNob3VsZCBiZSBsb2NhdGVkLjxv OnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsNSBsZXZlbDEgbGZvNiI+DQpMNFMgdGFrZXMgdGhlIGVuZC10by1lbmQgYXBwcm9h Y2ggc2F5aW5nIHRoYXQgaXQgaXMgc3VmZmljaWVudCB0byBkbyByZXNlcXVlbmNpbmcgaW4gb25l IHBsYWNlICh0aGUgcmVjZWl2aW5nIGhvc3QpIGlmIGl0IGlzIG5lZWRlZC4gVGhlbiBhbnkgcmVz ZXF1ZW5jaW5nIGRlbGF5IG9ubHkgYWZmZWN0cyB0aGF0IGZsb3cuPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzYiPg0KVGhlIERFVE5F VCBhcHByb2FjaCBpcyBzYXlpbmcgdGhlIHJlc2VxdWVuY2luZyBtdXN0IGJlIGRvbmUgaG9wLWJ5 LWhvcC4gVGhpcyBtZWFucyB0aGVyZSBhcHBlYXJzIHRvIGJlIG5vIHJlc2VxdWVuY2luZyBuZWVk ZWQgb24gdGhlIHJlY2VpdmVyIChleGNlcHQgaWYgdGhlcmUncyByZS1vcmRlcmluZyBvbiB0aGUg ZmluYWwgaG9wKS4NCjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm85Ij4NCkluIG9yZGVyIHRvIGd1YXJhbnRlZSBu byByZXNlcXVlbmNpbmcgaW4gdGhlIG5ldHdvcmsgKERFVE5FVCBhcHByb2FjaCksIG9ubHkgdGhl IHRoZSB3b3JzdCBjYXNlIGxhdGVuY3kgY2FuIGJlIGd1YXJhbnRlZWQsIGFuZCBldmVyeSBwYWNr ZXQgaGFzIHRvIGhhdmUgdGhhdCBzYW1lIHdvcnN0LWNhc2UgbGF0ZW5jeS48bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvOSI+DQpXaGVu IHlvdSBsZWF2ZSByZXNlcXVlbmNpbmcgdG8gdGhlIHJlY2VpdmVyIChlbmQtdG8tZW5kIGFwcHJv YWNoKSwgbW9zdCBvZiB0aGUgcGFja2V0cyBhcnJpdmUgZWFybGllciB0aGFuIHRoZXkgd291bGQg d2l0aCBERVRORVQsIGJ1dCBvdXQgb2Ygb3JkZXIgb25lcyBtaWdodCBub3QuIFRoZW4gdGhlIGFw cGxpY2F0aW9uIGNob29zZXMgd2hldGhlciBpdCB3YW50cyB0byB3YWl0LjxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlttc10gTXkgcG9pbnQg aXMgZGlmZmVyZW50OiBUaGVyZSBzZWVtIHRvIGJlIG90aGVyIHdvcmtpbmcgZ3JvdXBzIGluIHRo ZSBJRVRGIHRoYXQgZG8gdGFsayBhYm91dCDigJxsb3cgbGF0ZW5jeeKAnSBhcyB3ZWxsIGJ1dCBh cHBhcmVudGx5IHRoZXkgYWxzbyBkbyBuZWVkIGluLW9yZGVyIGRlbGl2ZXJ5DQogb2YgcGFja2V0 cywgdG9vLiBTbyB0aGUgYXNzdW1wdGlvbiB0aGF0IGUuZy4gYSBsaW5rIGxheWVyIHRlY2hub2xv Z3kgY2FuIHNpbXBseSBkaXNhYmxlIGluLW9yZGVyIGRlbGl2ZXJ5IGZvciBhbGwg4oCcbG93IGxh dGVuY3nigJ0gYXBwbGljYXRpb25zIHNlZW1zIG5vdCBjb3JyZWN0LiBUaGUgcmVhbGl0eSBtYXkg YmUgYSBiaXQgbW9yZSBjb21wbGV4Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PlRoZSAzIER1cEFDSyBydWxlIGluIFRDUCBsZWQgdGhlIEludGVybmV0IG5vdCB0byBmb2xsb3cg dGhlIGVuZC10by1lbmQgcHJpbmNpcGxlIG9uIHJlLXNlcXVlbmNpbmcuDQo8L3NwYW4+Tm93IHdl J3JlIHJlbW92aW5nIHRoZSAzIER1cEFDSyBydWxlLCB3ZSBjYW4gdGFrZSBhZHZhbnRhZ2Ugb2Yg dGhlIGUyZSBwcmluY2lwbGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W21zXSBGb3IgVENQLCB0aHJlZSBEdXBBQ0tTIGFy ZSBhIFNIT1VMRCBpbiBSRkMgNTY4MSBhbmQgUkZDIDU2ODEgaXMgc3RhbmRhcmRzIHRyYWNrLiBT byB0aGUgYmFyIGZvciDigJxyZW1vdmluZ+KAnSB0aGF0DQogcnVsZSBmb3IgVENQIGlzIG5vdCBs b3figKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+W21zXSBBbHNvLCB0aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUg Y29tZXMgd2l0aCB0cmFkZW9mZnMuIEZvciBpbnN0YW5jZSwgcmVseWluZyBvbiB0aGUgZW5kLXRv LWVuZCBwcmluY2lwbGUgZm9yIHJlY292ZXJ5DQogb2YgYml0IGVycm9ycyBpcyBub3QgZWZmaWNp ZW50LiBGb3IgaW4tb3JkZXIgZGVsaXZlcnkgdGhlcmUgYXJlIHRyYWRlb2ZmcyBhcyB3ZWxsLCBz ZWUgZS5nLiBTZWN0aW9uIDQgaW4gZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDQuIFRoZXJlIG1heSBi ZSBubyBmcmVlIGx1bmNoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9mIGNv dXJzZSwgYW4gYXBwbGljYXRpb24gbWlnaHQgY2hvb3NlIHRvIHVzZSBUQ1AgYW5kIEw0UywgcmF0 aGVyIHRoYW4gVURQIGFuZCBMNFMgKGUuZyBRVUlDKS4NCjwvc3Bhbj5UaGVuIHRoZXJlIGNvdWxk IHN0aWxsIGJlIEhvTCBibG9ja2luZyBpbiB0aGUgcmVjZWl2aW5nIFRDUCBzdGFjay4gQnV0IGF0 IGxlYXN0IHRoZXJlJ3Mgbm8gSG9MIGJsb2NraW5nIGluIHRoZSBuZXR3b3JrLCBhbmQgdGhlIGFw cCBjYW4gY2hvb3NlIGJldHdlZW4gc3RyZWFtIChUQ1ApIG9yIGRhdGFncmFtIChVRFApLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlttc10gSWYgTFJPL0dSTyBpbiB0aGUgcmVjZWl2aW5nIFRDUCBzdGFjayBnZXRzIG1lc3Nl ZCB1cCwgSSBmYWlsIHRvIHNlZSB0aGUgYmVuZWZpdCAoc2VlIGRyYWZ0LWlldGYtdGNwbS1yYWNr LTA0KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KPGJyPg0KPGJyPg0KQm9iPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDA2LzExLzIwMTggMTk6MjAsIFNjaGFyZiwgTWljaGFlbCB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkEgY29tbWVudCBvbiB0aGUgVENQTSBwcmVz ZW50YXRpb24gJnF1b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRo ZSBERVRORVQgV0cgaW4gUlRHIGFyZWEgaGFzIHF1aXRlIHNvbWUgdXNlcyBjYXNlcyBmb3IgdWx0 cmEtbG93IGxhdGVuY3kgdHJhbnNwb3J0IC0gaW4gcGFydGljdWxhciBhbHNvIHdpdGggYm91bmRl ZCBqaXR0ZXIuIEFuZCBzb21lIG9mIHRoZXNlIGFwcGxpY2F0aW9ucyAoZS5nLiB1c2luZyBVRFAp IGFwcGFyZW50bHkgbWF5IG5vdCBiZSBhYmxlIHRvIHRvbGVyYXRlICphbnkqIG91dC1vZi1vcmRl ciBwYWNrZXQgZGVsaXZlcnkuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286 cD48L3ByZT4NCjxwcmU+U28gcGVyaGFwcyBzb21lIGNyb3NzLWFyZWEgYWxpZ25tZW50IG9uIHVs dGEtbG93LWxhdGVuY3kgYXBwbGljYXRpb24gcmVxdWlyZW1lbnRzIHdvdWxkIGJlIHVzZWZ1bD88 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5NaWNo YWVsPG86cD48L286cD48L3ByZT4NCjxwcmU+KHdobyByZWNlbnRseSBoYWQgdG8gcmV2aWV3IGRy YWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZSk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBo cmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjxv OnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT4t LSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+ Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0 cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxw cmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9ib2JicmlzY29lLm5ldC8i Pmh0dHA6Ly9ib2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwOi8vYm9i YnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PG86cD48L286cD48L3ByZT4NCjxwcmU+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0 cDovL2JvYmJyaXNjb2UubmV0LyI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpw PjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D15394Crznt8114rzntrzd_-- From nobody Fri Nov 9 17:34:51 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1991126F72; Fri, 9 Nov 2018 17:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH4ZpxNrZNRP; Fri, 9 Nov 2018 17:34:46 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0865126CC7; Fri, 9 Nov 2018 17:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6ghClIIB3TPQGghUKi5vn7VOrSSXbqFzBBuUGXbGwDA=; b=IDaR3x9N5f5v4C+i6roNUMuT+ k10oXSXTf6F3NqbKtRPnQJuiBt35zdRT5wN1zdf96stZ69+zlhBkbZf3XtVccsWE0qxcDT+kTy9pe zavXULQGr+6SJkWMv34LKuwmjGcALZM1gxY3kAotO4/zEoe1TV0CQKgoFQXzBbLXwDubaG1ot8KJz HJKCZArhpFY+3tHHU2wizDF4IcxwFvKfQngKmW50nFxcpOAggWn9SBJztVRORpipSHiMt51ReWW88 T/k59zzS4TpQpVO0ap0heAWffh381LSNDS2Qk19dtPI7+6eWP64CyMEkHTLwd3JtUMauKNUiuTgkr 6Tv2A+fcw==; Received: from ppp-124-120-192-235.revip2.asianet.co.th ([124.120.192.235]:55544 helo=[192.168.1.48]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gLIAc-0004nK-OX; Sat, 10 Nov 2018 01:34:44 +0000 To: Praveen Balasubramanian , "Scharf, Michael" , "tcpm@ietf.org" Cc: "tsvwg@ietf.org" References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D1537CD@rznt8114.rznt.rzdir.fht-esslingen.de> <45512894-fc71-a4a8-4043-3feb06f9e347@bobbriscoe.net> From: Bob Briscoe Message-ID: <6413d62f-ecf1-3319-7bb2-2c763b0633be@bobbriscoe.net> Date: Sat, 10 Nov 2018 01:34:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7F0B484895BE17BF5AD75BFC" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 01:34:51 -0000 This is a multi-part message in MIME format. --------------7F0B484895BE17BF5AD75BFC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Praveen, Michael, The idea is not to relax ordering requirement on links. It's to make sure it doesn't keep getting tighter for ever. As flow-rates get faster, the requirements on links get tighter if the reordering window is expressed in packets. For instance (as I showed in my presentation), with RTT = 24ms (say), if the window is 12 segments, a reordering window of 3 DupACKs equates to 6ms. But as flow rates increase, say 8 times faster (window = 96) reduces the time over which links have to keep packets in order to 750μs. Another 8x faster, and links have to keep order within 94μs. And so on. This cannot go on indefinitely, because the constraints on link-layer retransmission are constant in time (length of link / speed of light + processing time). If the 3 DupACK rule is not removed, link timings will be continually squeezed, so radio links will eventually have to give up ARQ, which will be awful for performance. It will take decades before /all/ legacy (non-RACK) TCPs have stopped using any particular link. So links in general will still have to keep tightening their re-sequencing time because of legacy 3 Dup-ACK flows. But eventually the 3-DupACK flows that remain will tend to be those on unmaintained machines that will not be taking advantage of higher speeds. Then, assuming the RACK experiment remains successful over these decades, links will be able to stop tightening their reordering degree. The idea is that, for the L4S experiment, we can remove the 3 DupACK rule entirely from the start, and solely express reordering in units of time. Then, L4S transports will evolve, presumably using similar RACK-like reordering logic to non-L4S transports. And we shall see where the minimum reordering window ends up (in time units), and hopefully converge on a value we can standardize - both in TCP and in other transports. No L4S link would relax its ordering requirement if it led to worse TCP performance. So layer 4 will be in control of this process. Nonetheless, it is important to stop measuring reordering in packets. But hopefully, from the start of the L4S experiment, logical links solely bearing L4S traffic will not need to continually tighten their ordering requirement. If an OS supports RACK, which yours does, then buffering on the receiver will remain constant in time, which will mean the memory requirement will grow as flow rates scale up. You (Praveen) supported and implemented RACK before I'd even thought about all this. I'm also now a convert. I'm recognizing and articulating its wider advantages. Bob On 09/11/2018 19:10, Praveen Balasubramanian wrote: > > >> Therefore they can estimate the max reordering they allow their links > to introduce > > IMO L2 shouldn’t /introduce/ more reordering just because L4 > /congestion control/ is more resilient to it. There is other > performance impact due to reordering: LRO / GRO / RSC opportunity will > be reduced, more memory and CPU cost to do reassembly at L4 (this is > an active area for remote attacks) etc. IMO L4 guidance should remain > that link vendors must avoid reordering as much as possible and not > build solutions that cause frequent or consistent reordering. > > *From:*tcpm *On Behalf Of *Bob Briscoe > *Sent:* Friday, November 9, 2018 10:52 AM > *To:* Scharf, Michael ; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > The idea is that (as now in the RACK draft since discussion on the > tcpm list earlier this year under a subject something like vicious > circle or virtuous circle) there will be a limit on the initial RACK > reordering window expressed in fractional RTT units. > > Link vendors know the min e2e RTT of the paths that their links are > usually deployed over. Therefore they can estimate the max reordering > they allow their links to introduce. > > I don't expect this limit to be set in stone while both RACK and L4S > are experimental. But as both these experiments progress, I think the > industry will get a better idea of where the limit should lie. > > It was the realization that, if TCP adapted its reordering window to > the measured reordering degree without bound, the L2 world would > continually increase the reordering degree of their links (the vicious > circle). > > If there is any aspect of this limit expressed in units of packets, > the limit will decrease in time as flow rates increase, and therefore > not serve to give the L2 world any clear guidance - no de facto limit > agreed between the L4 world and the L2 world. > > If we keep the limit in units of RTT, hopefully then we have a > virtuous circle, not a vicious circle. > > > > Bob > > On 09/11/2018 18:28, Scharf, Michael wrote: > > I may miss something, but I read the outcome of the appendix as a > requirement “must be more robust to reordering”. As far as I > understand, that can be implemented in different ways. > > And I may be wrong, but those link technologies could be well > implemented in a router and then one needs to analyze how that > whole architecture fits into the scheduler, queue, policer, and > line card hardware design of a router. But that is something > routing people know better than me. My point is just to get the > experts into the loop early. > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 7:04 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > Please address the scaling rationale in the appendix for why it > does matter how a sender realizes this internally. > > The list of access links types I mentioned are rarely connected > directly to routers. > > > > Bob > > On 09/11/2018 17:44, Scharf, Michael wrote: > > I’ll not comment on link technology implementation, scheduler > and queue design assumptions in Appendix A.1.7 of > draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area may be > more familiar with the implications of internal designs e.g. > inside a router. IMHO the best way to get routing experts into > the loop before further discussing what is currently listed in > Appendix A.1.7. > > Thus, I limit my response to the actual wording in the main > part of draft-ietf-tsvwg-ecn-l4s-id-05: > >     o  A scalable congestion control MUST detect loss by > counting in > >       units of time, which is scalable, and MUST NOT count in > units of > >       packets (as in the 3 DupACK rule of traditional TCP), > which is not > >       scalable (see Appendix A.1.7 > for > rationale). > > As individual contributor, I disagree with this requirement. I > would probably be OK with a wording that a TCP sender must be > able to tolerate reordering beyond 3 Duplicate ACKs. I believe > it does not matter how a sender realizes this internally. > > And if that requirement is not just removed, I believe the > wording “traditional TCP” has to be replaced by “standard TCP”. > > BTW, also, in the rest of the document there has to be a clear > distinction between experiments and standards. History tells > us that some experiments can evolve into standards track > specifications, while other experiments may fail. And there is > no way of knowing that in advance. > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 11:08 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > On 09/11/2018 06:21, Scharf, Michael wrote: > > I don’t see the fundamental difference between a link > technology that guarantees in-order delivery within a flow > (say by flow hashing, see ECMP) vs. some link scheme that > guarantees in-order delivery, say, only for some fraction > of the traffic characterized by some other means (say, > other header bits). > > [The "other means" and "other bits" wording is pretty > ambiguous here. I reckon I can guess what you mean but then I > don't know why you're saying this, 'cos I don't think I've > disagreed with you on this. So perhaps you could be more > specific and we might be able to see why you've brought this up.] > > Also I wasn't really talking about all "link technology that > guarantees in-order delivery within a flow". {Note 1} I was > talking about link technology where all flows are blocked > while waiting to get the aggregate back in order that it was > in when it arrived. I specifically said: > > > > Note that there can be multiple flows over one link. So > 'in-order delivery' for a link does not mean in order of TCP > sequence number. It means 'delivered in the order that packets > arrived at the link' (the link ingress adds its own sequence > numbers, and the link egress buffers them until it can send > out in the same order, or until a time-out or max no. of link > retransmissions). > > For example: > > * A packet resequencing buffer after allowing for link-layer > retransmissions is common for radio link technologies such > as LTE (PDCP layer) and 802.11 WiFi. > * A packet resequencing buffer after merging multiple bonded > link channels is common for other access link technologies > such as downstream DOCSIS bonded channels. > > > > > > Clearly, reordering is a problem that needs to be discussed in > the IETF as a whole. And we could discuss whether a revision > of RFC 3366 is needed. > > No. There is no proposal to alter general guidance for all > links like RFC 3366. No-one is saying this. > > There is not even a proposal to require or even recommend that > L4S-specific links do anything. > > The specific proposal is to require L4S /sources/ to use a > RACK-like scheme, as a condition for setting the ECT(1) > codepoint. See the last bullet in S.4.3 of > draft-ietf-tsvwg-ecn-l4s-id-05 > . > > > This says nothing about what L4S links MUST, SHOULD or MAY do. > It just gives an L4S link an opportunity not to have to do > resequencing. > > > > > But I am not convinced that this topic has to be tied into an > experiment such as L4S. > > It is an opportunity that currently only applies to L4S. > > L4S is merely an example of a case where we can mandate that > there will be no non-RACK traffic in a link, which creates an > opportunity for those who are implementing the L4S DualQ > Coupled AQM to ignore the RFC3366 resequencing advice for the > L4S queue (but we are not changing the advice, because L4S is > only an experiment). The prize is to remove the head-of-line > blocking problem for their users. > > This is not L4S-specific, altho there are no other examples at > the moment where this opportunity is possible (so in that > sense it is /currently/ L4S-specific). > > > The message has to be handled really carefully, because the > opportunities for misunderstanding are enormous (as evidenced > by this thread, and we haven't even started talking to > non-transport people yet). > > So Gorry and David B want me to draft a short I-D that they > will word-smith and author as tsvwg chairs to make the > situation clear. > > I have said I don't want this discussion to be officially > raised outside the transport area until we are sure that a > variant of RACK is even feasible without any packet counting > at all (i.e. without the initial 3-DupACK rule in current > RACK). So I'll prioritize working that out for the next week > or so, rather than drafting anything. > > > > Bob > > {Note 1}: I hadn't considered that this would affect > technologies like ECMP that maintain order without a > resequencing buffer and without introducing HoL blocking. But > actually, the consequence there would be that L4S traffic > could be sprayed by ECMP without per-flow hashing. > > > > > Michael > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 6:42 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > That is the point I thought you were making, and my point /is/ > about that. > > If an application needs all the packets (i.e. a reliable > protocol), it's not useful to reduce the latency of some > packets but not all. That's where the in-order requirement > comes from. > > However, if a stream-based transport is used (i.e. TCP) the > /application/ still gets in-order delivery from TCP. It just > doesn't have to require links to provide in order delivery as > well. > > Note that there can be multiple flows over one link. So > 'in-order delivery' for a link does not mean in order of TCP > sequence number. It means 'delivered in the order that packets > arrived at the link' (the link ingress adds its own sequence > numbers, and the link egress buffers them until it can send > out in the same order, or until a time-out or max no. of link > retransmissions). > > So, if the link loses a packet from flow A (the link isn't > aware of microflows, I'm just saying the packet happens to be > from flow A), link-layer in-order delivery will hold back all > packets sent after that packet (from all flows, not just flow > A) until the link repairs the gap or gives up. > > So hop-by-hop in-order delivery gives every flow the same > delay as the worst delayed flow. > > Of course, someone building a network for DETNET would avoid > link technologies like WiFi or LTE that frequently lose and > retransmit packets. But wherever there is variable delay in a > link, guaranteed in-order delivery per-hop means every flow is > guaranteed to always get the worst delay from every link, > which would have been experienced by only one flow without > per-hop in-order delivery. > > And many of the applications of DETNET involve dumb industrial > machinery that just expects everything to arrive in order and > to a clocked schedule. But it's always as effective to deploy > a resequencing buffer as the penultimate hop, screwed onto the > receiving machine if necessary, rather than require per-hop > resequencing in the network. > > ________________ > So, why do Internet links often ensure in-order delivery even > though TCP puts everything in order for the application? > > Short answer: the 3 DupACK rule (which is to do with > loss-recovery, a different issue from the discussion above). > > Long answer: As flow rates have scaled up, the typical time > between 3 packet arrivals has become so small that TCP's > 3-DupACK rule makes links have to provide delivery with only a > very small re-ordering degree - so small that it's easier for > a link to just deliver everything in the order it received it; > not because TCP doesn't put packets back in order, but just so > as not to trigger TCP into generating spurious retransmissions. > > > > Bob > > On 08/11/2018 16:35, Scharf, Michael wrote: > > Inline [ms] > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Thursday, November 8, 2018 12:56 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > This is merely a symptom of a difference in opinion on > where the resequencing function should be located. > > * L4S takes the end-to-end approach saying that it is > sufficient to do resequencing in one place (the > receiving host) if it is needed. Then any resequencing > delay only affects that flow. > * The DETNET approach is saying the resequencing must be > done hop-by-hop. This means there appears to be no > resequencing needed on the receiver (except if there's > re-ordering on the final hop). > > * In order to guarantee no resequencing in the network > (DETNET approach), only the the worst case latency can > be guaranteed, and every packet has to have that same > worst-case latency. > * When you leave resequencing to the receiver > (end-to-end approach), most of the packets arrive > earlier than they would with DETNET, but out of order > ones might not. Then the application chooses whether > it wants to wait. > > [ms] My point is different: There seem to be other working > groups in the IETF that do talk about “low latency” as > well but apparently they also do need in-order delivery of > packets, too. So the assumption that e.g. a link layer > technology can simply disable in-order delivery for all > “low latency” applications seems not correct. The reality > may be a bit more complex. > > The 3 DupACK rule in TCP led the Internet not to follow > the end-to-end principle on re-sequencing. Now we're > removing the 3 DupACK rule, we can take advantage of the > e2e principle. > > [ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and > RFC 5681 is standards track. So the bar for “removing” > that rule for TCP is not low… > > [ms] Also, the end-to-end principle comes with tradeoffs. > For instance, relying on the end-to-end principle for > recovery of bit errors is not efficient. For in-order > delivery there are tradeoffs as well, see e.g. Section 4 > in draft-ietf-tcpm-rack-04. There may be no free lunch. > > Of course, an application might choose to use TCP and L4S, > rather than UDP and L4S (e.g QUIC). Then there could still > be HoL blocking in the receiving TCP stack. But at least > there's no HoL blocking in the network, and the app can > choose between stream (TCP) or datagram (UDP). > > [ms] If LRO/GRO in the receiving TCP stack gets messed up, > I fail to see the benefit (see draft-ietf-tcpm-rack-04). > > Michael > > > Bob > > On 06/11/2018 19:20, Scharf, Michael wrote: > > A comment on the TCPM presentation "L4S and RACK": > > > > As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery. > > > > So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful? > > > > Michael > > (who recently had to review draft-ietf-detnet-architecture) > > > > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------7F0B484895BE17BF5AD75BFC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Praveen, Michael,

The idea is not to relax ordering requirement on links. It's to make sure it doesn't keep getting tighter for ever.

As flow-rates get faster, the requirements on links get tighter if the reordering window is expressed in packets.
For instance (as I showed in my presentation), with RTT = 24ms (say), if the window is 12 segments, a reordering window of 3 DupACKs equates to 6ms. But as flow rates increase, say 8 times faster (window = 96) reduces the time over which links have to keep packets in order to 750μs. Another 8x faster, and links have to keep order within 94μs. And so on.

This cannot go on indefinitely, because the constraints on link-layer retransmission are constant in time (length of link / speed of light + processing time). If the 3 DupACK rule is not removed, link timings will be continually squeezed, so radio links will eventually have to give up ARQ, which will be awful for performance.

It will take decades before /all/ legacy (non-RACK) TCPs have stopped using any particular link. So links in general will still have to keep tightening their re-sequencing time because of legacy 3 Dup-ACK flows. But eventually the 3-DupACK flows that remain will tend to be those on unmaintained machines that will not be taking advantage of higher speeds. Then, assuming the RACK experiment remains successful over these decades, links will be able to stop tightening their reordering degree.


The idea is that, for the L4S experiment, we can remove the 3 DupACK rule entirely from the start, and solely express reordering in units of time. Then, L4S transports will evolve, presumably using similar RACK-like reordering logic to non-L4S transports. And we shall see where the minimum reordering window ends up (in time units), and hopefully converge on a value we can standardize - both in TCP and in other transports.

No L4S link would relax its ordering requirement if it led to worse TCP performance. So layer 4 will be in control of this process. Nonetheless, it is important to stop measuring reordering in packets. But hopefully, from the start of the L4S experiment, logical links solely bearing L4S traffic will not need to continually tighten their ordering requirement.

If an OS supports RACK, which yours does, then buffering on the receiver will remain constant in time, which will mean the memory requirement will grow as flow rates scale up.

You (Praveen) supported and implemented RACK before I'd even thought about all this. I'm also now a convert. I'm recognizing and articulating its wider advantages.


Bob


On 09/11/2018 19:10, Praveen Balasubramanian wrote:

>> Therefore they can estimate the max reordering they allow their links to introduce

IMO L2 shouldn’t introduce more reordering just because L4 congestion control is more resilient to it. There is other performance impact due to reordering: LRO / GRO / RSC opportunity will be reduced, more memory and CPU cost to do reassembly at L4 (this is an active area for remote attacks) etc. IMO L4 guidance should remain that link vendors must avoid reordering as much as possible and not build solutions that cause frequent or consistent reordering.

 

From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Bob Briscoe
Sent: Friday, November 9, 2018 10:52 AM
To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

The idea is that (as now in the RACK draft since discussion on the tcpm list earlier this year under a subject something like vicious circle or virtuous circle) there will be a limit on the initial RACK reordering window expressed in fractional RTT units.

Link vendors know the min e2e RTT of the paths that their links are usually deployed over. Therefore they can estimate the max reordering they allow their links to introduce.

I don't expect this limit to be set in stone while both RACK and L4S are experimental. But as both these experiments progress, I think the industry will get a better idea of where the limit should lie.

It was the realization that, if TCP adapted its reordering window to the measured reordering degree without bound, the L2 world would continually increase the reordering degree of their links (the vicious circle).

If there is any aspect of this limit expressed in units of packets, the limit will decrease in time as flow rates increase, and therefore not serve to give the L2 world any clear guidance - no de facto limit agreed between the L4 world and the L2 world.

If we keep the limit in units of RTT, hopefully then we have a virtuous circle, not a vicious circle.



Bob

On 09/11/2018 18:28, Scharf, Michael wrote:

I may miss something, but I read the outcome of the appendix as a requirement “must be more robust to reordering”. As far as I understand, that can be implemented in different ways.

 

And I may be wrong, but those link technologies could be well implemented in a router and then one needs to analyze how that whole architecture fits into the scheduler, queue, policer, and line card hardware design of a router. But that is something routing people know better than me. My point is just to get the experts into the loop early.

 

Michael

 

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, November 9, 2018 7:04 PM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

Please address the scaling rationale in the appendix for why it does matter how a sender realizes this internally.

The list of access links types I mentioned are rarely connected directly to routers.



Bob

On 09/11/2018 17:44, Scharf, Michael wrote:

I’ll not comment on link technology implementation, scheduler and queue design assumptions in Appendix A.1.7 of draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area may be more familiar with the implications of internal designs e.g. inside a router. IMHO the best way to get routing experts into the loop before further discussing what is currently listed in Appendix A.1.7.

 

Thus, I limit my response to the actual wording in the main part of draft-ietf-tsvwg-ecn-l4s-id-05:

 

    o  A scalable congestion control MUST detect loss by counting in

      units of time, which is scalable, and MUST NOT count in units of

      packets (as in the 3 DupACK rule of traditional TCP), which is not

      scalable (see Appendix A.1.7 for rationale).

 

As individual contributor, I disagree with this requirement. I would probably be OK with a wording that a TCP sender must be able to tolerate reordering beyond 3 Duplicate ACKs. I believe it does not matter how a sender realizes this internally.

 

And if that requirement is not just removed, I believe the wording “traditional TCP” has to be replaced by “standard TCP”.

 

BTW, also, in the rest of the document there has to be a clear distinction between experiments and standards. History tells us that some experiments can evolve into standards track specifications, while other experiments may fail. And there is no way of knowing that in advance.

 

Michael

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: Friday, November 9, 2018 11:08 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

On 09/11/2018 06:21, Scharf, Michael wrote:

I don’t see the fundamental difference between a link technology that guarantees in-order delivery within a flow (say by flow hashing, see ECMP) vs. some link scheme that guarantees in-order delivery, say, only for some fraction of the traffic characterized by some other means (say, other header bits).

[The "other means" and "other bits" wording is pretty ambiguous here. I reckon I can guess what you mean but then I don't know why you're saying this, 'cos I don't think I've disagreed with you on this. So perhaps you could be more specific and we might be able to see why you've brought this up.]

Also I wasn't really talking about all "link technology that guarantees in-order delivery within a flow". {Note 1} I was talking about link technology where all flows are blocked while waiting to get the aggregate back in order that it was in when it arrived. I specifically said:



Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

For example:

  • A packet resequencing buffer after allowing for link-layer retransmissions is common for radio link technologies such as LTE (PDCP layer) and 802.11 WiFi.
  • A packet resequencing buffer after merging multiple bonded link channels is common for other access link technologies such as downstream DOCSIS bonded channels.





 

Clearly, reordering is a problem that needs to be discussed in the IETF as a whole. And we could discuss whether a revision of RFC 3366 is needed.

No. There is no proposal to alter general guidance for all links like RFC 3366. No-one is saying this.

There is not even a proposal to require or even recommend that L4S-specific links do anything.

The specific proposal is to require L4S sources to use a RACK-like scheme, as a condition for setting the ECT(1) codepoint. See the last bullet in S.4.3 of draft-ietf-tsvwg-ecn-l4s-id-05.

This says nothing about what L4S links MUST, SHOULD or MAY do. It just gives an L4S link an opportunity not to have to do resequencing.




 

But I am not convinced that this topic has to be tied into an experiment such as L4S.

It is an opportunity that currently only applies to L4S.

L4S is merely an example of a case where we can mandate that there will be no non-RACK traffic in a link, which creates an opportunity for those who are implementing the L4S DualQ Coupled AQM to ignore the RFC3366 resequencing advice for the L4S queue (but we are not changing the advice, because L4S is only an experiment). The prize is to remove the head-of-line blocking problem for their users.

This is not L4S-specific, altho there are no other examples at the moment where this opportunity is possible (so in that sense it is currently L4S-specific).


The message has to be handled really carefully, because the opportunities for misunderstanding are enormous (as evidenced by this thread, and we haven't even started talking to non-transport people yet).

So Gorry and David B want me to draft a short I-D that they will word-smith and author as tsvwg chairs to make the situation clear.

I have said I don't want this discussion to be officially raised outside the transport area until we are sure that a variant of RACK is even feasible without any packet counting at all (i.e. without the initial 3-DupACK rule in current RACK). So I'll prioritize working that out for the next week or so, rather than drafting anything.



Bob

{Note 1}: I hadn't considered that this would affect technologies like ECMP that maintain order without a resequencing buffer and without introducing HoL blocking. But actually, the consequence there would be that L4S traffic could be sprayed by ECMP without per-flow hashing.




 

Michael

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Friday, November 9, 2018 6:42 AM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

That is the point I thought you were making, and my point /is/ about that.

If an application needs all the packets (i.e. a reliable protocol), it's not useful to reduce the latency of some packets but not all. That's where the in-order requirement comes from.

However, if a stream-based transport is used (i.e. TCP) the /application/ still gets in-order delivery from TCP. It just doesn't have to require links to provide in order delivery as well.

Note that there can be multiple flows over one link. So 'in-order delivery' for a link does not mean in order of TCP sequence number. It means 'delivered in the order that packets arrived at the link' (the link ingress adds its own sequence numbers, and the link egress buffers them until it can send out in the same order, or until a time-out or max no. of link retransmissions).

So, if the link loses a packet from flow A (the link isn't aware of microflows, I'm just saying the packet happens to be from flow A), link-layer in-order delivery will hold back all packets sent after that packet (from all flows, not just flow A) until the link repairs the gap or gives up.

So hop-by-hop in-order delivery gives every flow the same delay as the worst delayed flow.

Of course, someone building a network for DETNET would avoid link technologies like WiFi or LTE that frequently lose and retransmit packets. But wherever there is variable delay in a link, guaranteed in-order delivery per-hop means every flow is guaranteed to always get the worst delay from every link, which would have been experienced by only one flow without per-hop in-order delivery.

And many of the applications of DETNET involve dumb industrial machinery that just expects everything to arrive in order and to a clocked schedule. But it's always as effective to deploy a resequencing buffer as the penultimate hop, screwed onto the receiving machine if necessary, rather than require per-hop resequencing in the network.

________________
So, why do Internet links often ensure in-order delivery even though TCP puts everything in order for the application?

Short answer: the 3 DupACK rule (which is to do with loss-recovery, a different issue from the discussion above).

Long answer: As flow rates have scaled up, the typical time between 3 packet arrivals has become so small that TCP's 3-DupACK rule makes links have to provide delivery with only a very small re-ordering degree - so small that it's easier for a link to just deliver everything in the order it received it; not because TCP doesn't put packets back in order, but just so as not to trigger TCP into generating spurious retransmissions.



Bob

On 08/11/2018 16:35, Scharf, Michael wrote:

Inline [ms]

 

From: Bob Briscoe [mailto:in@bobbriscoe.net]
Sent: Thursday, November 8, 2018 12:56 PM
To: Scharf, Michael; tcpm@ietf.org
Cc: tsvwg@ietf.org
Subject: Re: [tsvwg] Cross-area alignment on "L4S and RACK"

 

Michael,

This is merely a symptom of a difference in opinion on where the resequencing function should be located.

  • L4S takes the end-to-end approach saying that it is sufficient to do resequencing in one place (the receiving host) if it is needed. Then any resequencing delay only affects that flow.
  • The DETNET approach is saying the resequencing must be done hop-by-hop. This means there appears to be no resequencing needed on the receiver (except if there's re-ordering on the final hop).

 

  • In order to guarantee no resequencing in the network (DETNET approach), only the the worst case latency can be guaranteed, and every packet has to have that same worst-case latency.
  • When you leave resequencing to the receiver (end-to-end approach), most of the packets arrive earlier than they would with DETNET, but out of order ones might not. Then the application chooses whether it wants to wait.

[ms] My point is different: There seem to be other working groups in the IETF that do talk about “low latency” as well but apparently they also do need in-order delivery of packets, too. So the assumption that e.g. a link layer technology can simply disable in-order delivery for all “low latency” applications seems not correct. The reality may be a bit more complex.

The 3 DupACK rule in TCP led the Internet not to follow the end-to-end principle on re-sequencing. Now we're removing the 3 DupACK rule, we can take advantage of the e2e principle.

[ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC 5681 is standards track. So the bar for “removing” that rule for TCP is not low…

[ms] Also, the end-to-end principle comes with tradeoffs. For instance, relying on the end-to-end principle for recovery of bit errors is not efficient. For in-order delivery there are tradeoffs as well, see e.g. Section 4 in draft-ietf-tcpm-rack-04. There may be no free lunch.

Of course, an application might choose to use TCP and L4S, rather than UDP and L4S (e.g QUIC). Then there could still be HoL blocking in the receiving TCP stack. But at least there's no HoL blocking in the network, and the app can choose between stream (TCP) or datagram (UDP).

[ms] If LRO/GRO in the receiving TCP stack gets messed up, I fail to see the benefit (see draft-ietf-tcpm-rack-04).

Michael


Bob

On 06/11/2018 19:20, Scharf, Michael wrote:

A comment on the TCPM presentation "L4S and RACK":
 
As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery.
 
So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful?
 
Michael
(who recently had to review draft-ietf-detnet-architecture)
 
 







-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/






-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/





-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/




-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/



-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------7F0B484895BE17BF5AD75BFC-- From nobody Sat Nov 10 00:13:56 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333BB130E02; Sat, 10 Nov 2018 00:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU5X86cmrExv; Sat, 10 Nov 2018 00:13:50 -0800 (PST) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A5612D4ED; Sat, 10 Nov 2018 00:13:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id AE22325A18; Sat, 10 Nov 2018 09:13:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1541837627; bh=1uKLOxif+baDhs3VRT0QKjOivLxTWqhNUI2poNC/ArA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=WSYwcNnh8ht3mXme8l7wzSXawD5JuCXzGPkd1UaMuY3sw4SVppHNwcYQvtLpjMNVX z2Cs1YEGFwzsOVvALyHnT1NcCylZiXvYaO2dXfUv73CWfItv9k40JKlkvGuieTAghG emXJAuI+n+OJVgx83aHOc0GKGhQgpk5BvbthO+o4= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AELYt5QBtYtV; Sat, 10 Nov 2018 09:13:47 +0100 (CET) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.hs-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sat, 10 Nov 2018 09:13:47 +0100 (CET) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.25]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0415.000; Sat, 10 Nov 2018 09:13:46 +0100 From: "Scharf, Michael" To: Bob Briscoe , Praveen Balasubramanian , "tcpm@ietf.org" CC: "tsvwg@ietf.org" Thread-Topic: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" Thread-Index: AdR2Bb4d1a0DCDIIR0elSSOg03+wFgBS9LuAAAnyRqAAG025AAACx04QAAaGWYAAD7CAQAAA6LeAAAIdXND///yrgIAABP8AgABrZoD//40q8A== Date: Sat, 10 Nov 2018 08:13:46 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D154250@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D1537CD@rznt8114.rznt.rzdir.fht-esslingen.de> <45512894-fc71-a4a8-4043-3feb06f9e347@bobbriscoe.net> <6413d62f-ecf1-3319-7bb2-2c763b0633be@bobbriscoe.net> In-Reply-To: <6413d62f-ecf1-3319-7bb2-2c763b0633be@bobbriscoe.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.29.249] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D154250rznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2018 08:13:55 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2D154250rznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQm9iLA0KDQpJIGJlbGlldmUgbW9yZSBlbXBpcmljYWwgZXZpZGVuY2UgaXMgbmVlZGVkIHRo YXQgdGhpcyBpcyBhIHByb2JsZW0gdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZC4NCg0KRm9yIGlu c3RhbmNlLCBmb3Igd2hhdCBsaW5rIHRlY2hub2xvZ2llcyBkb2VzIHRoaXMgcHJvYmxlbSBleGlz dCBpbiByZWFsaXR5Pw0KDQpZb3VyIGV4YW1wbGUgd2l0aCA5NHVzIHNlZW1zIHRvIGltcGx5IGEg ZGF0YSByYXRlIG9mIDM4NCBNYml0L3MgZm9yIGEgc2luZ2xlIFRDUCBzdHJlYW0uIFRoYXQgaXMg cHJvYmFibHkgbm90IHdoYXQgdGhlIHZhc3QgbWFqb3JpdHkgb2YgVENQIGNvbm5lY3Rpb25zIHVz ZS4gU28gaXMgdGhlcmUgYW4gZW5naW5lZXJpbmcgbmVlZD8NCg0KQW5kIEkgZG9u4oCZdCBnZXQg d2h5IGtlZXBpbmcgcmVvcmRlcmluZyB3aXRoaW4gOTR1cyBpcyBzbyBtdWNoIG9mIGEgY2hhbGxl bmdlIGZvciBhIGxpbmsgbGF5ZXIgdGVjaG5vbG9neS4gSSB3b3VsZCByZWFsbHkgbGlrZSB0byBs ZWFybiB0ZWNobmljYWwgcmVhc29ucyB3aHkgKG1vc3RseSkgaW4tb3JkZXIgZGVsaXZlcnkgb24g bGlua3MgY2Fubm90IGJlIGltcGxlbWVudGVkIG5vdyBvciBpbiBmdXR1cmUuDQoNCklmIHdlIGlu ZGVlZCBydW4gaW50byBhIHJlYWwtd29ybGQgdGVjaG5pY2FsIHByb2JsZW0sIGl0IHdvdWxkbuKA mXQgaGVscCB0byBzb2x2ZSB0aGF0IHByb2JsZW0gZm9yIEw0UyDigJMgaXQgbXVzdCBiZSBzb2x2 ZWQgZm9yIGFsbCBJbnRlcm5ldCB0cmFmZmljIHRoZW4gYW5kIHRoZSBvdmVyYWxsIHNvbHV0aW9u IHdvdWxkIChwcm9iYWJseSkgYmUgZGlmZmVyZW50IHRvIHRoZSBvbmUgdXNlZCBpbiBhbiBleHBl cmltZW50Lg0KDQpUbyBtZSwgb25lIG9mIHRoZSBmdW5kYW1lbnRhbCByZXF1aXJlbWVudHMgb24g YSBwYWNrZXQgbmV0d29yayBpcyB0aGF0IHRoZSBuZXR3b3JrIGludmVzdHMgc29tZSByZWFzb25h YmxlIGVmZm9ydCB0byBrZWVwIHBhY2tldHMgaW4gb3JkZXIgb24gYSBnaXZlbiBwYXRoIOKAkyBh bGJlaXQgYSBwYWNrZXQgbmV0d29yayBpcyBub3QgYWx3YXlzIHBlcmZlY3QgYW5kIHRoYXQgaGFz IGFsd2F5cyBiZWVuIE9LLiBJIGFtIG5vdCBjb252aW5jZWQgc28gZmFyIHRoYXQgaXQgbWFrZXMg c2Vuc2UgdG8gZ2l2ZSB1cCB0aGF0IGRlc2lnbiBndWlkZWxpbmUgZm9yIGxpbmsgdGVjaG5vbG9n aWVzIOKAkyBub3QgZXZlbiBmb3IgTDRTLg0KDQpNaWNoYWVsDQoNCg0KDQpGcm9tOiBCb2IgQnJp c2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBTYXR1cmRheSwgTm92ZW1i ZXIgMTAsIDIwMTggMjozNSBBTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuOyBTY2hhcmYs IE1pY2hhZWw7IHRjcG1AaWV0Zi5vcmcNCkNjOiB0c3Z3Z0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFt0Y3BtXSBbdHN2d2ddIENyb3NzLWFyZWEgYWxpZ25tZW50IG9uICJMNFMgYW5kIFJBQ0siDQoN ClByYXZlZW4sIE1pY2hhZWwsDQoNClRoZSBpZGVhIGlzIG5vdCB0byByZWxheCBvcmRlcmluZyBy ZXF1aXJlbWVudCBvbiBsaW5rcy4gSXQncyB0byBtYWtlIHN1cmUgaXQgZG9lc24ndCBrZWVwIGdl dHRpbmcgdGlnaHRlciBmb3IgZXZlci4NCg0KQXMgZmxvdy1yYXRlcyBnZXQgZmFzdGVyLCB0aGUg cmVxdWlyZW1lbnRzIG9uIGxpbmtzIGdldCB0aWdodGVyIGlmIHRoZSByZW9yZGVyaW5nIHdpbmRv dyBpcyBleHByZXNzZWQgaW4gcGFja2V0cy4NCkZvciBpbnN0YW5jZSAoYXMgSSBzaG93ZWQgaW4g bXkgcHJlc2VudGF0aW9uKSwgd2l0aCBSVFQgPSAyNG1zIChzYXkpLCBpZiB0aGUgd2luZG93IGlz IDEyIHNlZ21lbnRzLCBhIHJlb3JkZXJpbmcgd2luZG93IG9mIDMgRHVwQUNLcyBlcXVhdGVzIHRv IDZtcy4gQnV0IGFzIGZsb3cgcmF0ZXMgaW5jcmVhc2UsIHNheSA4IHRpbWVzIGZhc3RlciAod2lu ZG93ID0gOTYpIHJlZHVjZXMgdGhlIHRpbWUgb3ZlciB3aGljaCBsaW5rcyBoYXZlIHRvIGtlZXAg cGFja2V0cyBpbiBvcmRlciB0byA3NTDOvHMuIEFub3RoZXIgOHggZmFzdGVyLCBhbmQgbGlua3Mg aGF2ZSB0byBrZWVwIG9yZGVyIHdpdGhpbiA5NM68cy4gQW5kIHNvIG9uLg0KDQpUaGlzIGNhbm5v dCBnbyBvbiBpbmRlZmluaXRlbHksIGJlY2F1c2UgdGhlIGNvbnN0cmFpbnRzIG9uIGxpbmstbGF5 ZXIgcmV0cmFuc21pc3Npb24gYXJlIGNvbnN0YW50IGluIHRpbWUgKGxlbmd0aCBvZiBsaW5rIC8g c3BlZWQgb2YgbGlnaHQgKyBwcm9jZXNzaW5nIHRpbWUpLiBJZiB0aGUgMyBEdXBBQ0sgcnVsZSBp cyBub3QgcmVtb3ZlZCwgbGluayB0aW1pbmdzIHdpbGwgYmUgY29udGludWFsbHkgc3F1ZWV6ZWQs IHNvIHJhZGlvIGxpbmtzIHdpbGwgZXZlbnR1YWxseSBoYXZlIHRvIGdpdmUgdXAgQVJRLCB3aGlj aCB3aWxsIGJlIGF3ZnVsIGZvciBwZXJmb3JtYW5jZS4NCg0KSXQgd2lsbCB0YWtlIGRlY2FkZXMg YmVmb3JlIC9hbGwvIGxlZ2FjeSAobm9uLVJBQ0spIFRDUHMgaGF2ZSBzdG9wcGVkIHVzaW5nIGFu eSBwYXJ0aWN1bGFyIGxpbmsuIFNvIGxpbmtzIGluIGdlbmVyYWwgd2lsbCBzdGlsbCBoYXZlIHRv IGtlZXAgdGlnaHRlbmluZyB0aGVpciByZS1zZXF1ZW5jaW5nIHRpbWUgYmVjYXVzZSBvZiBsZWdh Y3kgMyBEdXAtQUNLIGZsb3dzLiBCdXQgZXZlbnR1YWxseSB0aGUgMy1EdXBBQ0sgZmxvd3MgdGhh dCByZW1haW4gd2lsbCB0ZW5kIHRvIGJlIHRob3NlIG9uIHVubWFpbnRhaW5lZCBtYWNoaW5lcyB0 aGF0IHdpbGwgbm90IGJlIHRha2luZyBhZHZhbnRhZ2Ugb2YgaGlnaGVyIHNwZWVkcy4gVGhlbiwg YXNzdW1pbmcgdGhlIFJBQ0sgZXhwZXJpbWVudCByZW1haW5zIHN1Y2Nlc3NmdWwgb3ZlciB0aGVz ZSBkZWNhZGVzLCBsaW5rcyB3aWxsIGJlIGFibGUgdG8gc3RvcCB0aWdodGVuaW5nIHRoZWlyIHJl b3JkZXJpbmcgZGVncmVlLg0KDQoNClRoZSBpZGVhIGlzIHRoYXQsIGZvciB0aGUgTDRTIGV4cGVy aW1lbnQsIHdlIGNhbiByZW1vdmUgdGhlIDMgRHVwQUNLIHJ1bGUgZW50aXJlbHkgZnJvbSB0aGUg c3RhcnQsIGFuZCBzb2xlbHkgZXhwcmVzcyByZW9yZGVyaW5nIGluIHVuaXRzIG9mIHRpbWUuIFRo ZW4sIEw0UyB0cmFuc3BvcnRzIHdpbGwgZXZvbHZlLCBwcmVzdW1hYmx5IHVzaW5nIHNpbWlsYXIg UkFDSy1saWtlIHJlb3JkZXJpbmcgbG9naWMgdG8gbm9uLUw0UyB0cmFuc3BvcnRzLiBBbmQgd2Ug c2hhbGwgc2VlIHdoZXJlIHRoZSBtaW5pbXVtIHJlb3JkZXJpbmcgd2luZG93IGVuZHMgdXAgKGlu IHRpbWUgdW5pdHMpLCBhbmQgaG9wZWZ1bGx5IGNvbnZlcmdlIG9uIGEgdmFsdWUgd2UgY2FuIHN0 YW5kYXJkaXplIC0gYm90aCBpbiBUQ1AgYW5kIGluIG90aGVyIHRyYW5zcG9ydHMuDQoNCk5vIEw0 UyBsaW5rIHdvdWxkIHJlbGF4IGl0cyBvcmRlcmluZyByZXF1aXJlbWVudCBpZiBpdCBsZWQgdG8g d29yc2UgVENQIHBlcmZvcm1hbmNlLiBTbyBsYXllciA0IHdpbGwgYmUgaW4gY29udHJvbCBvZiB0 aGlzIHByb2Nlc3MuIE5vbmV0aGVsZXNzLCBpdCBpcyBpbXBvcnRhbnQgdG8gc3RvcCBtZWFzdXJp bmcgcmVvcmRlcmluZyBpbiBwYWNrZXRzLiBCdXQgaG9wZWZ1bGx5LCBmcm9tIHRoZSBzdGFydCBv ZiB0aGUgTDRTIGV4cGVyaW1lbnQsIGxvZ2ljYWwgbGlua3Mgc29sZWx5IGJlYXJpbmcgTDRTIHRy YWZmaWMgd2lsbCBub3QgbmVlZCB0byBjb250aW51YWxseSB0aWdodGVuIHRoZWlyIG9yZGVyaW5n IHJlcXVpcmVtZW50Lg0KDQpJZiBhbiBPUyBzdXBwb3J0cyBSQUNLLCB3aGljaCB5b3VycyBkb2Vz LCB0aGVuIGJ1ZmZlcmluZyBvbiB0aGUgcmVjZWl2ZXIgd2lsbCByZW1haW4gY29uc3RhbnQgaW4g dGltZSwgd2hpY2ggd2lsbCBtZWFuIHRoZSBtZW1vcnkgcmVxdWlyZW1lbnQgd2lsbCBncm93IGFz IGZsb3cgcmF0ZXMgc2NhbGUgdXAuDQoNCllvdSAoUHJhdmVlbikgc3VwcG9ydGVkIGFuZCBpbXBs ZW1lbnRlZCBSQUNLIGJlZm9yZSBJJ2QgZXZlbiB0aG91Z2h0IGFib3V0IGFsbCB0aGlzLiBJJ20g YWxzbyBub3cgYSBjb252ZXJ0LiBJJ20gcmVjb2duaXppbmcgYW5kIGFydGljdWxhdGluZyBpdHMg d2lkZXIgYWR2YW50YWdlcy4NCg0KDQpCb2INCg0KT24gMDkvMTEvMjAxOCAxOToxMCwgUHJhdmVl biBCYWxhc3VicmFtYW5pYW4gd3JvdGU6DQo+PiBUaGVyZWZvcmUgdGhleSBjYW4gZXN0aW1hdGUg dGhlIG1heCByZW9yZGVyaW5nIHRoZXkgYWxsb3cgdGhlaXIgbGlua3MgdG8gaW50cm9kdWNlDQpJ TU8gTDIgc2hvdWxkbuKAmXQgaW50cm9kdWNlIG1vcmUgcmVvcmRlcmluZyBqdXN0IGJlY2F1c2Ug TDQgY29uZ2VzdGlvbiBjb250cm9sIGlzIG1vcmUgcmVzaWxpZW50IHRvIGl0LiBUaGVyZSBpcyBv dGhlciBwZXJmb3JtYW5jZSBpbXBhY3QgZHVlIHRvIHJlb3JkZXJpbmc6IExSTyAvIEdSTyAvIFJT QyBvcHBvcnR1bml0eSB3aWxsIGJlIHJlZHVjZWQsIG1vcmUgbWVtb3J5IGFuZCBDUFUgY29zdCB0 byBkbyByZWFzc2VtYmx5IGF0IEw0ICh0aGlzIGlzIGFuIGFjdGl2ZSBhcmVhIGZvciByZW1vdGUg YXR0YWNrcykgZXRjLiBJTU8gTDQgZ3VpZGFuY2Ugc2hvdWxkIHJlbWFpbiB0aGF0IGxpbmsgdmVu ZG9ycyBtdXN0IGF2b2lkIHJlb3JkZXJpbmcgYXMgbXVjaCBhcyBwb3NzaWJsZSBhbmQgbm90IGJ1 aWxkIHNvbHV0aW9ucyB0aGF0IGNhdXNlIGZyZXF1ZW50IG9yIGNvbnNpc3RlbnQgcmVvcmRlcmlu Zy4NCg0KRnJvbTogdGNwbSA8dGNwbS1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86dGNwbS1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQm9iIEJyaXNjb2UNClNlbnQ6IEZyaWRheSwgTm92 ZW1iZXIgOSwgMjAxOCAxMDo1MiBBTQ0KVG86IFNjaGFyZiwgTWljaGFlbCA8TWljaGFlbC5TY2hh cmZAaHMtZXNzbGluZ2VuLmRlPjxtYWlsdG86TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRl PjsgdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCkNjOiB0c3Z3Z0BpZXRmLm9y ZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RjcG1dIFt0c3Z3Z10gQ3Jv c3MtYXJlYSBhbGlnbm1lbnQgb24gIkw0UyBhbmQgUkFDSyINCg0KTWljaGFlbCwNCg0KVGhlIGlk ZWEgaXMgdGhhdCAoYXMgbm93IGluIHRoZSBSQUNLIGRyYWZ0IHNpbmNlIGRpc2N1c3Npb24gb24g dGhlIHRjcG0gbGlzdCBlYXJsaWVyIHRoaXMgeWVhciB1bmRlciBhIHN1YmplY3Qgc29tZXRoaW5n IGxpa2UgdmljaW91cyBjaXJjbGUgb3IgdmlydHVvdXMgY2lyY2xlKSB0aGVyZSB3aWxsIGJlIGEg bGltaXQgb24gdGhlIGluaXRpYWwgUkFDSyByZW9yZGVyaW5nIHdpbmRvdyBleHByZXNzZWQgaW4g ZnJhY3Rpb25hbCBSVFQgdW5pdHMuDQoNCkxpbmsgdmVuZG9ycyBrbm93IHRoZSBtaW4gZTJlIFJU VCBvZiB0aGUgcGF0aHMgdGhhdCB0aGVpciBsaW5rcyBhcmUgdXN1YWxseSBkZXBsb3llZCBvdmVy LiBUaGVyZWZvcmUgdGhleSBjYW4gZXN0aW1hdGUgdGhlIG1heCByZW9yZGVyaW5nIHRoZXkgYWxs b3cgdGhlaXIgbGlua3MgdG8gaW50cm9kdWNlLg0KDQpJIGRvbid0IGV4cGVjdCB0aGlzIGxpbWl0 IHRvIGJlIHNldCBpbiBzdG9uZSB3aGlsZSBib3RoIFJBQ0sgYW5kIEw0UyBhcmUgZXhwZXJpbWVu dGFsLiBCdXQgYXMgYm90aCB0aGVzZSBleHBlcmltZW50cyBwcm9ncmVzcywgSSB0aGluayB0aGUg aW5kdXN0cnkgd2lsbCBnZXQgYSBiZXR0ZXIgaWRlYSBvZiB3aGVyZSB0aGUgbGltaXQgc2hvdWxk IGxpZS4NCg0KSXQgd2FzIHRoZSByZWFsaXphdGlvbiB0aGF0LCBpZiBUQ1AgYWRhcHRlZCBpdHMg cmVvcmRlcmluZyB3aW5kb3cgdG8gdGhlIG1lYXN1cmVkIHJlb3JkZXJpbmcgZGVncmVlIHdpdGhv dXQgYm91bmQsIHRoZSBMMiB3b3JsZCB3b3VsZCBjb250aW51YWxseSBpbmNyZWFzZSB0aGUgcmVv cmRlcmluZyBkZWdyZWUgb2YgdGhlaXIgbGlua3MgKHRoZSB2aWNpb3VzIGNpcmNsZSkuDQoNCklm IHRoZXJlIGlzIGFueSBhc3BlY3Qgb2YgdGhpcyBsaW1pdCBleHByZXNzZWQgaW4gdW5pdHMgb2Yg cGFja2V0cywgdGhlIGxpbWl0IHdpbGwgZGVjcmVhc2UgaW4gdGltZSBhcyBmbG93IHJhdGVzIGlu Y3JlYXNlLCBhbmQgdGhlcmVmb3JlIG5vdCBzZXJ2ZSB0byBnaXZlIHRoZSBMMiB3b3JsZCBhbnkg Y2xlYXIgZ3VpZGFuY2UgLSBubyBkZSBmYWN0byBsaW1pdCBhZ3JlZWQgYmV0d2VlbiB0aGUgTDQg d29ybGQgYW5kIHRoZSBMMiB3b3JsZC4NCg0KSWYgd2Uga2VlcCB0aGUgbGltaXQgaW4gdW5pdHMg b2YgUlRULCBob3BlZnVsbHkgdGhlbiB3ZSBoYXZlIGEgdmlydHVvdXMgY2lyY2xlLCBub3QgYSB2 aWNpb3VzIGNpcmNsZS4NCg0KDQoNCkJvYg0KDQoNCk9uIDA5LzExLzIwMTggMTg6MjgsIFNjaGFy ZiwgTWljaGFlbCB3cm90ZToNCkkgbWF5IG1pc3Mgc29tZXRoaW5nLCBidXQgSSByZWFkIHRoZSBv dXRjb21lIG9mIHRoZSBhcHBlbmRpeCBhcyBhIHJlcXVpcmVtZW50IOKAnG11c3QgYmUgbW9yZSBy b2J1c3QgdG8gcmVvcmRlcmluZ+KAnS4gQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCwgdGhhdCBjYW4g YmUgaW1wbGVtZW50ZWQgaW4gZGlmZmVyZW50IHdheXMuDQoNCkFuZCBJIG1heSBiZSB3cm9uZywg YnV0IHRob3NlIGxpbmsgdGVjaG5vbG9naWVzIGNvdWxkIGJlIHdlbGwgaW1wbGVtZW50ZWQgaW4g YSByb3V0ZXIgYW5kIHRoZW4gb25lIG5lZWRzIHRvIGFuYWx5emUgaG93IHRoYXQgd2hvbGUgYXJj aGl0ZWN0dXJlIGZpdHMgaW50byB0aGUgc2NoZWR1bGVyLCBxdWV1ZSwgcG9saWNlciwgYW5kIGxp bmUgY2FyZCBoYXJkd2FyZSBkZXNpZ24gb2YgYSByb3V0ZXIuIEJ1dCB0aGF0IGlzIHNvbWV0aGlu ZyByb3V0aW5nIHBlb3BsZSBrbm93IGJldHRlciB0aGFuIG1lLiBNeSBwb2ludCBpcyBqdXN0IHRv IGdldCB0aGUgZXhwZXJ0cyBpbnRvIHRoZSBsb29wIGVhcmx5Lg0KDQpNaWNoYWVsDQoNCg0KRnJv bTogQm9iIEJyaXNjb2UgW21haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0XQ0KU2VudDogRnJpZGF5 LCBOb3ZlbWJlciA5LCAyMDE4IDc6MDQgUE0NClRvOiBTY2hhcmYsIE1pY2hhZWw7IHRjcG1AaWV0 Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpDYzogdHN2d2dAaWV0Zi5vcmc8bWFpbHRvOnRz dndnQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQg b24gIkw0UyBhbmQgUkFDSyINCg0KTWljaGFlbCwNCg0KUGxlYXNlIGFkZHJlc3MgdGhlIHNjYWxp bmcgcmF0aW9uYWxlIGluIHRoZSBhcHBlbmRpeCBmb3Igd2h5IGl0IGRvZXMgbWF0dGVyIGhvdyBh IHNlbmRlciByZWFsaXplcyB0aGlzIGludGVybmFsbHkuDQoNClRoZSBsaXN0IG9mIGFjY2VzcyBs aW5rcyB0eXBlcyBJIG1lbnRpb25lZCBhcmUgcmFyZWx5IGNvbm5lY3RlZCBkaXJlY3RseSB0byBy b3V0ZXJzLg0KDQoNCg0KQm9iDQpPbiAwOS8xMS8yMDE4IDE3OjQ0LCBTY2hhcmYsIE1pY2hhZWwg d3JvdGU6DQpJ4oCZbGwgbm90IGNvbW1lbnQgb24gbGluayB0ZWNobm9sb2d5IGltcGxlbWVudGF0 aW9uLCBzY2hlZHVsZXIgYW5kIHF1ZXVlIGRlc2lnbiBhc3N1bXB0aW9ucyBpbiBBcHBlbmRpeCBB LjEuNyBvZiBkcmFmdC1pZXRmLXRzdndnLWVjbi1sNHMtaWQtMDUuIFBlb3BsZSBlLmcuIGluIFJU RyBhcmVhIG1heSBiZSBtb3JlIGZhbWlsaWFyIHdpdGggdGhlIGltcGxpY2F0aW9ucyBvZiBpbnRl cm5hbCBkZXNpZ25zIGUuZy4gaW5zaWRlIGEgcm91dGVyLiBJTUhPIHRoZSBiZXN0IHdheSB0byBn ZXQgcm91dGluZyBleHBlcnRzIGludG8gdGhlIGxvb3AgYmVmb3JlIGZ1cnRoZXIgZGlzY3Vzc2lu ZyB3aGF0IGlzIGN1cnJlbnRseSBsaXN0ZWQgaW4gQXBwZW5kaXggQS4xLjcuDQoNClRodXMsIEkg bGltaXQgbXkgcmVzcG9uc2UgdG8gdGhlIGFjdHVhbCB3b3JkaW5nIGluIHRoZSBtYWluIHBhcnQg b2YgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tbDRzLWlkLTA1Og0KDQogICAgbyAgQSBzY2FsYWJsZSBj b25nZXN0aW9uIGNvbnRyb2wgTVVTVCBkZXRlY3QgbG9zcyBieSBjb3VudGluZyBpbg0KICAgICAg dW5pdHMgb2YgdGltZSwgd2hpY2ggaXMgc2NhbGFibGUsIGFuZCBNVVNUIE5PVCBjb3VudCBpbiB1 bml0cyBvZg0KICAgICAgcGFja2V0cyAoYXMgaW4gdGhlIDMgRHVwQUNLIHJ1bGUgb2YgdHJhZGl0 aW9uYWwgVENQKSwgd2hpY2ggaXMgbm90DQogICAgICBzY2FsYWJsZSAoc2VlIEFwcGVuZGl4IEEu MS43PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtaWV0Zi10c3Z3Zy1lY24t bDRzLWlkLTA1JTIzYXBwZW5kaXgtQS4xLjcmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3Nv ZnQuY29tJTdDNTQ3ZTUwM2UyMTg1NDk0ODNmMzAwOGQ2NDY3NDk1YjklN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NzczODYzODk1NDk2NDk4JnNkYXRhPSUy QmV6OU9DWmkxbTV3eDdUR0hrdmZHOVFzSmZKMFZ4aHNYeW5xV1cyalhHNCUzRCZyZXNlcnZlZD0w PiBmb3IgcmF0aW9uYWxlKS4NCg0KQXMgaW5kaXZpZHVhbCBjb250cmlidXRvciwgSSBkaXNhZ3Jl ZSB3aXRoIHRoaXMgcmVxdWlyZW1lbnQuIEkgd291bGQgcHJvYmFibHkgYmUgT0sgd2l0aCBhIHdv cmRpbmcgdGhhdCBhIFRDUCBzZW5kZXIgbXVzdCBiZSBhYmxlIHRvIHRvbGVyYXRlIHJlb3JkZXJp bmcgYmV5b25kIDMgRHVwbGljYXRlIEFDS3MuIEkgYmVsaWV2ZSBpdCBkb2VzIG5vdCBtYXR0ZXIg aG93IGEgc2VuZGVyIHJlYWxpemVzIHRoaXMgaW50ZXJuYWxseS4NCg0KQW5kIGlmIHRoYXQgcmVx dWlyZW1lbnQgaXMgbm90IGp1c3QgcmVtb3ZlZCwgSSBiZWxpZXZlIHRoZSB3b3JkaW5nIOKAnHRy YWRpdGlvbmFsIFRDUOKAnSBoYXMgdG8gYmUgcmVwbGFjZWQgYnkg4oCcc3RhbmRhcmQgVENQ4oCd Lg0KDQpCVFcsIGFsc28sIGluIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCB0aGVyZSBoYXMgdG8g YmUgYSBjbGVhciBkaXN0aW5jdGlvbiBiZXR3ZWVuIGV4cGVyaW1lbnRzIGFuZCBzdGFuZGFyZHMu IEhpc3RvcnkgdGVsbHMgdXMgdGhhdCBzb21lIGV4cGVyaW1lbnRzIGNhbiBldm9sdmUgaW50byBz dGFuZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbnMsIHdoaWxlIG90aGVyIGV4cGVyaW1lbnRzIG1h eSBmYWlsLiBBbmQgdGhlcmUgaXMgbm8gd2F5IG9mIGtub3dpbmcgdGhhdCBpbiBhZHZhbmNlLg0K DQpNaWNoYWVsDQoNCkZyb206IEJvYiBCcmlzY29lIFttYWlsdG86aWV0ZkBib2JicmlzY29lLm5l dF0NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgOSwgMjAxOCAxMTowOCBBTQ0KVG86IFNjaGFyZiwg TWljaGFlbDsgdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCkNjOiB0c3Z3Z0Bp ZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBDcm9z cy1hcmVhIGFsaWdubWVudCBvbiAiTDRTIGFuZCBSQUNLIg0KDQpNaWNoYWVsLA0KT24gMDkvMTEv MjAxOCAwNjoyMSwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOg0KSSBkb27igJl0IHNlZSB0aGUgZnVu ZGFtZW50YWwgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgbGluayB0ZWNobm9sb2d5IHRoYXQgZ3VhcmFu dGVlcyBpbi1vcmRlciBkZWxpdmVyeSB3aXRoaW4gYSBmbG93IChzYXkgYnkgZmxvdyBoYXNoaW5n LCBzZWUgRUNNUCkgdnMuIHNvbWUgbGluayBzY2hlbWUgdGhhdCBndWFyYW50ZWVzIGluLW9yZGVy IGRlbGl2ZXJ5LCBzYXksIG9ubHkgZm9yIHNvbWUgZnJhY3Rpb24gb2YgdGhlIHRyYWZmaWMgY2hh cmFjdGVyaXplZCBieSBzb21lIG90aGVyIG1lYW5zIChzYXksIG90aGVyIGhlYWRlciBiaXRzKS4N CltUaGUgIm90aGVyIG1lYW5zIiBhbmQgIm90aGVyIGJpdHMiIHdvcmRpbmcgaXMgcHJldHR5IGFt YmlndW91cyBoZXJlLiBJIHJlY2tvbiBJIGNhbiBndWVzcyB3aGF0IHlvdSBtZWFuIGJ1dCB0aGVu IEkgZG9uJ3Qga25vdyB3aHkgeW91J3JlIHNheWluZyB0aGlzLCAnY29zIEkgZG9uJ3QgdGhpbmsg SSd2ZSBkaXNhZ3JlZWQgd2l0aCB5b3Ugb24gdGhpcy4gU28gcGVyaGFwcyB5b3UgY291bGQgYmUg bW9yZSBzcGVjaWZpYyBhbmQgd2UgbWlnaHQgYmUgYWJsZSB0byBzZWUgd2h5IHlvdSd2ZSBicm91 Z2h0IHRoaXMgdXAuXQ0KDQpBbHNvIEkgd2Fzbid0IHJlYWxseSB0YWxraW5nIGFib3V0IGFsbCAi bGluayB0ZWNobm9sb2d5IHRoYXQgZ3VhcmFudGVlcyBpbi1vcmRlciBkZWxpdmVyeSB3aXRoaW4g YSBmbG93Ii4ge05vdGUgMX0gSSB3YXMgdGFsa2luZyBhYm91dCBsaW5rIHRlY2hub2xvZ3kgd2hl cmUgYWxsIGZsb3dzIGFyZSBibG9ja2VkIHdoaWxlIHdhaXRpbmcgdG8gZ2V0IHRoZSBhZ2dyZWdh dGUgYmFjayBpbiBvcmRlciB0aGF0IGl0IHdhcyBpbiB3aGVuIGl0IGFycml2ZWQuIEkgc3BlY2lm aWNhbGx5IHNhaWQ6DQoNCg0KDQoNCk5vdGUgdGhhdCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgZmxv d3Mgb3ZlciBvbmUgbGluay4gU28gJ2luLW9yZGVyIGRlbGl2ZXJ5JyBmb3IgYSBsaW5rIGRvZXMg bm90IG1lYW4gaW4gb3JkZXIgb2YgVENQIHNlcXVlbmNlIG51bWJlci4gSXQgbWVhbnMgJ2RlbGl2 ZXJlZCBpbiB0aGUgb3JkZXIgdGhhdCBwYWNrZXRzIGFycml2ZWQgYXQgdGhlIGxpbmsnICh0aGUg bGluayBpbmdyZXNzIGFkZHMgaXRzIG93biBzZXF1ZW5jZSBudW1iZXJzLCBhbmQgdGhlIGxpbmsg ZWdyZXNzIGJ1ZmZlcnMgdGhlbSB1bnRpbCBpdCBjYW4gc2VuZCBvdXQgaW4gdGhlIHNhbWUgb3Jk ZXIsIG9yIHVudGlsIGEgdGltZS1vdXQgb3IgbWF4IG5vLiBvZiBsaW5rIHJldHJhbnNtaXNzaW9u cykuDQpGb3IgZXhhbXBsZToNCg0KICAqICAgQSBwYWNrZXQgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBh ZnRlciBhbGxvd2luZyBmb3IgbGluay1sYXllciByZXRyYW5zbWlzc2lvbnMgaXMgY29tbW9uIGZv ciByYWRpbyBsaW5rIHRlY2hub2xvZ2llcyBzdWNoIGFzIExURSAoUERDUCBsYXllcikgYW5kIDgw Mi4xMSBXaUZpLg0KICAqICAgQSBwYWNrZXQgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBhZnRlciBtZXJn aW5nIG11bHRpcGxlIGJvbmRlZCBsaW5rIGNoYW5uZWxzIGlzIGNvbW1vbiBmb3Igb3RoZXIgYWNj ZXNzIGxpbmsgdGVjaG5vbG9naWVzIHN1Y2ggYXMgZG93bnN0cmVhbSBET0NTSVMgYm9uZGVkIGNo YW5uZWxzLg0KDQoNCg0KDQoNCg0KQ2xlYXJseSwgcmVvcmRlcmluZyBpcyBhIHByb2JsZW0gdGhh dCBuZWVkcyB0byBiZSBkaXNjdXNzZWQgaW4gdGhlIElFVEYgYXMgYSB3aG9sZS4gQW5kIHdlIGNv dWxkIGRpc2N1c3Mgd2hldGhlciBhIHJldmlzaW9uIG9mIFJGQyAzMzY2IGlzIG5lZWRlZC4NCk5v LiBUaGVyZSBpcyBubyBwcm9wb3NhbCB0byBhbHRlciBnZW5lcmFsIGd1aWRhbmNlIGZvciBhbGwg bGlua3MgbGlrZSBSRkMgMzM2Ni4gTm8tb25lIGlzIHNheWluZyB0aGlzLg0KDQpUaGVyZSBpcyBu b3QgZXZlbiBhIHByb3Bvc2FsIHRvIHJlcXVpcmUgb3IgZXZlbiByZWNvbW1lbmQgdGhhdCBMNFMt c3BlY2lmaWMgbGlua3MgZG8gYW55dGhpbmcuDQoNClRoZSBzcGVjaWZpYyBwcm9wb3NhbCBpcyB0 byByZXF1aXJlIEw0UyBzb3VyY2VzIHRvIHVzZSBhIFJBQ0stbGlrZSBzY2hlbWUsIGFzIGEgY29u ZGl0aW9uIGZvciBzZXR0aW5nIHRoZSBFQ1QoMSkgY29kZXBvaW50LiBTZWUgdGhlIGxhc3QgYnVs bGV0IGluIFMuNC4zIG9mIGRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNTxodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRv b2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNSUyM3Nl Y3Rpb24tNC4zJmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzU0N2U1MDNl MjE4NTQ5NDgzZjMwMDhkNjQ2NzQ5NWI5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN0MxJTdDMCU3QzYzNjc3Mzg2Mzg5NTUwNjUxMSZzZGF0YT1tJTJGbjZITlFuSlliVFBJbzBN UjhjVFhLZmNqMERYNTc5SEF5RDlMTWU0YVElM0QmcmVzZXJ2ZWQ9MD4uDQoNClRoaXMgc2F5cyBu b3RoaW5nIGFib3V0IHdoYXQgTDRTIGxpbmtzIE1VU1QsIFNIT1VMRCBvciBNQVkgZG8uIEl0IGp1 c3QgZ2l2ZXMgYW4gTDRTIGxpbmsgYW4gb3Bwb3J0dW5pdHkgbm90IHRvIGhhdmUgdG8gZG8gcmVz ZXF1ZW5jaW5nLg0KDQoNCg0KDQoNCg0KQnV0IEkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IHRoaXMg dG9waWMgaGFzIHRvIGJlIHRpZWQgaW50byBhbiBleHBlcmltZW50IHN1Y2ggYXMgTDRTLg0KSXQg aXMgYW4gb3Bwb3J0dW5pdHkgdGhhdCBjdXJyZW50bHkgb25seSBhcHBsaWVzIHRvIEw0Uy4NCg0K TDRTIGlzIG1lcmVseSBhbiBleGFtcGxlIG9mIGEgY2FzZSB3aGVyZSB3ZSBjYW4gbWFuZGF0ZSB0 aGF0IHRoZXJlIHdpbGwgYmUgbm8gbm9uLVJBQ0sgdHJhZmZpYyBpbiBhIGxpbmssIHdoaWNoIGNy ZWF0ZXMgYW4gb3Bwb3J0dW5pdHkgZm9yIHRob3NlIHdobyBhcmUgaW1wbGVtZW50aW5nIHRoZSBM NFMgRHVhbFEgQ291cGxlZCBBUU0gdG8gaWdub3JlIHRoZSBSRkMzMzY2IHJlc2VxdWVuY2luZyBh ZHZpY2UgZm9yIHRoZSBMNFMgcXVldWUgKGJ1dCB3ZSBhcmUgbm90IGNoYW5naW5nIHRoZSBhZHZp Y2UsIGJlY2F1c2UgTDRTIGlzIG9ubHkgYW4gZXhwZXJpbWVudCkuIFRoZSBwcml6ZSBpcyB0byBy ZW1vdmUgdGhlIGhlYWQtb2YtbGluZSBibG9ja2luZyBwcm9ibGVtIGZvciB0aGVpciB1c2Vycy4N Cg0KVGhpcyBpcyBub3QgTDRTLXNwZWNpZmljLCBhbHRobyB0aGVyZSBhcmUgbm8gb3RoZXIgZXhh bXBsZXMgYXQgdGhlIG1vbWVudCB3aGVyZSB0aGlzIG9wcG9ydHVuaXR5IGlzIHBvc3NpYmxlIChz byBpbiB0aGF0IHNlbnNlIGl0IGlzIGN1cnJlbnRseSBMNFMtc3BlY2lmaWMpLg0KDQoNClRoZSBt ZXNzYWdlIGhhcyB0byBiZSBoYW5kbGVkIHJlYWxseSBjYXJlZnVsbHksIGJlY2F1c2UgdGhlIG9w cG9ydHVuaXRpZXMgZm9yIG1pc3VuZGVyc3RhbmRpbmcgYXJlIGVub3Jtb3VzIChhcyBldmlkZW5j ZWQgYnkgdGhpcyB0aHJlYWQsIGFuZCB3ZSBoYXZlbid0IGV2ZW4gc3RhcnRlZCB0YWxraW5nIHRv IG5vbi10cmFuc3BvcnQgcGVvcGxlIHlldCkuDQoNClNvIEdvcnJ5IGFuZCBEYXZpZCBCIHdhbnQg bWUgdG8gZHJhZnQgYSBzaG9ydCBJLUQgdGhhdCB0aGV5IHdpbGwgd29yZC1zbWl0aCBhbmQgYXV0 aG9yIGFzIHRzdndnIGNoYWlycyB0byBtYWtlIHRoZSBzaXR1YXRpb24gY2xlYXIuDQoNCkkgaGF2 ZSBzYWlkIEkgZG9uJ3Qgd2FudCB0aGlzIGRpc2N1c3Npb24gdG8gYmUgb2ZmaWNpYWxseSByYWlz ZWQgb3V0c2lkZSB0aGUgdHJhbnNwb3J0IGFyZWEgdW50aWwgd2UgYXJlIHN1cmUgdGhhdCBhIHZh cmlhbnQgb2YgUkFDSyBpcyBldmVuIGZlYXNpYmxlIHdpdGhvdXQgYW55IHBhY2tldCBjb3VudGlu ZyBhdCBhbGwgKGkuZS4gd2l0aG91dCB0aGUgaW5pdGlhbCAzLUR1cEFDSyBydWxlIGluIGN1cnJl bnQgUkFDSykuIFNvIEknbGwgcHJpb3JpdGl6ZSB3b3JraW5nIHRoYXQgb3V0IGZvciB0aGUgbmV4 dCB3ZWVrIG9yIHNvLCByYXRoZXIgdGhhbiBkcmFmdGluZyBhbnl0aGluZy4NCg0KDQoNCkJvYg0K DQp7Tm90ZSAxfTogSSBoYWRuJ3QgY29uc2lkZXJlZCB0aGF0IHRoaXMgd291bGQgYWZmZWN0IHRl Y2hub2xvZ2llcyBsaWtlIEVDTVAgdGhhdCBtYWludGFpbiBvcmRlciB3aXRob3V0IGEgcmVzZXF1 ZW5jaW5nIGJ1ZmZlciBhbmQgd2l0aG91dCBpbnRyb2R1Y2luZyBIb0wgYmxvY2tpbmcuIEJ1dCBh Y3R1YWxseSwgdGhlIGNvbnNlcXVlbmNlIHRoZXJlIHdvdWxkIGJlIHRoYXQgTDRTIHRyYWZmaWMg Y291bGQgYmUgc3ByYXllZCBieSBFQ01QIHdpdGhvdXQgcGVyLWZsb3cgaGFzaGluZy4NCg0KDQoN Cg0KDQoNCk1pY2hhZWwNCg0KRnJvbTogQm9iIEJyaXNjb2UgW21haWx0bzppbkBib2JicmlzY29l Lm5ldF0NClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgOSwgMjAxOCA2OjQyIEFNDQpUbzogU2NoYXJm LCBNaWNoYWVsOyB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KQ2M6IHRzdndn QGlldGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHN2d2ddIENy b3NzLWFyZWEgYWxpZ25tZW50IG9uICJMNFMgYW5kIFJBQ0siDQoNCk1pY2hhZWwsDQoNClRoYXQg aXMgdGhlIHBvaW50IEkgdGhvdWdodCB5b3Ugd2VyZSBtYWtpbmcsIGFuZCBteSBwb2ludCAvaXMv IGFib3V0IHRoYXQuDQoNCklmIGFuIGFwcGxpY2F0aW9uIG5lZWRzIGFsbCB0aGUgcGFja2V0cyAo aS5lLiBhIHJlbGlhYmxlIHByb3RvY29sKSwgaXQncyBub3QgdXNlZnVsIHRvIHJlZHVjZSB0aGUg bGF0ZW5jeSBvZiBzb21lIHBhY2tldHMgYnV0IG5vdCBhbGwuIFRoYXQncyB3aGVyZSB0aGUgaW4t b3JkZXIgcmVxdWlyZW1lbnQgY29tZXMgZnJvbS4NCg0KSG93ZXZlciwgaWYgYSBzdHJlYW0tYmFz ZWQgdHJhbnNwb3J0IGlzIHVzZWQgKGkuZS4gVENQKSB0aGUgL2FwcGxpY2F0aW9uLyBzdGlsbCBn ZXRzIGluLW9yZGVyIGRlbGl2ZXJ5IGZyb20gVENQLiBJdCBqdXN0IGRvZXNuJ3QgaGF2ZSB0byBy ZXF1aXJlIGxpbmtzIHRvIHByb3ZpZGUgaW4gb3JkZXIgZGVsaXZlcnkgYXMgd2VsbC4NCg0KTm90 ZSB0aGF0IHRoZXJlIGNhbiBiZSBtdWx0aXBsZSBmbG93cyBvdmVyIG9uZSBsaW5rLiBTbyAnaW4t b3JkZXIgZGVsaXZlcnknIGZvciBhIGxpbmsgZG9lcyBub3QgbWVhbiBpbiBvcmRlciBvZiBUQ1Ag c2VxdWVuY2UgbnVtYmVyLiBJdCBtZWFucyAnZGVsaXZlcmVkIGluIHRoZSBvcmRlciB0aGF0IHBh Y2tldHMgYXJyaXZlZCBhdCB0aGUgbGluaycgKHRoZSBsaW5rIGluZ3Jlc3MgYWRkcyBpdHMgb3du IHNlcXVlbmNlIG51bWJlcnMsIGFuZCB0aGUgbGluayBlZ3Jlc3MgYnVmZmVycyB0aGVtIHVudGls IGl0IGNhbiBzZW5kIG91dCBpbiB0aGUgc2FtZSBvcmRlciwgb3IgdW50aWwgYSB0aW1lLW91dCBv ciBtYXggbm8uIG9mIGxpbmsgcmV0cmFuc21pc3Npb25zKS4NCg0KU28sIGlmIHRoZSBsaW5rIGxv c2VzIGEgcGFja2V0IGZyb20gZmxvdyBBICh0aGUgbGluayBpc24ndCBhd2FyZSBvZiBtaWNyb2Zs b3dzLCBJJ20ganVzdCBzYXlpbmcgdGhlIHBhY2tldCBoYXBwZW5zIHRvIGJlIGZyb20gZmxvdyBB KSwgbGluay1sYXllciBpbi1vcmRlciBkZWxpdmVyeSB3aWxsIGhvbGQgYmFjayBhbGwgcGFja2V0 cyBzZW50IGFmdGVyIHRoYXQgcGFja2V0IChmcm9tIGFsbCBmbG93cywgbm90IGp1c3QgZmxvdyBB KSB1bnRpbCB0aGUgbGluayByZXBhaXJzIHRoZSBnYXAgb3IgZ2l2ZXMgdXAuDQoNClNvIGhvcC1i eS1ob3AgaW4tb3JkZXIgZGVsaXZlcnkgZ2l2ZXMgZXZlcnkgZmxvdyB0aGUgc2FtZSBkZWxheSBh cyB0aGUgd29yc3QgZGVsYXllZCBmbG93Lg0KDQpPZiBjb3Vyc2UsIHNvbWVvbmUgYnVpbGRpbmcg YSBuZXR3b3JrIGZvciBERVRORVQgd291bGQgYXZvaWQgbGluayB0ZWNobm9sb2dpZXMgbGlrZSBX aUZpIG9yIExURSB0aGF0IGZyZXF1ZW50bHkgbG9zZSBhbmQgcmV0cmFuc21pdCBwYWNrZXRzLiBC dXQgd2hlcmV2ZXIgdGhlcmUgaXMgdmFyaWFibGUgZGVsYXkgaW4gYSBsaW5rLCBndWFyYW50ZWVk IGluLW9yZGVyIGRlbGl2ZXJ5IHBlci1ob3AgbWVhbnMgZXZlcnkgZmxvdyBpcyBndWFyYW50ZWVk IHRvIGFsd2F5cyBnZXQgdGhlIHdvcnN0IGRlbGF5IGZyb20gZXZlcnkgbGluaywgd2hpY2ggd291 bGQgaGF2ZSBiZWVuIGV4cGVyaWVuY2VkIGJ5IG9ubHkgb25lIGZsb3cgd2l0aG91dCBwZXItaG9w IGluLW9yZGVyIGRlbGl2ZXJ5Lg0KDQpBbmQgbWFueSBvZiB0aGUgYXBwbGljYXRpb25zIG9mIERF VE5FVCBpbnZvbHZlIGR1bWIgaW5kdXN0cmlhbCBtYWNoaW5lcnkgdGhhdCBqdXN0IGV4cGVjdHMg ZXZlcnl0aGluZyB0byBhcnJpdmUgaW4gb3JkZXIgYW5kIHRvIGEgY2xvY2tlZCBzY2hlZHVsZS4g QnV0IGl0J3MgYWx3YXlzIGFzIGVmZmVjdGl2ZSB0byBkZXBsb3kgYSByZXNlcXVlbmNpbmcgYnVm ZmVyIGFzIHRoZSBwZW51bHRpbWF0ZSBob3AsIHNjcmV3ZWQgb250byB0aGUgcmVjZWl2aW5nIG1h Y2hpbmUgaWYgbmVjZXNzYXJ5LCByYXRoZXIgdGhhbiByZXF1aXJlIHBlci1ob3AgcmVzZXF1ZW5j aW5nIGluIHRoZSBuZXR3b3JrLg0KDQpfX19fX19fX19fX19fX19fDQpTbywgd2h5IGRvIEludGVy bmV0IGxpbmtzIG9mdGVuIGVuc3VyZSBpbi1vcmRlciBkZWxpdmVyeSBldmVuIHRob3VnaCBUQ1Ag cHV0cyBldmVyeXRoaW5nIGluIG9yZGVyIGZvciB0aGUgYXBwbGljYXRpb24/DQoNClNob3J0IGFu c3dlcjogdGhlIDMgRHVwQUNLIHJ1bGUgKHdoaWNoIGlzIHRvIGRvIHdpdGggbG9zcy1yZWNvdmVy eSwgYSBkaWZmZXJlbnQgaXNzdWUgZnJvbSB0aGUgZGlzY3Vzc2lvbiBhYm92ZSkuDQoNCkxvbmcg YW5zd2VyOiBBcyBmbG93IHJhdGVzIGhhdmUgc2NhbGVkIHVwLCB0aGUgdHlwaWNhbCB0aW1lIGJl dHdlZW4gMyBwYWNrZXQgYXJyaXZhbHMgaGFzIGJlY29tZSBzbyBzbWFsbCB0aGF0IFRDUCdzIDMt RHVwQUNLIHJ1bGUgbWFrZXMgbGlua3MgaGF2ZSB0byBwcm92aWRlIGRlbGl2ZXJ5IHdpdGggb25s eSBhIHZlcnkgc21hbGwgcmUtb3JkZXJpbmcgZGVncmVlIC0gc28gc21hbGwgdGhhdCBpdCdzIGVh c2llciBmb3IgYSBsaW5rIHRvIGp1c3QgZGVsaXZlciBldmVyeXRoaW5nIGluIHRoZSBvcmRlciBp dCByZWNlaXZlZCBpdDsgbm90IGJlY2F1c2UgVENQIGRvZXNuJ3QgcHV0IHBhY2tldHMgYmFjayBp biBvcmRlciwgYnV0IGp1c3Qgc28gYXMgbm90IHRvIHRyaWdnZXIgVENQIGludG8gZ2VuZXJhdGlu ZyBzcHVyaW91cyByZXRyYW5zbWlzc2lvbnMuDQoNCg0KDQpCb2INCk9uIDA4LzExLzIwMTggMTY6 MzUsIFNjaGFyZiwgTWljaGFlbCB3cm90ZToNCklubGluZSBbbXNdDQoNCkZyb206IEJvYiBCcmlz Y29lIFttYWlsdG86aW5AYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIg OCwgMjAxOCAxMjo1NiBQTQ0KVG86IFNjaGFyZiwgTWljaGFlbDsgdGNwbUBpZXRmLm9yZzxtYWls dG86dGNwbUBpZXRmLm9yZz4NCkNjOiB0c3Z3Z0BpZXRmLm9yZzxtYWlsdG86dHN2d2dAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3RzdndnXSBDcm9zcy1hcmVhIGFsaWdubWVudCBvbiAiTDRTIGFu ZCBSQUNLIg0KDQpNaWNoYWVsLA0KDQpUaGlzIGlzIG1lcmVseSBhIHN5bXB0b20gb2YgYSBkaWZm ZXJlbmNlIGluIG9waW5pb24gb24gd2hlcmUgdGhlIHJlc2VxdWVuY2luZyBmdW5jdGlvbiBzaG91 bGQgYmUgbG9jYXRlZC4NCg0KICAqICAgTDRTIHRha2VzIHRoZSBlbmQtdG8tZW5kIGFwcHJvYWNo IHNheWluZyB0aGF0IGl0IGlzIHN1ZmZpY2llbnQgdG8gZG8gcmVzZXF1ZW5jaW5nIGluIG9uZSBw bGFjZSAodGhlIHJlY2VpdmluZyBob3N0KSBpZiBpdCBpcyBuZWVkZWQuIFRoZW4gYW55IHJlc2Vx dWVuY2luZyBkZWxheSBvbmx5IGFmZmVjdHMgdGhhdCBmbG93Lg0KICAqICAgVGhlIERFVE5FVCBh cHByb2FjaCBpcyBzYXlpbmcgdGhlIHJlc2VxdWVuY2luZyBtdXN0IGJlIGRvbmUgaG9wLWJ5LWhv cC4gVGhpcyBtZWFucyB0aGVyZSBhcHBlYXJzIHRvIGJlIG5vIHJlc2VxdWVuY2luZyBuZWVkZWQg b24gdGhlIHJlY2VpdmVyIChleGNlcHQgaWYgdGhlcmUncyByZS1vcmRlcmluZyBvbiB0aGUgZmlu YWwgaG9wKS4NCg0KDQogICogICBJbiBvcmRlciB0byBndWFyYW50ZWUgbm8gcmVzZXF1ZW5jaW5n IGluIHRoZSBuZXR3b3JrIChERVRORVQgYXBwcm9hY2gpLCBvbmx5IHRoZSB0aGUgd29yc3QgY2Fz ZSBsYXRlbmN5IGNhbiBiZSBndWFyYW50ZWVkLCBhbmQgZXZlcnkgcGFja2V0IGhhcyB0byBoYXZl IHRoYXQgc2FtZSB3b3JzdC1jYXNlIGxhdGVuY3kuDQogICogICBXaGVuIHlvdSBsZWF2ZSByZXNl cXVlbmNpbmcgdG8gdGhlIHJlY2VpdmVyIChlbmQtdG8tZW5kIGFwcHJvYWNoKSwgbW9zdCBvZiB0 aGUgcGFja2V0cyBhcnJpdmUgZWFybGllciB0aGFuIHRoZXkgd291bGQgd2l0aCBERVRORVQsIGJ1 dCBvdXQgb2Ygb3JkZXIgb25lcyBtaWdodCBub3QuIFRoZW4gdGhlIGFwcGxpY2F0aW9uIGNob29z ZXMgd2hldGhlciBpdCB3YW50cyB0byB3YWl0Lg0KW21zXSBNeSBwb2ludCBpcyBkaWZmZXJlbnQ6 IFRoZXJlIHNlZW0gdG8gYmUgb3RoZXIgd29ya2luZyBncm91cHMgaW4gdGhlIElFVEYgdGhhdCBk byB0YWxrIGFib3V0IOKAnGxvdyBsYXRlbmN54oCdIGFzIHdlbGwgYnV0IGFwcGFyZW50bHkgdGhl eSBhbHNvIGRvIG5lZWQgaW4tb3JkZXIgZGVsaXZlcnkgb2YgcGFja2V0cywgdG9vLiBTbyB0aGUg YXNzdW1wdGlvbiB0aGF0IGUuZy4gYSBsaW5rIGxheWVyIHRlY2hub2xvZ3kgY2FuIHNpbXBseSBk aXNhYmxlIGluLW9yZGVyIGRlbGl2ZXJ5IGZvciBhbGwg4oCcbG93IGxhdGVuY3nigJ0gYXBwbGlj YXRpb25zIHNlZW1zIG5vdCBjb3JyZWN0LiBUaGUgcmVhbGl0eSBtYXkgYmUgYSBiaXQgbW9yZSBj b21wbGV4Lg0KVGhlIDMgRHVwQUNLIHJ1bGUgaW4gVENQIGxlZCB0aGUgSW50ZXJuZXQgbm90IHRv IGZvbGxvdyB0aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUgb24gcmUtc2VxdWVuY2luZy4gTm93IHdl J3JlIHJlbW92aW5nIHRoZSAzIER1cEFDSyBydWxlLCB3ZSBjYW4gdGFrZSBhZHZhbnRhZ2Ugb2Yg dGhlIGUyZSBwcmluY2lwbGUuDQpbbXNdIEZvciBUQ1AsIHRocmVlIER1cEFDS1MgYXJlIGEgU0hP VUxEIGluIFJGQyA1NjgxIGFuZCBSRkMgNTY4MSBpcyBzdGFuZGFyZHMgdHJhY2suIFNvIHRoZSBi YXIgZm9yIOKAnHJlbW92aW5n4oCdIHRoYXQgcnVsZSBmb3IgVENQIGlzIG5vdCBsb3figKYNCltt c10gQWxzbywgdGhlIGVuZC10by1lbmQgcHJpbmNpcGxlIGNvbWVzIHdpdGggdHJhZGVvZmZzLiBG b3IgaW5zdGFuY2UsIHJlbHlpbmcgb24gdGhlIGVuZC10by1lbmQgcHJpbmNpcGxlIGZvciByZWNv dmVyeSBvZiBiaXQgZXJyb3JzIGlzIG5vdCBlZmZpY2llbnQuIEZvciBpbi1vcmRlciBkZWxpdmVy eSB0aGVyZSBhcmUgdHJhZGVvZmZzIGFzIHdlbGwsIHNlZSBlLmcuIFNlY3Rpb24gNCBpbiBkcmFm dC1pZXRmLXRjcG0tcmFjay0wNC4gVGhlcmUgbWF5IGJlIG5vIGZyZWUgbHVuY2guDQpPZiBjb3Vy c2UsIGFuIGFwcGxpY2F0aW9uIG1pZ2h0IGNob29zZSB0byB1c2UgVENQIGFuZCBMNFMsIHJhdGhl ciB0aGFuIFVEUCBhbmQgTDRTIChlLmcgUVVJQykuIFRoZW4gdGhlcmUgY291bGQgc3RpbGwgYmUg SG9MIGJsb2NraW5nIGluIHRoZSByZWNlaXZpbmcgVENQIHN0YWNrLiBCdXQgYXQgbGVhc3QgdGhl cmUncyBubyBIb0wgYmxvY2tpbmcgaW4gdGhlIG5ldHdvcmssIGFuZCB0aGUgYXBwIGNhbiBjaG9v c2UgYmV0d2VlbiBzdHJlYW0gKFRDUCkgb3IgZGF0YWdyYW0gKFVEUCkuDQpbbXNdIElmIExSTy9H Uk8gaW4gdGhlIHJlY2VpdmluZyBUQ1Agc3RhY2sgZ2V0cyBtZXNzZWQgdXAsIEkgZmFpbCB0byBz ZWUgdGhlIGJlbmVmaXQgKHNlZSBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNCkuDQpNaWNoYWVsDQoN Cg0KQm9iDQpPbiAwNi8xMS8yMDE4IDE5OjIwLCBTY2hhcmYsIE1pY2hhZWwgd3JvdGU6DQoNCkEg Y29tbWVudCBvbiB0aGUgVENQTSBwcmVzZW50YXRpb24gIkw0UyBhbmQgUkFDSyI6DQoNCg0KDQpB cyBmYXIgYXMgSSB1bmRlcnN0YW5kLCB0aGUgREVUTkVUIFdHIGluIFJURyBhcmVhIGhhcyBxdWl0 ZSBzb21lIHVzZXMgY2FzZXMgZm9yIHVsdHJhLWxvdyBsYXRlbmN5IHRyYW5zcG9ydCAtIGluIHBh cnRpY3VsYXIgYWxzbyB3aXRoIGJvdW5kZWQgaml0dGVyLiBBbmQgc29tZSBvZiB0aGVzZSBhcHBs aWNhdGlvbnMgKGUuZy4gdXNpbmcgVURQKSBhcHBhcmVudGx5IG1heSBub3QgYmUgYWJsZSB0byB0 b2xlcmF0ZSAqYW55KiBvdXQtb2Ytb3JkZXIgcGFja2V0IGRlbGl2ZXJ5Lg0KDQoNCg0KU28gcGVy aGFwcyBzb21lIGNyb3NzLWFyZWEgYWxpZ25tZW50IG9uIHVsdGEtbG93LWxhdGVuY3kgYXBwbGlj YXRpb24gcmVxdWlyZW1lbnRzIHdvdWxkIGJlIHVzZWZ1bD8NCg0KDQoNCk1pY2hhZWwNCg0KKHdo byByZWNlbnRseSBoYWQgdG8gcmV2aWV3IGRyYWZ0LWlldGYtZGV0bmV0LWFyY2hpdGVjdHVyZSkN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0LzxodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJG Ym9iYnJpc2NvZS5uZXQlMkYmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdD NTQ3ZTUwM2UyMTg1NDk0ODNmMzAwOGQ2NDY3NDk1YjklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NzczODYzODk1NTA2NTExJnNkYXRhPSUyQjRYb2xuS3lQ blk1Q3U4a3R1V1hpMlNKNXFib043QnI5JTJCNkRNckNIbm1jJTNEJnJlc2VydmVkPTA+DQoNCg0K DQoNCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0LzxodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGYm9iYnJpc2NvZS5uZXQl MkYmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDNTQ3ZTUwM2UyMTg1NDk0 ODNmMzAwOGQ2NDY3NDk1YjklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM2NzczODYzODk1NTE2NTE1JnNkYXRhPXhaUHZkcWtQV3QwQjFSYUdsbzB1NVB2cnlq YXptcWptOThwVjAwek9NV3clM0QmcmVzZXJ2ZWQ9MD4NCg0KDQoNCg0KDQoNCi0tDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2Jv YmJyaXNjb2UubmV0LzxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwJTNBJTJGJTJGYm9iYnJpc2NvZS5uZXQlMkYmZGF0YT0wMiU3QzAxJTdDcHJh dmIlNDBtaWNyb3NvZnQuY29tJTdDNTQ3ZTUwM2UyMTg1NDk0ODNmMzAwOGQ2NDY3NDk1YjklN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NzczODYzODk1NTI2 NTI0JnNkYXRhPVNwT0olMkZkdXdTRVJEbXNsRHl0d05MTklKNUw0T3h2cFR6bmNhQXgwb0ZyVSUz RCZyZXNlcnZlZD0wPg0KDQoNCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0LzxodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJG Ym9iYnJpc2NvZS5uZXQlMkYmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdD NTQ3ZTUwM2UyMTg1NDk0ODNmMzAwOGQ2NDY3NDk1YjklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NzczODYzODk1NTI2NTI0JnNkYXRhPVNwT0olMkZkdXdT RVJEbXNsRHl0d05MTklKNUw0T3h2cFR6bmNhQXgwb0ZyVSUzRCZyZXNlcnZlZD0wPg0KDQoNCg0K DQotLQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkJvYiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmJvYmJyaXNjb2UubmV0JTJGJmRhdGE9 MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzU0N2U1MDNlMjE4NTQ5NDgzZjMwMDhk NjQ2NzQ5NWI5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYz Njc3Mzg2Mzg5NTUzNjUzNyZzZGF0YT1seUJoY1hVNzRTVTU2czdxcjFPVVNmd2FJTDY4TGNiRjdX Snh0bXolMkJVYjAlM0QmcmVzZXJ2ZWQ9MD4NCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJy aXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0 Lw0K --_000_6EC6417807D9754DA64F3087E2E2E03E2D154250rznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFZvcmZvcm1hdGllcnRaY2hu DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNobiI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZvcm1hdGllcnQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNv bm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpwLkhU TUxQcmVmb3JtYXR0ZWQsIGxpLkhUTUxQcmVmb3JtYXR0ZWQsIGRpdi5IVE1MUHJlZm9ybWF0dGVk DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2Uy Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMjQN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTI1DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UyNg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMjcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTI4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNt IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBM aXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo1MTg4MTM2NDk7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMzg1MDAyMzI0O30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NjA1ODg5MzY5Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMTUwOTg4NTI0ODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjc4NDAzNjg5OTsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjAxOTA1NjIwMDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIEJvYiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGJlbGlldmUgbW9y ZSBlbXBpcmljYWwgZXZpZGVuY2UgaXMgbmVlZGVkIHRoYXQgdGhpcyBpcyBhIHByb2JsZW0gdGhh dCBuZWVkIHRvIGJlIGFkZHJlc3NlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Rm9yIGluc3RhbmNlLCBmb3Igd2hhdCBsaW5rIHRlY2hub2xvZ2llcyBkb2VzIHRoaXMgcHJv YmxlbSBleGlzdCBpbiByZWFsaXR5Pw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPllvdXIgZXhhbXBsZSB3aXRoIDk0dXMgc2VlbXMgdG8gaW1wbHkgYSBkYXRhIHJhdGUgb2Yg Mzg0IE1iaXQvcyBmb3IgYSBzaW5nbGUgVENQIHN0cmVhbS4gVGhhdCBpcyBwcm9iYWJseSBub3Qg d2hhdCB0aGUgdmFzdCBtYWpvcml0eSBvZiBUQ1AgY29ubmVjdGlvbnMNCiB1c2UuIFNvIGlzIHRo ZXJlIGFuIGVuZ2luZWVyaW5nIG5lZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFuZCBJIGRvbuKAmXQgZ2V0IHdoeSBrZWVwaW5nIHJlb3JkZXJpbmcgd2l0aGluIDk0dXMg aXMgc28gbXVjaCBvZiBhIGNoYWxsZW5nZSBmb3IgYSBsaW5rIGxheWVyIHRlY2hub2xvZ3kuIEkg d291bGQgcmVhbGx5IGxpa2UgdG8gbGVhcm4gdGVjaG5pY2FsDQogcmVhc29ucyB3aHkgKG1vc3Rs eSkgaW4tb3JkZXIgZGVsaXZlcnkgb24gbGlua3MgY2Fubm90IGJlIGltcGxlbWVudGVkIG5vdyBv ciBpbiBmdXR1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHdlIGlu ZGVlZCBydW4gaW50byBhIHJlYWwtd29ybGQgdGVjaG5pY2FsIHByb2JsZW0sIGl0IHdvdWxkbuKA mXQgaGVscCB0byBzb2x2ZSB0aGF0IHByb2JsZW0gZm9yIEw0UyDigJMgaXQgbXVzdCBiZSBzb2x2 ZWQgZm9yIGFsbCBJbnRlcm5ldCB0cmFmZmljDQogdGhlbiBhbmQgdGhlIG92ZXJhbGwgc29sdXRp b24gd291bGQgKHByb2JhYmx5KSBiZSBkaWZmZXJlbnQgdG8gdGhlIG9uZSB1c2VkIGluIGFuIGV4 cGVyaW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRvIG1lLCBvbmUg b2YgdGhlIGZ1bmRhbWVudGFsIHJlcXVpcmVtZW50cyBvbiBhIHBhY2tldCBuZXR3b3JrIGlzIHRo YXQgdGhlIG5ldHdvcmsgaW52ZXN0cyBzb21lIHJlYXNvbmFibGUgZWZmb3J0IHRvIGtlZXAgcGFj a2V0cyBpbiBvcmRlciBvbiBhDQogZ2l2ZW4gcGF0aCDigJMgYWxiZWl0IGEgcGFja2V0IG5ldHdv cmsgaXMgbm90IGFsd2F5cyBwZXJmZWN0IGFuZCB0aGF0IGhhcyBhbHdheXMgYmVlbiBPSy4gSSBh bSBub3QgY29udmluY2VkIHNvIGZhciB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIGdpdmUgdXAgdGhh dCBkZXNpZ24gZ3VpZGVsaW5lIGZvciBsaW5rIHRlY2hub2xvZ2llcyDigJMgbm90IGV2ZW4gZm9y IEw0Uy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWljaGFlbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IEJvYiBCcmlzY29lIFttYWls dG86aWV0ZkBib2JicmlzY29lLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTm92 ZW1iZXIgMTAsIDIwMTggMjozNSBBTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFt YW5pYW47IFNjaGFyZiwgTWljaGFlbDsgdGNwbUBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gdHN2 d2dAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0Y3BtXSBbdHN2d2ddIENyb3Nz LWFyZWEgYWxpZ25tZW50IG9uICZxdW90O0w0UyBhbmQgUkFDSyZxdW90OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5QcmF2ZWVuLCBNaWNoYWVsLDxicj4NCjxi cj4NClRoZSBpZGVhIGlzIG5vdCB0byByZWxheCBvcmRlcmluZyByZXF1aXJlbWVudCBvbiBsaW5r cy4gSXQncyB0byBtYWtlIHN1cmUgaXQgZG9lc24ndCBrZWVwIGdldHRpbmcgdGlnaHRlciBmb3Ig ZXZlci48YnI+DQo8YnI+DQpBcyBmbG93LXJhdGVzIGdldCBmYXN0ZXIsIHRoZSByZXF1aXJlbWVu dHMgb24gbGlua3MgZ2V0IHRpZ2h0ZXIgaWYgdGhlIHJlb3JkZXJpbmcgd2luZG93IGlzIGV4cHJl c3NlZCBpbiBwYWNrZXRzLjxicj4NCkZvciBpbnN0YW5jZSAoYXMgSSBzaG93ZWQgaW4gbXkgcHJl c2VudGF0aW9uKSwgd2l0aCBSVFQgPSAyNG1zIChzYXkpLCBpZiB0aGUgd2luZG93IGlzIDEyIHNl Z21lbnRzLCBhIHJlb3JkZXJpbmcgd2luZG93IG9mIDMgRHVwQUNLcyBlcXVhdGVzIHRvIDZtcy4g QnV0IGFzIGZsb3cgcmF0ZXMgaW5jcmVhc2UsIHNheSA4IHRpbWVzIGZhc3RlciAod2luZG93ID0g OTYpIHJlZHVjZXMgdGhlIHRpbWUgb3ZlciB3aGljaCBsaW5rcyBoYXZlIHRvIGtlZXANCiBwYWNr ZXRzIGluIG9yZGVyIHRvIDc1MM68cy4gQW5vdGhlciA4eCBmYXN0ZXIsIGFuZCBsaW5rcyBoYXZl IHRvIGtlZXAgb3JkZXIgd2l0aGluIDk0zrxzLiBBbmQgc28gb24uPGJyPg0KPGJyPg0KVGhpcyBj YW5ub3QgZ28gb24gaW5kZWZpbml0ZWx5LCBiZWNhdXNlIHRoZSBjb25zdHJhaW50cyBvbiBsaW5r LWxheWVyIHJldHJhbnNtaXNzaW9uIGFyZSBjb25zdGFudCBpbiB0aW1lIChsZW5ndGggb2YgbGlu ayAvIHNwZWVkIG9mIGxpZ2h0ICYjNDM7IHByb2Nlc3NpbmcgdGltZSkuIElmIHRoZSAzIER1cEFD SyBydWxlIGlzIG5vdCByZW1vdmVkLCBsaW5rIHRpbWluZ3Mgd2lsbCBiZSBjb250aW51YWxseSBz cXVlZXplZCwgc28gcmFkaW8gbGlua3Mgd2lsbA0KIGV2ZW50dWFsbHkgaGF2ZSB0byBnaXZlIHVw IEFSUSwgd2hpY2ggd2lsbCBiZSBhd2Z1bCBmb3IgcGVyZm9ybWFuY2UuPGJyPg0KPGJyPg0KSXQg d2lsbCB0YWtlIGRlY2FkZXMgYmVmb3JlIC9hbGwvIGxlZ2FjeSAobm9uLVJBQ0spIFRDUHMgaGF2 ZSBzdG9wcGVkIHVzaW5nIGFueSBwYXJ0aWN1bGFyIGxpbmsuIFNvIGxpbmtzIGluIGdlbmVyYWwg d2lsbCBzdGlsbCBoYXZlIHRvIGtlZXAgdGlnaHRlbmluZyB0aGVpciByZS1zZXF1ZW5jaW5nIHRp bWUgYmVjYXVzZSBvZiBsZWdhY3kgMyBEdXAtQUNLIGZsb3dzLiBCdXQgZXZlbnR1YWxseSB0aGUg My1EdXBBQ0sgZmxvd3MgdGhhdCByZW1haW4NCiB3aWxsIHRlbmQgdG8gYmUgdGhvc2Ugb24gdW5t YWludGFpbmVkIG1hY2hpbmVzIHRoYXQgd2lsbCBub3QgYmUgdGFraW5nIGFkdmFudGFnZSBvZiBo aWdoZXIgc3BlZWRzLiBUaGVuLCBhc3N1bWluZyB0aGUgUkFDSyBleHBlcmltZW50IHJlbWFpbnMg c3VjY2Vzc2Z1bCBvdmVyIHRoZXNlIGRlY2FkZXMsIGxpbmtzIHdpbGwgYmUgYWJsZSB0byBzdG9w IHRpZ2h0ZW5pbmcgdGhlaXIgcmVvcmRlcmluZyBkZWdyZWUuPGJyPg0KPGJyPg0KPGJyPg0KVGhl IGlkZWEgaXMgdGhhdCwgZm9yIHRoZSBMNFMgZXhwZXJpbWVudCwgd2UgY2FuIHJlbW92ZSB0aGUg MyBEdXBBQ0sgcnVsZSBlbnRpcmVseSBmcm9tIHRoZSBzdGFydCwgYW5kIHNvbGVseSBleHByZXNz IHJlb3JkZXJpbmcgaW4gdW5pdHMgb2YgdGltZS4gVGhlbiwgTDRTIHRyYW5zcG9ydHMgd2lsbCBl dm9sdmUsIHByZXN1bWFibHkgdXNpbmcgc2ltaWxhciBSQUNLLWxpa2UgcmVvcmRlcmluZyBsb2dp YyB0byBub24tTDRTIHRyYW5zcG9ydHMuIEFuZA0KIHdlIHNoYWxsIHNlZSB3aGVyZSB0aGUgbWlu aW11bSByZW9yZGVyaW5nIHdpbmRvdyBlbmRzIHVwIChpbiB0aW1lIHVuaXRzKSwgYW5kIGhvcGVm dWxseSBjb252ZXJnZSBvbiBhIHZhbHVlIHdlIGNhbiBzdGFuZGFyZGl6ZSAtIGJvdGggaW4gVENQ IGFuZCBpbiBvdGhlciB0cmFuc3BvcnRzLg0KPGJyPg0KPGJyPg0KTm8gTDRTIGxpbmsgd291bGQg cmVsYXggaXRzIG9yZGVyaW5nIHJlcXVpcmVtZW50IGlmIGl0IGxlZCB0byB3b3JzZSBUQ1AgcGVy Zm9ybWFuY2UuIFNvIGxheWVyIDQgd2lsbCBiZSBpbiBjb250cm9sIG9mIHRoaXMgcHJvY2Vzcy4g Tm9uZXRoZWxlc3MsIGl0IGlzIGltcG9ydGFudCB0byBzdG9wIG1lYXN1cmluZyByZW9yZGVyaW5n IGluIHBhY2tldHMuIEJ1dCBob3BlZnVsbHksIGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBMNFMgZXhw ZXJpbWVudCwgbG9naWNhbA0KIGxpbmtzIHNvbGVseSBiZWFyaW5nIEw0UyB0cmFmZmljIHdpbGwg bm90IG5lZWQgdG8gY29udGludWFsbHkgdGlnaHRlbiB0aGVpciBvcmRlcmluZyByZXF1aXJlbWVu dC48YnI+DQo8YnI+DQpJZiBhbiBPUyBzdXBwb3J0cyBSQUNLLCB3aGljaCB5b3VycyBkb2VzLCB0 aGVuIGJ1ZmZlcmluZyBvbiB0aGUgcmVjZWl2ZXIgd2lsbCByZW1haW4gY29uc3RhbnQgaW4gdGlt ZSwgd2hpY2ggd2lsbCBtZWFuIHRoZSBtZW1vcnkgcmVxdWlyZW1lbnQgd2lsbCBncm93IGFzIGZs b3cgcmF0ZXMgc2NhbGUgdXAuDQo8YnI+DQo8YnI+DQpZb3UgKFByYXZlZW4pIHN1cHBvcnRlZCBh bmQgaW1wbGVtZW50ZWQgUkFDSyBiZWZvcmUgSSdkIGV2ZW4gdGhvdWdodCBhYm91dCBhbGwgdGhp cy4gSSdtIGFsc28gbm93IGEgY29udmVydC4gSSdtIHJlY29nbml6aW5nIGFuZCBhcnRpY3VsYXRp bmcgaXRzIHdpZGVyIGFkdmFudGFnZXMuPGJyPg0KPGJyPg0KPGJyPg0KQm9iPGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDkvMTEvMjAx OCAxOToxMCwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOndpbmRvd3RleHQiPiZndDsmZ3Q7PC9zcGFuPiBUaGVyZWZvcmUgdGhleSBjYW4gZXN0 aW1hdGUgdGhlIG1heCByZW9yZGVyaW5nIHRoZXkgYWxsb3cgdGhlaXIgbGlua3MgdG8gaW50cm9k dWNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTU8gTDIgc2hvdWxkbuKA mXQgPGk+aW50cm9kdWNlPC9pPiBtb3JlIHJlb3JkZXJpbmcganVzdCBiZWNhdXNlIEw0DQo8aT5j b25nZXN0aW9uIGNvbnRyb2w8L2k+IGlzIG1vcmUgcmVzaWxpZW50IHRvIGl0LiBUaGVyZSBpcyBv dGhlciBwZXJmb3JtYW5jZSBpbXBhY3QgZHVlIHRvIHJlb3JkZXJpbmc6IExSTyAvIEdSTyAvIFJT QyBvcHBvcnR1bml0eSB3aWxsIGJlIHJlZHVjZWQsIG1vcmUgbWVtb3J5IGFuZCBDUFUgY29zdCB0 byBkbyByZWFzc2VtYmx5IGF0IEw0ICh0aGlzIGlzIGFuIGFjdGl2ZSBhcmVhIGZvciByZW1vdGUg YXR0YWNrcykgZXRjLiBJTU8gTDQgZ3VpZGFuY2UNCiBzaG91bGQgcmVtYWluIHRoYXQgbGluayB2 ZW5kb3JzIG11c3QgYXZvaWQgcmVvcmRlcmluZyBhcyBtdWNoIGFzIHBvc3NpYmxlIGFuZCBub3Qg YnVpbGQgc29sdXRpb25zIHRoYXQgY2F1c2UgZnJlcXVlbnQgb3IgY29uc2lzdGVudCByZW9yZGVy aW5nLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQi PiB0Y3BtDQo8YSBocmVmPSJtYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnIj4mbHQ7dGNwbS1i b3VuY2VzQGlldGYub3JnJmd0OzwvYT4gPGI+T24gQmVoYWxmIE9mDQo8L2I+Qm9iIEJyaXNjb2U8 YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IDEwOjUyIEFNPGJyPg0K PGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWwgPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuU2NoYXJm QGhzLWVzc2xpbmdlbi5kZSI+Jmx0O01pY2hhZWwuU2NoYXJmQGhzLWVzc2xpbmdlbi5kZSZndDs8 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHN2d2dAaWV0Zi5vcmciPnRzdndnQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RjcG1dIFt0c3Z3Z10gQ3Jvc3MtYXJl YSBhbGlnbm1lbnQgb24gJnF1b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5NaWNoYWVsLDxicj4NCjxicj4NClRoZSBpZGVhIGlzIHRoYXQgKGFzIG5vdyBpbiB0aGUgUkFD SyBkcmFmdCBzaW5jZSBkaXNjdXNzaW9uIG9uIHRoZSB0Y3BtIGxpc3QgZWFybGllciB0aGlzIHll YXIgdW5kZXIgYSBzdWJqZWN0IHNvbWV0aGluZyBsaWtlIHZpY2lvdXMgY2lyY2xlIG9yIHZpcnR1 b3VzIGNpcmNsZSkgdGhlcmUgd2lsbCBiZSBhIGxpbWl0IG9uIHRoZSBpbml0aWFsIFJBQ0sgcmVv cmRlcmluZyB3aW5kb3cgZXhwcmVzc2VkIGluIGZyYWN0aW9uYWwgUlRUIHVuaXRzLjxicj4NCjxi cj4NCkxpbmsgdmVuZG9ycyBrbm93IHRoZSBtaW4gZTJlIFJUVCBvZiB0aGUgcGF0aHMgdGhhdCB0 aGVpciBsaW5rcyBhcmUgdXN1YWxseSBkZXBsb3llZCBvdmVyLiBUaGVyZWZvcmUgdGhleSBjYW4g ZXN0aW1hdGUgdGhlIG1heCByZW9yZGVyaW5nIHRoZXkgYWxsb3cgdGhlaXIgbGlua3MgdG8gaW50 cm9kdWNlLjxicj4NCjxicj4NCkkgZG9uJ3QgZXhwZWN0IHRoaXMgbGltaXQgdG8gYmUgc2V0IGlu IHN0b25lIHdoaWxlIGJvdGggUkFDSyBhbmQgTDRTIGFyZSBleHBlcmltZW50YWwuIEJ1dCBhcyBi b3RoIHRoZXNlIGV4cGVyaW1lbnRzIHByb2dyZXNzLCBJIHRoaW5rIHRoZSBpbmR1c3RyeSB3aWxs IGdldCBhIGJldHRlciBpZGVhIG9mIHdoZXJlIHRoZSBsaW1pdCBzaG91bGQgbGllLjxicj4NCjxi cj4NCkl0IHdhcyB0aGUgcmVhbGl6YXRpb24gdGhhdCwgaWYgVENQIGFkYXB0ZWQgaXRzIHJlb3Jk ZXJpbmcgd2luZG93IHRvIHRoZSBtZWFzdXJlZCByZW9yZGVyaW5nIGRlZ3JlZSB3aXRob3V0IGJv dW5kLCB0aGUgTDIgd29ybGQgd291bGQgY29udGludWFsbHkgaW5jcmVhc2UgdGhlIHJlb3JkZXJp bmcgZGVncmVlIG9mIHRoZWlyIGxpbmtzICh0aGUgdmljaW91cyBjaXJjbGUpLjxicj4NCjxicj4N CklmIHRoZXJlIGlzIGFueSBhc3BlY3Qgb2YgdGhpcyBsaW1pdCBleHByZXNzZWQgaW4gdW5pdHMg b2YgcGFja2V0cywgdGhlIGxpbWl0IHdpbGwgZGVjcmVhc2UgaW4gdGltZSBhcyBmbG93IHJhdGVz IGluY3JlYXNlLCBhbmQgdGhlcmVmb3JlIG5vdCBzZXJ2ZSB0byBnaXZlIHRoZSBMMiB3b3JsZCBh bnkgY2xlYXIgZ3VpZGFuY2UgLSBubyBkZSBmYWN0byBsaW1pdCBhZ3JlZWQgYmV0d2VlbiB0aGUg TDQgd29ybGQgYW5kIHRoZSBMMiB3b3JsZC4NCjxicj4NCjxicj4NCklmIHdlIGtlZXAgdGhlIGxp bWl0IGluIHVuaXRzIG9mIFJUVCwgaG9wZWZ1bGx5IHRoZW4gd2UgaGF2ZSBhIHZpcnR1b3VzIGNp cmNsZSwgbm90IGEgdmljaW91cyBjaXJjbGUuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQm9iPGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gMDkvMTEvMjAxOCAxODoyOCwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIG1heSBtaXNzIHNvbWV0aGluZywgYnV0IEkgcmVhZCB0 aGUgb3V0Y29tZSBvZiB0aGUgYXBwZW5kaXggYXMgYSByZXF1aXJlbWVudCDigJxtdXN0IGJlIG1v cmUgcm9idXN0IHRvIHJlb3JkZXJpbmfigJ0uIEFzIGZhciBhcyBJIHVuZGVyc3RhbmQsIHRoYXQg Y2FuIGJlIGltcGxlbWVudGVkDQogaW4gZGlmZmVyZW50IHdheXMuIDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIEkg bWF5IGJlIHdyb25nLCBidXQgdGhvc2UgbGluayB0ZWNobm9sb2dpZXMgY291bGQgYmUgd2VsbCBp bXBsZW1lbnRlZCBpbiBhIHJvdXRlciBhbmQgdGhlbiBvbmUgbmVlZHMgdG8gYW5hbHl6ZSBob3cg dGhhdCB3aG9sZSBhcmNoaXRlY3R1cmUgZml0cyBpbnRvIHRoZQ0KIHNjaGVkdWxlciwgcXVldWUs IHBvbGljZXIsIGFuZCBsaW5lIGNhcmQgaGFyZHdhcmUgZGVzaWduIG9mIGEgcm91dGVyLiBCdXQg dGhhdCBpcyBzb21ldGhpbmcgcm91dGluZyBwZW9wbGUga25vdyBiZXR0ZXIgdGhhbiBtZS4gTXkg cG9pbnQgaXMganVzdCB0byBnZXQgdGhlIGV4cGVydHMgaW50byB0aGUgbG9vcCBlYXJseS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPk1pY2hhZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOndpbmRvd3RleHQiPiBCb2IgQnJpc2NvZSBbPGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJp c2NvZS5uZXQiPm1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIE5vdmVtYmVyIDksIDIwMTggNzowNCBQTTxicj4NCjxiPlRvOjwvYj4gU2No YXJmLCBNaWNoYWVsOyA8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9y ZzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+dHN2 d2dAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHN2d2ddIENyb3NzLWFy ZWEgYWxpZ25tZW50IG9uICZxdW90O0w0UyBhbmQgUkFDSyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+TWljaGFlbCw8YnI+DQo8YnI+DQpQbGVhc2UgYWRkcmVzcyB0aGUgc2NhbGluZyByYXRpb25h bGUgaW4gdGhlIGFwcGVuZGl4IGZvciB3aHkgaXQgZG9lcyBtYXR0ZXIgaG93IGEgc2VuZGVyIHJl YWxpemVzIHRoaXMgaW50ZXJuYWxseS48YnI+DQo8YnI+DQpUaGUgbGlzdCBvZiBhY2Nlc3MgbGlu a3MgdHlwZXMgSSBtZW50aW9uZWQgYXJlIHJhcmVseSBjb25uZWN0ZWQgZGlyZWN0bHkgdG8gcm91 dGVycy4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCkJvYjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA5LzExLzIwMTggMTc6NDQsIFNjaGFyZiwgTWljaGFl bCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWxsIG5vdCBjb21t ZW50IG9uIGxpbmsgdGVjaG5vbG9neSBpbXBsZW1lbnRhdGlvbiwgc2NoZWR1bGVyIGFuZCBxdWV1 ZSBkZXNpZ24gYXNzdW1wdGlvbnMgaW4gQXBwZW5kaXggQS4xLjcgb2YgZHJhZnQtaWV0Zi10c3Z3 Zy1lY24tbDRzLWlkLTA1LiBQZW9wbGUgZS5nLg0KIGluIFJURyBhcmVhIG1heSBiZSBtb3JlIGZh bWlsaWFyIHdpdGggdGhlIGltcGxpY2F0aW9ucyBvZiBpbnRlcm5hbCBkZXNpZ25zIGUuZy4gaW5z aWRlIGEgcm91dGVyLiBJTUhPIHRoZSBiZXN0IHdheSB0byBnZXQgcm91dGluZyBleHBlcnRzIGlu dG8gdGhlIGxvb3AgYmVmb3JlIGZ1cnRoZXIgZGlzY3Vzc2luZyB3aGF0IGlzIGN1cnJlbnRseSBs aXN0ZWQgaW4gQXBwZW5kaXggQS4xLjcuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaHVzLCBJIGxpbWl0IG15IHJlc3Bv bnNlIHRvIHRoZSBhY3R1YWwgd29yZGluZyBpbiB0aGUgbWFpbiBwYXJ0IG9mIGRyYWZ0LWlldGYt dHN2d2ctZWNuLWw0cy1pZC0wNTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyBvJm5ic3A7IEEgc2NhbGFibGUgY29uZ2VzdGlvbiBjb250cm9sIE1V U1QgZGV0ZWN0IGxvc3MgYnkgY291bnRpbmcgaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHVuaXRzIG9mIHRpbWUsIHdoaWNoIGlzIHNjYWxhYmxlLCBhbmQgTVVTVCBOT1QgY291bnQgaW4g dW5pdHMgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBhY2tldHMgKGFzIGluIHRoZSAz IER1cEFDSyBydWxlIG9mIHRyYWRpdGlvbmFsIFRDUCksIHdoaWNoIGlzIG5vdDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgc2NhbGFibGUgKHNlZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0Ij48YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRy YWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNSUyM2FwcGVuZGl4LUEuMS43JmFtcDtkYXRhPTAy JTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0M1NDdlNTAzZTIxODU0OTQ4M2YzMDA4ZDY0 Njc0OTViOSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3 NzM4NjM4OTU0OTY0OTgmYW1wO3NkYXRhPSUyQmV6OU9DWmkxbTV3eDdUR0hrdmZHOVFzSmZKMFZ4 aHNYeW5xV1cyalhHNCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFwcGVuZGl4DQogQS4x Ljc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+IGZvciByYXRpb25hbGUpLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ QXMgaW5kaXZpZHVhbCBjb250cmlidXRvciwgSSBkaXNhZ3JlZSB3aXRoIHRoaXMgcmVxdWlyZW1l bnQuIEkgd291bGQgcHJvYmFibHkgYmUgT0sgd2l0aCBhIHdvcmRpbmcgdGhhdCBhIFRDUCBzZW5k ZXIgbXVzdCBiZSBhYmxlIHRvIHRvbGVyYXRlIHJlb3JkZXJpbmcgYmV5b25kDQogMyBEdXBsaWNh dGUgQUNLcy4gSSBiZWxpZXZlIGl0IGRvZXMgbm90IG1hdHRlciBob3cgYSBzZW5kZXIgcmVhbGl6 ZXMgdGhpcyBpbnRlcm5hbGx5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIGlmIHRoYXQgcmVxdWlyZW1lbnQgaXMg bm90IGp1c3QgcmVtb3ZlZCwgSSBiZWxpZXZlIHRoZSB3b3JkaW5nIOKAnHRyYWRpdGlvbmFsIFRD UOKAnSBoYXMgdG8gYmUgcmVwbGFjZWQgYnkg4oCcc3RhbmRhcmQgVENQ4oCdLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ QlRXLCBhbHNvLCBpbiB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgdGhlcmUgaGFzIHRvIGJlIGEg Y2xlYXIgZGlzdGluY3Rpb24gYmV0d2VlbiBleHBlcmltZW50cyBhbmQgc3RhbmRhcmRzLiBIaXN0 b3J5IHRlbGxzIHVzIHRoYXQgc29tZSBleHBlcmltZW50cyBjYW4gZXZvbHZlDQogaW50byBzdGFu ZGFyZHMgdHJhY2sgc3BlY2lmaWNhdGlvbnMsIHdoaWxlIG90aGVyIGV4cGVyaW1lbnRzIG1heSBm YWlsLiBBbmQgdGhlcmUgaXMgbm8gd2F5IG9mIGtub3dpbmcgdGhhdCBpbiBhZHZhbmNlLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+TWljaGFlbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gQm9iIEJyaXNjb2UgWzxhIGhyZWY9 Im1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0Ij5tYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldDwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IDExOjA4IEFN PGJyPg0KPGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWw7IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGll dGYub3JnIj50Y3BtQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRv OnRzdndnQGlldGYub3JnIj50c3Z3Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFt0c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gJnF1b3Q7TDRTIGFuZCBSQUNLJnF1 b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5NaWNoYWVsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDA5LzExLzIwMTggMDY6MjEsIFNjaGFyZiwgTWljaGFlbCB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHNlZSB0aGUg ZnVuZGFtZW50YWwgZGlmZmVyZW5jZSBiZXR3ZWVuIGEgbGluayB0ZWNobm9sb2d5IHRoYXQgZ3Vh cmFudGVlcyBpbi1vcmRlciBkZWxpdmVyeSB3aXRoaW4gYSBmbG93IChzYXkgYnkgZmxvdyBoYXNo aW5nLCBzZWUgRUNNUCkgdnMuIHNvbWUgbGluaw0KIHNjaGVtZSB0aGF0IGd1YXJhbnRlZXMgaW4t b3JkZXIgZGVsaXZlcnksIHNheSwgb25seSBmb3Igc29tZSBmcmFjdGlvbiBvZiB0aGUgdHJhZmZp YyBjaGFyYWN0ZXJpemVkIGJ5IHNvbWUgb3RoZXIgbWVhbnMgKHNheSwgb3RoZXIgaGVhZGVyIGJp dHMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPltUaGUgJnF1b3Q7b3RoZXIgbWVhbnMmcXVvdDsgYW5kICZxdW90O290aGVyIGJpdHMm cXVvdDsgd29yZGluZyBpcyBwcmV0dHkgYW1iaWd1b3VzIGhlcmUuIEkgcmVja29uIEkgY2FuIGd1 ZXNzIHdoYXQgeW91IG1lYW4gYnV0IHRoZW4gSSBkb24ndCBrbm93IHdoeSB5b3UncmUgc2F5aW5n IHRoaXMsICdjb3MgSSBkb24ndCB0aGluayBJJ3ZlIGRpc2FncmVlZCB3aXRoIHlvdSBvbiB0aGlz LiBTbyBwZXJoYXBzIHlvdSBjb3VsZCBiZSBtb3JlIHNwZWNpZmljDQogYW5kIHdlIG1pZ2h0IGJl IGFibGUgdG8gc2VlIHdoeSB5b3UndmUgYnJvdWdodCB0aGlzIHVwLl08YnI+DQo8YnI+DQpBbHNv IEkgd2Fzbid0IHJlYWxseSB0YWxraW5nIGFib3V0IGFsbCAmcXVvdDs8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+bGluayB0ZWNobm9sb2d5IHRoYXQgZ3VhcmFudGVl cyBpbi1vcmRlciBkZWxpdmVyeSB3aXRoaW4gYSBmbG93PC9zcGFuPiZxdW90Oy4ge05vdGUgMX0g SSB3YXMgdGFsa2luZyBhYm91dCBsaW5rIHRlY2hub2xvZ3kgd2hlcmUgYWxsIGZsb3dzIGFyZQ0K IGJsb2NrZWQgd2hpbGUgd2FpdGluZyB0byBnZXQgdGhlIGFnZ3JlZ2F0ZSBiYWNrIGluIG9yZGVy IHRoYXQgaXQgd2FzIGluIHdoZW4gaXQgYXJyaXZlZC4gSSBzcGVjaWZpY2FsbHkgc2FpZDo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk5vdGUgdGhhdCB0aGVyZSBjYW4gYmUgbXVsdGlwbGUgZmxvd3Mgb3ZlciBvbmUgbGlu ay4gU28gJ2luLW9yZGVyIGRlbGl2ZXJ5JyBmb3IgYSBsaW5rIGRvZXMgbm90IG1lYW4gaW4gb3Jk ZXIgb2YgVENQIHNlcXVlbmNlIG51bWJlci4gSXQgbWVhbnMgJ2RlbGl2ZXJlZCBpbiB0aGUgb3Jk ZXIgdGhhdCBwYWNrZXRzIGFycml2ZWQgYXQgdGhlIGxpbmsnICh0aGUgbGluayBpbmdyZXNzIGFk ZHMgaXRzIG93biBzZXF1ZW5jZQ0KIG51bWJlcnMsIGFuZCB0aGUgbGluayBlZ3Jlc3MgYnVmZmVy cyB0aGVtIHVudGlsIGl0IGNhbiBzZW5kIG91dCBpbiB0aGUgc2FtZSBvcmRlciwgb3IgdW50aWwg YSB0aW1lLW91dCBvciBtYXggbm8uIG9mIGxpbmsgcmV0cmFuc21pc3Npb25zKS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlOjxvOnA+PC9vOnA+PC9wPg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZl bDEgbGZvMSI+DQpBIHBhY2tldCByZXNlcXVlbmNpbmcgYnVmZmVyIGFmdGVyIGFsbG93aW5nIGZv ciBsaW5rLWxheWVyIHJldHJhbnNtaXNzaW9ucyBpcyBjb21tb24gZm9yIHJhZGlvIGxpbmsgdGVj aG5vbG9naWVzIHN1Y2ggYXMgTFRFIChQRENQIGxheWVyKSBhbmQgODAyLjExIFdpRmkuDQo8bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZv MSI+DQpBIHBhY2tldCByZXNlcXVlbmNpbmcgYnVmZmVyIGFmdGVyIG1lcmdpbmcgbXVsdGlwbGUg Ym9uZGVkIGxpbmsgY2hhbm5lbHMgaXMgY29tbW9uIGZvciBvdGhlciBhY2Nlc3MgbGluayB0ZWNo bm9sb2dpZXMgc3VjaCBhcyBkb3duc3RyZWFtIERPQ1NJUyBib25kZWQgY2hhbm5lbHMuDQo8bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5DbGVhcmx5LCByZW9yZGVyaW5nIGlzIGEgcHJvYmxlbSB0aGF0IG5l ZWRzIHRvIGJlIGRpc2N1c3NlZCBpbiB0aGUgSUVURiBhcyBhIHdob2xlLiBBbmQgd2UgY291bGQg ZGlzY3VzcyB3aGV0aGVyIGEgcmV2aXNpb24gb2YgUkZDIDMzNjYgaXMgbmVlZGVkLg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8uIFRoZXJlIGlzIG5vIHBy b3Bvc2FsIHRvIGFsdGVyIGdlbmVyYWwgZ3VpZGFuY2UgZm9yIGFsbCBsaW5rcyBsaWtlIFJGQyAz MzY2LiBOby1vbmUgaXMgc2F5aW5nIHRoaXMuPGJyPg0KPGJyPg0KVGhlcmUgaXMgbm90IGV2ZW4g YSBwcm9wb3NhbCB0byByZXF1aXJlIG9yIGV2ZW4gcmVjb21tZW5kIHRoYXQgTDRTLXNwZWNpZmlj IGxpbmtzIGRvIGFueXRoaW5nLg0KPGJyPg0KPGJyPg0KVGhlIHNwZWNpZmljIHByb3Bvc2FsIGlz IHRvIHJlcXVpcmUgTDRTIDxpPnNvdXJjZXM8L2k+IHRvIHVzZSBhIFJBQ0stbGlrZSBzY2hlbWUs IGFzIGEgY29uZGl0aW9uIGZvciBzZXR0aW5nIHRoZSBFQ1QoMSkgY29kZXBvaW50LiBTZWUgdGhl IGxhc3QgYnVsbGV0IGluDQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUy RmRyYWZ0LWlldGYtdHN2d2ctZWNuLWw0cy1pZC0wNSUyM3NlY3Rpb24tNC4zJmFtcDtkYXRhPTAy JTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0M1NDdlNTAzZTIxODU0OTQ4M2YzMDA4ZDY0 Njc0OTViOSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3 NzM4NjM4OTU1MDY1MTEmYW1wO3NkYXRhPW0lMkZuNkhOUW5KWWJUUElvME1SOGNUWEtmY2owRFg1 NzlIQXlEOUxNZTRhUSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+DQpTLjQuMyBvZiBkcmFmdC1pZXRmLXRz dndnLWVjbi1sNHMtaWQtMDU8L2E+LiA8YnI+DQo8YnI+DQpUaGlzIHNheXMgbm90aGluZyBhYm91 dCB3aGF0IEw0UyBsaW5rcyBNVVNULCBTSE9VTEQgb3IgTUFZIGRvLiBJdCBqdXN0IGdpdmVzIGFu IEw0UyBsaW5rIGFuIG9wcG9ydHVuaXR5IG5vdCB0byBoYXZlIHRvIGRvIHJlc2VxdWVuY2luZy48 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnV0IEkgYW0gbm90IGNvbnZp bmNlZCB0aGF0IHRoaXMgdG9waWMgaGFzIHRvIGJlIHRpZWQgaW50byBhbiBleHBlcmltZW50IHN1 Y2ggYXMgTDRTLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 IGlzIGFuIG9wcG9ydHVuaXR5IHRoYXQgY3VycmVudGx5IG9ubHkgYXBwbGllcyB0byBMNFMuIDxi cj4NCjxicj4NCkw0UyBpcyBtZXJlbHkgYW4gZXhhbXBsZSBvZiBhIGNhc2Ugd2hlcmUgd2UgY2Fu IG1hbmRhdGUgdGhhdCB0aGVyZSB3aWxsIGJlIG5vIG5vbi1SQUNLIHRyYWZmaWMgaW4gYSBsaW5r LCB3aGljaCBjcmVhdGVzIGFuIG9wcG9ydHVuaXR5IGZvciB0aG9zZSB3aG8gYXJlIGltcGxlbWVu dGluZyB0aGUgTDRTIER1YWxRIENvdXBsZWQgQVFNIHRvIGlnbm9yZSB0aGUgUkZDMzM2NiByZXNl cXVlbmNpbmcgYWR2aWNlIGZvciB0aGUgTDRTIHF1ZXVlIChidXQNCiB3ZSBhcmUgbm90IGNoYW5n aW5nIHRoZSBhZHZpY2UsIGJlY2F1c2UgTDRTIGlzIG9ubHkgYW4gZXhwZXJpbWVudCkuIFRoZSBw cml6ZSBpcyB0byByZW1vdmUgdGhlIGhlYWQtb2YtbGluZSBibG9ja2luZyBwcm9ibGVtIGZvciB0 aGVpciB1c2Vycy4NCjxicj4NCjxicj4NClRoaXMgaXMgbm90IEw0Uy1zcGVjaWZpYywgYWx0aG8g dGhlcmUgYXJlIG5vIG90aGVyIGV4YW1wbGVzIGF0IHRoZSBtb21lbnQgd2hlcmUgdGhpcyBvcHBv cnR1bml0eSBpcyBwb3NzaWJsZSAoc28gaW4gdGhhdCBzZW5zZSBpdCBpcw0KPGk+Y3VycmVudGx5 PC9pPiBMNFMtc3BlY2lmaWMpLjxicj4NCjxicj4NCjxicj4NClRoZSBtZXNzYWdlIGhhcyB0byBi ZSBoYW5kbGVkIHJlYWxseSBjYXJlZnVsbHksIGJlY2F1c2UgdGhlIG9wcG9ydHVuaXRpZXMgZm9y IG1pc3VuZGVyc3RhbmRpbmcgYXJlIGVub3Jtb3VzIChhcyBldmlkZW5jZWQgYnkgdGhpcyB0aHJl YWQsIGFuZCB3ZSBoYXZlbid0IGV2ZW4gc3RhcnRlZCB0YWxraW5nIHRvIG5vbi10cmFuc3BvcnQg cGVvcGxlIHlldCkuPGJyPg0KPGJyPg0KU28gR29ycnkgYW5kIERhdmlkIEIgd2FudCBtZSB0byBk cmFmdCBhIHNob3J0IEktRCB0aGF0IHRoZXkgd2lsbCB3b3JkLXNtaXRoIGFuZCBhdXRob3IgYXMg dHN2d2cgY2hhaXJzIHRvIG1ha2UgdGhlIHNpdHVhdGlvbiBjbGVhci48YnI+DQo8YnI+DQpJIGhh dmUgc2FpZCBJIGRvbid0IHdhbnQgdGhpcyBkaXNjdXNzaW9uIHRvIGJlIG9mZmljaWFsbHkgcmFp c2VkIG91dHNpZGUgdGhlIHRyYW5zcG9ydCBhcmVhIHVudGlsIHdlIGFyZSBzdXJlIHRoYXQgYSB2 YXJpYW50IG9mIFJBQ0sgaXMgZXZlbiBmZWFzaWJsZSB3aXRob3V0IGFueSBwYWNrZXQgY291bnRp bmcgYXQgYWxsIChpLmUuIHdpdGhvdXQgdGhlIGluaXRpYWwgMy1EdXBBQ0sgcnVsZSBpbiBjdXJy ZW50IFJBQ0spLiBTbyBJJ2xsIHByaW9yaXRpemUNCiB3b3JraW5nIHRoYXQgb3V0IGZvciB0aGUg bmV4dCB3ZWVrIG9yIHNvLCByYXRoZXIgdGhhbiBkcmFmdGluZyBhbnl0aGluZy48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQpCb2I8YnI+DQo8YnI+DQp7Tm90ZSAxfTogSSBoYWRuJ3QgY29uc2lkZXJl ZCB0aGF0IHRoaXMgd291bGQgYWZmZWN0IHRlY2hub2xvZ2llcyBsaWtlIEVDTVAgdGhhdCBtYWlu dGFpbiBvcmRlciB3aXRob3V0IGEgcmVzZXF1ZW5jaW5nIGJ1ZmZlciBhbmQgd2l0aG91dCBpbnRy b2R1Y2luZyBIb0wgYmxvY2tpbmcuIEJ1dCBhY3R1YWxseSwgdGhlIGNvbnNlcXVlbmNlIHRoZXJl IHdvdWxkIGJlIHRoYXQgTDRTIHRyYWZmaWMgY291bGQgYmUgc3ByYXllZCBieSBFQ01QIHdpdGhv dXQNCiBwZXItZmxvdyBoYXNoaW5nLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5NaWNoYWVsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBCb2IgQnJpc2NvZSBbPGEgaHJlZj0i bWFpbHRvOmluQGJvYmJyaXNjb2UubmV0Ij5tYWlsdG86aW5AYm9iYnJpc2NvZS5uZXQ8L2E+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTm92ZW1iZXIgOSwgMjAxOCA2OjQyIEFNPGJyPg0K PGI+VG86PC9iPiBTY2hhcmYsIE1pY2hhZWw7IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3Jn Ij50Y3BtQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRzdndn QGlldGYub3JnIj50c3Z3Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0 c3Z3Z10gQ3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gJnF1b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5NaWNoYWVsLDxicj4NCjxicj4NClRoYXQgaXMgdGhlIHBvaW50IEkg dGhvdWdodCB5b3Ugd2VyZSBtYWtpbmcsIGFuZCBteSBwb2ludCAvaXMvIGFib3V0IHRoYXQuPGJy Pg0KPGJyPg0KSWYgYW4gYXBwbGljYXRpb24gbmVlZHMgYWxsIHRoZSBwYWNrZXRzIChpLmUuIGEg cmVsaWFibGUgcHJvdG9jb2wpLCBpdCdzIG5vdCB1c2VmdWwgdG8gcmVkdWNlIHRoZSBsYXRlbmN5 IG9mIHNvbWUgcGFja2V0cyBidXQgbm90IGFsbC4gVGhhdCdzIHdoZXJlIHRoZSBpbi1vcmRlciBy ZXF1aXJlbWVudCBjb21lcyBmcm9tLjxicj4NCjxicj4NCkhvd2V2ZXIsIGlmIGEgc3RyZWFtLWJh c2VkIHRyYW5zcG9ydCBpcyB1c2VkIChpLmUuIFRDUCkgdGhlIC9hcHBsaWNhdGlvbi8gc3RpbGwg Z2V0cyBpbi1vcmRlciBkZWxpdmVyeSBmcm9tIFRDUC4gSXQganVzdCBkb2Vzbid0IGhhdmUgdG8g cmVxdWlyZSBsaW5rcyB0byBwcm92aWRlIGluIG9yZGVyIGRlbGl2ZXJ5IGFzIHdlbGwuPGJyPg0K PGJyPg0KTm90ZSB0aGF0IHRoZXJlIGNhbiBiZSBtdWx0aXBsZSBmbG93cyBvdmVyIG9uZSBsaW5r LiBTbyAnaW4tb3JkZXIgZGVsaXZlcnknIGZvciBhIGxpbmsgZG9lcyBub3QgbWVhbiBpbiBvcmRl ciBvZiBUQ1Agc2VxdWVuY2UgbnVtYmVyLiBJdCBtZWFucyAnZGVsaXZlcmVkIGluIHRoZSBvcmRl ciB0aGF0IHBhY2tldHMgYXJyaXZlZCBhdCB0aGUgbGluaycgKHRoZSBsaW5rIGluZ3Jlc3MgYWRk cyBpdHMgb3duIHNlcXVlbmNlIG51bWJlcnMsIGFuZCB0aGUNCiBsaW5rIGVncmVzcyBidWZmZXJz IHRoZW0gdW50aWwgaXQgY2FuIHNlbmQgb3V0IGluIHRoZSBzYW1lIG9yZGVyLCBvciB1bnRpbCBh IHRpbWUtb3V0IG9yIG1heCBuby4gb2YgbGluayByZXRyYW5zbWlzc2lvbnMpLjxicj4NCjxicj4N ClNvLCBpZiB0aGUgbGluayBsb3NlcyBhIHBhY2tldCBmcm9tIGZsb3cgQSAodGhlIGxpbmsgaXNu J3QgYXdhcmUgb2YgbWljcm9mbG93cywgSSdtIGp1c3Qgc2F5aW5nIHRoZSBwYWNrZXQgaGFwcGVu cyB0byBiZSBmcm9tIGZsb3cgQSksIGxpbmstbGF5ZXIgaW4tb3JkZXIgZGVsaXZlcnkgd2lsbCBo b2xkIGJhY2sgYWxsIHBhY2tldHMgc2VudCBhZnRlciB0aGF0IHBhY2tldCAoZnJvbSBhbGwgZmxv d3MsIG5vdCBqdXN0IGZsb3cgQSkgdW50aWwgdGhlDQogbGluayByZXBhaXJzIHRoZSBnYXAgb3Ig Z2l2ZXMgdXAuIDxicj4NCjxicj4NClNvIGhvcC1ieS1ob3AgaW4tb3JkZXIgZGVsaXZlcnkgZ2l2 ZXMgZXZlcnkgZmxvdyB0aGUgc2FtZSBkZWxheSBhcyB0aGUgd29yc3QgZGVsYXllZCBmbG93Ljxi cj4NCjxicj4NCk9mIGNvdXJzZSwgc29tZW9uZSBidWlsZGluZyBhIG5ldHdvcmsgZm9yIERFVE5F VCB3b3VsZCBhdm9pZCBsaW5rIHRlY2hub2xvZ2llcyBsaWtlIFdpRmkgb3IgTFRFIHRoYXQgZnJl cXVlbnRseSBsb3NlIGFuZCByZXRyYW5zbWl0IHBhY2tldHMuIEJ1dCB3aGVyZXZlciB0aGVyZSBp cyB2YXJpYWJsZSBkZWxheSBpbiBhIGxpbmssIGd1YXJhbnRlZWQgaW4tb3JkZXIgZGVsaXZlcnkg cGVyLWhvcCBtZWFucyBldmVyeSBmbG93IGlzIGd1YXJhbnRlZWQNCiB0byBhbHdheXMgZ2V0IHRo ZSB3b3JzdCBkZWxheSBmcm9tIGV2ZXJ5IGxpbmssIHdoaWNoIHdvdWxkIGhhdmUgYmVlbiBleHBl cmllbmNlZCBieSBvbmx5IG9uZSBmbG93IHdpdGhvdXQgcGVyLWhvcCBpbi1vcmRlciBkZWxpdmVy eS4NCjxicj4NCjxicj4NCkFuZCBtYW55IG9mIHRoZSBhcHBsaWNhdGlvbnMgb2YgREVUTkVUIGlu dm9sdmUgZHVtYiBpbmR1c3RyaWFsIG1hY2hpbmVyeSB0aGF0IGp1c3QgZXhwZWN0cyBldmVyeXRo aW5nIHRvIGFycml2ZSBpbiBvcmRlciBhbmQgdG8gYSBjbG9ja2VkIHNjaGVkdWxlLiBCdXQgaXQn cyBhbHdheXMgYXMgZWZmZWN0aXZlIHRvIGRlcGxveSBhIHJlc2VxdWVuY2luZyBidWZmZXIgYXMg dGhlIHBlbnVsdGltYXRlIGhvcCwgc2NyZXdlZCBvbnRvIHRoZSByZWNlaXZpbmcNCiBtYWNoaW5l IGlmIG5lY2Vzc2FyeSwgcmF0aGVyIHRoYW4gcmVxdWlyZSBwZXItaG9wIHJlc2VxdWVuY2luZyBp biB0aGUgbmV0d29yay48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fPGJyPg0KU28sIHdoeSBk byBJbnRlcm5ldCBsaW5rcyBvZnRlbiBlbnN1cmUgaW4tb3JkZXIgZGVsaXZlcnkgZXZlbiB0aG91 Z2ggVENQIHB1dHMgZXZlcnl0aGluZyBpbiBvcmRlciBmb3IgdGhlIGFwcGxpY2F0aW9uPw0KPGJy Pg0KPGJyPg0KU2hvcnQgYW5zd2VyOiB0aGUgMyBEdXBBQ0sgcnVsZSAod2hpY2ggaXMgdG8gZG8g d2l0aCBsb3NzLXJlY292ZXJ5LCBhIGRpZmZlcmVudCBpc3N1ZSBmcm9tIHRoZSBkaXNjdXNzaW9u IGFib3ZlKS48YnI+DQo8YnI+DQpMb25nIGFuc3dlcjogQXMgZmxvdyByYXRlcyBoYXZlIHNjYWxl ZCB1cCwgdGhlIHR5cGljYWwgdGltZSBiZXR3ZWVuIDMgcGFja2V0IGFycml2YWxzIGhhcyBiZWNv bWUgc28gc21hbGwgdGhhdCBUQ1AncyAzLUR1cEFDSyBydWxlIG1ha2VzIGxpbmtzIGhhdmUgdG8g cHJvdmlkZSBkZWxpdmVyeSB3aXRoIG9ubHkgYSB2ZXJ5IHNtYWxsIHJlLW9yZGVyaW5nIGRlZ3Jl ZSAtIHNvIHNtYWxsIHRoYXQgaXQncyBlYXNpZXIgZm9yIGEgbGluayB0byBqdXN0DQogZGVsaXZl ciBldmVyeXRoaW5nIGluIHRoZSBvcmRlciBpdCByZWNlaXZlZCBpdDsgbm90IGJlY2F1c2UgVENQ IGRvZXNuJ3QgcHV0IHBhY2tldHMgYmFjayBpbiBvcmRlciwgYnV0IGp1c3Qgc28gYXMgbm90IHRv IHRyaWdnZXIgVENQIGludG8gZ2VuZXJhdGluZyBzcHVyaW91cyByZXRyYW5zbWlzc2lvbnMuPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KQm9iPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gMDgvMTEvMjAxOCAxNjozNSwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbmxpbmUgW21zXTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3Rl eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5k b3d0ZXh0Ij4gQm9iIEJyaXNjb2UgWzxhIGhyZWY9Im1haWx0bzppbkBib2JicmlzY29lLm5ldCI+ bWFpbHRvOmluQGJvYmJyaXNjb2UubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgTm92ZW1iZXIgOCwgMjAxOCAxMjo1NiBQTTxicj4NCjxiPlRvOjwvYj4gU2NoYXJmLCBNaWNo YWVsOyA8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyI+dGNwbUBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0c3Z3Z0BpZXRmLm9yZyI+dHN2d2dAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHN2d2ddIENyb3NzLWFyZWEgYWxpZ25t ZW50IG9uICZxdW90O0w0UyBhbmQgUkFDSyZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TWljaGFl bCw8YnI+DQo8YnI+DQpUaGlzIGlzIG1lcmVseSBhIHN5bXB0b20gb2YgYSBkaWZmZXJlbmNlIGlu IG9waW5pb24gb24gd2hlcmUgdGhlIHJlc2VxdWVuY2luZyBmdW5jdGlvbiBzaG91bGQgYmUgbG9j YXRlZC48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KTDRTIHRha2VzIHRoZSBlbmQtdG8tZW5k IGFwcHJvYWNoIHNheWluZyB0aGF0IGl0IGlzIHN1ZmZpY2llbnQgdG8gZG8gcmVzZXF1ZW5jaW5n IGluIG9uZSBwbGFjZSAodGhlIHJlY2VpdmluZyBob3N0KSBpZiBpdCBpcyBuZWVkZWQuIFRoZW4g YW55IHJlc2VxdWVuY2luZyBkZWxheSBvbmx5IGFmZmVjdHMgdGhhdCBmbG93LjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj4NClRo ZSBERVRORVQgYXBwcm9hY2ggaXMgc2F5aW5nIHRoZSByZXNlcXVlbmNpbmcgbXVzdCBiZSBkb25l IGhvcC1ieS1ob3AuIFRoaXMgbWVhbnMgdGhlcmUgYXBwZWFycyB0byBiZSBubyByZXNlcXVlbmNp bmcgbmVlZGVkIG9uIHRoZSByZWNlaXZlciAoZXhjZXB0IGlmIHRoZXJlJ3MgcmUtb3JkZXJpbmcg b24gdGhlIGZpbmFsIGhvcCkuDQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQpJbiBvcmRlciB0byBndWFy YW50ZWUgbm8gcmVzZXF1ZW5jaW5nIGluIHRoZSBuZXR3b3JrIChERVRORVQgYXBwcm9hY2gpLCBv bmx5IHRoZSB0aGUgd29yc3QgY2FzZSBsYXRlbmN5IGNhbiBiZSBndWFyYW50ZWVkLCBhbmQgZXZl cnkgcGFja2V0IGhhcyB0byBoYXZlIHRoYXQgc2FtZSB3b3JzdC1jYXNlIGxhdGVuY3kuPG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMi Pg0KV2hlbiB5b3UgbGVhdmUgcmVzZXF1ZW5jaW5nIHRvIHRoZSByZWNlaXZlciAoZW5kLXRvLWVu ZCBhcHByb2FjaCksIG1vc3Qgb2YgdGhlIHBhY2tldHMgYXJyaXZlIGVhcmxpZXIgdGhhbiB0aGV5 IHdvdWxkIHdpdGggREVUTkVULCBidXQgb3V0IG9mIG9yZGVyIG9uZXMgbWlnaHQgbm90LiBUaGVu IHRoZSBhcHBsaWNhdGlvbiBjaG9vc2VzIHdoZXRoZXIgaXQgd2FudHMgdG8gd2FpdC48bzpwPjwv bzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlttc10gTXkgcG9pbnQgaXMgZGlm ZmVyZW50OiBUaGVyZSBzZWVtIHRvIGJlIG90aGVyIHdvcmtpbmcgZ3JvdXBzIGluIHRoZSBJRVRG IHRoYXQgZG8gdGFsayBhYm91dCDigJxsb3cgbGF0ZW5jeeKAnSBhcyB3ZWxsIGJ1dCBhcHBhcmVu dGx5IHRoZXkgYWxzbyBkbyBuZWVkIGluLW9yZGVyIGRlbGl2ZXJ5IG9mIHBhY2tldHMsDQogdG9v LiBTbyB0aGUgYXNzdW1wdGlvbiB0aGF0IGUuZy4gYSBsaW5rIGxheWVyIHRlY2hub2xvZ3kgY2Fu IHNpbXBseSBkaXNhYmxlIGluLW9yZGVyIGRlbGl2ZXJ5IGZvciBhbGwg4oCcbG93IGxhdGVuY3ni gJ0gYXBwbGljYXRpb25zIHNlZW1zIG5vdCBjb3JyZWN0LiBUaGUgcmVhbGl0eSBtYXkgYmUgYSBi aXQgbW9yZSBjb21wbGV4Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIDMgRHVwQUNLIHJ1bGUgaW4gVENQ IGxlZCB0aGUgSW50ZXJuZXQgbm90IHRvIGZvbGxvdyB0aGUgZW5kLXRvLWVuZCBwcmluY2lwbGUg b24gcmUtc2VxdWVuY2luZy4gTm93IHdlJ3JlIHJlbW92aW5nIHRoZSAzIER1cEFDSyBydWxlLCB3 ZSBjYW4gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGUyZSBwcmluY2lwbGUuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bbXNdIEZvciBUQ1AsIHRocmVl IER1cEFDS1MgYXJlIGEgU0hPVUxEIGluIFJGQyA1NjgxIGFuZCBSRkMgNTY4MSBpcyBzdGFuZGFy ZHMgdHJhY2suIFNvIHRoZSBiYXIgZm9yIOKAnHJlbW92aW5n4oCdIHRoYXQgcnVsZSBmb3IgVENQ DQogaXMgbm90IGxvd+KApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlttc10gQWxzbywgdGhlIGVuZC10by1lbmQgcHJpbmNpcGxlIGNv bWVzIHdpdGggdHJhZGVvZmZzLiBGb3IgaW5zdGFuY2UsIHJlbHlpbmcgb24gdGhlIGVuZC10by1l bmQgcHJpbmNpcGxlIGZvciByZWNvdmVyeSBvZiBiaXQNCiBlcnJvcnMgaXMgbm90IGVmZmljaWVu dC4gRm9yIGluLW9yZGVyIGRlbGl2ZXJ5IHRoZXJlIGFyZSB0cmFkZW9mZnMgYXMgd2VsbCwgc2Vl IGUuZy4gU2VjdGlvbiA0IGluIGRyYWZ0LWlldGYtdGNwbS1yYWNrLTA0LiBUaGVyZSBtYXkgYmUg bm8gZnJlZSBsdW5jaC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9mIGNvdXJzZSwgYW4gYXBwbGljYXRpb24g bWlnaHQgY2hvb3NlIHRvIHVzZSBUQ1AgYW5kIEw0UywgcmF0aGVyIHRoYW4gVURQIGFuZCBMNFMg KGUuZyBRVUlDKS4gVGhlbiB0aGVyZSBjb3VsZCBzdGlsbCBiZSBIb0wgYmxvY2tpbmcgaW4gdGhl IHJlY2VpdmluZyBUQ1Agc3RhY2suIEJ1dCBhdCBsZWFzdCB0aGVyZSdzIG5vIEhvTCBibG9ja2lu ZyBpbiB0aGUgbmV0d29yaywNCiBhbmQgdGhlIGFwcCBjYW4gY2hvb3NlIGJldHdlZW4gc3RyZWFt IChUQ1ApIG9yIGRhdGFncmFtIChVRFApLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+W21zXSBJZiBMUk8vR1JPIGluIHRoZSByZWNlaXZpbmcgVENQ IHN0YWNrIGdldHMgbWVzc2VkIHVwLCBJIGZhaWwgdG8gc2VlIHRoZSBiZW5lZml0IChzZWUgZHJh ZnQtaWV0Zi10Y3BtLXJhY2stMDQpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pY2hhZWw8L3NwYW4+PGJyPg0KPGJyPg0KPGJyPg0K Qm9iPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDYvMTEv MjAxOCAxOToyMCwgU2NoYXJmLCBNaWNoYWVsIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPkEgY29tbWVudCBvbiB0aGUgVENQTSBwcmVzZW50YXRpb24gJnF1 b3Q7TDRTIGFuZCBSQUNLJnF1b3Q7OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BcyBm YXIgYXMgSSB1bmRlcnN0YW5kLCB0aGUgREVUTkVUIFdHIGluIFJURyBhcmVhIGhhcyBxdWl0ZSBz b21lIHVzZXMgY2FzZXMgZm9yIHVsdHJhLWxvdyBsYXRlbmN5IHRyYW5zcG9ydCAtIGluIHBhcnRp Y3VsYXIgYWxzbyB3aXRoIGJvdW5kZWQgaml0dGVyLiBBbmQgc29tZSBvZiB0aGVzZSBhcHBsaWNh dGlvbnMgKGUuZy4gdXNpbmcgVURQKSBhcHBhcmVudGx5IG1heSBub3QgYmUgYWJsZSB0byB0b2xl cmF0ZSAqYW55KiBvdXQtb2Ytb3JkZXIgcGFja2V0IGRlbGl2ZXJ5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5TbyBwZXJoYXBzIHNvbWUgY3Jvc3MtYXJlYSBhbGlnbm1lbnQgb24gdWx0 YS1sb3ctbGF0ZW5jeSBhcHBsaWNhdGlvbiByZXF1aXJlbWVudHMgd291bGQgYmUgdXNlZnVsPzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NaWNoYWVsPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4od2hvIHJlY2VudGx5IGhhZCB0byByZXZpZXcgZHJhZnQtaWV0 Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlKTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGYm9iYnJpc2NvZS5uZXQlMkYm YW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzU0N2U1MDNlMjE4NTQ5 NDgzZjMwMDhkNjQ2NzQ5NWI5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjc3Mzg2Mzg5NTUwNjUxMSZhbXA7c2RhdGE9JTJCNFhvbG5LeVBuWTVDdThrdHVX WGkyU0o1cWJvTjdCcjklMkI2RE1yQ0hubWMlM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHA6Ly9ib2Ji cmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0gPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGYm9i YnJpc2NvZS5uZXQlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3 QzU0N2U1MDNlMjE4NTQ5NDgzZjMwMDhkNjQ2NzQ5NWI5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3Mzg2Mzg5NTUxNjUxNSZhbXA7c2RhdGE9eFpQdmRx a1BXdDBCMVJhR2xvMHU1UHZyeWphem1xam05OHBWMDB6T01XdyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+ aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4tLSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPkJvYiBCcmlzY29lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZib2JicmlzY29lLm5l dCUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDNTQ3ZTUwM2Uy MTg1NDk0ODNmMzAwOGQ2NDY3NDk1YjklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2NzczODYzODk1NTI2NTI0JmFtcDtzZGF0YT1TcE9KJTJGZHV3U0VSRG1z bER5dHdOTE5JSjVMNE94dnBUem5jYUF4MG9GclUlM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHA6Ly9i b2JicmlzY29lLm5ldC88L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0gPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGYm9iYnJpc2NvZS5u ZXQlMkYmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzU0N2U1MDNl MjE4NTQ5NDgzZjMwMDhkNjQ2NzQ5NWI5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRi NDclN0MxJTdDMCU3QzYzNjc3Mzg2Mzg5NTUyNjUyNCZhbXA7c2RhdGE9U3BPSiUyRmR1d1NFUkRt c2xEeXR3TkxOSUo1TDRPeHZwVHpuY2FBeDBvRnJVJTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwOi8v Ym9iYnJpc2NvZS5uZXQvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Qm9iIEJyaXNjb2UmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cCUzQSUyRiUyRmJvYmJyaXNjb2UubmV0JTJGJmFtcDtkYXRhPTAyJTdDMDElN0Nw cmF2YiU0MG1pY3Jvc29mdC5jb20lN0M1NDdlNTAzZTIxODU0OTQ4M2YzMDA4ZDY0Njc0OTViOSU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3NzM4NjM4OTU1 MzY1MzcmYW1wO3NkYXRhPWx5QmhjWFU3NFNVNTZzN3FyMU9VU2Z3YUlMNjhMY2JGN1dKeHRteiUy QlViMCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LS0gPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8v Ym9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6EC6417807D9754DA64F3087E2E2E03E2D154250rznt8114rzntrzd_-- From nobody Mon Nov 12 04:11:07 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A77130E11 for ; Mon, 12 Nov 2018 04:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WkdN9qwHDNvM for ; Mon, 12 Nov 2018 04:11:03 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2BE3130E08 for ; Mon, 12 Nov 2018 04:11:02 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id v1-v6so7404311ljd.0 for ; Mon, 12 Nov 2018 04:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5l1PU0P9FSWm1IIjZK2GCOatGjB57BnIbRyQcccD6Kw=; b=CjOniXwttRYWbKsCRSCR3oePUH4xIqm+NDbLDIYJOnn7GxlLyNDeAI+KtDrbvHAhca JBohoSpEzNl3JDwKLJ1hzU36G0JCRqNdDQdd51VX5yrXqKu34fb0venUgytn90xq3QwT ZoLF3fvPdksnWE/XYyuFG5+FJH/ZHwaPMha73DbtbYoAGGI3X1/BIcJn4xIOvlVBmHu7 FRMruQ4cdKPp9e8N9dcVp0/V52d26yQxxP7fLgvDmTDMMBEZ6C/G7IcryCpKspJViCkE V6XyiZnlgX2/rWpnFZCkTWsnkjJGp/gAijTS32GFBXzIgAgOxvCefRQOLQwsJY6mUxC4 HyIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5l1PU0P9FSWm1IIjZK2GCOatGjB57BnIbRyQcccD6Kw=; b=pIu0YWXZYjaMlRGyjvrV5f1vGjhbk03JIRwiOAii73Ngm3rMt2an/oL8UREdCb7avf VZSaP4i6brkVsX9s7VGOJ1dW/RwhXHyKad1evsq9Ahv2ULqSmefCbNswB+MrNaEQ6Dh0 yH/F9xDEWemZ9CbTEE/yjjnQ+bNZxtmPz/gUhvR/VvhrNrjES9ilbkt3nSyDLBlFNGAW YzkCD/sl25Y+1agMsXpGHHUkej5KzJ73d5NRx2jLoOtyodifV19MN0IKspyOD9S14JcF 78pCphkqYvyUttDp9xz041+ntKcJxhmxlfbGijjvMI26IeNiWsF3I+pD6650X0kT6/N9 QO6w== X-Gm-Message-State: AGRZ1gJfDHxptZxTDwqnU1/7+WpVVeruMsCI/YER1gtCxuCCIbm+Fc4N O/wIyvl+XvX4n2lf2+Dr2IxSRahMq6rjKMXhy93p0zpW X-Google-Smtp-Source: AJdET5dQyZxSC00U0gkXGMeLa9c9w2U72MxY2p6TNzvB+JKKwPA3sVwPAOL4c0993wCvZMQKuwlYTtY/BnU5lrZLwSg= X-Received: by 2002:a2e:b04f:: with SMTP id d15-v6mr557658ljl.3.1542024660955; Mon, 12 Nov 2018 04:11:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Mon, 12 Nov 2018 19:10:49 +0700 Message-ID: To: Yoshifumi Nishida Cc: ycheng=40google.com@dmarc.ietf.org, Ian Swett , tcpm@ietf.org Content-Type: multipart/alternative; boundary="00000000000026b596057a769809" Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 12:11:06 -0000 --00000000000026b596057a769809 Content-Type: text/plain; charset="UTF-8" Thank you for that feedback, Bob. Our goal was to drive active participation from more TCPM experts and regulars, and I hope we see more of it. As for saying something un-QUIC, I wouldn't worry, but I understand your point. I'm glad the presentation helped. If it's valuable, we'd be happy to do another presentation in Prague with changes between now and then. On Fri, Nov 9, 2018 at 7:45 PM Yoshifumi Nishida wrote: > > On Thu, Nov 8, 2018 at 4:37 PM Yuchung Cheng 40google.com@dmarc.ietf.org> wrote: > >> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe wrote: >> > >> > I just wanted to thank Jana for explaining QUIC loss recovery to us >> (and QUIC CC as far as it goes). >> > And thank you Jana, Ian, the chairs of both WGs (and anyone else >> involved) for setting it up. >> > >> > If one is not full-time on QUIC, it's very difficult to keep up with >> all the changes. But now we have a checkpoint to start from, I feel I will >> not be wasting people's time if I try to get involved - at least I only >> might say something un-QUIC occasionally, rather than nearly always. This >> has allowed people who understand how TCP cold be improved to help with >> QUIC, when working on QUIC isn't their day job. >> > >> > Again, Thank you. >> I like particularly that QUIC only reduces cwnd to 1 after the loss is >> confirmed not upon RTO fires. It should be very feasible for TCP (at >> least Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd >> reductions! >> > > +1 > >> >> Also IMHO TCP w/ quality timestamps are almost as good as QUIC >> pkt-ids. Google internally uses usec. We wish we could upstream it but >> RFC needs to be updated. >> > > I agree using timestamp for the purpose. > But, if we try to utilize the TS like pkt-id, I personally think it'll be > similar to use it as extend seqno like draft-bagnulo-tcpm-esn-00 rather > than fine grade TS. :) > > In any cases, it seems to me that many people think 7232 TS is not being > very efficient for today's internet. > it might be good time to think about extending TS option just like what > we're doing on ECN.. TS++? > -- > Yoshi > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --00000000000026b596057a769809 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for that feedback, Bob. Our goal was to drive ac= tive participation from more TCPM experts and regulars, and I hope we see m= ore of it. As for saying something un-QUIC, I wouldn't worry, but I und= erstand your point. I'm glad the presentation helped.=C2=A0

If it's valuable, we'd be happy to do another presentation = in Prague with changes between now and then.

On Fri, Nov 9, 2018 at 7:45 PM Yoshifumi Nishi= da <nishida@sfc.wide.ad.jp= > wrote:

On Thu, Nov 8, 2= 018 at 4:37 PM Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org> wrote:<= br>
On Thu, Nov 8, 2= 018 at 3:14 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
> I just wanted to thank Jana for explaining QUIC loss recovery to us (a= nd QUIC CC as far as it goes).
> And thank you Jana, Ian, the chairs of both WGs (and anyone else invol= ved) for setting it up.
>
> If one is not full-time on QUIC, it's very difficult to keep up wi= th all the changes. But now we have a checkpoint to start from, I feel I wi= ll not be wasting people's time if I try to get involved - at least I o= nly might say something un-QUIC occasionally, rather than nearly always. Th= is has allowed people who understand how TCP cold be improved to help with = QUIC, when working on QUIC isn't their day job.
>
> Again, Thank you.
I like particularly that QUIC only reduces cwnd to 1 after the loss is
confirmed not upon RTO fires. It should be very feasible for TCP (at
least Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd
reductions!

+1=C2=A0=C2=A0

Also IMHO TCP w/ quality timestamps are almost as good as QUIC
pkt-ids. Google internally uses usec. We wish we could upstream it but
RFC needs to be updated.

I agree using = timestamp for the purpose.=C2=A0
But, if we try to utilize the TS= like pkt-id, I personally think it'll be similar to use it as extend s= eqno like draft-bagnulo-tcpm-esn-00 rather than fine grade TS. :)

In any cases, it seems to me that many people think 7232 TS= is not being very efficient for today's internet.
it might b= e good time to think about extending TS option just like what we're doi= ng on ECN..=C2=A0 TS++?
--
Yoshi


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--00000000000026b596057a769809-- From nobody Mon Nov 12 04:13:49 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61355130DFC for ; Mon, 12 Nov 2018 04:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GCnfGtb_3T5 for ; Mon, 12 Nov 2018 04:13:46 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E74130E0C for ; Mon, 12 Nov 2018 04:13:45 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id k19-v6so7370458lji.11 for ; Mon, 12 Nov 2018 04:13:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t2qCodLVm8vggjH2jDu30cp9VBLkK1PGPFJnwozQkGM=; b=fYUw1Q2EuI+m/KtwEoVPR8Sq+cV06t5D1AG5oN/w+djV6i9wgpy3oAnbeVQPJ7gDhv lIupmqd0g38BPVUuz1utAMY962HxV4V9umZRvlfrMHVZc4pS4QlR8jejcFZPvq2+HarB VtiGYD64SrD7IjB0gCNZgKWc/+TdFMnDIs4FSyePhvdM8W8aLHysUawglCcpkGanJ50W FOgcYfOSf4q8x5mt71M3Ir5IcAWG3RU5E0yp/kzTQ+H8NSsCqgb0T7EqjUneWbxSOgp8 6CKVh/Z1HQ7p+qRGIibQZGhrzXL0dLMTKxrZRHh+RD9J4352X3p5PkTWdKM03R6hUzu1 czHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t2qCodLVm8vggjH2jDu30cp9VBLkK1PGPFJnwozQkGM=; b=bkj82DVl5PlvXsIoPmWqvq4SN5nMLrYJ2lZK6Qsn246l+1v/dMYuYrVhJeN+t3iUZt T7j7x1egOM36yJ0/fdgXTBqsGnvHTzYNwmuAg2JRtm4A/GrZPYLpQPxl6tbSToZ02KeZ X2XtdLdwH2wUNhIfOh4chSXy3/WCV89Qa2k5LBUeenDK9oyMs1nuRVUSwpQBuTRXngdK 5760heLcj4Jo68ZG/YvFGPWey/6Dh+X9NT3Aq5yBR49/lVh4NGqudUwYwkdtnqREKpD7 6iNHml31ZG9KITRok3x5NJcPwFJV2+5hU9Mm2auBOi1lDBR0P5iTfJCrx5C43IkS10bI THXw== X-Gm-Message-State: AGRZ1gIDzGKIojOTKFhfKLT48hWYQZ5C8WxYfVHJoWqBDHM+snm+X60Q e4LmdOJF0OSr6iSJGAPfsroXfWkT8iC6nkJgluY= X-Google-Smtp-Source: AJdET5fjjTSh9X+nmZiAySZcpOYMe1tsbESgNiw7fWUZEgo6vGWraEdZA4tXz7940+r9qidGALOpAoqtshGZEEhS054= X-Received: by 2002:a2e:6c04:: with SMTP id h4-v6mr511237ljc.92.1542024823598; Mon, 12 Nov 2018 04:13:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Mon, 12 Nov 2018 19:13:32 +0700 Message-ID: To: Praveen Balasubramanian Cc: ycheng=40google.com@dmarc.ietf.org, Bob Briscoe , Ian Swett , tcpm@ietf.org Content-Type: multipart/alternative; boundary="000000000000d871cf057a76a1bf" Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 12:13:48 -0000 --000000000000d871cf057a76a1bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Praveen, The point you're raising -- that we've lost the ack clock after an RTO -- is a reasonable point. My argument is that with pacing, cwnd reduction is unwarranted because in the extreme case, this collapses to restart after idle, where sending at cwnd with pacing is reasonable. The draft does not say that a sender should reduce the cwnd if it is not pacing, which we should add. Does that make sense? - jana On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian wrote: > Yuchung I brought that difference up in an email to the quic wg earlier > this week. > > In app send limited case, inflight could be very small compared to cwnd. > So in QUIC there is potential to send a burst out after a long idle perio= d > (with outstanding data) where TCP wouldn't. The draft claims this is okay > to do because RTO may have been a result of RTT increase instead of loss. > Is there data to suggest on which side we should err? i.e. data on what a= re > the chances that an RTO is due to an RTT increase versus loss. > > Do you see any safety concerns with delayed reduction of cwnd in case > where the RTO is not spurious? > > -----Original Message----- > From: tcpm On Behalf Of Yuchung Cheng > Sent: Thursday, November 8, 2018 4:38 PM > To: Bob Briscoe > Cc: Ian Swett ; tcpm IETF list > Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > > On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe wrote: > > > > I just wanted to thank Jana for explaining QUIC loss recovery to us (an= d > QUIC CC as far as it goes). > > And thank you Jana, Ian, the chairs of both WGs (and anyone else > involved) for setting it up. > > > > If one is not full-time on QUIC, it's very difficult to keep up with al= l > the changes. But now we have a checkpoint to start from, I feel I will no= t > be wasting people's time if I try to get involved - at least I only might > say something un-QUIC occasionally, rather than nearly always. This has > allowed people who understand how TCP cold be improved to help with QUIC, > when working on QUIC isn't their day job. > > > > Again, Thank you. > I like particularly that QUIC only reduces cwnd to 1 after the loss is > confirmed not upon RTO fires. It should be very feasible for TCP (at leas= t > Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd reductions! > > Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt-ids. > Google internally uses usec. We wish we could upstream it but RFC needs t= o > be updated. > > > > > > > Bob > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbobbris= coe.net%2F&data=3D02%7C01%7Cpravb%40microsoft.com%7Cf0911eeb74d7446f424= 508d645dbb779%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367732073167111= 49&sdata=3D0pt6YfpYOaF%2B5IWEKY3LMj1idEnYbApqUvWzhtLa5qE%3D&reserve= d=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= i > > etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micros= o > > ft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7cd0 > > 11db47%7C1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfAlyh= K > > QQ05Cea421rgb64DlEMvs%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.c= om%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfAlyhKQQ05Cea421rg= b64DlEMvs%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000d871cf057a76a1bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Praveen,

The point you're raising -= - that we've lost the ack clock after an RTO -- is a reasonable point. = My argument is that with pacing, cwnd reduction is unwarranted because in t= he extreme case, this collapses to restart after idle, where sending at cwn= d with pacing is reasonable.

The draft does not sa= y that a sender should reduce the cwnd if it is not pacing, which we should= add. Does that=C2=A0make sense?

- jana

On Fri, Nov 9, 2018 at 8:3= 4 AM Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:
Yuchung I brought that difference up in an email= to the quic wg earlier this week.

In app send limited case, inflight could be very small compared to cwnd. So= in QUIC there is potential to send a burst out after a long idle period (w= ith outstanding data) where TCP wouldn't. The draft claims this is okay= to do because RTO may have been a result of RTT increase instead of loss. = Is there data to suggest on which side we should err? i.e. data on what are= the chances that an RTO is due to an RTT increase versus loss.

Do you see any safety concerns with delayed reduction of cwnd in case where= the RTO is not spurious?

-----Original Message-----
From: tcpm <t= cpm-bounces@ietf.org> On Behalf Of Yuchung Cheng
Sent: Thursday, November 8, 2018 4:38 PM
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: Ian Swett <= ianswett@google.com>; tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] Thank you for the QUIC session in tcpm

On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>
> I just wanted to thank Jana for explaining QUIC loss recovery to us (a= nd QUIC CC as far as it goes).
> And thank you Jana, Ian, the chairs of both WGs (and anyone else invol= ved) for setting it up.
>
> If one is not full-time on QUIC, it's very difficult to keep up wi= th all the changes. But now we have a checkpoint to start from, I feel I wi= ll not be wasting people's time if I try to get involved - at least I o= nly might say something un-QUIC occasionally, rather than nearly always. Th= is has allowed people who understand how TCP cold be improved to help with = QUIC, when working on QUIC isn't their day job.
>
> Again, Thank you.
I like particularly that QUIC only reduces cwnd to 1 after the loss is conf= irmed not upon RTO fires. It should be very feasible for TCP (at least Linu= x) w/ TCP timestamps. It'll save a lot of spurious cwnd reductions!

Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt-ids. Goo= gle internally uses usec. We wish we could upstream it but RFC needs to be = updated.

>
>
> Bob
>
>
> --
> ________________________________________________________________
> Bob Briscoe=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://na01.safelinks.protectio= n.outlook.com/?url=3Dhttp%3A%2F%2Fbobbriscoe.net%2F&amp;data=3D02%7C01%= 7Cpravb%40microsoft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141= af91ab2d7cd011db47%7C1%7C0%7C636773207316711149&amp;sdata=3D0pt6YfpYOaF= %2B5IWEKY3LMj1idEnYbApqUvWzhtLa5qE%3D&amp;reserved=3D0
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://na01.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i
> etf.or= g%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40microso<= br> > ft.com<= /a>%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7cd0
> 11db47%7C1%7C0%7C636773207316711149&amp;sdata=3DK667a3IQG4rarQ%2FO= fAlyhK
> QQ05Cea421rgb64DlEMvs%3D&amp;reserved=3D0

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A= %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpra= vb%40microsoft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91a= b2d7cd011db47%7C1%7C0%7C636773207316711149&amp;sdata=3DK667a3IQG4rarQ%2= FOfAlyhKQQ05Cea421rgb64DlEMvs%3D&amp;reserved=3D0

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000d871cf057a76a1bf-- From nobody Mon Nov 12 08:37:49 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6412F1AC for ; Mon, 12 Nov 2018 08:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rkf5cgca5UEg for ; Mon, 12 Nov 2018 08:37:46 -0800 (PST) Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B3C12426A for ; Mon, 12 Nov 2018 08:37:46 -0800 (PST) Received: by mail-it1-x130.google.com with SMTP id k141-v6so14072839itk.3 for ; Mon, 12 Nov 2018 08:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZwpgOaO3j9EPsJGGwYUmM4EZuUKJJjLUdrLqk1BQX1E=; b=I7Ljs+oMk2ohXequPTyNFz45EhlWZaXb+0rrHTP5ZlzeR1IB3VIFRki8H7NkgnbVaz 6JmpzziVXHcwzgGfeV2c+zRo/az0zzQnBfFsjlNPuQnI3sIMmFksamTx1fTuttcg6eig m+AZ5zAW7THxRo8NWXeWzENt3k1KXbcDhcxGTKY8F887tzfegPTWyvL9ouz8FESpB4bm TkQyBfK9e77xpGb7HdH60jhS5JkxN5uO3/MTfvzwQw2ZWge01ZUgl1FWEHvE7wDPx5b7 eC4ynwXcOcIREIK7enz+9ATeJGReSeqfVA+oElftrDjevJ74x5Xjp1mRHnUFVKaXIpHA BoZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZwpgOaO3j9EPsJGGwYUmM4EZuUKJJjLUdrLqk1BQX1E=; b=iIifrB5VraXvuTQnFy3ZRsiln4sQ6+BPjIYI/bkm4Phx4/aF0B5wvToLw2oONIpTxP OLE6Equ8e+R/tELUh/pko7QXpAHpx0j7Nj9h8cO/+ouv3YwhYRhchX5spFMNE3JEVc4O CbRZU393aJ7nLS/kCVkIqNtLsfe0/A7yXLgT3Y3yQwebZLdIQbEgB/SLuF5BY1hOIDxL mI1enFHVXWzKaosiOrwgsTopER8cszz972/oZ/FKGeklMR+V4V1JRZk6e8vKb1ToMKmq +xXtgHE1lu83j/MJjyNbNz3AjXfJTUi8cNyK0kwMynm0kJ0I/42JqHCZ1O8HQky8TbMs CxJQ== X-Gm-Message-State: AGRZ1gLVrcOjtdsnCvjnQC766+JbccysaM19VM7BwbtLzyspmPPS+b5Y 0NsNFfUVlQp9EE57TTv/CAbYwJQVF8pj/GDSqyMiFA== X-Google-Smtp-Source: AJdET5eLV02QZLzmqCj63tkfp5fMBzUdPnTkuuiRn2N/FbUi8D7zPoI3tkonK/ucedjw8g1B8VSOHktPJcXcs2cLJLc= X-Received: by 2002:a02:3b54:: with SMTP id i20-v6mr1458753jaf.17.1542040665019; Mon, 12 Nov 2018 08:37:45 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a5e:8515:0:0:0:0:0 with HTTP; Mon, 12 Nov 2018 08:37:03 -0800 (PST) In-Reply-To: References: From: Yuchung Cheng Date: Mon, 12 Nov 2018 08:37:03 -0800 Message-ID: To: Jana Iyengar Cc: Praveen Balasubramanian , Bob Briscoe , Ian Swett , "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 16:37:48 -0000 On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar wrote: > Praveen, > > The point you're raising -- that we've lost the ack clock after an RTO --= is > a reasonable point. My argument is that with pacing, cwnd reduction is > unwarranted because in the extreme case, this collapses to restart after > idle, where sending at cwnd with pacing is reasonable I agree w/ Jana as well - the most generic way to treat burst due to prior_inflight << cwnd is pacing. With QUIC's approach, when RTO fires, cwnd remains unchanged until the ACK of the first retransmission (i.e. a probe packet) comes back. Therefore the delay is one RTT and the potential damage is an additional cwnd-worth of burst. Yes the worst case is more aggressive, and it can be too much for DC incast case if pacing isn't supported - one idea is to selective enable that if RTT variance is very large vs RTT. > > The draft does not say that a sender should reduce the cwnd if it is not > pacing, which we should add. Does that make sense? > > - jana > > On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian > wrote: >> >> Yuchung I brought that difference up in an email to the quic wg earlier >> this week. >> >> In app send limited case, inflight could be very small compared to cwnd. >> So in QUIC there is potential to send a burst out after a long idle peri= od >> (with outstanding data) where TCP wouldn't. The draft claims this is oka= y to >> do because RTO may have been a result of RTT increase instead of loss. I= s >> there data to suggest on which side we should err? i.e. data on what are= the >> chances that an RTO is due to an RTT increase versus loss. >> >> Do you see any safety concerns with delayed reduction of cwnd in case >> where the RTO is not spurious? >> >> -----Original Message----- >> From: tcpm On Behalf Of Yuchung Cheng >> Sent: Thursday, November 8, 2018 4:38 PM >> To: Bob Briscoe >> Cc: Ian Swett ; tcpm IETF list >> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm >> >> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe wrote: >> > >> > I just wanted to thank Jana for explaining QUIC loss recovery to us (a= nd >> > QUIC CC as far as it goes). >> > And thank you Jana, Ian, the chairs of both WGs (and anyone else >> > involved) for setting it up. >> > >> > If one is not full-time on QUIC, it's very difficult to keep up with a= ll >> > the changes. But now we have a checkpoint to start from, I feel I will= not >> > be wasting people's time if I try to get involved - at least I only mi= ght >> > say something un-QUIC occasionally, rather than nearly always. This ha= s >> > allowed people who understand how TCP cold be improved to help with QU= IC, >> > when working on QUIC isn't their day job. >> > >> > Again, Thank you. >> I like particularly that QUIC only reduces cwnd to 1 after the loss is >> confirmed not upon RTO fires. It should be very feasible for TCP (at lea= st >> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd reductions! >> >> Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt-ids. >> Google internally uses usec. We wish we could upstream it but RFC needs = to >> be updated. >> >> > >> > >> > Bob >> > >> > >> > -- >> > ________________________________________________________________ >> > Bob Briscoe >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbobb= riscoe.net%2F&data=3D02%7C01%7Cpravb%40microsoft.com%7Cf0911eeb74d7446f= 424508d645dbb779%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6367732073167= 11149&sdata=3D0pt6YfpYOaF%2B5IWEKY3LMj1idEnYbApqUvWzhtLa5qE%3D&rese= rved=3D0 >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= .i >> > etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro= so >> > ft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7cd0 >> > 11db47%7C1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfAly= hK >> > QQ05Cea421rgb64DlEMvs%3D&reserved=3D0 >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.= com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7cd011db47%7= C1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfAlyhKQQ05Cea421r= gb64DlEMvs%3D&reserved=3D0 >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Nov 12 09:38:40 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4662B130E89 for ; Mon, 12 Nov 2018 09:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9ubyQUD0vyG for ; Mon, 12 Nov 2018 09:38:28 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780094.outbound.protection.outlook.com [40.107.78.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53CAB130E6F for ; Mon, 12 Nov 2018 09:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nVENmkYbdtifDa+ooWUwx38Gt0OcW80Zt2Xy/rk80AA=; b=H27GpB/IvnOQko7EnM6FeLpl+4Mnxnof+nXtre6jMHy+JBO7sOsILUwnnSzAcRNkxv108tE8CFKHLy82SM6bcyrs0IMTkSzsJsf5yCA7gJA5aRjGsBNDu90zBYaFqBGh5rtGPqGX0oRlJqWTXfc1MXc+bJbvvMQRB5y20lNR9kc= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1113.namprd21.prod.outlook.com (52.132.149.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.6; Mon, 12 Nov 2018 17:35:34 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a%4]) with mapi id 15.20.1361.004; Mon, 12 Nov 2018 17:35:34 +0000 From: Praveen Balasubramanian To: Yuchung Cheng , Jana Iyengar CC: Bob Briscoe , Ian Swett , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] Thank you for the QUIC session in tcpm Thread-Index: AQHUd1RO08g6biwnTkKIBqYAsYD8EKVGmkCAgAAPe9CABWndAIAASaGAgAAPTgA= Date: Mon, 12 Nov 2018 17:35:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:f:6ce0:726b:c77c:8d6d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR2101MB1113; 6:D1+eWiXN2d+xvZC+e0gAUJDNMhN0w4LgXRwtaww7sRNXvgf/V8+krq+xH2fB5T1d/7O0WHBXHoL+fQ9DdrnQznSkEoSuLJ7Wp+KAv9S8M3kt68Scn10MmOgjJS3nU1ILpq+hKmVaGsem9E7G1wjnOHwyBe+JWRQFU5D4sNpE7/J7VYoiwMUKI2+n+eTt5i/dWg7TxgUIKIjsUEX9awvwfWVWK6wnulK0l3WHZlo4bXPWCrXbqIpSmEA8r2tzSH4QuK05T/SlqrS3Uwn8d+cjy7iBlIl7va4lASCLAbHPt3bdBMAS56cW2Jl5aHo+QED+T+Cb/QxZmcT5C6FAGeM4nLz9KAqbdhhIogw4UkMFEGortEfbhOYftS4CBaWBObQMt/1oorgYysHOPlOwj5zmpb/QoB3MS6heVjU4sfjr0yQ9Cle/ZotGHF76kh4Xuu01Y0YR+mhh8YQXMRWQ4ml5Ng==; 5:MPFg6RX81bVEV7NVvZ5ySutAxlXwngAh+YTEpUg/do2qL7fOoDvly3J33Yw0dbyPstdQkrL7diSZDq5xl9PwmgkKQ4VRUMqfI7bfhQsD5WgNdCFuEQe18U+JDQIjCE4WsvBY8NgulRIdmQf6dZONEX2JMgQ4e2AWFbwyR77MDBY=; 7:L253Mboq6ad0dt0tUOo49ixH6cYawpO110ZFiV6BfqRGimoTRaLzhc7iJ/zQZPvj4VewRuAHVppTJQH49qYn8xFKHCFC5P31xXcvNHlOOmKKRsBAydWPp+n1URkyVGJRAfL0UyDIQBruLf9Ie1rGng== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1595d258-4200-46a6-7da7-08d648c54050 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390040)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB1113; x-ms-traffictypediagnostic: MW2PR2101MB1113: x-ms-exchange-purlcount: 4 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(8220035)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231402)(944501410)(4982022)(2018427008)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:MW2PR2101MB1113; BCL:0; PCL:0; RULEID:; SRVR:MW2PR2101MB1113; x-forefront-prvs: 0854128AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(396003)(346002)(366004)(189003)(199004)(13464003)(478600001)(966005)(33656002)(6436002)(14454004)(10290500003)(25786009)(105586002)(22452003)(54906003)(4326008)(256004)(14444005)(110136005)(71190400001)(71200400001)(39060400002)(93886005)(2900100001)(316002)(229853002)(53936002)(6306002)(9686003)(6246003)(55016002)(7736002)(345774005)(97736004)(8990500004)(68736007)(5660300001)(46003)(11346002)(305945005)(486006)(74316002)(86612001)(86362001)(446003)(476003)(6506007)(102836004)(53546011)(76176011)(99286004)(7696005)(106356001)(81166006)(6116002)(186003)(10090500001)(8676002)(8936002)(81156014)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1113; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: vLg6eZaMBga6aBQsAWjxQs65rrF+6AX7cf22UGQ3LFl+Pz2k6B/pYAxgSrBr/ULvBVyyU9dvPGs3kLDR4YXXTEgVh29sdRvDqfzNB7UYSMHMcMDkOKaOb62e1ySFqO2uzNQLddg8coiLQ6CwYgCHSAK6sH1gS2wxIrcZylJIeGUd1U/IEBnyaY7E7U4M/AJGuVp8Nb3p25/3jP0kQkhhXZHy4ofjkVwlFiyxaLcd0XX8isHpIyKDoJVObNcg/FaJWeblVQGbu7kqOaINE4EsNwtplXUJTpaoxmKK52nSlnVHhvV61TgYvDA7Yy6ePDnxhjXjkgYLBFjwl+IXHuZZC+vngHXkkipQBztRmkvBNMs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1595d258-4200-46a6-7da7-08d648c54050 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2018 17:35:34.1706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1113 Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 17:38:39 -0000 WXVjaHVuZyB0aGlzIG1pZ2h0IGJlIHdvcnRoIGV4cGVyaW1lbnRpbmcgd2l0aCBhbmQgZ2V0dGlu ZyBtb3JlIGRhdGEgb24uIE1heWJlIHRoZXJlIHNob3VsZCBiZSBzb21lIHJlYWN0aW9uIHRvIGFu IHVuY29uZmlybWVkIFJUTyBldmVuIGlmIGl0IGlzIG5vdCByZWR1Y3Rpb24gYWxsIHRoZSB3YXkg dG8gTFc/IEkgbGlrZSBKYW5hJ3Mgc3VnZ2VzdGlvbiB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBT SE9VTEQgZHJvcCB0aGUgY3duZCBldmVuIGZvciB1bmNvbmZpcm1lZCBSVE8gaWYgbm90IHBhY2lu Zy4gDQoNCkkgY2hlY2tlZCB0aGUgbGF0ZXN0IGRyYWZ0IGFuZCBwYWNpbmcgaXMgYSBSRUNPTU1F TkRFRC4gSSBhbSBub3RpY2luZyB0aGF0IHRyYW5zcG9ydCBhbGdvcml0aG1zIGluIExpbnV4IGFu ZCBpbiBRVUlDIGFyZSBldm9sdmluZyBhc3N1bWluZyBwYWNpbmcgd2hpY2ggaXMgYSBmdW5jdGlv biB1c3VhbGx5IGltcGxlbWVudGVkIGFuZCBjb25maWd1cmVkIG91dHNpZGUgb2YgdGhlIHRyYW5z cG9ydC4gU28gdGhlIHRyYW5zcG9ydCBpcyBwb3RlbnRpYWxseSBtYWtpbmcgYW4gYXNzdW1wdGlv biB3aGljaCBtYXkgcmVzdWx0IGluIHNhZmV0eSBpc3N1ZXMuIEZvciBleGFtcGxlIEJCUiBjb25n ZXN0aW9uIGNvbnRyb2wgbWF5IG5vdCB3b3JrIHZlcnkgd2VsbCBpZiBwYWNpbmcgd2FzIGRpc2Fi bGVkIG9yIG1pc2NvbmZpZ3VyZWQ/IEkgZG9u4oCZdCBrbm93IG9mIGFueSByb2J1c3Qgc29sdXRp b24gdG8gdGhpcyBvdGhlciB0aGFuIGJ1aWxkIHBhY2luZyBpbnRvIHRoZSB0cmFuc3BvcnQgaXRz ZWxmLiBQYWNpbmcgaXMgYWxzbyB2ZXJ5IGNoYWxsZW5naW5nIGZvciBsb3cgbGF0ZW5jeSBmbG93 cyBiZWNhdXNlIG9mIGxhY2sgb2Ygc3VwcG9ydCBmb3IgZmluZSBncmFpbmVkIHRpbWVycy4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFl1Y2h1bmcgQ2hlbmcgPHljaGVuZ0Bn b29nbGUuY29tPiANClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTIsIDIwMTggODozNyBBTQ0KVG86 IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJh bWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgQm9iIEJyaXNjb2UgPGlldGZAYm9iYnJpc2Nv ZS5uZXQ+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyB0Y3BtQGlldGYub3JnIEV4 dGVuc2lvbnMgPHRjcG1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3RjcG1dIFRoYW5rIHlvdSBm b3IgdGhlIFFVSUMgc2Vzc2lvbiBpbiB0Y3BtDQoNCk9uIE1vbiwgTm92IDEyLCAyMDE4IGF0IDQ6 MTMgQU0sIEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gUHJhdmVl biwNCj4NCj4gVGhlIHBvaW50IHlvdSdyZSByYWlzaW5nIC0tIHRoYXQgd2UndmUgbG9zdCB0aGUg YWNrIGNsb2NrIGFmdGVyIGFuIFJUTyANCj4gLS0gaXMgYSByZWFzb25hYmxlIHBvaW50LiBNeSBh cmd1bWVudCBpcyB0aGF0IHdpdGggcGFjaW5nLCBjd25kIA0KPiByZWR1Y3Rpb24gaXMgdW53YXJy YW50ZWQgYmVjYXVzZSBpbiB0aGUgZXh0cmVtZSBjYXNlLCB0aGlzIGNvbGxhcHNlcyANCj4gdG8g cmVzdGFydCBhZnRlciBpZGxlLCB3aGVyZSBzZW5kaW5nIGF0IGN3bmQgd2l0aCBwYWNpbmcgaXMg cmVhc29uYWJsZQ0KSSBhZ3JlZSB3LyBKYW5hIGFzIHdlbGwgLSB0aGUgbW9zdCBnZW5lcmljIHdh eSB0byB0cmVhdCBidXJzdCBkdWUgdG8gcHJpb3JfaW5mbGlnaHQgPDwgY3duZCBpcyBwYWNpbmcu IFdpdGggUVVJQydzIGFwcHJvYWNoLCB3aGVuIFJUTyBmaXJlcywgY3duZCByZW1haW5zIHVuY2hh bmdlZCB1bnRpbCB0aGUgQUNLIG9mIHRoZSBmaXJzdCByZXRyYW5zbWlzc2lvbiAoaS5lLiBhIHBy b2JlIHBhY2tldCkgY29tZXMgYmFjay4gVGhlcmVmb3JlIHRoZSBkZWxheSBpcyBvbmUgUlRUIGFu ZCB0aGUgcG90ZW50aWFsIGRhbWFnZSBpcyBhbiBhZGRpdGlvbmFsIGN3bmQtd29ydGggb2YgYnVy c3QuDQoNClllcyB0aGUgd29yc3QgY2FzZSBpcyBtb3JlIGFnZ3Jlc3NpdmUsIGFuZCBpdCBjYW4g YmUgdG9vIG11Y2ggZm9yIERDIGluY2FzdCBjYXNlIGlmIHBhY2luZyBpc24ndCBzdXBwb3J0ZWQg LSBvbmUgaWRlYSBpcyB0byBzZWxlY3RpdmUgZW5hYmxlIHRoYXQgaWYgUlRUIHZhcmlhbmNlIGlz IHZlcnkgbGFyZ2UgdnMgUlRULg0KDQo+DQo+IFRoZSBkcmFmdCBkb2VzIG5vdCBzYXkgdGhhdCBh IHNlbmRlciBzaG91bGQgcmVkdWNlIHRoZSBjd25kIGlmIGl0IGlzIA0KPiBub3QgcGFjaW5nLCB3 aGljaCB3ZSBzaG91bGQgYWRkLiBEb2VzIHRoYXQgbWFrZSBzZW5zZT8NCj4NCj4gLSBqYW5hDQo+ DQo+IE9uIEZyaSwgTm92IDksIDIwMTggYXQgODozNCBBTSBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh biANCj4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+Pg0K Pj4gWXVjaHVuZyBJIGJyb3VnaHQgdGhhdCBkaWZmZXJlbmNlIHVwIGluIGFuIGVtYWlsIHRvIHRo ZSBxdWljIHdnIA0KPj4gZWFybGllciB0aGlzIHdlZWsuDQo+Pg0KPj4gSW4gYXBwIHNlbmQgbGlt aXRlZCBjYXNlLCBpbmZsaWdodCBjb3VsZCBiZSB2ZXJ5IHNtYWxsIGNvbXBhcmVkIHRvIGN3bmQu DQo+PiBTbyBpbiBRVUlDIHRoZXJlIGlzIHBvdGVudGlhbCB0byBzZW5kIGEgYnVyc3Qgb3V0IGFm dGVyIGEgbG9uZyBpZGxlIA0KPj4gcGVyaW9kICh3aXRoIG91dHN0YW5kaW5nIGRhdGEpIHdoZXJl IFRDUCB3b3VsZG4ndC4gVGhlIGRyYWZ0IGNsYWltcyANCj4+IHRoaXMgaXMgb2theSB0byBkbyBi ZWNhdXNlIFJUTyBtYXkgaGF2ZSBiZWVuIGEgcmVzdWx0IG9mIFJUVCBpbmNyZWFzZSANCj4+IGlu c3RlYWQgb2YgbG9zcy4gSXMgdGhlcmUgZGF0YSB0byBzdWdnZXN0IG9uIHdoaWNoIHNpZGUgd2Ug c2hvdWxkIA0KPj4gZXJyPyBpLmUuIGRhdGEgb24gd2hhdCBhcmUgdGhlIGNoYW5jZXMgdGhhdCBh biBSVE8gaXMgZHVlIHRvIGFuIFJUVCBpbmNyZWFzZSB2ZXJzdXMgbG9zcy4NCj4+DQo+PiBEbyB5 b3Ugc2VlIGFueSBzYWZldHkgY29uY2VybnMgd2l0aCBkZWxheWVkIHJlZHVjdGlvbiBvZiBjd25k IGluIGNhc2UgDQo+PiB3aGVyZSB0aGUgUlRPIGlzIG5vdCBzcHVyaW91cz8NCj4+DQo+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogdGNwbSA8dGNwbS1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgWXVjaHVuZyBDaGVuZw0KPj4gU2VudDogVGh1cnNkYXksIE5vdmVt YmVyIDgsIDIwMTggNDozOCBQTQ0KPj4gVG86IEJvYiBCcmlzY29lIDxpZXRmQGJvYmJyaXNjb2Uu bmV0Pg0KPj4gQ2M6IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47IHRjcG0gSUVURiBs aXN0IDx0Y3BtQGlldGYub3JnPg0KPj4gU3ViamVjdDogUmU6IFt0Y3BtXSBUaGFuayB5b3UgZm9y IHRoZSBRVUlDIHNlc3Npb24gaW4gdGNwbQ0KPj4NCj4+IE9uIFRodSwgTm92IDgsIDIwMTggYXQg MzoxNCBBTSwgQm9iIEJyaXNjb2UgPGlldGZAYm9iYnJpc2NvZS5uZXQ+IHdyb3RlOg0KPj4gPg0K Pj4gPiBJIGp1c3Qgd2FudGVkIHRvIHRoYW5rIEphbmEgZm9yIGV4cGxhaW5pbmcgUVVJQyBsb3Nz IHJlY292ZXJ5IHRvIHVzIA0KPj4gPiAoYW5kIFFVSUMgQ0MgYXMgZmFyIGFzIGl0IGdvZXMpLg0K Pj4gPiBBbmQgdGhhbmsgeW91IEphbmEsIElhbiwgdGhlIGNoYWlycyBvZiBib3RoIFdHcyAoYW5k IGFueW9uZSBlbHNlDQo+PiA+IGludm9sdmVkKSBmb3Igc2V0dGluZyBpdCB1cC4NCj4+ID4NCj4+ ID4gSWYgb25lIGlzIG5vdCBmdWxsLXRpbWUgb24gUVVJQywgaXQncyB2ZXJ5IGRpZmZpY3VsdCB0 byBrZWVwIHVwIA0KPj4gPiB3aXRoIGFsbCB0aGUgY2hhbmdlcy4gQnV0IG5vdyB3ZSBoYXZlIGEg Y2hlY2twb2ludCB0byBzdGFydCBmcm9tLCBJIA0KPj4gPiBmZWVsIEkgd2lsbCBub3QgYmUgd2Fz dGluZyBwZW9wbGUncyB0aW1lIGlmIEkgdHJ5IHRvIGdldCBpbnZvbHZlZCAtIA0KPj4gPiBhdCBs ZWFzdCBJIG9ubHkgbWlnaHQgc2F5IHNvbWV0aGluZyB1bi1RVUlDIG9jY2FzaW9uYWxseSwgcmF0 aGVyIA0KPj4gPiB0aGFuIG5lYXJseSBhbHdheXMuIFRoaXMgaGFzIGFsbG93ZWQgcGVvcGxlIHdo byB1bmRlcnN0YW5kIGhvdyBUQ1AgDQo+PiA+IGNvbGQgYmUgaW1wcm92ZWQgdG8gaGVscCB3aXRo IFFVSUMsIHdoZW4gd29ya2luZyBvbiBRVUlDIGlzbid0IHRoZWlyIGRheSBqb2IuDQo+PiA+DQo+ PiA+IEFnYWluLCBUaGFuayB5b3UuDQo+PiBJIGxpa2UgcGFydGljdWxhcmx5IHRoYXQgUVVJQyBv bmx5IHJlZHVjZXMgY3duZCB0byAxIGFmdGVyIHRoZSBsb3NzIA0KPj4gaXMgY29uZmlybWVkIG5v dCB1cG9uIFJUTyBmaXJlcy4gSXQgc2hvdWxkIGJlIHZlcnkgZmVhc2libGUgZm9yIFRDUCANCj4+ IChhdCBsZWFzdA0KPj4gTGludXgpIHcvIFRDUCB0aW1lc3RhbXBzLiBJdCdsbCBzYXZlIGEgbG90 IG9mIHNwdXJpb3VzIGN3bmQgcmVkdWN0aW9ucyENCj4+DQo+PiBBbHNvIElNSE8gVENQIHcvIHF1 YWxpdHkgdGltZXN0YW1wcyBhcmUgYWxtb3N0IGFzIGdvb2QgYXMgUVVJQyBwa3QtaWRzLg0KPj4g R29vZ2xlIGludGVybmFsbHkgdXNlcyB1c2VjLiBXZSB3aXNoIHdlIGNvdWxkIHVwc3RyZWFtIGl0 IGJ1dCBSRkMgDQo+PiBuZWVkcyB0byBiZSB1cGRhdGVkLg0KPj4NCj4+ID4NCj4+ID4NCj4+ID4g Qm9iDQo+PiA+DQo+PiA+DQo+PiA+IC0tDQo+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4gQm9iIEJyaXNjb2UN Cj4+ID4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cCUzQSUyRiUyRmJvYg0KPj4gPiBicmlzY29lLm5ldCUyRiZhbXA7ZGF0YT0wMiU3QzAxJTdD cHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDM2M0ZDIyODY2DQo+PiA+IDg0NDQ2OTFjMTY4MDhkNjQ4 YmQyY2U5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCUNCj4+ID4g N0M2MzY3NzYzNzQ2NzgzMjEzMjQmYW1wO3NkYXRhPVQlMkJXVEVjNDJWQyUyQnolMkJzbU1GeWps bTM3aG1Bd2ZlZQ0KPj4gPiBidVBjdU1ZbFZoZ0RZJTNEJmFtcDtyZXNlcnZlZD0wDQo+PiA+DQo+ PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ IHRjcG0gbWFpbGluZyBsaXN0DQo+PiA+IHRjcG1AaWV0Zi5vcmcNCj4+ID4gaHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3dw0K Pj4gPiB3LmkgDQo+PiA+IGV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtk YXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3INCj4+ID4gb3NvDQo+PiA+IGZ0LmNvbSU3Q2YwOTEx ZWViNzRkNzQ0NmY0MjQ1MDhkNjQ1ZGJiNzc5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDcNCj4+ ID4gY2QwIA0KPj4gPiAxMWRiNDclN0MxJTdDMCU3QzYzNjc3MzIwNzMxNjcxMTE0OSZhbXA7c2Rh dGE9SzY2N2EzSVFHNHJhclElMkZPZkFsDQo+PiA+IHloSw0KPj4gPiBRUTA1Q2VhNDIxcmdiNjRE bEVNdnMlM0QmYW1wO3Jlc2VydmVkPTANCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4+IHRjcG1AaWV0 Zi5vcmcNCj4+DQo+PiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy4NCj4+IGlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3Rp bmZvJTJGdGNwbSZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNybw0KPj4gc29mdC5jb20l N0MzYzRkMjI4NjY4NDQ0NjkxYzE2ODA4ZDY0OGJkMmNlOSU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3DQo+PiBjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3NjM3NDY3ODMyMTMyNCZhbXA7c2RhdGE9 MzNXeEtoNWM2cUw0bG41amVycHgNCj4+IFJoeXRmcmoxaVRLMjg0cEVxdjVmV0tZJTNEJmFtcDty ZXNlcnZlZD0wDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+IHRjcG0gbWFpbGluZyBsaXN0DQo+PiB0Y3BtQGlldGYub3JnDQo+PiBodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnd3dy4NCj4+IGlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7ZGF0 YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNybw0KPj4gc29mdC5jb20lN0MzYzRkMjI4NjY4NDQ0Njkx YzE2ODA4ZDY0OGJkMmNlOSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3DQo+PiBjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjc3NjM3NDY3ODMyMTMyNCZhbXA7c2RhdGE9MzNXeEtoNWM2cUw0bG41amVy cHgNCj4+IFJoeXRmcmoxaVRLMjg0cEVxdjVmV0tZJTNEJmFtcDtyZXNlcnZlZD0wDQo= From nobody Mon Nov 12 23:01:13 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC4C128CF3 for ; Mon, 12 Nov 2018 23:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyjnomSWRn4T for ; Mon, 12 Nov 2018 23:00:48 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E18130DC1 for ; Mon, 12 Nov 2018 23:00:47 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id t9-v6so9849456ljh.6 for ; Mon, 12 Nov 2018 23:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kzPOztQsxYDhmXgz7t/FB72Iplab8jCk9HpVwAjn0Uw=; b=caP4eceMU83EW4oLnYBQGMPPQZvlMQSWta/iTXhZOiLqDyuqzH/39vj0zrsp4ptavx cCAIuvB1zFrXAJgdZhHaKisPUXlIqs/bllkiu6Q3JoumFzUM85JtPxNzRxrUF2MSHK8a UhGTm5bp9OJnSkC8fh9/93Xtg+euHwSH36Ox36TmT3LC9kA4hQ/8d9KBUSHOeQndztoc hWdBub4PjL4yF+KScuwIh/3XWqe+lGspLS72i15bxWZt3ArxFKQvncbXDxLDZy4DEkhp JavOMkCtdRjKG/Ht8uJnyGDZ/nmdIvbZFedblwqsNhqbLzgMwWLrPpYjbNghghFscGvv SlVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kzPOztQsxYDhmXgz7t/FB72Iplab8jCk9HpVwAjn0Uw=; b=HDor+nz34sZZ59t5RTffYbblaHcl0ieUahEjySAOr+wWgrueprAUuaSlI6l38IF4uX iGb4VH4qHHh73hChlC0ZODavfl2NltniPV/rjnYoyFoim3ol0WWDz1YVPL+pPOYaWuJv OvAg1eW0o70aBGS7Um+p7VDa21NKFTwGMFiLdCXUTnyyi7lNlRZttG5jaE/uQANqd0Fa pFVCWmJNgnOl0hd87tqCQ1AAzwf0tAULTDBnncibkb9jjY7Mvx9EQszs1Yh29BJPYNCS MfK92XgPWqL036vW6moVtgjh/sL34zDr2tu+NGblw7UX9z3T2R7A0Qu/M5hye8LI1Q0A gMoA== X-Gm-Message-State: AGRZ1gIcOwCY53kqAeIQl18skJEf4Zu720qLuYITeKW2QuIwHrckLYHN byy7tgzcBJQ2D2kFC7SBPBvE2p7cgeegxMhskls= X-Google-Smtp-Source: AJdET5dYkAjqfmys/fwvEeejbMIfjShluLdYpqjqjEXddQ8siAPZkiEgtD99tyta2RwDHG2IORuzoKtBdPzaRiw4EJU= X-Received: by 2002:a2e:6c04:: with SMTP id h4-v6mr2303914ljc.92.1542092446034; Mon, 12 Nov 2018 23:00:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Tue, 13 Nov 2018 14:00:34 +0700 Message-ID: To: Praveen Balasubramanian Cc: Yuchung Cheng , Bob Briscoe , Ian Swett , tcpm@ietf.org Content-Type: multipart/alternative; boundary="00000000000074f0a5057a86601b" Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 07:00:52 -0000 --00000000000074f0a5057a86601b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Praveen, I think that's a deployment configuration question... you're right to note that BBR requires pacing, but I don't think the solution here is necessarily to build pacing into the transport. It's certainly useful to build it in as a safeguard in case the deployment environment does not implement pacing, but I think it still is useful to describe and implement controllers for environments that implement pacing. - jana On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian < pravb@microsoft.com> wrote: > Yuchung this might be worth experimenting with and getting more data on. > Maybe there should be some reaction to an unconfirmed RTO even if it is n= ot > reduction all the way to LW? I like Jana's suggestion that the > implementation SHOULD drop the cwnd even for unconfirmed RTO if not pacin= g. > > I checked the latest draft and pacing is a RECOMMENDED. I am noticing tha= t > transport algorithms in Linux and in QUIC are evolving assuming pacing > which is a function usually implemented and configured outside of the > transport. So the transport is potentially making an assumption which may > result in safety issues. For example BBR congestion control may not work > very well if pacing was disabled or misconfigured? I don=E2=80=99t know o= f any > robust solution to this other than build pacing into the transport itself= . > Pacing is also very challenging for low latency flows because of lack of > support for fine grained timers. > > -----Original Message----- > From: Yuchung Cheng > Sent: Monday, November 12, 2018 8:37 AM > To: Jana Iyengar > Cc: Praveen Balasubramanian ; Bob Briscoe < > ietf@bobbriscoe.net>; Ian Swett ; tcpm@ietf.org > Extensions > Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > > On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar wrote: > > Praveen, > > > > The point you're raising -- that we've lost the ack clock after an RTO > > -- is a reasonable point. My argument is that with pacing, cwnd > > reduction is unwarranted because in the extreme case, this collapses > > to restart after idle, where sending at cwnd with pacing is reasonable > I agree w/ Jana as well - the most generic way to treat burst due to > prior_inflight << cwnd is pacing. With QUIC's approach, when RTO fires, > cwnd remains unchanged until the ACK of the first retransmission (i.e. a > probe packet) comes back. Therefore the delay is one RTT and the potentia= l > damage is an additional cwnd-worth of burst. > > Yes the worst case is more aggressive, and it can be too much for DC > incast case if pacing isn't supported - one idea is to selective enable > that if RTT variance is very large vs RTT. > > > > > The draft does not say that a sender should reduce the cwnd if it is > > not pacing, which we should add. Does that make sense? > > > > - jana > > > > On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian > > wrote: > >> > >> Yuchung I brought that difference up in an email to the quic wg > >> earlier this week. > >> > >> In app send limited case, inflight could be very small compared to cwn= d. > >> So in QUIC there is potential to send a burst out after a long idle > >> period (with outstanding data) where TCP wouldn't. The draft claims > >> this is okay to do because RTO may have been a result of RTT increase > >> instead of loss. Is there data to suggest on which side we should > >> err? i.e. data on what are the chances that an RTO is due to an RTT > increase versus loss. > >> > >> Do you see any safety concerns with delayed reduction of cwnd in case > >> where the RTO is not spurious? > >> > >> -----Original Message----- > >> From: tcpm On Behalf Of Yuchung Cheng > >> Sent: Thursday, November 8, 2018 4:38 PM > >> To: Bob Briscoe > >> Cc: Ian Swett ; tcpm IETF list > >> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > >> > >> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe > wrote: > >> > > >> > I just wanted to thank Jana for explaining QUIC loss recovery to us > >> > (and QUIC CC as far as it goes). > >> > And thank you Jana, Ian, the chairs of both WGs (and anyone else > >> > involved) for setting it up. > >> > > >> > If one is not full-time on QUIC, it's very difficult to keep up > >> > with all the changes. But now we have a checkpoint to start from, I > >> > feel I will not be wasting people's time if I try to get involved - > >> > at least I only might say something un-QUIC occasionally, rather > >> > than nearly always. This has allowed people who understand how TCP > >> > cold be improved to help with QUIC, when working on QUIC isn't their > day job. > >> > > >> > Again, Thank you. > >> I like particularly that QUIC only reduces cwnd to 1 after the loss > >> is confirmed not upon RTO fires. It should be very feasible for TCP > >> (at least > >> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd reductions= ! > >> > >> Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt-ids= . > >> Google internally uses usec. We wish we could upstream it but RFC > >> needs to be updated. > >> > >> > > >> > > >> > Bob > >> > > >> > > >> > -- > >> > ________________________________________________________________ > >> > Bob Briscoe > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbo= b > >> > briscoe.net%2F&data=3D02%7C01%7Cpravb%40microsoft.com%7C3c4d2286= 6 > >> > 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > >> > 7C636776374678321324&sdata=3DT%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfe= e > >> > buPcuMYlVhgDY%3D&reserved=3D0 > >> > > >> > _______________________________________________ > >> > tcpm mailing list > >> > tcpm@ietf.org > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= w > >> > w.i > >> > etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40mic= r > >> > oso > >> > ft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7 > >> > cd0 > >> > 11db47%7C1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfA= l > >> > yhK > >> > QQ05Cea421rgb64DlEMvs%3D&reserved=3D0 > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > >> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micr= o > >> soft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 > >> cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerp= x > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > >> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micr= o > >> soft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 > >> cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerp= x > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 > --00000000000074f0a5057a86601b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Praveen,

I think that's a deploymen= t configuration question... you're right to note that BBR requires paci= ng, but I don't think the solution here is necessarily to build pacing = into the transport. It's certainly useful to build it in as a safeguard= in case the deployment environment does not implement pacing, but I think = it still is useful to describe and implement controllers for environments t= hat implement pacing.

- jana

<= /div>
On Tue, Nov 13, 2018 a= t 12:35 AM Praveen Balasubramanian <pravb@microsoft.com> wrote:
Yuchung this might be worth experimenting with and getting more data on.= Maybe there should be some reaction to an unconfirmed RTO even if it is no= t reduction all the way to LW? I like Jana's suggestion that the implem= entation SHOULD drop the cwnd even for unconfirmed RTO if not pacing.

I checked the latest draft and pacing is a RECOMMENDED. I am noticing that = transport algorithms in Linux and in QUIC are evolving assuming pacing whic= h is a function usually implemented and configured outside of the transport= . So the transport is potentially making an assumption which may result in = safety issues. For example BBR congestion control may not work very well if= pacing was disabled or misconfigured? I don=E2=80=99t know of any robust s= olution to this other than build pacing into the transport itself. Pacing i= s also very challenging for low latency flows because of lack of support fo= r fine grained timers.

-----Original Message-----
From: Yuchung Cheng <ycheng@google.com>
Sent: Monday, November 12, 2018 8:37 AM
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; Bob Briscoe <ietf@bobbriscoe.net>; Ian S= wett <ianswett@= google.com>; tcpm= @ietf.org Extensions <tcpm@ietf.org>
Subject: Re: [tcpm] Thank you for the QUIC session in tcpm

On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar <jri.ietf@gmail.com> wrote:
> Praveen,
>
> The point you're raising -- that we've lost the ack clock afte= r an RTO
> -- is a reasonable point. My argument is that with pacing, cwnd
> reduction is unwarranted because in the extreme case, this collapses <= br> > to restart after idle, where sending at cwnd with pacing is reasonable=
I agree w/ Jana as well - the most generic way to treat burst due to prior_= inflight << cwnd is pacing. With QUIC's approach, when RTO fires,= cwnd remains unchanged until the ACK of the first retransmission (i.e. a p= robe packet) comes back. Therefore the delay is one RTT and the potential d= amage is an additional cwnd-worth of burst.

Yes the worst case is more aggressive, and it can be too much for DC incast= case if pacing isn't supported - one idea is to selective enable that = if RTT variance is very large vs RTT.

>
> The draft does not say that a sender should reduce the cwnd if it is <= br> > not pacing, which we should add. Does that make sense?
>
> - jana
>
> On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian
> <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:
>>
>> Yuchung I brought that difference up in an email to the quic wg >> earlier this week.
>>
>> In app send limited case, inflight could be very small compared to= cwnd.
>> So in QUIC there is potential to send a burst out after a long idl= e
>> period (with outstanding data) where TCP wouldn't. The draft c= laims
>> this is okay to do because RTO may have been a result of RTT incre= ase
>> instead of loss. Is there data to suggest on which side we should =
>> err? i.e. data on what are the chances that an RTO is due to an RT= T increase versus loss.
>>
>> Do you see any safety concerns with delayed reduction of cwnd in c= ase
>> where the RTO is not spurious?
>>
>> -----Original Message-----
>> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yuchung Cheng
>> Sent: Thursday, November 8, 2018 4:38 PM
>> To: Bob Briscoe <ietf@bobbriscoe.net>
>> Cc: Ian Swett <ianswett@google.com>; tcpm IETF list <tcpm@ietf.org>
>> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm
>>
>> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote: >> >
>> > I just wanted to thank Jana for explaining QUIC loss recovery= to us
>> > (and QUIC CC as far as it goes).
>> > And thank you Jana, Ian, the chairs of both WGs (and anyone e= lse
>> > involved) for setting it up.
>> >
>> > If one is not full-time on QUIC, it's very difficult to k= eep up
>> > with all the changes. But now we have a checkpoint to start f= rom, I
>> > feel I will not be wasting people's time if I try to get = involved -
>> > at least I only might say something un-QUIC occasionally, rat= her
>> > than nearly always. This has allowed people who understand ho= w TCP
>> > cold be improved to help with QUIC, when working on QUIC isn&= #39;t their day job.
>> >
>> > Again, Thank you.
>> I like particularly that QUIC only reduces cwnd to 1 after the los= s
>> is confirmed not upon RTO fires. It should be very feasible for TC= P
>> (at least
>> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd re= ductions!
>>
>> Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt= -ids.
>> Google internally uses usec. We wish we could upstream it but RFC =
>> needs to be updated.
>>
>> >
>> >
>> > Bob
>> >
>> >
>> > --
>> > _____________________________________________________________= ___
>> > Bob Briscoe
>> > https://na01.safe= links.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbob
>> > briscoe.net%2F&amp;data=3D02%7C01%7Cpravb%40microsoft.com%7= C3c4d22866
>> > 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%
>> > 7C636776374678321324&amp;sdata=3DT%2BWTEc42VC%2Bz%2BsmMFy= jlm37hmAwfee
>> > buPcuMYlVhgDY%3D&amp;reserved=3D0
>> >
>> > _______________________________________________
>> > tcpm mailing list
>> > tcpm@ietf.= org
>> > https://na01.safe= links.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww
>> > w.i
>> > etf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%4= 0micr
>> > oso
>> > ft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7 >> > cd0
>> > 11db47%7C1%7C0%7C636773207316711149&amp;sdata=3DK667a3IQG= 4rarQ%2FOfAl
>> > yhK
>> > QQ05Cea421rgb64DlEMvs%3D&amp;reserved=3D0
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>>
>> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>> i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40mi= cro
>> s= oft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 >> cd011db47%7C1%7C0%7C636776374678321324&amp;sdata=3D33WxKh5c6qL= 4ln5jerpx
>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserved=3D0
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>> i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40mi= cro
>> s= oft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 >> cd011db47%7C1%7C0%7C636776374678321324&amp;sdata=3D33WxKh5c6qL= 4ln5jerpx
>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserved=3D0
--00000000000074f0a5057a86601b-- From nobody Mon Nov 12 23:13:31 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72C9124BAA for ; Mon, 12 Nov 2018 23:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwxEqd1-qX9W for ; Mon, 12 Nov 2018 23:13:26 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8943812D4E7 for ; Mon, 12 Nov 2018 23:13:25 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id v15-v6so9857564ljh.13 for ; Mon, 12 Nov 2018 23:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8qeexS7WIEkVqF0xapZeFFOd7xqJZOD4VbK/7cbFQZ0=; b=u7s8ngmemhYL6AC2UK5zwpieCeeHFOghnpA4YxmEqBL0vfH19wTKFMyvdxmZY3WAkJ Bme/2y3ApGIEZEIc/KfGI3TGS/SodUakoEQpQX/bqEHovaedCY3VxyOcWf95qJXPcuEs JPiXKZWhbiO0+X0cc6ZzAQpJrYUg+qJECMOXlUyJuvMw6oPEZTRTDAxAdofBGN1ORBwa 1bfLYuDQipYwyX73mh0LwJyyYlunTxQokNAyLjw+AVygogF9tNfLOVMwneSgTtT5MGwS o6GqXYfExd6i3O50MgH5QOIcmAw/c3QeBipcwNrriIaMlHg0gdbpTvKva9jtgQB00qWj 6PmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8qeexS7WIEkVqF0xapZeFFOd7xqJZOD4VbK/7cbFQZ0=; b=Fva37gGY2/3ZY35cAytXOGJhbGMqZOzG+/Y88HmhJe19tka4/riu4PxO2WrQSjEn8j BGCmzCBxqCBoSHLTRl6PkmYeMN4tbjj0nRpAKSZTbQTwMXnSfokeJPJtRiW/W/dTlqEH Ygxo3cKY4ky+mPurKoq0TZ7DPjmT1/XD2CLRXy9bFor55JyGMp9B4xzRHYVKe5VJDmZM Oh1jTZMgR9dcKeraMUp5aUwIgABUXJ3PZadCqJHa5LFJiQ7GDTFlsn1ugjQJ0BFcKQ6A 0RWlLIpoulEEHUw6Z/wC79W0+UvjWgz53IRLG0xUbS1IHjTa+j390Rwd26N2kQ0x1F6w IyPg== X-Gm-Message-State: AGRZ1gIXjtvGa0xeMk47t507EXSK7Veji6vgOUIYGJJXjWhPXMeR1B1B MkZsyxkuUDRXw+ikyAXc7rHiBzp75TS6x/o62ZM= X-Google-Smtp-Source: AJdET5f8VqUOT75saA+AntSZq+HE4ZUZmFe+ZO7FSt++lRZyUmeC97m/AdEiE7nyc0Sb55fUwAJD9tl51sChW40rGL0= X-Received: by 2002:a2e:b04f:: with SMTP id d15-v6mr2682907ljl.3.1542093203532; Mon, 12 Nov 2018 23:13:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Tue, 13 Nov 2018 14:13:12 +0700 Message-ID: To: Praveen Balasubramanian Cc: Yuchung Cheng , Bob Briscoe , Ian Swett , tcpm@ietf.org Content-Type: multipart/alternative; boundary="0000000000009b6ee6057a868d4e" Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 07:13:30 -0000 --0000000000009b6ee6057a868d4e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On what to do with an unconfirmed RTO: So, my thought is that if you've hit an RTO, it's been a REALLY LONG time, because we've gone through TLP(s) by now and failed. (This might change if we decide to combine TLP and RTO, but that's for a later discussion.) It's not fully clear to me what the right responses here are, but some thoughts follow. 1/ If this was an actual increase in the RTT, it would naturally roll into the SRTT and RTTVAR. We might even consider resetting the RTT estimator, but we already know that the EWMA estimator we love takes just a while to catch on, and I don't want to litigate changing the estimator fundamentally here. 2/ Linux fq uses min_rtt IIRC, which shouldn't change as a result of an increase in RTT. This *might* be a good time to kick the min_rtt estimator to pace more conservatively. 3/ I'm not convinced that it makes sense to change the cwnd. It seems clear that an RTT increase with the same BW should increase the cwnd if anything, so it seems reasonable to continue with the same cwnd at least. If the BW changed, hopefully that'll be reflected in a congestion signal, but in the absence of a congestion signal, I think we should keep the cwnd as is. On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian < pravb@microsoft.com> wrote: > Yuchung this might be worth experimenting with and getting more data on. > Maybe there should be some reaction to an unconfirmed RTO even if it is n= ot > reduction all the way to LW? I like Jana's suggestion that the > implementation SHOULD drop the cwnd even for unconfirmed RTO if not pacin= g. > > I checked the latest draft and pacing is a RECOMMENDED. I am noticing tha= t > transport algorithms in Linux and in QUIC are evolving assuming pacing > which is a function usually implemented and configured outside of the > transport. So the transport is potentially making an assumption which may > result in safety issues. For example BBR congestion control may not work > very well if pacing was disabled or misconfigured? I don=E2=80=99t know o= f any > robust solution to this other than build pacing into the transport itself= . > Pacing is also very challenging for low latency flows because of lack of > support for fine grained timers. > > -----Original Message----- > From: Yuchung Cheng > Sent: Monday, November 12, 2018 8:37 AM > To: Jana Iyengar > Cc: Praveen Balasubramanian ; Bob Briscoe < > ietf@bobbriscoe.net>; Ian Swett ; tcpm@ietf.org > Extensions > Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > > On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar wrote: > > Praveen, > > > > The point you're raising -- that we've lost the ack clock after an RTO > > -- is a reasonable point. My argument is that with pacing, cwnd > > reduction is unwarranted because in the extreme case, this collapses > > to restart after idle, where sending at cwnd with pacing is reasonable > I agree w/ Jana as well - the most generic way to treat burst due to > prior_inflight << cwnd is pacing. With QUIC's approach, when RTO fires, > cwnd remains unchanged until the ACK of the first retransmission (i.e. a > probe packet) comes back. Therefore the delay is one RTT and the potentia= l > damage is an additional cwnd-worth of burst. > > Yes the worst case is more aggressive, and it can be too much for DC > incast case if pacing isn't supported - one idea is to selective enable > that if RTT variance is very large vs RTT. > > > > > The draft does not say that a sender should reduce the cwnd if it is > > not pacing, which we should add. Does that make sense? > > > > - jana > > > > On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian > > wrote: > >> > >> Yuchung I brought that difference up in an email to the quic wg > >> earlier this week. > >> > >> In app send limited case, inflight could be very small compared to cwn= d. > >> So in QUIC there is potential to send a burst out after a long idle > >> period (with outstanding data) where TCP wouldn't. The draft claims > >> this is okay to do because RTO may have been a result of RTT increase > >> instead of loss. Is there data to suggest on which side we should > >> err? i.e. data on what are the chances that an RTO is due to an RTT > increase versus loss. > >> > >> Do you see any safety concerns with delayed reduction of cwnd in case > >> where the RTO is not spurious? > >> > >> -----Original Message----- > >> From: tcpm On Behalf Of Yuchung Cheng > >> Sent: Thursday, November 8, 2018 4:38 PM > >> To: Bob Briscoe > >> Cc: Ian Swett ; tcpm IETF list > >> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > >> > >> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe > wrote: > >> > > >> > I just wanted to thank Jana for explaining QUIC loss recovery to us > >> > (and QUIC CC as far as it goes). > >> > And thank you Jana, Ian, the chairs of both WGs (and anyone else > >> > involved) for setting it up. > >> > > >> > If one is not full-time on QUIC, it's very difficult to keep up > >> > with all the changes. But now we have a checkpoint to start from, I > >> > feel I will not be wasting people's time if I try to get involved - > >> > at least I only might say something un-QUIC occasionally, rather > >> > than nearly always. This has allowed people who understand how TCP > >> > cold be improved to help with QUIC, when working on QUIC isn't their > day job. > >> > > >> > Again, Thank you. > >> I like particularly that QUIC only reduces cwnd to 1 after the loss > >> is confirmed not upon RTO fires. It should be very feasible for TCP > >> (at least > >> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd reductions= ! > >> > >> Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt-ids= . > >> Google internally uses usec. We wish we could upstream it but RFC > >> needs to be updated. > >> > >> > > >> > > >> > Bob > >> > > >> > > >> > -- > >> > ________________________________________________________________ > >> > Bob Briscoe > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbo= b > >> > briscoe.net%2F&data=3D02%7C01%7Cpravb%40microsoft.com%7C3c4d2286= 6 > >> > 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > >> > 7C636776374678321324&sdata=3DT%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfe= e > >> > buPcuMYlVhgDY%3D&reserved=3D0 > >> > > >> > _______________________________________________ > >> > tcpm mailing list > >> > tcpm@ietf.org > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= w > >> > w.i > >> > etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40mic= r > >> > oso > >> > ft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7 > >> > cd0 > >> > 11db47%7C1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfA= l > >> > yhK > >> > QQ05Cea421rgb64DlEMvs%3D&reserved=3D0 > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > >> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micr= o > >> soft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 > >> cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerp= x > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > >> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micr= o > >> soft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 > >> cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerp= x > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 > --0000000000009b6ee6057a868d4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On what to do with an unconfirmed RTO: So, my thought= is that if you've hit an RTO, it's been a REALLY LONG time, becaus= e we've gone through TLP(s) by now and failed. (This might change if we= decide to combine TLP and RTO, but that's for a later discussion.)=C2= =A0 It's not fully clear to me what the right responses here are, but s= ome thoughts follow.

1/ If this was an actual incr= ease in the RTT, it would naturally roll into the SRTT and RTTVAR. We might= even consider resetting the RTT estimator, but we already know that the EW= MA estimator we love takes just a while to catch on, and I don't want t= o litigate changing the estimator fundamentally here.

<= div>2/ Linux fq uses min_rtt IIRC, which shouldn't change as a result o= f an increase in RTT. This *might* be a good time to kick the min_rtt estim= ator to pace more conservatively.

3/ I'm not c= onvinced that it makes sense to change the cwnd. It seems clear that an RTT= increase with the same BW should increase the cwnd if anything, so it seem= s reasonable to continue with the same cwnd at least. If the BW changed, ho= pefully that'll be reflected in a congestion signal, but in the absence= of a congestion signal, I think we should keep the cwnd as is.
<= br>

On Tue, Nov = 13, 2018 at 12:35 AM Praveen Balasubramanian <pravb@microsoft.com> wrote:
Yuchung this might be worth experimenting with and getting mo= re data on. Maybe there should be some reaction to an unconfirmed RTO even = if it is not reduction all the way to LW? I like Jana's suggestion that= the implementation SHOULD drop the cwnd even for unconfirmed RTO if not pa= cing.

I checked the latest draft and pacing is a RECOMMENDED. I am noticing that = transport algorithms in Linux and in QUIC are evolving assuming pacing whic= h is a function usually implemented and configured outside of the transport= . So the transport is potentially making an assumption which may result in = safety issues. For example BBR congestion control may not work very well if= pacing was disabled or misconfigured? I don=E2=80=99t know of any robust s= olution to this other than build pacing into the transport itself. Pacing i= s also very challenging for low latency flows because of lack of support fo= r fine grained timers.

-----Original Message-----
From: Yuchung Cheng <ycheng@google.com>
Sent: Monday, November 12, 2018 8:37 AM
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; Bob Briscoe <ietf@bobbriscoe.net>; Ian S= wett <ianswett@= google.com>; tcpm= @ietf.org Extensions <tcpm@ietf.org>
Subject: Re: [tcpm] Thank you for the QUIC session in tcpm

On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar <jri.ietf@gmail.com> wrote:
> Praveen,
>
> The point you're raising -- that we've lost the ack clock afte= r an RTO
> -- is a reasonable point. My argument is that with pacing, cwnd
> reduction is unwarranted because in the extreme case, this collapses <= br> > to restart after idle, where sending at cwnd with pacing is reasonable=
I agree w/ Jana as well - the most generic way to treat burst due to prior_= inflight << cwnd is pacing. With QUIC's approach, when RTO fires,= cwnd remains unchanged until the ACK of the first retransmission (i.e. a p= robe packet) comes back. Therefore the delay is one RTT and the potential d= amage is an additional cwnd-worth of burst.

Yes the worst case is more aggressive, and it can be too much for DC incast= case if pacing isn't supported - one idea is to selective enable that = if RTT variance is very large vs RTT.

>
> The draft does not say that a sender should reduce the cwnd if it is <= br> > not pacing, which we should add. Does that make sense?
>
> - jana
>
> On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian
> <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:
>>
>> Yuchung I brought that difference up in an email to the quic wg >> earlier this week.
>>
>> In app send limited case, inflight could be very small compared to= cwnd.
>> So in QUIC there is potential to send a burst out after a long idl= e
>> period (with outstanding data) where TCP wouldn't. The draft c= laims
>> this is okay to do because RTO may have been a result of RTT incre= ase
>> instead of loss. Is there data to suggest on which side we should =
>> err? i.e. data on what are the chances that an RTO is due to an RT= T increase versus loss.
>>
>> Do you see any safety concerns with delayed reduction of cwnd in c= ase
>> where the RTO is not spurious?
>>
>> -----Original Message-----
>> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yuchung Cheng
>> Sent: Thursday, November 8, 2018 4:38 PM
>> To: Bob Briscoe <ietf@bobbriscoe.net>
>> Cc: Ian Swett <ianswett@google.com>; tcpm IETF list <tcpm@ietf.org>
>> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm
>>
>> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote: >> >
>> > I just wanted to thank Jana for explaining QUIC loss recovery= to us
>> > (and QUIC CC as far as it goes).
>> > And thank you Jana, Ian, the chairs of both WGs (and anyone e= lse
>> > involved) for setting it up.
>> >
>> > If one is not full-time on QUIC, it's very difficult to k= eep up
>> > with all the changes. But now we have a checkpoint to start f= rom, I
>> > feel I will not be wasting people's time if I try to get = involved -
>> > at least I only might say something un-QUIC occasionally, rat= her
>> > than nearly always. This has allowed people who understand ho= w TCP
>> > cold be improved to help with QUIC, when working on QUIC isn&= #39;t their day job.
>> >
>> > Again, Thank you.
>> I like particularly that QUIC only reduces cwnd to 1 after the los= s
>> is confirmed not upon RTO fires. It should be very feasible for TC= P
>> (at least
>> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd re= ductions!
>>
>> Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt= -ids.
>> Google internally uses usec. We wish we could upstream it but RFC =
>> needs to be updated.
>>
>> >
>> >
>> > Bob
>> >
>> >
>> > --
>> > _____________________________________________________________= ___
>> > Bob Briscoe
>> > https://na01.safe= links.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbob
>> > briscoe.net%2F&amp;data=3D02%7C01%7Cpravb%40microsoft.com%7= C3c4d22866
>> > 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%
>> > 7C636776374678321324&amp;sdata=3DT%2BWTEc42VC%2Bz%2BsmMFy= jlm37hmAwfee
>> > buPcuMYlVhgDY%3D&amp;reserved=3D0
>> >
>> > _______________________________________________
>> > tcpm mailing list
>> > tcpm@ietf.= org
>> > https://na01.safe= links.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww
>> > w.i
>> > etf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%4= 0micr
>> > oso
>> > ft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7 >> > cd0
>> > 11db47%7C1%7C0%7C636773207316711149&amp;sdata=3DK667a3IQG= 4rarQ%2FOfAl
>> > yhK
>> > QQ05Cea421rgb64DlEMvs%3D&amp;reserved=3D0
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>>
>> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>> i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40mi= cro
>> s= oft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 >> cd011db47%7C1%7C0%7C636776374678321324&amp;sdata=3D33WxKh5c6qL= 4ln5jerpx
>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserved=3D0
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>> i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40mi= cro
>> s= oft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 >> cd011db47%7C1%7C0%7C636776374678321324&amp;sdata=3D33WxKh5c6qL= 4ln5jerpx
>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserved=3D0
--0000000000009b6ee6057a868d4e-- From nobody Tue Nov 13 09:03:22 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39409128B14; Tue, 13 Nov 2018 09:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owlA52cGTri1; Tue, 13 Nov 2018 09:03:06 -0800 (PST) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730116.outbound.protection.outlook.com [40.107.73.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BBB127332; Tue, 13 Nov 2018 09:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gs8j/SbvMdwhlJ/UhV9yAb8WNw/DU8fVPK7M2AIn1gI=; b=a/S8KcTHx6047IxE0zpMeUU5UX9ataT/23eRAQ79bQgXykYMKRqdeqt9XXeGvS+wz2HP3CNX9x07/g5N8d0kR9AteXeYVLWdX+Oj9mr3AUxSZRvkwIVHZNyY2e8Ie+XvQFSFQiYBdzbczckTNNd5V/deUKSfgzYAOMeY2ZrKP6I= Received: from CY4PR22MB0983.namprd22.prod.outlook.com (10.171.171.20) by CY4PR22MB0197.namprd22.prod.outlook.com (10.169.186.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.21; Tue, 13 Nov 2018 17:03:01 +0000 Received: from CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::706e:6d82:cc25:531f]) by CY4PR22MB0983.namprd22.prod.outlook.com ([fe80::706e:6d82:cc25:531f%10]) with mapi id 15.20.1294.045; Tue, 13 Nov 2018 17:03:01 +0000 From: Mike Bishop To: Bob Briscoe , "quic-chairs@ietf.org" , "tcpm-chairs@ietf.org" , Jana Iyengar , Ian Swett CC: tcpm IETF list , QUIC IETF mailing list Thread-Topic: Thank you for the QUIC session in tcpm Thread-Index: AQHUd1ROy5gMjHpEPkq3vojU1r0IT6VN9rug Date: Tue, 13 Nov 2018 17:03:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:701:29d3:1d08:ae57:dba] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR22MB0197; 6:TWWaWhF+gVQVmsyf2FL6aA5DtRqrJ00b92eA69EvzhaNGmPgpovdQa0D6VkeOh6T8PJwLdyHBp8I0bYWqc6Q/LmG692G+hjvkujJIPgmuxkT/Ahi7Tx6cY2woJuHBpspX2iJv64bf4S0+zDRgDLBOZ3gzvaxv+Sv8/n53s4oCUmcFjkknqLvzs2MmES78so2U70BPlC+XNqfkQtGOYtlQcjx/d9IZSSqKoZA7ePJonzoeRPZw7KM3IZGpzFJq+l1VFFARyjI+umLkBQzGu6p/IUdK/3ylShVyVOrcr8Bhc6QEtxeZz5Eq/swDfyh+LM2ot0aFmje0dTKQHFR9yfrsI7Pe+xnAVTT9MTDXXePQABHzcqZm8b/wY9yjT/3Ya/qUflt6l2T4v5kbwNYEyYRXPSLbWRtf8bYHAu2fdMe/7GPE81Vw+1qY3pzRKTQ0nzn4XDTCO7WtUPS4Z1D7PgFVA==; 5:vRe4kY8ILQyaLwPMmTcaT27yC0zm+XoStNvFXjgQYo3LRh8Mp7XtziSkiUoBJoo7eu8AXOAg7m4nL8Gy3qDeGN+ZORbyvWzXu0jgMxUJwhnUHKVUguPMocwO1NjiEAd75H+EmZAm3w1QZyg0HTFTfGWfOji/Pt+01OrSQGXdqpU=; 7:dl2pYmooYqO+JyXXk3wu7Bka/l4ij3/k229m+i91xLWcmRhiBBjlEiQ1eNW4DTyJSnkoqdDq0/Elp/yyfkAoT9DEMwT2jC1RZOtQDkG+aPnS4zbvtP19wYFjfzpKBTEHRcqqp9w+RtC/bB09P2HGZg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8bf3237d-e8f9-447d-137c-08d64989def0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390060)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0197; x-ms-traffictypediagnostic: CY4PR22MB0197: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(211936372134217)(153496737603132); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231406)(944501410)(4982022)(52105112)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(2016111802025)(6043046)(201708071742011)(7699051)(76991095); SRVR:CY4PR22MB0197; BCL:0; PCL:0; RULEID:; SRVR:CY4PR22MB0197; x-forefront-prvs: 085551F5A8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(136003)(346002)(396003)(366004)(39830400003)(376002)(13464003)(189003)(199004)(74316002)(102836004)(6306002)(11346002)(53936002)(9686003)(55016002)(53546011)(446003)(345774005)(6116002)(6506007)(966005)(186003)(8676002)(99286004)(33656002)(316002)(2906002)(53376002)(6246003)(110136005)(106356001)(508600001)(76176011)(46003)(105586002)(14454004)(6436002)(5660300001)(74482002)(7696005)(97736004)(305945005)(256004)(68736007)(4326008)(7736002)(25786009)(2900100001)(71200400001)(2501003)(71190400001)(81166006)(8936002)(81156014)(229853002)(476003)(486006)(2201001)(54906003)(39060400002)(86362001)(336755003)(18886065003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR22MB0197; H:CY4PR22MB0983.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: Bt6kNUMlOLhSQ1J90Btu/ZKn5QD6K6jtvHziTGnyqigsmV1ZjWgj0EdKyEdaRkJWzSpFYezxOwCUNCTlkjq905eqSQo2ZXxWDOK3z73nzSjkJIXyBiUFT21RNOsYvVjDqJO4pACQwH0UDIDOm9MuZ5ZoD/Sefa+Hl5LEY9/Bq4nAY8yhq4CCV+SpwwbAlhyqhiVl0Y8IVPtbQ/iqN2r25phOKmL1T879pBIv7sStZa04cDu4VAW6VhRWEIO1Qmhab1MasCXUPAEZSerz59r9XOQcx3k50wVzmvUTlKf8XdmZlE+aNFXKM9Vkrih44pZTsRx9tcGFHNM37ARjqNnDYVV8ggcApxVr48PmdObcjcE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 8bf3237d-e8f9-447d-137c-08d64989def0 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2018 17:03:01.7775 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0197 Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 17:03:14 -0000 V2Ugd2VsY29tZSB5b3VyIGludm9sdmVtZW50IQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQm9iIEJy aXNjb2UNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciA4LCAyMDE4IDM6MTUgQU0NClRvOiBxdWlj LWNoYWlyc0BpZXRmLm9yZzsgdGNwbS1jaGFpcnNAaWV0Zi5vcmc7IEphbmEgSXllbmdhciA8anJp LmlldGZAZ21haWwuY29tPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPg0KQ2M6IHRj cG0gSUVURiBsaXN0IDx0Y3BtQGlldGYub3JnPjsgUVVJQyBJRVRGIG1haWxpbmcgbGlzdCA8cXVp Y0BpZXRmLm9yZz4NClN1YmplY3Q6IFRoYW5rIHlvdSBmb3IgdGhlIFFVSUMgc2Vzc2lvbiBpbiB0 Y3BtDQoNCkkganVzdCB3YW50ZWQgdG8gdGhhbmsgSmFuYSBmb3IgZXhwbGFpbmluZyBRVUlDIGxv c3MgcmVjb3ZlcnkgdG8gdXMgKGFuZCBRVUlDIENDIGFzIGZhciBhcyBpdCBnb2VzKS4NCkFuZCB0 aGFuayB5b3UgSmFuYSwgSWFuLCB0aGUgY2hhaXJzIG9mIGJvdGggV0dzIChhbmQgYW55b25lIGVs c2UNCmludm9sdmVkKSBmb3Igc2V0dGluZyBpdCB1cC4NCg0KSWYgb25lIGlzIG5vdCBmdWxsLXRp bWUgb24gUVVJQywgaXQncyB2ZXJ5IGRpZmZpY3VsdCB0byBrZWVwIHVwIHdpdGggYWxsIHRoZSBj aGFuZ2VzLiBCdXQgbm93IHdlIGhhdmUgYSBjaGVja3BvaW50IHRvIHN0YXJ0IGZyb20sIEkgZmVl bCBJIHdpbGwgbm90IGJlIHdhc3RpbmcgcGVvcGxlJ3MgdGltZSBpZiBJIHRyeSB0byBnZXQgaW52 b2x2ZWQgLSBhdCBsZWFzdCBJIG9ubHkgbWlnaHQgc2F5IHNvbWV0aGluZyB1bi1RVUlDIG9jY2Fz aW9uYWxseSwgcmF0aGVyIHRoYW4gbmVhcmx5IGFsd2F5cy4gDQpUaGlzIGhhcyBhbGxvd2VkIHBl b3BsZSB3aG8gdW5kZXJzdGFuZCBob3cgVENQIGNvbGQgYmUgaW1wcm92ZWQgdG8gaGVscCB3aXRo IFFVSUMsIHdoZW4gd29ya2luZyBvbiBRVUlDIGlzbid0IHRoZWlyIGRheSBqb2IuDQoNCkFnYWlu LCBUaGFuayB5b3UuDQoNCg0KQm9iDQoNCg0KLS0NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJvYiBCcmlzY29lICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29lLm5ldC8NCg0K From nobody Tue Nov 13 11:57:38 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBDB130DE0 for ; Tue, 13 Nov 2018 11:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.848 X-Spam-Level: X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bMfgqDb2zXl for ; Tue, 13 Nov 2018 11:57:32 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690137.outbound.protection.outlook.com [40.107.69.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0085C12D4EA for ; Tue, 13 Nov 2018 11:57:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jLa0ICcraGZm7HQFggjxoQY++VrlyV02QHPTGfPAtv0=; b=D+cuT93tpGok4ECqQ/w5bpRje+MUugIzqCBtkm63+p4th+1Zd+UEHsLiud12/qw4EkhtTzuiai5ipep0xRlDslBljsyUm4F9ZVkGG1iON16YN6QIVkMsJVz9apS3rznBk0UStbbrPSVTYKkluPhgN/ISmUuZuVOJaEmYcrlTrjM= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB1019.namprd21.prod.outlook.com (52.132.146.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.2; Tue, 13 Nov 2018 19:57:27 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a%4]) with mapi id 15.20.1361.004; Tue, 13 Nov 2018 19:57:27 +0000 From: Praveen Balasubramanian To: Jana Iyengar CC: Yuchung Cheng , Bob Briscoe , Ian Swett , "tcpm@ietf.org" Thread-Topic: [tcpm] Thank you for the QUIC session in tcpm Thread-Index: AQHUd1RO08g6biwnTkKIBqYAsYD8EKVGmkCAgAAPe9CABWndAIAASaGAgAAPTgCAAOV9AIAAqJBA Date: Tue, 13 Nov 2018 19:57:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:f:c1d5:5925:c0a1:c266] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR2101MB1019; 6:ELDxvI+bpqhclgMlOnFqbuwFh1H3pRTlUwVyowWIT0IKM9HBTWiWJzH194VdjJieN5RLZgEsDbDzIg0o0lQrUGcNO4iINnt+wLLTeilAmSf2bJNsB1/gzJLCWCcNXmB4CUh8xqi8fWVpgtaLN/a/v5pjGf5XDY1ulXyjPZrVAoPFOse3/dQgK8a1xoNvMtYCMrC9kxW/8V7L4nQLUwxe1X1Lqgq/1liLer1LRUK7XSuS2bzRGKvpmgp2u8B5Shvd7Rzecml+3KTH933l6bhGyM2dWnGJU2jfwA6NTfpcZTw9cXEBVjNr/ecP8t+UyjB269QEqbrqO109NSzq8TE9AQpPEFnBTtQWuzyr0JtiUElCaBU61ahaGR7cahBQfuukNbT9BV8DsodXJ9jtEYbSUHlJFfL1/elP0AWPoV5/MqJNkJGm1PsgqIQr3VziDcFcRxE8/DxqlBGVD6hRSuOysA==; 5:0fA2R5Rt//eCLycLHOovrpccKWmUjD6rMFyC087r4XC7Xr2QwJe0LSrtHvcmpAGoLjH7ZxvcOixujVisl0kOZVJT8Eap3jH7vde/7cp09tvLmnLqEpTg8B7b/jOwPDKBpCDdjL9fLJNWaKtjMf2cOR0ChslMekC8AQQ38/CVGRc=; 7:7hgbKkgz8RsL/JJBBjH7yOqzsNvSuzU7S+1rLsDlgB7Hfl0djm9kacSd9WRsFRSqjDLbOIj3JVX9tqwRjv4L3604RhA4h/P8uUnyfeOf8aeyC65kevOZViBesCGI0txObp2pb8vgz/IqZPoSzwh7Vw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ec9a8626-b715-4ab5-29a4-08d649a23caf x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390060)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MW2PR2101MB1019; x-ms-traffictypediagnostic: MW2PR2101MB1019: x-ms-exchange-purlcount: 18 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(8220035)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231409)(944501410)(4982022)(2018427008)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:MW2PR2101MB1019; BCL:0; PCL:0; RULEID:; SRVR:MW2PR2101MB1019; x-forefront-prvs: 085551F5A8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(136003)(396003)(39860400002)(189003)(199004)(13464003)(55016002)(6306002)(6436002)(9686003)(256004)(54896002)(86612001)(236005)(14454004)(102836004)(71200400001)(86362001)(229853002)(71190400001)(81156014)(14444005)(8676002)(81166006)(97736004)(2900100001)(74316002)(8936002)(5660300001)(478600001)(966005)(53936002)(68736007)(6246003)(6916009)(186003)(46003)(606006)(7736002)(39060400002)(105586002)(486006)(53546011)(6506007)(11346002)(476003)(4326008)(10090500001)(446003)(76176011)(2906002)(22452003)(316002)(106356001)(25786009)(54906003)(345774005)(6116002)(33656002)(93886005)(99286004)(8990500004)(7696005)(10290500003)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB1019; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: mdb1I+Ovycku8jrr+SuT5Z5v/wccLSGJ1GqJHMU5rOyWSRzUD+jERzhUttyH/IXdwQc73oUfePTfOhsdqDx7UB/ItIhSABiWBvlEoHzE5ElBidf4RW61Cl0mSak1h39t+TCw+tKyslBTMjk+Qck0qZKEJ0Jzov4mWRfb0phNm8IlFyGYgxgSCtHT9QcNPabnwcaVuQtELw5Qo5fLr6f6oj+8ANvJ5N1f/gVmUsz3jrt3xqkUTrZJwnUZ+LItT9SFcawVsHhfDWtxczxkLoCv+10YrAURQkW3uIrXF0Cw1jMLxOQcmCp4j5Fr7XzCngGZ0Er+QTrmkHf91IyL/hvbVUy7GINEWngVlIdQJ4fNJRY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MW2PR2101MB1049E1E97815AA80CDEEFF88B6C20MW2PR2101MB1049_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec9a8626-b715-4ab5-29a4-08d649a23caf X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2018 19:57:27.0235 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1019 Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2018 19:57:36 -0000 --_000_MW2PR2101MB1049E1E97815AA80CDEEFF88B6C20MW2PR2101MB1049_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgYWxsIGdyZWF0IGFzc3VtaW5nIHRoYXQgUlRUIGluY3JlYXNlIHdhcyB0aGUgcmVh c29uIGZvciB0aGUgcHJvbG9uZ2VkIHNpbGVuY2UuIEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBt ZWFzdXJlIGJvdGggaW5jaWRlbmNlcyBvZiBzcHVyaW91cyBSVE9zIGFuZCBtZWFzdXJlZCBSVFQg aW5jcmVhc2VzIHBvc3Qgc3B1cmlvdXMgUlRPcywgYW5kIHRoYXQgc2hvdWxkIHRlbGwgdXMgd2hp Y2ggc2lkZSB3ZSBzaG91bGQgZXJyIG9uLg0KDQpGb3Igc2FmZXR5IHJlYXNvbnMsIHNob3VsZCB3 ZSBwdXQgaW4gdGhlIHRleHQgZm9yIHJlZHVjaW5nIHRoZSBjd25kIGluIGFic2VuY2Ugb2YgcGFj aW5nIHRvIGtlZXAgY29uc2lzdGVuY3kgd2l0aCBUQ1AgYmVoYXZpb3IsIGF0IGxlYXN0IHVudGls IGRhdGEgc2hvd3Mgb3RoZXJ3aXNlPyBJIHdvcnJ5IHRoYXQgbW9zdCBhcHAgZGV2ZWxvcGVycyB3 aXRob3V0IHRyYW5zcG9ydCBiYWNrZ3JvdW5kIHdpbGwgbm90IGhhdmUgdGhlIGV4cGVydGlzZSB0 byByZWFsaXplIHRoZSBpc3N1ZXMgY2F1c2VkIGJ5IGJ1cnN0IGFmdGVyIGlkbGUuIFRoZSBvdGhl ciBvcHRpb24gaXMgdG8gbWFrZSBwYWNpbmcgbWFuZGF0b3J5IGluIHRoZSBkcmFmdC4NCg0KRnJv bTogSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb20+DQpTZW50OiBNb25kYXksIE5vdmVt YmVyIDEyLCAyMDE4IDExOjEzIFBNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi QG1pY3Jvc29mdC5jb20+DQpDYzogWXVjaHVuZyBDaGVuZyA8eWNoZW5nQGdvb2dsZS5jb20+OyBC b2IgQnJpc2NvZSA8aWV0ZkBib2JicmlzY29lLm5ldD47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29v Z2xlLmNvbT47IHRjcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdGNwbV0gVGhhbmsgeW91IGZv ciB0aGUgUVVJQyBzZXNzaW9uIGluIHRjcG0NCg0KT24gd2hhdCB0byBkbyB3aXRoIGFuIHVuY29u ZmlybWVkIFJUTzogU28sIG15IHRob3VnaHQgaXMgdGhhdCBpZiB5b3UndmUgaGl0IGFuIFJUTywg aXQncyBiZWVuIGEgUkVBTExZIExPTkcgdGltZSwgYmVjYXVzZSB3ZSd2ZSBnb25lIHRocm91Z2gg VExQKHMpIGJ5IG5vdyBhbmQgZmFpbGVkLiAoVGhpcyBtaWdodCBjaGFuZ2UgaWYgd2UgZGVjaWRl IHRvIGNvbWJpbmUgVExQIGFuZCBSVE8sIGJ1dCB0aGF0J3MgZm9yIGEgbGF0ZXIgZGlzY3Vzc2lv bi4pICBJdCdzIG5vdCBmdWxseSBjbGVhciB0byBtZSB3aGF0IHRoZSByaWdodCByZXNwb25zZXMg aGVyZSBhcmUsIGJ1dCBzb21lIHRob3VnaHRzIGZvbGxvdy4NCg0KMS8gSWYgdGhpcyB3YXMgYW4g YWN0dWFsIGluY3JlYXNlIGluIHRoZSBSVFQsIGl0IHdvdWxkIG5hdHVyYWxseSByb2xsIGludG8g dGhlIFNSVFQgYW5kIFJUVFZBUi4gV2UgbWlnaHQgZXZlbiBjb25zaWRlciByZXNldHRpbmcgdGhl IFJUVCBlc3RpbWF0b3IsIGJ1dCB3ZSBhbHJlYWR5IGtub3cgdGhhdCB0aGUgRVdNQSBlc3RpbWF0 b3Igd2UgbG92ZSB0YWtlcyBqdXN0IGEgd2hpbGUgdG8gY2F0Y2ggb24sIGFuZCBJIGRvbid0IHdh bnQgdG8gbGl0aWdhdGUgY2hhbmdpbmcgdGhlIGVzdGltYXRvciBmdW5kYW1lbnRhbGx5IGhlcmUu DQoNCjIvIExpbnV4IGZxIHVzZXMgbWluX3J0dCBJSVJDLCB3aGljaCBzaG91bGRuJ3QgY2hhbmdl IGFzIGEgcmVzdWx0IG9mIGFuIGluY3JlYXNlIGluIFJUVC4gVGhpcyAqbWlnaHQqIGJlIGEgZ29v ZCB0aW1lIHRvIGtpY2sgdGhlIG1pbl9ydHQgZXN0aW1hdG9yIHRvIHBhY2UgbW9yZSBjb25zZXJ2 YXRpdmVseS4NCg0KMy8gSSdtIG5vdCBjb252aW5jZWQgdGhhdCBpdCBtYWtlcyBzZW5zZSB0byBj aGFuZ2UgdGhlIGN3bmQuIEl0IHNlZW1zIGNsZWFyIHRoYXQgYW4gUlRUIGluY3JlYXNlIHdpdGgg dGhlIHNhbWUgQlcgc2hvdWxkIGluY3JlYXNlIHRoZSBjd25kIGlmIGFueXRoaW5nLCBzbyBpdCBz ZWVtcyByZWFzb25hYmxlIHRvIGNvbnRpbnVlIHdpdGggdGhlIHNhbWUgY3duZCBhdCBsZWFzdC4g SWYgdGhlIEJXIGNoYW5nZWQsIGhvcGVmdWxseSB0aGF0J2xsIGJlIHJlZmxlY3RlZCBpbiBhIGNv bmdlc3Rpb24gc2lnbmFsLCBidXQgaW4gdGhlIGFic2VuY2Ugb2YgYSBjb25nZXN0aW9uIHNpZ25h bCwgSSB0aGluayB3ZSBzaG91bGQga2VlcCB0aGUgY3duZCBhcyBpcy4NCg0KDQpPbiBUdWUsIE5v diAxMywgMjAxOCBhdCAxMjozNSBBTSBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWlj cm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KWXVjaHVuZyB0 aGlzIG1pZ2h0IGJlIHdvcnRoIGV4cGVyaW1lbnRpbmcgd2l0aCBhbmQgZ2V0dGluZyBtb3JlIGRh dGEgb24uIE1heWJlIHRoZXJlIHNob3VsZCBiZSBzb21lIHJlYWN0aW9uIHRvIGFuIHVuY29uZmly bWVkIFJUTyBldmVuIGlmIGl0IGlzIG5vdCByZWR1Y3Rpb24gYWxsIHRoZSB3YXkgdG8gTFc/IEkg bGlrZSBKYW5hJ3Mgc3VnZ2VzdGlvbiB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgZHJv cCB0aGUgY3duZCBldmVuIGZvciB1bmNvbmZpcm1lZCBSVE8gaWYgbm90IHBhY2luZy4NCg0KSSBj aGVja2VkIHRoZSBsYXRlc3QgZHJhZnQgYW5kIHBhY2luZyBpcyBhIFJFQ09NTUVOREVELiBJIGFt IG5vdGljaW5nIHRoYXQgdHJhbnNwb3J0IGFsZ29yaXRobXMgaW4gTGludXggYW5kIGluIFFVSUMg YXJlIGV2b2x2aW5nIGFzc3VtaW5nIHBhY2luZyB3aGljaCBpcyBhIGZ1bmN0aW9uIHVzdWFsbHkg aW1wbGVtZW50ZWQgYW5kIGNvbmZpZ3VyZWQgb3V0c2lkZSBvZiB0aGUgdHJhbnNwb3J0LiBTbyB0 aGUgdHJhbnNwb3J0IGlzIHBvdGVudGlhbGx5IG1ha2luZyBhbiBhc3N1bXB0aW9uIHdoaWNoIG1h eSByZXN1bHQgaW4gc2FmZXR5IGlzc3Vlcy4gRm9yIGV4YW1wbGUgQkJSIGNvbmdlc3Rpb24gY29u dHJvbCBtYXkgbm90IHdvcmsgdmVyeSB3ZWxsIGlmIHBhY2luZyB3YXMgZGlzYWJsZWQgb3IgbWlz Y29uZmlndXJlZD8gSSBkb27igJl0IGtub3cgb2YgYW55IHJvYnVzdCBzb2x1dGlvbiB0byB0aGlz IG90aGVyIHRoYW4gYnVpbGQgcGFjaW5nIGludG8gdGhlIHRyYW5zcG9ydCBpdHNlbGYuIFBhY2lu ZyBpcyBhbHNvIHZlcnkgY2hhbGxlbmdpbmcgZm9yIGxvdyBsYXRlbmN5IGZsb3dzIGJlY2F1c2Ug b2YgbGFjayBvZiBzdXBwb3J0IGZvciBmaW5lIGdyYWluZWQgdGltZXJzLg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWXVjaHVuZyBDaGVuZyA8eWNoZW5nQGdvb2dsZS5jb208 bWFpbHRvOnljaGVuZ0Bnb29nbGUuY29tPj4NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTIsIDIw MTggODozNyBBTQ0KVG86IEphbmEgSXllbmdhciA8anJpLmlldGZAZ21haWwuY29tPG1haWx0bzpq cmkuaWV0ZkBnbWFpbC5jb20+Pg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBt aWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj47IEJvYiBCcmlzY29lIDxp ZXRmQGJvYmJyaXNjb2UubmV0PG1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0Pj47IElhbiBTd2V0 dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+OyB0Y3Bt QGlldGYub3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPiBFeHRlbnNpb25zIDx0Y3BtQGlldGYub3Jn PG1haWx0bzp0Y3BtQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbdGNwbV0gVGhhbmsgeW91IGZv ciB0aGUgUVVJQyBzZXNzaW9uIGluIHRjcG0NCg0KT24gTW9uLCBOb3YgMTIsIDIwMTggYXQgNDox MyBBTSwgSmFuYSBJeWVuZ2FyIDxqcmkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmpyaS5pZXRmQGdt YWlsLmNvbT4+IHdyb3RlOg0KPiBQcmF2ZWVuLA0KPg0KPiBUaGUgcG9pbnQgeW91J3JlIHJhaXNp bmcgLS0gdGhhdCB3ZSd2ZSBsb3N0IHRoZSBhY2sgY2xvY2sgYWZ0ZXIgYW4gUlRPDQo+IC0tIGlz IGEgcmVhc29uYWJsZSBwb2ludC4gTXkgYXJndW1lbnQgaXMgdGhhdCB3aXRoIHBhY2luZywgY3du ZA0KPiByZWR1Y3Rpb24gaXMgdW53YXJyYW50ZWQgYmVjYXVzZSBpbiB0aGUgZXh0cmVtZSBjYXNl LCB0aGlzIGNvbGxhcHNlcw0KPiB0byByZXN0YXJ0IGFmdGVyIGlkbGUsIHdoZXJlIHNlbmRpbmcg YXQgY3duZCB3aXRoIHBhY2luZyBpcyByZWFzb25hYmxlDQpJIGFncmVlIHcvIEphbmEgYXMgd2Vs bCAtIHRoZSBtb3N0IGdlbmVyaWMgd2F5IHRvIHRyZWF0IGJ1cnN0IGR1ZSB0byBwcmlvcl9pbmZs aWdodCA8PCBjd25kIGlzIHBhY2luZy4gV2l0aCBRVUlDJ3MgYXBwcm9hY2gsIHdoZW4gUlRPIGZp cmVzLCBjd25kIHJlbWFpbnMgdW5jaGFuZ2VkIHVudGlsIHRoZSBBQ0sgb2YgdGhlIGZpcnN0IHJl dHJhbnNtaXNzaW9uIChpLmUuIGEgcHJvYmUgcGFja2V0KSBjb21lcyBiYWNrLiBUaGVyZWZvcmUg dGhlIGRlbGF5IGlzIG9uZSBSVFQgYW5kIHRoZSBwb3RlbnRpYWwgZGFtYWdlIGlzIGFuIGFkZGl0 aW9uYWwgY3duZC13b3J0aCBvZiBidXJzdC4NCg0KWWVzIHRoZSB3b3JzdCBjYXNlIGlzIG1vcmUg YWdncmVzc2l2ZSwgYW5kIGl0IGNhbiBiZSB0b28gbXVjaCBmb3IgREMgaW5jYXN0IGNhc2UgaWYg cGFjaW5nIGlzbid0IHN1cHBvcnRlZCAtIG9uZSBpZGVhIGlzIHRvIHNlbGVjdGl2ZSBlbmFibGUg dGhhdCBpZiBSVFQgdmFyaWFuY2UgaXMgdmVyeSBsYXJnZSB2cyBSVFQuDQoNCj4NCj4gVGhlIGRy YWZ0IGRvZXMgbm90IHNheSB0aGF0IGEgc2VuZGVyIHNob3VsZCByZWR1Y2UgdGhlIGN3bmQgaWYg aXQgaXMNCj4gbm90IHBhY2luZywgd2hpY2ggd2Ugc2hvdWxkIGFkZC4gRG9lcyB0aGF0IG1ha2Ug c2Vuc2U/DQo+DQo+IC0gamFuYQ0KPg0KPiBPbiBGcmksIE5vdiA5LCAyMDE4IGF0IDg6MzQgQU0g UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NCj4gPHByYXZiPTQwbWljcm9zb2Z0LmNvbUBkbWFyYy5p ZXRmLm9yZzxtYWlsdG86NDBtaWNyb3NvZnQuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+ Pg0KPj4gWXVjaHVuZyBJIGJyb3VnaHQgdGhhdCBkaWZmZXJlbmNlIHVwIGluIGFuIGVtYWlsIHRv IHRoZSBxdWljIHdnDQo+PiBlYXJsaWVyIHRoaXMgd2Vlay4NCj4+DQo+PiBJbiBhcHAgc2VuZCBs aW1pdGVkIGNhc2UsIGluZmxpZ2h0IGNvdWxkIGJlIHZlcnkgc21hbGwgY29tcGFyZWQgdG8gY3du ZC4NCj4+IFNvIGluIFFVSUMgdGhlcmUgaXMgcG90ZW50aWFsIHRvIHNlbmQgYSBidXJzdCBvdXQg YWZ0ZXIgYSBsb25nIGlkbGUNCj4+IHBlcmlvZCAod2l0aCBvdXRzdGFuZGluZyBkYXRhKSB3aGVy ZSBUQ1Agd291bGRuJ3QuIFRoZSBkcmFmdCBjbGFpbXMNCj4+IHRoaXMgaXMgb2theSB0byBkbyBi ZWNhdXNlIFJUTyBtYXkgaGF2ZSBiZWVuIGEgcmVzdWx0IG9mIFJUVCBpbmNyZWFzZQ0KPj4gaW5z dGVhZCBvZiBsb3NzLiBJcyB0aGVyZSBkYXRhIHRvIHN1Z2dlc3Qgb24gd2hpY2ggc2lkZSB3ZSBz aG91bGQNCj4+IGVycj8gaS5lLiBkYXRhIG9uIHdoYXQgYXJlIHRoZSBjaGFuY2VzIHRoYXQgYW4g UlRPIGlzIGR1ZSB0byBhbiBSVFQgaW5jcmVhc2UgdmVyc3VzIGxvc3MuDQo+Pg0KPj4gRG8geW91 IHNlZSBhbnkgc2FmZXR5IGNvbmNlcm5zIHdpdGggZGVsYXllZCByZWR1Y3Rpb24gb2YgY3duZCBp biBjYXNlDQo+PiB3aGVyZSB0aGUgUlRPIGlzIG5vdCBzcHVyaW91cz8NCj4+DQo+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogdGNwbSA8dGNwbS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgWXVjaHVuZyBDaGVu Zw0KPj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDgsIDIwMTggNDozOCBQTQ0KPj4gVG86IEJv YiBCcmlzY29lIDxpZXRmQGJvYmJyaXNjb2UubmV0PG1haWx0bzppZXRmQGJvYmJyaXNjb2UubmV0 Pj4NCj4+IENjOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0 QGdvb2dsZS5jb20+PjsgdGNwbSBJRVRGIGxpc3QgPHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1A aWV0Zi5vcmc+Pg0KPj4gU3ViamVjdDogUmU6IFt0Y3BtXSBUaGFuayB5b3UgZm9yIHRoZSBRVUlD IHNlc3Npb24gaW4gdGNwbQ0KPj4NCj4+IE9uIFRodSwgTm92IDgsIDIwMTggYXQgMzoxNCBBTSwg Qm9iIEJyaXNjb2UgPGlldGZAYm9iYnJpc2NvZS5uZXQ8bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5u ZXQ+PiB3cm90ZToNCj4+ID4NCj4+ID4gSSBqdXN0IHdhbnRlZCB0byB0aGFuayBKYW5hIGZvciBl eHBsYWluaW5nIFFVSUMgbG9zcyByZWNvdmVyeSB0byB1cw0KPj4gPiAoYW5kIFFVSUMgQ0MgYXMg ZmFyIGFzIGl0IGdvZXMpLg0KPj4gPiBBbmQgdGhhbmsgeW91IEphbmEsIElhbiwgdGhlIGNoYWly cyBvZiBib3RoIFdHcyAoYW5kIGFueW9uZSBlbHNlDQo+PiA+IGludm9sdmVkKSBmb3Igc2V0dGlu ZyBpdCB1cC4NCj4+ID4NCj4+ID4gSWYgb25lIGlzIG5vdCBmdWxsLXRpbWUgb24gUVVJQywgaXQn cyB2ZXJ5IGRpZmZpY3VsdCB0byBrZWVwIHVwDQo+PiA+IHdpdGggYWxsIHRoZSBjaGFuZ2VzLiBC dXQgbm93IHdlIGhhdmUgYSBjaGVja3BvaW50IHRvIHN0YXJ0IGZyb20sIEkNCj4+ID4gZmVlbCBJ IHdpbGwgbm90IGJlIHdhc3RpbmcgcGVvcGxlJ3MgdGltZSBpZiBJIHRyeSB0byBnZXQgaW52b2x2 ZWQgLQ0KPj4gPiBhdCBsZWFzdCBJIG9ubHkgbWlnaHQgc2F5IHNvbWV0aGluZyB1bi1RVUlDIG9j Y2FzaW9uYWxseSwgcmF0aGVyDQo+PiA+IHRoYW4gbmVhcmx5IGFsd2F5cy4gVGhpcyBoYXMgYWxs b3dlZCBwZW9wbGUgd2hvIHVuZGVyc3RhbmQgaG93IFRDUA0KPj4gPiBjb2xkIGJlIGltcHJvdmVk IHRvIGhlbHAgd2l0aCBRVUlDLCB3aGVuIHdvcmtpbmcgb24gUVVJQyBpc24ndCB0aGVpciBkYXkg am9iLg0KPj4gPg0KPj4gPiBBZ2FpbiwgVGhhbmsgeW91Lg0KPj4gSSBsaWtlIHBhcnRpY3VsYXJs eSB0aGF0IFFVSUMgb25seSByZWR1Y2VzIGN3bmQgdG8gMSBhZnRlciB0aGUgbG9zcw0KPj4gaXMg Y29uZmlybWVkIG5vdCB1cG9uIFJUTyBmaXJlcy4gSXQgc2hvdWxkIGJlIHZlcnkgZmVhc2libGUg Zm9yIFRDUA0KPj4gKGF0IGxlYXN0DQo+PiBMaW51eCkgdy8gVENQIHRpbWVzdGFtcHMuIEl0J2xs IHNhdmUgYSBsb3Qgb2Ygc3B1cmlvdXMgY3duZCByZWR1Y3Rpb25zIQ0KPj4NCj4+IEFsc28gSU1I TyBUQ1Agdy8gcXVhbGl0eSB0aW1lc3RhbXBzIGFyZSBhbG1vc3QgYXMgZ29vZCBhcyBRVUlDIHBr dC1pZHMuDQo+PiBHb29nbGUgaW50ZXJuYWxseSB1c2VzIHVzZWMuIFdlIHdpc2ggd2UgY291bGQg dXBzdHJlYW0gaXQgYnV0IFJGQw0KPj4gbmVlZHMgdG8gYmUgdXBkYXRlZC4NCj4+DQo+PiA+DQo+ PiA+DQo+PiA+IEJvYg0KPj4gPg0KPj4gPg0KPj4gPiAtLQ0KPj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+IEJv YiBCcmlzY29lDQo+PiA+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZib2INCj4+ID4gYnJpc2NvZS5uZXQ8aHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmJyaXNj b2UubmV0JmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzdjNTQwYmMyMzRi ODQwNWI0NTQwMDhkNjQ5Mzc4MTIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjc3NjkwMDA5MjUzMTAzNSZzZGF0YT1ydHIxZkVaR2NFcWJTcVpaSWhHNkhQ ZG1mYjVMekdHQUZDTXRvTE55VFdvJTNEJnJlc2VydmVkPTA+JTJGJmFtcDtkYXRhPTAyJTdDMDEl N0NwcmF2YiU0MG1pY3Jvc29mdC5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRjQwbWljcm9zb2Z0LmNvbSZkYXRhPTAyJTdD MDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0M3YzU0MGJjMjM0Yjg0MDViNDU0MDA4ZDY0OTM3 ODEyMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3NzY5 MDAwOTI1MzEwMzUmc2RhdGE9U1FRV0laeThVQ1JxajV3NUk0ZGczc2dqdlRrcnlnVFhCY2klMkJP SkVUVkUwJTNEJnJlc2VydmVkPTA+JTdDM2M0ZDIyODY2DQo+PiA+IDg0NDQ2OTFjMTY4MDhkNjQ4 YmQyY2U5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCUNCj4+ID4g N0M2MzY3NzYzNzQ2NzgzMjEzMjQmYW1wO3NkYXRhPVQlMkJXVEVjNDJWQyUyQnolMkJzbU1GeWps bTM3aG1Bd2ZlZQ0KPj4gPiBidVBjdU1ZbFZoZ0RZJTNEJmFtcDtyZXNlcnZlZD0wDQo+PiA+DQo+ PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+ IHRjcG0gbWFpbGluZyBsaXN0DQo+PiA+IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5v cmc+DQo+PiA+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3cNCj4+ID4gdy5pDQo+PiA+IGV0Zi5vcmc8aHR0cHM6Ly9uYTAx LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmV0Zi5v cmcmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDN2M1NDBiYzIzNGI4NDA1 YjQ1NDAwOGQ2NDkzNzgxMjMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM2Nzc2OTAwMDkyNTQxMDM1JnNkYXRhPVFycTBKUG1mYzQ4TndRNlNVOUlNWUV2QTh4 M042T3BoRlR4WDJUcGNLdWslM0QmcmVzZXJ2ZWQ9MD4lMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0 Y3BtJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3INCj4+ID4gb3NvDQo+PiA+IGZ0LmNv bTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNBJTJGJTJGZnQuY29tJmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Qzdj NTQwYmMyMzRiODQwNWI0NTQwMDhkNjQ5Mzc4MTIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3NjkwMDA5MjU0MTAzNSZzZGF0YT1CZDZBbmRiTEE5cG9j bUZzQ3ZLQUdNSnc1bnNNVjRvaXlkd2xUNjd3TkhvJTNEJnJlc2VydmVkPTA+JTdDZjA5MTFlZWI3 NGQ3NDQ2ZjQyNDUwOGQ2NDVkYmI3NzklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkNw0KPj4gPiBj ZDANCj4+ID4gMTFkYjQ3JTdDMSU3QzAlN0M2MzY3NzMyMDczMTY3MTExNDkmYW1wO3NkYXRhPUs2 NjdhM0lRRzRyYXJRJTJGT2ZBbA0KPj4gPiB5aEsNCj4+ID4gUVEwNUNlYTQyMXJnYjY0RGxFTXZz JTNEJmFtcDtyZXNlcnZlZD0wDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IHRjcG0gbWFpbGluZyBsaXN0DQo+PiB0Y3BtQGlldGYub3Jn PG1haWx0bzp0Y3BtQGlldGYub3JnPg0KPj4NCj4+IGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3Lg0KPj4gaWV0Zi5vcmc8 aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUz QSUyRiUyRmlldGYub3JnJmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Qzdj NTQwYmMyMzRiODQwNWI0NTQwMDhkNjQ5Mzc4MTIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3NjkwMDA5MjU1MTA0OSZzZGF0YT12UHplYUc4RHkzNTJv bXl1V1ZFJTJCQzZiUUlWNDhvJTJGZ21pWXprb0tQN1QxcyUzRCZyZXNlcnZlZD0wPiUyRm1haWxt YW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm8NCj4+ IHNvZnQuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHAlM0ElMkYlMkZzb2Z0LmNvbSZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29m dC5jb20lN0M3YzU0MGJjMjM0Yjg0MDViNDU0MDA4ZDY0OTM3ODEyMyU3QzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3NzY5MDAwOTI1NTEwNDkmc2RhdGE9S3FW eWJnQWdOJTJCbDFLdHF1eGw1aHliV2dRZzA1T3o5TlF1VUQyJTJCUHFRRDQlM0QmcmVzZXJ2ZWQ9 MD4lN0MzYzRkMjI4NjY4NDQ0NjkxYzE2ODA4ZDY0OGJkMmNlOSU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3DQo+PiBjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3NjM3NDY3ODMyMTMyNCZhbXA7c2Rh dGE9MzNXeEtoNWM2cUw0bG41amVycHgNCj4+IFJoeXRmcmoxaVRLMjg0cEVxdjVmV0tZJTNEJmFt cDtyZXNlcnZlZD0wDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IHRjcG0gbWFpbGluZyBsaXN0DQo+PiB0Y3BtQGlldGYub3JnPG1haWx0 bzp0Y3BtQGlldGYub3JnPg0KPj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuDQo+PiBpZXRmLm9yZzxodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGaWV0 Zi5vcmcmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDN2M1NDBiYzIzNGI4 NDA1YjQ1NDAwOGQ2NDkzNzgxMjMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 QzElN0MwJTdDNjM2Nzc2OTAwMDkyNTYxMDUzJnNkYXRhPUVRYmxaWmoxc25zMTAyYUdkbkhPJTJG dlhQY1JWZzFjakVpVU1ZSyUyQmFKUFNrJTNEJnJlc2VydmVkPTA+JTJGbWFpbG1hbiUyRmxpc3Rp bmZvJTJGdGNwbSZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNybw0KPj4gc29mdC5jb208 aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUz QSUyRiUyRnNvZnQuY29tJmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Qzdj NTQwYmMyMzRiODQwNWI0NTQwMDhkNjQ5Mzc4MTIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3NjkwMDA5MjU2MTA1MyZzZGF0YT1YSUwyVEJ0ZmVRZllO Um56Q3p4S1FoaCUyRjlHZHlXRDlsRHR0ZDF3MXdhSE0lM0QmcmVzZXJ2ZWQ9MD4lN0MzYzRkMjI4 NjY4NDQ0NjkxYzE2ODA4ZDY0OGJkMmNlOSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3DQo+PiBj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3NjM3NDY3ODMyMTMyNCZhbXA7c2RhdGE9MzNXeEtoNWM2 cUw0bG41amVycHgNCj4+IFJoeXRmcmoxaVRLMjg0cEVxdjVmV0tZJTNEJmFtcDtyZXNlcnZlZD0w DQo= --_000_MW2PR2101MB1049E1E97815AA80CDEEFF88B6C20MW2PR2101MB1049_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYXTigJlzIGFsbCBncmVhdCBhc3N1bWluZyB0aGF0IFJUVCBp bmNyZWFzZSB3YXMgdGhlIHJlYXNvbiBmb3IgdGhlIHByb2xvbmdlZCBzaWxlbmNlLiBJdCBzaG91 bGQgYmUgcG9zc2libGUgdG8gbWVhc3VyZSBib3RoIGluY2lkZW5jZXMgb2Ygc3B1cmlvdXMgUlRP cyBhbmQgbWVhc3VyZWQgUlRUIGluY3JlYXNlcyBwb3N0IHNwdXJpb3VzIFJUT3MsIGFuZCB0aGF0 IHNob3VsZCB0ZWxsIHVzIHdoaWNoIHNpZGUgd2UNCiBzaG91bGQgZXJyIG9uLiA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Rm9yIHNhZmV0eSByZWFzb25zLCBzaG91bGQgd2UgcHV0IGluIHRoZSB0 ZXh0IGZvciByZWR1Y2luZyB0aGUgY3duZCBpbiBhYnNlbmNlIG9mIHBhY2luZyB0byBrZWVwIGNv bnNpc3RlbmN5IHdpdGggVENQIGJlaGF2aW9yLCBhdCBsZWFzdCB1bnRpbCBkYXRhIHNob3dzIG90 aGVyd2lzZT8gSSB3b3JyeSB0aGF0IG1vc3QgYXBwIGRldmVsb3BlcnMgd2l0aG91dCB0cmFuc3Bv cnQgYmFja2dyb3VuZCB3aWxsIG5vdA0KIGhhdmUgdGhlIGV4cGVydGlzZSB0byByZWFsaXplIHRo ZSBpc3N1ZXMgY2F1c2VkIGJ5IGJ1cnN0IGFmdGVyIGlkbGUuIFRoZSBvdGhlciBvcHRpb24gaXMg dG8gbWFrZSBwYWNpbmcgbWFuZGF0b3J5IGluIHRoZSBkcmFmdC4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gSmFuYSBJeWVuZ2FyICZsdDtqcmkuaWV0ZkBnbWFpbC5jb20m Z3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE5vdmVtYmVyIDEyLCAyMDE4IDExOjEzIFBN PGJyPg0KPGI+VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9z b2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFl1Y2h1bmcgQ2hlbmcgJmx0O3ljaGVuZ0Bnb29n bGUuY29tJmd0OzsgQm9iIEJyaXNjb2UgJmx0O2lldGZAYm9iYnJpc2NvZS5uZXQmZ3Q7OyBJYW4g U3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7OyB0Y3BtQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gVGhhbmsgeW91IGZvciB0aGUgUVVJQyBzZXNzaW9uIGlu IHRjcG08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiB3aGF0IHRvIGRv IHdpdGggYW4gdW5jb25maXJtZWQgUlRPOiBTbywgbXkgdGhvdWdodCBpcyB0aGF0IGlmIHlvdSd2 ZSBoaXQgYW4gUlRPLCBpdCdzIGJlZW4gYSBSRUFMTFkgTE9ORyB0aW1lLCBiZWNhdXNlIHdlJ3Zl IGdvbmUgdGhyb3VnaCBUTFAocykgYnkgbm93IGFuZCBmYWlsZWQuIChUaGlzIG1pZ2h0IGNoYW5n ZSBpZiB3ZSBkZWNpZGUgdG8gY29tYmluZSBUTFAgYW5kIFJUTywgYnV0IHRoYXQncyBmb3INCiBh IGxhdGVyIGRpc2N1c3Npb24uKSZuYnNwOyBJdCdzIG5vdCBmdWxseSBjbGVhciB0byBtZSB3aGF0 IHRoZSByaWdodCByZXNwb25zZXMgaGVyZSBhcmUsIGJ1dCBzb21lIHRob3VnaHRzIGZvbGxvdy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS8g SWYgdGhpcyB3YXMgYW4gYWN0dWFsIGluY3JlYXNlIGluIHRoZSBSVFQsIGl0IHdvdWxkIG5hdHVy YWxseSByb2xsIGludG8gdGhlIFNSVFQgYW5kIFJUVFZBUi4gV2UgbWlnaHQgZXZlbiBjb25zaWRl ciByZXNldHRpbmcgdGhlIFJUVCBlc3RpbWF0b3IsIGJ1dCB3ZSBhbHJlYWR5IGtub3cgdGhhdCB0 aGUgRVdNQSBlc3RpbWF0b3Igd2UgbG92ZSB0YWtlcyBqdXN0IGEgd2hpbGUgdG8gY2F0Y2ggb24s IGFuZA0KIEkgZG9uJ3Qgd2FudCB0byBsaXRpZ2F0ZSBjaGFuZ2luZyB0aGUgZXN0aW1hdG9yIGZ1 bmRhbWVudGFsbHkgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Mi8gTGludXggZnEgdXNlcyBtaW5fcnR0IElJUkMsIHdoaWNoIHNob3Vs ZG4ndCBjaGFuZ2UgYXMgYSByZXN1bHQgb2YgYW4gaW5jcmVhc2UgaW4gUlRULiBUaGlzICptaWdo dCogYmUgYSBnb29kIHRpbWUgdG8ga2ljayB0aGUgbWluX3J0dCBlc3RpbWF0b3IgdG8gcGFjZSBt b3JlIGNvbnNlcnZhdGl2ZWx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4zLyBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IGl0IG1ha2VzIHNlbnNl IHRvIGNoYW5nZSB0aGUgY3duZC4gSXQgc2VlbXMgY2xlYXIgdGhhdCBhbiBSVFQgaW5jcmVhc2Ug d2l0aCB0aGUgc2FtZSBCVyBzaG91bGQgaW5jcmVhc2UgdGhlIGN3bmQgaWYgYW55dGhpbmcsIHNv IGl0IHNlZW1zIHJlYXNvbmFibGUgdG8gY29udGludWUgd2l0aCB0aGUgc2FtZSBjd25kIGF0IGxl YXN0LiBJZiB0aGUgQlcgY2hhbmdlZCwgaG9wZWZ1bGx5DQogdGhhdCdsbCBiZSByZWZsZWN0ZWQg aW4gYSBjb25nZXN0aW9uIHNpZ25hbCwgYnV0IGluIHRoZSBhYnNlbmNlIG9mIGEgY29uZ2VzdGlv biBzaWduYWwsIEkgdGhpbmsgd2Ugc2hvdWxkIGtlZXAgdGhlIGN3bmQgYXMgaXMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBO b3YgMTMsIDIwMTggYXQgMTI6MzUgQU0gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhy ZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WXVjaHVuZyB0 aGlzIG1pZ2h0IGJlIHdvcnRoIGV4cGVyaW1lbnRpbmcgd2l0aCBhbmQgZ2V0dGluZyBtb3JlIGRh dGEgb24uIE1heWJlIHRoZXJlIHNob3VsZCBiZSBzb21lIHJlYWN0aW9uIHRvIGFuIHVuY29uZmly bWVkIFJUTyBldmVuIGlmIGl0IGlzIG5vdCByZWR1Y3Rpb24gYWxsIHRoZSB3YXkgdG8gTFc/IEkg bGlrZSBKYW5hJ3Mgc3VnZ2VzdGlvbiB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBTSE9VTEQgZHJv cA0KIHRoZSBjd25kIGV2ZW4gZm9yIHVuY29uZmlybWVkIFJUTyBpZiBub3QgcGFjaW5nLiA8YnI+ DQo8YnI+DQpJIGNoZWNrZWQgdGhlIGxhdGVzdCBkcmFmdCBhbmQgcGFjaW5nIGlzIGEgUkVDT01N RU5ERUQuIEkgYW0gbm90aWNpbmcgdGhhdCB0cmFuc3BvcnQgYWxnb3JpdGhtcyBpbiBMaW51eCBh bmQgaW4gUVVJQyBhcmUgZXZvbHZpbmcgYXNzdW1pbmcgcGFjaW5nIHdoaWNoIGlzIGEgZnVuY3Rp b24gdXN1YWxseSBpbXBsZW1lbnRlZCBhbmQgY29uZmlndXJlZCBvdXRzaWRlIG9mIHRoZSB0cmFu c3BvcnQuIFNvIHRoZSB0cmFuc3BvcnQgaXMgcG90ZW50aWFsbHkNCiBtYWtpbmcgYW4gYXNzdW1w dGlvbiB3aGljaCBtYXkgcmVzdWx0IGluIHNhZmV0eSBpc3N1ZXMuIEZvciBleGFtcGxlIEJCUiBj b25nZXN0aW9uIGNvbnRyb2wgbWF5IG5vdCB3b3JrIHZlcnkgd2VsbCBpZiBwYWNpbmcgd2FzIGRp c2FibGVkIG9yIG1pc2NvbmZpZ3VyZWQ/IEkgZG9u4oCZdCBrbm93IG9mIGFueSByb2J1c3Qgc29s dXRpb24gdG8gdGhpcyBvdGhlciB0aGFuIGJ1aWxkIHBhY2luZyBpbnRvIHRoZSB0cmFuc3BvcnQg aXRzZWxmLiBQYWNpbmcNCiBpcyBhbHNvIHZlcnkgY2hhbGxlbmdpbmcgZm9yIGxvdyBsYXRlbmN5 IGZsb3dzIGJlY2F1c2Ugb2YgbGFjayBvZiBzdXBwb3J0IGZvciBmaW5lIGdyYWluZWQgdGltZXJz Ljxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogWXVjaHVu ZyBDaGVuZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnljaGVuZ0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9i bGFuayI+eWNoZW5nQGdvb2dsZS5jb208L2E+Jmd0Ow0KPGJyPg0KU2VudDogTW9uZGF5LCBOb3Zl bWJlciAxMiwgMjAxOCA4OjM3IEFNPGJyPg0KVG86IEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpyaS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpyaS5pZXRmQGdtYWls LmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVm PSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jv c29mdC5jb208L2E+Jmd0OzsgQm9iIEJyaXNjb2UgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGJv YmJyaXNjb2UubmV0IiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBib2JicmlzY29lLm5ldDwvYT4mZ3Q7 OyBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRv OnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50Y3BtQGlldGYub3JnPC9hPiBFeHRlbnNp b25zICZsdDs8YSBocmVmPSJtYWlsdG86dGNwbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRj cG1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJlOiBbdGNwbV0gVGhhbmsgeW91IGZv ciB0aGUgUVVJQyBzZXNzaW9uIGluIHRjcG08YnI+DQo8YnI+DQpPbiBNb24sIE5vdiAxMiwgMjAx OCBhdCA0OjEzIEFNLCBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmkuaWV0ZkBn bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7IFByYXZlZW4sPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHBvaW50IHlvdSdy ZSByYWlzaW5nIC0tIHRoYXQgd2UndmUgbG9zdCB0aGUgYWNrIGNsb2NrIGFmdGVyIGFuIFJUTyA8 YnI+DQomZ3Q7IC0tIGlzIGEgcmVhc29uYWJsZSBwb2ludC4gTXkgYXJndW1lbnQgaXMgdGhhdCB3 aXRoIHBhY2luZywgY3duZCA8YnI+DQomZ3Q7IHJlZHVjdGlvbiBpcyB1bndhcnJhbnRlZCBiZWNh dXNlIGluIHRoZSBleHRyZW1lIGNhc2UsIHRoaXMgY29sbGFwc2VzIDxicj4NCiZndDsgdG8gcmVz dGFydCBhZnRlciBpZGxlLCB3aGVyZSBzZW5kaW5nIGF0IGN3bmQgd2l0aCBwYWNpbmcgaXMgcmVh c29uYWJsZTxicj4NCkkgYWdyZWUgdy8gSmFuYSBhcyB3ZWxsIC0gdGhlIG1vc3QgZ2VuZXJpYyB3 YXkgdG8gdHJlYXQgYnVyc3QgZHVlIHRvIHByaW9yX2luZmxpZ2h0ICZsdDsmbHQ7IGN3bmQgaXMg cGFjaW5nLiBXaXRoIFFVSUMncyBhcHByb2FjaCwgd2hlbiBSVE8gZmlyZXMsIGN3bmQgcmVtYWlu cyB1bmNoYW5nZWQgdW50aWwgdGhlIEFDSyBvZiB0aGUgZmlyc3QgcmV0cmFuc21pc3Npb24gKGku ZS4gYSBwcm9iZSBwYWNrZXQpIGNvbWVzIGJhY2suIFRoZXJlZm9yZSB0aGUgZGVsYXkNCiBpcyBv bmUgUlRUIGFuZCB0aGUgcG90ZW50aWFsIGRhbWFnZSBpcyBhbiBhZGRpdGlvbmFsIGN3bmQtd29y dGggb2YgYnVyc3QuPGJyPg0KPGJyPg0KWWVzIHRoZSB3b3JzdCBjYXNlIGlzIG1vcmUgYWdncmVz c2l2ZSwgYW5kIGl0IGNhbiBiZSB0b28gbXVjaCBmb3IgREMgaW5jYXN0IGNhc2UgaWYgcGFjaW5n IGlzbid0IHN1cHBvcnRlZCAtIG9uZSBpZGVhIGlzIHRvIHNlbGVjdGl2ZSBlbmFibGUgdGhhdCBp ZiBSVFQgdmFyaWFuY2UgaXMgdmVyeSBsYXJnZSB2cyBSVFQuPGJyPg0KPGJyPg0KJmd0Ozxicj4N CiZndDsgVGhlIGRyYWZ0IGRvZXMgbm90IHNheSB0aGF0IGEgc2VuZGVyIHNob3VsZCByZWR1Y2Ug dGhlIGN3bmQgaWYgaXQgaXMgPGJyPg0KJmd0OyBub3QgcGFjaW5nLCB3aGljaCB3ZSBzaG91bGQg YWRkLiBEb2VzIHRoYXQgbWFrZSBzZW5zZT88YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIGphbmE8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBPbiBGcmksIE5vdiA5LCAyMDE4IGF0IDg6MzQgQU0gUHJhdmVlbiBC YWxhc3VicmFtYW5pYW4gPGJyPg0KJmd0OyAmbHQ7cHJhdmI9PGEgaHJlZj0ibWFpbHRvOjQwbWlj cm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNv bUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgWXVjaHVuZyBJIGJyb3VnaHQgdGhhdCBkaWZmZXJlbmNlIHVwIGluIGFuIGVtYWlsIHRvIHRo ZSBxdWljIHdnIDxicj4NCiZndDsmZ3Q7IGVhcmxpZXIgdGhpcyB3ZWVrLjxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgSW4gYXBwIHNlbmQgbGltaXRlZCBjYXNlLCBpbmZsaWdodCBjb3VsZCBi ZSB2ZXJ5IHNtYWxsIGNvbXBhcmVkIHRvIGN3bmQuPGJyPg0KJmd0OyZndDsgU28gaW4gUVVJQyB0 aGVyZSBpcyBwb3RlbnRpYWwgdG8gc2VuZCBhIGJ1cnN0IG91dCBhZnRlciBhIGxvbmcgaWRsZSA8 YnI+DQomZ3Q7Jmd0OyBwZXJpb2QgKHdpdGggb3V0c3RhbmRpbmcgZGF0YSkgd2hlcmUgVENQIHdv dWxkbid0LiBUaGUgZHJhZnQgY2xhaW1zIDxicj4NCiZndDsmZ3Q7IHRoaXMgaXMgb2theSB0byBk byBiZWNhdXNlIFJUTyBtYXkgaGF2ZSBiZWVuIGEgcmVzdWx0IG9mIFJUVCBpbmNyZWFzZSA8YnI+ DQomZ3Q7Jmd0OyBpbnN0ZWFkIG9mIGxvc3MuIElzIHRoZXJlIGRhdGEgdG8gc3VnZ2VzdCBvbiB3 aGljaCBzaWRlIHdlIHNob3VsZCA8YnI+DQomZ3Q7Jmd0OyBlcnI/IGkuZS4gZGF0YSBvbiB3aGF0 IGFyZSB0aGUgY2hhbmNlcyB0aGF0IGFuIFJUTyBpcyBkdWUgdG8gYW4gUlRUIGluY3JlYXNlIHZl cnN1cyBsb3NzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRG8geW91IHNlZSBhbnkgc2Fm ZXR5IGNvbmNlcm5zIHdpdGggZGVsYXllZCByZWR1Y3Rpb24gb2YgY3duZCBpbiBjYXNlIDxicj4N CiZndDsmZ3Q7IHdoZXJlIHRoZSBSVE8gaXMgbm90IHNwdXJpb3VzPzxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyBGcm9t OiB0Y3BtICZsdDs8YSBocmVmPSJtYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+dGNwbS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24gQmVoYWxmIE9mIFl1Y2h1 bmcgQ2hlbmc8YnI+DQomZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgOCwgMjAxOCA0 OjM4IFBNPGJyPg0KJmd0OyZndDsgVG86IEJvYiBCcmlzY29lICZsdDs8YSBocmVmPSJtYWlsdG86 aWV0ZkBib2JicmlzY29lLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAYm9iYnJpc2NvZS5uZXQ8 L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7IENjOiBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzpp YW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNvbTwv YT4mZ3Q7OyB0Y3BtIElFVEYgbGlzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj50Y3BtQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OyBTdWJq ZWN0OiBSZTogW3RjcG1dIFRoYW5rIHlvdSBmb3IgdGhlIFFVSUMgc2Vzc2lvbiBpbiB0Y3BtPGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBUaHUsIE5vdiA4LCAyMDE4IGF0IDM6MTQgQU0s IEJvYiBCcmlzY29lICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBib2JicmlzY29lLm5ldCIgdGFy Z2V0PSJfYmxhbmsiPmlldGZAYm9iYnJpc2NvZS5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBJIGp1c3Qgd2FudGVkIHRvIHRoYW5rIEphbmEg Zm9yIGV4cGxhaW5pbmcgUVVJQyBsb3NzIHJlY292ZXJ5IHRvIHVzIDxicj4NCiZndDsmZ3Q7ICZn dDsgKGFuZCBRVUlDIENDIGFzIGZhciBhcyBpdCBnb2VzKS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEFu ZCB0aGFuayB5b3UgSmFuYSwgSWFuLCB0aGUgY2hhaXJzIG9mIGJvdGggV0dzIChhbmQgYW55b25l IGVsc2U8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGludm9sdmVkKSBmb3Igc2V0dGluZyBpdCB1cC48YnI+ DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBJZiBvbmUgaXMgbm90IGZ1bGwtdGlt ZSBvbiBRVUlDLCBpdCdzIHZlcnkgZGlmZmljdWx0IHRvIGtlZXAgdXAgPGJyPg0KJmd0OyZndDsg Jmd0OyB3aXRoIGFsbCB0aGUgY2hhbmdlcy4gQnV0IG5vdyB3ZSBoYXZlIGEgY2hlY2twb2ludCB0 byBzdGFydCBmcm9tLCBJIDxicj4NCiZndDsmZ3Q7ICZndDsgZmVlbCBJIHdpbGwgbm90IGJlIHdh c3RpbmcgcGVvcGxlJ3MgdGltZSBpZiBJIHRyeSB0byBnZXQgaW52b2x2ZWQgLSA8YnI+DQomZ3Q7 Jmd0OyAmZ3Q7IGF0IGxlYXN0IEkgb25seSBtaWdodCBzYXkgc29tZXRoaW5nIHVuLVFVSUMgb2Nj YXNpb25hbGx5LCByYXRoZXIgPGJyPg0KJmd0OyZndDsgJmd0OyB0aGFuIG5lYXJseSBhbHdheXMu IFRoaXMgaGFzIGFsbG93ZWQgcGVvcGxlIHdobyB1bmRlcnN0YW5kIGhvdyBUQ1AgPGJyPg0KJmd0 OyZndDsgJmd0OyBjb2xkIGJlIGltcHJvdmVkIHRvIGhlbHAgd2l0aCBRVUlDLCB3aGVuIHdvcmtp bmcgb24gUVVJQyBpc24ndCB0aGVpciBkYXkgam9iLjxicj4NCiZndDsmZ3Q7ICZndDs8YnI+DQom Z3Q7Jmd0OyAmZ3Q7IEFnYWluLCBUaGFuayB5b3UuPGJyPg0KJmd0OyZndDsgSSBsaWtlIHBhcnRp Y3VsYXJseSB0aGF0IFFVSUMgb25seSByZWR1Y2VzIGN3bmQgdG8gMSBhZnRlciB0aGUgbG9zcyA8 YnI+DQomZ3Q7Jmd0OyBpcyBjb25maXJtZWQgbm90IHVwb24gUlRPIGZpcmVzLiBJdCBzaG91bGQg YmUgdmVyeSBmZWFzaWJsZSBmb3IgVENQIDxicj4NCiZndDsmZ3Q7IChhdCBsZWFzdDxicj4NCiZn dDsmZ3Q7IExpbnV4KSB3LyBUQ1AgdGltZXN0YW1wcy4gSXQnbGwgc2F2ZSBhIGxvdCBvZiBzcHVy aW91cyBjd25kIHJlZHVjdGlvbnMhPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBbHNvIElN SE8gVENQIHcvIHF1YWxpdHkgdGltZXN0YW1wcyBhcmUgYWxtb3N0IGFzIGdvb2QgYXMgUVVJQyBw a3QtaWRzLjxicj4NCiZndDsmZ3Q7IEdvb2dsZSBpbnRlcm5hbGx5IHVzZXMgdXNlYy4gV2Ugd2lz aCB3ZSBjb3VsZCB1cHN0cmVhbSBpdCBidXQgUkZDIDxicj4NCiZndDsmZ3Q7IG5lZWRzIHRvIGJl IHVwZGF0ZWQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsg Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgQm9iPGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsm Z3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IC0tPGJyPg0KJmd0OyZndDsgJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyZndDsgJmd0OyBCb2IgQnJpc2NvZTxicj4NCiZndDsmZ3Q7ICZndDsgPGEgaHJl Zj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cCUzQSUyRiUyRmJvYiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRmJvYjwvYT48YnI+DQomZ3Q7 Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZicmlzY29lLm5ldCZhbXA7ZGF0YT0wMiU3QzAxJTdD cHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDN2M1NDBiYzIzNGI4NDA1YjQ1NDAwOGQ2NDkzNzgxMjMl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Nzc2OTAwMDky NTMxMDM1JmFtcDtzZGF0YT1ydHIxZkVaR2NFcWJTcVpaSWhHNkhQZG1mYjVMekdHQUZDTXRvTE55 VFdvJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpicmlzY29lLm5ldDwvYT4l MkYmYW1wO2FtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU8YSBocmVmPSJodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGNDBtaWNyb3Nv ZnQuY29tJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0M3YzU0MGJj MjM0Yjg0MDViNDU0MDA4ZDY0OTM3ODEyMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzY3NzY5MDAwOTI1MzEwMzUmYW1wO3NkYXRhPVNRUVdJWnk4VUNScWo1 dzVJNGRnM3NnanZUa3J5Z1RYQmNpJTJCT0pFVFZFMCUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0 PSJfYmxhbmsiPjQwbWljcm9zb2Z0LmNvbTwvYT4lN0MzYzRkMjI4NjY8YnI+DQomZ3Q7Jmd0OyAm Z3Q7IDg0NDQ2OTFjMTY4MDhkNjQ4YmQyY2U5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN0MxJTdDMCU8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDdDNjM2Nzc2Mzc0Njc4MzIxMzI0JmFt cDthbXA7c2RhdGE9VCUyQldURWM0MlZDJTJCeiUyQnNtTUZ5amxtMzdobUF3ZmVlPGJyPg0KJmd0 OyZndDsgJmd0OyBidVBjdU1ZbFZoZ0RZJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDxicj4NCiZndDsm Z3Q7ICZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgJmd0OyB0Y3BtIG1haWxpbmcgbGlzdDxi cj4NCiZndDsmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj50Y3BtQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ3dyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3dzwvYT48YnI+DQomZ3Q7Jmd0OyAm Z3Q7IHcuaSA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZldGYub3JnJmFtcDtk YXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0M3YzU0MGJjMjM0Yjg0MDViNDU0 MDA4ZDY0OTM3ODEyMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzY3NzY5MDAwOTI1NDEwMzUmYW1wO3NkYXRhPVFycTBKUG1mYzQ4TndRNlNVOUlNWUV2QTh4 M042T3BoRlR4WDJUcGNLdWslM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmV0 Zi5vcmc8L2E+JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7YW1wO2RhdGE9MDIlN0Mw MSU3Q3ByYXZiJTQwbWljcjxicj4NCiZndDsmZ3Q7ICZndDsgb3NvPGJyPg0KJmd0OyZndDsgJmd0 OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwJTNBJTJGJTJGZnQuY29tJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jv c29mdC5jb20lN0M3YzU0MGJjMjM0Yjg0MDViNDU0MDA4ZDY0OTM3ODEyMyU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3NzY5MDAwOTI1NDEwMzUmYW1wO3Nk YXRhPUJkNkFuZGJMQTlwb2NtRnNDdktBR01KdzVuc01WNG9peWR3bFQ2N3dOSG8lM0QmYW1wO3Jl c2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmZ0LmNvbTwvYT4lN0NmMDkxMWVlYjc0ZDc0NDZm NDI0NTA4ZDY0NWRiYjc3OSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3PGJyPg0KJmd0OyZndDsg Jmd0OyBjZDAgPGJyPg0KJmd0OyZndDsgJmd0OyAxMWRiNDclN0MxJTdDMCU3QzYzNjc3MzIwNzMx NjcxMTE0OSZhbXA7YW1wO3NkYXRhPUs2NjdhM0lRRzRyYXJRJTJGT2ZBbDxicj4NCiZndDsmZ3Q7 ICZndDsgeWhLPGJyPg0KJmd0OyZndDsgJmd0OyBRUTA1Q2VhNDIxcmdiNjREbEVNdnMlM0QmYW1w O2FtcDtyZXNlcnZlZD0wPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IHRjcG0gbWFp bGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj50Y3BtQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM0ElMkYlMkZ3d3ciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3PC9h Pi48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGaWV0Zi5vcmcmYW1wO2RhdGE9MDIlN0Mw MSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzdjNTQwYmMyMzRiODQwNWI0NTQwMDhkNjQ5Mzc4 MTIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3Njkw MDA5MjU1MTA0OSZhbXA7c2RhdGE9dlB6ZWFHOER5MzUyb215dVdWRSUyQkM2YlFJVjQ4byUyRmdt aVl6a29LUDdUMXMlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmlldGYub3Jn PC9hPiUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2FtcDtkYXRhPTAyJTdDMDElN0Nw cmF2YiU0MG1pY3JvPGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnNvZnQuY29tJmFtcDtk YXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0M3YzU0MGJjMjM0Yjg0MDViNDU0 MDA4ZDY0OTM3ODEyMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzY3NzY5MDAwOTI1NTEwNDkmYW1wO3NkYXRhPUtxVnliZ0FnTiUyQmwxS3RxdXhsNWh5Yldn UWcwNU96OU5RdVVEMiUyQlBxUUQ0JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+ DQpzb2Z0LmNvbTwvYT4lN0MzYzRkMjI4NjY4NDQ0NjkxYzE2ODA4ZDY0OGJkMmNlOSU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3PGJyPg0KJmd0OyZndDsgY2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3 NzYzNzQ2NzgzMjEzMjQmYW1wO2FtcDtzZGF0YT0zM1d4S2g1YzZxTDRsbjVqZXJweDxicj4NCiZn dDsmZ3Q7IFJoeXRmcmoxaVRLMjg0cEVxdjVmV0tZJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyB0Y3BtIG1haWxpbmcgbGlzdDxicj4NCiZndDsm Z3Q7IDxhIGhyZWY9Im1haWx0bzp0Y3BtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGNwbUBp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dyIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZ3d3c8L2E+Ljxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZp ZXRmLm9yZyZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDN2M1NDBi YzIzNGI4NDA1YjQ1NDAwOGQ2NDkzNzgxMjMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3QzElN0MwJTdDNjM2Nzc2OTAwMDkyNTYxMDUzJmFtcDtzZGF0YT1FUWJsWlpqMXNuczEw MmFHZG5ITyUyRnZYUGNSVmcxY2pFaVVNWUslMkJhSlBTayUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFy Z2V0PSJfYmxhbmsiPg0KaWV0Zi5vcmc8L2E+JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZh bXA7YW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm88YnI+DQomZ3Q7Jmd0OyA8YSBocmVm PSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNBJTJGJTJGc29mdC5jb20mYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNv bSU3QzdjNTQwYmMyMzRiODQwNWI0NTQwMDhkNjQ5Mzc4MTIzJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc3NjkwMDA5MjU2MTA1MyZhbXA7c2RhdGE9WElM MlRCdGZlUWZZTlJuekN6eEtRaGglMkY5R2R5V0Q5bER0dGQxdzF3YUhNJTNEJmFtcDtyZXNlcnZl ZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpzb2Z0LmNvbTwvYT4lN0MzYzRkMjI4NjY4NDQ0NjkxYzE2 ODA4ZDY0OGJkMmNlOSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3PGJyPg0KJmd0OyZndDsgY2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzY3NzYzNzQ2NzgzMjEzMjQmYW1wO2FtcDtzZGF0YT0zM1d4S2g1 YzZxTDRsbjVqZXJweDxicj4NCiZndDsmZ3Q7IFJoeXRmcmoxaVRLMjg0cEVxdjVmV0tZJTNEJmFt cDthbXA7cmVzZXJ2ZWQ9MDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MW2PR2101MB1049E1E97815AA80CDEEFF88B6C20MW2PR2101MB1049_-- From nobody Wed Nov 14 08:14:04 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FFE130E5D for ; Wed, 14 Nov 2018 08:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAHHBBusf5yE for ; Wed, 14 Nov 2018 08:13:59 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49807130DD7 for ; Wed, 14 Nov 2018 08:13:59 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id x2-v6so8138009pfm.7 for ; Wed, 14 Nov 2018 08:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=XLvX2ZSiJOB5qzWttJRKY1d20/EAeNZ89pQx+1MtZHY=; b=HzMb5mFHPa/dyJdevXQLkHFW14OjdnmjgT+oLpHoDONRy+zUPopNr5goh+tq+4Zff4 RhWNPH1ui+HyITPqsbyPcNkrracyh8JJDkBDZ1TkFrGtjsphwqALSDigLX2KR/ITAP+Z bw0jVMvUUbjynPSGDN5fRDNHPzzQ8+cDaF+pWzA5LxQxsoMhyd8OOlgxJZKlOsdW8bDV 7lBX/xodtTlaxrLBRgG0kayQ8yuWjgdTBz2f0fQVGPPyGxm6V3vntgNZPPhRlzt4Tz3U pr+Sk1BHMXV6s6UnLyakWd2jlM3O911evdT0QkUIgXjvtFbr0NVQHCBUvtA0Sp/lTSEh ZF+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XLvX2ZSiJOB5qzWttJRKY1d20/EAeNZ89pQx+1MtZHY=; b=PXvm8gIuwPk4tGVJSQwOiG+0rUW9sQP8sX1qoHEY7hZR0p5xOThyQIpCl4T7Hm5PTB jojATPrtfUtc2GRwuu2rNdKuSCVNDS5Gn3To8ZwSaapxqpoqYxRw85vJUA8FcXy7R2Hy MSms4l/zfpu7GKaFRWjcxppSwINuDMNXKzPFhkjSY3rUl9HMcffmzX2KbwKm0V5KUBt/ nZytgmDrmhWqrB/ZfpMLyzBbP5JSKHx3mbwcUGA+mIvDvu5PYwbwMPycsoJcRFTmilPP JTfviONfc6NvjD3iiw5sD6eXJjvfuRIEtefHGNrbXSHCiFN3vd5k7IZHwEr0MDsTUV/7 TZKw== X-Gm-Message-State: AGRZ1gLA34MgOzYLeudLbxsiB2kyDZQhR1OhCw3+6/TTcys/fO/3B/kw qhrPkWpW2netvRPryLRgWnCAgpDE X-Google-Smtp-Source: AJdET5chrnXZ+wYUz0A/XwtcyepYUQQPW4oTOGAd7cOoWml3psCwD/+YHt2hx9tOKkINxje5lP4LNA== X-Received: by 2002:a65:434d:: with SMTP id k13mr2316115pgq.269.1542212038583; Wed, 14 Nov 2018 08:13:58 -0800 (PST) Received: from [192.168.44.50] ([64.114.255.114]) by smtp.gmail.com with ESMTPSA id 134sm23548762pgb.78.2018.11.14.08.13.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Nov 2018 08:13:57 -0800 (PST) To: tcpm@ietf.org References: From: Eric Dumazet Message-ID: Date: Wed, 14 Nov 2018 08:13:57 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2018 16:14:03 -0000 On 11/12/2018 11:13 PM, Jana Iyengar wrote: > On what to do with an unconfirmed RTO: So, my thought is that if you've hit an RTO, it's been a REALLY LONG time, because we've gone through TLP(s) by now and failed. (This might change if we decide to combine TLP and RTO, but that's for a later discussion.)  It's not fully clear to me what the right responses here are, but some thoughts follow. > > 1/ If this was an actual increase in the RTT, it would naturally roll into the SRTT and RTTVAR. We might even consider resetting the RTT estimator, but we already know that the EWMA estimator we love takes just a while to catch on, and I don't want to litigate changing the estimator fundamentally here. > > 2/ Linux fq uses min_rtt IIRC, which shouldn't change as a result of an increase in RTT. This *might* be a good time to kick the min_rtt estimator to pace more conservatively. linux fq does not use min_rtt, but the pacing rate set by TCP. pacing rate for Cubic is using SRTT ( https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c#L806 ) For BBR, pacing rate depends on various factors and phases, but SRTT is used, not min_rtt https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_bbr.c#L231 > > 3/ I'm not convinced that it makes sense to change the cwnd. It seems clear that an RTT increase with the same BW should increase the cwnd if anything, so it seems reasonable to continue with the same cwnd at least. If the BW changed, hopefully that'll be reflected in a congestion signal, but in the absence of a congestion signal, I think we should keep the cwnd as is. > > > On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian > wrote: > > Yuchung this might be worth experimenting with and getting more data on. Maybe there should be some reaction to an unconfirmed RTO even if it is not reduction all the way to LW? I like Jana's suggestion that the implementation SHOULD drop the cwnd even for unconfirmed RTO if not pacing. > > I checked the latest draft and pacing is a RECOMMENDED. I am noticing that transport algorithms in Linux and in QUIC are evolving assuming pacing which is a function usually implemented and configured outside of the transport.. So the transport is potentially making an assumption which may result in safety issues. For example BBR congestion control may not work very well if pacing was disabled or misconfigured? I don’t know of any robust solution to this other than build pacing into the transport itself. Pacing is also very challenging for low latency flows because of lack of support for fine grained timers. > > -----Original Message----- > From: Yuchung Cheng > > Sent: Monday, November 12, 2018 8:37 AM > To: Jana Iyengar > > Cc: Praveen Balasubramanian >; Bob Briscoe >; Ian Swett >; tcpm@ietf.org Extensions > > Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > > On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar > wrote: > > Praveen, > > > > The point you're raising -- that we've lost the ack clock after an RTO > > -- is a reasonable point. My argument is that with pacing, cwnd > > reduction is unwarranted because in the extreme case, this collapses > > to restart after idle, where sending at cwnd with pacing is reasonable > I agree w/ Jana as well - the most generic way to treat burst due to prior_inflight << cwnd is pacing. With QUIC's approach, when RTO fires, cwnd remains unchanged until the ACK of the first retransmission (i.e. a probe packet) comes back. Therefore the delay is one RTT and the potential damage is an additional cwnd-worth of burst. > > Yes the worst case is more aggressive, and it can be too much for DC incast case if pacing isn't supported - one idea is to selective enable that if RTT variance is very large vs RTT. > > > > > The draft does not say that a sender should reduce the cwnd if it is > > not pacing, which we should add. Does that make sense? > > > > - jana > > > > On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian > > > wrote: > >> > >> Yuchung I brought that difference up in an email to the quic wg > >> earlier this week. > >> > >> In app send limited case, inflight could be very small compared to cwnd. > >> So in QUIC there is potential to send a burst out after a long idle > >> period (with outstanding data) where TCP wouldn't. The draft claims > >> this is okay to do because RTO may have been a result of RTT increase > >> instead of loss. Is there data to suggest on which side we should > >> err? i.e. data on what are the chances that an RTO is due to an RTT increase versus loss. > >> > >> Do you see any safety concerns with delayed reduction of cwnd in case > >> where the RTO is not spurious? > >> > >> -----Original Message----- > >> From: tcpm > On Behalf Of Yuchung Cheng > >> Sent: Thursday, November 8, 2018 4:38 PM > >> To: Bob Briscoe > > >> Cc: Ian Swett >; tcpm IETF list > > >> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > >> > >> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe > wrote: > >> > > >> > I just wanted to thank Jana for explaining QUIC loss recovery to us > >> > (and QUIC CC as far as it goes). > >> > And thank you Jana, Ian, the chairs of both WGs (and anyone else > >> > involved) for setting it up. > >> > > >> > If one is not full-time on QUIC, it's very difficult to keep up > >> > with all the changes. But now we have a checkpoint to start from, I > >> > feel I will not be wasting people's time if I try to get involved - > >> > at least I only might say something un-QUIC occasionally, rather > >> > than nearly always. This has allowed people who understand how TCP > >> > cold be improved to help with QUIC, when working on QUIC isn't their day job. > >> > > >> > Again, Thank you. > >> I like particularly that QUIC only reduces cwnd to 1 after the loss > >> is confirmed not upon RTO fires. It should be very feasible for TCP > >> (at least > >> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd reductions! > >> > >> Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt-ids. > >> Google internally uses usec. We wish we could upstream it but RFC > >> needs to be updated. > >> > >> > > >> > > >> > Bob > >> > > >> > > >> > -- > >> > ________________________________________________________________ > >> > Bob Briscoe > >> > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbob > >> > briscoe.net %2F&data=02%7C01%7Cpravb%40microsoft.com %7C3c4d22866 > >> > 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > >> > 7C636776374678321324&sdata=T%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfee > >> > buPcuMYlVhgDY%3D&reserved=0 > >> > > >> > _______________________________________________ > >> > tcpm mailing list > >> > tcpm@ietf.org > >> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > >> > w.i > >> > etf.org %2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40micr > >> > oso > >> > ft.com %7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7 > >> > cd0 > >> > 11db47%7C1%7C0%7C636773207316711149&sdata=K667a3IQG4rarQ%2FOfAl > >> > yhK > >> > QQ05Cea421rgb64DlEMvs%3D&reserved=0 > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > >> ietf.org %2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40micro > >> soft.com %7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 > >> cd011db47%7C1%7C0%7C636776374678321324&sdata=33WxKh5c6qL4ln5jerpx > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=0 > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > >> ietf.org %2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40micro > >> soft.com %7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 > >> cd011db47%7C1%7C0%7C636776374678321324&sdata=33WxKh5c6qL4ln5jerpx > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=0 > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Nov 14 20:17:08 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA0E12426A for ; Wed, 14 Nov 2018 20:17:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FRcy0zHLPY9 for ; Wed, 14 Nov 2018 20:17:03 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699971286E3 for ; Wed, 14 Nov 2018 20:17:01 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id t22-v6so16080755lji.7 for ; Wed, 14 Nov 2018 20:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KgCA3Nla6HriRENebtsUui9HObMqC2mtrD4+eK8W/d4=; b=UbX8xKyWdxP0IqlG73R+hNwTIG3p2HgMJsI3usmxDZa6jJp0MZ6P92EopZUbX/6Web +JYVcPrsjX7E1y0Oh8cVzs5LDRjNfaiq/g8FY1iQgeiyNXuJn9DyapTbYT2e6IyUCq+X R1oWxS6vYHDc4xrtlX3WNzn2p2jlkThoVOVJwFlTudAdFro2Vf6VU1uepj0zUS7oNAPK kps5KaSjDEJL+/fqHfucvNJz+u9zgMr+RURluK1BldRbXDe/va0gKRq92a2w0dUuCB3l PlZK+NrWNSU2iKb4aue5SMSZknLWcf3SgG8/OIdLWHDfI+MjIgWb/imrh6Z+wSWa6mA1 /MWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KgCA3Nla6HriRENebtsUui9HObMqC2mtrD4+eK8W/d4=; b=d1WImsYTRyeiqjReHCyIfWofle4o7n3aeYmgQFFWnzzp3Z1blDKH2HyzE+MNqkjptX s23CfUHCNPsAP252dPEFT8ZJFqNz2QQ0+F1zsOmk8ZPbTbQaOk1g4YDbBeGIAttGflzT MYidCwxkcrGkaZ4jvtbzA14XhktEwMwJ/So6dosJHEXc/WiagUm5l/IFJ8iPcbjwhnq3 h/HyzNbTYkUPIXcckyZplnDvEzkO8x/gKefYUwJNrm+T+hw9nHtrlXz3bm7bJG+cgfbv CABmot5i9iT3lzJx8vqfwC03krC242fhGSFobtOQOnSfcXZilB17APqO0EI9ygIg++3J 3RoQ== X-Gm-Message-State: AGRZ1gKEdcbOjmMtM22o9HRLPuxsFrtup6caDdxts3Q0tvUKhEr4vZJ2 qxzeh5fv6emRsL/7N5GBhGqWQcMR1VfC9ezw6HY= X-Google-Smtp-Source: AJdET5cH0QjPjdBXrOwZCr1xD+nXMRtve+9xBlRAMz54El2hx2zzlt3bsipH6jvJWwPoumE9ElzJOKSHvlQW+/lo5dI= X-Received: by 2002:a2e:8643:: with SMTP id i3-v6mr2248112ljj.43.1542255419294; Wed, 14 Nov 2018 20:16:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Thu, 15 Nov 2018 09:46:47 +0530 Message-ID: To: Praveen Balasubramanian Cc: Yuchung Cheng , Bob Briscoe , Ian Swett , tcpm@ietf.org Content-Type: multipart/alternative; boundary="0000000000006b8b2e057aac52e0" Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 04:17:06 -0000 --0000000000006b8b2e057aac52e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Praveen, I think it's a good idea to require that cwnd be reduced in the absence of pacing. I've opened #2007 to track this. - jana On Wed, Nov 14, 2018 at 1:27 AM Praveen Balasubramanian wrote: > That=E2=80=99s all great assuming that RTT increase was the reason for th= e > prolonged silence. It should be possible to measure both incidences of > spurious RTOs and measured RTT increases post spurious RTOs, and that > should tell us which side we should err on. > > > > For safety reasons, should we put in the text for reducing the cwnd in > absence of pacing to keep consistency with TCP behavior, at least until > data shows otherwise? I worry that most app developers without transport > background will not have the expertise to realize the issues caused by > burst after idle. The other option is to make pacing mandatory in the > draft. > > > > *From:* Jana Iyengar > *Sent:* Monday, November 12, 2018 11:13 PM > *To:* Praveen Balasubramanian > *Cc:* Yuchung Cheng ; Bob Briscoe ; > Ian Swett ; tcpm@ietf.org > *Subject:* Re: [tcpm] Thank you for the QUIC session in tcpm > > > > On what to do with an unconfirmed RTO: So, my thought is that if you've > hit an RTO, it's been a REALLY LONG time, because we've gone through TLP(= s) > by now and failed. (This might change if we decide to combine TLP and RTO= , > but that's for a later discussion.) It's not fully clear to me what the > right responses here are, but some thoughts follow. > > > > 1/ If this was an actual increase in the RTT, it would naturally roll int= o > the SRTT and RTTVAR. We might even consider resetting the RTT estimator, > but we already know that the EWMA estimator we love takes just a while to > catch on, and I don't want to litigate changing the estimator fundamental= ly > here. > > > > 2/ Linux fq uses min_rtt IIRC, which shouldn't change as a result of an > increase in RTT. This *might* be a good time to kick the min_rtt estimato= r > to pace more conservatively. > > > > 3/ I'm not convinced that it makes sense to change the cwnd. It seems > clear that an RTT increase with the same BW should increase the cwnd if > anything, so it seems reasonable to continue with the same cwnd at least. > If the BW changed, hopefully that'll be reflected in a congestion signal, > but in the absence of a congestion signal, I think we should keep the cwn= d > as is. > > > > > > On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > Yuchung this might be worth experimenting with and getting more data on. > Maybe there should be some reaction to an unconfirmed RTO even if it is n= ot > reduction all the way to LW? I like Jana's suggestion that the > implementation SHOULD drop the cwnd even for unconfirmed RTO if not pacin= g. > > I checked the latest draft and pacing is a RECOMMENDED. I am noticing tha= t > transport algorithms in Linux and in QUIC are evolving assuming pacing > which is a function usually implemented and configured outside of the > transport. So the transport is potentially making an assumption which may > result in safety issues. For example BBR congestion control may not work > very well if pacing was disabled or misconfigured? I don=E2=80=99t know o= f any > robust solution to this other than build pacing into the transport itself= . > Pacing is also very challenging for low latency flows because of lack of > support for fine grained timers. > > -----Original Message----- > From: Yuchung Cheng > Sent: Monday, November 12, 2018 8:37 AM > To: Jana Iyengar > Cc: Praveen Balasubramanian ; Bob Briscoe < > ietf@bobbriscoe.net>; Ian Swett ; tcpm@ietf.org > Extensions > Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > > On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar wrote: > > Praveen, > > > > The point you're raising -- that we've lost the ack clock after an RTO > > -- is a reasonable point. My argument is that with pacing, cwnd > > reduction is unwarranted because in the extreme case, this collapses > > to restart after idle, where sending at cwnd with pacing is reasonable > I agree w/ Jana as well - the most generic way to treat burst due to > prior_inflight << cwnd is pacing. With QUIC's approach, when RTO fires, > cwnd remains unchanged until the ACK of the first retransmission (i.e. a > probe packet) comes back. Therefore the delay is one RTT and the potentia= l > damage is an additional cwnd-worth of burst. > > Yes the worst case is more aggressive, and it can be too much for DC > incast case if pacing isn't supported - one idea is to selective enable > that if RTT variance is very large vs RTT. > > > > > The draft does not say that a sender should reduce the cwnd if it is > > not pacing, which we should add. Does that make sense? > > > > - jana > > > > On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian > > wrote: > >> > >> Yuchung I brought that difference up in an email to the quic wg > >> earlier this week. > >> > >> In app send limited case, inflight could be very small compared to cwn= d. > >> So in QUIC there is potential to send a burst out after a long idle > >> period (with outstanding data) where TCP wouldn't. The draft claims > >> this is okay to do because RTO may have been a result of RTT increase > >> instead of loss. Is there data to suggest on which side we should > >> err? i.e. data on what are the chances that an RTO is due to an RTT > increase versus loss. > >> > >> Do you see any safety concerns with delayed reduction of cwnd in case > >> where the RTO is not spurious? > >> > >> -----Original Message----- > >> From: tcpm On Behalf Of Yuchung Cheng > >> Sent: Thursday, November 8, 2018 4:38 PM > >> To: Bob Briscoe > >> Cc: Ian Swett ; tcpm IETF list > >> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > >> > >> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe > wrote: > >> > > >> > I just wanted to thank Jana for explaining QUIC loss recovery to us > >> > (and QUIC CC as far as it goes). > >> > And thank you Jana, Ian, the chairs of both WGs (and anyone else > >> > involved) for setting it up. > >> > > >> > If one is not full-time on QUIC, it's very difficult to keep up > >> > with all the changes. But now we have a checkpoint to start from, I > >> > feel I will not be wasting people's time if I try to get involved - > >> > at least I only might say something un-QUIC occasionally, rather > >> > than nearly always. This has allowed people who understand how TCP > >> > cold be improved to help with QUIC, when working on QUIC isn't their > day job. > >> > > >> > Again, Thank you. > >> I like particularly that QUIC only reduces cwnd to 1 after the loss > >> is confirmed not upon RTO fires. It should be very feasible for TCP > >> (at least > >> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd reductions= ! > >> > >> Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt-ids= . > >> Google internally uses usec. We wish we could upstream it but RFC > >> needs to be updated. > >> > >> > > >> > > >> > Bob > >> > > >> > > >> > -- > >> > ________________________________________________________________ > >> > Bob Briscoe > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbo= b > >> > briscoe.net > > %2F&data=3D02%7C01%7Cpravb%40microsoft.com > > %7C3c4d22866 > >> > 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > >> > 7C636776374678321324&sdata=3DT%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfe= e > >> > buPcuMYlVhgDY%3D&reserved=3D0 > >> > > >> > _______________________________________________ > >> > tcpm mailing list > >> > tcpm@ietf.org > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= w > >> > w.i > >> > etf.org > > %2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micr > >> > oso > >> > ft.com > > %7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7 > >> > cd0 > >> > 11db47%7C1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfA= l > >> > yhK > >> > QQ05Cea421rgb64DlEMvs%3D&reserved=3D0 > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > >> ietf.org > > %2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro > >> soft.com > > %7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 > >> cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerp= x > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > >> ietf.org > > %2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro > >> soft.com > > %7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 > >> cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerp= x > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 > > --0000000000006b8b2e057aac52e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Praveen,

I think it's a good idea t= o require that cwnd be reduced in the absence of pacing. I've opened #2007 to tr= ack this.

- jana

On Wed, Nov 14, 2018 at 1:27 AM Praveen Balasubra= manian <pravb@microsoft.com&g= t; wrote:

That=E2=80=99s all great assuming that RTT increase = was the reason for the prolonged silence. It should be possible to measure = both incidences of spurious RTOs and measured RTT increases post spurious R= TOs, and that should tell us which side we should err on.

=C2=A0

For safety reasons, should we put in the text for re= ducing the cwnd in absence of pacing to keep consistency with TCP behavior,= at least until data shows otherwise? I worry that most app developers with= out transport background will not have the expertise to realize the issues caused by burst after idle. The o= ther option is to make pacing mandatory in the draft.

=C2=A0

From: Jana Iyengar <jri.ietf@gmail.com>
Sent: Monday, November 12, 2018 11:13 PM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Yuchung Cheng <ycheng@google.com>; Bob Briscoe <ietf@bobbriscoe.net>; Ian Swett &l= t;ianswett@google.= com>; tcpm@ietf.o= rg
Subject: Re: [tcpm] Thank you for the QUIC session in tcpm=

=C2=A0

On what to do with an unconfirmed RTO: So, my though= t is that if you've hit an RTO, it's been a REALLY LONG time, becau= se we've gone through TLP(s) by now and failed. (This might change if w= e decide to combine TLP and RTO, but that's for a later discussion.)=C2=A0 It's not fully clear to me what the right r= esponses here are, but some thoughts follow.

=C2=A0

1/ If this was an actual increase in the RTT, it wou= ld naturally roll into the SRTT and RTTVAR. We might even consider resettin= g the RTT estimator, but we already know that the EWMA estimator we love ta= kes just a while to catch on, and I don't want to litigate changing the estimator fundamentally here.=

=C2=A0

2/ Linux fq uses min_rtt IIRC, which shouldn't c= hange as a result of an increase in RTT. This *might* be a good time to kic= k the min_rtt estimator to pace more conservatively.

=C2=A0

3/ I'm not convinced that it makes sense to chan= ge the cwnd. It seems clear that an RTT increase with the same BW should in= crease the cwnd if anything, so it seems reasonable to continue with the sa= me cwnd at least. If the BW changed, hopefully that'll be reflected in a congestion signal, but in the absence of a c= ongestion signal, I think we should keep the cwnd as is.

=C2=A0

=C2=A0

On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubrama= nian <pravb@mic= rosoft.com> wrote:

Yuchung this might be worth experimenting with and g= etting more data on. Maybe there should be some reaction to an unconfirmed = RTO even if it is not reduction all the way to LW? I like Jana's sugges= tion that the implementation SHOULD drop the cwnd even for unconfirmed RTO if not pacing.

I checked the latest draft and pacing is a RECOMMENDED. I am noticing that = transport algorithms in Linux and in QUIC are evolving assuming pacing whic= h is a function usually implemented and configured outside of the transport= . So the transport is potentially making an assumption which may result in safety issues. For example BBR co= ngestion control may not work very well if pacing was disabled or misconfig= ured? I don=E2=80=99t know of any robust solution to this other than build = pacing into the transport itself. Pacing is also very challenging for low latency flows because of lack of support = for fine grained timers.

-----Original Message-----
From: Yuchung Cheng <ycheng@google.com>
Sent: Monday, November 12, 2018 8:37 AM
To: Jana Iyengar <jri.ietf@gmail.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; Bob Briscoe <ietf@bobbriscoe.net>; Ian S= wett <ianswett@= google.com>; tcpm@ietf.org Extens= ions <tcpm@ietf.org>
Subject: Re: [tcpm] Thank you for the QUIC session in tcpm

On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar <jri.ietf@gmail.com> wrote:
> Praveen,
>
> The point you're raising -- that we've lost the ack clock afte= r an RTO
> -- is a reasonable point. My argument is that with pacing, cwnd
> reduction is unwarranted because in the extreme case, this collapses <= br> > to restart after idle, where sending at cwnd with pacing is reasonable=
I agree w/ Jana as well - the most generic way to treat burst due to prior_= inflight << cwnd is pacing. With QUIC's approach, when RTO fires,= cwnd remains unchanged until the ACK of the first retransmission (i.e. a p= robe packet) comes back. Therefore the delay is one RTT and the potential damage is an additional cwnd-worth of burst.<= br>
Yes the worst case is more aggressive, and it can be too much for DC incast= case if pacing isn't supported - one idea is to selective enable that = if RTT variance is very large vs RTT.

>
> The draft does not say that a sender should reduce the cwnd if it is <= br> > not pacing, which we should add. Does that make sense?
>
> - jana
>
> On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian
> <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:
>>
>> Yuchung I brought that difference up in an email to the quic wg >> earlier this week.
>>
>> In app send limited case, inflight could be very small compared to= cwnd.
>> So in QUIC there is potential to send a burst out after a long idl= e
>> period (with outstanding data) where TCP wouldn't. The draft c= laims
>> this is okay to do because RTO may have been a result of RTT incre= ase
>> instead of loss. Is there data to suggest on which side we should =
>> err? i.e. data on what are the chances that an RTO is due to an RT= T increase versus loss.
>>
>> Do you see any safety concerns with delayed reduction of cwnd in c= ase
>> where the RTO is not spurious?
>>
>> -----Original Message-----
>> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Yuchung Cheng
>> Sent: Thursday, November 8, 2018 4:38 PM
>> To: Bob Briscoe <ietf@bobbriscoe.net>
>> Cc: Ian Swett <ianswett@google.com>; tcpm IETF list <tcpm@ietf.org>
>> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm
>>
>> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe <ietf@bobbriscoe.net> wrote: >> >
>> > I just wanted to thank Jana for explaining QUIC loss recovery= to us
>> > (and QUIC CC as far as it goes).
>> > And thank you Jana, Ian, the chairs of both WGs (and anyone e= lse
>> > involved) for setting it up.
>> >
>> > If one is not full-time on QUIC, it's very difficult to k= eep up
>> > with all the changes. But now we have a checkpoint to start f= rom, I
>> > feel I will not be wasting people's time if I try to get = involved -
>> > at least I only might say something un-QUIC occasionally, rat= her
>> > than nearly always. This has allowed people who understand ho= w TCP
>> > cold be improved to help with QUIC, when working on QUIC isn&= #39;t their day job.
>> >
>> > Again, Thank you.
>> I like particularly that QUIC only reduces cwnd to 1 after the los= s
>> is confirmed not upon RTO fires. It should be very feasible for TC= P
>> (at least
>> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd re= ductions!
>>
>> Also IMHO TCP w/ quality timestamps are almost as good as QUIC pkt= -ids.
>> Google internally uses usec. We wish we could upstream it but RFC =
>> needs to be updated.
>>
>> >
>> >
>> > Bob
>> >
>> >
>> > --
>> > _____________________________________________________________= ___
>> > Bob Briscoe
>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbob >> > briscoe.net%2F&amp;data=3D02%7C01%7Cpravb%40microsoft.com%7C3c4d22866
>> > 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%
>> > 7C636776374678321324&amp;sdata=3DT%2BWTEc42VC%2Bz%2BsmMFy= jlm37hmAwfee
>> > buPcuMYlVhgDY%3D&amp;reserved=3D0
>> >
>> > _______________________________________________
>> > tcpm mailing list
>> > tcpm@ietf.= org
>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww >> > w.i
>> > etf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40mi= cr
>> > oso
>> > ft.com%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7
>> > cd0
>> > 11db47%7C1%7C0%7C636773207316711149&amp;sdata=3DK667a3IQG= 4rarQ%2FOfAl
>> > yhK
>> > QQ05Cea421rgb64DlEMvs%3D&amp;reserved=3D0
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>>
>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.=
>> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40m= icro
>> soft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 >> cd011db47%7C1%7C0%7C636776374678321324&amp;sdata=3D33WxKh5c6qL= 4ln5jerpx
>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserved=3D0
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.=
>> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40m= icro
>> soft.com%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 >> cd011db47%7C1%7C0%7C636776374678321324&amp;sdata=3D33WxKh5c6qL= 4ln5jerpx
>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserved=3D0

--0000000000006b8b2e057aac52e0-- From nobody Wed Nov 14 20:18:08 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9771286E3 for ; Wed, 14 Nov 2018 20:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQi-vgZr0SQT for ; Wed, 14 Nov 2018 20:18:01 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2308212426A for ; Wed, 14 Nov 2018 20:18:01 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id k19-v6so16079574lji.11 for ; Wed, 14 Nov 2018 20:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Y1HD3G5XcugEInyfzHmsndk5Z/S1DSZYmX1+ldh59g=; b=JQfI3zw557ShUYqA2HI/l1jc5zwOuLvSyD90mHL1pzKNCGXPjjF6SvqhzgSgpEvR83 aelescFYCD4wsPVsPCoQ0gL8EFMjWhlrkSCVWAQSyrYdmLezS9bext3kn13RA3j8bcL+ yExvdnuDC8CLr7wtrYCQgaO01U7hJXYZaUyH7OML4IfLseNlr7A2yLuSH9Z/SkH2ZI4J uJ6Vgo0+P4MyOhDhcRVZvndC0oK4Sa44O4JzZZIs6+Nqq4pOmb77BuhUO+AOg64jxoDh qhTYSENbUPyEkwW9dKv/MM80X+W4bAyuf6OWFIiucsR8VsM1T5qvyHFfV+FwbajrKdK5 jl8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Y1HD3G5XcugEInyfzHmsndk5Z/S1DSZYmX1+ldh59g=; b=QLSQMSxS5pF17+wgqA7rtx2k7oawF7qLLk9WA/nw+BafzN3QyZF9uP2tQWPrKcEC9p jxp/Oc9LSKdX8VY73VfyL3iByP3Se8Bh6IgHsTKskQaSL1p3Xa5zbsHSmZqoZCM9Dj5P fSiW9hDp6bUp1P9YWE99Ln/vPsXtCaXtrPNqgIEOtlENdnVPXyMlpeMdIEScR9uFiShm xH1Nxdm2eBC6E8ow1GfvQ1k+u7y/vWz45TGw6sMf9MbySoPCnh3nqfEJuIyIxGR5qLxZ ItXkXqFmggXk0iotdtRjDKERCsXIbQZCn0HLVgV/mfYCiBOlrSCUCQWlFHsSPuqSxi6P dE9g== X-Gm-Message-State: AGRZ1gJ4DOIIA/AEU0Ahh/ZA6wGcDRtNveEHavblMMueDpVYCsX6ALDn E8h0qxcZcMTZqK53oGkt3NwwbKrP9aVlp8jqu5057nJr X-Google-Smtp-Source: AJdET5f4qiVArkUkNIAWy8LaMUBy5ttg9dgzUEV9DQBRVmm4hT6HOdWZcsddOn9b3KqxRld8mrbpBr0SUF71/V2jK4A= X-Received: by 2002:a2e:6c04:: with SMTP id h4-v6mr2529762ljc.92.1542255479279; Wed, 14 Nov 2018 20:17:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Thu, 15 Nov 2018 09:47:47 +0530 Message-ID: To: eric.dumazet@gmail.com Cc: tcpm@ietf.org Content-Type: multipart/alternative; boundary="000000000000fed90f057aac5518" Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 04:18:05 -0000 --000000000000fed90f057aac5518 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the clarification, Eric. I'm a bit surprised to see srtt be used by both Cubic and BBR, but that discussion's not for this thread. On Wed, Nov 14, 2018 at 9:44 PM Eric Dumazet wrote= : > > > On 11/12/2018 11:13 PM, Jana Iyengar wrote: > > On what to do with an unconfirmed RTO: So, my thought is that if you've > hit an RTO, it's been a REALLY LONG time, because we've gone through TLP(= s) > by now and failed. (This might change if we decide to combine TLP and RTO= , > but that's for a later discussion.) It's not fully clear to me what the > right responses here are, but some thoughts follow. > > > > 1/ If this was an actual increase in the RTT, it would naturally roll > into the SRTT and RTTVAR. We might even consider resetting the RTT > estimator, but we already know that the EWMA estimator we love takes just= a > while to catch on, and I don't want to litigate changing the estimator > fundamentally here. > > > > 2/ Linux fq uses min_rtt IIRC, which shouldn't change as a result of an > increase in RTT. This *might* be a good time to kick the min_rtt estimato= r > to pace more conservatively. > > linux fq does not use min_rtt, but the pacing rate set by TCP. > > pacing rate for Cubic is using SRTT ( > https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c#L806 = ) > > For BBR, pacing rate depends on various factors and phases, but SRTT is > used, not min_rtt > > https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_bbr.c#L231 > > > > > > 3/ I'm not convinced that it makes sense to change the cwnd. It seems > clear that an RTT increase with the same BW should increase the cwnd if > anything, so it seems reasonable to continue with the same cwnd at least. > If the BW changed, hopefully that'll be reflected in a congestion signal, > but in the absence of a congestion signal, I think we should keep the cwn= d > as is. > > > > > > On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian < > pravb@microsoft.com > wrote: > > > > Yuchung this might be worth experimenting with and getting more dat= a > on. Maybe there should be some reaction to an unconfirmed RTO even if it = is > not reduction all the way to LW? I like Jana's suggestion that the > implementation SHOULD drop the cwnd even for unconfirmed RTO if not pacin= g. > > > > I checked the latest draft and pacing is a RECOMMENDED. I am > noticing that transport algorithms in Linux and in QUIC are evolving > assuming pacing which is a function usually implemented and configured > outside of the transport.. So the transport is potentially making an > assumption which may result in safety issues. For example BBR congestion > control may not work very well if pacing was disabled or misconfigured? I > don=E2=80=99t know of any robust solution to this other than build pacing= into the > transport itself. Pacing is also very challenging for low latency flows > because of lack of support for fine grained timers. > > > > -----Original Message----- > > From: Yuchung Cheng > > > Sent: Monday, November 12, 2018 8:37 AM > > To: Jana Iyengar > > > Cc: Praveen Balasubramanian pravb@microsoft.com>>; Bob Briscoe ietf@bobbriscoe.net>>; Ian Swett ianswett@google.com>>; tcpm@ietf.org Extensions < > tcpm@ietf.org > > > Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > > > > On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar > wrote: > > > Praveen, > > > > > > The point you're raising -- that we've lost the ack clock after a= n > RTO > > > -- is a reasonable point. My argument is that with pacing, cwnd > > > reduction is unwarranted because in the extreme case, this > collapses > > > to restart after idle, where sending at cwnd with pacing is > reasonable > > I agree w/ Jana as well - the most generic way to treat burst due t= o > prior_inflight << cwnd is pacing. With QUIC's approach, when RTO fires, > cwnd remains unchanged until the ACK of the first retransmission (i.e. a > probe packet) comes back. Therefore the delay is one RTT and the potentia= l > damage is an additional cwnd-worth of burst. > > > > Yes the worst case is more aggressive, and it can be too much for D= C > incast case if pacing isn't supported - one idea is to selective enable > that if RTT variance is very large vs RTT. > > > > > > > > The draft does not say that a sender should reduce the cwnd if it > is > > > not pacing, which we should add. Does that make sense? > > > > > > - jana > > > > > > On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian > > > 40microsoft.com@dmarc.ietf.org>> wrote: > > >> > > >> Yuchung I brought that difference up in an email to the quic wg > > >> earlier this week. > > >> > > >> In app send limited case, inflight could be very small compared > to cwnd. > > >> So in QUIC there is potential to send a burst out after a long > idle > > >> period (with outstanding data) where TCP wouldn't. The draft > claims > > >> this is okay to do because RTO may have been a result of RTT > increase > > >> instead of loss. Is there data to suggest on which side we shoul= d > > >> err? i.e. data on what are the chances that an RTO is due to an > RTT increase versus loss. > > >> > > >> Do you see any safety concerns with delayed reduction of cwnd in > case > > >> where the RTO is not spurious? > > >> > > >> -----Original Message----- > > >> From: tcpm = > > On Behalf Of Yuchung Cheng > > >> Sent: Thursday, November 8, 2018 4:38 PM > > >> To: Bob Briscoe >> > > >> Cc: Ian Swett >= ; > tcpm IETF list > > > >> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm > > >> > > >> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe > wrote: > > >> > > > >> > I just wanted to thank Jana for explaining QUIC loss recovery > to us > > >> > (and QUIC CC as far as it goes). > > >> > And thank you Jana, Ian, the chairs of both WGs (and anyone el= se > > >> > involved) for setting it up. > > >> > > > >> > If one is not full-time on QUIC, it's very difficult to keep u= p > > >> > with all the changes. But now we have a checkpoint to start > from, I > > >> > feel I will not be wasting people's time if I try to get > involved - > > >> > at least I only might say something un-QUIC occasionally, rath= er > > >> > than nearly always. This has allowed people who understand how > TCP > > >> > cold be improved to help with QUIC, when working on QUIC isn't > their day job. > > >> > > > >> > Again, Thank you. > > >> I like particularly that QUIC only reduces cwnd to 1 after the > loss > > >> is confirmed not upon RTO fires. It should be very feasible for > TCP > > >> (at least > > >> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd > reductions! > > >> > > >> Also IMHO TCP w/ quality timestamps are almost as good as QUIC > pkt-ids. > > >> Google internally uses usec. We wish we could upstream it but RF= C > > >> needs to be updated. > > >> > > >> > > > >> > > > >> > Bob > > >> > > > >> > > > >> > -- > > >> > ______________________________________________________________= __ > > >> > Bob Briscoe > > >> > > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbob > > >> > briscoe.net %2F&data=3D02%7C01%7Cpravb= % > 40microsoft.com %7C3c4d22866 > > >> > > 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > > >> > > 7C636776374678321324&sdata=3DT%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfee > > >> > buPcuMYlVhgDY%3D&reserved=3D0 > > >> > > > >> > _______________________________________________ > > >> > tcpm mailing list > > >> > tcpm@ietf.org > > >> > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww > > >> > w.i > > >> > etf.org >%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micr > > >> > oso > > >> > ft.com >%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7 > > >> > cd0 > > >> > > 11db47%7C1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfAl > > >> > yhK > > >> > QQ05Cea421rgb64DlEMvs%3D&reserved=3D0 > > >> > > >> _______________________________________________ > > >> tcpm mailing list > > >> tcpm@ietf.org > > >> > > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > >> ietf.org >%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro > > >> soft.com >%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 > > >> > cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerpx > > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 > > >> > > >> _______________________________________________ > > >> tcpm mailing list > > >> tcpm@ietf.org > > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > >> ietf.org >%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro > > >> soft.com >%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 > > >> > cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerpx > > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000fed90f057aac5518 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the clarification, Eric. I'm a bit surprise= d to see srtt be used by both Cubic and BBR, but that discussion's not = for this thread.

On We= d, Nov 14, 2018 at 9:44 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:


On 11/12/2018 11:13 PM, Jana Iyengar wrote:
> On what to do with an unconfirmed RTO: So, my thought is that if you&#= 39;ve hit an RTO, it's been a REALLY LONG time, because we've gone = through TLP(s) by now and failed. (This might change if we decide to combin= e TLP and RTO, but that's for a later discussion.)=C2=A0 It's not f= ully clear to me what the right responses here are, but some thoughts follo= w.
>
> 1/ If this was an actual increase in the RTT, it would naturally roll = into the SRTT and RTTVAR. We might even consider resetting the RTT estimato= r, but we already know that the EWMA estimator we love takes just a while t= o catch on, and I don't want to litigate changing the estimator fundame= ntally here.
>
> 2/ Linux fq uses min_rtt IIRC, which shouldn't change as a result = of an increase in RTT. This *might* be a good time to kick the min_rtt esti= mator to pace more conservatively.

linux fq does not use min_rtt, but the pacing rate set by TCP.

pacing rate for Cubic is using SRTT ( https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_inp= ut.c#L806 )

For BBR, pacing rate depends on various factors and phases, but SRTT is use= d, not min_rtt

https://elixir.bootlin.com/lin= ux/latest/source/net/ipv4/tcp_bbr.c#L231


>
> 3/ I'm not convinced that it makes sense to change the cwnd. It se= ems clear that an RTT increase with the same BW should increase the cwnd if= anything, so it seems reasonable to continue with the same cwnd at least. = If the BW changed, hopefully that'll be reflected in a congestion signa= l, but in the absence of a congestion signal, I think we should keep the cw= nd as is.
>
>
> On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian <pravb@microsoft.com &= lt;mailto:pravb@mi= crosoft.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Yuchung this might be worth experimenting with and = getting more data on. Maybe there should be some reaction to an unconfirmed= RTO even if it is not reduction all the way to LW? I like Jana's sugge= stion that the implementation SHOULD drop the cwnd even for unconfirmed RTO= if not pacing.
>
>=C2=A0 =C2=A0 =C2=A0I checked the latest draft and pacing is a RECOMMEN= DED. I am noticing that transport algorithms in Linux and in QUIC are evolv= ing assuming pacing which is a function usually implemented and configured = outside of the transport.. So the transport is potentially making an assump= tion which may result in safety issues. For example BBR congestion control = may not work very well if pacing was disabled or misconfigured? I don=E2=80= =99t know of any robust solution to this other than build pacing into the t= ransport itself. Pacing is also very challenging for low latency flows beca= use of lack of support for fine grained timers.
>
>=C2=A0 =C2=A0 =C2=A0-----Original Message-----
>=C2=A0 =C2=A0 =C2=A0From: Yuchung Cheng <ycheng@google.com <mailto:ycheng@google.com>>
>=C2=A0 =C2=A0 =C2=A0Sent: Monday, November 12, 2018 8:37 AM
>=C2=A0 =C2=A0 =C2=A0To: Jana Iyengar <jri.ietf@gmail.com <mailto:jri.ietf@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0Cc: Praveen Balasubramanian <pravb@microsoft.com <mailto:pravb@microsoft.com<= /a>>>; Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>>; Ian Swett <= ;ianswett@google.c= om <mailto:= ianswett@google.com>>; tcpm@ietf.org <mailto:tcpm@ietf.org> Extensions <tcpm@ietf.org <mailto:tcpm@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0Subject: Re: [tcpm] Thank you for the QUIC session = in tcpm
>
>=C2=A0 =C2=A0 =C2=A0On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar <<= a href=3D"mailto:jri.ietf@gmail.com" target=3D"_blank">jri.ietf@gmail.com <mailto:jri.i= etf@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0> Praveen,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The point you're raising -- that we've= lost the ack clock after an RTO
>=C2=A0 =C2=A0 =C2=A0> -- is a reasonable point. My argument is that = with pacing, cwnd
>=C2=A0 =C2=A0 =C2=A0> reduction is unwarranted because in the extrem= e case, this collapses
>=C2=A0 =C2=A0 =C2=A0> to restart after idle, where sending at cwnd w= ith pacing is reasonable
>=C2=A0 =C2=A0 =C2=A0I agree w/ Jana as well - the most generic way to t= reat burst due to prior_inflight << cwnd is pacing. With QUIC's a= pproach, when RTO fires, cwnd remains unchanged until the ACK of the first = retransmission (i.e. a probe packet) comes back. Therefore the delay is one= RTT and the potential damage is an additional cwnd-worth of burst.
>
>=C2=A0 =C2=A0 =C2=A0Yes the worst case is more aggressive, and it can b= e too much for DC incast case if pacing isn't supported - one idea is t= o selective enable that if RTT variance is very large vs RTT.
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The draft does not say that a sender should re= duce the cwnd if it is
>=C2=A0 =C2=A0 =C2=A0> not pacing, which we should add. Does that mak= e sense?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> - jana
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasub= ramanian
>=C2=A0 =C2=A0 =C2=A0> <pravb=3D40microsoft.com@dmarc.ietf.org <ma= ilto:40= microsoft.com@dmarc.ietf.org>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Yuchung I brought that difference up in an= email to the quic wg
>=C2=A0 =C2=A0 =C2=A0>> earlier this week.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> In app send limited case, inflight could b= e very small compared to cwnd.
>=C2=A0 =C2=A0 =C2=A0>> So in QUIC there is potential to send a bu= rst out after a long idle
>=C2=A0 =C2=A0 =C2=A0>> period (with outstanding data) where TCP w= ouldn't. The draft claims
>=C2=A0 =C2=A0 =C2=A0>> this is okay to do because RTO may have be= en a result of RTT increase
>=C2=A0 =C2=A0 =C2=A0>> instead of loss. Is there data to suggest = on which side we should
>=C2=A0 =C2=A0 =C2=A0>> err? i.e. data on what are the chances tha= t an RTO is due to an RTT increase versus loss.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Do you see any safety concerns with delaye= d reduction of cwnd in case
>=C2=A0 =C2=A0 =C2=A0>> where the RTO is not spurious?
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0>> From: tcpm <tcpm-bounces@ietf.org <mailto:tcpm-bounces@ietf.org<= /a>>> On Behalf Of Yuchung Cheng
>=C2=A0 =C2=A0 =C2=A0>> Sent: Thursday, November 8, 2018 4:38 PM >=C2=A0 =C2=A0 =C2=A0>> To: Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net= >>
>=C2=A0 =C2=A0 =C2=A0>> Cc: Ian Swett <ianswett@google.com <mailto:ianswett@google.com&g= t;>; tcpm IETF list <tcpm@ietf.org <mailto:tcpm@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0>> Subject: Re: [tcpm] Thank you for the QUIC= session in tcpm
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On Thu, Nov 8, 2018 at 3:14 AM, Bob Brisco= e <ietf@bobbris= coe.net <mailto:ietf@bobbriscoe.net>> wrote:
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > I just wanted to thank Jana for expla= ining QUIC loss recovery to us
>=C2=A0 =C2=A0 =C2=A0>> > (and QUIC CC as far as it goes).
>=C2=A0 =C2=A0 =C2=A0>> > And thank you Jana, Ian, the chairs o= f both WGs (and anyone else
>=C2=A0 =C2=A0 =C2=A0>> > involved) for setting it up.
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > If one is not full-time on QUIC, it&#= 39;s very difficult to keep up
>=C2=A0 =C2=A0 =C2=A0>> > with all the changes. But now we have= a checkpoint to start from, I
>=C2=A0 =C2=A0 =C2=A0>> > feel I will not be wasting people'= ;s time if I try to get involved -
>=C2=A0 =C2=A0 =C2=A0>> > at least I only might say something u= n-QUIC occasionally, rather
>=C2=A0 =C2=A0 =C2=A0>> > than nearly always. This has allowed = people who understand how TCP
>=C2=A0 =C2=A0 =C2=A0>> > cold be improved to help with QUIC, w= hen working on QUIC isn't their day job.
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > Again, Thank you.
>=C2=A0 =C2=A0 =C2=A0>> I like particularly that QUIC only reduces= cwnd to 1 after the loss
>=C2=A0 =C2=A0 =C2=A0>> is confirmed not upon RTO fires. It should= be very feasible for TCP
>=C2=A0 =C2=A0 =C2=A0>> (at least
>=C2=A0 =C2=A0 =C2=A0>> Linux) w/ TCP timestamps. It'll save a= lot of spurious cwnd reductions!
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Also IMHO TCP w/ quality timestamps are al= most as good as QUIC pkt-ids.
>=C2=A0 =C2=A0 =C2=A0>> Google internally uses usec. We wish we co= uld upstream it but RFC
>=C2=A0 =C2=A0 =C2=A0>> needs to be updated.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > Bob
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > --
>=C2=A0 =C2=A0 =C2=A0>> > _____________________________________= ___________________________
>=C2=A0 =C2=A0 =C2=A0>> > Bob Briscoe
>=C2=A0 =C2=A0 =C2=A0>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbo= b
>=C2=A0 =C2=A0 =C2=A0>> > briscoe.net <http://briscoe.net>%2F&a= mp;amp;data=3D02%7C01%7Cpravb%40microsoft.com <http://40microsoft.com&= gt;%7C3c4d22866
>=C2=A0 =C2=A0 =C2=A0>> > 8444691c16808d648bd2ce9%7C72f988bf86f= 141af91ab2d7cd011db47%7C1%7C0%
>=C2=A0 =C2=A0 =C2=A0>> > 7C636776374678321324&amp;sdata=3D= T%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfee
>=C2=A0 =C2=A0 =C2=A0>> > buPcuMYlVhgDY%3D&amp;reserved=3D0=
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > _____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0>> > tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0>> > tcpm@ietf.org <mailto:tcpm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= w
>=C2=A0 =C2=A0 =C2=A0>> > w.i
>=C2=A0 =C2=A0 =C2=A0>> > etf.org <http://etf.org>%2Fmailman%2Flistin= fo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40micr
>=C2=A0 =C2=A0 =C2=A0>> > oso
>=C2=A0 =C2=A0 =C2=A0>> > ft.com <http://ft.com>%7Cf0911eeb74d7446f424508= d645dbb779%7C72f988bf86f141af91ab2d7
>=C2=A0 =C2=A0 =C2=A0>> > cd0
>=C2=A0 =C2=A0 =C2=A0>> > 11db47%7C1%7C0%7C636773207316711149&a= mp;amp;sdata=3DK667a3IQG4rarQ%2FOfAl
>=C2=A0 =C2=A0 =C2=A0>> > yhK
>=C2=A0 =C2=A0 =C2=A0>> > QQ05Cea421rgb64DlEMvs%3D&amp;rese= rved=3D0
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> __________________________________________= _____
>=C2=A0 =C2=A0 =C2=A0>> tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>=C2=A0 =C2=A0 =C2=A0>> ietf.org <http://ietf.org>%2Fmailman%2Flistinfo%= 2Ftcpm&amp;data=3D02%7C01%7Cpravb%40micro
>=C2=A0 =C2=A0 =C2=A0>> soft.com <http://soft.com>%7C3c4d228668444691c16= 808d648bd2ce9%7C72f988bf86f141af91ab2d7
>=C2=A0 =C2=A0 =C2=A0>> cd011db47%7C1%7C0%7C636776374678321324&= ;amp;sdata=3D33WxKh5c6qL4ln5jerpx
>=C2=A0 =C2=A0 =C2=A0>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserve= d=3D0
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> __________________________________________= _____
>=C2=A0 =C2=A0 =C2=A0>> tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>=C2=A0 =C2=A0 =C2=A0>> ietf.org <http://ietf.org>%2Fmailman%2Flistinfo%= 2Ftcpm&amp;data=3D02%7C01%7Cpravb%40micro
>=C2=A0 =C2=A0 =C2=A0>> soft.com <http://soft.com>%7C3c4d228668444691c16= 808d648bd2ce9%7C72f988bf86f141af91ab2d7
>=C2=A0 =C2=A0 =C2=A0>> cd011db47%7C1%7C0%7C636776374678321324&= ;amp;sdata=3D33WxKh5c6qL4ln5jerpx
>=C2=A0 =C2=A0 =C2=A0>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserve= d=3D0
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000fed90f057aac5518-- From nobody Thu Nov 15 09:15:51 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922BD12F1A5 for ; Thu, 15 Nov 2018 09:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iwxcukaiaibq for ; Thu, 15 Nov 2018 09:15:47 -0800 (PST) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636FE124BAA for ; Thu, 15 Nov 2018 09:15:47 -0800 (PST) Received: by mail-oi1-x233.google.com with SMTP id r127-v6so17372516oie.3 for ; Thu, 15 Nov 2018 09:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OeN5+q3JItYrwtPS9KXoDWT17IhaPekTjIaYsRfTD+s=; b=A+Z0fFPjo2xXUZnxLsb4lvbYVfWb2KTGHtsP542rb+dhP097IholUWUyXxIukZVimE hmzzwDLwqAYwMUCfeTVqdzdk6xiN0C3/3qDTXB7ZH+biY0W5Y+Lpj7N4OdS5J4QLxlXC tADua60RQ0yJB+R83twQSe7CjIyCtSsSvV6HhCH6uzImOpR9lIahsyBGOrvAoHntnFHS PwkEKDO7cjBkwFBM61IIxkUF7ORzox30ZAA8pg2DR5OO4wAQmhecMzu4I0vywHYdJByX 7zpabbWgAyjfSmCg0MMeAzyC4RH+tGBQLjK60YBomkd0wsQR6hKjBda6GDPL6BZXQCA2 JpAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OeN5+q3JItYrwtPS9KXoDWT17IhaPekTjIaYsRfTD+s=; b=ewuh8i9V0aWu+JXsWeyrWkE06TFUkkvrmFImgoxzSbY/o8QxULVGQXgQK/NMEgyojj 7eA85JVZTQDO2zlLLD6PeBVCyuBV7H7qXHlNIfLvdprK8FQZ2C9Z3DTea9HUqmCOXA6H UYnkoTGJUUc8EwPBAG1cUhYUHw9vjemrvDAeqnENh58TJZxTtHsjZKVwxUpcPoYag8r3 RiBziPQn8Y7slTG+cvF8bdFwIX0gDa4NzbADN9wfx1U1EMDou4LPKpxcx3k0dBewKHNJ 6LNZbuKWX3Eg2TcbA4p2qwviWOQmsc09+8Lmd8vWDofbwqXjQvcGqqDsEKbCtcyE6nO4 lEwg== X-Gm-Message-State: AGRZ1gJ7/cPyjV/xLxgVQ3tFfk+UhiDPcB40LcN6kxoulSHZtMTaAnjd fD842YPz/QIgJPlzkKYZ5ekHMLTTjuhC5iHxVoHl7g== X-Google-Smtp-Source: AJdET5cXL4IgM1GToed1BoTzzr5K3pRoiPAirp3o5e1wlzwJ2zfcI95CwJau06fMtdqwGPNZojOabu/4RDsVqc+pGpo= X-Received: by 2002:aca:b05:: with SMTP id 5-v6mr4334537oil.157.1542302146112; Thu, 15 Nov 2018 09:15:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Thu, 15 Nov 2018 12:15:38 -0500 Message-ID: To: Jana Iyengar Cc: Eric Dumazet , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008eb639057ab733fb" Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2018 17:15:50 -0000 --0000000000008eb639057ab733fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 14, 2018 at 11:18 PM Jana Iyengar wrote: > Thanks for the clarification, Eric. I'm a bit surprised to see srtt be > used by both Cubic and BBR, but that discussion's not for this thread. > Just to add context (sorry to dilute the thread!), the spot in Linux TCP BBR that Eric pointed to that is using srtt is the initialization code (bbr_init_pacing_rate_from_rtt()). The code is using srtt here to compute a pacing rate (via pacing_rate =3D gain * cwd / srtt) largely because Linux T= CP can hot-swap congestion control modules. Because of that possibility, the cwnd and srtt that BBR inherits at initialization may have been from a buffer-bloated CUBIC/Reno connection, where srtt may have bloated in proportion to cwnd, so that cwd / srtt is generally a better approximation to the available bandwidth than cwnd / min_rtt. As you would imagine, after that initialization, Linux TCP BBR does not use srtt (or min_rtt) to update the pacing rate; it uses a function of the estimated bandwidth. best, neal > On Wed, Nov 14, 2018 at 9:44 PM Eric Dumazet > wrote: > >> >> >> On 11/12/2018 11:13 PM, Jana Iyengar wrote: >> > On what to do with an unconfirmed RTO: So, my thought is that if you'v= e >> hit an RTO, it's been a REALLY LONG time, because we've gone through TLP= (s) >> by now and failed. (This might change if we decide to combine TLP and RT= O, >> but that's for a later discussion.) It's not fully clear to me what the >> right responses here are, but some thoughts follow. >> > >> > 1/ If this was an actual increase in the RTT, it would naturally roll >> into the SRTT and RTTVAR. We might even consider resetting the RTT >> estimator, but we already know that the EWMA estimator we love takes jus= t a >> while to catch on, and I don't want to litigate changing the estimator >> fundamentally here. >> > >> > 2/ Linux fq uses min_rtt IIRC, which shouldn't change as a result of a= n >> increase in RTT. This *might* be a good time to kick the min_rtt estimat= or >> to pace more conservatively. >> >> linux fq does not use min_rtt, but the pacing rate set by TCP. >> >> pacing rate for Cubic is using SRTT ( >> https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c#L806 >> ) >> >> For BBR, pacing rate depends on various factors and phases, but SRTT is >> used, not min_rtt >> >> https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_bbr.c#L231 >> >> >> > >> > 3/ I'm not convinced that it makes sense to change the cwnd. It seems >> clear that an RTT increase with the same BW should increase the cwnd if >> anything, so it seems reasonable to continue with the same cwnd at least= . >> If the BW changed, hopefully that'll be reflected in a congestion signal= , >> but in the absence of a congestion signal, I think we should keep the cw= nd >> as is. >> > >> > >> > On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian < >> pravb@microsoft.com > wrote: >> > >> > Yuchung this might be worth experimenting with and getting more >> data on. Maybe there should be some reaction to an unconfirmed RTO even = if >> it is not reduction all the way to LW? I like Jana's suggestion that the >> implementation SHOULD drop the cwnd even for unconfirmed RTO if not paci= ng. >> > >> > I checked the latest draft and pacing is a RECOMMENDED. I am >> noticing that transport algorithms in Linux and in QUIC are evolving >> assuming pacing which is a function usually implemented and configured >> outside of the transport.. So the transport is potentially making an >> assumption which may result in safety issues. For example BBR congestion >> control may not work very well if pacing was disabled or misconfigured? = I >> don=E2=80=99t know of any robust solution to this other than build pacin= g into the >> transport itself. Pacing is also very challenging for low latency flows >> because of lack of support for fine grained timers. >> > >> > -----Original Message----- >> > From: Yuchung Cheng > >> > Sent: Monday, November 12, 2018 8:37 AM >> > To: Jana Iyengar > >> > Cc: Praveen Balasubramanian > pravb@microsoft.com>>; Bob Briscoe > ietf@bobbriscoe.net>>; Ian Swett > ianswett@google.com>>; tcpm@ietf.org Extensions < >> tcpm@ietf.org > >> > Subject: Re: [tcpm] Thank you for the QUIC session in tcpm >> > >> > On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar > > wrote: >> > > Praveen, >> > > >> > > The point you're raising -- that we've lost the ack clock after >> an RTO >> > > -- is a reasonable point. My argument is that with pacing, cwnd >> > > reduction is unwarranted because in the extreme case, this >> collapses >> > > to restart after idle, where sending at cwnd with pacing is >> reasonable >> > I agree w/ Jana as well - the most generic way to treat burst due >> to prior_inflight << cwnd is pacing. With QUIC's approach, when RTO fire= s, >> cwnd remains unchanged until the ACK of the first retransmission (i.e. a >> probe packet) comes back. Therefore the delay is one RTT and the potenti= al >> damage is an additional cwnd-worth of burst. >> > >> > Yes the worst case is more aggressive, and it can be too much for >> DC incast case if pacing isn't supported - one idea is to selective enab= le >> that if RTT variance is very large vs RTT. >> > >> > > >> > > The draft does not say that a sender should reduce the cwnd if i= t >> is >> > > not pacing, which we should add. Does that make sense? >> > > >> > > - jana >> > > >> > > On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian >> > > > 40microsoft.com@dmarc.ietf.org>> wrote: >> > >> >> > >> Yuchung I brought that difference up in an email to the quic wg >> > >> earlier this week. >> > >> >> > >> In app send limited case, inflight could be very small compared >> to cwnd. >> > >> So in QUIC there is potential to send a burst out after a long >> idle >> > >> period (with outstanding data) where TCP wouldn't. The draft >> claims >> > >> this is okay to do because RTO may have been a result of RTT >> increase >> > >> instead of loss. Is there data to suggest on which side we shou= ld >> > >> err? i.e. data on what are the chances that an RTO is due to an >> RTT increase versus loss. >> > >> >> > >> Do you see any safety concerns with delayed reduction of cwnd i= n >> case >> > >> where the RTO is not spurious? >> > >> >> > >> -----Original Message----- >> > >> From: tcpm > >> On Behalf Of Yuchung Cheng >> > >> Sent: Thursday, November 8, 2018 4:38 PM >> > >> To: Bob Briscoe > >> >> > >> Cc: Ian Swett = >; >> tcpm IETF list > >> > >> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm >> > >> >> > >> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe > > wrote: >> > >> > >> > >> > I just wanted to thank Jana for explaining QUIC loss recovery >> to us >> > >> > (and QUIC CC as far as it goes). >> > >> > And thank you Jana, Ian, the chairs of both WGs (and anyone >> else >> > >> > involved) for setting it up. >> > >> > >> > >> > If one is not full-time on QUIC, it's very difficult to keep = up >> > >> > with all the changes. But now we have a checkpoint to start >> from, I >> > >> > feel I will not be wasting people's time if I try to get >> involved - >> > >> > at least I only might say something un-QUIC occasionally, >> rather >> > >> > than nearly always. This has allowed people who understand ho= w >> TCP >> > >> > cold be improved to help with QUIC, when working on QUIC isn'= t >> their day job. >> > >> > >> > >> > Again, Thank you. >> > >> I like particularly that QUIC only reduces cwnd to 1 after the >> loss >> > >> is confirmed not upon RTO fires. It should be very feasible for >> TCP >> > >> (at least >> > >> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd >> reductions! >> > >> >> > >> Also IMHO TCP w/ quality timestamps are almost as good as QUIC >> pkt-ids. >> > >> Google internally uses usec. We wish we could upstream it but R= FC >> > >> needs to be updated. >> > >> >> > >> > >> > >> > >> > >> > Bob >> > >> > >> > >> > >> > >> > -- >> > >> > >> ________________________________________________________________ >> > >> > Bob Briscoe >> > >> > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbob >> > >> > briscoe.net %2F&data=3D02%7C01%7Cprav= b% >> 40microsoft.com %7C3c4d22866 >> > >> > >> 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% >> > >> > >> 7C636776374678321324&sdata=3DT%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfee >> > >> > buPcuMYlVhgDY%3D&reserved=3D0 >> > >> > >> > >> > _______________________________________________ >> > >> > tcpm mailing list >> > >> > tcpm@ietf.org >> > >> > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww >> > >> > w.i >> > >> > etf.org > >%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micr >> > >> > oso >> > >> > ft.com > >%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7 >> > >> > cd0 >> > >> > >> 11db47%7C1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfAl >> > >> > yhK >> > >> > QQ05Cea421rgb64DlEMvs%3D&reserved=3D0 >> > >> >> > >> _______________________________________________ >> > >> tcpm mailing list >> > >> tcpm@ietf.org >> > >> >> > >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >> > >> ietf.org > >%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro >> > >> soft.com > >%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 >> > >> >> cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerpx >> > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 >> > >> >> > >> _______________________________________________ >> > >> tcpm mailing list >> > >> tcpm@ietf.org >> > >> >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >> > >> ietf.org > >%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro >> > >> soft.com > >%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 >> > >> >> cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerpx >> > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 >> > >> > >> > >> > _______________________________________________ >> > tcpm mailing list >> > tcpm@ietf.org >> > https://www.ietf.org/mailman/listinfo/tcpm >> > >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000008eb639057ab733fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 14= , 2018 at 11:18 PM Jana Iyengar <j= ri.ietf@gmail.com> wrote:
Thanks for the clarification, Eric. I'm a bit surprised = to see srtt be used by both Cubic and BBR, but that discussion's not fo= r this thread.

Just to add context (sorry = to dilute the thread!), the spot in Linux TCP BBR that Eric pointed to that= is using srtt is the initialization code (bbr_init_pacing_rate_from_rtt())= . The code is using srtt here to compute a pacing rate (via pacing_rate =3D= gain * cwd / srtt) largely because Linux TCP can hot-swap congestion contr= ol modules. Because of that possibility, the cwnd and srtt that BBR inherit= s at initialization may have been from a buffer-bloated CUBIC/Reno connecti= on, where srtt may have bloated in proportion to cwnd, so that cwd / srtt i= s generally a better approximation to the available bandwidth than cwnd / m= in_rtt.=C2=A0 As you would imagine, after that initialization, Linux TCP BB= R does not use srtt (or min_rtt) to update the pacing rate; it uses a funct= ion of the estimated bandwidth.

best,
neal

=C2=A0
On Wed, = Nov 14, 2018 at 9:44 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:


On 11/12/2018 11:13 PM, Jana Iyengar wrote:
> On what to do with an unconfirmed RTO: So, my thought is that if you&#= 39;ve hit an RTO, it's been a REALLY LONG time, because we've gone = through TLP(s) by now and failed. (This might change if we decide to combin= e TLP and RTO, but that's for a later discussion.)=C2=A0 It's not f= ully clear to me what the right responses here are, but some thoughts follo= w.
>
> 1/ If this was an actual increase in the RTT, it would naturally roll = into the SRTT and RTTVAR. We might even consider resetting the RTT estimato= r, but we already know that the EWMA estimator we love takes just a while t= o catch on, and I don't want to litigate changing the estimator fundame= ntally here.
>
> 2/ Linux fq uses min_rtt IIRC, which shouldn't change as a result = of an increase in RTT. This *might* be a good time to kick the min_rtt esti= mator to pace more conservatively.

linux fq does not use min_rtt, but the pacing rate set by TCP.

pacing rate for Cubic is using SRTT ( https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_inp= ut.c#L806 )

For BBR, pacing rate depends on various factors and phases, but SRTT is use= d, not min_rtt

https://elixir.bootlin.com/lin= ux/latest/source/net/ipv4/tcp_bbr.c#L231


>
> 3/ I'm not convinced that it makes sense to change the cwnd. It se= ems clear that an RTT increase with the same BW should increase the cwnd if= anything, so it seems reasonable to continue with the same cwnd at least. = If the BW changed, hopefully that'll be reflected in a congestion signa= l, but in the absence of a congestion signal, I think we should keep the cw= nd as is.
>
>
> On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian <pravb@microsoft.com &= lt;mailto:pravb@mi= crosoft.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Yuchung this might be worth experimenting with and = getting more data on. Maybe there should be some reaction to an unconfirmed= RTO even if it is not reduction all the way to LW? I like Jana's sugge= stion that the implementation SHOULD drop the cwnd even for unconfirmed RTO= if not pacing.
>
>=C2=A0 =C2=A0 =C2=A0I checked the latest draft and pacing is a RECOMMEN= DED. I am noticing that transport algorithms in Linux and in QUIC are evolv= ing assuming pacing which is a function usually implemented and configured = outside of the transport.. So the transport is potentially making an assump= tion which may result in safety issues. For example BBR congestion control = may not work very well if pacing was disabled or misconfigured? I don=E2=80= =99t know of any robust solution to this other than build pacing into the t= ransport itself. Pacing is also very challenging for low latency flows beca= use of lack of support for fine grained timers.
>
>=C2=A0 =C2=A0 =C2=A0-----Original Message-----
>=C2=A0 =C2=A0 =C2=A0From: Yuchung Cheng <ycheng@google.com <mailto:ycheng@google.com>>
>=C2=A0 =C2=A0 =C2=A0Sent: Monday, November 12, 2018 8:37 AM
>=C2=A0 =C2=A0 =C2=A0To: Jana Iyengar <jri.ietf@gmail.com <mailto:jri.ietf@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0Cc: Praveen Balasubramanian <pravb@microsoft.com <mailto:pravb@microsoft.com<= /a>>>; Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>>; Ian Swett <= ;ianswett@google.c= om <mailto:= ianswett@google.com>>; tcpm@ietf.org <mailto:tcpm@ietf.org> Extensions <tcpm@ietf.org <mailto:tcpm@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0Subject: Re: [tcpm] Thank you for the QUIC session = in tcpm
>
>=C2=A0 =C2=A0 =C2=A0On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar <<= a href=3D"mailto:jri.ietf@gmail.com" target=3D"_blank">jri.ietf@gmail.com <mailto:jri.i= etf@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0> Praveen,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The point you're raising -- that we've= lost the ack clock after an RTO
>=C2=A0 =C2=A0 =C2=A0> -- is a reasonable point. My argument is that = with pacing, cwnd
>=C2=A0 =C2=A0 =C2=A0> reduction is unwarranted because in the extrem= e case, this collapses
>=C2=A0 =C2=A0 =C2=A0> to restart after idle, where sending at cwnd w= ith pacing is reasonable
>=C2=A0 =C2=A0 =C2=A0I agree w/ Jana as well - the most generic way to t= reat burst due to prior_inflight << cwnd is pacing. With QUIC's a= pproach, when RTO fires, cwnd remains unchanged until the ACK of the first = retransmission (i.e. a probe packet) comes back. Therefore the delay is one= RTT and the potential damage is an additional cwnd-worth of burst.
>
>=C2=A0 =C2=A0 =C2=A0Yes the worst case is more aggressive, and it can b= e too much for DC incast case if pacing isn't supported - one idea is t= o selective enable that if RTT variance is very large vs RTT.
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The draft does not say that a sender should re= duce the cwnd if it is
>=C2=A0 =C2=A0 =C2=A0> not pacing, which we should add. Does that mak= e sense?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> - jana
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasub= ramanian
>=C2=A0 =C2=A0 =C2=A0> <pravb=3D40microsoft.com@dmarc.ietf.org <ma= ilto:40= microsoft.com@dmarc.ietf.org>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Yuchung I brought that difference up in an= email to the quic wg
>=C2=A0 =C2=A0 =C2=A0>> earlier this week.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> In app send limited case, inflight could b= e very small compared to cwnd.
>=C2=A0 =C2=A0 =C2=A0>> So in QUIC there is potential to send a bu= rst out after a long idle
>=C2=A0 =C2=A0 =C2=A0>> period (with outstanding data) where TCP w= ouldn't. The draft claims
>=C2=A0 =C2=A0 =C2=A0>> this is okay to do because RTO may have be= en a result of RTT increase
>=C2=A0 =C2=A0 =C2=A0>> instead of loss. Is there data to suggest = on which side we should
>=C2=A0 =C2=A0 =C2=A0>> err? i.e. data on what are the chances tha= t an RTO is due to an RTT increase versus loss.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Do you see any safety concerns with delaye= d reduction of cwnd in case
>=C2=A0 =C2=A0 =C2=A0>> where the RTO is not spurious?
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0>> From: tcpm <tcpm-bounces@ietf.org <mailto:tcpm-bounces@ietf.org<= /a>>> On Behalf Of Yuchung Cheng
>=C2=A0 =C2=A0 =C2=A0>> Sent: Thursday, November 8, 2018 4:38 PM >=C2=A0 =C2=A0 =C2=A0>> To: Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net= >>
>=C2=A0 =C2=A0 =C2=A0>> Cc: Ian Swett <ianswett@google.com <mailto:ianswett@google.com&g= t;>; tcpm IETF list <tcpm@ietf.org <mailto:tcpm@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0>> Subject: Re: [tcpm] Thank you for the QUIC= session in tcpm
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On Thu, Nov 8, 2018 at 3:14 AM, Bob Brisco= e <ietf@bobbris= coe.net <mailto:ietf@bobbriscoe.net>> wrote:
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > I just wanted to thank Jana for expla= ining QUIC loss recovery to us
>=C2=A0 =C2=A0 =C2=A0>> > (and QUIC CC as far as it goes).
>=C2=A0 =C2=A0 =C2=A0>> > And thank you Jana, Ian, the chairs o= f both WGs (and anyone else
>=C2=A0 =C2=A0 =C2=A0>> > involved) for setting it up.
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > If one is not full-time on QUIC, it&#= 39;s very difficult to keep up
>=C2=A0 =C2=A0 =C2=A0>> > with all the changes. But now we have= a checkpoint to start from, I
>=C2=A0 =C2=A0 =C2=A0>> > feel I will not be wasting people'= ;s time if I try to get involved -
>=C2=A0 =C2=A0 =C2=A0>> > at least I only might say something u= n-QUIC occasionally, rather
>=C2=A0 =C2=A0 =C2=A0>> > than nearly always. This has allowed = people who understand how TCP
>=C2=A0 =C2=A0 =C2=A0>> > cold be improved to help with QUIC, w= hen working on QUIC isn't their day job.
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > Again, Thank you.
>=C2=A0 =C2=A0 =C2=A0>> I like particularly that QUIC only reduces= cwnd to 1 after the loss
>=C2=A0 =C2=A0 =C2=A0>> is confirmed not upon RTO fires. It should= be very feasible for TCP
>=C2=A0 =C2=A0 =C2=A0>> (at least
>=C2=A0 =C2=A0 =C2=A0>> Linux) w/ TCP timestamps. It'll save a= lot of spurious cwnd reductions!
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Also IMHO TCP w/ quality timestamps are al= most as good as QUIC pkt-ids.
>=C2=A0 =C2=A0 =C2=A0>> Google internally uses usec. We wish we co= uld upstream it but RFC
>=C2=A0 =C2=A0 =C2=A0>> needs to be updated.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > Bob
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > --
>=C2=A0 =C2=A0 =C2=A0>> > _____________________________________= ___________________________
>=C2=A0 =C2=A0 =C2=A0>> > Bob Briscoe
>=C2=A0 =C2=A0 =C2=A0>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbo= b
>=C2=A0 =C2=A0 =C2=A0>> > briscoe.net <http://briscoe.net>%2F&a= mp;amp;data=3D02%7C01%7Cpravb%40microsoft.com <http://40microsoft.com&= gt;%7C3c4d22866
>=C2=A0 =C2=A0 =C2=A0>> > 8444691c16808d648bd2ce9%7C72f988bf86f= 141af91ab2d7cd011db47%7C1%7C0%
>=C2=A0 =C2=A0 =C2=A0>> > 7C636776374678321324&amp;sdata=3D= T%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfee
>=C2=A0 =C2=A0 =C2=A0>> > buPcuMYlVhgDY%3D&amp;reserved=3D0=
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > _____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0>> > tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0>> > tcpm@ietf.org <mailto:tcpm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= w
>=C2=A0 =C2=A0 =C2=A0>> > w.i
>=C2=A0 =C2=A0 =C2=A0>> > etf.org <http://etf.org>%2Fmailman%2Flistin= fo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40micr
>=C2=A0 =C2=A0 =C2=A0>> > oso
>=C2=A0 =C2=A0 =C2=A0>> > ft.com <http://ft.com>%7Cf0911eeb74d7446f424508= d645dbb779%7C72f988bf86f141af91ab2d7
>=C2=A0 =C2=A0 =C2=A0>> > cd0
>=C2=A0 =C2=A0 =C2=A0>> > 11db47%7C1%7C0%7C636773207316711149&a= mp;amp;sdata=3DK667a3IQG4rarQ%2FOfAl
>=C2=A0 =C2=A0 =C2=A0>> > yhK
>=C2=A0 =C2=A0 =C2=A0>> > QQ05Cea421rgb64DlEMvs%3D&amp;rese= rved=3D0
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> __________________________________________= _____
>=C2=A0 =C2=A0 =C2=A0>> tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>=C2=A0 =C2=A0 =C2=A0>> ietf.org <http://ietf.org>%2Fmailman%2Flistinfo%= 2Ftcpm&amp;data=3D02%7C01%7Cpravb%40micro
>=C2=A0 =C2=A0 =C2=A0>> soft.com <http://soft.com>%7C3c4d228668444691c16= 808d648bd2ce9%7C72f988bf86f141af91ab2d7
>=C2=A0 =C2=A0 =C2=A0>> cd011db47%7C1%7C0%7C636776374678321324&= ;amp;sdata=3D33WxKh5c6qL4ln5jerpx
>=C2=A0 =C2=A0 =C2=A0>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserve= d=3D0
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> __________________________________________= _____
>=C2=A0 =C2=A0 =C2=A0>> tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>=C2=A0 =C2=A0 =C2=A0>> ietf.org <http://ietf.org>%2Fmailman%2Flistinfo%= 2Ftcpm&amp;data=3D02%7C01%7Cpravb%40micro
>=C2=A0 =C2=A0 =C2=A0>> soft.com <http://soft.com>%7C3c4d228668444691c16= 808d648bd2ce9%7C72f988bf86f141af91ab2d7
>=C2=A0 =C2=A0 =C2=A0>> cd011db47%7C1%7C0%7C636776374678321324&= ;amp;sdata=3D33WxKh5c6qL4ln5jerpx
>=C2=A0 =C2=A0 =C2=A0>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserve= d=3D0
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000008eb639057ab733fb-- From nobody Sun Nov 18 13:16:50 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E59F7128CF3 for ; Sun, 18 Nov 2018 13:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yFbShAIYpOS for ; Sun, 18 Nov 2018 13:16:46 -0800 (PST) Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803:203:178:142:146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D1A127B92 for ; Sun, 18 Nov 2018 13:16:45 -0800 (PST) Received: from mail-it1-f181.google.com (mail-it1-f181.google.com [209.85.166.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 061F527879A for ; Mon, 19 Nov 2018 06:16:43 +0900 (JST) Received: by mail-it1-f181.google.com with SMTP id o19so5363455itg.5 for ; Sun, 18 Nov 2018 13:16:42 -0800 (PST) X-Gm-Message-State: AGRZ1gLczx5PWS3iDitdExuxgjppdftHy6Y5gB9ZZnWJ+8XuQRklWbOu exRjbW206B/1zD5g85aYfJPkXQfYESCETH//aEw= X-Google-Smtp-Source: AJdET5dDfcmMqD7ESoIz0/YuFkkclHwqDYekUWTpgcHsS64xa2xB5e1t58lOFOu59+RQWwEQBcPfTxsA69uhzvN3A5g= X-Received: by 2002:a02:98bb:: with SMTP id q56mr17559938jaj.24.1542575801628; Sun, 18 Nov 2018 13:16:41 -0800 (PST) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Sun, 18 Nov 2018 13:16:30 -0800 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b1fcfe057af6ea5a" Archived-At: Subject: [tcpm] draft minutes uploaded X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Nov 2018 21:16:48 -0000 --000000000000b1fcfe057af6ea5a Content-Type: text/plain; charset="UTF-8" Hi, I just uploaded a draft minutes for bangkok meeting. Please let the chairs know if you have corrections, suggestions or questions. https://datatracker.ietf.org/doc/minutes-103-tcpm/ Thanks, -- tcpm co-chairs --000000000000b1fcfe057af6ea5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I just uploaded a draft minutes for ban= gkok meeting.
Please let the chairs know if you have corrections,= suggestions or questions.


<= /div>
Thanks,
--
tcpm co-chairs
--000000000000b1fcfe057af6ea5a-- From Kiruthika.Varadarajan@harman.com Wed Nov 21 07:40:07 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56622128AFB for ; Wed, 21 Nov 2018 07:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Yrorxsd8GX for ; Wed, 21 Nov 2018 07:40:05 -0800 (PST) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0AF12777C for ; Wed, 21 Nov 2018 07:40:05 -0800 (PST) Received: from [67.219.251.51] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-c.us-west-2.aws.symcld.net id 5B/C2-11805-45C75FB5; Wed, 21 Nov 2018 15:40:04 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjk+JIrShJLcpLzFFi42LxThM+phtc8zX a4Mc6fYsddxYxWWw7OZ/Jgclj56y77B5LlvxkCmCKYs3MS8qvSGDNeHvzN3tBv2nF8u8vmRsY /xh2MXJxCAlsZpSY8nU/C4SziVGi4f1nJgjnIKPEp8f/2LsYOTnYBBwlvv58DGaLCChLrL7/g RHEZhYwlfh16DITiC0soCcxo2MpE0SNscTmNfdYIWw9icV7nrGB2CwCqhJP1zWB1fAKuEtM2n oYrIZRQEzi+6k1TBAzxSVuPZkPZksIiEg8vHiaDcIWlXj5+B8rhG0gsXXpPqCrOYBsBYn/Lzg gWtMkNq65xAYxXlDi5MwnLCC2kICuxOX5/9gnMIrMQrJhFpKWWUhaIOI5EhdvLoKq0ZFYsPsT G4StLbFs4WtmGPvMgcdMmOLlEi2ze1gh7BiJ1uNH2WcBg5RZ4DGjRPO8dqgFihJTuh+yL2DkW cVokVSUmZ5RkpuYmaNraGCga2hopGtobKFrZGyhl1ilm6xXWqxbnlpcomukl1herFdcmZuck6 KXl1qyiRGYDlIKut7tYDyzKP0QoyQHk5IoL1v212ghvqT8lMqMxOKM+KLSnNTiQ4wyHBxKEry Pq4BygkWp6akVaZk5wMQEk5bg4FES4eWrBkrzFhck5hZnpkOkTjFacvxb8H86M8ejGR0zmDne gUghlrz8vFQpcV5dkAYBkIaM0jy4cbDkeYlRVkqYl5GBgUGIpyC1KDezBFX+FaM4B6OSMK8My BSezLwSuK2vgA5iAjpI9sxnkINKEhFSUg2Mlt2zzC98MPD8kXLwv0OPVHSC0T6HZQ6zv9xbdP bLScGuxbE9+2c9yPmtHNPCz15/iVHbnL3jwjTXRTtrBdfk226sU4oPDvP9HGn98uynKxKS5e7 /wuzr1jQ/bJTc+uF/FO8uFQ+r5MbNG2vuRs2rP3xUbvGm9SlMbY4tXL+73AzDDssnXDNTYinO SDTUYi4qTgQA2G0ICJkDAAA= X-Env-Sender: Kiruthika.Varadarajan@harman.com X-Msg-Ref: server-11.tower-363.messagelabs.com!1542814802!2108509!1 X-Originating-IP: [75.102.19.198] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5428 invoked from network); 21 Nov 2018 15:40:03 -0000 Received: from unknown.ord.scnet.net (HELO HICGWSMB09.ad.harman.com) (75.102.19.198) by server-11.tower-363.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 21 Nov 2018 15:40:03 -0000 Received: from HICGWSMB03.ad.harman.com (10.10.24.96) by HICGWSMB09.ad.harman.com (10.10.24.241) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 21 Nov 2018 10:40:02 -0500 Received: from HICGWSMB01.ad.harman.com (10.10.24.94) by HICGWSMB03.ad.harman.com (10.10.24.96) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 21 Nov 2018 10:40:02 -0500 Received: from HICGWSMB01.ad.harman.com ([fe80::14bd:f949:b421:895d]) by HICGWSMB01.ad.harman.com ([fe80::14bd:f949:b421:895d%13]) with mapi id 15.00.1365.000; Wed, 21 Nov 2018 09:40:02 -0600 From: "Varadarajan, Kiruthika" To: "tcpm@ietf.org" CC: "johnwheffner@gmail.com" Thread-Topic: Linux TCP Stack and Zero Window Probe Thread-Index: AdSBsCBxTffgOUeISfqsOaGpkVCGxw== Date: Wed, 21 Nov 2018 15:40:02 +0000 Message-ID: <246bdcf112bb4ebe875df662e3467ab5@HICGWSMB01.ad.harman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.10.24.164] Content-Type: multipart/mixed; boundary="_004_246bdcf112bb4ebe875df662e3467ab5HICGWSMB01adharmancom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 21 Nov 2018 10:20:35 -0800 Subject: [tcpm] Linux TCP Stack and Zero Window Probe X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 15:43:39 -0000 --_004_246bdcf112bb4ebe875df662e3467ab5HICGWSMB01adharmancom_ Content-Type: multipart/alternative; boundary="_000_246bdcf112bb4ebe875df662e3467ab5HICGWSMB01adharmancom_" --_000_246bdcf112bb4ebe875df662e3467ab5HICGWSMB01adharmancom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Team, I have a question in Zero Window Probe in TCP. If the client sends Zero Window, according to RFC spec is it mandatory for = the Linux TCP stack to send Zero Window Probe. In my stack I am not getting Zero Window Probe instead I am getting Keep Al= ive. I have attached my wireshark traces. Can you please confirm if this is the = expected behavior from TCP stack. Thanks & Regards Kiruthika --_000_246bdcf112bb4ebe875df662e3467ab5HICGWSMB01adharmancom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Team,

I have a question in Zero Window Probe in TCP.<= /o:p>

If the client sends Zero Window, according to RFC sp= ec is it mandatory for the Linux TCP stack to send Zero Window Probe.<= /o:p>

In my stack I am not getting Zero Window Probe inste= ad I am getting Keep Alive.

I have attached my wireshark traces. Can you please = confirm if this is the expected behavior from TCP stack.

 

Thanks & Regards

Kiruthika

 

--_000_246bdcf112bb4ebe875df662e3467ab5HICGWSMB01adharmancom_-- --_004_246bdcf112bb4ebe875df662e3467ab5HICGWSMB01adharmancom_ Content-Type: application/octet-stream; name="NPF_{E7DFB959-A54B-4F2C-849E-9843429162FB}_2018-06-06_22-18-59-720.pcap" Content-Description: NPF_{E7DFB959-A54B-4F2C-849E-9843429162FB}_2018-06-06_22-18-59-720.pcap Content-Disposition: attachment; filename="NPF_{E7DFB959-A54B-4F2C-849E-9843429162FB}_2018-06-06_22-18-59-720.pcap"; size=2130; creation-date="Thu, 18 Oct 2018 10:37:09 GMT"; modification-date="Wed, 06 Jun 2018 16:49:07 GMT" Content-Transfer-Encoding: base64 1MOyoQIABAAAAAAAAAAAAAD6AAABAAAAs0EYW5owCwA8AAAAPAAAAAgCyv66vgAkmw+hxggARQAA KABjQAAeBgNvrBAAe6wQAGMPoL9AT6YR99XhxKtQEP//i8oAAAAAAAAAALNBGFuuMgsAPAAAADwA AAAAJJsPocYIAsr+ur4IAEUAACiW50AAQAZK6qwQAGOsEAB7v0APoNXhxKsAAAAAUAQAAO1zAAAA AAAAAACzQRhbsG8LADwAAAA8AAAACALK/rq+ACSbD6HGCABFAAAoAGNAAB4GA2+sEAB7rBAAYw+g v0D8zBbvFUeE+VAQ///Z+AAAAAAAAAAAs0EYW4dxCwA8AAAAPAAAAAAkmw+hxggCyv66vggARQAA KJbpQABABkrorBAAY6wQAHu/QA+gFUeE+QAAAABQBAAA7cAAAAAAAAAAALNBGFttqgsAPAAAADwA AAAIAsr+ur4AJJsPocYIAEUAACgAY0AAHgYDb6wQAHusEABjD6C/QIalengFEHQBUBD//w3GAAAA AAAAAACzQRhbrqwLADwAAAA8AAAAACSbD6HGCALK/rq+CABFAAAolu1AAEAGSuSsEABjrBAAe79A D6AFEHQBAAAAAFAEAAAO8AAAAAAAAAAAs0EYW4HTCwBDAAAAQwAAAAgCyv66vgAkmw+hxggARQAA NTZhAACAEatYrBAAe6wQAGMXcBdxACG6SAEFAgEAAAARAAAAAAEBAAABv0AABKwQAGOzQRhbs9YL ADwAAAA8AAAAACSbD6HGCALK/rq+CABFAAAutGlAAEARLVesEABjrBAAexdxF3AAGvPEAQUCAQAA AAoAAAAAAQGAAAAEs0EYW6npCwA+AAAAPgAAAAgCyv66vgAkmw+hxggARQAAMDZiAACAEatcrBAA e6wQAGMXcBdxABxzugEFAgQAAAAMAAAAAAEBAAAABAACs0EYW6HrCwA8AAAAPAAAAAAkmw+hxggC yv66vggARQAALLRsQABAES1WrBAAY6wQAHsXcRdwABjzywEFAgQAAAAIAAAAAAEBgAAABLNBGFu5 DgwAPAAAADwAAAAIAsr+ur4AJJsPocYIAEUAACgAY0AAHgYDb6wQAHusEABjD6C/QOcxgKsAAAAA UAL//yAmAAABAYAAAASzQRhbsxAMADwAAAA8AAAAACSbD6HGCALK/rq+CABFAAAsAABAAEAG4c2s EABjrBAAe79AD6A30vL55zGArGASchBrfAAAAgQFtAAEs0EYW2xBDAA8AAAAPAAAAAgCyv66vgAk mw+hxggARQAAKABjQAAeBgNvrBAAe6wQAGMPoL9A5zGArDfS8vpQEP//9UkAAAIEBbQABLNBGFsC RgwAOgAAADoAAAAIAsr+ur4AJJsPocYIAEUAACw2YwAAgBGrX6wQAHusEABjF3AXcQAYNJJCQgAB AAAACAAAAAABAQAAs0EYW+NIDABGAAAARgAAAAAkmw+hxggCyv66vggARQAAOLR9QABAES05rBAA Y6wQAHsXcRdwACQ1ZwEFggQAAAAcAAAAAAEBAgAABAAFD6AABKwQAHuzQRhbuVwMAEEAAABBAAAA CALK/rq+ACSbD6HGCABFAAAzNmQAAIARq1esEAB7rBAAYxdwF3EAH3WxAQUCAgAAAA8AAAAAAQEA AAAFAAEAAf60QRhb0U0MADwAAAA8AAAAACSbD6HGCALK/rq+CABFAAApOx1AAEAGprOsEABjrBAA e79AD6A30vL65zGArFAYchCFLwAA/gEAAAAFtEEYW2RODAA8AAAAPAAAAAAkmw+hxggCyv66vggA RQAALLhDQABAESl/rBAAY6wQAHsXcRdwABjzzQEFAgIAAAAIAAAAAAEBgAAABbRBGFswggwAPAAA ADwAAAAIAsr+ur4AJJsPocYIAEUAACgAY0AAHgYDb6wQAHusEABjD6C/QOcxgKw30vL7UBAAAPVI AAABAYAAAAW0QRhb9Y0MAEMAAABDAAAACALK/rq+ACSbD6HGCABFAAA1NmUAAIARq1SsEAB7rBAA YxdwF3EAIdjrAQUCAgAAABEAAAAAAQEAAAAFAAMAA7q74LVBGFs0UgwAPAAAADwAAAAAJJsPocYI Asr+ur4IAEUAACy6Y0AAQBEnX6wQAGOsEAB7F3EXcAAY880BBQICAAAACAAAAAABAYAAAAW2QRhb am0AADwAAAA8AAAAACSbD6HGCALK/rq+CABFAAAoOx5AAEAGprOsEABjrBAAe79AD6A30vL65zGA rFAQchCDOQAAAQGAAAAFtkEYW+UEBwA8AAAAPAAAAAAkmw+hxggCyv66vggARQAAKDsfQABABqay rBAAY6wQAHu/QA+gN9Ly+ucxgKxQEHIQgzkAAAEBgAAABbdBGFtHTwUAPAAAADwAAAAAJJsPocYI Asr+ur4IAEUAACg7IEAAQAamsawQAGOsEAB7v0APoDfS8vrnMYCsUBByEIM5AAABAYAAAAW5QRhb ySgBADwAAAA8AAAAACSbD6HGCALK/rq+CABFAAAoOyFAAEAGprCsEABjrBAAe79AD6A30vL65zGA rFAQchCDOQAAAQGAAAAFu0EYW6ShAABVAAAAVQAAAAgCyv66vgAkmw+hxggARQAARzZmAACAEatB rBAAe6wQAGMXcBdxADP8hwEFAAMAAAAjAAAAAAEBAAAABAAX77u/VENQX1BST0JJTkdfV0lORE9X UwC7QRhbiqQAADwAAAA8AAAAACSbD6HGCALK/rq+CABFAAAsu1hAAEARJmqsEABjrBAAexdxF3AA GPXMAQUAAwAAAAgAAAAAAQGAAAAE --_004_246bdcf112bb4ebe875df662e3467ab5HICGWSMB01adharmancom_-- From nobody Wed Nov 21 16:31:29 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D29A130EA4 for ; Wed, 21 Nov 2018 16:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7sbiNpu1vZS for ; Wed, 21 Nov 2018 16:31:15 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC90C130E8B for ; Wed, 21 Nov 2018 16:31:14 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id g11-v6so6435875ljk.3 for ; Wed, 21 Nov 2018 16:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=urThbPGgcHGxd87WdvIxrrdi42KY/bA8AXNvrrf+DhE=; b=PWEm0Du7g9wKvz/A5hH9CZv73zOQgMzLpprHetlBMRWwkCNPm+o8VtlyETp8XVoLXx 3bSD4fc0R+yHGfo+uR5lJSHbgsPkQ103dro8Ogs5Qj+YSX4Q9NEgGw9FFBxQKHcpufOY Pqiem65b0SgRk/+yIWnGgSKQsD0p51olX2M9Vf7GXG4QSAQ809YRuCIyCW5YaGjYuYkT CJ2D7EiUPMaLwzlNfWEG6ivhPOto4+p1vqiDHvudlbbrSN450mCMXONyhBbXkhI4dSAx NoJCnMbMaWQuTUGtc+bc0Aq4LdlXuqYqOaUM+m9JbfgSpW9bOCUKMxrJmv18ZtUEvmD2 /dxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=urThbPGgcHGxd87WdvIxrrdi42KY/bA8AXNvrrf+DhE=; b=mA+VBDk+oAXDLEemL5fgRdQVamLo+g2yaRuBv56rBlpPD03wXlEUo/gN2F3rlSnqwV e3WZowE2kigRPJRLaBrniQeViW4cI7bnbO4hIMJwlRtCjznCfOWe54G6P3iN+RaIyvV6 MTWOoqf3HsGIcIUs96A4+8rLOLe44ReBQd8Rql92s3bmId6eEbkHyAxmXWchLNq2xO3u BQbBsBr0za1a95bwZxIW3sN8S8cHqS3rJ3xoomLL9hR6w0hAINdG9VlQ0m95zmP2WfZt pMFUgXCzsjfL4w8jAPn/2MeHMsVmE/SgD0L7ygOU+wtHdHm5pypK6sSZssxG7qm+JT68 jGRg== X-Gm-Message-State: AA+aEWZiH78lcx1oLT/AEztiz+ZNg6tUTHbQWvIclpyhnndN+CtzMbzt oY9wBwLoAClmtOcF8p2iPNANE6zuFKkKKZPfUgI= X-Google-Smtp-Source: AJdET5e3vt+9jMmn0P8Dz+WtDusCGhQIA/Eey1AzVTPn6R1Wy/OzdhKcYfc1oZYp6lHrKFfXfD90dQoQOgM14a2BVdA= X-Received: by 2002:a2e:6c04:: with SMTP id h4-v6mr5111025ljc.92.1542846672801; Wed, 21 Nov 2018 16:31:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jana Iyengar Date: Wed, 21 Nov 2018 16:31:01 -0800 Message-ID: To: Neal Cardwell Cc: eric.dumazet@gmail.com, tcpm@ietf.org Content-Type: multipart/alternative; boundary="000000000000e01551057b35fb0a" Archived-At: Subject: Re: [tcpm] Thank you for the QUIC session in tcpm X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 00:31:21 -0000 --000000000000e01551057b35fb0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the clarification, Neal! On Thu, Nov 15, 2018 at 9:15 AM Neal Cardwell wrote: > On Wed, Nov 14, 2018 at 11:18 PM Jana Iyengar wrote: > >> Thanks for the clarification, Eric. I'm a bit surprised to see srtt be >> used by both Cubic and BBR, but that discussion's not for this thread. >> > > Just to add context (sorry to dilute the thread!), the spot in Linux TCP > BBR that Eric pointed to that is using srtt is the initialization code > (bbr_init_pacing_rate_from_rtt()). The code is using srtt here to compute= a > pacing rate (via pacing_rate =3D gain * cwd / srtt) largely because Linux= TCP > can hot-swap congestion control modules. Because of that possibility, the > cwnd and srtt that BBR inherits at initialization may have been from a > buffer-bloated CUBIC/Reno connection, where srtt may have bloated in > proportion to cwnd, so that cwd / srtt is generally a better approximatio= n > to the available bandwidth than cwnd / min_rtt. As you would imagine, > after that initialization, Linux TCP BBR does not use srtt (or min_rtt) t= o > update the pacing rate; it uses a function of the estimated bandwidth. > > best, > neal > > > >> On Wed, Nov 14, 2018 at 9:44 PM Eric Dumazet >> wrote: >> >>> >>> >>> On 11/12/2018 11:13 PM, Jana Iyengar wrote: >>> > On what to do with an unconfirmed RTO: So, my thought is that if >>> you've hit an RTO, it's been a REALLY LONG time, because we've gone thr= ough >>> TLP(s) by now and failed. (This might change if we decide to combine TL= P >>> and RTO, but that's for a later discussion.) It's not fully clear to m= e >>> what the right responses here are, but some thoughts follow. >>> > >>> > 1/ If this was an actual increase in the RTT, it would naturally roll >>> into the SRTT and RTTVAR. We might even consider resetting the RTT >>> estimator, but we already know that the EWMA estimator we love takes ju= st a >>> while to catch on, and I don't want to litigate changing the estimator >>> fundamentally here. >>> > >>> > 2/ Linux fq uses min_rtt IIRC, which shouldn't change as a result of >>> an increase in RTT. This *might* be a good time to kick the min_rtt >>> estimator to pace more conservatively. >>> >>> linux fq does not use min_rtt, but the pacing rate set by TCP. >>> >>> pacing rate for Cubic is using SRTT ( >>> https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_input.c#L80= 6 >>> ) >>> >>> For BBR, pacing rate depends on various factors and phases, but SRTT is >>> used, not min_rtt >>> >>> https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_bbr.c#L231 >>> >>> >>> > >>> > 3/ I'm not convinced that it makes sense to change the cwnd. It seems >>> clear that an RTT increase with the same BW should increase the cwnd if >>> anything, so it seems reasonable to continue with the same cwnd at leas= t. >>> If the BW changed, hopefully that'll be reflected in a congestion signa= l, >>> but in the absence of a congestion signal, I think we should keep the c= wnd >>> as is. >>> > >>> > >>> > On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian < >>> pravb@microsoft.com > wrote: >>> > >>> > Yuchung this might be worth experimenting with and getting more >>> data on. Maybe there should be some reaction to an unconfirmed RTO even= if >>> it is not reduction all the way to LW? I like Jana's suggestion that th= e >>> implementation SHOULD drop the cwnd even for unconfirmed RTO if not pac= ing. >>> > >>> > I checked the latest draft and pacing is a RECOMMENDED. I am >>> noticing that transport algorithms in Linux and in QUIC are evolving >>> assuming pacing which is a function usually implemented and configured >>> outside of the transport.. So the transport is potentially making an >>> assumption which may result in safety issues. For example BBR congestio= n >>> control may not work very well if pacing was disabled or misconfigured?= I >>> don=E2=80=99t know of any robust solution to this other than build paci= ng into the >>> transport itself. Pacing is also very challenging for low latency flows >>> because of lack of support for fine grained timers. >>> > >>> > -----Original Message----- >>> > From: Yuchung Cheng = > >>> > Sent: Monday, November 12, 2018 8:37 AM >>> > To: Jana Iyengar > >>> > Cc: Praveen Balasubramanian >> pravb@microsoft.com>>; Bob Briscoe >> ietf@bobbriscoe.net>>; Ian Swett >> ianswett@google.com>>; tcpm@ietf.org Extensions = < >>> tcpm@ietf.org > >>> > Subject: Re: [tcpm] Thank you for the QUIC session in tcpm >>> > >>> > On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar >> > wrote: >>> > > Praveen, >>> > > >>> > > The point you're raising -- that we've lost the ack clock after >>> an RTO >>> > > -- is a reasonable point. My argument is that with pacing, cwnd >>> > > reduction is unwarranted because in the extreme case, this >>> collapses >>> > > to restart after idle, where sending at cwnd with pacing is >>> reasonable >>> > I agree w/ Jana as well - the most generic way to treat burst due >>> to prior_inflight << cwnd is pacing. With QUIC's approach, when RTO fir= es, >>> cwnd remains unchanged until the ACK of the first retransmission (i.e. = a >>> probe packet) comes back. Therefore the delay is one RTT and the potent= ial >>> damage is an additional cwnd-worth of burst. >>> > >>> > Yes the worst case is more aggressive, and it can be too much for >>> DC incast case if pacing isn't supported - one idea is to selective ena= ble >>> that if RTT variance is very large vs RTT. >>> > >>> > > >>> > > The draft does not say that a sender should reduce the cwnd if >>> it is >>> > > not pacing, which we should add. Does that make sense? >>> > > >>> > > - jana >>> > > >>> > > On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasubramanian >>> > > >> 40microsoft.com@dmarc.ietf.org>> wrote: >>> > >> >>> > >> Yuchung I brought that difference up in an email to the quic w= g >>> > >> earlier this week. >>> > >> >>> > >> In app send limited case, inflight could be very small compare= d >>> to cwnd. >>> > >> So in QUIC there is potential to send a burst out after a long >>> idle >>> > >> period (with outstanding data) where TCP wouldn't. The draft >>> claims >>> > >> this is okay to do because RTO may have been a result of RTT >>> increase >>> > >> instead of loss. Is there data to suggest on which side we >>> should >>> > >> err? i.e. data on what are the chances that an RTO is due to a= n >>> RTT increase versus loss. >>> > >> >>> > >> Do you see any safety concerns with delayed reduction of cwnd >>> in case >>> > >> where the RTO is not spurious? >>> > >> >>> > >> -----Original Message----- >>> > >> From: tcpm > >>> On Behalf Of Yuchung Cheng >>> > >> Sent: Thursday, November 8, 2018 4:38 PM >>> > >> To: Bob Briscoe >> ietf@bobbriscoe.net>> >>> > >> Cc: Ian Swett >; >>> tcpm IETF list > >>> > >> Subject: Re: [tcpm] Thank you for the QUIC session in tcpm >>> > >> >>> > >> On Thu, Nov 8, 2018 at 3:14 AM, Bob Briscoe < >>> ietf@bobbriscoe.net > wrote: >>> > >> > >>> > >> > I just wanted to thank Jana for explaining QUIC loss recover= y >>> to us >>> > >> > (and QUIC CC as far as it goes). >>> > >> > And thank you Jana, Ian, the chairs of both WGs (and anyone >>> else >>> > >> > involved) for setting it up. >>> > >> > >>> > >> > If one is not full-time on QUIC, it's very difficult to keep >>> up >>> > >> > with all the changes. But now we have a checkpoint to start >>> from, I >>> > >> > feel I will not be wasting people's time if I try to get >>> involved - >>> > >> > at least I only might say something un-QUIC occasionally, >>> rather >>> > >> > than nearly always. This has allowed people who understand >>> how TCP >>> > >> > cold be improved to help with QUIC, when working on QUIC >>> isn't their day job. >>> > >> > >>> > >> > Again, Thank you. >>> > >> I like particularly that QUIC only reduces cwnd to 1 after the >>> loss >>> > >> is confirmed not upon RTO fires. It should be very feasible fo= r >>> TCP >>> > >> (at least >>> > >> Linux) w/ TCP timestamps. It'll save a lot of spurious cwnd >>> reductions! >>> > >> >>> > >> Also IMHO TCP w/ quality timestamps are almost as good as QUIC >>> pkt-ids. >>> > >> Google internally uses usec. We wish we could upstream it but >>> RFC >>> > >> needs to be updated. >>> > >> >>> > >> > >>> > >> > >>> > >> > Bob >>> > >> > >>> > >> > >>> > >> > -- >>> > >> > >>> ________________________________________________________________ >>> > >> > Bob Briscoe >>> > >> > >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbob >>> > >> > briscoe.net %2F&data=3D02%7C01%7Cpra= vb% >>> 40microsoft.com %7C3c4d22866 >>> > >> > >>> 8444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% >>> > >> > >>> 7C636776374678321324&sdata=3DT%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfee >>> > >> > buPcuMYlVhgDY%3D&reserved=3D0 >>> > >> > >>> > >> > _______________________________________________ >>> > >> > tcpm mailing list >>> > >> > tcpm@ietf.org >>> > >> > >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fww >>> > >> > w.i >>> > >> > etf.org >> >%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micr >>> > >> > oso >>> > >> > ft.com >> >%7Cf0911eeb74d7446f424508d645dbb779%7C72f988bf86f141af91ab2d7 >>> > >> > cd0 >>> > >> > >>> 11db47%7C1%7C0%7C636773207316711149&sdata=3DK667a3IQG4rarQ%2FOfAl >>> > >> > yhK >>> > >> > QQ05Cea421rgb64DlEMvs%3D&reserved=3D0 >>> > >> >>> > >> _______________________________________________ >>> > >> tcpm mailing list >>> > >> tcpm@ietf.org >>> > >> >>> > >> >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >>> > >> ietf.org >> >%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro >>> > >> soft.com >> >%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 >>> > >> >>> cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerpx >>> > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 >>> > >> >>> > >> _______________________________________________ >>> > >> tcpm mailing list >>> > >> tcpm@ietf.org >>> > >> >>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >>> > >> ietf.org >> >%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro >>> > >> soft.com >> >%7C3c4d228668444691c16808d648bd2ce9%7C72f988bf86f141af91ab2d7 >>> > >> >>> cd011db47%7C1%7C0%7C636776374678321324&sdata=3D33WxKh5c6qL4ln5jerpx >>> > >> Rhytfrj1iTK284pEqv5fWKY%3D&reserved=3D0 >>> > >>> > >>> > >>> > _______________________________________________ >>> > tcpm mailing list >>> > tcpm@ietf.org >>> > https://www.ietf.org/mailman/listinfo/tcpm >>> > >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> > --000000000000e01551057b35fb0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the clarification, Neal!

On Thu, Nov 15, 2018 at 9:15 AM Neal Cardwel= l <ncardwell@google.com> = wrote:
On Wed, Nov 14, 2018 at 11:18 PM Jana Iye= ngar <jri.ietf@g= mail.com> wrote:
Thanks for the clarification, Eric. I'm a bit surprised to see sr= tt be used by both Cubic and BBR, but that discussion's not for this th= read.

Just to add context (sorry to dilute= the thread!), the spot in Linux TCP BBR that Eric pointed to that is using= srtt is the initialization code (bbr_init_pacing_rate_from_rtt()). The cod= e is using srtt here to compute a pacing rate (via pacing_rate =3D gain * c= wd / srtt) largely because Linux TCP can hot-swap congestion control module= s. Because of that possibility, the cwnd and srtt that BBR inherits at init= ialization may have been from a buffer-bloated CUBIC/Reno connection, where= srtt may have bloated in proportion to cwnd, so that cwd / srtt is general= ly a better approximation to the available bandwidth than cwnd / min_rtt.= =C2=A0 As you would imagine, after that initialization, Linux TCP BBR does = not use srtt (or min_rtt) to update the pacing rate; it uses a function of = the estimated bandwidth.

best,
neal

=C2=A0
On Wed, Nov 14,= 2018 at 9:44 PM Eric Dumazet <eric.dumazet@gmail.com> wrote:


On 11/12/2018 11:13 PM, Jana Iyengar wrote:
> On what to do with an unconfirmed RTO: So, my thought is that if you&#= 39;ve hit an RTO, it's been a REALLY LONG time, because we've gone = through TLP(s) by now and failed. (This might change if we decide to combin= e TLP and RTO, but that's for a later discussion.)=C2=A0 It's not f= ully clear to me what the right responses here are, but some thoughts follo= w.
>
> 1/ If this was an actual increase in the RTT, it would naturally roll = into the SRTT and RTTVAR. We might even consider resetting the RTT estimato= r, but we already know that the EWMA estimator we love takes just a while t= o catch on, and I don't want to litigate changing the estimator fundame= ntally here.
>
> 2/ Linux fq uses min_rtt IIRC, which shouldn't change as a result = of an increase in RTT. This *might* be a good time to kick the min_rtt esti= mator to pace more conservatively.

linux fq does not use min_rtt, but the pacing rate set by TCP.

pacing rate for Cubic is using SRTT ( https://elixir.bootlin.com/linux/latest/source/net/ipv4/tcp_inp= ut.c#L806 )

For BBR, pacing rate depends on various factors and phases, but SRTT is use= d, not min_rtt

https://elixir.bootlin.com/lin= ux/latest/source/net/ipv4/tcp_bbr.c#L231


>
> 3/ I'm not convinced that it makes sense to change the cwnd. It se= ems clear that an RTT increase with the same BW should increase the cwnd if= anything, so it seems reasonable to continue with the same cwnd at least. = If the BW changed, hopefully that'll be reflected in a congestion signa= l, but in the absence of a congestion signal, I think we should keep the cw= nd as is.
>
>
> On Tue, Nov 13, 2018 at 12:35 AM Praveen Balasubramanian <pravb@microsoft.com &= lt;mailto:pravb@mi= crosoft.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Yuchung this might be worth experimenting with and = getting more data on. Maybe there should be some reaction to an unconfirmed= RTO even if it is not reduction all the way to LW? I like Jana's sugge= stion that the implementation SHOULD drop the cwnd even for unconfirmed RTO= if not pacing.
>
>=C2=A0 =C2=A0 =C2=A0I checked the latest draft and pacing is a RECOMMEN= DED. I am noticing that transport algorithms in Linux and in QUIC are evolv= ing assuming pacing which is a function usually implemented and configured = outside of the transport.. So the transport is potentially making an assump= tion which may result in safety issues. For example BBR congestion control = may not work very well if pacing was disabled or misconfigured? I don=E2=80= =99t know of any robust solution to this other than build pacing into the t= ransport itself. Pacing is also very challenging for low latency flows beca= use of lack of support for fine grained timers.
>
>=C2=A0 =C2=A0 =C2=A0-----Original Message-----
>=C2=A0 =C2=A0 =C2=A0From: Yuchung Cheng <ycheng@google.com <mailto:ycheng@google.com>>
>=C2=A0 =C2=A0 =C2=A0Sent: Monday, November 12, 2018 8:37 AM
>=C2=A0 =C2=A0 =C2=A0To: Jana Iyengar <jri.ietf@gmail.com <mailto:jri.ietf@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0Cc: Praveen Balasubramanian <pravb@microsoft.com <mailto:pravb@microsoft.com<= /a>>>; Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net>>; Ian Swett <= ;ianswett@google.c= om <mailto:= ianswett@google.com>>; tcpm@ietf.org <mailto:tcpm@ietf.org> Extensions <tcpm@ietf.org <mailto:tcpm@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0Subject: Re: [tcpm] Thank you for the QUIC session = in tcpm
>
>=C2=A0 =C2=A0 =C2=A0On Mon, Nov 12, 2018 at 4:13 AM, Jana Iyengar <<= a href=3D"mailto:jri.ietf@gmail.com" target=3D"_blank">jri.ietf@gmail.com <mailto:jri.i= etf@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0> Praveen,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The point you're raising -- that we've= lost the ack clock after an RTO
>=C2=A0 =C2=A0 =C2=A0> -- is a reasonable point. My argument is that = with pacing, cwnd
>=C2=A0 =C2=A0 =C2=A0> reduction is unwarranted because in the extrem= e case, this collapses
>=C2=A0 =C2=A0 =C2=A0> to restart after idle, where sending at cwnd w= ith pacing is reasonable
>=C2=A0 =C2=A0 =C2=A0I agree w/ Jana as well - the most generic way to t= reat burst due to prior_inflight << cwnd is pacing. With QUIC's a= pproach, when RTO fires, cwnd remains unchanged until the ACK of the first = retransmission (i.e. a probe packet) comes back. Therefore the delay is one= RTT and the potential damage is an additional cwnd-worth of burst.
>
>=C2=A0 =C2=A0 =C2=A0Yes the worst case is more aggressive, and it can b= e too much for DC incast case if pacing isn't supported - one idea is t= o selective enable that if RTT variance is very large vs RTT.
>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The draft does not say that a sender should re= duce the cwnd if it is
>=C2=A0 =C2=A0 =C2=A0> not pacing, which we should add. Does that mak= e sense?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> - jana
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> On Fri, Nov 9, 2018 at 8:34 AM Praveen Balasub= ramanian
>=C2=A0 =C2=A0 =C2=A0> <pravb=3D40microsoft.com@dmarc.ietf.org <ma= ilto:40= microsoft.com@dmarc.ietf.org>> wrote:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Yuchung I brought that difference up in an= email to the quic wg
>=C2=A0 =C2=A0 =C2=A0>> earlier this week.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> In app send limited case, inflight could b= e very small compared to cwnd.
>=C2=A0 =C2=A0 =C2=A0>> So in QUIC there is potential to send a bu= rst out after a long idle
>=C2=A0 =C2=A0 =C2=A0>> period (with outstanding data) where TCP w= ouldn't. The draft claims
>=C2=A0 =C2=A0 =C2=A0>> this is okay to do because RTO may have be= en a result of RTT increase
>=C2=A0 =C2=A0 =C2=A0>> instead of loss. Is there data to suggest = on which side we should
>=C2=A0 =C2=A0 =C2=A0>> err? i.e. data on what are the chances tha= t an RTO is due to an RTT increase versus loss.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Do you see any safety concerns with delaye= d reduction of cwnd in case
>=C2=A0 =C2=A0 =C2=A0>> where the RTO is not spurious?
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> -----Original Message-----
>=C2=A0 =C2=A0 =C2=A0>> From: tcpm <tcpm-bounces@ietf.org <mailto:tcpm-bounces@ietf.org<= /a>>> On Behalf Of Yuchung Cheng
>=C2=A0 =C2=A0 =C2=A0>> Sent: Thursday, November 8, 2018 4:38 PM >=C2=A0 =C2=A0 =C2=A0>> To: Bob Briscoe <ietf@bobbriscoe.net <mailto:ietf@bobbriscoe.net= >>
>=C2=A0 =C2=A0 =C2=A0>> Cc: Ian Swett <ianswett@google.com <mailto:ianswett@google.com&g= t;>; tcpm IETF list <tcpm@ietf.org <mailto:tcpm@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0>> Subject: Re: [tcpm] Thank you for the QUIC= session in tcpm
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> On Thu, Nov 8, 2018 at 3:14 AM, Bob Brisco= e <ietf@bobbris= coe.net <mailto:ietf@bobbriscoe.net>> wrote:
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > I just wanted to thank Jana for expla= ining QUIC loss recovery to us
>=C2=A0 =C2=A0 =C2=A0>> > (and QUIC CC as far as it goes).
>=C2=A0 =C2=A0 =C2=A0>> > And thank you Jana, Ian, the chairs o= f both WGs (and anyone else
>=C2=A0 =C2=A0 =C2=A0>> > involved) for setting it up.
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > If one is not full-time on QUIC, it&#= 39;s very difficult to keep up
>=C2=A0 =C2=A0 =C2=A0>> > with all the changes. But now we have= a checkpoint to start from, I
>=C2=A0 =C2=A0 =C2=A0>> > feel I will not be wasting people'= ;s time if I try to get involved -
>=C2=A0 =C2=A0 =C2=A0>> > at least I only might say something u= n-QUIC occasionally, rather
>=C2=A0 =C2=A0 =C2=A0>> > than nearly always. This has allowed = people who understand how TCP
>=C2=A0 =C2=A0 =C2=A0>> > cold be improved to help with QUIC, w= hen working on QUIC isn't their day job.
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > Again, Thank you.
>=C2=A0 =C2=A0 =C2=A0>> I like particularly that QUIC only reduces= cwnd to 1 after the loss
>=C2=A0 =C2=A0 =C2=A0>> is confirmed not upon RTO fires. It should= be very feasible for TCP
>=C2=A0 =C2=A0 =C2=A0>> (at least
>=C2=A0 =C2=A0 =C2=A0>> Linux) w/ TCP timestamps. It'll save a= lot of spurious cwnd reductions!
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Also IMHO TCP w/ quality timestamps are al= most as good as QUIC pkt-ids.
>=C2=A0 =C2=A0 =C2=A0>> Google internally uses usec. We wish we co= uld upstream it but RFC
>=C2=A0 =C2=A0 =C2=A0>> needs to be updated.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > Bob
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > --
>=C2=A0 =C2=A0 =C2=A0>> > _____________________________________= ___________________________
>=C2=A0 =C2=A0 =C2=A0>> > Bob Briscoe
>=C2=A0 =C2=A0 =C2=A0>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fbo= b
>=C2=A0 =C2=A0 =C2=A0>> > briscoe.net <http://briscoe.net>%2F&a= mp;amp;data=3D02%7C01%7Cpravb%40microsoft.com <http://40microsoft.com&= gt;%7C3c4d22866
>=C2=A0 =C2=A0 =C2=A0>> > 8444691c16808d648bd2ce9%7C72f988bf86f= 141af91ab2d7cd011db47%7C1%7C0%
>=C2=A0 =C2=A0 =C2=A0>> > 7C636776374678321324&amp;sdata=3D= T%2BWTEc42VC%2Bz%2BsmMFyjlm37hmAwfee
>=C2=A0 =C2=A0 =C2=A0>> > buPcuMYlVhgDY%3D&amp;reserved=3D0=
>=C2=A0 =C2=A0 =C2=A0>> >
>=C2=A0 =C2=A0 =C2=A0>> > _____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0>> > tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0>> > tcpm@ietf.org <mailto:tcpm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0>> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= w
>=C2=A0 =C2=A0 =C2=A0>> > w.i
>=C2=A0 =C2=A0 =C2=A0>> > etf.org <http://etf.org>%2Fmailman%2Flistin= fo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40micr
>=C2=A0 =C2=A0 =C2=A0>> > oso
>=C2=A0 =C2=A0 =C2=A0>> > ft.com <http://ft.com>%7Cf0911eeb74d7446f424508= d645dbb779%7C72f988bf86f141af91ab2d7
>=C2=A0 =C2=A0 =C2=A0>> > cd0
>=C2=A0 =C2=A0 =C2=A0>> > 11db47%7C1%7C0%7C636773207316711149&a= mp;amp;sdata=3DK667a3IQG4rarQ%2FOfAl
>=C2=A0 =C2=A0 =C2=A0>> > yhK
>=C2=A0 =C2=A0 =C2=A0>> > QQ05Cea421rgb64DlEMvs%3D&amp;rese= rved=3D0
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> __________________________________________= _____
>=C2=A0 =C2=A0 =C2=A0>> tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>=C2=A0 =C2=A0 =C2=A0>> ietf.org <http://ietf.org>%2Fmailman%2Flistinfo%= 2Ftcpm&amp;data=3D02%7C01%7Cpravb%40micro
>=C2=A0 =C2=A0 =C2=A0>> soft.com <http://soft.com>%7C3c4d228668444691c16= 808d648bd2ce9%7C72f988bf86f141af91ab2d7
>=C2=A0 =C2=A0 =C2=A0>> cd011db47%7C1%7C0%7C636776374678321324&= ;amp;sdata=3D33WxKh5c6qL4ln5jerpx
>=C2=A0 =C2=A0 =C2=A0>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserve= d=3D0
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> __________________________________________= _____
>=C2=A0 =C2=A0 =C2=A0>> tcpm mailing list
>=C2=A0 =C2=A0 =C2=A0>> tcpm@ietf.org <mailto:tcpm@ietf.org>
>=C2=A0 =C2=A0 =C2=A0>> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>=C2=A0 =C2=A0 =C2=A0>> ietf.org <http://ietf.org>%2Fmailman%2Flistinfo%= 2Ftcpm&amp;data=3D02%7C01%7Cpravb%40micro
>=C2=A0 =C2=A0 =C2=A0>> soft.com <http://soft.com>%7C3c4d228668444691c16= 808d648bd2ce9%7C72f988bf86f141af91ab2d7
>=C2=A0 =C2=A0 =C2=A0>> cd011db47%7C1%7C0%7C636776374678321324&= ;amp;sdata=3D33WxKh5c6qL4ln5jerpx
>=C2=A0 =C2=A0 =C2=A0>> Rhytfrj1iTK284pEqv5fWKY%3D&amp;reserve= d=3D0
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
>

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000e01551057b35fb0a-- From nobody Thu Nov 22 03:00:33 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A54128B14; Thu, 22 Nov 2018 03:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyQnvnLkx-m9; Thu, 22 Nov 2018 03:00:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AA2129AB8; Thu, 22 Nov 2018 03:00:22 -0800 (PST) Received: from [10.67.53.165] ([217.70.211.17]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MX19U-1fu0FS1oRg-00VzKG; Thu, 22 Nov 2018 11:59:38 +0100 To: tsvwg@ietf.org, "tcpm@ietf.org" , "Scharf, Michael (Nokia - DE/Stuttgart)" , bob Briscoe References: <6EC6417807D9754DA64F3087E2E2E03E2D14F3F0@rznt8114.rznt.rzdir.fht-esslingen.de> <110030da-11f7-c9c2-c059-2abdf6178864@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15201A@rznt8114.rznt.rzdir.fht-esslingen.de> <1f7ccdda-0e0c-4241-3cfb-b4fe4cc00b47@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D152905@rznt8114.rznt.rzdir.fht-esslingen.de> <53f76b72-67e8-9c95-0ea5-a5621f378dd0@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D1536B3@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2D1537CD@rznt8114.rznt.rzdir.fht-esslingen.de> <45512894-fc71-a4a8-4043-3feb06f9e347@bobbriscoe.net> <6EC6417807D9754DA64F3087E2E2E03E2D15394C@rznt8114.rznt.rzdir.fht-esslingen.de> From: "Scheffenegger, Richard" Message-ID: <42b3afcb-7050-b94c-bfc4-5c40628b4330@gmx.at> Date: Thu, 22 Nov 2018 11:59:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D15394C@rznt8114.rznt.rzdir.fht-esslingen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:iH8+NSu5K8BnfRmlWQM/U0k4dqwQS4STg7gxMwDJxZ4Z21A8ybt goMjaqKqyV3YVOGQw3X0/W9e3oJI6gtHZG6NDay6gJnOI9fyschChFUI/Pc0Mgkz6/dw2yP e0AvFLfXqwckbKKEZWoZvWjJrDKaQE9Yz+23ueONyUp055E+ctdQb57pL3mdPX7u5tap7pl 50ttAgfnQ9urIZIHk/Qgg== X-UI-Out-Filterresults: notjunk:1;V03:K0:UEsz6on3WHs=:3YD9pBll4c0CB2Zpt+RlBD JYVYrhAxYXpaaZqWKKeOEB/XZCHcPNxRfZtbVoeFu08f7lwPBc9nz7fpWWEPaH/4AbsiqsGdD 243fO8in5JIKf42Zp8ohMtbnuoZkwZ0cy8qRXcQShrkNl/cp04Ke82uR+24nyqjS8BvtF/Tru imVq3FfDLIbo2bKtBdRSK89tafuKqRPSW48pZcVPSxaII/RCuJX/qEMOi39gBpKs3mNJGMVsa uEv8GZIDh3bNQDRg/UsApeFKfz6acCqrzuQEIQatCiuCNlf42F0WcF+t5kKLYiMGY33yYGN+d Kcdu75mB95wBDmE8zmAHrXqo/3vX+rAscfNLcfHbfOKBn3bak/8jEamzdpO8uMYQFn9JgL4lA goplhUJfFRajjXVsllyE7le1Y0608BIOVIdh+OtdS/T/ld2vuBGfYXbbrF/5cKxyQzCGxvYEk tmq2+nAP2PVC7veLWwd6xMWsi1LrdHIefrSYhvLlTfmuHQ25KKINZGrRANwrx87rwBhCUll7z 0pgblr1VZBHRnOkc4Y9pZ0IsrqFp5Iho7845iPXOBHgZEiXTHgqamulJC2sipEjsEl3ntH2ik smZmoC++nHJutS7ms2C3udE1c7R6QU1GLZZCrTo+FboNn2lMedEdEviuAxtmE6iqwlIM33aMW aDW8BB2fUmpcbw6yW+foiciRd0VJhkR01eQIezgpd27edb81oDTS0PCa79eTFYgkvupy3RucL Vd2fBP2PP1E2sPSEVjSggcJ9oNSAQrRj4gUmMkTPGcXS+sTPXziKwef+JZq99ENgS4JYm66ez I9HzDFaj0Yq41hw4ElPh0k9lqUo2ZdcsdEb7WUzJ4P1dd2V+d6/l/BRH7wZgGSfrUzZPpN/m0 JatJmrt/qXCa/bisytJ0SOIvwk0q7aqDZRJgePWXSWDbLIk1wIMrdnB3lT55Uc Archived-At: Subject: Re: [tcpm] [tsvwg] Cross-area alignment on "L4S and RACK" X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 11:00:31 -0000 Hi, Just to chime in here, for a (unfortunately common) real world example that I tend to run into more frequently recently: Some implementations of (L2 or L3) ECMP appear to perform regular / load-triggered rebalancing events. I have observed these in particular with certain VSwitch implementations, as well as some modern, proprietary L2 "trill-like" switch topologies. While there are adaptive experimental mechanisms in TCP to deal with relatively consistent reordering (measured in packets), the timescales involved in my examples above are such, that these adaptive variants really can not cope properly. And the argument, to measure the reordering extent in units of time rather than packets seems sensible to me, as it bounds the maximum delay incurred before a retransmission happens. In the above mentioned examples, doing rebalance events only when the relative buffer utilization allows for a bounded (in time) reorder extent should be relatively easy to work out. Compared to the status quo (where the potential worst case reordering extent is not considered), this seems to be an improvement. Best regards, Richard Am 09.11.2018 um 20:28 schrieb Scharf, Michael: > First, I don’t know if the currently discussed parameters for the RACK > reordering window are indeed future proof. Maybe TCP stacks could use > different parameters in one or two years from now? So what is the > real-world benefit for a link designer **now** in relying on an > parameters that can change easily? And I would actually assume that the > exact parameter values in a (hypothetical) future standards track > specification of RACK would be a SHOULD. Different TCP stacks may pick > different values. How useful is this then to a link designer? > > Second, I don’t understand why one cannot try to provide some other > guidance, say, in terms of number of triggered DUPACKs or the like. > Let’s assume we said a stack must be able to deal with a reorder degree > of 10? For which link technologies would this not be good enough? > > Third, some real-world data would facilitate this discussion quite a > bit, IMHO. I have a hard time to follow this proposal without examples > for different RTTs, different number of parallel connections, different > mixtures of traffic, etc. > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 7:52 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > The idea is that (as now in the RACK draft since discussion on the tcpm > list earlier this year under a subject something like vicious circle or > virtuous circle) there will be a limit on the initial RACK reordering > window expressed in fractional RTT units. > > Link vendors know the min e2e RTT of the paths that their links are > usually deployed over. Therefore they can estimate the max reordering > they allow their links to introduce. > > I don't expect this limit to be set in stone while both RACK and L4S are > experimental. But as both these experiments progress, I think the > industry will get a better idea of where the limit should lie. > > It was the realization that, if TCP adapted its reordering window to the > measured reordering degree without bound, the L2 world would continually > increase the reordering degree of their links (the vicious circle). > > If there is any aspect of this limit expressed in units of packets, the > limit will decrease in time as flow rates increase, and therefore not > serve to give the L2 world any clear guidance - no de facto limit agreed > between the L4 world and the L2 world. > > If we keep the limit in units of RTT, hopefully then we have a virtuous > circle, not a vicious circle. > > > > Bob > > On 09/11/2018 18:28, Scharf, Michael wrote: > > I may miss something, but I read the outcome of the appendix as a > requirement “must be more robust to reordering”. As far as I > understand, that can be implemented in different ways. > > And I may be wrong, but those link technologies could be well > implemented in a router and then one needs to analyze how that whole > architecture fits into the scheduler, queue, policer, and line card > hardware design of a router. But that is something routing people > know better than me. My point is just to get the experts into the > loop early. > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 7:04 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > Please address the scaling rationale in the appendix for why it does > matter how a sender realizes this internally. > > The list of access links types I mentioned are rarely connected > directly to routers. > > > > Bob > > On 09/11/2018 17:44, Scharf, Michael wrote: > > I’ll not comment on link technology implementation, scheduler > and queue design assumptions in Appendix A.1.7 of > draft-ietf-tsvwg-ecn-l4s-id-05. People e.g. in RTG area may be > more familiar with the implications of internal designs e.g. > inside a router. IMHO the best way to get routing experts into > the loop before further discussing what is currently listed in > Appendix A.1.7. > > Thus, I limit my response to the actual wording in the main part > of draft-ietf-tsvwg-ecn-l4s-id-05: > >     o  A scalable congestion control MUST detect loss by > counting in > >       units of time, which is scalable, and MUST NOT count in > units of > >       packets (as in the 3 DupACK rule of traditional TCP), > which is not > >       scalable (see Appendix A.1.7 > for > rationale). > > As individual contributor, I disagree with this requirement. I > would probably be OK with a wording that a TCP sender must be > able to tolerate reordering beyond 3 Duplicate ACKs. I believe > it does not matter how a sender realizes this internally. > > And if that requirement is not just removed, I believe the > wording “traditional TCP” has to be replaced by “standard TCP”. > > BTW, also, in the rest of the document there has to be a clear > distinction between experiments and standards. History tells us > that some experiments can evolve into standards track > specifications, while other experiments may fail. And there is > no way of knowing that in advance. > > Michael > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 11:08 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > On 09/11/2018 06:21, Scharf, Michael wrote: > > I don’t see the fundamental difference between a link > technology that guarantees in-order delivery within a flow > (say by flow hashing, see ECMP) vs. some link scheme that > guarantees in-order delivery, say, only for some fraction of > the traffic characterized by some other means (say, other > header bits). > > [The "other means" and "other bits" wording is pretty ambiguous > here. I reckon I can guess what you mean but then I don't know > why you're saying this, 'cos I don't think I've disagreed with > you on this. So perhaps you could be more specific and we might > be able to see why you've brought this up.] > > Also I wasn't really talking about all "link technology that > guarantees in-order delivery within a flow". {Note 1} I was > talking about link technology where all flows are blocked while > waiting to get the aggregate back in order that it was in when > it arrived. I specifically said: > > > > Note that there can be multiple flows over one link. So > 'in-order delivery' for a link does not mean in order of TCP > sequence number. It means 'delivered in the order that packets > arrived at the link' (the link ingress adds its own sequence > numbers, and the link egress buffers them until it can send out > in the same order, or until a time-out or max no. of link > retransmissions). > > For example: > > * A packet resequencing buffer after allowing for link-layer > retransmissions is common for radio link technologies such > as LTE (PDCP layer) and 802.11 WiFi. > * A packet resequencing buffer after merging multiple bonded > link channels is common for other access link technologies > such as downstream DOCSIS bonded channels. > > > > > > Clearly, reordering is a problem that needs to be discussed in > the IETF as a whole. And we could discuss whether a revision of > RFC 3366 is needed. > > No. There is no proposal to alter general guidance for all links > like RFC 3366. No-one is saying this. > > There is not even a proposal to require or even recommend that > L4S-specific links do anything. > > The specific proposal is to require L4S /sources/ to use a > RACK-like scheme, as a condition for setting the ECT(1) > codepoint. See the last bullet in S.4.3 of > draft-ietf-tsvwg-ecn-l4s-id-05 > . > > > This says nothing about what L4S links MUST, SHOULD or MAY do. > It just gives an L4S link an opportunity not to have to do > resequencing. > > > > > But I am not convinced that this topic has to be tied into an > experiment such as L4S. > > It is an opportunity that currently only applies to L4S. > > L4S is merely an example of a case where we can mandate that > there will be no non-RACK traffic in a link, which creates an > opportunity for those who are implementing the L4S DualQ Coupled > AQM to ignore the RFC3366 resequencing advice for the L4S queue > (but we are not changing the advice, because L4S is only an > experiment). The prize is to remove the head-of-line blocking > problem for their users. > > This is not L4S-specific, altho there are no other examples at > the moment where this opportunity is possible (so in that sense > it is /currently/ L4S-specific). > > > The message has to be handled really carefully, because the > opportunities for misunderstanding are enormous (as evidenced by > this thread, and we haven't even started talking to > non-transport people yet). > > So Gorry and David B want me to draft a short I-D that they will > word-smith and author as tsvwg chairs to make the situation clear. > > I have said I don't want this discussion to be officially raised > outside the transport area until we are sure that a variant of > RACK is even feasible without any packet counting at all (i.e. > without the initial 3-DupACK rule in current RACK). So I'll > prioritize working that out for the next week or so, rather than > drafting anything. > > > > Bob > > {Note 1}: I hadn't considered that this would affect > technologies like ECMP that maintain order without a > resequencing buffer and without introducing HoL blocking. But > actually, the consequence there would be that L4S traffic could > be sprayed by ECMP without per-flow hashing. > > > > > Michael > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Friday, November 9, 2018 6:42 AM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > That is the point I thought you were making, and my point /is/ > about that. > > If an application needs all the packets (i.e. a reliable > protocol), it's not useful to reduce the latency of some packets > but not all. That's where the in-order requirement comes from. > > However, if a stream-based transport is used (i.e. TCP) the > /application/ still gets in-order delivery from TCP. It just > doesn't have to require links to provide in order delivery as well. > > Note that there can be multiple flows over one link. So > 'in-order delivery' for a link does not mean in order of TCP > sequence number. It means 'delivered in the order that packets > arrived at the link' (the link ingress adds its own sequence > numbers, and the link egress buffers them until it can send out > in the same order, or until a time-out or max no. of link > retransmissions). > > So, if the link loses a packet from flow A (the link isn't aware > of microflows, I'm just saying the packet happens to be from > flow A), link-layer in-order delivery will hold back all packets > sent after that packet (from all flows, not just flow A) until > the link repairs the gap or gives up. > > So hop-by-hop in-order delivery gives every flow the same delay > as the worst delayed flow. > > Of course, someone building a network for DETNET would avoid > link technologies like WiFi or LTE that frequently lose and > retransmit packets. But wherever there is variable delay in a > link, guaranteed in-order delivery per-hop means every flow is > guaranteed to always get the worst delay from every link, which > would have been experienced by only one flow without per-hop > in-order delivery. > > And many of the applications of DETNET involve dumb industrial > machinery that just expects everything to arrive in order and to > a clocked schedule. But it's always as effective to deploy a > resequencing buffer as the penultimate hop, screwed onto the > receiving machine if necessary, rather than require per-hop > resequencing in the network. > > ________________ > So, why do Internet links often ensure in-order delivery even > though TCP puts everything in order for the application? > > Short answer: the 3 DupACK rule (which is to do with > loss-recovery, a different issue from the discussion above). > > Long answer: As flow rates have scaled up, the typical time > between 3 packet arrivals has become so small that TCP's > 3-DupACK rule makes links have to provide delivery with only a > very small re-ordering degree - so small that it's easier for a > link to just deliver everything in the order it received it; not > because TCP doesn't put packets back in order, but just so as > not to trigger TCP into generating spurious retransmissions. > > > > Bob > > On 08/11/2018 16:35, Scharf, Michael wrote: > > Inline [ms] > > *From:*Bob Briscoe [mailto:in@bobbriscoe.net] > *Sent:* Thursday, November 8, 2018 12:56 PM > *To:* Scharf, Michael; tcpm@ietf.org > *Cc:* tsvwg@ietf.org > *Subject:* Re: [tsvwg] Cross-area alignment on "L4S and RACK" > > Michael, > > This is merely a symptom of a difference in opinion on where > the resequencing function should be located. > > * L4S takes the end-to-end approach saying that it is > sufficient to do resequencing in one place (the > receiving host) if it is needed. Then any resequencing > delay only affects that flow. > * The DETNET approach is saying the resequencing must be > done hop-by-hop. This means there appears to be no > resequencing needed on the receiver (except if there's > re-ordering on the final hop). > > * In order to guarantee no resequencing in the network > (DETNET approach), only the the worst case latency can > be guaranteed, and every packet has to have that same > worst-case latency. > * When you leave resequencing to the receiver (end-to-end > approach), most of the packets arrive earlier than they > would with DETNET, but out of order ones might not. Then > the application chooses whether it wants to wait. > > [ms] My point is different: There seem to be other working > groups in the IETF that do talk about “low latency” as well > but apparently they also do need in-order delivery of > packets, too. So the assumption that e.g. a link layer > technology can simply disable in-order delivery for all “low > latency” applications seems not correct. The reality may be > a bit more complex. > > The 3 DupACK rule in TCP led the Internet not to follow the > end-to-end principle on re-sequencing. Now we're removing > the 3 DupACK rule, we can take advantage of the e2e principle. > > [ms] For TCP, three DupACKS are a SHOULD in RFC 5681 and RFC > 5681 is standards track. So the bar for “removing” that rule > for TCP is not low… > > [ms] Also, the end-to-end principle comes with tradeoffs. > For instance, relying on the end-to-end principle for > recovery of bit errors is not efficient. For in-order > delivery there are tradeoffs as well, see e.g. Section 4 in > draft-ietf-tcpm-rack-04. There may be no free lunch. > > Of course, an application might choose to use TCP and L4S, > rather than UDP and L4S (e.g QUIC). Then there could still > be HoL blocking in the receiving TCP stack. But at least > there's no HoL blocking in the network, and the app can > choose between stream (TCP) or datagram (UDP). > > [ms] If LRO/GRO in the receiving TCP stack gets messed up, I > fail to see the benefit (see draft-ietf-tcpm-rack-04). > > Michael > > > Bob > > On 06/11/2018 19:20, Scharf, Michael wrote: > > A comment on the TCPM presentation "L4S and RACK": > > > > As far as I understand, the DETNET WG in RTG area has quite some uses cases for ultra-low latency transport - in particular also with bounded jitter. And some of these applications (e.g. using UDP) apparently may not be able to tolerate *any* out-of-order packet delivery. > > > > So perhaps some cross-area alignment on ulta-low-latency application requirements would be useful? > > > > Michael > > (who recently had to review draft-ietf-detnet-architecture) > > > > > > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > > > > -- > > ________________________________________________________________ > > Bob Briscoehttp://bobbriscoe.net/ > From nobody Thu Nov 22 04:25:31 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E8F12D4E8 for ; Thu, 22 Nov 2018 04:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qa7rXH-JVRop for ; Thu, 22 Nov 2018 04:25:27 -0800 (PST) Received: from mail.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CA5129AB8 for ; Thu, 22 Nov 2018 04:25:26 -0800 (PST) Received: from Idefix4.local (unknown [212.201.121.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fw153970) by mail.fh-muenster.de (Postfix) with ESMTPSA id F11092848E3 for ; Thu, 22 Nov 2018 13:25:24 +0100 (CET) To: tcpm@ietf.org From: Felix Weinrank Message-ID: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> Date: Thu, 22 Nov 2018 13:25:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 12:25:30 -0000 Hey RACK authors, we're evaluating the nuts and bolts of RACK in its current version and we are missing variable explanations. Most of the variables are listed and explained in section 5 (Definitions of variables) but at least two are missing. SND.UNA RACK.dupthresh << This is where we're stuck And I think this paragraph from section 5 needs two cosmetic newlines: "RACK.reo_wnd_persist" is the number of loss recoveries before resetting RACK.reo_wnd "RACK.dsack" indicates if a DSACK option has been received since last RACK.reo_wnd change "RACK.pkts_sacked" returns the total number of packets selectively acknowledged in the SACK scoreboard. Best regards Felix Weinrank From nobody Thu Nov 22 06:59:01 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C647130ED9 for ; Thu, 22 Nov 2018 06:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.959 X-Spam-Level: X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEEzuno_SAj1 for ; Thu, 22 Nov 2018 06:58:57 -0800 (PST) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A93130E34 for ; Thu, 22 Nov 2018 06:58:57 -0800 (PST) Received: by mail-ot1-x32d.google.com with SMTP id t5so8310683otk.1 for ; Thu, 22 Nov 2018 06:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G/ixvg1w2YVwd2p8nySQqdpxyH9851XE159PxdyVuiU=; b=G+3GblQngT/yhEMlYO2O51EzNVcUYQrtDx7ANu85/N8lnEKpUWkRjkVdiZO+xvHwEC afMvGPLLnQNZj/AlmfMUuPB7lakLY7po9359YxhTN3TehGOaVr2nilv0itZeGizp6hCU yVqCYBaxDiia5sk9Y9YitaukhePTuSZytbw5nFhXJ82s5SbTX6gbS9hGj9HrDU3/Dkmv 8bvMLhZs3qJFUFzIDtu6jTCIS0shCk/8XGfCzzMKFXl3E2KjOaJJVZHu1ijA3HPC4fDg qJTlj/+nKD7lMmOY0LbdRrJZa2/UvzkLnZjJ/h6DCTBtdtbymD/naYBxuCM9/E+pEy18 000A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G/ixvg1w2YVwd2p8nySQqdpxyH9851XE159PxdyVuiU=; b=OC8l9HAMOz6sB/YQ4397OE5gg97j8VUM7L+AvLWesvU+BBxtka+I6HBBX7C1NgEb1M 2/HDI25XMpqoUKkBFDkGnfSg0JEcsA/8a6diAlcJ45eGvcDMoGoronAORDL+vBwYlRkF QZSsOHmmX96kkAnO7i3GczznUYxCFsYK/eyraJIfbRGUr88kc3Hq2eGJIo8PN07f35UG FcVGT7BY7eKSYCDqx/pf49lFWFqtsVwPj2ZwLVjd96DXJOlQGTzwXGQx5R6iNOSbEtpH d9ohjk/A0/AvegLqcdyVx1iSyjY/rZFtHM45HKTnLmsPHfZ5TNhs9/47sKR4IvVVe86r f5ww== X-Gm-Message-State: AA+aEWadwVLbWvzdeUhFz/6wwmVqmxZnEXqZnFw4S5Idq0/8csmM0gCk 50hf5VBgO+07PKRjpgWvWdLWmy+OhW/NuIVFx5PfCA== X-Google-Smtp-Source: AFSGD/Wl4Mt6TTzYlMq5umsSVp2+CZHta+NK3/QiXBvnxtK+d8EQrHjfNecAsxI+At3ObD8DH1alBqlxzVVMZKcdmNs= X-Received: by 2002:a9d:489d:: with SMTP id d29mr5943991otf.311.1542898736681; Thu, 22 Nov 2018 06:58:56 -0800 (PST) MIME-Version: 1.0 References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> In-Reply-To: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> From: Neal Cardwell Date: Thu, 22 Nov 2018 09:58:40 -0500 Message-ID: To: Felix Weinrank Cc: "tcpm@ietf.org" , Yuchung Cheng Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 14:59:00 -0000 On Thu, Nov 22, 2018 at 7:25 AM Felix Weinrank wrote: > > Hey RACK authors, > > we're evaluating the nuts and bolts of RACK in its current version and > we are missing variable explanations. > Most of the variables are listed and explained in section 5 (Definitions > of variables) but at least two are missing. Thanks for pointing these out! We'll add these in the next draft. > SND.UNA The RACK draft uses the SND.UNA and SND.NXT notations from the TCP RFC (from https://tools.ietf.org/html/rfc793#section-3.3 on page 25): SND.UNA = oldest unacknowledged sequence number SND.NXT = next sequence number to be sent > RACK.dupthresh << This is where we're stuck This is using the DupThresh term from RFC 6675, "A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP" (from https://tools.ietf.org/html/rfc6675 on page 4): We define a variable "DupThresh" that holds the number of duplicate acknowledgments required to trigger a retransmission. Per [RFC5681], this threshold is defined to be 3 duplicate acknowledgments. > And I think this paragraph from section 5 needs two cosmetic newlines: > "RACK.reo_wnd_persist" is the number of loss recoveries before > resetting RACK.reo_wnd "RACK.dsack" indicates if a DSACK option has > been received since last RACK.reo_wnd change "RACK.pkts_sacked" > returns the total number of packets selectively acknowledged in the > SACK scoreboard. Thanks for pointing out the missing newlines! We will try to get that formatting cleaned up in the next rev. thanks, neal From nobody Thu Nov 22 07:01:28 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F03D127133 for ; Thu, 22 Nov 2018 07:01: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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUAwqcP9bZ8q for ; Thu, 22 Nov 2018 07:01:24 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D22B126CB6 for ; Thu, 22 Nov 2018 07:01:24 -0800 (PST) Received: from [10.0.1.118] (unknown [212.201.121.94]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 041F5721E280C; Thu, 22 Nov 2018 16:01:12 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Michael Tuexen In-Reply-To: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> Date: Thu, 22 Nov 2018 16:01:09 +0100 Cc: tcpm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> To: Felix Weinrank X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 15:01:27 -0000 > On 22. Nov 2018, at 13:25, Felix Weinrank = wrote: >=20 > Hey RACK authors, >=20 > we're evaluating the nuts and bolts of RACK in its current version and = we are missing variable explanations. > Most of the variables are listed and explained in section 5 = (Definitions of variables) but at least two are missing. >=20 > SND.UNA The above is a standard TCP variable explained in https://tools.ietf.org/html/rfc793#section-3.2 Best regards Michael > RACK.dupthresh << This is where we're stuck >=20 > And I think this paragraph from section 5 needs two cosmetic newlines: > "RACK.reo_wnd_persist" is the number of loss recoveries before > resetting RACK.reo_wnd "RACK.dsack" indicates if a DSACK option has > been received since last RACK.reo_wnd change "RACK.pkts_sacked" > returns the total number of packets selectively acknowledged in the > SACK scoreboard. >=20 > Best regards > Felix Weinrank >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Nov 22 07:04:06 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4505130ED9 for ; Thu, 22 Nov 2018 07:04:04 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcE2tM3ZuTa1 for ; Thu, 22 Nov 2018 07:03:56 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531FA130DC0 for ; Thu, 22 Nov 2018 07:03:49 -0800 (PST) Received: from [10.0.1.118] (unknown [212.201.121.94]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 15784721E280C; Thu, 22 Nov 2018 16:03:42 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Michael Tuexen In-Reply-To: Date: Thu, 22 Nov 2018 16:03:39 +0100 Cc: Felix Weinrank , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> To: Neal Cardwell X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 15:04:05 -0000 > On 22. Nov 2018, at 15:58, Neal Cardwell = wrote: >=20 > On Thu, Nov 22, 2018 at 7:25 AM Felix Weinrank = wrote: >>=20 >> Hey RACK authors, >>=20 >> we're evaluating the nuts and bolts of RACK in its current version = and >> we are missing variable explanations. >> Most of the variables are listed and explained in section 5 = (Definitions >> of variables) but at least two are missing. >=20 > Thanks for pointing these out! We'll add these in the next draft. >=20 >> SND.UNA >=20 > The RACK draft uses the SND.UNA and SND.NXT notations from the TCP RFC > (from https://tools.ietf.org/html/rfc793#section-3.3 on page 25): >=20 > SND.UNA =3D oldest unacknowledged sequence number >=20 > SND.NXT =3D next sequence number to be sent >=20 >> RACK.dupthresh << This is where we're stuck >=20 > This is using the DupThresh term from RFC 6675, "A Conservative Loss > Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP" > (from https://tools.ietf.org/html/rfc6675 on page 4): >=20 > We define a variable "DupThresh" that holds the number of duplicate > acknowledgments required to trigger a retransmission. Per = [RFC5681], > this threshold is defined to be 3 duplicate acknowledgments. Please add such a description for RACK.dupthresh to Section 5. Best regards Michael >=20 >> And I think this paragraph from section 5 needs two cosmetic = newlines: >> "RACK.reo_wnd_persist" is the number of loss recoveries before >> resetting RACK.reo_wnd "RACK.dsack" indicates if a DSACK option has >> been received since last RACK.reo_wnd change "RACK.pkts_sacked" >> returns the total number of packets selectively acknowledged in the >> SACK scoreboard. >=20 > Thanks for pointing out the missing newlines! We will try to get that > formatting cleaned up in the next rev. >=20 > thanks, > neal >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Nov 22 07:28:33 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688A5129533 for ; Thu, 22 Nov 2018 07:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yv2Jk1wjv_Mm for ; Thu, 22 Nov 2018 07:28:29 -0800 (PST) Received: from mail.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE861292AD for ; Thu, 22 Nov 2018 07:28:28 -0800 (PST) Received: from Idefix4.local (unknown [212.201.121.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fw153970) by mail.fh-muenster.de (Postfix) with ESMTPSA id 4C20B2848DB for ; Thu, 22 Nov 2018 16:28:27 +0100 (CET) To: tcpm@ietf.org References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> From: Felix Weinrank Message-ID: <632bc671-4294-5eb3-ff8a-8c7dd492beb1@fh-muenster.de> Date: Thu, 22 Nov 2018 16:28:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 15:28:31 -0000 On 22.11.18 15:58, Neal Cardwell wrote: > On Thu, Nov 22, 2018 at 7:25 AM Felix Weinrank wrote: >> Hey RACK authors, >> >> we're evaluating the nuts and bolts of RACK in its current version and >> we are missing variable explanations. >> Most of the variables are listed and explained in section 5 (Definitions >> of variables) but at least two are missing. > Thanks for pointing these out! We'll add these in the next draft. > >> SND.UNA > The RACK draft uses the SND.UNA and SND.NXT notations from the TCP RFC > (from https://tools.ietf.org/html/rfc793#section-3.3 on page 25): > > SND.UNA = oldest unacknowledged sequence number > > SND.NXT = next sequence number to be sent > >> RACK.dupthresh << This is where we're stuck > This is using the DupThresh term from RFC 6675, "A Conservative Loss > Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP" > (from https://tools.ietf.org/html/rfc6675 on page 4): > > We define a variable "DupThresh" that holds the number of duplicate > acknowledgments required to trigger a retransmission. Per [RFC5681], > this threshold is defined to be 3 duplicate acknowledgments. Thanks for the explanation. I don't completely understand the following check:        If RACK.reordering_seen is FALSE:            If in loss recovery:  /* If in fast or timeout recovery */                RACK.reo_wnd = 0                Return            Else if RACK.pkts_sacked >= RACK.dupthresh:                RACK.reo_wnd = 0                return The Draft says: "RACK.pkts_sacked" returns the total number of packets selectively acknowledged in the SACK scoreboard. Whats the purpose of this check: RACK.pkts_sacked >= RACK.dupthresh Best regards Felix > >> And I think this paragraph from section 5 needs two cosmetic newlines: >> "RACK.reo_wnd_persist" is the number of loss recoveries before >> resetting RACK.reo_wnd "RACK.dsack" indicates if a DSACK option has >> been received since last RACK.reo_wnd change "RACK.pkts_sacked" >> returns the total number of packets selectively acknowledged in the >> SACK scoreboard. > Thanks for pointing out the missing newlines! We will try to get that > formatting cleaned up in the next rev. > > thanks, > neal From nobody Thu Nov 22 07:28:45 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2266131038 for ; Thu, 22 Nov 2018 07:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.959 X-Spam-Level: X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLP-ezYzYUpX for ; Thu, 22 Nov 2018 07:28:35 -0800 (PST) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05857130FF6 for ; Thu, 22 Nov 2018 07:28:35 -0800 (PST) Received: by mail-oi1-x232.google.com with SMTP id b141so7707821oii.12 for ; Thu, 22 Nov 2018 07:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XYWagwvcqCuo+XBzSYb+HVI/wz2e3DOZOzYF7KakPaA=; b=p6g3JH3UwW2pJRYax3Dkp551VN8fuGkFCjCerL6BG8V1dx2JLbi1g6SyJBi25lXrVX 37BpM9/lOCrjyalEq5XFVx37qEPU+ssHxNiF5HzzVmJe1Sx554cGh9jZtymltUUt0j1d AA57uXhNTQb4lirP7r4jtIp6mSMJFoqxeBhRqJTmZvbgA5eOsvnKMebklWs448VmIsi9 P4JNTYJqeG/ie4rgKdTYsecJUBpZDqr18eF3XKHmDDELsT1iZfRyPm+JuVoaOZn/YHuV 7E7UDtIRbfGD6KlQEH8SYBjGx0Ibqy/jEbtAJLuRIC1dZDRC3JDRmJE53PwzqdK/ymBZ 8YxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XYWagwvcqCuo+XBzSYb+HVI/wz2e3DOZOzYF7KakPaA=; b=qJB4Ih/oInHpLq4FZiTe3EbPVlUDF8DbtW+GPLdQMqmU2k8uAHRqTMLdEPgt2CINEv mBrL+m3nWP8Ldsxb+MWT4fHkZSoAVEpYQQ0j4BLa+pp9MKRepZgjvjo7yQ7FAyl2nYC/ ypWbkcKoDER3wc2aVqHaVj2BjBsrD7KcA3iyvUGHZzvpbuPpmYv/pb5IJXShx9u6tDKk 8WysnXoI3K0rSAs1Bp0T35R7E13erJoGq2bN0YyB15PdH0OOZO6YukWxpaYB8WK/tRFO BqsFPGS2QBizvLnb1uUuPYrOhBTY9S3iNU/0PZHXqoN0AukWoBLAIcYrXb859CjtCk72 28XQ== X-Gm-Message-State: AGRZ1gIMVlJF8BOMn9PweC0e06v4wq319Rdrwll5M0n9Drhhbcsxp2dn ra17ohV3Wl7n49+5I23RxAag2rG/7IiwECDOIpAW4Cwu+OQJwg== X-Google-Smtp-Source: AJdET5fiLWFkab5X0UUFXMaTbHLc5WRGd9BwXg80O9bBXsm+Bc8gM6iYeT9fhQgf26xwyl0DW9hDpe+uG1axkAlLyP4= X-Received: by 2002:aca:c43:: with SMTP id i3mr6745716oiy.157.1542900513950; Thu, 22 Nov 2018 07:28:33 -0800 (PST) MIME-Version: 1.0 References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> In-Reply-To: From: Neal Cardwell Date: Thu, 22 Nov 2018 10:28:17 -0500 Message-ID: To: Michael Tuexen Cc: ncardwell=40google.com@dmarc.ietf.org, "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 15:28:43 -0000 On Thu, Nov 22, 2018 at 10:04 AM Michael Tuexen wrote: > > > On 22. Nov 2018, at 15:58, Neal Cardwell wrote: > > > > On Thu, Nov 22, 2018 at 7:25 AM Felix Weinrank wrote: > >> RACK.dupthresh << This is where we're stuck > > > > This is using the DupThresh term from RFC 6675, "A Conservative Loss > > Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP" > > (from https://tools.ietf.org/html/rfc6675 on page 4): > > > > We define a variable "DupThresh" that holds the number of duplicate > > acknowledgments required to trigger a retransmission. Per [RFC5681], > > this threshold is defined to be 3 duplicate acknowledgments. > Please add such a description for RACK.dupthresh to Section 5. Thanks, Michael. Based on this discussion, we have inserted a definition of RACK.dupthresh in Section 5 in our internal version of the draft, so it will be in the next rev. thanks, neal From nobody Thu Nov 22 08:01:14 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5ADF1292AD for ; Thu, 22 Nov 2018 08:01:12 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fi0Khoj4Rqu for ; Thu, 22 Nov 2018 08:01:06 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A550C126C7E for ; Thu, 22 Nov 2018 08:01:06 -0800 (PST) Received: from [10.0.1.118] (unknown [212.201.121.94]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 8E977721E280C; Thu, 22 Nov 2018 17:01:02 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Michael Tuexen In-Reply-To: Date: Thu, 22 Nov 2018 17:00:59 +0100 Cc: ncardwell=40google.com@dmarc.ietf.org, "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <904FE7A2-BE98-43A5-B4E4-4C23700D672E@lurchi.franken.de> References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> To: Neal Cardwell X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 16:01:13 -0000 > On 22. Nov 2018, at 16:28, Neal Cardwell wrote: >=20 > On Thu, Nov 22, 2018 at 10:04 AM Michael Tuexen > wrote: >>=20 >>> On 22. Nov 2018, at 15:58, Neal Cardwell = wrote: >>>=20 >>> On Thu, Nov 22, 2018 at 7:25 AM Felix Weinrank = wrote: >>>> RACK.dupthresh << This is where we're stuck >>>=20 >>> This is using the DupThresh term from RFC 6675, "A Conservative Loss >>> Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP" >>> (from https://tools.ietf.org/html/rfc6675 on page 4): >>>=20 >>> We define a variable "DupThresh" that holds the number of duplicate >>> acknowledgments required to trigger a retransmission. Per = [RFC5681], >>> this threshold is defined to be 3 duplicate acknowledgments. >> Please add such a description for RACK.dupthresh to Section 5. >=20 > Thanks, Michael. Based on this discussion, we have inserted a > definition of RACK.dupthresh in Section 5 in our internal version of > the draft, so it will be in the next rev. Great, thanks a lot. Best regards Michael >=20 > thanks, > neal From nobody Thu Nov 22 08:16:51 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12BE130DF9 for ; Thu, 22 Nov 2018 08:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.959 X-Spam-Level: X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMTJeneD_Clp for ; Thu, 22 Nov 2018 08:16:43 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BABD2124BF6 for ; Thu, 22 Nov 2018 08:16:43 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id x23so7863200oix.3 for ; Thu, 22 Nov 2018 08:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=10y5h2qL13F2sOzNJgqC04ZKMslgvekXmiGAXcnnl8w=; b=gEB/HKrSUltn3+sTrT63v4ima7dc+e6LJfM17UDpJTKncYHQBF5Fubwymbnj/qQFmi 0p/f2A8wF3MdaraqQEWPGTyWAwDtnvyPXu5nhHwQ7Ai2/UBRi/dNGp0qysz8U4QmgoUe NWFMLjmn4mk5kQYmGhzJYbiBdJMhL071i7YChtr6nLyqIpouVv6QnmnV/JcJaXOG7xRs ddRxTmq4lsoOtPP0yGcZkxeODiii/WZ8aN8Sk77UILg2LusV8+WbFmyiEjTTCkpLB+pV gS4KV6BDZmfTUib3O4K23VGrvxc6eWVqgitNnNxWd7lpgaSt+1xeKbjFLxpW9dZYuj/Y bXFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=10y5h2qL13F2sOzNJgqC04ZKMslgvekXmiGAXcnnl8w=; b=OheFj9AdJXpk89CgwHyJ4xFFw+Go1DvaWZyMLm0QDRm4k/LMMWaxG/W/DHckspJTpp i+Oi4kg9JfIdbb4fePlBHf/gCVPs3xB0R5p/YXolxUUOOQIusA4ttanbSeJpGGVr4ARS 6TeasyEo6pynXAlG2yPWDvwPgI3xAq0LUfpNWM7PY+Dj/3asXBA7J43egio0hdOYCRkX MOfFJpDv6lo126N6cnMvVTuvrPl1Cf6qzmX785tDFkfGPYu3V95BgKW0b/kC3Iqd0Lm4 8oXx3fA5kH5YWUAjuMaB4yXEYTRSnMG6s8xrwoEVBNbCMBXI/AGRnx+LojBZQEWCGnn1 XZEA== X-Gm-Message-State: AGRZ1gJAnfIBV7U7XZYi/nQDLRmV05fl1FEn88NMvzvmMw0XDnfrLeDA v0JPW3hvzuuZwFhXlkj4xX3qaqPi9i9y6lfFikT90A== X-Google-Smtp-Source: AJdET5fARxnfnES6A2UT6cNy+H/qe74TyEZUwi7kLPOCMnJL3P/PgMbPEq4KhvpcC9mriMoFIhRQhaUjjnC3YQHOZYY= X-Received: by 2002:aca:4ace:: with SMTP id x197mr6764362oia.129.1542903402785; Thu, 22 Nov 2018 08:16:42 -0800 (PST) MIME-Version: 1.0 References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> <632bc671-4294-5eb3-ff8a-8c7dd492beb1@fh-muenster.de> In-Reply-To: <632bc671-4294-5eb3-ff8a-8c7dd492beb1@fh-muenster.de> From: Neal Cardwell Date: Thu, 22 Nov 2018 11:16:26 -0500 Message-ID: To: Felix Weinrank Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 16:16:47 -0000 On Thu, Nov 22, 2018 at 10:28 AM Felix Weinrank wrote: > > > On 22.11.18 15:58, Neal Cardwell wrote: > > On Thu, Nov 22, 2018 at 7:25 AM Felix Weinrank wrote: > >> Hey RACK authors, > >> > >> we're evaluating the nuts and bolts of RACK in its current version and > >> we are missing variable explanations. > >> Most of the variables are listed and explained in section 5 (Definitions > >> of variables) but at least two are missing. > > Thanks for pointing these out! We'll add these in the next draft. > > > >> SND.UNA > > The RACK draft uses the SND.UNA and SND.NXT notations from the TCP RFC > > (from https://tools.ietf.org/html/rfc793#section-3.3 on page 25): > > > > SND.UNA = oldest unacknowledged sequence number > > > > SND.NXT = next sequence number to be sent > > > >> RACK.dupthresh << This is where we're stuck > > This is using the DupThresh term from RFC 6675, "A Conservative Loss > > Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP" > > (from https://tools.ietf.org/html/rfc6675 on page 4): > > > > We define a variable "DupThresh" that holds the number of duplicate > > acknowledgments required to trigger a retransmission. Per [RFC5681], > > this threshold is defined to be 3 duplicate acknowledgments. > Thanks for the explanation. > > I don't completely understand the following check: > > If RACK.reordering_seen is FALSE: > If in loss recovery: /* If in fast or timeout recovery */ > RACK.reo_wnd = 0 > Return > Else if RACK.pkts_sacked >= RACK.dupthresh: > RACK.reo_wnd = 0 > return > > The Draft says: > "RACK.pkts_sacked" returns the total number of packets selectively > acknowledged in the SACK scoreboard. > > Whats the purpose of this check: RACK.pkts_sacked >= RACK.dupthresh This is the traditional TCP Fast Retransmit heuristic, described in https://tools.ietf.org/html/rfc5681 in section 3.2, and https://tools.ietf.org/html/rfc6675 in section 5, and the older https://tools.ietf.org/html/rfc2001 in section 3. One way to think about it would be: if a receiver selectively acknowledges a data sequence range, then that means there is an unacknowledged "hole" in the sequence space below the selectively acknowledged range. There are two main possibilities for this hole: (1) That unacknowledged hole will stay unacknowledged indefinitely, suggesting that the original packets containing that data were permanently lost, and need to be retransmitted (which this algorithm triggers). (2) That unacknowledged hole will be acknowledged later, which would suggest that the network reordered the data somewhere in transit, delaying the earlier data and causing it to arrive after the later data. Waiting for three data segments to be selectively acknowledged allows extra "settling" time for that reordered packet to make it to the receiver and fill that hole; this implicit settling delay helps avoid spurious retransmits in cases where the network has started to reorder packets but the sender has not had a chance to observe the reordering yet. For cases where the sender has observed reordering (RACK.reord is true) then the sender maintains (in RACK.reo_wnd) an explicit estimate of how long (in time) it should wait for such reordering to settle, before triggering a fast retransmit. BTW, for consistency, the line that says: If RACK.reordering_seen is FALSE: should use the "RACK.reord" name, and should be: If RACK.reord is FALSE: That will be fixed in the next rev. thanks, neal From nobody Thu Nov 22 10:22:14 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77A8130FE4 for ; Thu, 22 Nov 2018 10:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.959 X-Spam-Level: X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPHMb-MI63yI for ; Thu, 22 Nov 2018 10:22:10 -0800 (PST) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25700130F19 for ; Thu, 22 Nov 2018 10:22:10 -0800 (PST) Received: by mail-oi1-x22f.google.com with SMTP id v6so8132864oif.2 for ; Thu, 22 Nov 2018 10:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bwaonNUKOkLl/IRo68JiiBpZyBmAYR9BXV9WnzI4JRo=; b=kClkaAlUfOj4sE9iZFDavE10rwjiT7HzkevpH8OhdA1gFz7jmHZy6iCzKjzUYqj0vE EY50wGRBc1zH5gc+GTHGM13XJB47GbPoCDeNzROiIJt6NfL80ZKY35wXrma0p77qQfU/ NTG9PsKwVC9OIO2DORZC+TUJoEM65fL+XAEOag1ONE5Po90M5aUIf/jTfs+BBenPr0Cf MyuyFZ0xKK7VasF0OmOzc4QgvtNwYXU40x+lL8ONxeIfzO5XVX6Ea6xxrxPKT7M8FhY3 QMviuaPTnjlrF5BbDc5KVrfLLl8+EnV+KzlXW3a5bNPhnmw6JUunYbf8ndXPyH500bQ2 XzwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bwaonNUKOkLl/IRo68JiiBpZyBmAYR9BXV9WnzI4JRo=; b=KUfxZDbzVHCaci2fkhUB3m3AK9QaNlJNof3iHjcBaCV5BBiCAFMiUYEs8L606iAYh6 4cfHZLloV/J/faBBWcLGrhUoZHutc4XwI3UP+kfQpvbMYR4YBOyygzYX9FccEyTDwIQT yfVmEpDZsngHDo+yy56TLPhZA1wy8QMGM/Kv4pQ+CvHtNa9YR0zktR2JXg1F8CLYrkrx w6k4pi66bwAJ4X5vfHeokP4oqR3vFZ65ZmEU3rkNS7BCDtUCygAnn7Au+d/wYKIjCzOB 5moYL5S6MMSKwDtbC3HeJndah3mzSX6WhsMGrOKr0P/SmuB1L2gYy4O8aN6rJ1bLLG1l ZxUQ== X-Gm-Message-State: AGRZ1gJ0QC+FXvbwnlnD5CoKnS9LsNfhnMoWYBzTRPSXxKc968Difdbt L7mibHuLiLjfj/4osBnUJ+ZV9mLOpceYYlZmkcWRKA== X-Google-Smtp-Source: AJdET5d8PZoDTFvJoMy5hbJpPmAgsZlud/LQdu7GGNuZfGA/bGiLoYA/tlH12m/uK/enIPq01CzHWDLCA936FYpYBz0= X-Received: by 2002:aca:52d4:: with SMTP id g203mr6960473oib.14.1542910929215; Thu, 22 Nov 2018 10:22:09 -0800 (PST) MIME-Version: 1.0 References: <246bdcf112bb4ebe875df662e3467ab5@HICGWSMB01.ad.harman.com> In-Reply-To: <246bdcf112bb4ebe875df662e3467ab5@HICGWSMB01.ad.harman.com> From: Neal Cardwell Date: Thu, 22 Nov 2018 13:21:52 -0500 Message-ID: To: Kiruthika.Varadarajan@harman.com Cc: "tcpm@ietf.org" , John Heffner Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Linux TCP Stack and Zero Window Probe X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2018 18:22:13 -0000 Hi, This is expected. Linux TCP uses the same code to generate keepalive probes and zero window probes. (Note that the comment for tcp_write_wakeup() is "Initiate keepalive or window probe from timer"). So, on the wire and divorced from context, the two kinds of packets can look the same. Given the context in your trace, with the receiver just having advertised a receive window of 0 bytes, and with the probes starting in the range of a plausible RTO, and exponentially backing off, those look like zero window probes to me. best, neal ps: this is a condensed version of the trace, with tcpdump -ttt relative timestamps: 00:00:00.025099 cli > srv: S 3878781099:3878781099(0) win 65535 00:00:00.000506 srv > cli: S. 936571641:936571641(0) ack 3878781100 win 29200 00:00:00.012473 cli > srv: . 3878781100:3878781100(0) ack 936571642 win 65535 00:00:01.003173 srv > cli: P. 936571642:936571643(1) ack 3878781100 win 29200 00:00:00.013407 cli > srv: . 3878781100:3878781100(0) ack 936571643 win 0 00:00:01.208250 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200 00:00:00.431995 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200 00:00:00.887970 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200 00:00:01.728002 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200 On Wed, Nov 21, 2018 at 1:21 PM Varadarajan, Kiruthika wrote: > > Hi Team, > > I have a question in Zero Window Probe in TCP. > > If the client sends Zero Window, according to RFC spec is it mandatory for the Linux TCP stack to send Zero Window Probe. > > In my stack I am not getting Zero Window Probe instead I am getting Keep Alive. > > I have attached my wireshark traces. Can you please confirm if this is the expected behavior from TCP stack. > > > > Thanks & Regards > > Kiruthika > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Nov 23 08:43:14 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCAF130DFD for ; Fri, 23 Nov 2018 08:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQg206w0DVXq for ; Fri, 23 Nov 2018 08:43:09 -0800 (PST) Received: from mail.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D0812F1A6 for ; Fri, 23 Nov 2018 08:43:09 -0800 (PST) Received: from Idefix4.local (unknown [212.201.121.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fw153970) by mail.fh-muenster.de (Postfix) with ESMTPSA id 188562803AC for ; Fri, 23 Nov 2018 17:43:07 +0100 (CET) To: tcpm@ietf.org References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> <632bc671-4294-5eb3-ff8a-8c7dd492beb1@fh-muenster.de> From: Felix Weinrank Message-ID: <2c008352-5068-f915-8603-70cb4a110002@fh-muenster.de> Date: Fri, 23 Nov 2018 17:43:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 16:43:12 -0000 Thank you very much for the explanation, this helps a lot! :) Felix On 22.11.18 17:16, Neal Cardwell wrote: > On Thu, Nov 22, 2018 at 10:28 AM Felix Weinrank wrote: >> >> On 22.11.18 15:58, Neal Cardwell wrote: >>> On Thu, Nov 22, 2018 at 7:25 AM Felix Weinrank wrote: >>>> Hey RACK authors, >>>> >>>> we're evaluating the nuts and bolts of RACK in its current version and >>>> we are missing variable explanations. >>>> Most of the variables are listed and explained in section 5 (Definitions >>>> of variables) but at least two are missing. >>> Thanks for pointing these out! We'll add these in the next draft. >>> >>>> SND.UNA >>> The RACK draft uses the SND.UNA and SND.NXT notations from the TCP RFC >>> (from https://tools.ietf.org/html/rfc793#section-3.3 on page 25): >>> >>> SND.UNA = oldest unacknowledged sequence number >>> >>> SND.NXT = next sequence number to be sent >>> >>>> RACK.dupthresh << This is where we're stuck >>> This is using the DupThresh term from RFC 6675, "A Conservative Loss >>> Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCP" >>> (from https://tools.ietf.org/html/rfc6675 on page 4): >>> >>> We define a variable "DupThresh" that holds the number of duplicate >>> acknowledgments required to trigger a retransmission. Per [RFC5681], >>> this threshold is defined to be 3 duplicate acknowledgments. >> Thanks for the explanation. >> >> I don't completely understand the following check: >> >> If RACK.reordering_seen is FALSE: >> If in loss recovery: /* If in fast or timeout recovery */ >> RACK.reo_wnd = 0 >> Return >> Else if RACK.pkts_sacked >= RACK.dupthresh: >> RACK.reo_wnd = 0 >> return >> >> The Draft says: >> "RACK.pkts_sacked" returns the total number of packets selectively >> acknowledged in the SACK scoreboard. >> >> Whats the purpose of this check: RACK.pkts_sacked >= RACK.dupthresh > This is the traditional TCP Fast Retransmit heuristic, described in > https://tools.ietf.org/html/rfc5681 in section 3.2, and > https://tools.ietf.org/html/rfc6675 in section 5, and the older > https://tools.ietf.org/html/rfc2001 in section 3. > > One way to think about it would be: if a receiver selectively > acknowledges a data sequence range, then that means there is an > unacknowledged "hole" in the sequence space below the selectively > acknowledged range. There are two main possibilities for this hole: > (1) That unacknowledged hole will stay unacknowledged indefinitely, > suggesting that the original packets containing that data were > permanently lost, and need to be retransmitted (which this algorithm > triggers). (2) That unacknowledged hole will be acknowledged later, > which would suggest that the network reordered the data somewhere in > transit, delaying the earlier data and causing it to arrive after the > later data. Waiting for three data segments to be selectively > acknowledged allows extra "settling" time for that reordered packet to > make it to the receiver and fill that hole; this implicit settling > delay helps avoid spurious retransmits in cases where the network has > started to reorder packets but the sender has not had a chance to > observe the reordering yet. For cases where the sender has observed > reordering (RACK.reord is true) then the sender maintains (in > RACK.reo_wnd) an explicit estimate of how long (in time) it should > wait for such reordering to settle, before triggering a fast > retransmit. > > BTW, for consistency, the line that says: > > If RACK.reordering_seen is FALSE: > > should use the "RACK.reord" name, and should be: > > If RACK.reord is FALSE: > > That will be fixed in the next rev. > > thanks, > neal From nobody Fri Nov 23 09:44:22 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5491252B7 for ; Thu, 22 Nov 2018 21:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Axk0tksdGBN for ; Thu, 22 Nov 2018 21:54:29 -0800 (PST) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51D0130DE5 for ; Thu, 22 Nov 2018 21:54:28 -0800 (PST) Received: from [67.219.250.194] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-b.us-west-2.aws.symcld.net id 4E/4F-08857-22197FB5; Fri, 23 Nov 2018 05:33:22 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAKsWRWlGSWpSXmKPExsXinSZ8TFdp4vd og33L5C123FnEZNFxZy+LxbaT85kcmD12zrrL7rFgU6nHkiU/mQKYo1gz85LyKxJYM05Pm8lS 8FKxYvetaYwNjBsUuxi5OIQEtjBK3N/TyAbhbGaUOLShiRXCOcgosW7iKuYuRk4ONgFHia8/H 7OD2CICGhJ3Fz1gBLGZBbwk7v6+wQZiCwt4SOzeeg8ozgFU4ylx9AcTRLmVxMYlL8FaWQRUJd 43r2QFsXkF3CUmn//FCLGrF2jx/ptgMzkFAiXu7f0F1swoICbx/dQaJohd4hK3nswHsyUEBCS W7DnPDGGLSrx8/I8VwjaQ2Lp0HwvIDRICChL/X3CAmMwCmhLrd+lDTFGUmNL9kB3iBEGJkzOf sIDYQgK6Epfn/2OfwCg+C8myWQjds5B0z0LSvYCRZRWjRVJRZnpGSW5iZo6uoYGBrqGhka6hs QkQm+slVukm6ZUW65anFpfoGukllhfrFVfmJuek6OWllmxiBMZoSkFb5w7Gzu70Q4ySHExKor y/Qr9HC/El5adUZiQWZ8QXleakFh9ilOHgUJLgfdMPlBMsSk1PrUjLzAEmC5i0BAePkghvKUi at7ggMbc4Mx0idYrRkuPfgv/TmTmunOmcwczxZu6PGcxCLHn5ealS4ryrQBoEQBoySvPgxsES 2iVGWSlhXkYGBgYhnoLUotzMElT5V4ziHIxKwrwNIFN4MvNK4La+AjqICegg2TOfQQ4qSURIS TUwOmdvEHb7YmP/MXHSZzUFpaPrtooZXPJiMJ3k1btil3rrVZfl+9g371yw4OB79nuHmy4b7p 3NYPlrYerJvNNu/H6NHLs2OLF/V4mZuFB0VZeLXjmfa+B04UVrnP70XDFjad36r0i05Xj2h8X T665M3bqcf936nCsnutI0VL7eST30WfKM9S2hBUosxRmJhlrMRcWJAIDfQqZjAwAA X-Env-Sender: Kiruthika.Varadarajan@harman.com X-Msg-Ref: server-23.tower-342.messagelabs.com!1542951201!2179324!1 X-Originating-IP: [75.102.19.198] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.14.24; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12442 invoked from network); 23 Nov 2018 05:33:22 -0000 Received: from unknown.ord.scnet.net (HELO HICGWSMB09.ad.harman.com) (75.102.19.198) by server-23.tower-342.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 23 Nov 2018 05:33:22 -0000 Received: from HICGWSMB08.ad.harman.com (10.10.24.109) by HICGWSMB09.ad.harman.com (10.10.24.241) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 23 Nov 2018 00:33:20 -0500 Received: from HICGWSMB01.ad.harman.com (10.10.24.94) by HICGWSMB08.ad.harman.com (10.10.24.109) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 23 Nov 2018 00:33:20 -0500 Received: from HICGWSMB01.ad.harman.com ([fe80::14bd:f949:b421:895d]) by HICGWSMB01.ad.harman.com ([fe80::14bd:f949:b421:895d%13]) with mapi id 15.00.1365.000; Thu, 22 Nov 2018 23:33:20 -0600 From: "Varadarajan, Kiruthika" To: Neal Cardwell CC: "tcpm@ietf.org" , John Heffner Thread-Topic: [EXTERNAL] Re: [tcpm] Linux TCP Stack and Zero Window Probe Thread-Index: AdSBsCBxTffgOUeISfqsOaGpkVCGxwBEme0AAAmIbDA= Date: Fri, 23 Nov 2018 05:33:20 +0000 Message-ID: <1ad46d5108314dadbf913919f2907872@HICGWSMB01.ad.harman.com> References: <246bdcf112bb4ebe875df662e3467ab5@HICGWSMB01.ad.harman.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.10.24.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 23 Nov 2018 09:44:21 -0800 Subject: Re: [tcpm] [EXTERNAL] Re: Linux TCP Stack and Zero Window Probe X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 05:54:43 -0000 SGkgTmVhbCwNCiBCdXQgUkZDIHNwZWMgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5 MyNzZWN0aW9uLTMuNyAgc2F5cyBhZnRlciBUQ1AtWmVybyBXaW5kb3cgZnJvbSBjbGllbnQsIHNl cnZlciBtdXN0IHNlbmQgDQogVENQIFplcm8gV2luZG93IFByb2JlLCBIZW5jZSBpbiB0Y3Bfd3Jp dGVfd2FrZXVwLCB0Y3BfeG1pdF9wcm9iZV9za2IgZXhwZWN0IG1pYiB0byBiZSBMSU5VWF9NSUJf VENQV0lOUFJPQkUNCiAgQXJlIHdlIG5vdCB2aW9sYXRpbmcgdGhlIHNwZWM/DQoNCg0KVGhhbmtz ICYgUmVnYXJkcw0KS2lydXRoaWthDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IE5lYWwgQ2FyZHdlbGwgPG5jYXJkd2VsbEBnb29nbGUuY29tPiANClNlbnQ6IFRodXJzZGF5 LCBOb3ZlbWJlciAyMiwgMjAxOCAxMTo1MiBQTQ0KVG86IFZhcmFkYXJhamFuLCBLaXJ1dGhpa2Eg PEtpcnV0aGlrYS5WYXJhZGFyYWphbkBoYXJtYW4uY29tPg0KQ2M6IHRjcG1AaWV0Zi5vcmc7IEpv aG4gSGVmZm5lciA8am9obndoZWZmbmVyQGdtYWlsLmNvbT4NClN1YmplY3Q6IFtFWFRFUk5BTF0g UmU6IFt0Y3BtXSBMaW51eCBUQ1AgU3RhY2sgYW5kIFplcm8gV2luZG93IFByb2JlDQoNCkhpLA0K DQpUaGlzIGlzIGV4cGVjdGVkLiBMaW51eCBUQ1AgdXNlcyB0aGUgc2FtZSBjb2RlIHRvIGdlbmVy YXRlIGtlZXBhbGl2ZSBwcm9iZXMgYW5kIHplcm8gd2luZG93IHByb2Jlcy4gKE5vdGUgdGhhdCB0 aGUgY29tbWVudCBmb3INCnRjcF93cml0ZV93YWtldXAoKSBpcyAiSW5pdGlhdGUga2VlcGFsaXZl IG9yIHdpbmRvdyBwcm9iZSBmcm9tIHRpbWVyIikuIFNvLCBvbiB0aGUgd2lyZSBhbmQgZGl2b3Jj ZWQgZnJvbSBjb250ZXh0LCB0aGUgdHdvIGtpbmRzIG9mIHBhY2tldHMgY2FuIGxvb2sgdGhlIHNh bWUuDQoNCkdpdmVuIHRoZSBjb250ZXh0IGluIHlvdXIgdHJhY2UsIHdpdGggdGhlIHJlY2VpdmVy IGp1c3QgaGF2aW5nIGFkdmVydGlzZWQgYSByZWNlaXZlIHdpbmRvdyBvZiAwIGJ5dGVzLCBhbmQg d2l0aCB0aGUgcHJvYmVzIHN0YXJ0aW5nIGluIHRoZSByYW5nZSBvZiBhIHBsYXVzaWJsZSBSVE8s IGFuZCBleHBvbmVudGlhbGx5IGJhY2tpbmcgb2ZmLCB0aG9zZSBsb29rIGxpa2UgemVybyB3aW5k b3cgcHJvYmVzIHRvIG1lLg0KDQpiZXN0LA0KbmVhbA0KDQpwczogdGhpcyBpcyBhIGNvbmRlbnNl ZCB2ZXJzaW9uIG9mIHRoZSB0cmFjZSwgd2l0aCB0Y3BkdW1wIC10dHQgcmVsYXRpdmUgdGltZXN0 YW1wczoNCg0KMDA6MDA6MDAuMDI1MDk5IGNsaSA+IHNydjogUyAzODc4NzgxMDk5OjM4Nzg3ODEw OTkoMCkgd2luIDY1NTM1DQowMDowMDowMC4wMDA1MDYgc3J2ID4gY2xpOiBTLiA5MzY1NzE2NDE6 OTM2NTcxNjQxKDApIGFjayAzODc4NzgxMTAwIHdpbiAyOTIwMCA8bXNzIDE0NjA+DQowMDowMDow MC4wMTI0NzMgY2xpID4gc3J2OiAuIDM4Nzg3ODExMDA6Mzg3ODc4MTEwMCgwKSBhY2sgOTM2NTcx NjQyIHdpbiA2NTUzNQ0KMDA6MDA6MDEuMDAzMTczIHNydiA+IGNsaTogUC4gOTM2NTcxNjQyOjkz NjU3MTY0MygxKSBhY2sgMzg3ODc4MTEwMCB3aW4gMjkyMDANCjAwOjAwOjAwLjAxMzQwNyBjbGkg PiBzcnY6IC4gMzg3ODc4MTEwMDozODc4NzgxMTAwKDApIGFjayA5MzY1NzE2NDMgd2luIDANCjAw OjAwOjAxLjIwODI1MCBzcnYgPiBjbGk6IC4gOTM2NTcxNjQyOjkzNjU3MTY0MigwKSBhY2sgMzg3 ODc4MTEwMCB3aW4gMjkyMDANCjAwOjAwOjAwLjQzMTk5NSBzcnYgPiBjbGk6IC4gOTM2NTcxNjQy OjkzNjU3MTY0MigwKSBhY2sgMzg3ODc4MTEwMCB3aW4gMjkyMDANCjAwOjAwOjAwLjg4Nzk3MCBz cnYgPiBjbGk6IC4gOTM2NTcxNjQyOjkzNjU3MTY0MigwKSBhY2sgMzg3ODc4MTEwMCB3aW4gMjky MDANCjAwOjAwOjAxLjcyODAwMiBzcnYgPiBjbGk6IC4gOTM2NTcxNjQyOjkzNjU3MTY0MigwKSBh Y2sgMzg3ODc4MTEwMCB3aW4gMjkyMDANCg0KT24gV2VkLCBOb3YgMjEsIDIwMTggYXQgMToyMSBQ TSBWYXJhZGFyYWphbiwgS2lydXRoaWthIDxLaXJ1dGhpa2EuVmFyYWRhcmFqYW5AaGFybWFuLmNv bT4gd3JvdGU6DQo+DQo+IEhpIFRlYW0sDQo+DQo+IEkgaGF2ZSBhIHF1ZXN0aW9uIGluIFplcm8g V2luZG93IFByb2JlIGluIFRDUC4NCj4NCj4gSWYgdGhlIGNsaWVudCBzZW5kcyBaZXJvIFdpbmRv dywgYWNjb3JkaW5nIHRvIFJGQyBzcGVjIGlzIGl0IG1hbmRhdG9yeSBmb3IgdGhlIExpbnV4IFRD UCBzdGFjayB0byBzZW5kIFplcm8gV2luZG93IFByb2JlLg0KPg0KPiBJbiBteSBzdGFjayBJIGFt IG5vdCBnZXR0aW5nIFplcm8gV2luZG93IFByb2JlIGluc3RlYWQgSSBhbSBnZXR0aW5nIEtlZXAg QWxpdmUuDQo+DQo+IEkgaGF2ZSBhdHRhY2hlZCBteSB3aXJlc2hhcmsgdHJhY2VzLiBDYW4geW91 IHBsZWFzZSBjb25maXJtIGlmIHRoaXMgaXMgdGhlIGV4cGVjdGVkIGJlaGF2aW9yIGZyb20gVENQ IHN0YWNrLg0KPg0KPg0KPg0KPiBUaGFua3MgJiBSZWdhcmRzDQo+DQo+IEtpcnV0aGlrYQ0KPg0K Pg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiB0Y3BtIG1haWxpbmcgbGlzdA0KPiB0Y3BtQGlldGYub3JnDQo+IGh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS9hLzEvNXM5T2dwdUdBREc0LXdOYXlpS0NEYU9qcDR0OHhFZE56SW4NCj4g Mm0wZ0loYkk9P2Q9cXd1RzJsRDFIR3lUa1Q2SVROdjJULUlaVHNLRURRRUxIaE9LdU8zNVlrNkR3 QXFDdzFfbWFTdTl1Sg0KPiBpMFNKNU9vTDVoUlh4S2ZGTVZWZFBycEg3TnFab2lBMmlDNF9zVzlT NURTOGlYUGNGdHZlRmFSWlpGYWVabGpDREhjVmpsDQo+IHhHTHV4a3hRaUxrZklOWEtreXZFcWFT alNmZVZ0UnNUZlFoSTEzMkRJY1FLMG9CWlpEanpuUndvZEI4LTF6NUlZSmMxMTcNCj4gMEVLTjd2 VzZuSXM2VWc4eWJsbWdqbnFvaFc4d2otcUhJZTYwTVJQWkNUakNLdVg3NV9HQmRTZURxYkNscHlQ MlVhY3plZw0KPiBWX2lCSGNmWFoxNjlxMncteTR0dzVhVGI3azhHWkdoTDVHWG4wZlVvSkkwNFBv TDZPUmM4eTlrX1dJaWZFek8ybjNDajVvDQo+IDZXZ2xEWGpwQ1hZOGt1dE0wdVBrelVXM3dsbHZv M0EyZVVEZ2gyUGNDMjhGcEc4eTJESXFSZFd6bTNpVVplOElXWnNGLW4NCj4gZm1xSDgyQkxjM2d5 Q09rJTNEJnU9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l Mg0KPiBGdGNwbQ0K From nobody Fri Nov 23 10:51:42 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADEF12DD85 for ; Fri, 23 Nov 2018 10:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.96 X-Spam-Level: X-Spam-Status: No, score=-18.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arUHyAgMuBTy for ; Fri, 23 Nov 2018 10:51:39 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6031288EB for ; Fri, 23 Nov 2018 10:51:39 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id x202so10662580oif.13 for ; Fri, 23 Nov 2018 10:51:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RCOuvT6c6GRrYSaYOM7gNui/X/HodoRq8RrQ96RWYMw=; b=Mux3VO1H2Sf+Xfgjf+BzAKvFqHaxTUeJ/hvB9XLIkU+UyULwsHLyaTEjbwshkfpeYf xL3HHj62UPK0bt/Q1b/DqSYAqr80FiE937iJCCtkWYP6DQCpFCRR+Ph754/lYesIPUDW /HoAZWboy6D32Eo8TSBJt8ZpGSKvNeiameqP5iB1YIno5h3gi20JzpzjTRLTsJX0Iqgt A9Tv1DkrhZneX0jcq5fj3dboPxEz5iJgJV7wILx/4376HyGl5JcSE5Phh9TRlvOnxdNH HGY7Un/9pv5iwQZxPB5SRCifb0JDznj1BLA/t2/SmEUTE0eoMfLqb4uHZEknCbFXz5r9 rXsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RCOuvT6c6GRrYSaYOM7gNui/X/HodoRq8RrQ96RWYMw=; b=Y+dBD+XKFwFtEL6IRzOZ+BQQImYf05V5Fv28DTtScYsSfnE+VJSyByLP70k3VlMvWu 8X58i31GfytIfKA6iF2ulh/bd8Yv8G9D+kyYuoaKupi4HJU0rV5No4u9SFm5q35xMUMm fMD4yBGRr/bd9k0yqOvIH1mZP8sDdsKGWvZOraiue/vnyPL9K/xQZ/MMsFLzFDrSeKr0 7BeLn691NcCQ4ELPJtbWQpwMrmxmTIKYNWeMyZfb3YVICfWYK/KuitTHTm52XduT2Kc7 0W+rKKxHd22FY6SPvvdc2ygpn7CP1whIxsT+V3peem5GNg6pK26x9rYjrMQ/5yXbjlOl /1Kg== X-Gm-Message-State: AGRZ1gIMfYaX+Szlkk7x2lWfaKpwhX9WnNWt4ltaSmfs+jqGI5vaVJGS h0VCYqZQ8GfLskTMD26f7VW/D8Be7aK4HofxwawfyC+lSoRlLg== X-Google-Smtp-Source: AJdET5ecy6n5T5SucJVlFsOo5OkoQ7I5bJGvNUrUjhXIx3eeWQ0oecbQB0NkNFBNejEn8j1Wv4oOGfzollNJfHTkDAU= X-Received: by 2002:aca:c43:: with SMTP id i3mr9655775oiy.157.1542999098455; Fri, 23 Nov 2018 10:51:38 -0800 (PST) MIME-Version: 1.0 References: <246bdcf112bb4ebe875df662e3467ab5@HICGWSMB01.ad.harman.com> <1ad46d5108314dadbf913919f2907872@HICGWSMB01.ad.harman.com> In-Reply-To: <1ad46d5108314dadbf913919f2907872@HICGWSMB01.ad.harman.com> From: Neal Cardwell Date: Fri, 23 Nov 2018 13:51:21 -0500 Message-ID: To: Kiruthika.Varadarajan@harman.com Cc: "tcpm@ietf.org" , John Heffner Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] [EXTERNAL] Re: Linux TCP Stack and Zero Window Probe X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2018 18:51:41 -0000 On Fri, Nov 23, 2018 at 12:33 AM Varadarajan, Kiruthika wrote: > > Hi Neal, > But RFC spec https://tools.ietf.org/html/rfc793#section-3.7 says after TCP-Zero Window from client, server must send > TCP Zero Window Probe, >From the packet trace it seems like that is what happened. > Hence in tcp_write_wakeup, tcp_xmit_probe_skb expect mib to be LINUX_MIB_TCPWINPROBE Yes, indeed. Do you have snapshots of the SNMP counters from the machine before and after that trace, to show that the wrong counter was incremented? > Are we not violating the spec? The on-the-wire behavior of the server looks fine to me. However, if we are looking for spec violations, it looks like the client is violating the spec by retracting the right edge of the receive window (from "ack 936571642 win 65535" to "ack 936571643 win 0"). best, neal > > Thanks & Regards > Kiruthika > > > -----Original Message----- > From: Neal Cardwell > Sent: Thursday, November 22, 2018 11:52 PM > To: Varadarajan, Kiruthika > Cc: tcpm@ietf.org; John Heffner > Subject: [EXTERNAL] Re: [tcpm] Linux TCP Stack and Zero Window Probe > > Hi, > > This is expected. Linux TCP uses the same code to generate keepalive probes and zero window probes. (Note that the comment for > tcp_write_wakeup() is "Initiate keepalive or window probe from timer"). So, on the wire and divorced from context, the two kinds of packets can look the same. > > Given the context in your trace, with the receiver just having advertised a receive window of 0 bytes, and with the probes starting in the range of a plausible RTO, and exponentially backing off, those look like zero window probes to me. > > best, > neal > > ps: this is a condensed version of the trace, with tcpdump -ttt relative timestamps: > > 00:00:00.025099 cli > srv: S 3878781099:3878781099(0) win 65535 > 00:00:00.000506 srv > cli: S. 936571641:936571641(0) ack 3878781100 win 29200 > 00:00:00.012473 cli > srv: . 3878781100:3878781100(0) ack 936571642 win 65535 > 00:00:01.003173 srv > cli: P. 936571642:936571643(1) ack 3878781100 win 29200 > 00:00:00.013407 cli > srv: . 3878781100:3878781100(0) ack 936571643 win 0 > 00:00:01.208250 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200 > 00:00:00.431995 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200 > 00:00:00.887970 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200 > 00:00:01.728002 srv > cli: . 936571642:936571642(0) ack 3878781100 win 29200 > > On Wed, Nov 21, 2018 at 1:21 PM Varadarajan, Kiruthika wrote: > > > > Hi Team, > > > > I have a question in Zero Window Probe in TCP. > > > > If the client sends Zero Window, according to RFC spec is it mandatory for the Linux TCP stack to send Zero Window Probe. > > > > In my stack I am not getting Zero Window Probe instead I am getting Keep Alive. > > > > I have attached my wireshark traces. Can you please confirm if this is the expected behavior from TCP stack. > > > > > > > > Thanks & Regards > > > > Kiruthika > > > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://clicktime.symantec.com/a/1/5s9OgpuGADG4-wNayiKCDaOjp4t8xEdNzIn > > 2m0gIhbI=?d=qwuG2lD1HGyTkT6ITNv2T-IZTsKEDQELHhOKuO35Yk6DwAqCw1_maSu9uJ > > i0SJ5OoL5hRXxKfFMVVdPrpH7NqZoiA2iC4_sW9S5DS8iXPcFtveFaRZZFaeZljCDHcVjl > > xGLuxkxQiLkfINXKkyvEqaSjSfeVtRsTfQhI132DIcQK0oBZZDjznRwodB8-1z5IYJc117 > > 0EKN7vW6nIs6Ug8yblmgjnqohW8wj-qHIe60MRPZCTjCKuX75_GBdSeDqbClpyP2Uaczeg > > V_iBHcfXZ169q2w-y4tw5aTb7k8GZGhL5GXn0fUoJI04PoL6ORc8y9k_WIifEzO2n3Cj5o > > 6WglDXjpCXY8kutM0uPkzUW3wllvo3A2eUDgh2PcC28FpG8y2DIqRdWzm3iUZe8IWZsF-n > > fmqH82BLc3gyCOk%3D&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2 > > Ftcpm From nobody Wed Nov 28 07:28:08 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5307130FB8 for ; Wed, 28 Nov 2018 07:27:56 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-X_uRSF0UIv for ; Wed, 28 Nov 2018 07:27:55 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5AB130E12 for ; Wed, 28 Nov 2018 07:27:54 -0800 (PST) Received: from [10.68.35.97] ([217.70.211.18]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lmb2Z-1fsPgd26Ut-00aFEA; Wed, 28 Nov 2018 16:27:48 +0100 To: Neal Cardwell , Felix Weinrank Cc: "tcpm@ietf.org" References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> <632bc671-4294-5eb3-ff8a-8c7dd492beb1@fh-muenster.de> From: "Scheffenegger, Richard" Message-ID: <5f27394f-5f88-457d-5a2a-8ce4fcd80202@gmx.at> Date: Wed, 28 Nov 2018 16:27:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:kjSPXNQin6oaizVzBrWwoXFbgnveVPUZKnHBsQEoiA/tw4DcQpX iwMup3E0zdWetSurwviPcFWk2etQORes57Edm8U5/53+ZRArRu0DQmEKqKiBATP2u9YhZ2V zqTQ62fUu7atkKxkEjEeWN5ju5/qXCoDk7513kbXQEDvk9PHv05chYiPK2nDs2pJ7UH/RXG y7YO8NG8cKrbaAkRFuhDw== X-UI-Out-Filterresults: notjunk:1;V03:K0:kAEh6EDj2Z4=:au52IwEXaqcmOvQ5iJQjIk Qyj+FEYF1Sk6Z/Hr7nEiPkYi2hGT2d8Suu4Is3AN4660j7sxlZCMBic1BPeWzGH54Ed9Aciqz CohlF+qOQLaBQ/SA/mhtKIGt+6JbLZ84E+qGJiknPcupuc83KQ/WmCiVg+bov1KkFAXOheFyb zM7F8QKy8M3tVry+RNuTnZBlaILTJ5PBQWYEyZcezAwXF6N8nprMNHXm1X97MhYFjpO6ddOnS MnuJqkc8JswZIIBuj46fU7BjC0kb1SvN7PgQ5JCTxePvGnGCyPuskAI+2DYdjO1coh4Y3QEBf G6ExvIea8svSXOtn9O5qbC7PAPTPdzKHBRYHGJTc2PYqhNp73DPqDskR6LM70U1+WLmYNT0aW g5OyquOxHtb54tI9asUIpuU1trJBmQAZvIEc9oHCfpXGdEIoaJrngTcaYwLPpSa1B+ASxtexF YvA3EpP/rNRw2ynhVLpHCWg39545mEyu33sk1gBg/g+f3fCEXOKmKIrGWloquwUmexdkaugOW VKOj+jXnz0Waph10e6k1tZ9BxaFRXCufUT5jWsB1M40Y52Ck03b7hh5hXxqdkLg070+ZSC8nR Uu+M8JBuuO4YlFs0oQQ6QOZ3jrwdnatys1ZHYzaGGqYoQp1WNm4YDZNj8FOa5yNX7pcncp2vx pXSBq1oIRlZBdfrKR20MUEDdHfnn+ogjKzQbLXK+fKtspeSfpdCubaYRk2f4yjk21lC7XLQRi pL4C94fuU8IDF9M+39rmrAQJPIFXXEaeY3xgCHSJud0LF73cnYYo1Xoyi1Cp+sHmS5Or0eL5e PVCQ/DVwYXxp9PZ/VxQHJbyhTX0oR8xa5DBjtA9AvNonBeRvggc/bRiHOiLIG7VHl/foTIX6H dlfFK24rWuF8L38/g82thDvNx3uAc+jfEpsvNEtL+syXxWTRBSTDC0RhsQfmx0 Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 15:28:07 -0000 Hi Neal, Am 22.11.2018 um 17:16 schrieb Neal Cardwell: > On Thu, Nov 22, 2018 at 10:28 AM Felix Weinrank wrote: >> >> I don't completely understand the following check: >> >> If RACK.reordering_seen is FALSE: >> If in loss recovery: /* If in fast or timeout recovery */ >> RACK.reo_wnd = 0 >> Return >> Else if RACK.pkts_sacked >= RACK.dupthresh: >> RACK.reo_wnd = 0 >> return >> >> The Draft says: >> "RACK.pkts_sacked" returns the total number of packets selectively >> acknowledged in the SACK scoreboard. >> >> Whats the purpose of this check: RACK.pkts_sacked >= RACK.dupthresh > > This is the traditional TCP Fast Retransmit heuristic, described in > https://tools.ietf.org/html/rfc5681 in section 3.2, and > https://tools.ietf.org/html/rfc6675 in section 5, and the older > https://tools.ietf.org/html/rfc2001 in section 3. To be pedandic, only RFC3517 and RFC6675 would be applicable directly, as RACK requires SACK support. Also, RFC6675 explicitly shortened the trigger condition from receiving 3 DupACKs down to FACK > (dupthresh - 1)*SMSS. That is, RFC6675 allows entering Loss Recovery on the first ACK(SACK), without waiting for any duplicate ACKs at all... Thus it is much more "aggressive", and I've seen two independent examples recently, where Receivers exploit this capability (and don't work well against a RFC3517 sender). Earlier 3517 still needed 3 duplicate ACKs. In that context, RACK takes a middle ground, as the receiver has to have seen dupthresh data segments, but the sender can enter loss recovery already, even when ACK loss, ACK compression or ACK thinning are prevalent in the return path. (A single ACK, with an appropriate SACK block(s) is still sufficient to enter LR with RACK, but unlike 6675, positive proof that 3 packets got delivered is required). Which is a Good Thing (TM) :) > > One way to think about it would be: if a receiver selectively > acknowledges a data sequence range, then that means there is an > unacknowledged "hole" in the sequence space below the selectively > acknowledged range. There are two main possibilities for this hole: > (1) That unacknowledged hole will stay unacknowledged indefinitely, > suggesting that the original packets containing that data were > permanently lost, and need to be retransmitted (which this algorithm > triggers). (2) That unacknowledged hole will be acknowledged later, > which would suggest that the network reordered the data somewhere in > transit, delaying the earlier data and causing it to arrive after the > later data. Waiting for three data segments to be selectively > acknowledged allows extra "settling" time for that reordered packet to > make it to the receiver and fill that hole; this implicit settling > delay helps avoid spurious retransmits in cases where the network has > started to reorder packets but the sender has not had a chance to > observe the reordering yet. For cases where the sender has observed > reordering (RACK.reord is true) then the sender maintains (in > RACK.reo_wnd) an explicit estimate of how long (in time) it should > wait for such reordering to settle, before triggering a fast > retransmit. > From nobody Wed Nov 28 07:57:21 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97B5E130EB8 for ; Wed, 28 Nov 2018 07:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTBMKoQzHm-M for ; Wed, 28 Nov 2018 07:57:07 -0800 (PST) Received: from smtp-rs2-vallila1.fe.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856EA128CF3 for ; Wed, 28 Nov 2018 07:57:06 -0800 (PST) Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) by smtp-rs2.it.helsinki.fi (8.14.7/8.14.7) with ESMTP id wASFuihV026582; Wed, 28 Nov 2018 17:56:46 +0200 Received: by whs-18.cs.helsinki.fi (Postfix, from userid 1070048) id C52FD360362; Wed, 28 Nov 2018 17:56:44 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by whs-18.cs.helsinki.fi (Postfix) with ESMTP id C3B54360013; Wed, 28 Nov 2018 17:56:44 +0200 (EET) Date: Wed, 28 Nov 2018 17:56:44 +0200 (EET) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: Richard Scheffenegger cc: Neal Cardwell , Felix Weinrank , "tcpm@ietf.org" In-Reply-To: <5f27394f-5f88-457d-5a2a-8ce4fcd80202@gmx.at> Message-ID: References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> <632bc671-4294-5eb3-ff8a-8c7dd492beb1@fh-muenster.de> <5f27394f-5f88-457d-5a2a-8ce4fcd80202@gmx.at> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 15:57:10 -0000 On Wed, 28 Nov 2018, Richard Scheffenegger wrote: > Am 22.11.2018 um 17:16 schrieb Neal Cardwell: > > On Thu, Nov 22, 2018 at 10:28 AM Felix Weinrank > > wrote: > > > > > > I don't completely understand the following check: > > > > > > If RACK.reordering_seen is FALSE: > > > If in loss recovery: /* If in fast or timeout recovery */ > > > RACK.reo_wnd = 0 > > > Return > > > Else if RACK.pkts_sacked >= RACK.dupthresh: > > > RACK.reo_wnd = 0 > > > return > > > > > > The Draft says: > > > "RACK.pkts_sacked" returns the total number of packets selectively > > > acknowledged in the SACK scoreboard. > > > > > > Whats the purpose of this check: RACK.pkts_sacked >= RACK.dupthresh > > > > This is the traditional TCP Fast Retransmit heuristic, described in > > https://tools.ietf.org/html/rfc5681 in section 3.2, and > > https://tools.ietf.org/html/rfc6675 in section 5, and the older > > https://tools.ietf.org/html/rfc2001 in section 3. > > To be pedandic, only RFC3517 and RFC6675 would be applicable directly, as RACK > requires SACK support. > > Also, RFC6675 explicitly shortened the trigger condition from receiving 3 > DupACKs down to FACK > (dupthresh - 1)*SMSS. Where does that "FACK" part come from? Not from RFC6675 for sure. The condition given in RFC6675 requires at least that many bytes to be acknowledged by SACK blocks to trigger recovery, not just sequence distance like FACK does. > That is, RFC6675 allows > entering Loss Recovery on the first ACK(SACK), without waiting for any > duplicate ACKs at all... Thus it is much more "aggressive", and I've seen two > independent examples recently, where Receivers exploit this capability (and > don't work well against a RFC3517 sender). > > Earlier 3517 still needed 3 duplicate ACKs. > > In that context, RACK takes a middle ground, as the receiver has to have seen > dupthresh data segments, but the sender can enter loss recovery already, even > when ACK loss, ACK compression or ACK thinning are prevalent in the return > path. > > (A single ACK, with an appropriate SACK block(s) is still sufficient to enter > LR with RACK, but unlike 6675, positive proof that 3 packets got delivered is > required). > > Which is a Good Thing (TM) :) RFC6675 algorithm requires a positive proof that at least 3 MSS sized packets were delirered. The algorithm just doesn't use dup ACK as a proxy for that but bases the decision on scoreboard details only. Maybe you're misreading the RFC6675 somehow? -- i. From nobody Wed Nov 28 08:10:24 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02046130E93 for ; Wed, 28 Nov 2018 08:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.959 X-Spam-Level: X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_CcwRdeGTKU for ; Wed, 28 Nov 2018 08:10:20 -0800 (PST) Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B4E1293FB for ; Wed, 28 Nov 2018 08:10:20 -0800 (PST) Received: by mail-it1-x12d.google.com with SMTP id o19so5153329itg.5 for ; Wed, 28 Nov 2018 08:10:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9NR1CALNQuVhuKsUv9glje9O7VTKcixKBMeZvJ28fQg=; b=cm6a14BHB8TScRRGfmRCVx9654bbYhaFWLEGcjSrQkf2bH7dDaj/33flD+MUmBml7a /yeFwxmBBEiB/UNMNlrIHzuvtnAlLGiYuoQ7haeBUP/6yvvJg65FeyYAFLVFs7F/RM6E 2xUuyFBoh0Cs9SvL3ANnt9C5fonbJg8ST89VRAbl4PwdXXBUJ8/M41Z/uqz/b1hwv/kV 3p/s2RKc/toMxH3A5TxeSRSy/pV9pI7J9Y9rRAiluzPkdnjwkIPp0YxZTxoG4eZ/oraS xUM0uXw6pRgYBHAqYN2PJC/O3zyf2o72K+akvgDedXkMnQWjgD0wPobLA3Yc1EmV3r/0 FAiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9NR1CALNQuVhuKsUv9glje9O7VTKcixKBMeZvJ28fQg=; b=tQQXWsnsTsJKZHaspStWuMXb6RL3VFpEzQZKfLuJP+4G2XYUdjjAG8rTv3b4f30zWl tAvgPdl+NXZIavEPIST+T1XBLk2uWO8zZChuOzUjOhxkomc1p26zTp6BUo9iYZXgiugJ Vid8mAFzXS346X8ormURkVNQWQCg+UwKAXQ0NZhY1XDsDXwNtvh93s7+UESzACcd7nua zcL3DkTzjOPRXuEEOA/ex3AGeDwPA7JKXYMs3W/XX6m2ieoQgcePJvdppFFRuCmY4O3J VmUUU3oI+ElwVGULwzPYgjATGa9ZmKMODaeKuK1Z8X1w4XKF2qqRswphDIfUk0H7eahE NSdw== X-Gm-Message-State: AA+aEWaW1Y6VSvws0motZhXgtWjYt3jySvnEGcyIh7A9051hw1RXuvzF SpdcfzLnQsqSUJRTVCu//kUN8/MXhBcUztJXECd7KA== X-Google-Smtp-Source: AFSGD/Us1kD3N+1ImFdO0r6jhdnnt69TlEAjYHShh7BM4UQZNDjTG1YZR+G9MB2UnwAxULSfeCymJOaXTdOMw3xLiMg= X-Received: by 2002:a24:94c9:: with SMTP id j192mr768352ite.125.1543421419668; Wed, 28 Nov 2018 08:10:19 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a6b:fe0c:0:0:0:0:0 with HTTP; Wed, 28 Nov 2018 08:09:38 -0800 (PST) In-Reply-To: References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> <632bc671-4294-5eb3-ff8a-8c7dd492beb1@fh-muenster.de> <5f27394f-5f88-457d-5a2a-8ce4fcd80202@gmx.at> From: Yuchung Cheng Date: Wed, 28 Nov 2018 08:09:38 -0800 Message-ID: To: =?UTF-8?Q?Ilpo_J=C3=A4rvinen?= Cc: Richard Scheffenegger , Neal Cardwell , "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2018 16:10:23 -0000 On Wed, Nov 28, 2018 at 7:56 AM, Ilpo J=C3=A4rvinen wrote: > On Wed, 28 Nov 2018, Richard Scheffenegger wrote: >> Am 22.11.2018 um 17:16 schrieb Neal Cardwell: >> > On Thu, Nov 22, 2018 at 10:28 AM Felix Weinrank >> > wrote: >> > > >> > > I don't completely understand the following check: >> > > >> > > If RACK.reordering_seen is FALSE: >> > > If in loss recovery: /* If in fast or timeout recovery= */ >> > > RACK.reo_wnd =3D 0 >> > > Return >> > > Else if RACK.pkts_sacked >=3D RACK.dupthresh: >> > > RACK.reo_wnd =3D 0 >> > > return >> > > >> > > The Draft says: >> > > "RACK.pkts_sacked" returns the total number of packets selectively >> > > acknowledged in the SACK scoreboard. >> > > >> > > Whats the purpose of this check: RACK.pkts_sacked >=3D RACK.dupthres= h >> > >> > This is the traditional TCP Fast Retransmit heuristic, described in >> > https://tools.ietf.org/html/rfc5681 in section 3.2, and >> > https://tools.ietf.org/html/rfc6675 in section 5, and the older >> > https://tools.ietf.org/html/rfc2001 in section 3. >> >> To be pedandic, only RFC3517 and RFC6675 would be applicable directly, a= s RACK >> requires SACK support. >> >> Also, RFC6675 explicitly shortened the trigger condition from receiving = 3 >> DupACKs down to FACK > (dupthresh - 1)*SMSS. > > Where does that "FACK" part come from? Not from RFC6675 for sure. The > condition given in RFC6675 requires at least that many bytes to be > acknowledged by SACK blocks to trigger recovery, not just sequence > distance like FACK does. > >> That is, RFC6675 allows >> entering Loss Recovery on the first ACK(SACK), without waiting for any >> duplicate ACKs at all... Thus it is much more "aggressive", and I've see= n two >> independent examples recently, where Receivers exploit this capability (= and >> don't work well against a RFC3517 sender). >> >> Earlier 3517 still needed 3 duplicate ACKs. >> >> In that context, RACK takes a middle ground, as the receiver has to have= seen >> dupthresh data segments, but the sender can enter loss recovery already,= even >> when ACK loss, ACK compression or ACK thinning are prevalent in the retu= rn >> path. >> >> (A single ACK, with an appropriate SACK block(s) is still sufficient to = enter >> LR with RACK, but unlike 6675, positive proof that 3 packets got deliver= ed is >> required). >> >> Which is a Good Thing (TM) :) > > RFC6675 algorithm requires a positive proof that at least 3 MSS sized > packets were delirered. The algorithm just doesn't use dup ACK as a proxy > for that but bases the decision on scoreboard details only. Maybe you're > misreading the RFC6675 somehow? This is to echo Ilpo's question that RFC6675 requires 3 OOO pkts to trigger= . > > -- > i. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm