From pasi.sarolahti@iki.fi Sun Sep 2 23:53:59 2012 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 8386D21F8464 for ; Sun, 2 Sep 2012 23:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mTTi5pzyffI for ; Sun, 2 Sep 2012 23:53:58 -0700 (PDT) Received: from kirsi2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEA121F84A6 for ; Sun, 2 Sep 2012 23:53:58 -0700 (PDT) Received: from [192.168.10.134] (192.76.146.51) by kirsi2.inet.fi (8.5.140.03) (authenticated as saropa-1) id 502AD3600021A17C; Mon, 3 Sep 2012 09:53:57 +0300 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Pasi Sarolahti In-Reply-To: Date: Mon, 3 Sep 2012 08:54:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <59C900CC-E746-4F54-AF2E-12B12D940D3B@iki.fi> <20120827144313.6624729F0A77@lawyers.icir.org> To: tcpm@ietf.org X-Mailer: Apple Mail (2.1278) Cc: Matt Mathis Subject: Re: [tcpm] WGLC for Proportional Rate Reduction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2012 06:53:59 -0000 Hi, We need to move forward with the Proportional Rate Reduction draft. = There have been a couple of comments supporting its publication as = Proposed Standard rather than Experimental, but on the hand, Matt made = some points for keeping with the current status. Therefore, after = discussing with my co-chairs, we think the most appropriate path is to = continue as planned, and proceed towards publishing the document as = Experimental. There were also some other comments made in response to the WGLC, so the = authors should do a revision based on those before we request = publication of the draft. Thanks for your input! - Pasi On Aug 27, 2012, at 9:16 PM, Matt Mathis wrote: > Sorry for the long radio silence here. >=20 > The only reason to bother with standards track is if there is a need > to compel reluctant manufacturers to implement and deploy it. > Customers can then write in their requests for quotes specifications > such as "must support SACK (RFC 2018), and then suddenly the lack of > SACK support becomes a high priority issue for some large manufacture > who shall remain nameless. >=20 > Back in the old days (before 1990) RFC meant "request for comments" > and there was no such concept as "standards track". We wrote down our > ideas, and if they were valuable, they became part of the installed > base. For PRR this has already come to pass for the installed base > that is most important to me. >=20 > If management at Apple or Microsoft think PRR isn't worth the effort, > then making PRR a standard will permit their customers to influence > their priorities. Given the extent to which PRR is an across the > board win, I really don't think this is required. (However, I could > change my mind if a TCP engineer at one of the above companies > indicate that they are getting pushback from their management.) >=20 > Finally there are some details in PRR that are effected by Laminar. I > would rather not go to the effort of fixing the current draft to make > it a proper normative PS, but not totally correct. (Hint: Yoshifumi > Nishida's "off by one" comment reflects the difference between pipe > and total_pipe). >=20 > So here is what I was planning to do: Push out the current document > as experimental, and then after Laminar is further along, generate a > normative respecification using Laminar state variables (probably as > one section of a larger doc, but that remains TBD). >=20 > Does that make sense? >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 >=20 > On Mon, Aug 27, 2012 at 7:43 AM, Mark Allman wrote: >>=20 >>> I wonder about the process issues related to changing the status at >>> this point. >>=20 >> The process is that y'all say someone has suggested the status should = be >> standards track and you want to know what the WG thinks of that. = This >> document has not left the WG. I have not seen any declaration that = it >> passed WGLC. It is within this WG's purview to consider this = question. >>=20 >> allman >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 From monia.gh@gmail.com Mon Sep 3 16:50:34 2012 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 073A821F8639 for ; Mon, 3 Sep 2012 16:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzIGeAY9+el9 for ; Mon, 3 Sep 2012 16:50:33 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27E8621F8634 for ; Mon, 3 Sep 2012 16:50:33 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6769988vbb.31 for ; Mon, 03 Sep 2012 16:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=ZXTl6y2wkSJ3ZE0xh37dxy5LFdzUOV3GdYRthqYQRc4=; b=bE4egZsjns6XchotREajbgXf/RrRsrwoR8K4HyJG9PtKax114Uik1w4VnvAo3Ahntt /Hu/RV3UNOnt3xfnFQwpgAHC+MmGbllizBZ1B+la8cfwo2K9+djbKXF4FoH8Icmdw6IM tuaHVbR4Vsddn6Za5Qv6bR1EbpWhYwz/EVDvh3EGCCFnD3Xh/oPSykD9RLcJaEcD6vpk vzV/5MwkjpEtmyX7hwW9bAPVR9zH8/n6QsTGlNyaOn18szLEwgUern76TY2zdH3yWI/V g6hsYLN8vMgPO1d1D/FmN1Hz1Ivt5UnpQW828+CbIk3synRGdxkN0X5Z9TPVudll9o8Q dLPQ== Received: by 10.58.221.66 with SMTP id qc2mr14261296vec.30.1346716232377; Mon, 03 Sep 2012 16:50:32 -0700 (PDT) MIME-Version: 1.0 Sender: monia.gh@gmail.com Received: by 10.58.239.41 with HTTP; Mon, 3 Sep 2012 16:50:12 -0700 (PDT) From: Monia Ghobadi Date: Mon, 3 Sep 2012 19:50:12 -0400 X-Google-Sender-Auth: Hkm8XbTOVil4Gn9LCVDncdhUTDU Message-ID: To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=047d7bf162e4a4e41904c8d4ceb1 Subject: [tcpm] Traffic Burstiness Survey X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2012 23:52:09 -0000 --047d7bf162e4a4e41904c8d4ceb1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear TCPM members, I am a PhD student at University of Toronto and I am working on traffic burstiness in data centers. In the following I am asking two questions to raise motivation for my research. I appreciate if anyone could answer these questions to their best knowledge. *The questions are:* 1) =91Bursty=92 is a word with no agreed meaning. How do you define a burst= y traffic? 2) If you are involved with a data center, is your data center traffic bursty? -- If yes, -- Do you think that it will be useful to supress the burstiness in your traffic? (For example by pacing the traffic into shorter bursts) -- If no: -- Are you already supressing the burstiness? How? -- Would you anticipate the traffic becoming burstier in the future? Thanks, Monia ------------------ Monia Ghobadi PhD Student University of Toronto http://www.cs.utoronto.ca/~monia/ --047d7bf162e4a4e41904c8d4ceb1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear TCPM members,

I am a PhD student at University of Toronto and I am working on traf= fic burstiness in data centers. In the following I am asking two questions = to raise motivation for my research. I appreciate if anyone could answer th= ese questions to their best knowledge. The questions are:

1) =91Bursty=92 is a word = with no agreed meaning. How do you define a bursty traffic?
2) If you are involved with a data center, is your data center traffic = bursty?
=A0=A0=A0-- If yes,
=A0=A0=A0=A0=A0=A0=A0=A0-- Do you think that it will be useful to supr= ess the burstiness in your traffic? (For example by pacing the traffic into shor= ter bursts)
=A0=A0=A0-- If no:
=A0=A0=A0=A0=A0=A0=A0=A0-- Are you a= lready supressing the burstiness? How?
=A0=A0=A0=A0=A0=A0=A0=A0-- Would you anticipate the traffic becoming b= urstier in the future?

Thanks,
Monia

------------------
Monia Ghobadi
PhD Studen= t
University of Toronto
http://www.cs.ut= oronto.ca/~monia/
--047d7bf162e4a4e41904c8d4ceb1-- From mattmathis@google.com Mon Sep 3 20:41:26 2012 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 96C3C21F8625 for ; Mon, 3 Sep 2012 20:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.563 X-Spam-Level: X-Spam-Status: No, score=-100.563 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0SerdktRuHb for ; Mon, 3 Sep 2012 20:41:26 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9313121F8499 for ; Mon, 3 Sep 2012 20:41:22 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3098823wgb.13 for ; Mon, 03 Sep 2012 20:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=TWmq4eWyIRDvO0/jPcqAoNO7W6iYNqffM5ZPaFMDG/0=; b=Cq4SlMcE4yg5F3ikiewI/mgHUT95Wmnm+nBwmAnNed8b/C8pyuZFALsXR/OP+DGABc 8JKsBA6t6kxA2/KBV37eYY+axBFq8C+jDlECq/e7SgoJRHUivVCFlCxGSAuJp+B5+Lpj Ud3XjD1mKTJ4Ggol8XpeguW6XYF+GWTThW3WnmmeoMD9v2nu3PKdoSCwYSe6yeuF0EEx 1TAE5KVk+RQ5Mw80V4FMaO359T/MSf87wMNAFKJSgteMAAojUf4kk5Nnrmj0CyFAqod7 jnoSUdruU4GQephynoJeeOWpxE7f4AxWIV5au4FwvokJsQvPUnEZzCdOd7avpROgTNl7 jA+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=TWmq4eWyIRDvO0/jPcqAoNO7W6iYNqffM5ZPaFMDG/0=; b=nLa1S0+SqPM7tqkr9QZSXbB84BQw9TWEpRpgXEVAhcG3TzeUPdW7eedcQR4KgVoyB/ 3/wQSWwhKydLg9f56WNcy3p/txupoW7ijNIP7a05ry3GtrBk0UrjYkyJBwrAlrHUJhsr Kh6j3o5CH4DPMeBnFSFfDc9evkdVpqaafoyJ5YNqb+W9B4n/AyXLAOYWa0uar9DZcinm PBnhLNrKz5QZ28cCRQvqyrTxQUH0H0noItf4Nvf/vmEGu/ZPSOR4AzUsPqRQLNbIH5Ed OjSP1FixIyh8yiuvwKE2NlS0/VEEod0PrQrhOelpQH/o6xUliIxE63LRMZVbZ0iGLSNj 9AiA== Received: by 10.180.91.132 with SMTP id ce4mr27589525wib.17.1346730081682; Mon, 03 Sep 2012 20:41:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.91.132 with SMTP id ce4mr27589509wib.17.1346730081453; Mon, 03 Sep 2012 20:41:21 -0700 (PDT) Received: by 10.217.0.9 with HTTP; Mon, 3 Sep 2012 20:41:21 -0700 (PDT) In-Reply-To: References: <59C900CC-E746-4F54-AF2E-12B12D940D3B@iki.fi> <20120827144313.6624729F0A77@lawyers.icir.org> Date: Mon, 3 Sep 2012 20:41:21 -0700 Message-ID: From: Matt Mathis To: Pasi Sarolahti Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkbwBqobh1FjUmxANEuJP20wI3b7iOHlW+u9qucjfF8q8ABio5PSQruZ1HNRO2qvVz/YSkNdVDLOtBfoMHqhYSP1XVxgDJh6QCpl8yWTKuazfnzM2pVqR1DPE84okYdqoM3xqEZZFkKhLP9Kr1Z/IDB5Ku6bEoUbZml1FnTqV4FXqPHxhQaWFT8uY8ynvubeMJrO9XO Cc: tcpm@ietf.org Subject: Re: [tcpm] WGLC for Proportional Rate Reduction X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2012 03:41:26 -0000 Thanks! I will make the requested revisions. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Sun, Sep 2, 2012 at 11:54 PM, Pasi Sarolahti wro= te: > Hi, > > We need to move forward with the Proportional Rate Reduction draft. There= have been a couple of comments supporting its publication as Proposed Stan= dard rather than Experimental, but on the hand, Matt made some points for k= eeping with the current status. Therefore, after discussing with my co-chai= rs, we think the most appropriate path is to continue as planned, and proce= ed towards publishing the document as Experimental. > > There were also some other comments made in response to the WGLC, so the = authors should do a revision based on those before we request publication o= f the draft. > > Thanks for your input! > > - Pasi > > > On Aug 27, 2012, at 9:16 PM, Matt Mathis wrote: > >> Sorry for the long radio silence here. >> >> The only reason to bother with standards track is if there is a need >> to compel reluctant manufacturers to implement and deploy it. >> Customers can then write in their requests for quotes specifications >> such as "must support SACK (RFC 2018), and then suddenly the lack of >> SACK support becomes a high priority issue for some large manufacture >> who shall remain nameless. >> >> Back in the old days (before 1990) RFC meant "request for comments" >> and there was no such concept as "standards track". We wrote down our >> ideas, and if they were valuable, they became part of the installed >> base. For PRR this has already come to pass for the installed base >> that is most important to me. >> >> If management at Apple or Microsoft think PRR isn't worth the effort, >> then making PRR a standard will permit their customers to influence >> their priorities. Given the extent to which PRR is an across the >> board win, I really don't think this is required. (However, I could >> change my mind if a TCP engineer at one of the above companies >> indicate that they are getting pushback from their management.) >> >> Finally there are some details in PRR that are effected by Laminar. I >> would rather not go to the effort of fixing the current draft to make >> it a proper normative PS, but not totally correct. (Hint: Yoshifumi >> Nishida's "off by one" comment reflects the difference between pipe >> and total_pipe). >> >> So here is what I was planning to do: Push out the current document >> as experimental, and then after Laminar is further along, generate a >> normative respecification using Laminar state variables (probably as >> one section of a larger doc, but that remains TBD). >> >> Does that make sense? >> >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >> >> >> On Mon, Aug 27, 2012 at 7:43 AM, Mark Allman wrote: >>> >>>> I wonder about the process issues related to changing the status at >>>> this point. >>> >>> The process is that y'all say someone has suggested the status should b= e >>> standards track and you want to know what the WG thinks of that. This >>> document has not left the WG. I have not seen any declaration that it >>> passed WGLC. It is within this WG's purview to consider this question. >>> >>> allman >>> >>> >>> >>> >>> _______________________________________________ >>> tcpm mailing list >>> tcpm@ietf.org >>> https://www.ietf.org/mailman/listinfo/tcpm >>> > From nanditad@google.com Wed Sep 5 13:01:39 2012 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 78D6621F86D1 for ; Wed, 5 Sep 2012 13:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADZnwXxudc6l for ; Wed, 5 Sep 2012 13:01:38 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4D6521F86BA for ; Wed, 5 Sep 2012 13:01:38 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1100122obb.31 for ; Wed, 05 Sep 2012 13:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=JmvV1Ere1PPwQk97bAc3tfdt0YNlIaFOemNHIoQTHt4=; b=Ba/Gvcul+cM7vBiqr6T9x9RfP18jeDJq/BvG84EFRiGD7SRA2rzRqEqltkwoGwQiF2 TcsS3daEkzyX9RrWlrXEIW8xQXknp3hnsXjSDK9pU4PjYZYLk77a7gJQiyB5/ID18lpO AKxe0dnGS8VcxYIIKr7eY51tZ7n6QtNjz2qt2pHoxf400egPYpllMqyQho+M4ilYBGGE XCX0Ha9b4JP8uln+wXiERAKMelx7IudSxn+HPjfA8jeiMmoloUuJGYTzhzC3s3vjENkU 13zdQ0VAImDAjI9c8SkA8ZyNpAC6RsN4/uKUErosykUSrkh3IRIu06lz7NdhRh74ZTAd fMoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=JmvV1Ere1PPwQk97bAc3tfdt0YNlIaFOemNHIoQTHt4=; b=j5w89dUsHbMv0wgsmr0lT1oihjokUBKhl6hLAS6Ay4vPY/me+bqVroEaEpLiPzvkzF tN/754Ils8Dfg1j2b4vt4ef+4xFf/pvb8Vi6NZVNTP91De2m85cUiPlPGiTQMx7tmppZ MmBrpLa4duux38Lg07OkCQs/xSauMlaSKt7REc5IpDrYjmpRRQzMpsz94vdgo3WSc7I7 6lXOtlhf3XQtLNkobOi1F3Xj6ZdLDpD3UtxadQB/P3l1CmK1LjNIfyoBtSM9xs9OnrDg 53F5gyzg1gdTWFHkO7dloj8Ajym7dbYlWdfjqt4dMxMUyiER+sRjNOCKnIZosrVGork8 f3wQ== Received: by 10.60.7.99 with SMTP id i3mr17981426oea.86.1346875298296; Wed, 05 Sep 2012 13:01:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.7.99 with SMTP id i3mr17981417oea.86.1346875298133; Wed, 05 Sep 2012 13:01:38 -0700 (PDT) Received: by 10.182.52.7 with HTTP; Wed, 5 Sep 2012 13:01:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Sep 2012 13:01:38 -0700 Message-ID: From: Nandita Dukkipati To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkULWVExwBb8YzdEX8CxniYcwAk/zPJdXxDwKwJo2Zz2RWM67lyNLBBhotgxQOESrKi/XulxOf81jo4Xj3rEMLt7R/8fYgPA6U29yOkY2xUJnROsRyGIi6zZCGwxL+RWta2WgQfxdL+Ztac6oeaT4jJxY/5dAk5it0adUdUmLecY4cgq4fwDv55HqHe+p1QPPcqzSbY Cc: tcpm@ietf.org, Matt Mathis Subject: Re: [tcpm] Question and comments about draft-dukkipati-tcpm-tcp-loss-probe X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 05 Sep 2012 20:01:39 -0000 Michael, Apologies for the delay. These are good comments, here are some answers - On Wed, Aug 29, 2012 at 7:21 AM, Michael Welzl wrote: > Hi, > > In an effort to address the CPM chairs' suggestion to clarify how draft-h= urtig-tcpm-rtorestart related to draft-dukkipati-tcpm-tcp-loss-probe, I fin= ally got around to reading the loss-probe draft - and I'm missing a key bit= of information that would help me make the distinction (and would probably= be good to include in your draft anyway - and: sorry if I missed it! but I= think it's really not there): what is the rationale for your choice of "2 = * SRTT" in the calculation of the probe timeout (PTO)? I mean, why not 3*RT= T, 1.5*RTT, whatever? If this is just the result of measurements, it would = be good to report that where you report the others. The probe timeout or PTO value was not out of measurements but in fact picked in the design/coding stage and we just stuck with it. The reason for 2.RTT is approximately as follows: the sender should wait long enough to know that an ACK is overdue. Under normal circumstances, i.e. no losses, this would typically be one RTT. But choosing PTO to be exactly an RTT is likely to generate spurious probes given that even end-system timings can easily push an ACK to be above an RTT. And hence I just chose it to be the next integral value of RTT. > > On a side note, I also think that it would be helpful for the reader to k= now how you obtained the first results that you present, regarding the larg= e difference between RTO and RTT, in the introduction (par. starting with "= To get a sense...". I assume that this is the effect of a queue growing on = a short flow, giving a large variance in the RTO calculation, but if that's= what it is it would be good to say so. This is a great question. The RTO and RTT values were measured by just instrumenting the kernel. So right now it's just reporting the measured values. I don't have a good answer on why the variance is large - possibly queuing, or variance in mobile channels. Open question. > > I also noticed an inconsistency: your draft is called "TCP Loss Probe", w= hereas the slides at http://www.ietf.org/proceedings/84/slides/slides-84-tc= pm-14.pdf > call it "Tail Loss Probe". Personally I prefer the latter term. Good catch :) Changed my mind between the draft and presentation date. We'll go with Tail loss probe. > > Finally, I think that this draft raises the obvious question: if it's ben= eficial to send an extra packet, why not 2, just to be safe? Or 3? Or ... = =3D> surely there is a point of where things get unacceptable. It would be= nice to see this trade-off quantified and evaluated, leading to a conclusi= on that explains why 1 probe packet is a good choice (or maybe even leading= to a different number?). In fact TLP v1 had no limit on number of probes sent prior to hitting the RTO limit. And then an experiment showed sending just one probe suffices to get most (~90%) of latency benefits. Hence our current implementation limits to one probe; the draft allows up to two consecutive probes. Agree that it's worthwhile documenting the tradeoff. Thanks for your read; will incorporate these in the next revision. Nandita > > Cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From ycheng@google.com Thu Sep 6 11:42:59 2012 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 4AAC221F86A3 for ; Thu, 6 Sep 2012 11:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+vUIyOzybwI for ; Thu, 6 Sep 2012 11:42:58 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B917621F867C for ; Thu, 6 Sep 2012 11:42:58 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3412818obb.31 for ; Thu, 06 Sep 2012 11:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=wScxFOsEJcqVQfabc5fnrj6ZTGjmIlimW8i4uwWQN3Q=; b=UvzgiC7Rc0i6kIBC3BmgaZEFizxplRH96WyrnEvn41adkXEpFFe5YuBtudCxGVRbNp q/W7M7exf3gcWQfQivhLOsOcTrh+2U/oIiAz8InpZsEvabA2kywN3NeNi/hbxl5aLg8K WBwBCUg9cSgBHfMUKy+buSyo4sry1smr2Qz+op18z1K0Xi7fbWmFXzEbVqmzxzEpmjNN AERzfgnlmD13lmkAh7dPe7Gxfa/gC3dkd9YFw/zfZVSV5FUcjkrNOT1IiDKcl1cjrN6q pRVshmIsYrC8VZbSxMrn0SsFF3DjITvtJOVel/1v3Yy4VeKdy3JaK+juu1t+m/VgQFPe NVNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=wScxFOsEJcqVQfabc5fnrj6ZTGjmIlimW8i4uwWQN3Q=; b=H50uZxBJn4VjrpmfVJz5pcw0XprmQP5KVzOtb3lQI4e7/eyPvykIHrpd9rPll+9uUi +9FqYcpS1tnfh08KKZS//uAPRB3KgUhoeaAfYplbR34/KRTydCiyPKaR4Mb+GdLystHW by6jKrVyERbMh6zvAhwQmVLtGgh5ijQMrJRl9OqTK7iwC9MkKvMkvR6P8p5q9kxfj+4O gpT+ZBxuXCPXGkGpEYGQiZGa0ZKgBiEAMqL/aL0fKZBtMO+jsVLcgGQ+t9x+VSeqBaZY ivh4JlolPBis1W3CqDV+oiqQIUxaECjuUpROjnivX6VEJUZuwRU0EIIPmIYlquAS5pGa hrGA== Received: by 10.182.118.2 with SMTP id ki2mr3372473obb.101.1346956978167; Thu, 06 Sep 2012 11:42:58 -0700 (PDT) Received: by 10.182.118.2 with SMTP id ki2mr3372465obb.101.1346956978090; Thu, 06 Sep 2012 11:42:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.22.169 with HTTP; Thu, 6 Sep 2012 11:42:37 -0700 (PDT) From: Yuchung Cheng Date: Thu, 6 Sep 2012 11:42:37 -0700 Message-ID: To: "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnYq935gDTxJD4qoxdObjfBlytpUTW1T9/2Y+vhWiCtb9TLPCH4XYUUcQDxxfmJoo/WIpRilYU34yMgj8VO4nOf33zuVgJnyQaS87q2Kz0lMde8sfpV7Sy+kw06G7t4Sy+LsE1HL6ksmlZuovUzDhOFk7WOpYlHwuZ1z+Ei017kFOQLFuhF/+ONFQDpcsLia244PlcA Subject: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 18:42:59 -0000 RFC 5681 specifically calls to use FlightSize instead of cwnd for cwnd reduction. """When a TCP sender detects segment loss using the retransmission timer and the given segment has not yet been resent by way of the retransmission timer, the value of ssthresh MUST be set to no more than the value given in equation (4): ssthresh = max (FlightSize / 2, 2*SMSS) (4) where, as discussed above, FlightSize is the amount of outstanding data in the network. [...] Implementation Note: An easy mistake to make is to simply use cwnd, rather than FlightSize, which in some implementations may incidentally increase well beyond rwnd. """ When a sender sends cwnd==20 packets a) fast-recovery: only 17th packet got dropped. FlightSize == 4 (pipe==1), ssthresh=2 b) timeout: 17-20th packets are dropped. FlightSize == 4(pipe==4), ssthresh=2 As a result, the next transaction, e.g., an HTTP response, will almost exit slow-start immediately and slowly increase cwnd per RTT. But AFAIK, ssthresh is based on slow-start overshoot by half of cwnd (of previous round trip), not current FlightSize. This has been implicitly addressed in Laminar, but I want to call this out b/c I don't understand the rwnd argument in RFC5681. As long as the sender respects rwnd, what's the problem? From eblanton@cs.ohiou.edu Thu Sep 6 12:07:34 2012 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 8AED921F84F1 for ; Thu, 6 Sep 2012 12:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFv7HkfFu2uN for ; Thu, 6 Sep 2012 12:07:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7760521F84EC for ; Thu, 6 Sep 2012 12:07:31 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=mail.kb8ojh.net) by psg.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T9hQG-0008J6-4T; Thu, 06 Sep 2012 19:07:29 +0000 Received: by mail.kb8ojh.net (Postfix, from userid 1000) id 4183831BB5; Thu, 6 Sep 2012 15:08:36 -0400 (EDT) Date: Thu, 6 Sep 2012 15:08:36 -0400 From: Ethan Blanton To: Yuchung Cheng Message-ID: <20120906190836.GA8018@mail.kb8ojh.net> Mail-Followup-To: Yuchung Cheng , "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 19:07:34 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yuchung Cheng spake unto us the following wisdom: > RFC 5681 specifically calls to use FlightSize instead of cwnd for cwnd > reduction. >=20 > """When a TCP sender detects segment loss using the retransmission timer > and the given segment has not yet been resent by way of the > retransmission timer, the value of ssthresh MUST be set to no more > than the value given in equation (4): >=20 > ssthresh =3D max (FlightSize / 2, 2*SMSS) (4) >=20 > where, as discussed above, FlightSize is the amount of outstanding > data in the network. >=20 > [...] >=20 > Implementation Note: An easy mistake to make is to simply use cwnd, > rather than FlightSize, which in some implementations may > incidentally increase well beyond rwnd. > """ > When a sender sends cwnd=3D=3D20 packets > a) fast-recovery: only 17th packet got dropped. FlightSize =3D=3D 4 > (pipe=3D=3D1), ssthresh=3D2 > b) timeout: 17-20th packets are dropped. FlightSize =3D=3D 4(pipe=3D=3D4)= , ssthresh=3D2 Note that this is _only_ true if there were only 20 segments available to send. Otherwise, by the time the dup ACKs for 17 come in, up to 32 (remember ssthresh!) new segments would have been clocked out. So your sender is either data-limited or protocol-limited or some such. What that means is, in your scenario, where FlightSize =3D=3D 4, at the time that packet 17 was dropped, your TCP's contribution to the network traffic was only 4 packets. Therefore, as far as it can tell, a burden of 4 packets is "too much". Yes, this is over simple and probably not the case -- but we're also talking about a corner case, here. Since you don't have any new data to send, anyway, you'll retransmit 17, get an ACK for 20, and close the connection or wait for new data or whatever. Ethan --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBUEj0tP8fixZ3H8crAQjFCgf/XRxoG+d3G1Hk7baB3tMht2Vgwx6VrTu/ daL2bOLuabBjAySKUp1ouBtmaAJUs40Il1w9cdyQrcJ99NUxqpBywB2goLTxsdPQ xkdjzHXI52upeg2bgDBtamc7T+qsSiDkyCzNpWUG8FdPPAqC7lGoL0Xe8OlOFET5 FfgeCH/K1Z+wsI05ykNe8Vv9Shx1/CJnWXjJ86DUNZl56qXqpENmLAvDdgQLe4AK H8BZgG6Ij66Vii8Al8Tu8ndK2HMMO8JnYIIEbj9gASHCusB2ZqdopA7xg8GCaMKM E641K5C5mRpyQE6yR/ORlE6xIL243ARsiM9Sfv0S30hoMmNn5ll71Q== =HJZ1 -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From ycheng@google.com Thu Sep 6 12:33:24 2012 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 0291221F8716 for ; Thu, 6 Sep 2012 12:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.912 X-Spam-Level: X-Spam-Status: No, score=-102.912 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_RMML_Stock9=0.13, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdXzXedGaQN3 for ; Thu, 6 Sep 2012 12:33:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 27E9621F8744 for ; Thu, 6 Sep 2012 12:33:22 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3521251obb.31 for ; Thu, 06 Sep 2012 12:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=rJ2c2TykAztHOg/bpcKlm9wGAiXoH2EtmNNyK2jz/fA=; b=n+VP701WF7qGHyFTIOOfvbf3o2PdiwB+rKs4//H/goxD2/Gb+FFFUKvh12RDxl/a9m Y6aNlVt8aibF7i8O0gY6zsUW4s8ykyPHn1g1l5B+x58hSv2L49FZ7yAZDEhLQgxZs7rO BUPp2cux7fiRFdzPiYJl0F5R9nx42cTP94CfVuvdAE/7xNu0XKGkpD+SZgR/mDLj/D+0 YsL/y2pMJ36i2j5bOEBWUk1icvQV5ikwvO/UY1VYPtx5g+5K4QMW2L7lKCidfwXYALc+ Sa7LPATC3w4yarm9wWIqes5f7Rp18JZvJk/z3pSJD3p2YkcBERCqbshW0dQGrp4cXW3a firQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=rJ2c2TykAztHOg/bpcKlm9wGAiXoH2EtmNNyK2jz/fA=; b=gf2Jd/jKVrobdjpTaqH5edzi6IRVu1itO+IRN8tDuWaf1zXMV09fdrufLoGR7PIm7x osDHFQk/r5EUPWwBb/Pkhu7uYH2U8FE4REisxs0PlG6sbM8Gyc+fmLl7mmBo5wxcTtd0 L4JpAsSo7Xrn5mWWWP67U9H8gG9m6t3JJADANx7Desf7T6ce1xGqr4FOcyJuXabbp3r+ 3SFXy7fM1t3/RN53UcrxVNCTSO5g2WEnkwoLdZtdq6dyNHtuprfrvvRiRR32n8XgTRTq YSl6M7A5OdcDS2DRn+oJGZ9SpivEtgZq7+tgATr2xI2uwZivvpO8Z+YJw5TyRQSsMb/r wkJA== Received: by 10.182.74.68 with SMTP id r4mr3566112obv.31.1346960002595; Thu, 06 Sep 2012 12:33:22 -0700 (PDT) Received: by 10.182.74.68 with SMTP id r4mr3566102obv.31.1346960002503; Thu, 06 Sep 2012 12:33:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.22.169 with HTTP; Thu, 6 Sep 2012 12:33:02 -0700 (PDT) In-Reply-To: <20120906190836.GA8018@mail.kb8ojh.net> References: <20120906190836.GA8018@mail.kb8ojh.net> From: Yuchung Cheng Date: Thu, 6 Sep 2012 12:33:02 -0700 Message-ID: To: Yuchung Cheng , "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkUFBiPGEbIx4XtHuW4hsK+Ri4wlc8OL19nWBfJNRl44QMRPtMlytf9b2lOGKNoYS1B3JE4rSfKq/NLA+RsjMNhg/iv0x1D1kMqJ+9hk984zNn+KheVDAXkSFPHNfcSwPsKmxTSQ7nk672Mp3Oift2ozMn+tiTnTpbgtZK6Cv0EEd12WYAhF4QKpZ4GIZ3/NsTdB33v Subject: Re: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 19:33:24 -0000 On Thu, Sep 6, 2012 at 12:08 PM, Ethan Blanton wrote: > Yuchung Cheng spake unto us the following wisdom: >> RFC 5681 specifically calls to use FlightSize instead of cwnd for cwnd >> reduction. >> >> """When a TCP sender detects segment loss using the retransmission timer >> and the given segment has not yet been resent by way of the >> retransmission timer, the value of ssthresh MUST be set to no more >> than the value given in equation (4): >> >> ssthresh = max (FlightSize / 2, 2*SMSS) (4) >> >> where, as discussed above, FlightSize is the amount of outstanding >> data in the network. >> >> [...] >> >> Implementation Note: An easy mistake to make is to simply use cwnd, >> rather than FlightSize, which in some implementations may >> incidentally increase well beyond rwnd. >> """ >> When a sender sends cwnd==20 packets >> a) fast-recovery: only 17th packet got dropped. FlightSize == 4 >> (pipe==1), ssthresh=2 >> b) timeout: 17-20th packets are dropped. FlightSize == 4(pipe==4), ssthresh=2 > > Note that this is _only_ true if there were only 20 segments available > to send. Otherwise, by the time the dup ACKs for 17 come in, up to 32 > (remember ssthresh!) new segments would have been clocked out. So > your sender is either data-limited or protocol-limited or some such. This is unfortunately the case of trillions of HTTP flows or any RPC interactive type traffic today. It's not a corner case. > > What that means is, in your scenario, where FlightSize == 4, at the > time that packet 17 was dropped, your TCP's contribution to the > network traffic was only 4 packets. Therefore, as far as it can tell, > a burden of 4 packets is "too much". so if I send 100 packet (then stop) and only the last 1 got dropped. I should start from ssthresh == 2? isn't it more reasonable to assume 100 is too much, not 1 is too much? then I am kinda unfortunate if the next some data is ready to send 1 RTT after the one packet loss is recovered. and I still don't get the rationale of rwnd argument in RFC 5681. > > Yes, this is over simple and probably not the case -- but we're also > talking about a corner case, here. Since you don't have any new data > to send, anyway, you'll retransmit 17, get an ACK for 20, and close > the connection or wait for new data or whatever. > > Ethan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQEVAwUBUEj0tP8fixZ3H8crAQjFCgf/XRxoG+d3G1Hk7baB3tMht2Vgwx6VrTu/ > daL2bOLuabBjAySKUp1ouBtmaAJUs40Il1w9cdyQrcJ99NUxqpBywB2goLTxsdPQ > xkdjzHXI52upeg2bgDBtamc7T+qsSiDkyCzNpWUG8FdPPAqC7lGoL0Xe8OlOFET5 > FfgeCH/K1Z+wsI05ykNe8Vv9Shx1/CJnWXjJ86DUNZl56qXqpENmLAvDdgQLe4AK > H8BZgG6Ij66Vii8Al8Tu8ndK2HMMO8JnYIIEbj9gASHCusB2ZqdopA7xg8GCaMKM > E641K5C5mRpyQE6yR/ORlE6xIL243ARsiM9Sfv0S30hoMmNn5ll71Q== > =HJZ1 > -----END PGP SIGNATURE----- > From mallman@icir.org Thu Sep 6 12:54:14 2012 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 EC90F21F8710 for ; Thu, 6 Sep 2012 12:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRKLCksp8HAO for ; Thu, 6 Sep 2012 12:54:14 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA3F21F86DC for ; Thu, 6 Sep 2012 12:54:14 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q86Js49R027928; Thu, 6 Sep 2012 12:54:04 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3F3452B075E6; Thu, 6 Sep 2012 15:54:03 -0400 (EDT) To: Yuchung Cheng From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Waitin' on a Sunny Day X-URL-0: http://www.icir.org/mallman-files/Document83708.doc X-URL-1: http://www.icir.org/mallman-files/Document20811.html X-URL-2: http://www.icir.org/mallman-files/Document36939.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma65368-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 06 Sep 2012 15:54:02 -0400 Sender: mallman@icir.org Message-Id: <20120906195403.3F3452B075E6@lawyers.icir.org> Cc: "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 19:54:15 -0000 ----------ma65368-1 Content-Type: text/plain Content-Disposition: inline A few things ... - I don't buy Ethan's argument that the burden on the network is 4 packets if you lose the 17th. It seems to me the burden is measured from the front of the window not the back. So, in this case it was a burden of 17 packets that caused the loss. - The historical reason why we use FlightSize instead of cwnd is that cwnd was not always reflective of the burden placed on the network. For instance, some implementations just let the cwnd grow without bound regardless of whether it was used or not. So, the cwnd might be (say) 100 even though you have never sent more than 20 segments per RTT when you go to set ssthresh. - (The note about the rwnd is not elegant! All we mean is that the cwnd is growing without being used and, hey, it could even grow higher than the rwnd. But, really who cares about the rwnd ... the point is that it grows unused and so is not reflective of anything.) - I may well buy that the current scheme leaves us too conservative due to cases like you sketch. Exactly how important this case is I'll leave to you and Ethan to fight out! :-) - So, without additional schemes we're left with being too aggressive (using cwnd) or too conservative (using FlightSize). But, if we're going to error that is probably the right direction. - I probably would not have all that much heartburn making the ssthresh 10 in the case you describe as long as there was some knowledge that a cwnd of 20 was used recently. I.e., it isn't the result of some large storage of permission to send that was built up over time, but was in fact the result of the application's sending pattern. I think one could design some rules around that notion that would be OK. allman ----------ma65368-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlBI/1oACgkQWyrrWs4yIs5gOACfd2E6HtgbPQzYgDTr/t8t2Tc2 er4An309rmYYmYY3fz4h0YX3B6Ug8/co =jO2h -----END PGP SIGNATURE----- ----------ma65368-1-- From eblanton@cs.ohiou.edu Thu Sep 6 14:24:24 2012 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 D56CD21F86FF for ; Thu, 6 Sep 2012 14:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIgaK0-ilwGM for ; Thu, 6 Sep 2012 14:24:24 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 600C421F86FE for ; Thu, 6 Sep 2012 14:24:24 -0700 (PDT) Received: from 99-52-196-7.lightspeed.crmlin.sbcglobal.net ([99.52.196.7] helo=mail.kb8ojh.net) by psg.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T9jYj-000D61-Ok; Thu, 06 Sep 2012 21:24:22 +0000 Received: by mail.kb8ojh.net (Postfix, from userid 1000) id 5A85A31BB5; Thu, 6 Sep 2012 17:25:30 -0400 (EDT) Date: Thu, 6 Sep 2012 17:25:30 -0400 From: Ethan Blanton To: Mark Allman Message-ID: <20120906212530.GB8018@mail.kb8ojh.net> Mail-Followup-To: Mark Allman , Yuchung Cheng , "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" References: <20120906195403.3F3452B075E6@lawyers.icir.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tjCHc7DPkfUGtrlw" Content-Disposition: inline In-Reply-To: <20120906195403.3F3452B075E6@lawyers.icir.org> X-GnuPG-Fingerprint: CB44 99AC EDDA D1AB D6E6 A2CA FF1F 8B16 771F C72B User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 21:24:24 -0000 --tjCHc7DPkfUGtrlw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mark Allman spake unto us the following wisdom: > A few things ... >=20 > - I don't buy Ethan's argument that the burden on the network is 4 > packets if you lose the 17th. It seems to me the burden is measured > from the front of the window not the back. So, in this case it was > a burden of 17 packets that caused the loss. Note that this was not intended to be my argument; my argument is that a TCP that doesn't "remember" such things (and 5681 does not) only knows about the 4 packets at the time of the loss, so it *thinks* the burden is 4. This is clearly not optimal, and I would not argue that it is. Perhaps I stated this poorly. > - So, without additional schemes we're left with being too aggressive > (using cwnd) or too conservative (using FlightSize). But, if we're > going to error that is probably the right direction. Agreed. > - I probably would not have all that much heartburn making the > ssthresh 10 in the case you describe as long as there was some > knowledge that a cwnd of 20 was used recently. I.e., it isn't the > result of some large storage of permission to send that was built up > over time, but was in fact the result of the application's sending > pattern. I think one could design some rules around that notion > that would be OK. Also agreed. I think it's reasonable to assume that the FlightSize in effect at the time a lost packet was *sent* is safe, for sure. Ethan --tjCHc7DPkfUGtrlw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUBUEkUyv8fixZ3H8crAQjDTQf9FG9ICMk6qClf3I3ImKQqHK0teDHZc9Nq qK9puTGxt3UyV1i5o8Dfxe95w5DQ8KiwllLw8ApsUCEma57eTfeEKi680uXkJken Z83RePjmeV3Ys2xHaAhpizHaeHRU8KNOl07Ss3D1lbrP/n0UtKmCCoMC6M9dt71m DDpPHZ0pt7vQoy/X8eU6Xm14++Qds31kvAenhM7hJUdTW8xJeXjQ5EgvUYkOur5B nvjlgfZLEpqbOHlmLXJCzzAJ9XrFKRLKh1JgIljz8rB1YTre7f3nFiUp5DervZgz +2Ry4Wkci0WV2Y085pQpyWdqRlV0BwxRfcyRoeulISbCRblwqtdtFQ== =9s9n -----END PGP SIGNATURE----- --tjCHc7DPkfUGtrlw-- From mallman@icir.org Thu Sep 6 15:05:58 2012 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 0C5A621F86AA for ; Thu, 6 Sep 2012 15:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBy1DIkj17n5 for ; Thu, 6 Sep 2012 15:05:57 -0700 (PDT) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9E93021F866D for ; Thu, 6 Sep 2012 15:05:57 -0700 (PDT) Received: from lawyers.icir.org (envoy.icir.org [192.150.187.30]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id q86M5X9x011686; Thu, 6 Sep 2012 15:05:33 -0700 (PDT) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 57B072B08E15; Thu, 6 Sep 2012 18:05:32 -0400 (EDT) To: Ethan Blanton From: Mark Allman In-Reply-To: <20120906212530.GB8018@mail.kb8ojh.net> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Waitin' on a Sunny Day X-URL-0: http://www.icir.org/mallman-files/Document27728.jpg X-URL-1: http://www.icir.org/mallman-files/Document85595.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="--------ma7722-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 06 Sep 2012 18:05:32 -0400 Sender: mallman@icir.org Message-Id: <20120906220532.57B072B08E15@lawyers.icir.org> Cc: "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" Subject: Re: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mallman@icir.org List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 22:05:58 -0000 ----------ma7722-1 Content-Type: text/plain Content-Disposition: inline > Note that this was not intended to be my argument; my argument is that > a TCP that doesn't "remember" such things (and 5681 does not) only > knows about the 4 packets at the time of the loss, so it *thinks* the > burden is 4. This is clearly not optimal, and I would not argue that > it is. Perhaps I stated this poorly. I agree with that. allman ----------ma7722-1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) iEYEARECAAYFAlBJHisACgkQWyrrWs4yIs4f2ACeLUjORWqjg7UTzp/8OZpj/C1F zdIAn16lTsZ61Ek1QdLNxSgRm/dPfLb0 =AXnn -----END PGP SIGNATURE----- ----------ma7722-1-- From mattmathis@google.com Thu Sep 6 15:50:36 2012 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 5F11721E803D for ; Thu, 6 Sep 2012 15:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP0+19nr-oci for ; Thu, 6 Sep 2012 15:50:35 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8489F21E803A for ; Thu, 6 Sep 2012 15:50:35 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1650472wib.13 for ; Thu, 06 Sep 2012 15:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record; bh=ikzziI0axOo0akzOxioHmPJTXmKw9RlbKjQEQFpPcDY=; b=n79QItn+m0DuCh0qZtCuNHuV1QGqG8/PFYStkO7ITm20GKhFUJsVCVaClmJde8HbPa H/8nklcSpmTXCvdqcyASwJElydtqHXtYjpPXaiq0kaUr31iFqSo3umtWEWt39OULt8nm e2kBMPuWz98S/a4xpUh+j8zdwQu66cTddBiFcIBPGQZYTtK4SBEkvsAJK74JbpaM9HLH vkjNUwUw0m5dqcwUae6c/qIQolrTL7hd5IYFLvTewwBllZ+yGFaZ6UAQIDTc7jQjZbVL b2keSHSOEBiDMVC2W/PrKJ6PvVPEC20gfhA0F76ONDg0qxpsNvT19QgZi9tdEGn9HO8E c9tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-system-of-record:x-gm-message-state; bh=ikzziI0axOo0akzOxioHmPJTXmKw9RlbKjQEQFpPcDY=; b=e9U5KX7xJ2RHmy9I/nPCbA5/JMzVUDedLflFp9bHfW3yLKoR5eg7IsB9QREka5rut7 fKLki/h/O0Kd7RcZkkdCoUeMHQkmJZ/vfu4K+Gz6FqGNB98diRCcPqVuyqJRakKme2yM BdJSrgSvkSwvUTwWcE5Y6GBKw0Lf2FM5QAhbDb8ZL0mdntrEJ6Z+yNf1aTOes3GOtEwp t1c6aLbY4DHc5QjgsKnYrbPjBy0wbt6hogiNNXondXKlq8KDYj98vOGXNo7d0pxwIAWG WMU1EgjUlh5PcrISUXJELevQxZl6EoN9SXudb8SnpC8yKS+y/x2CjvLfRuhVZ4mg1ZsK Pukg== Received: by 10.216.131.204 with SMTP id m54mr1948203wei.93.1346971834496; Thu, 06 Sep 2012 15:50:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.131.204 with SMTP id m54mr1948194wei.93.1346971834315; Thu, 06 Sep 2012 15:50:34 -0700 (PDT) Received: by 10.217.0.9 with HTTP; Thu, 6 Sep 2012 15:50:34 -0700 (PDT) In-Reply-To: <20120906212530.GB8018@mail.kb8ojh.net> References: <20120906195403.3F3452B075E6@lawyers.icir.org> <20120906212530.GB8018@mail.kb8ojh.net> Date: Thu, 6 Sep 2012 15:50:34 -0700 Message-ID: From: Matt Mathis To: Mark Allman , Yuchung Cheng , "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm0V2xtSYlekEEMxKGGq6QTz6cwjvZqseVkkMGU6RgLFBRc5srx8jKcWPmrOL9nZiIIkXrCvp5OV9AleyzMn2IiN6o02zLLlk2zSXbIONNf+zSI8FkqpVG3WMSmr2jDOD47pOgxIY7IQwGjYirN7eEY0v0SUZgYliuPeICLI/kYlBP02UKWhBCHf1XheqTTsw3rxF1Z Subject: Re: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 06 Sep 2012 22:50:36 -0000 On Thu, Sep 6, 2012 at 2:25 PM, Ethan Blanton wrote: > Mark Allman spake unto us the following wisdom: >> A few things ... >> >> - I don't buy Ethan's argument that the burden on the network is 4 >> packets if you lose the 17th. It seems to me the burden is measured >> from the front of the window not the back. So, in this case it was >> a burden of 17 packets that caused the loss. > > Note that this was not intended to be my argument; my argument is that > a TCP that doesn't "remember" such things (and 5681 does not) only > knows about the 4 packets at the time of the loss, so it *thinks* the > burden is 4. This is clearly not optimal, and I would not argue that > it is. Perhaps I stated this poorly. I would say that you are using the wrong state variables: at this point cwnd is simultaneously being used to suppress bursts and remember the congestion state from before the application pause. If you parameterize it differently (e.g. Laminar) this becomes a non-problem. >> - So, without additional schemes we're left with being too aggressive >> (using cwnd) or too conservative (using FlightSize). But, if we're >> going to error that is probably the right direction. > > Agreed. Yes exactly. One solution would be to pace from FS up to ccwind.... This case is described in the Laminar draft. >> - I probably would not have all that much heartburn making the >> ssthresh 10 in the case you describe as long as there was some >> knowledge that a cwnd of 20 was used recently. I.e., it isn't the >> result of some large storage of permission to send that was built up >> over time, but was in fact the result of the application's sending >> pattern. I think one could design some rules around that notion >> that would be OK. > > Also agreed. I think it's reasonable to assume that the FlightSize in > effect at the time a lost packet was *sent* is safe, for sure. I point out this logic assumes that it was the instantaneous queue length that triggered the losses (as it is for drop tail). With RED or CoDel, the losses are normally triggered by a persistent queue, which may or may not depend on the instantaneous window at the time the packet was either sent or received. With CoDel, drops are triggered when the minimum window size is still large enough to sustain a queue.... The peak window has no effect on the drops (unless the queue overflows). Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay From gorry@erg.abdn.ac.uk Thu Sep 6 23:53:17 2012 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 3837C21E8096 for ; Thu, 6 Sep 2012 23:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3WMlUsup2dj for ; Thu, 6 Sep 2012 23:53:16 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 58C0721E8095 for ; Thu, 6 Sep 2012 23:53:16 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 57FD42B44BB; Fri, 7 Sep 2012 07:53:14 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 7 Sep 2012 07:53:14 +0100 Message-ID: In-Reply-To: References: <20120906195403.3F3452B075E6@lawyers.icir.org> <20120906212530.GB8018@mail.kb8ojh.net> Date: Fri, 7 Sep 2012 07:53:14 +0100 From: gorry@erg.abdn.ac.uk To: "Matt Mathis" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" , Mark Allman Subject: Re: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 06:53:17 -0000 If FlightSize is not ~cwnd, then at the time, the flow is not fully utilising cwnd, but there are a wide range of (app) behaviours that result in this condition. My thoughts are that we should update the behaviour in both in standards-track TCP and also in Laminar. This has been the topic of the new-cwv draft that we have been proposing as an update to TCP. It's been discussed on the ICCRG list, and we're re-structuring our draft and expect to publish this revision in a week or so. Gorry > On Thu, Sep 6, 2012 at 2:25 PM, Ethan Blanton > wrote: >> Mark Allman spake unto us the following wisdom: >>> A few things ... >>> >>> - I don't buy Ethan's argument that the burden on the network is 4 >>> packets if you lose the 17th. It seems to me the burden is >>> measured >>> from the front of the window not the back. So, in this case it was >>> a burden of 17 packets that caused the loss. >> >> Note that this was not intended to be my argument; my argument is that >> a TCP that doesn't "remember" such things (and 5681 does not) only >> knows about the 4 packets at the time of the loss, so it *thinks* the >> burden is 4. This is clearly not optimal, and I would not argue that >> it is. Perhaps I stated this poorly. > > I would say that you are using the wrong state variables: at this > point cwnd is simultaneously being used to suppress bursts and > remember the congestion state from before the application pause. If > you parameterize it differently (e.g. Laminar) this becomes a > non-problem. > >>> - So, without additional schemes we're left with being too aggressive >>> (using cwnd) or too conservative (using FlightSize). But, if we're >>> going to error that is probably the right direction. >> >> Agreed. > > Yes exactly. One solution would be to pace from FS up to ccwind.... > This case is described in the Laminar draft. > >>> - I probably would not have all that much heartburn making the >>> ssthresh 10 in the case you describe as long as there was some >>> knowledge that a cwnd of 20 was used recently. I.e., it isn't the >>> result of some large storage of permission to send that was built >>> up >>> over time, but was in fact the result of the application's sending >>> pattern. I think one could design some rules around that notion >>> that would be OK. >> >> Also agreed. I think it's reasonable to assume that the FlightSize in >> effect at the time a lost packet was *sent* is safe, for sure. > > I point out this logic assumes that it was the instantaneous queue > length that triggered the losses (as it is for drop tail). With RED > or CoDel, the losses are normally triggered by a persistent queue, > which may or may not depend on the instantaneous window at the time > the packet was either sent or received. With CoDel, drops are > triggered when the minimum window size is still large enough to > sustain a queue.... The peak window has no effect on the drops > (unless the queue overflows). > > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From michawe@ifi.uio.no Fri Sep 7 00:00:16 2012 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 E2D9021F84BF for ; Fri, 7 Sep 2012 00:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPm92-Kz61iq for ; Fri, 7 Sep 2012 00:00:16 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0A321F84B2 for ; Fri, 7 Sep 2012 00:00:16 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1T9sY2-00065z-Gt; Fri, 07 Sep 2012 09:00:14 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1T9sY2-0004eG-1j; Fri, 07 Sep 2012 09:00:14 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl In-Reply-To: Date: Fri, 7 Sep 2012 09:00:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <07B9730D-105E-4059-AD65-ACEF141F354B@ifi.uio.no> References: To: Nandita Dukkipati X-Mailer: Apple Mail (2.1278) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 1 sum rcpts/h 6 sum msgs/h 2 total rcpts 23393 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, RP_MATCHES_RCVD=-1.018, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 03BF3C45736FFF3F629F27AFEA7E88A18197F99A X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9429 max/h 20 blacklist 0 greylist 0 ratelimit 0 Cc: tcpm@ietf.org, Matt Mathis Subject: Re: [tcpm] Question and comments about draft-dukkipati-tcpm-tcp-loss-probe X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 07:00:17 -0000 Hi, On 5. sep. 2012, at 22:01, Nandita Dukkipati wrote: > Michael, Apologies for the delay. These are good comments, here are > some answers - >=20 > On Wed, Aug 29, 2012 at 7:21 AM, Michael Welzl = wrote: >> Hi, >>=20 >> In an effort to address the CPM chairs' suggestion to clarify how = draft-hurtig-tcpm-rtorestart related to = draft-dukkipati-tcpm-tcp-loss-probe, I finally got around to reading the = loss-probe draft - and I'm missing a key bit of information that would = help me make the distinction (and would probably be good to include in = your draft anyway - and: sorry if I missed it! but I think it's really = not there): what is the rationale for your choice of "2 * SRTT" in the = calculation of the probe timeout (PTO)? I mean, why not 3*RTT, 1.5*RTT, = whatever? If this is just the result of measurements, it would be good = to report that where you report the others. >=20 > The probe timeout or PTO value was not out of measurements but in fact > picked in the design/coding stage and we just stuck with it. The > reason for 2.RTT is approximately as follows: the sender should wait > long enough to know that an ACK is overdue. Under normal > circumstances, i.e. no losses, this would typically be one RTT. But > choosing PTO to be exactly an RTT is likely to generate spurious > probes given that even end-system timings can easily push an ACK to be > above an RTT. And hence I just chose it to be the next integral value > of RTT. That makes sense to me; it's good to know the rationale behind it, = thanks. Just a minor detail: because the logic behind RTO also says that an ACK = is overdue, I would suggest setting PTO to min(RTO, 2*RTT). Sure, such a = small RTO is not the case of concern for you, but I'm not sure it's = really a corner case; perhaps? Either way, there will not a big = difference in the resulting behavior, but taking the min probably just = makes more sense. Cheers, Michael From michawe@ifi.uio.no Fri Sep 7 00:42:24 2012 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 2D97221F85F7 for ; Fri, 7 Sep 2012 00:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvEcLeJ7jcVB for ; Fri, 7 Sep 2012 00:42:23 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) by ietfa.amsl.com (Postfix) with ESMTP id BDEC021F84A2 for ; Fri, 7 Sep 2012 00:42:21 -0700 (PDT) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1T9tCl-0008Kz-G0; Fri, 07 Sep 2012 09:42:19 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx5.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1T9tCk-0002aH-NL; Fri, 07 Sep 2012 09:42:19 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: Date: Fri, 7 Sep 2012 09:42:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <41A94FC2-A138-4485-B7B9-21F3E9D34237@ifi.uio.no> References: <20120906195403.3F3452B075E6@lawyers.icir.org> <20120906212530.GB8018@mail.kb8ojh.net> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1278) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 2 sum rcpts/h 11 sum msgs/h 3 total rcpts 23398 max rcpts/h 58 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, FSL_RCVD_USER=0.001, RP_MATCHES_RCVD=-1.018, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2E8D714F8F08F315DEED0F2B0AA8C68D799002D6 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9430 max/h 20 blacklist 0 greylist 0 ratelimit 0 Cc: "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" , Matt Mathis , Mark Allman Subject: Re: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 07:42:24 -0000 Hi all, Not too long ago, Yuchung pointed out a very similar problem to the one = here with our own work, draft-hurtig-tcpm-rtorestart-02.txt, which = intends to make the RTO timer more aggressive if the really used window = is very small. We used FlightSize in our algorithm to represent this = "really used window". As with RFC 5681, our rationale is that FlightSize = captures the amount of data that is actually transmitted onto the = network, which may be significantly smaller than cwnd if the sender is = application-limited. Yuchung has now shown us that this choice is bad, twice. FlightSize = captures what we want, but additionally, a small FlightSize is also = always reached towards the end of an arbitrarily large window (yes, this = is also an application-limited case - it's about the difference between = an application with a low constant sending rate and the end of a = transfer (or, similarly, an application with a stop-and-go behavior)). = Neither our draft nor RFC 5681 really captures this situation. Indeed, = it seems to me the same problem appears in = draft-fairhurst-tcpm-newcwv-03.txt, which also relies on FlightSize in a = similar way: Section 4.2: *** Non-validated phase: FlightSize <(2/3)*cwnd. This is the phase where the cwnd has a value based on a previous measurement of the available capacity, and the usage of this capacity has not been validated in the previous RTT. *** If FlightSize reaches this value at the end of a larger window, I think = this statement is wrong. Indeed, in accordance with Yuchung's examples, = this would make the mechanisms in this draft kick in every time at the = end of e.g. a 20-packet-long web flow (or indeed at the end of any = transfer, with arbitrary length). I don't think that's the intention? I suspect that we can find more examples of RFCs or drafts with this = issue. The problem is indeed more fundamental - as Matt said, we're = using the wrong state variables. I can well imagine that the problem = automatically disappears with TCP Laminar, but as a smaller update to = existing / ongoing work, what we really need is probably a means to = differentiate Yuchung's case from the case of concern in at least RFC = 5681, draft-hurtig-tcpm-rtorestart and = draft-fairhurst-tcpm-newcwv-03.txt. Here's a simple suggestion: can we identify Yuchung's case by saying = that FlightSize has been continuously decreasing? Cheers, Michael On 7. sep. 2012, at 08:53, gorry@erg.abdn.ac.uk wrote: > If FlightSize is not ~cwnd, then at the time, the flow is not fully > utilising cwnd, but there are a wide range of (app) behaviours that = result > in this condition. My thoughts are that we should update the behaviour = in > both in standards-track TCP and also in Laminar. >=20 > This has been the topic of the new-cwv draft that we have been = proposing > as an update to TCP. It's been discussed on the ICCRG list, and we're > re-structuring our draft and expect to publish this revision in a week = or > so. >=20 > Gorry >=20 >=20 >> On Thu, Sep 6, 2012 at 2:25 PM, Ethan Blanton >> wrote: >>> Mark Allman spake unto us the following wisdom: >>>> A few things ... >>>>=20 >>>> - I don't buy Ethan's argument that the burden on the network is 4 >>>> packets if you lose the 17th. It seems to me the burden is >>>> measured >>>> from the front of the window not the back. So, in this case it = was >>>> a burden of 17 packets that caused the loss. >>>=20 >>> Note that this was not intended to be my argument; my argument is = that >>> a TCP that doesn't "remember" such things (and 5681 does not) only >>> knows about the 4 packets at the time of the loss, so it *thinks* = the >>> burden is 4. This is clearly not optimal, and I would not argue = that >>> it is. Perhaps I stated this poorly. >>=20 >> I would say that you are using the wrong state variables: at this >> point cwnd is simultaneously being used to suppress bursts and >> remember the congestion state from before the application pause. If >> you parameterize it differently (e.g. Laminar) this becomes a >> non-problem. >>=20 >>>> - So, without additional schemes we're left with being too = aggressive >>>> (using cwnd) or too conservative (using FlightSize). But, if = we're >>>> going to error that is probably the right direction. >>>=20 >>> Agreed. >>=20 >> Yes exactly. One solution would be to pace from FS up to ccwind.... >> This case is described in the Laminar draft. >>=20 >>>> - I probably would not have all that much heartburn making the >>>> ssthresh 10 in the case you describe as long as there was some >>>> knowledge that a cwnd of 20 was used recently. I.e., it isn't = the >>>> result of some large storage of permission to send that was = built >>>> up >>>> over time, but was in fact the result of the application's = sending >>>> pattern. I think one could design some rules around that notion >>>> that would be OK. >>>=20 >>> Also agreed. I think it's reasonable to assume that the FlightSize = in >>> effect at the time a lost packet was *sent* is safe, for sure. >>=20 >> I point out this logic assumes that it was the instantaneous queue >> length that triggered the losses (as it is for drop tail). With RED >> or CoDel, the losses are normally triggered by a persistent queue, >> which may or may not depend on the instantaneous window at the time >> the packet was either sent or received. With CoDel, drops are >> triggered when the minimum window size is still large enough to >> sustain a queue.... The peak window has no effect on the drops >> (unless the queue overflows). >>=20 >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From gorry@erg.abdn.ac.uk Fri Sep 7 01:32:47 2012 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 850ED21F8447 for ; Fri, 7 Sep 2012 01:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qNCBVYIjssA for ; Fri, 7 Sep 2012 01:32:46 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5683D21F8444 for ; Fri, 7 Sep 2012 01:32:46 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id A44AC2B45E7; Fri, 7 Sep 2012 09:32:45 +0100 (BST) Received: from Gorry.local (ra-gorry.erg.abdn.ac.uk [139.133.204.42]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id DCD1C2B44BB; Fri, 7 Sep 2012 09:32:39 +0100 (BST) Message-ID: <5049B126.90800@erg.abdn.ac.uk> Date: Fri, 07 Sep 2012 09:32:38 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Michael Welzl References: <20120906195403.3F3452B075E6@lawyers.icir.org> <20120906212530.GB8018@mail.kb8ojh.net> <41A94FC2-A138-4485-B7B9-21F3E9D34237@ifi.uio.no> In-Reply-To: <41A94FC2-A138-4485-B7B9-21F3E9D34237@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" , Matt Mathis , Mark Allman Subject: Re: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:32:47 -0000 It's not easy to just say FlightSize decreases, since this can happen in various cases. I'm wondering how useful it is to measure FlightSize during a transfer. It's a reasonable measure when there is reported congestion to figure out what was sent in the last "pipe", but it can result in an unexpected value (e.g. at the end of a burst). One of the changes we'd like to introduce in the next revision of new-cwv is to avoid this reliance on FlightSize to determine the window state of the sender. Instead we will suggest that the sender dtermines the state of the "pipe" by comparing the window that was ACK'ed with cwnd - not the volume of data was sent (FlightSize). In some cases, the two seem to be quite different. Gorry On 07/09/2012 08:42, Michael Welzl wrote: > Hi all, > > Not too long ago, Yuchung pointed out a very similar problem to the one here with our own work, draft-hurtig-tcpm-rtorestart-02.txt, which intends to make the RTO timer more aggressive if the really used window is very small. We used FlightSize in our algorithm to represent this "really used window". As with RFC 5681, our rationale is that FlightSize captures the amount of data that is actually transmitted onto the network, which may be significantly smaller than cwnd if the sender is application-limited. > > Yuchung has now shown us that this choice is bad, twice. FlightSize captures what we want, but additionally, a small FlightSize is also always reached towards the end of an arbitrarily large window (yes, this is also an application-limited case - it's about the difference between an application with a low constant sending rate and the end of a transfer (or, similarly, an application with a stop-and-go behavior)). Neither our draft nor RFC 5681 really captures this situation. Indeed, it seems to me the same problem appears in draft-fairhurst-tcpm-newcwv-03.txt, which also relies on FlightSize in a similar way: > > Section 4.2: > *** > Non-validated phase: FlightSize <(2/3)*cwnd. This is the phase > where the cwnd has a value based on a previous measurement of the > available capacity, and the usage of this capacity has not been > validated in the previous RTT. > *** > > If FlightSize reaches this value at the end of a larger window, I think this statement is wrong. Indeed, in accordance with Yuchung's examples, this would make the mechanisms in this draft kick in every time at the end of e.g. a 20-packet-long web flow (or indeed at the end of any transfer, with arbitrary length). I don't think that's the intention? > > I suspect that we can find more examples of RFCs or drafts with this issue. The problem is indeed more fundamental - as Matt said, we're using the wrong state variables. I can well imagine that the problem automatically disappears with TCP Laminar, but as a smaller update to existing / ongoing work, what we really need is probably a means to differentiate Yuchung's case from the case of concern in at least RFC 5681, draft-hurtig-tcpm-rtorestart and draft-fairhurst-tcpm-newcwv-03.txt. > > Here's a simple suggestion: can we identify Yuchung's case by saying that FlightSize has been continuously decreasing? > > Cheers, > Michael > > > On 7. sep. 2012, at 08:53, gorry@erg.abdn.ac.uk wrote: > >> If FlightSize is not ~cwnd, then at the time, the flow is not fully >> utilising cwnd, but there are a wide range of (app) behaviours that result >> in this condition. My thoughts are that we should update the behaviour in >> both in standards-track TCP and also in Laminar. >> >> This has been the topic of the new-cwv draft that we have been proposing >> as an update to TCP. It's been discussed on the ICCRG list, and we're >> re-structuring our draft and expect to publish this revision in a week or >> so. >> >> Gorry >> >> >>> On Thu, Sep 6, 2012 at 2:25 PM, Ethan Blanton >>> wrote: >>>> Mark Allman spake unto us the following wisdom: >>>>> A few things ... >>>>> >>>>> - I don't buy Ethan's argument that the burden on the network is 4 >>>>> packets if you lose the 17th. It seems to me the burden is >>>>> measured >>>>> from the front of the window not the back. So, in this case it was >>>>> a burden of 17 packets that caused the loss. >>>> >>>> Note that this was not intended to be my argument; my argument is that >>>> a TCP that doesn't "remember" such things (and 5681 does not) only >>>> knows about the 4 packets at the time of the loss, so it *thinks* the >>>> burden is 4. This is clearly not optimal, and I would not argue that >>>> it is. Perhaps I stated this poorly. >>> >>> I would say that you are using the wrong state variables: at this >>> point cwnd is simultaneously being used to suppress bursts and >>> remember the congestion state from before the application pause. If >>> you parameterize it differently (e.g. Laminar) this becomes a >>> non-problem. >>> >>>>> - So, without additional schemes we're left with being too aggressive >>>>> (using cwnd) or too conservative (using FlightSize). But, if we're >>>>> going to error that is probably the right direction. >>>> >>>> Agreed. >>> >>> Yes exactly. One solution would be to pace from FS up to ccwind.... >>> This case is described in the Laminar draft. >>> >>>>> - I probably would not have all that much heartburn making the >>>>> ssthresh 10 in the case you describe as long as there was some >>>>> knowledge that a cwnd of 20 was used recently. I.e., it isn't the >>>>> result of some large storage of permission to send that was built >>>>> up >>>>> over time, but was in fact the result of the application's sending >>>>> pattern. I think one could design some rules around that notion >>>>> that would be OK. >>>> >>>> Also agreed. I think it's reasonable to assume that the FlightSize in >>>> effect at the time a lost packet was *sent* is safe, for sure. >>> >>> I point out this logic assumes that it was the instantaneous queue >>> length that triggered the losses (as it is for drop tail). With RED >>> or CoDel, the losses are normally triggered by a persistent queue, >>> which may or may not depend on the instantaneous window at the time >>> the packet was either sent or received. With CoDel, drops are >>> triggered when the minimum window size is still large enough to >>> sustain a queue.... The peak window has no effect on the drops >>> (unless the queue overflows). >>> >>> Thanks, >>> --MM-- >>> The best way to predict the future is to create it. - Alan Kay >>> _______________________________________________ >>> 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 > From nanditad@google.com Fri Sep 7 12:18:05 2012 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 41CEF21E80C0 for ; Fri, 7 Sep 2012 12:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.677 X-Spam-Level: X-Spam-Status: No, score=-102.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIeMrc3rbuZk for ; Fri, 7 Sep 2012 12:18:04 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACB7F21E808F for ; Fri, 7 Sep 2012 12:18:04 -0700 (PDT) Received: by qcac10 with SMTP id c10so1855998qca.31 for ; Fri, 07 Sep 2012 12:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=htGZD6vYEfFWeKjyQSAIdPMN/L4iINHFfnsh835WX50=; b=d7uqo+fuWSRgbRTu8d7jazjU/g9BHqDEvP1kaQCBD5Gat/05F3/6Wx1CQB275L5nxo PJRF0mCH9ShfYOfJv8h293xiTHJ0ykNNk3GeG7Vm47rmjodMZEvUTj6KorVD8c9t96sV gS4fQE95Pn5tLgNMFomTqD6vISSs1S5LEmOtXWlzEi5/aYt7vzYasL/03yFafwBbGTLF V3xi5WmlbOjdYsuIv6jHkXSQ0/7qKrSsbj4tQEeApnX1U6F+EzT9qhWGqLGjKGxstDVY kxiMzd90i5KacwymsVa70+Fiiw+yiDxgs+fxXF/Za4KHR7VeHpjggPFrnKEOCMoYpOjN zZHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=htGZD6vYEfFWeKjyQSAIdPMN/L4iINHFfnsh835WX50=; b=JyFy4qEj10TWCnxUOdmcshCv6YSshoJgc3aD+ywtKpAhWBPnd/h+ZA8yD8DahIMCC+ U9H9ANQKd2Tfv8udg5LZEfbcBWsAKtDHCJwju6weF6po70iWkf2L4QaTOvDB82udtO8U KMtJi0/LAPjJFMjfgnReRTGXOfYkGGvCaEjuBBe0uPHIM7z+ZKU7eSjMzwRi2PjsGrq4 M54335SIf+2tyeab77E7RZLO6sEj5ytOu89vpy4c4XLRA8DwFxq5oyAcaGxf+nmgUVdC XRaL72Kh4ETT0AWMcyY4QILax4tC3W81wvj9r92wIpeUSDIjZkYb3ai/nghdRbMqELQJ W3pw== Received: by 10.224.98.2 with SMTP id o2mr8850477qan.57.1347045484168; Fri, 07 Sep 2012 12:18:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.98.2 with SMTP id o2mr8850449qan.57.1347045483572; Fri, 07 Sep 2012 12:18:03 -0700 (PDT) Received: by 10.229.192.77 with HTTP; Fri, 7 Sep 2012 12:18:03 -0700 (PDT) In-Reply-To: <07B9730D-105E-4059-AD65-ACEF141F354B@ifi.uio.no> References: <07B9730D-105E-4059-AD65-ACEF141F354B@ifi.uio.no> Date: Fri, 7 Sep 2012 12:18:03 -0700 Message-ID: From: Nandita Dukkipati To: Michael Welzl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQk+pYOhnV3VZJxUAyDeKLjHnL2WOPGAwvXk/JtBOvXe3liriG/EaQ9JBtb2kRlAoqU2qZjXl9tS/2McfnATDIiPYzVXZv5d4g32sNW2D8Kn6LlV9A0d5xlPxgX3SYzg7YsFRq1AZSIS9gS1AEwxBB4jHDqVNx3rlp1ukDCB+OmE4WvaDkeeq+DRa53Kd1dmVVh4mJ1l Cc: tcpm@ietf.org, Matt Mathis Subject: Re: [tcpm] Question and comments about draft-dukkipati-tcpm-tcp-loss-probe X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 19:18:05 -0000 >> The probe timeout or PTO value was not out of measurements but in fact >> picked in the design/coding stage and we just stuck with it. The >> reason for 2.RTT is approximately as follows: the sender should wait >> long enough to know that an ACK is overdue. Under normal >> circumstances, i.e. no losses, this would typically be one RTT. But >> choosing PTO to be exactly an RTT is likely to generate spurious >> probes given that even end-system timings can easily push an ACK to be >> above an RTT. And hence I just chose it to be the next integral value >> of RTT. > > That makes sense to me; it's good to know the rationale behind it, thanks= . > > Just a minor detail: because the logic behind RTO also says that an ACK i= s overdue, I would suggest setting PTO to min(RTO, 2*RTT). Sure, such a sma= ll RTO is not the case of concern for you, but I'm not sure it's really a c= orner case; perhaps? Either way, there will not a big difference in the res= ulting behavior, but taking the min probably just makes more sense. Agree, so if we are not able to schedule a PTO (Step 2 condition in TLP algo. fails when RTO is not farther than PTO), we could just make PTO to be a value smaller than RTO. There wouldn't be much point in sending a probe if PTO is exactly RTO, so it does need to be strictly smaller. Along similar lines we have been toying with an idea to push out the RTO epoch farther by a sufficient value such that we always get to schedule the lower impact PTO (still 2.RTT) before taking the high impact RTO. > > Cheers, > Michael > From nanditad@google.com Fri Sep 7 12:33:01 2012 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 12EAA21F861E for ; Fri, 7 Sep 2012 12:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmWF8djE47xy for ; Fri, 7 Sep 2012 12:33:00 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51ECE21F85FF for ; Fri, 7 Sep 2012 12:33:00 -0700 (PDT) Received: by qafi29 with SMTP id i29so87056qaf.10 for ; Fri, 07 Sep 2012 12:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-system-of-record; bh=bLJ4LoiLI+0ckAskbUrJs/SGgTWDOD94YZ/UPUkX2fQ=; b=DuDFnNrn28oQOMwyPmS4hZB0fPaiuyG+8KV561U7bvfgTDdL5qetjth1FNcq5d+WE3 VzZPIRvypH7cvpYSqdt5v7kvdiRDbXMxb/iArVBLlEAro6oi0V3EhawqtHnNoyiuiC4y buWkE32WlPh5UsWF1T9botJLirz3lTqfrfjxNPKUG95sJK8L3M367nL3f0K4eMxlLLkr hncGjOVhieYN0/kEqD64WlJdYM4gBBB0Z3gJec5OW7h1xeqPVqlJO1uByrRwYKvDMrcc OuBwzx0o+dT1Bg6RPUeHBMT0n0rmH9qDBbZ3yWZaGgYT3z2UaiJu7jC1jwdLgyW4KsWZ ZESg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-system-of-record:x-gm-message-state; bh=bLJ4LoiLI+0ckAskbUrJs/SGgTWDOD94YZ/UPUkX2fQ=; b=a7cntMHZlSgM6BAbch9f86hg3eYnM0P5B3jXlNFJsCtphHScyJZSevZlz07IUnA27L /Blk0Vq3JChE0PdB8zrTFbBKY1OwpGaXjgePnPc9GoOQBe+kPSRhwXZisb2LvBa3ELIG hcHIdrNYlZf4MuzIV/kVsxKPAv9WRwHH5YOm47AbIl+H1fSCTzorUG9Dv+A9h78p2hDj GaDzFcGumpPrt6RmGvW1uzgJorMQjRfvTApJH/KQ7ZWpAlr43B8/pP4oOGX0976Qq1gv 2uFbyGZfRKwa1s9pTQw4EjeR6GwNeM4+bzMeO5mHQ6geqG+nsJ1B6pJLSs8p01mhLppV QuIw== Received: by 10.224.221.84 with SMTP id ib20mr8887207qab.50.1347046379805; Fri, 07 Sep 2012 12:32:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.221.84 with SMTP id ib20mr8887197qab.50.1347046379654; Fri, 07 Sep 2012 12:32:59 -0700 (PDT) Received: by 10.229.192.77 with HTTP; Fri, 7 Sep 2012 12:32:59 -0700 (PDT) Date: Fri, 7 Sep 2012 12:32:59 -0700 Message-ID: From: Nandita Dukkipati To: tcpm@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQlm/33NNTl0sL9UWSPD26vrV/7FVNVcYNkC92HAtxyXp2iGtPy8AM8/uzk4FLgfZ7F93MQHERI1h8fYBPXBxvEZaiuud1yL7j4TB8z6Ofwd85znAN4sAHw3j8GpsXbcPKCXDTOUR3qEHJGMzIvPQ7k+iYjXZfRHyELQ3JSGoO3AqqLN2FRDWlcNMvRWUuvGkrdB2jz1 Cc: Matt Mathis Subject: [tcpm] Tail loss probe discussions @IETF-84 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 19:33:01 -0000 Michael's email reminded me to send out my summary of discussions related to TLP at last IETF. Because of tight TCPM agenda, all questions were offline. Folks can correct me if I am recounting the discussions incorrectly ;) [Richard Scheffenegger] * For TLP loss plugging, if timestamps are available, could they be used to check which transmission plugged the hole? - That's correct. Draft should include this. * "rescue retransmission" introduced in 3517bis deals with loss events such as AL*SL*. TLP covers wider range of circumstances such as AL*. How often is "AL*" really a AL*S*L* that can be recovered by regular SACK recovery. Reference to 3517bis and rescue retransmissions would be good. - We implemented rescue retransmission on our Web servers, but didn't see much performance improvement. When the last segment is lost, it is more likely that a number of contiguous segments preceding the segment are also lost, i.e. AL* is common. Timeouts that occur in the fast recovery are rare. * Wouldn't it be worthwhile to look into an adaptive re-ACK scheme, where client retransmits the last ACK when for a certain period no additional data segment was received? - But that in itself is not sufficient to trigger fast recovery at sender. The receiver has no SACK blocks to report in the event of tail loss. Just receiving duplicate ACKs without SACK blocks is not enough to trigger fast recovery (at least true for Linux SACK). [Anantha Ramaiah] * How many consecutive probes do you send? - Draft specifies at most two back-to-back probes. * Can you take help from the applications to indicate end of transaction and somehow use that for smarter tail loss recovery? * Wanted to see a description/diagram of relation between PTO (probe timeout) and RTO. [Michael Welzl and tcpm chairs] * There is another draft in tcpm related to RTO - http://www.ietf.org/id/draft-hurtig-tcpm-rtorestart-02.txt Would be great to understand the relation between RTO-restart and TLP draft. Both draft authors think these I-Ds are orthogonal; more discussion needed on this front. [Ilpo J=E4rvinen] Linux specific. * Discussed about reviving the idea of transmitting just 1-byte probe. As per Ilpo it may be a Linux bug that a SACK of one segment triggers fast recovery but that a SACK of 1-byte disn't. Potentially if we fix this bug, we will not require any extra loss detection algorithm. * Apparently there was something like TLP by the thin-stream folks. Even posted to net-dev, but patch was confusing to review. Need to look this up. * We discussed on whether TLP probes should increment retrans_out. If we do that then sender can no longer be in Open state, so probably best not to increment retrans_out. Plan to address these questions in the next rev. of I-D. Nandita From ycheng@google.com Fri Sep 7 15:49:22 2012 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 E810D21F85F0 for ; Fri, 7 Sep 2012 15:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.945 X-Spam-Level: X-Spam-Status: No, score=-102.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeEU+uPydYL7 for ; Fri, 7 Sep 2012 15:49:22 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9B821F85E6 for ; Fri, 7 Sep 2012 15:49:22 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so170312obb.31 for ; Fri, 07 Sep 2012 15:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=WZ/AaQQjGJQp8Vd/surpw+Tb0ho0rG8NCY/0lzHyFGA=; b=I32I/eR2qdiijy7dRwHQ1LrRE4BiiMq3EdBSENNxWO+4/QrROoT1cjntx56KL1bS1e vC4zcGL4fExAPhHOCHt64qSODkqFFtNqLZvYVQ6fRaifWUhlnDhv631x3lIeOEIQyimG EExFHEvkXbTJoLRL6nwqeBB6UuMCbDOeF35WYqFrvfmemDFNfyTWhpf/QzB64FDjIl/w 7slTNYn0GcWNdH3h6Q57yPRF36BhDf7ljEqEMpmRPgwSZq1Hj7yxx5YsJlo63Tr2Lzrj qI6CDcDA/mUtFVe5A3SSqtbTt0NPGkXb25f0yhJ2RWKpnqbohTrhYSpPD0zyNtjnEoPZ +RJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=WZ/AaQQjGJQp8Vd/surpw+Tb0ho0rG8NCY/0lzHyFGA=; b=R0k86bJLJjMTu/OnHwzDiuOlXu/D+m3PtnPqzdTAu1nlmmjMvgAnOormO4pcjEUu5C sCF+MLQqdRnAsGrIAvfKvnoovNoN5yxxexWehBixjwQ80wWyBOZHdzXMULzjowF7D5KK BmYnDhTy9mUKCqBaMNMEOGiBGBXD+fiL0HJS6iPHFWecM6EVO+YJDkNzVzJsIqraMA23 FdAQSidOzMXbG+eFzwFCCk1WJSuKP0wDX0hT1khTGa11SIxzDadYiotC6uYomUAzN58/ Qa7Y+AsL+oEQVOXXUXla9pf1tWPiUfUe6eV2fHLjDUZZ5B+5fB5Ua8Z0EzW3RUjz3kV2 zo2w== Received: by 10.182.74.68 with SMTP id r4mr7645995obv.31.1347058162012; Fri, 07 Sep 2012 15:49:22 -0700 (PDT) Received: by 10.182.74.68 with SMTP id r4mr7645982obv.31.1347058161909; Fri, 07 Sep 2012 15:49:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.22.169 with HTTP; Fri, 7 Sep 2012 15:49:01 -0700 (PDT) In-Reply-To: <5049B126.90800@erg.abdn.ac.uk> References: <20120906195403.3F3452B075E6@lawyers.icir.org> <20120906212530.GB8018@mail.kb8ojh.net> <41A94FC2-A138-4485-B7B9-21F3E9D34237@ifi.uio.no> <5049B126.90800@erg.abdn.ac.uk> From: Yuchung Cheng Date: Fri, 7 Sep 2012 15:49:01 -0700 Message-ID: To: gorry@erg.abdn.ac.uk Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmlro2+/SjvQ6lWw8q+G9mns+aMTsouNe0Q9mPNwMHBF1LpsaWS3a6YAkDqoKmjEHKANSu18s1BwamAjCt7t7OgykDuneSSIIn8psZWUpcfgduGyH50JNG6mVver0hVSZ1GYaXfFLmmktn6FmBDH2Di+jSU15ZsN9FP3sqAubchIBvk3A+vPtTGxz7rFLhB5tezkOQG Cc: "tcpm@ietf.org Extensions" , "iccrg@cs.ucl.ac.uk list" , Matt Mathis , Michael Welzl , Mark Allman Subject: Re: [tcpm] RFC5681: why halving FlightSize not cwnd? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 07 Sep 2012 22:49:23 -0000 I am glad we all identify the problem about FlightSize. We need a better mechanism to address application-limited cases, i.e., when cwnd is not fully used recently. within an RTT or so: a) loss: halve cwnd or flightsize or something else? b) no-loss: grow cwnd or not? longer than several RTTs (idle) c) decay the cwnd every couple minutes or every couple RTO, slow-start to prev cwnd, blah? There is always a concern about potential bursts leaving cwnd >> FlightSize. So RFCs and implementations drag cwnd to "moderate" potential bursts. For example, Linux pulls cwnd down to FlightSize + epsilon whenever an ACK does not look right, and refuses to grow cwnd unless it was fully used. And most congestion control design does not consider these events. I don't know what the right solution is yet. Pacing + track inflight of last RTT? but I know app-limited cases happen a whole lot today. Beside HTTP or RPCs (in data centers), even video deliveries are interactive, e.g., NetFlix or Youtube. The apps pace at second(s) interval to conserve network bandwidth. And TCP-smart apps all use persistent connections today. TCP usage has moved away from bulk-ftp long time... Yuchung From michael.scharf@alcatel-lucent.com Wed Sep 12 22:38:06 2012 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 BC94C21F84B2 for ; Wed, 12 Sep 2012 22:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkoig8rXn+HW for ; Wed, 12 Sep 2012 22:38:05 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id AA7A521F848B for ; Wed, 12 Sep 2012 22:38:04 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8D5bwo1028260 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 13 Sep 2012 07:38:03 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 13 Sep 2012 07:38:00 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Thu, 13 Sep 2012 07:37:59 +0200 Thread-Topic: [ipr-announce] IPR Disclosure: NetApp's Statement about IPR related to draft-kuehlewind-conex-accurate-ecn-01 and draft-kuehlewind-tcpm-accurate-ecn-01 Thread-Index: Ac2RDafGO+VlmL0nR8qi3743rjfs7wAY+4Fg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891AAE4099@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: [tcpm] FW: [ipr-announce] IPR Disclosure: NetApp's Statement about IPR related to draft-kuehlewind-conex-accurate-ecn-01 and draft-kuehlewind-tcpm-accurate-ecn-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2012 05:38:06 -0000 fyi Comments? -----Original Message----- From: ipr-announce-bounces@ietf.org [mailto:ipr-announce-bounces@ietf.org] = On Behalf Of IETF Secretariat Sent: Wednesday, September 12, 2012 7:40 PM To: mirja.kuehlewind@ikr.uni-stuttgart.de; rs@netapp.com Cc: ipr-announce@ietf.org Subject: [ipr-announce] IPR Disclosure: NetApp's Statement about IPR relate= d to draft-kuehlewind-conex-accurate-ecn-01 and draft-kuehlewind-tcpm-accur= ate-ecn-01 Dear Mirja Kuehlewind, Richard Scheffenegger: An IPR disclosure that pertains to your Internet-Draft entitled "More Accu= rate ECN Feedback in TCP" (draft-kuehlewind-tcpm-accurate-ecn) was submitte= d to the IETF Secretariat on 2012-09-12 and has been posted on the "IETF Pa= ge of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1881/). The title of the IPR disclosure i= s "NetApp's Statement about IPR related to draft-kuehlewind-conex-accurate-= ecn-01 and draft-kuehlewind-tcpm-accurate-ecn-01.""); The IETF Secretariat _______________________________________________ ipr-announce mailing list ipr-announce@ietf.org https://www.ietf.org/mailman/listinfo/ipr-announce From tsabatini@hotmail.com Thu Sep 13 07:12:50 2012 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 F042F21F84F9 for ; Thu, 13 Sep 2012 07:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z28IBpnXrhFx for ; Thu, 13 Sep 2012 07:12:42 -0700 (PDT) Received: from bay0-omc2-s7.bay0.hotmail.com (bay0-omc2-s7.bay0.hotmail.com [65.54.190.82]) by ietfa.amsl.com (Postfix) with ESMTP id AEBAC21F84E2 for ; Thu, 13 Sep 2012 07:12:42 -0700 (PDT) Received: from BAY158-W62 ([65.54.190.123]) by bay0-omc2-s7.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Sep 2012 07:12:42 -0700 Message-ID: Content-Type: multipart/mixed; boundary="_d72115f6-159f-40f2-96e9-411bf0a4c0f7_" X-Originating-IP: [74.64.96.39] From: Anthony Sabatini To: tcpm Date: Thu, 13 Sep 2012 10:12:41 -0400 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Sep 2012 14:12:42.0386 (UTC) FILETIME=[D6E40F20:01CD91B9] Subject: [tcpm] New draft draft-sabatini-tcp-sack-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2012 14:12:51 -0000 --_d72115f6-159f-40f2-96e9-411bf0a4c0f7_ Content-Type: multipart/alternative; boundary="_8761743b-b439-45a9-99ca-6483a19a3c80_" --_8761743b-b439-45a9-99ca-6483a19a3c80_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All - Having taken into account all of your kind comments I have incorporated the= m into this draft. Also=2C for those who would like to understand the history behind the propo= sed changes I have also included a draft of the TDLC rfc=2C draft-sabatini-= tdlc-00. Thank you for forbearance. Tony Anthony Sabatini 200 West 20th Street Apt. 1216 New York=2C NY 10011 Phone: (212) 867-7179 Mobile: (917) 224-8388 =20 = --_8761743b-b439-45a9-99ca-6483a19a3c80_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
All -

Having taken into account all of your kind comments I have inc= orporated them into this draft.

Also=2C for those who would like to = understand the history behind the proposed changes I have also included a d= raft of the TDLC rfc=2C draft-sabatini-tdlc-00.

Thank you for forbea= rance.

Tony

Anthony Sabatini
200 =3BWest 20th StreetApt. 1216
New York=2C NY 10011

Phone: (212) 867-7179
Mobile:= (917) 224-8388

 =3B
= --_8761743b-b439-45a9-99ca-6483a19a3c80_-- --_d72115f6-159f-40f2-96e9-411bf0a4c0f7_ Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sackrfc1out.txt" DQoNCg0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEEuIFNhYmF0aW5pDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQnJva2VyIENvbW11bmljYXRpb25zIEluYy4NCkludGVuZGVkIFN0 YXR1czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgLg0KRXhwaXJlczogRmVicnVhcnkgMTQsIDIwMTMgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQXVndXN0IDE1LCAyMDEyDQoNCiAgICAgICBIaWdobHkgRWZmaWNpZW50IFNlbGVjdGl2 ZSBBY2tub3dsZWRnZW1lbnQgKFNBQ0spIGZvciBUQ1ANCiAgICAgICAgICAgICAgICAgICAgICAg ZHJhZnQtc2FiYXRpbmktdGNwLXNhY2stMDENCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBU aGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGgg dGhlDQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LiBJbnRlcm5ldC1EcmFmdHMg YXJlIHdvcmtpbmcNCiAgIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFz ayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywNCiAgIGFuZCBpdHMgd29ya2luZyBncm91cHMuIE5v dGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQ0KICAgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0 IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFuZCBtYXkg YmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQg YW55DQogICB0aW1lLiBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMg YXMgcmVmZXJlbmNlDQogICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJh ZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy8xaWQtYWJzdHJh Y3RzLmh0bWwNCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9y aWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRt bA0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEphbnVhcnkgMjIsIDIw MTMuDQoNCiAgIENvbW1lbnRzIGFyZSBzb2xpY2l0ZWQgYW5kIHNob3VsZCBiZSBhZGRyZXNzZWQg dG8gdGhlIGF1dGhvciBhdA0KICAgZHJhZnQtc2Fja0B0c2FiYXRpbmkuY29tLg0KDQpDb3B5cmln aHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAxMiBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gQWxsIHJpZ2h0cyBy ZXNlcnZlZC4NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhl IElFVEYgVHJ1c3QncyBMZWdhbA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3Vt ZW50cw0KICAgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0 IG9uIHRoZSBkYXRlIG9mDQogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiBQbGVhc2Ug cmV2aWV3IHRoZXNlIGRvY3VtZW50cw0KICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlv dXIgcmlnaHRzIGFuZCByZXN0cmljdGlvbnMgd2l0aCByZXNwZWN0DQogICB0byB0aGlzIGRvY3Vt ZW50LiBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0DQog ICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlk ZWQgd2l0aG91dCB3YXJyYW50eSBhcw0KICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJT RCBMaWNlbnNlLg0KDQpBYnN0cmFjdA0KDQoNCg0KU2FiYXRpbmksIEFudGhvbnkgICAgICAgRXhw aXJlcyBGZWJydWFyeSAxNCwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDFdDQoNCg0KDQoNCg0K SW50ZXJuZXQgRHJhZnQgICAgICAgIEhpZ2ggRWZmaWNpZW5jeSBTQUNLIGZvciBUQ1AgICAgICAg QXVndXN0IDE1LCAyMDEyDQoNCg0KICAgVGhpcyBtZW1vIGV4cGFuZHMgb24gdGhlIFNlbGVjdGl2 ZSBBY2tub3dsZWRnZW1lbnQgUHJvdG9jb2wgZGVzY3JpYmVkDQogICBpbiBSRkMyMDE4IHRvIGlt cHJvdmUgaXRzIHBlcmZvcm1hbmNlIGFuZCBlZmZpY2llbmN5IHdoaWxlIHJlZHVjaW5nDQogICB0 aGUgZGVsYXkgaW52b2x2ZWQgaW4gcmVjb3ZlcmluZyBsb3N0IHNlZ21lbnRzLiAgVGhpcyBsZWFk cyB0byB2ZXJ5DQogICByZWxpYWJsZSBhbmQgZWZmaWNpZW50IGNvbW11bmljYXRpb25zIHJlZ2Fy ZGxlc3Mgb2YgdHJhbnNpdCBkZWxheSBvcg0KICAgaGlnaCBsZXZlbHMgb2YgbG9zdCBzZWdtZW50 cyBkdWUgdG8gbm9pc2Ugb3IgY29uZ2VzdGlvbi4gIEl0DQogICBpbnRyb2R1Y2VzIGEgZnVuZGFt ZW50YWxseSBuZXcgd2F5IG9mIGxvb2tpbmcgYXQgU2VsZWN0aXZlDQogICBBY2tub3dsZWRnZW1l bnQgYW5kIHVzZXMgdGhpcyBjb25jZXB0IHRvIGltcHJvdmUgdGhlIHBlcmZvcm1hbmNlIG9mDQog ICB0aGUgUkZDMjAxOCBwcm90b2NvbC4gIFRoaXMgbWVtbyBwcm9wb3NlcyBhbiBpbXBsZW1lbnRh dGlvbiBvZiB0aGUNCiAgIGltcHJvdmVkIFNBQ0sgYW5kIGRpc2N1c3NlcyBpdHMgcGVyZm9ybWFu Y2UgYW5kIHJlbGF0ZWQgaXNzdWVzLg0KDQpBY2tub3dsZWRnZW1lbnRzDQoNCiAgIE11Y2ggb2Yg dGhlIHRleHQgaW4gdGhpcyBkb2N1bWVudCBpcyB0YWtlbiBkaXJlY3RseSBmcm9tIFJGQzIwMTgg IlRDUA0KICAgU2VsZWN0aXZlIEFja25vd2xlZGdlbWVudCBPcHRpb25zIiBieSBNLiBNYXRoaXMs IEouIE1haGRhdmksIFMuIEZsb3lkDQogICBhbmQgQS4gUm9tYW5vdyBhbmQgUkZDMTA3MiAiVENQ IEV4dGVuc2lvbnMgZm9yIExvbmctRGVsYXkgUGF0aHMiIGJ5DQogICBCLiBCcmFkZW4gYW5kIFYu IEphY29ic29uLg0KDQoxLiAgSW50cm9kdWN0aW9uDQoNCiAgIFRoaXMgcmV2aXNpb24gdG8gdGhl IFNBQ0sgcHJvdG9jb2wgaGFzIGl0cyByb290cyBpbiBhIHNpbWlsYXIsIEhETEMNCiAgIGJhc2Vk IHByb3RvY29sIEkgZGVzaWduZWQgYW5kIGltcGxlbWVudGVkIGZvciBzZWN1cmUgZmluYW5jaWFs DQogICB0cmFuc2FjdGlvbnMuICBUaGF0IHByb3RvY29sLCBiZWluZyBkZXNpZ25lZCBmb3IgdXNl IG9uIGEgd29ybGR3aWRlDQogICBiYXNpcywgd2FzIGJvcm4gb3V0IG9mIHRoZSBuZWVkIGZvciBh IHByb3RvY29sIHRoYXQgd291bGQgaGFuZGxlIGFueQ0KICAgY29tbXVuaWNhdGlvbnMgZW52aXJv bm1lbnQgbm8gbWF0dGVyIGhvdyBub2lzeSBvciBob3cgbXVjaCBkZWxheQ0KICAgKGluY2x1ZGlu ZyBtdWx0aXBsZSBzYXRlbGxpdGUgaG9wcykgd2FzIGluIHRoZSBwYXRoLiAgSW4gbGF0ZXIgeWVh cnMNCiAgIGl0cyBwcm9wZXJ0aWVzIHdlcmUgZm91bmQgdmFsdWFibGUgaW4gY29uZ2VzdGlvbiBz aXR1YXRpb25zIHdoZXJlDQogICBwYWNrZXRzIHdlcmUgZHJvcHBlZC4NCg0KICAgTXVsdGlwbGUg cGFja2V0IGxvc3NlcyBmcm9tIGEgd2luZG93IG9mIGRhdGEgY2FuIGhhdmUgYSBjYXRhc3Ryb3Bo aWMNCiAgIGVmZmVjdCBvbiBUQ1AgdGhyb3VnaHB1dC4gVENQIFtQb3N0ZWw4MV0gdXNlcyBhIGN1 bXVsYXRpdmUNCiAgIGFja25vd2xlZGdtZW50IHNjaGVtZSBpbiB3aGljaCByZWNlaXZlZCBzZWdt ZW50cyB0aGF0IGFyZSBub3QgYXQgdGhlDQogICBsZWZ0IGVkZ2Ugb2YgdGhlIHJlY2VpdmUgd2lu ZG93IGFyZSBub3QgYWNrbm93bGVkZ2VkLiAgVGhpcyBmb3JjZXMNCiAgIHRoZSBzZW5kZXIgdG8g ZWl0aGVyIHdhaXQgYSByb3VuZC10cmlwIHRpbWUgdG8gZmluZCBvdXQgYWJvdXQgZWFjaA0KICAg bG9zdCBwYWNrZXQsIG9yIHRvIHVubmVjZXNzYXJpbHkgcmV0cmFuc21pdCBzZWdtZW50cyB3aGlj aCBoYXZlIGJlZW4NCiAgIGNvcnJlY3RseSByZWNlaXZlZCBbRmFsbDk1XS4gIFdpdGggdGhlIGN1 bXVsYXRpdmUgYWNrbm93bGVkZ21lbnQNCiAgIHNjaGVtZSwgbXVsdGlwbGUgZHJvcHBlZCBzZWdt ZW50cyBnZW5lcmFsbHkgY2F1c2UgVENQIHRvIGxvc2UgaXRzDQogICBBQ0stYmFzZWQgY2xvY2ss IHJlZHVjaW5nIG92ZXJhbGwgdGhyb3VnaHB1dC4NCg0KICAgU2VsZWN0aXZlIEFja25vd2xlZGdt ZW50IChTQUNLKSBpcyBhIHN0cmF0ZWd5IHdoaWNoIGNvcnJlY3RzIHRoaXMNCiAgIGJlaGF2aW9y IGluIHRoZSBmYWNlIG9mIG11bHRpcGxlIGRyb3BwZWQgc2VnbWVudHMuICBXaXRoIHNlbGVjdGl2 ZQ0KICAgYWNrbm93bGVkZ21lbnRzLCB0aGUgZGF0YSByZWNlaXZlciBjYW4gaW5mb3JtIHRoZSBz ZW5kZXIgYWJvdXQgYWxsDQogICBzZWdtZW50cyB0aGF0IGhhdmUgYXJyaXZlZCBzdWNjZXNzZnVs bHksIHNvIHRoZSBzZW5kZXIgbmVlZA0KICAgcmV0cmFuc21pdCBvbmx5IHRoZSBzZWdtZW50cyB0 aGF0IGhhdmUgYWN0dWFsbHkgYmVlbiBsb3N0LiAgVGhlDQogICBjb21wYXRpYmxlIGV4dGVuc2lv bnMgdG8gUkZDMjAxOCBwcm9wb3NlZCBoZXJlIGVuaGFuY2UgdGhlIHByb3RvY29sDQogICBieSBj aGFuZ2luZyByZXRyYW5zbWlzc2lvbiBmcm9tIGEgd29yc3QgY2FzZSB0aW1lciBiYXNpcyB0byBh DQogICBkZXRlcm1pbmlzdGljLCBzdGF0ZSBkcml2ZW4gYmFzaXMgd2hpY2ggcmVzcG9uZHMgcmFw aWRseSB0byBsaW5rDQogICBjb25kaXRpb25zLg0KDQoNCg0KDQpTYWJhdGluaSwgQW50aG9ueSAg ICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE0LCAyMDEzICAgICAgICAgICAgICAgW1BhZ2UgMl0NCg0K DQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgSGlnaCBFZmZpY2llbmN5IFNBQ0sgZm9yIFRD UCAgICAgICBBdWd1c3QgMTUsIDIwMTINCg0KDQogICBJIHByb3Bvc2UgbW9kaWZpY2F0aW9ucyB0 byB0aGUgU0FDSyBvcHRpb25zIGFzIHByb3Bvc2VkIGluIFJGQzIwMTguDQogICBTcGVjaWZpY2Fs bHksIEkgYWRkIGEgdHJhbnNtaXQgc3RhdGUgdG8gZWFjaCB0cmFuc21pdHRlZCBtZXNzYWdlIGFu ZA0KICAgcmV0dXJuIHRoYXQgdHJhbnNtaXQgc3RhdGUgd2hlbiBlYWNoIGFja25vd2xlZGdlbWVu dCBpcyBzZW50LiAgQnkNCiAgIHVzaW5nIHRoZSByZXR1cm5lZCB0cmFuc21pdCBzdGF0ZSBJIGNh biB0ZWxsIHdoYXQgbWVzc2FnZXMgaGF2ZSBiZWVuDQogICB0cmFuc21pdHRlZCBhZnRlciB0aGUg aW5mb3JtYXRpb24gaW4gdGhlIGFja25vd2xlZGdlbWVudCBhbmQgdGh1cw0KICAgcmVidWlsZCB0 aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUgcmVjZWl2ZXIgYXQgdGhlIHRyYW5zbWl0dGVyLiAgSSBh bHNvDQogICBwcm9wb3NlIGNoYW5nZXMgdG8gdGhlIHdheSBTQUNLIGJsb2NrcyBhcmUgcmVwb3J0 ZWQgdG8gaW5zdXJlIHRoYXQNCiAgIHRoZSBvbGRlc3QsIGFuZCB0aHVzIHRoZSBtb3N0IGNyaXRp Y2FsLCBhcmUgdHJhbnNtaXR0ZWQgZXhwZWRpdGlvdXNseQ0KICAgd2l0aG91dCBqZW9wYXJkaXpp bmcgdGhlIG11bHRpcGxlIHJlcGV0aXRpb24gb2YgU0FDSyBpbmZvcm1hdGlvbg0KICAgd2hpY2gg Z2l2ZXMgdGhlIGN1cnJlbnQgcHJvdG9jb2wgaXRzIHJlbGlhYmlsaXR5LiAgQWRkaXRpb25hbGx5 IHNpbmNlDQogICB0aGUgc3BhY2UgdG8gc3RvcmUgYWNrbm93bGVkZ2VtZW50cyBpbiBJUHY0IGlz IGxpbWl0ZWQgYW5kIG1heSBub3QgYmUNCiAgIGFibGUgdG8gYWNjb21tb2RhdGUgYWxsIG9mIHRo ZSBhY2tub3dsZWRnZW1lbnQgcGFpcnMsIEkgcHJvcG9zZSBhDQogICBtZXRob2Qgb2Ygc2VuZGlu ZyB0aGUgY29tcGxldGUgcmVjZWl2ZXIgc3RhdGUgYnkgc2VuZGluZyBtdWx0aXBsZQ0KICAgYWNr bm93bGVkZ2VtZW50cyB3aGVuIGl0IGJlY29tZXMgZXZpZGVudCB0aGF0IHRyYW5zbWlzc2lvbiBo YXMNCiAgIHN0YWxsZWQgZHVlIHRvIGxvc3Mgb2YgbXVsdGlwbGUgQUNLcy4NCg0KICAgVGhlIFJG QzIwMTggc2VsZWN0aXZlIGFja25vd2xlZGdtZW50IGV4dGVuc2lvbiB1c2VzIHR3byBUQ1Agb3B0 aW9ucy4NCiAgIFRoZSBmaXJzdCBpcyBhbiBlbmFibGluZyBvcHRpb24sICJTQUNLLXBlcm1pdHRl ZCIsIHdoaWNoIG1heSBiZSBzZW50DQogICBpbiBhIFNZTiBzZWdtZW50IHRvIGluZGljYXRlIHRo YXQgdGhlIFNBQ0sgb3B0aW9uIGNhbiBiZSB1c2VkIG9uY2UNCiAgIHRoZSBjb25uZWN0aW9uIGlz IGVzdGFibGlzaGVkLiAgVGhpcyBvcHRpb24gaXMgZXh0ZW5kZWQgdG8gYm90aA0KICAgaW5kaWNh dGUgdGhhdCB0aGlzIG5ld2VyIHZlcnNpb24gb2YgdGhlIHByb3RvY29sIGlzIGJlaW5nIHVzZWQg YW5kIHRvDQogICBlc3RhYmxpc2ggYW4gaW5pdGlhbCB2YWx1ZSBmb3IgdHJhbnNtaXQgc3RhdGUu ICBUaGUgb3RoZXIgaXMgdGhlIFNBQ0sNCiAgIG9wdGlvbiBpdHNlbGYsIHdoaWNoIG1heSBiZSBz ZW50IG92ZXIgYW4gZXN0YWJsaXNoZWQgY29ubmVjdGlvbiBvbmNlDQogICBwZXJtaXNzaW9uIGhh cyBiZWVuIGdpdmVuIGJ5IFNBQ0stcGVybWl0dGVkLiAgVGhpcyBoYXMgYWxzbyBiZWVuDQogICBl eHRlbmRlZCB0byBhZGQgYm90aCB0aGUgdHJhbnNtaXQgc3RhdGUgaW1wbGljaXQgaW4gdGhlIG1l c3NhZ2UgYW5kDQogICB0aGUgdHJhbnNtaXQgc3RhdGUgdGhhdCB3YXMgcmVjZWl2ZWQgYXQgdGhl IGZhciBlbmQgKG5vdyBjYWxsZWQNCiAgICJSZXR1cm5lZCBTdGF0ZSIpLg0KDQogICBUaGUgU0FD SyBvcHRpb24gaXMgdG8gYmUgaW5jbHVkZWQgaW4gYSBzZWdtZW50IHNlbnQgZnJvbSBhIFRDUCB0 aGF0DQogICBpcyByZWNlaXZpbmcgZGF0YSB0byB0aGUgVENQIHRoYXQgaXMgc2VuZGluZyB0aGF0 IGRhdGE7IHdlIHdpbGwgcmVmZXINCiAgIHRvIHRoZXNlIFRDUCdzIGFzIHRoZSBkYXRhIHJlY2Vp dmVyIGFuZCB0aGUgZGF0YSBzZW5kZXIsDQogICByZXNwZWN0aXZlbHkuICBXZSB3aWxsIGNvbnNp ZGVyIGEgcGFydGljdWxhciBzaW1wbGV4IGRhdGEgZmxvdzsgYW55DQogICBkYXRhIGZsb3dpbmcg aW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uIG92ZXIgdGhlIHNhbWUgY29ubmVjdGlvbiBjYW4gYmUN CiAgIHRyZWF0ZWQgaW5kZXBlbmRlbnRseS4NCg0KMi4gIFVuZGVybHlpbmcgY29uY2VwdHMNCg0K ICAgSW4gb3JkZXIgZm9yIGEgc2VuZGVyIHRvIGtub3cgaG93IHRvIG9wdGltYWxseSB0cmFuc21p dCBtZXNzYWdlcyB0byBhDQogICByZWNlaXZlciB0aGUgc2VuZGVyIG11c3QgcmVjcmVhdGUgdGhl IHN0YXRlIG9mIHRoZSByZWNlaXZlciBhcyBvZiB0aGUNCiAgIGxhc3QgYWNrbm93bGVkZ2VtZW50 IHJlY2VpdmVkICh3aGljaCBzZWdtZW50cyBoYXZlIGJlZW4gcmVjZWl2ZWQgYW5kDQogICBhY2tu b3dsZWRnZWQsIHdoaWNoIHNlZ21lbnRzIGhhdmUgbm90KSBhbmQgdGhlbiAiYWdlIiBvciBtb2Rp ZnkgdGhhdA0KICAgc3RhdGUgYnkgdXBkYXRpbmcgaXQgYmFzZWQgdXBvbiB0aGUgbWVzc2FnZXMg dHJhbnNtaXR0ZWQgc2luY2UgdGhlDQogICBzdGF0ZSBpbXBsaWNpdCBpbiB0aGUgYWNrbm93bGVk Z2VtZW50IHdhcyBjdXJyZW50LiAgSW4gb3JkZXIgdG8gZG8NCiAgIHRoaXMgdGhlIHNlbmRlciBt dXN0IG1haW50YWluIGEgdHJhbnNtaXNzaW9uIG9yZGVyIGxpc3Qgd2hpY2gNCiAgIGNvbnRhaW5z IGVudHJpZXMgZm9yIHRoZSBzZWdtZW50IHJhbmdlcyBvZiBlYWNoIG1lc3NhZ2UgYXMgaXQgaXMN CiAgIHNlbnQuICBXZSBjYWxsZWQgdGhlIGluZGV4IGludG8gdGhlIHRyYW5zbWlzc2lvbiBvcmRl ciBsaXN0ICJTZW5kDQogICBTdGF0ZSIgYW5kIHRyYW5zbWl0IHRoaXMgc3RhdGUgdmFyaWFibGUg d2l0aCBlYWNoIG1lc3NhZ2UuICBUaGUNCiAgIHJlY2VpdmVyLCBhZnRlciBjb3JyZWN0bHkgcmVj ZWl2aW5nIHRoZSBtZXNzYWdlLCBzYXZlcyB0aGlzIHZhbHVlIGFuZA0KDQoNCg0KU2FiYXRpbmks IEFudGhvbnkgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNCwgMjAxMyAgICAgICAgICAgICAgIFtQ YWdlIDNdDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgIEhpZ2ggRWZmaWNpZW5jeSBT QUNLIGZvciBUQ1AgICAgICAgQXVndXN0IDE1LCAyMDEyDQoNCg0KICAgcmV0dXJucyBpdCAobm93 IGNhbGxlZCAiUmV0dXJuZWQgU3RhdGUiKSBhbmQgdGhlIGxpc3Qgb2Ygc2VsZWN0aXZlbHkNCiAg IGFja25vd2xlZGdlZCBzZWdtZW50cyB3aXRoIGVhY2ggYWNrbm93bGVkZ2VtZW50LiAgV2hlbiB0 aGUgc2VuZGVyDQogICByZWNlaXZlcyB0aGlzIGluZm9ybWF0aW9uIGl0IGlzIHRoZW4gY2FwYWJs ZSBvZiBjb25zdHJ1Y3RpbmcgYSBsaXN0DQogICBvZiBtaXNzaW5nIHNlZ21lbnRzIGJ5IHRha2lu ZyBpdHMgdW5hY2tub3dsZWRnZWQgc2VnbWVudCByYW5nZSBsaXN0DQogICBhbmQgbW9kaWZ5aW5n IGl0IG9uIHRoZSBiYXNpcyBvZiB0aGUgcmVjZWl2ZWQgc2VsZWN0aXZlDQogICBhY2tub3dsZWRn ZW1lbnRzIGFuZCB0aGVuIHJlbW92aW5nIGZyb20gdGhhdCBsaXN0IGFsbCBzZWdtZW50cyB0aGF0 DQogICBoYXZlIGJlZW4gdHJhbnNtaXR0ZWQgc2luY2UgdGhlIG1lc3NhZ2Ugd2hpY2ggY2F1c2Vk IHRoZQ0KICAgYWNrbm93bGVkZ2VtZW50IHdoaWNoIGlzIGFsbCBzZWdtZW50cyBzZW50IHdpdGgg aW5kZXhlcyBiZXR3ZWVuIHRoZQ0KICAgY3VycmVudCAic2VuZCBzdGF0ZSIgYW5kIHRoZSAicmVj ZWl2ZSBzdGF0ZSIgaW4gdGhlIGFja25vd2xlZGdlbWVudA0KICAgbWVzc2FnZS4NCg0KICAgVG8g YWNjb21tb2RhdGUgdGhlIGlzc3VlIG9mIHJlY2VpdmluZyBzZWdtZW50cyBvdXQgb2Ygb3JkZXIg YXQgdGhlDQogICByZWNlaXZlciwgb3IgdGhvc2UgcGFja2V0cyBkZWxheWVkIGJ5IGFsdGVybmF0 ZSByb3V0aW5nLCB0aGUgc2VuZGVyDQogICBkb2VzIG5vdCBpbnN0YW50bHkgdXBkYXRlIGl0cyBD dXJyZW50IFJldHVybmVkIFN0YXRlIHZhbHVlIGZyb20gdGhlDQogICBpbmNvbWluZyBBQ0sgKHdo aWNoIGNvdWxkIHRyaWdnZXIgYSBmYWxzZSByZXRyYW5zbWlzc2lvbikgYnV0IHJhdGhlcg0KICAg cHV0cyBpdCBvbiBhIHRpbWVyIHF1ZXVlIGZvciBhIGxlbmd0aCBvZiB0aW1lICgiUmVvcmRlcmlu ZyBUaW1lIikNCiAgIGFwcHJvcHJpYXRlIHRvIHRoZSBkZWxheSByYW5kb21uZXNzIGluIHRoZSBh cnJpdmFsIHBhdGggKHR5cGljYWxseSAyMA0KICAgdG8gMTAwIG1zIGJhc2VkIG9uIG1lZGlhLCBz cGVlZCBhbmQgZGlzdGFuY2UpLCB3aGljaCB3aGVuIHRoZSB0aW1lcg0KICAgZW50cnkgZXhwaXJl cywgY2F1c2VzIHRoZSB1cGRhdGUgb2YgdGhlIEN1cnJlbnQgUmV0dXJuZWQgU3RhdGUgdmFsdWUu DQogICBJZiB0aGUgdXBkYXRlZCBDdXJyZW50IFJldHVybmVkIFN0YXRlIHZhbHVlIHNob3dzIGJs b2NrcyB0aGF0IHJlbWFpbg0KICAgdW5hY2tub3dsZWRnZWQgYWZ0ZXIgdGhpcyB0aW1lIG91dCB0 aGV5IGFyZSBhc3N1bWVkIHRvIGJlIGxvc3QgYW5kDQogICB0aGV5IGFyZSBxdWV1ZWQgZm9yIHJl dHJhbnNtaXNzaW9uLg0KDQogICBUaHVzIGJ5IHRyYW5zbWl0dGluZyB0aGUgY29tcGxldGUgYWNr bm93bGVkZ2VtZW50IGluZm9ybWF0aW9uIHRocm91Z2gNCiAgIHRoZSBTQUNLIGJsb2NrcyBmcm9t IHRoZSByZWNlaXZlciBhbG9uZyB3aXRoIGFuIGluZGljYXRvciB0byB0aGUNCiAgIHNlbmRlciBh cyB0byBpdHMgc3RhdGUgY3VycmVudCBhdCB0aGUgdGltZSBvZiB0aGUgYWNrbm93bGVkZ2VtZW50 IHRoZQ0KICAgc2VuZGVyIGNhbiBhY2N1cmF0ZWx5IHJlY3JlYXRlIHRoZSBjdXJyZW50IHN0YXR1 cyBvZiB0aGUgcmVjZWl2ZXINCiAgIGFzc3VtaW5nIGFsbCAiaW4gZmxpZ2h0IiBtZXNzYWdlcyB3 ZXJlIHJlY2VpdmVkIGFuZCB0aHVzIG9ubHkgc2VuZA0KICAgdGhlIHVuYWNrbm93bGVkZ2VkIG1l c3NhZ2VzIHN0YXJ0aW5nIHdpdGggdGhlIG9sZGVzdCBmb2xsb3dlZCBieSBhbnkNCiAgIG5ldyBt ZXNzYWdlcyB3aG9zZSB0cmFuc21pc3Npb24gaXMgcmVxdWVzdGVkLg0KDQozLiBFbmhhbmNlZCBT YWNrLVBlcm1pdHRlZCBPcHRpb24NCg0KICAgVGhpcyBkb2N1bWVudCBpcyBkZXNpZ25lZCB0byBi ZSBhbiBleHRlbnNpb24gb2YgUkZDMjAxOCBhbmQgYW55DQogICBpbXBsZW1lbnRhdGlvbiBvZiBp dCBtdXN0IGJlIGRlc2lnbmVkIHRvIGZhbGwgYmFjayB0byBoYW5kbGluZw0KICAgUkZDMjAxOCB3 aGVuIGhlIG90aGVyIHBhdHkgaXMgbm90IGNhcGFibGUgb2YgaGFuZGxpbmcgdGhlIGVuaGFuY2Vk DQogICBwcm90b2NvbC4NCg0KICAgQWx0aG91Z2ggRW5oYW5jZWQgU0FDSyBpcyBhIGNvbXBhdGli bGUgZXh0ZW5zaW9uIG9mIHN0YW5kYXJkIFNBQ0sgaXQNCiAgIGlzIHJlY29nbml6ZWQgdGhhdCBj ZXJ0YWluIG1pZGRsZXdhcmUgYm94ZXMgYXJlIG5vdCBSRkMgY29tcGxpYW50IGFzDQogICB0byBl eHRlbnNpb25zIGFuZCB0aGVyZWZvcmUgd2lsbCBmYWlsIGlmLCBhcyB3b3VsZCBwcm9wZXJseSBi ZSBkb25lLA0KICAgRW5oYW5jZWQgU0FDSyB3YXMgaGFuZGxlZCBhcyBzdWNoLiAgVGhlcmVmb3Jl IEVuaGFuY2VkIFNBQ0sgaXMNCiAgIHRyYW5zbWl0dGVkIGFzIHR3byBvcHRpb25zIGJvdGggaW4g dGhlIFNZTiBwYWNrZXRzIGFzIHdlbGwgYXMgZGF0YQ0KICAgYW5kIEFDSyBwYWNrZXRzLg0KDQog ICBUaGUgZmlyc3Qgb3B0aW9uIG9mIHRoZSBwYWlyIE1VU1QgYmUgdGhlIHN0YW5kYXJkIFNBQ0sg b3B0aW9uIChLaW5kID0NCiAgIDQpIGlmIHRoaXMgZW5kcG9pbnQgZGVzaXJlcyBhIFNBQ0sgc2Vz c2lvbiBvZiBhbnkga2luZC4gIFRoZSBzZWNvbmQNCiAgIGZvdXIgb3Igc2l4IGJ5dGUgb3B0aW9u IG1heSBiZSBzZW50IGluIGEgU1lOIGJ5IGEgVENQIHRoYXQgaGFzIGJlZW4NCg0KDQoNClNhYmF0 aW5pLCBBbnRob255ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTQsIDIwMTMgICAgICAgICAgICAg ICBbUGFnZSA0XQ0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICBIaWdoIEVmZmljaWVu Y3kgU0FDSyBmb3IgVENQICAgICAgIEF1Z3VzdCAxNSwgMjAxMg0KDQoNCiAgIGV4dGVuZGVkIHRv IHJlY2VpdmUgKGFuZCBwcmVzdW1hYmx5IHByb2Nlc3MpIHRoZSBFbmhhbmNlZCBTQUNLIG9wdGlv bg0KICAgaW4gb3JkZXIgdG8gaW5kaWNhdGUgaXRzIHdpbGxpbmduZXNzIHRvIGVudGVyIGludG8g YW4gRW5oYW5jZWQgU0FDSw0KICAgc2Vzc2lvbi4NCg0KICAgVGhpcyBvcHRpb24gTVVTVCBOT1Qg YmUgdHJhbnNtaXR0ZWQgb24gbm9uLVNZTiBzZWdtZW50cyBpbiB0aGUNCiAgIGN1cnJlbnQgcHJv dG9jb2wsIGl0IGlzIGxlZnQgdG8gZnV0dXJlIHN0dWR5IGFzIHRvIGl0cyB1c2UgZm9yDQogICB0 cmFuc21pdHRpbmcgbG9uZyBzZXF1ZW5jZXMgb2YgYWNrbm93bGVkZ2VtZW50cyBpbiBvbmUgZnJh bWUuDQoNCiAgICAgICBUQ1AgU0FDSy1QZXJtaXR0ZWQgT3B0aW9uOg0KDQogICAgICAgS2luZDog NA0KDQogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAgMw0KICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBLaW5kPTQgICAgICAgIHwgTGVuZ3RoPTIg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KDQogICAgICAgVENQIEVuaGFuY2VkIFNBQ0sgU2V0dXAg T3B0aW9uOg0KDQogICAgICAgS2luZDogWDENCg0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwgICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfFB8UnxQfFJ8ICAgICAgICAgICAgICAgICAgICAg ICB8DQogICAgICB8IEtpbmQ9WDEgICAgICAgfCBMZW5ndGg9NiBvciA4IHxUfFR8WHxYfCBSZXNl cnZlZCAgICAgICAgICAgICAgfA0KICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICB8T3xPfFR8VHwgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAg ICBpZiBSWFQgPSAwIG5vdCByZXF1ZXN0aW5nIGV4dGVuZGVkIHN0YXRlDQogICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwgU2VuZCBTdGF0ZSBUb2tlbiAgICAg ICAgICAgICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAg ICBpZiBSWFQgPSAxIHJlcXVlc3RpbmcgZXh0ZW5kZWQgc3RhdGUNCiAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICAgICB8IEV4dGVuZGVkIFNlbmQgU3RhdGUgVG9rZW4gICAgICAgICAgICAgICAgICAgICB8IFJl c2VydmVkICAgICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KDQogICBDb250cm9sIEJpdHM6IDQgYml0 cyAoZnJvbSBsZWZ0IHRvIHJpZ2h0KToNCg0KICAgICAgIFBUTzogIFRva2VucyBQZXJtaXR0ZWQs IHRoZSBzZW5kZXIgc3VwcG9ydHMgdGhlIHJlcXVpcmVtZW50cyBvZg0KICAgICAgIHRoaXMgZXh0 ZW5zaW9uDQoNCiAgICAgICBSVE86ICBSZXF1ZXN0IFRva2Vucywgc2VuZGVyIHJlcXVlc3RzIGxp bmsgdXNlIHRoZSBwcm90b2NvbA0KICAgICAgIG91dGxpbmVkIGluIHRoaXMgZXh0ZW5zaW9uDQoN CiAgICAgICBQWFQ6ICBFeHRlbmRlZCBUb2tlbnMgU3VwcG9ydGVkDQoNCiAgICAgICBSWFQ6ICBS ZXF1ZXN0IEV4dGVuZGVkIFRva2Vuczogc2VuZGVyIHJlcXVlc3RzIHVzaW5nIGV4dGVuZGVkDQoN Cg0KDQpTYWJhdGluaSwgQW50aG9ueSAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE0LCAyMDEzICAg ICAgICAgICAgICAgW1BhZ2UgNV0NCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgSGln aCBFZmZpY2llbmN5IFNBQ0sgZm9yIFRDUCAgICAgICBBdWd1c3QgMTUsIDIwMTINCg0KDQogICAg ICAgdG9rZW5zLg0KDQogICBSZXNlcnZlZDogMTIgYml0cw0KDQogICAgICAgUmVzZXJ2ZWQgZm9y IGZ1dHVyZSB1c2UsIG11c3QgYmUgc2V0IHRvIHplcm8NCg0KICAgSWYgUlRPIGlzIHNldCB0aGVu IHRoZSBTZW5kIFN0YXRlIGltbWVkaWF0ZWx5IGZvbGxvd3MsIDE2IGJpdHMgaWYgUlhUDQogICBp cyBub3Qgc2V0IGFuZCAyNCBiaXRzIGlmIGl0IGlzLiAgSWYgbmVjZXNzYXJ5IHRoZSBvcHRpb24g aXMgcGFkZGVkDQogICB3aXRoIGEgYmluYXJ5IHplcm8gYnl0ZSBzbyB0aGF0IGxlbmd0aCBpcyBh biBldmVuIG51bWJlci4gIEluIHRoZQ0KICAgY2FzZSB0aGF0IG9uZSBlbmQgY2FuIG9ubHkgc3Vw cG9ydCAxNiBiaXQgdG9rZW5zIG9ubHkgdGhlIHJpZ2h0IG1vc3QNCiAgIDE2IGJpdHMgb2YgdGhl IGV4dGVuZGVkIGZpZWxkIGlzIHVzZWQuDQoNCiAgIEZvciBicmV2aXR5IGluIHRoaXMgZG9jdW1l bnQgb25seSB0aGUgbGVzc2VyLCAxNiBiaXQgZm9ybWF0IGlzIHNob3duLg0KDQo0LiBTQUNLIE9w dGlvbiBGb3JtYXQNCg0KICAgQXMgd2l0aCB0aGUgU1lOIG9wdGlvbnMsIEVuaGFuY2VkIFNBQ0sg aW5mb3JtYXRpb24gbXVzdCBiZQ0KICAgdHJhbnNtaXR0ZWQgYXMgYSBzZXBlcmF0ZSBvcHRpb24g aW4gb3JkZXIgdG8gYWNjb21vZGF0ZSBub24gUkZDDQogICBjb21wbGlhbnQgbWlkZGxld2FyZSBi b3hlcy4gIEJ5IGl0cyBuYXR1cmUgaXQgbXVzdCBwcmVjZWRlIHRoZSBUQ1ANCiAgIFNBQ0sgT3B0 aW9uLg0KDQogICAgICAgVENQIEVuaGFuY2VkIFNBQ0sgT3B0aW9uOg0KDQogICAgICAgS2luZDog WDINCg0KICAgICAgIExlbmd0aDogNiAob3IgOCBpZiBleHRlbmRlZCB0b2tlbikNCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSstLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAg ICAgICAgICB8IEtpbmQ9WDIgfCBMZW49NiB8DQogICAgICAgKy0tLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tKy0tLS0tLS0tKw0KICAgICAgIHwgU2VuZCBTdGF0ZSAgICAgIHwgUmV0dXJuZWQgU3Rh dGUgIHwNCiAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0rDQoNCg0K ICAgICAgIFRDUCBTQUNLIE9wdGlvbjoNCg0KICAgICAgIEtpbmQ6IDUNCg0KICAgICAgIExlbmd0 aDogVmFyaWFibGUNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSstLS0tLS0t LSsNCiAgICAgICAgICAgICAgICAgICAgICAgICB8IEtpbmQ9NSB8IExlbmd0aCB8DQogICAgICAg Ky0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tKw0KICAgICAgIHwgICAgICBMZWZ0 IEVkZ2Ugb2YgMXN0IEJsb2NrICAgICAgIHwNCiAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0rLS0t LS0tLS0rLS0tLS0tLS0rDQogICAgICAgfCAgICAgIFJpZ2h0IEVkZ2Ugb2YgMXN0IEJsb2NrICAg ICAgfA0KICAgICAgICstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSsNCiAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCg0KDQpTYWJhdGluaSwg QW50aG9ueSAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE0LCAyMDEzICAgICAgICAgICAgICAgW1Bh Z2UgNl0NCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgSGlnaCBFZmZpY2llbmN5IFNB Q0sgZm9yIFRDUCAgICAgICBBdWd1c3QgMTUsIDIwMTINCg0KDQogICAgICAgLyAgICAgICAgICAg IC4gLiAuICAgICAgICAgICAgICAgICAgLw0KICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCiAgICAgICArLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0t LS0rDQogICAgICAgfCAgICAgIExlZnQgRWRnZSBvZiBudGggQmxvY2sgICAgICAgfA0KICAgICAg ICstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSstLS0tLS0tLSsNCiAgICAgICB8ICAgICAgUmln aHQgRWRnZSBvZiBudGggQmxvY2sgICAgICB8DQogICAgICAgKy0tLS0tLS0tKy0tLS0tLS0tKy0t LS0tLS0tKy0tLS0tLS0tKw0KDQogICBUaGUgU0FDSyBvcHRpb24gaXMgdG8gYmUgc2VudCBieSBh IGRhdGEgcmVjZWl2ZXIgdG8gaW5mb3JtIHRoZSBkYXRhDQogICBzZW5kZXIgb2Ygbm9uLWNvbnRp Z3VvdXMgYmxvY2tzIG9mIGRhdGEgdGhhdCBoYXZlIGJlZW4gcmVjZWl2ZWQgYW5kDQogICBxdWV1 ZWQuICBUaGUgZGF0YSByZWNlaXZlciBhd2FpdHMgdGhlIHJlY2VpcHQgb2YgZGF0YSAocGVyaGFw cyBieQ0KICAgbWVhbnMgb2YgcmV0cmFuc21pc3Npb25zKSB0byBmaWxsIHRoZSBnYXBzIGluIHNl cXVlbmNlIHNwYWNlIGJldHdlZW4NCiAgIHJlY2VpdmVkIGJsb2Nrcy4gIFdoZW4gbWlzc2luZyBz ZWdtZW50cyBhcmUgcmVjZWl2ZWQsIHRoZSBkYXRhDQogICByZWNlaXZlciBhY2tub3dsZWRnZXMg dGhlIGRhdGEgbm9ybWFsbHkgYnkgYWR2YW5jaW5nIHRoZSBsZWZ0IHdpbmRvdw0KICAgZWRnZSBp biB0aGUgQWNrbm93bGVkZ2VtZW50IE51bWJlciBGaWVsZCBvZiB0aGUgVENQIGhlYWRlci4gIFRo ZSBTQUNLDQogICBvcHRpb24gZG9lcyBub3QgY2hhbmdlIHRoZSBtZWFuaW5nIG9yIHVzZSBvZiB0 aGUgQWNrbm93bGVkZ2VtZW50DQogICBOdW1iZXIgZmllbGQuDQoNCiAgIFRoaXMgb3B0aW9uIGNv bnRhaW5zIGEgbGlzdCBvZiBzb21lIG9mIHRoZSBibG9ja3Mgb2YgY29udGlndW91cw0KICAgc2Vx dWVuY2Ugc3BhY2Ugb2NjdXBpZWQgYnkgZGF0YSB0aGF0IGhhcyBiZWVuIHJlY2VpdmVkIGFuZCBx dWV1ZWQNCiAgIHdpdGhpbiB0aGUgd2luZG93Lg0KDQogICBFYWNoIGNvbnRpZ3VvdXMgYmxvY2sg b2YgZGF0YSBxdWV1ZWQgYXQgdGhlIGRhdGEgcmVjZWl2ZXIgaXMgZGVmaW5lZA0KICAgaW4gdGhl IFNBQ0sgb3B0aW9uIGJ5IHR3byAzMi1iaXQgdW5zaWduZWQgaW50ZWdlcnMgaW4gbmV0d29yayBi eXRlDQogICBvcmRlcjoNCg0KICAgKiAgICBMZWZ0IEVkZ2Ugb2YgQmxvY2sNCg0KICAgICAgICBU aGlzIGlzIHRoZSBmaXJzdCBzZXF1ZW5jZSBudW1iZXIgb2YgdGhpcyBibG9jay4NCg0KICAgKiAg ICBSaWdodCBFZGdlIG9mIEJsb2NrDQoNCiAgICAgICAgVGhpcyBpcyB0aGUgc2VxdWVuY2UgbnVt YmVyIGltbWVkaWF0ZWx5IGZvbGxvd2luZyB0aGUgbGFzdA0KICAgc2VxdWVuY2UgbnVtYmVyIG9m IHRoaXMgYmxvY2suDQoNCiAgIEVhY2ggYmxvY2sgcmVwcmVzZW50cyByZWNlaXZlZCBieXRlcyBv ZiBkYXRhIHRoYXQgYXJlIGNvbnRpZ3VvdXMgYW5kDQogICBpc29sYXRlZDsgdGhhdCBpcywgdGhl IGJ5dGVzIGp1c3QgYmVsb3cgdGhlIGJsb2NrLCAoTGVmdCBFZGdlIG9mDQogICBCbG9jayAtIDEp LCBhbmQganVzdCBhYm92ZSB0aGUgYmxvY2ssIChSaWdodCBFZGdlIG9mIEJsb2NrKSwgaGF2ZSBu b3QNCiAgIGJlZW4gcmVjZWl2ZWQuDQoNCiAgIEEgU0FDSyBvcHRpb24gdGhhdCBzcGVjaWZpZXMg biBibG9ja3Mgd2lsbCBoYXZlIGEgbGVuZ3RoIG9mIDgqbis2DQogICBieXRlcywgc28gdGhlIDQw IGJ5dGVzIGF2YWlsYWJsZSBmb3IgVENQIG9wdGlvbnMgY2FuIHNwZWNpZnkgYQ0KICAgbWF4aW11 bSBvZiA0IGJsb2Nrcy4gIEl0IGlzIHN1Z2dlc3RlZCB0aGF0IHRoZSBFbmhhbmNlZCBTQUNLIHdp bGwNCiAgIHByb3ZpZGUgdGhlIHRpbWUtc3RhbXAgaW5mb3JtYXRpb24gdXNlZCBmb3IgUlRUTSBb SmFjb2Jzb245Ml0uDQoNCjUuICBHZW5lcmF0aW5nIFNhY2sgT3B0aW9uczogRGF0YSBSZWNlaXZl ciBCZWhhdmlvcg0KDQogICBJZiB0aGUgZGF0YSByZWNlaXZlciBoYXMgcmVjZWl2ZWQgYSBTQUNL LVBlcm1pdHRlZCBvcHRpb24gb24gdGhlIFNZTg0KDQoNCg0KU2FiYXRpbmksIEFudGhvbnkgICAg ICAgRXhwaXJlcyBGZWJydWFyeSAxNCwgMjAxMyAgICAgICAgICAgICAgIFtQYWdlIDddDQoNCg0K DQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgIEhpZ2ggRWZmaWNpZW5jeSBTQUNLIGZvciBUQ1Ag ICAgICAgQXVndXN0IDE1LCAyMDEyDQoNCg0KICAgZm9yIHRoaXMgY29ubmVjdGlvbiwgdGhlIGRh dGEgcmVjZWl2ZXIgTUFZIGVsZWN0IHRvIGdlbmVyYXRlIFNBQ0sNCiAgIG9wdGlvbnMgYXMgZGVz Y3JpYmVkIGJlbG93LiAgSWYgdGhlIGRhdGEgcmVjZWl2ZXIgZ2VuZXJhdGVzIFNBQ0sNCiAgIG9w dGlvbnMgdW5kZXIgYW55IGNpcmN1bXN0YW5jZSwgaXQgTVVTVCBnZW5lcmF0ZSB0aGVtIHVuZGVy IGFsbA0KICAgcGVybWl0dGVkIGNpcmN1bXN0YW5jZXMuICBJZiB0aGUgZGF0YSByZWNlaXZlciBo YXMgbm90IHJlY2VpdmVkIGENCiAgIFNBQ0stUGVybWl0dGVkIG9wdGlvbiBmb3IgYSBnaXZlbiBj b25uZWN0aW9uLCBpdCBNVVNUIE5PVCBzZW5kIFNBQ0sNCiAgIG9wdGlvbnMgb24gdGhhdCBjb25u ZWN0aW9uLg0KDQogICBJZiBzZW50IGF0IGFsbCwgU0FDSyBvcHRpb25zIE1VU1QgYmUgaW5jbHVk ZWQgaW4gYWxsIEFDS3Mgd2hpY2ggZG8NCiAgIG5vdCBBQ0sgdGhlIGhpZ2hlc3Qgc2VxdWVuY2Ug bnVtYmVyIGluIHRoZSBkYXRhIHJlY2VpdmVyJ3MgcXVldWUuICBJbg0KICAgdGhpcyBzaXR1YXRp b24gdGhlIG5ldHdvcmsgaGFzIGxvc3Qgb3IgbWlzLW9yZGVyZWQgZGF0YSwgc3VjaCB0aGF0DQog ICB0aGUgcmVjZWl2ZXIgaG9sZHMgbm9uLWNvbnRpZ3VvdXMgZGF0YSBpbiBpdHMgcXVldWUuICBS RkMgMTEyMiwNCiAgIFNlY3Rpb24gNC4yLjIuMjEsIGRpc2N1c3NlcyB0aGUgcmVhc29ucyBmb3Ig dGhlIHJlY2VpdmVyIHRvIHNlbmQgQUNLcw0KICAgaW4gcmVzcG9uc2UgdG8gYWRkaXRpb25hbCBz ZWdtZW50cyByZWNlaXZlZCBpbiB0aGlzIHN0YXRlLiAgVGhlDQogICByZWNlaXZlciBNVVNUIHNl bmQgYW4gQUNLIGZvciBldmVyeSB2YWxpZCBzZWdtZW50IHRoYXQgYXJyaXZlcw0KICAgY29udGFp bmluZyBuZXcgZGF0YSwgYW5kIGVhY2ggb2YgdGhlc2UgImR1cGxpY2F0ZSIgQUNLcyBTSE9VTEQg YmVhciBhDQogICBTQUNLIG9wdGlvbi4NCg0KICAgVGhlIHB1cnBvc2Ugb2YgdGhlIFNBQ0sgYmxv Y2tzIGlzIHRvIHJlY3JlYXRlIHRoZSBzdGF0dXMgb2YgdGhlDQogICByZWNlaXZlciBhdCB0aGUg dHJhbnNtaXR0ZXIuICBUbyB0aGF0IGVuZCB0aGUgbW9zdCBpbXBvcnRhbnQNCiAgIGluZm9ybWF0 aW9uIGlzICgxKSBuZXcgb3IgY2hhbmdlZCBibG9ja3MsICgyKSB0aGUgc2Vjb25kIHRyYW5zbWlz c2lvbg0KICAgb2YgbmV3IG9yIGNoYW5nZWQgYmxvY2tzLCAoMykgYSBjb21wbGV0ZSBlbnVtZXJh dGlvbiBvZiBhbGwgcmVjZWl2ZWQNCiAgIGJsb2NrcyBzdGFydGluZyBmcm9tIHRoZSBvbGRlc3Qg Zmlyc3QuDQoNCiAgIElmIHRoZSBkYXRhIHJlY2VpdmVyIGNob29zZXMgdG8gc2VuZCBhIFNBQ0sg b3B0aW9uLCB0aGUgZm9sbG93aW5nDQogICBydWxlcyBhcHBseToNCg0KICAgICAgKiBUaGUgZGF0 YSByZWNlaXZlciBmaXJzdCBmaWxscyBpbiAiU2VuZCBTdGF0ZSIgaW4gdGhlIG9wdGlvbiBmcm9t DQogICAgICB0aGUgY3VycmVudCB2YWx1ZSBvZiBpdHMgIlNlbmQgU3RhdGUiLiAgVGhlIGRhdGEg cmVjZWl2ZXIgdGhlbg0KICAgICAgZmlsbHMgaW4gIlJldHVybmVkIFN0YXRlIiBmcm9tIGl0cyAi U2F2ZWQgU2VuZCBTdGF0ZSIgd2hpY2ggd2FzDQogICAgICBzZXQgYnkgZWl0aGVyIHRoZSBTWU4g b3B0aW9uIG9yIHRoZSBTQUNLIG9wdGlvbiBvZiB0aGUgbGFzdCBUQ1ANCiAgICAgIHBhY2tldCB0 aGF0IGNvbnRhaW5lZCBhIHZhbHVlIHdoaWNoIHdhcyBsb2dpY2FsbHkgZ3JlYXRlciB0aGFuIHRo ZQ0KICAgICAgY3VycmVudCBzYXZlZCB2YWx1ZS4NCg0KICAgICAgKiBTQUNLIGJsb2NrcyByZXBy ZXNlbnRpbmcgYWxsIGRpc2NvbnRpZ3VvdXMgc2VnbWVudCByYW5nZXMNCiAgICAgIHJlY2VpdmVk IHdoZXJlIHRob3NlIHJhbmdlcyBhcmUgbG9naWNhbGx5IG92ZXIgdGhlIEFja25vd2xlZGdlbWVu dA0KICAgICAgTnVtYmVyIGluIHRoZSBUQ1AgaGVhZGVyIGFyZSBrZXB0IGluIGxvZ2ljYWxseSBh c2NlbmRpbmcgYnkNCiAgICAgIHNlZ21lbnQgcmFuZ2UgbGlzdC4gIEFkZGl0aW9uYWxseSBhIGNv dW50IChhIGZvdXIgYnl0ZSBiaW5hcnkgZm9yDQogICAgICBzYWZldHkpIGlzIG1haW50YWluZWQg aW4gZWFjaCBibG9jayB3aGljaCByZXByZXNlbnRzIHRoZSBudW1iZXIgb2YNCiAgICAgIHRpbWVz IGl0IGhhcyBiZWVuIHRyYW5zbWl0dGVkLiAgRWFjaCB0aW1lIGEgU0FDSyBibG9jayBpcyBhZGRl ZCBvcg0KICAgICAgY2hhbmdlcyAobm9ybWFsbHkgYnkgYmVpbmcgbWVyZ2VkIHdpdGggYW5vdGhl ciBlbnRyeSkgdGhlIGNvdW50IGlzDQogICAgICBzZXQgdG8gemVybygwKS4NCg0KICAgICAgKiBB bGwgU0FDSyBibG9jayBzbG90cyBTSE9VTEQgYmUgZmlsbGVkIG9uIGVhY2ggZWFjaCBub3JtYWwg QUNLDQogICAgICB0cmFuc21pdHRlZCwgc3RhcnRpbmcgd2l0aCB0aG9zZSB0aGF0IGhhdmUgdGhl IGxvd2VzdCBjb3VudA0KICAgICAgKGFja25vd2xlZGdpbmcgdGhlIG1vc3QgcmVjZW50bHkgcmVj ZWl2ZWQgc2VnbWVudHMpLCBmb2xsb3dlZCBieQ0KICAgICAgdGhvc2Ugd2l0aCB0aGUgbmV4dCBs b3dlc3QgY291bnQsIGFuZCBzbyBvbiB1bnRpbCBhbGwgU0FDSyBibG9jaw0KICAgICAgc2xvdHMg YXJlIGZpbGxlZC4gIEFzIGVhY2ggU0FDSyBibG9jayBpcyBtb3ZlZCB0byBhIHNsb3QgaXRzIGNv dW50DQogICAgICBpcyBpbmNyZW1lbnRlZCBieSBvbmUoMSkgKHRodXMgY2FyZSBuZWVkcyB0byBi ZSB0YWtlbiBvbiB0aGUNCg0KDQoNClNhYmF0aW5pLCBBbnRob255ICAgICAgIEV4cGlyZXMgRmVi cnVhcnkgMTQsIDIwMTMgICAgICAgICAgICAgICBbUGFnZSA4XQ0KDQoNCg0KDQoNCkludGVybmV0 IERyYWZ0ICAgICAgICBIaWdoIEVmZmljaWVuY3kgU0FDSyBmb3IgVENQICAgICAgIEF1Z3VzdCAx NSwgMjAxMg0KDQoNCiAgICAgIHNlY29uZCBhbmQgc3Vic2VxdWVudCBwYXNzZXMgdG8gc2tpcCB0 aG9zZSBlbnRyaWVzIGN1cnJlbnRseSBpbg0KICAgICAgU0FDSyBibG9ja3Mgc2xvdHMpLiBCeSBh bHdheXMgc3RhcnRpbmcgZnJvbSB0aGUgb2xkZXN0IHdlIGluc3VyZQ0KICAgICAgdGhlIG1vc3Qg Y3JpdGljYWwgaGF2ZSB0aGUgZmlyc3QgY2hhbmNlIGF0IHJlY2VpdmluZyBhIFNBQ0sgYmxvY2sN CiAgICAgIHNsb3QuIFNBQ0sgYmxvY2tzIGFyZSBlbXB0eSBPTkxZIGlmIHRoZXJlIGFyZSBsZXNz IFNBQ0sgYmxvY2tzDQogICAgICBvdXRzdGFuZGluZyB0aGFuIHRoZXJlIGFyZSBhdmFpbGFibGUg c2xvdHMuIFRoaXMgbWV0aG9kb2xvZ3kNCiAgICAgIGFzc3VyZXMgYSBmYWlyIG51bWJlciBvZiB0 cmFuc21pc3Npb25zIHRvIGFsbCBTQUNLIGJsb2Nrcy4NCg0KICAgICAgKiBUaGUgcmVjZWl2ZXIg cmVjZWl2ZXMgYSBTZW5kIFN0YXRlIGZyb20gdGhlIHNlbmRlciB0aGF0IGlzDQogICAgICBsb2dp Y2FsbHkgZ3JlYXRlciB0aGFuIGFueSBwcmV2aW91c2x5IHNlZW4gdGhlIHJlY2VpdmVyIG11c3QN CiAgICAgIGdlbmVyYXRlIGFuIEFDSyByZWdhcmRsZXNzIG9mIHdoZXRoZXIgYW55IFNBQ0sgYmxv Y2tzIGhhdmUNCiAgICAgIGNoYW5nZWQuICBOb3RlIHRoYXQgc3VjaCBhIFNlbmQgU3RhdGUgY2hh bmdlIGNhbiBjb21lIGZyb20gYW4gQUNLDQogICAgICBwcm9kdWNlZCBieSB0aGUgc2VuZGVyIGFz IHdlbGwgYXMgYSBtZXNzYWdlLg0KDQogICAgICAqIFRoZSBkZWZpbml0aW9ucyBpbiBSRkMxMDIy IGFyZSBjaGFuZ2VkIHN1Y2ggdGhhdCBpZiB0aGVyZSBhcmUNCiAgICAgIGVudHJpZXMgb24gdGhl IFNBQ0sgYmxvY2sgbGlzdCBhbiBBQ0sgQUxXQVlTIGdvZXMgb3V0IGluIHJlc3BvbnNlDQogICAg ICB0byBhIHJlY2VpdmVkIGRhdGEgc2VnbWVudC4NCg0KICAgICAgKiBUbyBpbnN1cmUgdGhhdCB0 aGUgbGFzdCBhZGRlZCBvciBjaGFuZ2VkIFNBQ0sgYmxvY2sgaXMNCiAgICAgIHRyYW5zbWl0dGVk IGEgc2Vjb25kIHRpbWUsIGlmIHRoZSBsaW5rIGdvZXMgaWRsZSBmb3IgMipSZW9yZGVyaW5nDQog ICAgICBUaW1lIHRoZSByZWNlaXZlciBTSE9VTEQgc2VuZCBhbm90aGVyIEFDSyBmb2xsb3dpbmcg dGhlIHJ1bGVzDQogICAgICBhYm92ZS4NCg0KICAgICAgKiBBIHRpbWVyIGlzIG1haW50YWluZWQg YmFzZWQgb24gdGhlIHRpbWVzdGFtcCBvZiB0aGUgb2xkZXN0IFNBQ0sNCiAgICAgIGJsb2NrIGFu ZCBpcyBzZXQgdG8gUlRUKjEuMjUsIGl0IGlzIHJlc2V0IGVhY2ggdGltZSBhIFNBQ0sgYmxvY2sN CiAgICAgIHdpdGggYSBkaWZmZXJlbnQgc2VnbWVudCBzdGFydCBiZWNvbWVzIHRoZSBvbGRlc3Qg U0FDSyBibG9jay4gIEF0DQogICAgICB0aGUgZXhwaXJhdGlvbiBvZiB0aGlzIHRpbWVyLCBzaW5j ZSB0aGlzIGFuZCBwcm9iYWJseSBvdGhlcg0KICAgICAgc2VnbWVudHMgaGF2ZSBub3QgYmVlbiBy ZXRyYW5zbWl0dGVkIHRvIHRoZSByZWNlaXZlciwgdGhlIHJlY2VpdmVyDQogICAgICByZXNldHMg dGhlIHRpbWVyIHRvIC4yNSpSVFQgYW5kIGFnYWluIHNlbmRzIHN1ZmZpY2llbnQNCiAgICAgIGFj a25vd2xlZGdlbWVudHMgdG8gY29tcGxldGVseSB0cmFuc21pdCBhbGwgY3VycmVudCBTQUNLIGJs b2Nrcw0KICAgICAgc3RhcnRpbmcgZnJvbSB0aGUgb25lIHdpdGggdGhlIGxvZ2ljYWxseSBsb3dl c3Qgc2VnbWVudCBzdGFydCBhbmQNCiAgICAgIHByb2NlZWRpbmcgaW4gYXNjZW5kaW5nIHNlcXVl bmNlLiAgTm90ZSB0aGF0IHRoaXMgcHJvY2VzcyBpcw0KICAgICAgYWJvcnRlZCBieSBhbnkgYWN0 aW9uIHRoYXQgY2hhbmdlcyB0aGUgb2xkZXN0IFNBQ0sgYmxvY2suICBUaGlzDQogICAgICB0aW1l ciBpcyB1c2VkIHRvIGFzc3VyZSB0aGF0IGluIGNhc2Ugb2YgYSBidXJzdCBlcnJvciB0aGUgc2Vu ZGVyDQogICAgICBoYXMgZW5vdWdoIGluZm9ybWF0aW9uIHRvIHJlc3RhcnQgcHJvcGVybHkuDQoN Cg0KNi4gIEludGVycHJldGluZyB0aGUgU2FjayBPcHRpb24gYW5kIFJldHJhbnNtaXNzaW9uIFN0 cmF0ZWd5OiBEYXRhDQogICBTZW5kZXIgQmVoYXZpb3INCg0KICAgQXMgZWFjaCB0cmFuc21pc3Np b24gcmVxdWVzdCBmcm9tIHRoZSBjYWxsaW5nIHByb2dyYW0gaXMgcHJvY2Vzc2VkDQogICBhbmQg ZW50cnkgaXMgbWFkZSBpbnRvIHRoZSBzZWdtZW50IHF1ZXVlIHRvIGhhbmRsZSB0aGUgcmVxdWVz dCBhbmQNCiAgIGl0cyBidWZmZXJpbmcuICBFbnRyaWVzIGFyZSByZW1vdmVkIGZyb20gdGhlIHNl Z21lbnQgcXVldWUgd2hlbiB0aGUNCiAgIHNlZ21lbnQgaXMgY29tcGxldGVseSBhY2tub3dsZWRn ZWQgZWl0aGVyIHRocm91Z2ggdGhlIEFja25vd2xlZGdlbWVudA0KICAgTnVtYmVyIEZpZWxkIG9m IHRoZSBUQ1AgaGVhZGVyIHBhc3NpbmcgdGhyb3VnaCB0aGUgZW5kIG9mIHRoYXQNCiAgIHNlZ21l bnQgb3IgYnkgYSBTQUNLIGJsb2NrIGNvbXBsZXRpbmcgdGhlIGFja25vd2xlZGdlbWVudCBvZiB0 aGF0DQogICBzZWdtZW50LiAgVGhlIHNlZ21lbnQgaXMgYWxzbyBhcHBlbmRlZCB0byB0aGUgZW5k IG9mIHRoZQ0KICAgcmV0cmFuc21pc3Npb24gcXVldWUgYW5kIHRyYW5zbWlzc2lvbiByZXN0YXJ0 ZWQgZnJvbSB0aGF0IHNlZ21lbnQgaWYNCiAgIHRyYW5zbWlzc2lvbiBoYXMgc3RvcHBlZC4NCg0K DQoNClNhYmF0aW5pLCBBbnRob255ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTQsIDIwMTMgICAg ICAgICAgICAgICBbUGFnZSA5XQ0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICBIaWdo IEVmZmljaWVuY3kgU0FDSyBmb3IgVENQICAgICAgIEF1Z3VzdCAxNSwgMjAxMg0KDQoNCiAgIEJl Zm9yZSBwcm9jZXNzaW5nIHRoZSBTQUNLIGluZm9ybWF0aW9uIHRoZSBBY2tub3dsZWRnZW1lbnQg TnVtYmVyDQogICBGaWVsZCBvZiB0aGUgVENQIGhlYWRlciBpcyB1c2VkIHRvIGVsaW1pbmF0ZSBv dXRkYXRlZCBlbnRyaWVzIGZyb20NCiAgIHRoZSBzZWdtZW50IHF1ZXVlLCBzYXZlZCBsaXN0IGFu ZCByZXRyYW5zbWlzc2lvbiBxdWV1ZSBiZWZvcmUgbmV3DQogICBpbmZvcm1hdGlvbiBpcyBhZGRl ZC4gIFRoZSBhY2tub3dsZWRnZW1lbnQgbWF5IHNwbGl0IHRoZSBmaXJzdCBlbnRyeQ0KICAgaW4g ZWl0aGVyIHRoZSBzZWdtZW50IHF1ZXVlIG9yIHRoZSByZXRyYW5zbWlzc2lvbiBxdWV1ZSBpbiB3 aGljaCBjYXNlDQogICBhIHBzZXVkbyBlbnRyeSBpcyBjcmVhdGVkIGluIHRoYXQgcXVldWUgZm9y IHRoZSB1bmFja25vd2xlZGdlZA0KICAgcmVtYWluZGVyIHdoaWNoIGFkZGl0aW9uYWxseSBwb2lu dHMgdG8gdGhlIHNhdmVkIG9yaWdpbmFsIGVudHJ5IHdpdGgNCiAgIGFuIGFkZGl0aW9uYWwgZmll bGQgd2hpY2ggaXMgdGhlIGNvdW50IG9mIHBzZXVkbyBzZWdtZW50cyBkZXJpdmVkDQogICBmcm9t IGl0LCBzZXQgdG8gb25lIGluIHRoaXMgY2FzZS4gIFRoZSBBY2tub3dsZWRnZW1lbnQgTnVtYmVy IEZpZWxkDQogICBvZiB0aGUgVENQIGhlYWRlciBtYXkgZW5kIHVwIGVsaW1pbmF0aW5nIGEgcHNl dWRvIGVudHJ5IGluIHdoaWNoIGNhc2UNCiAgIHRoZSBwc2V1ZG8gc2VnbWVudCBjb3VudCBvZiB0 aGUgb3JpZ2luYWwgc2F2ZWQgZW50cnkgaXMgZGVjcmVtZW50ZWQNCiAgIGFuZCBpZiB6ZXJvIHRo ZSBzZWdtZW50IGlzIHRoZW4gZW50aXJlbHkgcmVtb3ZlZCBmcm9tIGJvdGggdGhlDQogICBzZWdt ZW50IHF1ZXVlIGFuZCB0aGUgc2F2ZWQgbGlzdC4NCg0KICAgSW4gcHJvY2Vzc2luZyBzZWxlY3Rp dmUgYWNrbm93bGVkZ2VtZW50cyB0aGUgdHJhbnNtaXR0ZXIgYXBwbGllcyBlYWNoDQogICBTQUNL IGJsb2NrIHRvIGZpcnN0IHRoZSBzZWdtZW50IHF1ZXVlIGFuZCB0aGVuIHRoZSByZXRyYW5zbWlz c2lvbg0KICAgcXVldWUuICBJZiB0aGUgU0FDSyBibG9jayBjb21wbGV0ZWx5IGFja25vd2xlZGdl cyBhIHNlZ21lbnQgaXQgaXMNCiAgIHJlbW92ZWQgZnJvbSB0aGUgc2VnbWVudCBxdWV1ZSBhbmQg bW92ZWQgdG8gdGhlIHNhdmVkIGxpc3Qgd2l0aCBhDQogICBjb3VudCBvZiB6ZXJvIG9yIGNvbXBs ZXRlbHkgaWYgZnJvbSB0aGUgcmV0cmFuc21pc3Npb24gcXVldWUuICBJZiB0aGUNCiAgIFNBQ0sg YmxvY2sgY29tcGxldGVseSBhY2tub3dsZWRnZXMgYSBwc2V1ZG8gc2VnbWVudCB0aGF0IHNlZ21l bnQgaXMNCiAgIHJlbW92ZWQgYW5kIGlmIGZyb20gdGhlIHNlZ21lbnQgcXVldWUgdGhlIHBzZXVk byBzZWdtZW50IGNvdW50IGluIHRoZQ0KICAgcmVsYXRlZCBzYXZlZCBlbnRyeSBpcyBkZWNyZW1l bnRlZC4gIElmIHRoZSBTQUNLIGJsb2NrIGFja25vd2xlZGdlcw0KICAgdGhlIGJlZ2lubmluZyBv ciBlbmQgb2YgYSBzZWdtZW50IGluIGVpdGhlciBxdWV1ZSBhIHBzZXVkbyBlbnRyeSBpcw0KICAg Y3JlYXRlZCB3aXRoIHRoZSBhZGp1c3RlZCB1bmFja25vd2xlZGdlZCByZW1haW5kZXIsIGlmIHRo ZSBzZWdtZW50DQogICB3YXMgb24gdGhlIHNlZ21lbnQgbGlzdCB0aGUgb3JpZ2luYWwgc2VnbWVu dCBpcyBtb3ZlZCB0byB0aGUgc2F2ZWQNCiAgIGxpc3QgYW5kIHRoZSBwc2V1ZG8gY291bnQgaXMg c2V0IHRvIG9uZS4gIElmIHRoZSBlbnRyeSB3YXMgYWxyZWFkeSBhDQogICBwc2V1ZG8gc2VnbWVu dCBhbmQgdGhpcyBTQUNLIGFja25vd2xlZGdlcyB0aGUgYmVnaW5uaW5nIG9yIGVuZCBvZiB0aGUN CiAgIHNlZ21lbnQsIHRoZSBzZWdtZW50IGxpbWl0cyBhcmUgYWRqdXN0ZWQgYnV0IG5vIG90aGVy IGFjdGlvbiBvY2N1cnMuDQogICBJZiB0aGlzIGVudHJ5IGlzIGFscmVhZHkgYSBwc2V1ZG8gZW50 cnkgYW5kIHRoZSBTQUNLIGJsb2NrIHNwbGl0cyB0aGUNCiAgIHNlZ21lbnQgaW4gdHdvIGEgc2Vj b25kIHBzZXVkbyBlbnRyeSBpcyBjcmVhdGVkIHRvIGhhbmRsZSB0aGUgcmlnaHQNCiAgIGhhbmQg c2lkZSBvZiB0aGUgcmFuZ2UgYW5kLCBpZiBvbiB0aGUgc2VnbWVudCBsaXN0LCB0aGUgcHNldWRv DQogICBzZWdtZW50IGNvdW50IGluIHRoZSByZWxhdGVkIHNhdmUgbGlzdCBlbnRyeSBpcyBpbmNy ZW1lbnRlZCBieSBvbmUuDQogICBUaGUgb3JpZ2luYWwgcHNldWRvIGVudHJ5IGlzIG1vZGlmaWVk IHRvIHJlcHJlc2VudCB0aGUgbGVmdCBoYW5kDQogICByYW5nZSBjcmVhdGVkIGJ5IHRoZSBTQUNL Lg0KDQogICBUaGUgc2VuZGVyIG1haW50YWlucyBhIFRyYW5zbWlzc2lvbiBMaXN0IHdoaWNoIGFu IGFycmF5IG9mIHN0cnVjdHVyZXMNCiAgIGludG8gd2hpY2ggdGhlIHNlZ21lbnQgc3RhcnQgYW5k IGVuZCBhZGRyZXNzZXMgb2YgZWFjaCB0cmFuc21pdHRlZA0KICAgYmxvY2sgKGJlIGl0IGEgcHJp bWFyeSB0cmFuc21pc3Npb24gb3IgYSByZXRyYW5zbWlzc2lvbikgaXMgcGxhY2VkLg0KICAgVGhp cyBsaXN0IGlzLCBmb3Igb3B0aW1hbCBwcm9jZXNzaW5nLCBhIHBvd2VyIG9mIDIgaW4gc2l6ZSBh bmQgaXMsIGF0DQogICBhIG1pbmltdW0sIGZvdXIgdGltZXMgYXMgbGFyZ2UgYXMgdGhlIE1heGlt dW0gTnVtYmVyIG9mIFNlZ21lbnRzDQogICBPdXRzdGFuZGluZy4gIEFzIGVhY2ggc2VnbWVudCBp cyB0cmFuc21pdHRlZCB0aGUgY3VycmVudCBUcmFuc21pdA0KICAgVG9rZW4gbW9kdWx1cyB0aGUg VHJhbnNtaXNzaW9uIExpc3Qgc2l6ZSBpcyB1c2VkIGFzIGFuIGluZGV4IGludG8NCiAgIHRoaXMg c3RydWN0dXJlIHRvIHN0b3JlIHRoZSBzZWdtZW50IHN0YXJ0IGFuZCBlbmQgYW5kIHRoZW4gdGhl DQogICBUcmFuc21pdCBUb2tlbiBpcyBpbmNyZW1lbnRlZCBieSBvbmUuDQoNCiAgIFdoZW4gZWFj aCBlYWNoIG5ldyBTQUNLIG9wdGlvbiBpcyBwcm9jZXNzZWQsIGl0cyBSZXR1cm5lZCBUb2tlbiBp cw0KICAgY2hlY2tlZCBhZ2FpbnN0IHRoZSBDdXJyZW50IFJldHVybmVkIFRva2VuIGFuZCB0aGUg RnV0dXJlIFJldHVybmVkDQogICBUb2tlbiBMaXN0LCBpZiBsb2dpY2FsbHkgZ3JlYXRlciB0aGFu IGFueSBvZiB0aGUgYWJvdmUsIGl0IGlzDQoNCg0KDQpTYWJhdGluaSwgQW50aG9ueSAgICAgICBF eHBpcmVzIEZlYnJ1YXJ5IDE0LCAyMDEzICAgICAgICAgICAgICBbUGFnZSAxMF0NCg0KDQoNCg0K DQpJbnRlcm5ldCBEcmFmdCAgICAgICAgSGlnaCBFZmZpY2llbmN5IFNBQ0sgZm9yIFRDUCAgICAg ICBBdWd1c3QgMTUsIDIwMTINCg0KDQogICBpbnNlcnRlZCBpbnRvIHRoZSBGdXR1cmUgUmV0dXJu ZWQgVG9rZW4gbGlzdCBpbiBsb2dpY2FsIG9yZGVyIGFsb25nDQogICB3aXRoIHRoZSBjdXJyZW50 IHRpbWUtc3RhbXAgaW5jcmVtZW50ZWQgYnkgdGhlIFJlb3JkZXJpbmcgVGltZS4gIElmDQogICBp dCBpcyB0aGUgZmlyc3QgZW50cnkgb24gdGhlIGxpc3QgYSB0aW1lciBpcyBzdGFydGVkIGZvciB0 aGUgdmFsdWUNCiAgIHRva2VuIHRpbWUgc3RhbXAgbWludXMgY3VycmVudCB0aW1lIHN0YW1wLiAg V2hlbiB0aGUgdGltZXIgZXhwaXJlcw0KICAgdGhlIGZpcnN0IGVudHJ5IG9uIHRoZSBGdXR1cmUg UmV0dXJuZWQgVG9rZW4gbGlzdCBzZXQgYXMgdGhlIEN1cnJlbnQNCiAgIFJldHVybmVkIFRva2Vu IGFuZCB0aGVuIGl0IGlzIHJlbW92ZWQgZnJvbSB0aGUgbGlzdC4gIElmIHRoZXJlIGFyZQ0KICAg bW9yZSBtZW1iZXJzIG9uIHRoZSBGdXR1cmUgUmV0dXJuZWQgVG9rZW4gbGlzdCB0aGUgdGltZXIg aXMgcmVzdGFydGVkDQogICB3aXRoIGEgdmFsdWUgb2YgdGhlIHRpbWUtc3RhbXAgaW4gdGhhdCBl bnRyeSBtaW51cyB0aGUgY3VycmVudCB0aW1lLQ0KICAgc3RhbXAuICBBIGNoYW5nZSBpbiB0aGUg Q3VycmVudCBSZXR1cm5lZCBUb2tlbiBjYXVzZXMgYSByZWNyZWF0aW9uIG9mDQogICB0aGUgUmV0 cmFuc21pc3Npb24gUXVldWUgYnkgZmlyc3QgY29weWluZyB0aGUgU2VnbWVudCBRdWV1ZSBhbmQg dGhlbg0KICAgcmVtb3ZpbmcgZnJvbSBpdCBhbGwgc2VnbWVudHMgdGhhdCBoYXZlIGJlZW4gdHJh bnNtaXR0ZWQNCiAgIHN1YnNlcXVlbnRseSwgaW4gYSBwcm9jZXNzIGlkZW50aWNhbCB0byBwcm9j ZXNzaW5nIGEgU0FDSyBibG9jaw0KICAgc3RhcnRpbmcgYXQgdGhlIHNlZ21lbnQgaWRlbnRpZmll ZCBieSB0aGUgQ3VycmVudCBSZXR1cm5lZCBUb2tlbiBmcm9tDQogICB0aGUgVHJhbnNtaXNzaW9u IExpc3QgYW5kIGNvbnRpbnVpbmcgdGhyb3VnaCB0aGUgVHJhbnNtaXNzaW9uIExpc3QgdXANCiAg IHRvIHRoZSAoYnV0IG5vdCBpbmNsdWRpbmcpIHRoZSBUcmFuc21pdCBUb2tlbi4gIFRoZSBUcmFu c21pc3Npb24NCiAgIFBvaW50ZXIgaXMgdGhlbiBzZXQgdG8gZmlyc3QgaW5jb21wbGV0ZSBlbnRy eSBpbiB0aGUgUmV0cmFuc21pc3Npb24NCiAgIFF1ZXVlIGFuZCB0cmFuc21pc3Npb24gcmVzdGFy dGVkIGlmIGl0IGhhcyBzdG9wcGVkLg0KDQogICBBbm90aGVyIG1ldGhvZCBvZiBpbXBsZW1lbnRh dGlvbiB3aGljaCBhbGxvd3MgcXVpY2tlciByZXRyYW5zbWlzc2lvbg0KICAgcmVzcG9uc2UgYXQg dGhlIGV4cGVuc2Ugb2YgYnVpbGRpbmcgdGhlIFJldHJhbnNtaXNzaW9uIFF1ZXVlIGEgc2Vjb25k DQogICB0aW1lIGlzIHRvIHJldHJpZXZlIHRoZSB0aW1lIHN0YW1wIG9mIHRoZSBqdXN0IHJlY2Vp ZXZlZCBSZXR1cm5lZA0KICAgVG9rZW4gaWYgdGhhdCBSZXR1cm5lZCBUb2tlbiBoYXMgbm90IHBy ZXZpb3VzbHkgYmVlbiBzZWVuIChieQ0KICAgY29tcGFyaW5nIGl0IHdpdGggdGhlIEN1cnJlbnQg UmV0dXJuZWQgVG9rZW4gYW5kIHRoZSBGdXR1cmUgUmV0dXJuZWQNCiAgIFRva2VuIGxpc3QpIGFu ZCB0aGVuIHN1YnRyYWN0aW5nIGZyb20gdGhhdCB0aW1lc3RhbXAgdGhlIFJlb3JkZXJpbmcNCiAg IFRpbWUgdG8gYWxsb3cgZm9yIG91dCBvZiBvcmRlciBtZXNzYWdlcy4gIFRoaXMgdmFsdWUgaXMg dGhlbiB1c2VkIHRvDQogICBzZWxlY3QgYW55IGVudHJ5IG9uIHRoZSBUcmFuc21pc3Npb24gTGlz dCB3aXRoIGFuIGVxdWFsIG9yIGdyZWF0ZXINCiAgIHRpbWVzdGFtcC4gIFRoZSBmaXJzdCB2ZXJz aW9uIG9mIHRoZSBSZXRyYW5zbWlzc2lvbiBRdWV1ZSBpcyBjcmVhdGVkDQogICBieSBjb3B5aW5n IHRoZSBTZWdtZW50IFF1ZXVlIGFuZCB0aGVuIHJlbW92aW5nIHRoZSBzZWdtZW50cyB0aGF0IGhh dmUNCiAgIHNpbmNlIGJlZW4gcmV0cmFuc21pdHRlZCBiYXNlZCBvbiB0aGUgYWRqdXN0ZWQgdGlt ZXN0YW1wLiAgV2hlbiB0aGUNCiAgIHRpbWVyIG9uIHRoZSBGdXR1cmUgUmV0dXJuZWQgVG9rZW4g TGlzdCBleHBpcmVzIHRoZSByZXRyYW5zbWlzc2lvbg0KICAgcXVldWUgaXMgcmVjcmVhdGVkIGEg c2Vjb25kIHRpbWUgYXMgaW4gdGhlIHByZWNlZWRpbmcgcGFyYWdyYXBoLg0KDQogICBOb3RlOiBG b3IgcHJvY2Vzc2luZyBlZmZpY2llbmN5IHdlIGJlbGlldmUgbW9zdCBwZW9wbGUgd2lsbCBpbXBs ZW1lbnQNCiAgIHRoZSBSZXRyYW5zbWlzc2lvbiBRdWV1ZSBhcyBhZGRpdGlvbmFsIGZpZWxkcyBp biB0aGUgU2VnbWVudCBRdWV1ZS4NCg0KNi4xICBIYW5kbGluZyBsYXN0IHNlZ21lbnQgcHJvYmxl bQ0KDQogICBJZiB0aGUgc2VuZGVyIHNpZGUgb2YgdGhlIGxpbmsgZ29lcyBpZGxlIGZvciAyKlJl b3JkZXJpbmcgVGltZSBhbmQNCiAgIHRoZXJlIGFyZSBzdGlsbCB1bmFja25vd2xlZGdlZCBzZWdt ZW50cyB0aGUgc2VuZGVyIFNIT1VMRCBzZW5kIGFuIEFDSw0KICAgKHdoaWNoIHdvdWxkIGhhdmUg dGhlIHVwZGF0ZWQgU2VuZCBTdGF0ZSkgc28gdGhhdCB0aGUgcmVjZWl2ZXIgbWF5DQogICB1bHRp bWF0ZWx5IGRldGVjdCBpZiB0aGUgbGFzdCBtZXNzYWdlIGlzIG1pc3NpbmcgYW5kIGNhdXNlIGl0 IHRvIGJlDQogICB0cmFuc21pdHRlZCAodGhlIHJlY2VpdmVyIHdvdWxkIHBhc3MgdGhlIFNlbmQg U3RhdGUgYmFjayBhcyBSZXR1cm5lZA0KICAgU3RhdGUgYW5kIHRoZSBzZW5kZXIgd291bGQgcmVh bGl6ZSB0aGUgc2VnbWVudCBpcyBzdGlsbCBvdXRzdGFuZGluZykuDQoNCjYuMiAgQ29uZ2VzdGlv biBDb250cm9sIElzc3Vlcw0KDQogICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGF0dGVtcHQgdG8g c3BlY2lmeSBpbiBkZXRhaWwgdGhlIGNvbmdlc3Rpb24NCiAgIGNvbnRyb2wgYWxnb3JpdGhtcyBm b3IgaW1wbGVtZW50YXRpb25zIG9mIFRDUCB3aXRoIFNBQ0suICBIb3dldmVyLA0KDQoNCg0KU2Fi YXRpbmksIEFudGhvbnkgICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNCwgMjAxMyAgICAgICAgICAg ICAgW1BhZ2UgMTFdDQoNCg0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgIEhpZ2ggRWZmaWNp ZW5jeSBTQUNLIGZvciBUQ1AgICAgICAgQXVndXN0IDE1LCAyMDEyDQoNCg0KICAgdGhlIGNvbmdl c3Rpb24gY29udHJvbCBhbGdvcml0aG1zIHByZXNlbnQgaW4gdGhlIGRlIGZhY3RvIHN0YW5kYXJk DQogICBUQ1AgaW1wbGVtZW50YXRpb25zIE1VU1QgYmUgcHJlc2VydmVkIFtTdGV2ZW5zOTRdLiAg VGhpcyBhbGdvcml0aG0NCiAgIGVsaW1pbmF0ZXMgbXVjaCB1bm5lY2Vzc2FyeSByZXRyYW5zbWlz c2lvbiBzbyBpcyBsaWtlbHkgdG8gbGVzc2VuDQogICBvdmVyYWxsIGNvbmdlc3Rpb24uDQoNCiAg IE5vdGUgdGhhdCB0aGUgZW5oYW5jZWQgcHJvdG9jb2wgZG9lcyBub3Qgc3VmZmVyIGZyb20gdHJh ZGl0aW9uYWwNCiAgIGNvbmdlc3Rpb24gY29sbGFwc2UgZXZlbiB0aG91Z2ggaXQgaXMgbW9yZSBy b2J1c3QsIHNpbmNlIGl0IGRvZXMgbm90DQogICB1c2UgdGltZXJzIGFuZCBpcyByYXRlIGxpbWl0 ZWQgYnkgdGhlIHRva2Vucy4gIERlbGF5ZWQgYW5kIGxvc3QNCiAgIG1lc3NhZ2VzIGFuZCBBQ0tT IG1ha2UgaXQgc2xvd2VyIGJ1dCBkbyBub3QgaW5jcmVhc2UgdGhlIHRyYWZmaWMgaXQNCiAgIHNl bmRzIHNpZ25pZmljYW50bHkuDQoNCiAgIFRoZSB1c2Ugb2YgdGltZS1vdXRzIGFzIGEgZmFsbC1i YWNrIG1lY2hhbmlzbSBmb3IgZGV0ZWN0aW5nIGRyb3BwZWQNCiAgIHBhY2tldHMgaXMgdW5jaGFu Z2VkIGJ5IHRoZSBTQUNLIG9wdGlvbi4gIEJlY2F1c2UgaW4gbm9ybWFsIG9wZXJhdGlvbg0KICAg YWNrbm93bGVkZ2VtZW50cyB3aWxsIHByZXZlbnQgcmV0cmFuc21pdCB0aW1lb3V0LCB3aGVuIGEg cmV0cmFuc21pdA0KICAgdGltZW91dCBvY2N1cnMgdGhlIGRhdGEgc2VuZGVyIFNIT1VMRCBpZ25v cmUgcHJpb3IgU0FDSyBpbmZvcm1hdGlvbg0KICAgaW4gZGV0ZXJtaW5pbmcgd2hpY2ggZGF0YSB0 byByZXRyYW5zbWl0Lg0KDQogICBGdXR1cmUgcmVzZWFyY2ggaW50byBjb25nZXN0aW9uIGNvbnRy b2wgYWxnb3JpdGhtcyBtYXkgdGFrZSBhZHZhbnRhZ2UNCiAgIG9mIHRoZSBhZGRpdGlvbmFsIGlu Zm9ybWF0aW9uIHByb3ZpZGVkIGJ5IFNBQ0suICBPbmUgc3VjaCBhcmVhIGZvcg0KICAgZnV0dXJl IHJlc2VhcmNoIGNvbmNlcm5zIG1vZGlmaWNhdGlvbnMgdG8gVENQIGZvciBhIHdpcmVsZXNzIG9y DQogICBzYXRlbGxpdGUgZW52aXJvbm1lbnQgd2hlcmUgcGFja2V0IGxvc3MgaXMgbm90IG5lY2Vz c2FyaWx5IGFuDQogICBpbmRpY2F0aW9uIG9mIGNvbmdlc3Rpb24uDQoNCjcuICBFZmZpY2llbmN5 IGFuZCBXb3JzdCBDYXNlIEJlaGF2aW9yDQoNCiAgIEFsdGhvdWdoIHRoaXMgaGlnaCBlZmZpY2ll bmN5IGltcHJvdmVkIFNBQ0sgb3B0aW9uIHNlbmRzIG1vcmUgYW5kDQogICBsYXJnZXIgU0FDSyBi bG9ja3MgYW5kIG1vcmUgYWNrbm93bGVkZ2VtZW50cyB0aGFuIHRoZSBwcmV2aW91cw0KICAgdmVy c2lvbiwgd2l0aCBhbiBhY3RpdmUgYmktZGlyZWN0aW9uYWwgbGluayBhZGRpdGlvbmFsDQogICBh Y2tub3dsZWRnZW1lbnRzIGFyZSBvZnRlbiBhc3NvY2lhdGVkIHdpdGggZGF0YSB0cmFuc21pc3Np b24gYW5kIHRodXMNCiAgIG5vdCBhIHBlbmFsdHkuICBJZiB0aGUgU0FDSyBvcHRpb24gbmVlZHMg dG8gYmUgdXNlZCBkdWUgdG8gc2VnbWVudA0KICAgbG9zcyB0aGVuIHRoZSBpbXByb3ZlZCBlZmZp Y2llbmN5IGFmZm9yZGVkIHdpdGggdGhpcyBwcm90b2NvbCBtb3JlDQogICB0aGFuIGp1c3RpZmll cyB0aGUgYWRkaXRpb25hbCBTQUNLIGJsb2Nrcy4NCg0KICAgVGhlIGRlcGxveW1lbnQgb2Ygb3Ro ZXIgVENQIG9wdGlvbnMgbWF5IHJlZHVjZSB0aGUgbnVtYmVyIG9mDQogICBhdmFpbGFibGUgU0FD SyBibG9ja3MgdG8gMiBvciBldmVuIHRvIDEuICBUaGlzIHdpbGwgcmVkdWNlIHRoZQ0KICAgcmVk dW5kYW5jeSBvZiBTQUNLIGRlbGl2ZXJ5IGluIHRoZSBwcmVzZW5jZSBvZiBsb3N0IEFDS3MuICBF dmVuIHNvLA0KICAgdGhlIGV4cG9zdXJlIG9mIFRDUCBTQUNLIGluIHJlZ2FyZCB0byB0aGUgdW5u ZWNlc3NhcnkgcmV0cmFuc21pc3Npb24NCiAgIG9mIHBhY2tldHMgaXMgc3RyaWN0bHkgbGVzcyB0 aGFuIHRoZSBleHBvc3VyZSBvZiBjdXJyZW50DQogICBpbXBsZW1lbnRhdGlvbnMgb2YgVENQLiAg VGhlIHdvcnN0LWNhc2UgY29uZGl0aW9ucyBuZWNlc3NhcnkgZm9yIHRoZQ0KICAgc2VuZGVyIHRv IG5lZWRsZXNzbHkgcmV0cmFuc21pdCBkYXRhIGlzIGRpc2N1c3NlZCBpbiBtb3JlIGRldGFpbCBp biBhDQogICBzZXBhcmF0ZSBkb2N1bWVudCBbRmxveWQ5Nl0uDQoNCiAgIE9sZGVyIFRDUCBpbXBs ZW1lbnRhdGlvbnMgd2hpY2ggZG8gbm90IGhhdmUgdGhlIFNBQ0sgb3B0aW9uIHdpbGwgbm90DQog ICBiZSB1bmZhaXJseSBkaXNhZHZhbnRhZ2VkIHdoZW4gY29tcGV0aW5nIGFnYWluc3QgU0FDSy1j YXBhYmxlIFRDUHMuDQogICBUaGlzIGlzc3VlIGlzIGRpc2N1c3NlZCBpbiBtb3JlIGRldGFpbCBp biBbRmxveWQ5Nl0uDQoNCjguICBUaW1lLXN0YW1waW5nDQoNCg0KDQoNClNhYmF0aW5pLCBBbnRo b255ICAgICAgIEV4cGlyZXMgRmVicnVhcnkgMTQsIDIwMTMgICAgICAgICAgICAgIFtQYWdlIDEy XQ0KDQoNCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICBIaWdoIEVmZmljaWVuY3kgU0FDSyBm b3IgVENQICAgICAgIEF1Z3VzdCAxNSwgMjAxMg0KDQoNCiAgIE9uZSBwbGVhc2FudCBiZW5lZml0 IG9mIGhhdmluZyBhIHRva2VuIHdoaWNoIGlzIHJldHVybmVkIGJ5IHRoZSBmYXINCiAgIGVuZCBv biBhIGRldGVybWluaXN0aWMgYmFzaXMgaXMgdGhlIGVhc3kgY2FsY3VsYXRpb24gb2Ygcm91bmQg dHJpcA0KICAgZGVsYXkuICBXZSBjYW4gc2F2ZSBhIHRpbWUgc3RhbXAgYWxvbmcgd2l0aCB0aGUg c2VnbWVudCBpbmZvcm1hdGlvbg0KICAgaW4gb3VyIHRyYW5zbWlzc2lvbiBvcmRlciBhcnJheS4g IFRoaXMgYWxsb3dzIHVzIHRvIGNhbGN1bGF0ZSByb3VuZA0KICAgdHJpcCBkZWxheSB3aGVuIHdl IHJlY2VpdmUgb3VyICJSZXR1cm5lZCBTdGF0ZSIgdmFsdWUgYW5kIHVzZSBpdCB0bw0KICAgYWNj ZXNzIHRoZSB0aW1lLXN0YW1wLiAgU2luY2UgbW9yZSB0aGFuIG9uZSByZWNlaXZlZCBtZXNzYWdl IG1pZ2h0DQogICBoYXZlIHRoZSBzYW1lICJSZXR1cm5lZCBTdGF0ZSIgdmFsdWUgd2UgbWFyayB0 aGUgdGltZS1zdGFtcCBhZnRlciB1c2UNCiAgIHRvIGluZGljYXRlIHRoYXQgdGhlIHZhbHVlIHNo b3VsZCBub3QgYmUgdXNlZCBhZ2Fpbi4gIE5vdGUgdGhhdCBpZiBhbg0KICAgYWNrbm93bGVkZ2Vt ZW50IGlzIGxvc3Qgd2Ugd2lsbCBjYWxjdWxhdGUgYSBsb25nZXIgZGVsYXkgdGhhbiBpcw0KICAg YWNjdXJhdGUgdGhlcmVmb3JlIHdlIG11c3Qgc21vb3RoIHRoZSByZXR1cm5lZCB2YWx1ZXMsIHR5 cGljYWxseQ0KICAgcmV0dXJuaW5nIHRoZSBzbWEgbGxlc3Qgb3V0IG9mIHRoZSBsYXN0IE4gd2hl cmUgTiBpcyB0eXBpY2FsbHkgZm91ci4NCg0KDQo5LiBEYXRhIFJlY2VpdmVyIFJlbmVnaW5nDQoN CiAgIFNpbmNlIHRoZSBTZW5kZXIgaXMgcmVjcmVhdGluZyB0aGUgc3RhdGUgb2YgdGhlIFJlY2Vp dmVyLCB0aGUgZGF0YQ0KICAgUmVjZWl2ZXIgTVVTVCBOT1QgZGlzY2FyZCBkYXRhIGluIGl0cyBx dWV1ZSBvbmNlIHRoYXQgZGF0YSBoYXMgYmVlbg0KICAgcmVwb3J0ZWQgaW4gYSBTQUNLIG9wdGlv bi4gIFRoZSBSZWNlaXZlciBpcyByZXNwb25zaWJsZSBmb3INCiAgIGFsbG9jYXRpbmcgZW5vdWdo IGJ1ZmZlcnMgc28gdGhhdCB0aGUgbWlzc2luZyBzZWdtZW50cyB3aXRoaW4gdGhlDQogICB3aW5k b3cgbWF5IGJlIHByb3Blcmx5IHJlY2VpdmVkIGFuZCBwcm9jZXNzZWQuICBTaW5jZSBlbmhhbmNl ZCBTQUNLDQogICBpcyBldmVudCBkcml2ZW4gdGhlIGxhY2sgb2YgYSBuZXcgZXZlbnQgZm9yIDIu NTAqUlRUIFNIT1VMRCB0cmlnZ2VyIGENCiAgIGNvbm5lY3Rpb24gcmVzZXQgdG8gZ3VhcmQgYWdh aW5zIGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFja3MuDQoNCjEwLiAgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMNCg0KICAgVGhpcyBkb2N1bWVudCBuZWl0aGVyIHN0cmVuZ3RoZW5zIG5vciB3ZWFrZW5z IFRDUCdzIGN1cnJlbnQgc2VjdXJpdHkNCiAgIHByb3BlcnRpZXMuDQoNCjExLiBSZWZlcmVuY2Vz DQoNCiAgIFtKYWNvYnNvbjg4XSwgSmFjb2Jzb24sIFYuIGFuZCBSLiBCcmFkZW4sICJUQ1AgRXh0 ZW5zaW9ucyBmb3IgTG9uZy0NCiAgIERlbGF5IFBhdGhzIiwgUkZDIDEwNzIsIE9jdG9iZXIgMTk4 OC4NCg0KICAgW0phY29ic29uOTJdIEphY29ic29uLCBWLiwgQnJhZGVuLCBSLiwgYW5kIEQuIEJv cm1hbiwgIlRDUCBFeHRlbnNpb25zDQogICBmb3IgSGlnaCBQZXJmb3JtYW5jZSIsIFJGQyAxMzIz LCBNYXkgMTk5Mi4NCg0KICAgW01hdGhpczk2XSBNYXRoaXMsIE0uLCBNYWhkYXZpLCBKLiwgRmxv eWQsIFMuLCBSb21hbm93LCBKLiAiVENQDQogICBTZWxlY3RpdmUgQWNrbm93bGVkZGdlbWVudCBP cHRpb25zIiwgUkZDIDIwMTgsIE9jdG9iZXIgMTk5Ni4NCg0KICAgW1Bvc3RlbDgxXSAgUG9zdGVs LCBKLiwgIlRyYW5zbWlzc2lvbiBDb250cm9sIFByb3RvY29sIC0gREFSUEENCiAgIEludGVybmV0 IFByb2dyYW0gUHJvdG9jb2wgU3BlY2lmaWNhdGlvbiIsIFJGQyA3OTMsIERBUlBBLCBTZXB0ZW1i ZXINCiAgIDE5ODEuDQoNCkF1dGhvcidzIEFkZHJlc3MNCg0KICAgICAgQW50aG9ueSBTYWJhdGlu aQ0KICAgICAgQnJva2VyIENvbW11bmljYXRpb25zIEluYy4NCiAgICAgIDIwMCBXZXN0IDIwdGgg U3RyZWV0DQoNCg0KDQpTYWJhdGluaSwgQW50aG9ueSAgICAgICBFeHBpcmVzIEZlYnJ1YXJ5IDE0 LCAyMDEzICAgICAgICAgICAgICBbUGFnZSAxM10NCg0KDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAg ICAgICAgSGlnaCBFZmZpY2llbmN5IFNBQ0sgZm9yIFRDUCAgICAgICBBdWd1c3QgMTUsIDIwMTIN Cg0KDQogICAgICBTdWl0ZSAxMjE2DQogICAgICBOZXcgWW9yaywgTlkgMTAwMTENCiAgICAgIEVt YWlsOiBkcmFmdC1zYWNrQHRzYWJhdGluaS5jb20NCg0KICAgICAgVGhlIGF1dGhvciBpcyBjdXJy ZW50bHkgYSBtYXN0ZXIncyBkZWdyZWUgY2FuZGlkYXRlIGF0IC0NCg0KICAgICAgSG9mc3RyYSBV bml2ZXJzaXR5DQogICAgICBIZW1wc3RlYWQsIE4uWS4NCg0KICAgICAgSGlzIGFkdmlzZXIgaXMg RHIuIFhpYW5nIEZ1DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KU2FiYXRpbmksIEFudGhvbnkg ICAgICAgRXhwaXJlcyBGZWJydWFyeSAxNCwgMjAxMyAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoN Cg0K --_d72115f6-159f-40f2-96e9-411bf0a4c0f7_ Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tdlcrfc1out.txt" DQoNCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBBLiBTYWJhdGluaQ0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEJyb2tlciBDb21tdW5pY2F0aW9ucyBJbmMuDQpJbnRlbmRlZCBzdGF0dXM6IFN0 YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjgsIDIwMTINCkV4 cGlyZXM6IE1hcmNoIDEsIDIwMTMNCg0KDQogICAgICAgICAgICAgVERMQywgQW4gaW1wcm92ZWQg IlNlbGVjdGl2ZSBSZXBlYXQiIHByb3RvY29sLg0KICAgICAgICAgICAgICAgICAgICAgICAgIGRy YWZ0LXNhYmF0aW5pLXRkbGMtMDANCg0KQWJzdHJhY3QNCg0KICAgVGhpcyBwYXBlciBkZXNjcmli ZXMgYW4gZXh0cmVtZWx5IGVmZmljaWVudCBhbmQgcmVsaWFibGUgcmVhbC10aW1lDQogICAiU2Vs ZWN0aXZlIFJlcGVhdCIgcHJvdG9jb2wgdGhhdCB3YXMgaW1wbGVtZW50ZWQgYXMgdGhlIGJhY2ti b25lDQogICB0cmFuc21pc3Npb24gcHJvdG9jb2wgZm9yIHRoZSBsYXJnZXN0IGZpbmFuY2lhbCBp bmZvcm1hdGlvbiBuZXR3b3JrDQogICBpbiB0aGUgVW5pdGVkIFN0YXRlcyBkdXJpbmcgdGhlIDE5 ODAncyBhbmQgMTk5MCdzLiAgVGhlIHByb3RvY29sIGlzDQogICBjYXBhYmxlIG9mIHdvcmtpbmcg ZWZmaWNpZW50bHkgaW4gYWxsIGVudmlyb25tZW50cyBpbmNsdWRpbmcgdGhvc2UNCiAgIHdpdGgg c3Vic3RhbnRpYWwgZGVsYXkgYW5kIGhpZ2ggZXJyb3Igb3IgY29uZ2VzdGlvbiByYXRlcywNCiAg IHRyYW5zbWl0dGluZyBvcHRpbWFsbHkgZG93biB0byB0aGUgcG9pbnQgdGhhdCB0aGVyZSBpcyBv bmUgZXJyb3IgcGVyDQogICBibG9jaywgbmV2ZXIgcmVzZW5kaW5nIGEgYmxvY2sgdGhhdCBoYXMg YmVlbiByZWNlaXZlZCBjb3JyZWN0bHkgYW5kDQogICBhbHdheXMgc2VuZGluZyB0aGUgYmxvY2tz IGluIGFuIG9yZGVyIHdoaWNoIGlzIG9wdGltYWwgZm9yDQogICBleHBlZGl0aW91cyBkZWxpdmVy eS4gIFRoaXMgcHJvdG9jb2wgcmVwcmVzZW50cyBhIG5ldyB3YXkgb2YgbG9va2luZw0KICAgYXQg IlNlbGVjdGl2ZSBSZXBlYXQiIHByb3RvY29scyBhbmQgdGhlIGNvbmNlcHRzIGl0IGludHJvZHVj ZXMgaGF2ZQ0KICAgd2lkZSBhcHBsaWNhYmlsaXR5IGluIG90aGVyIHByb3RvY29scy4gIEl0IHdv cmtzIGVxdWFsbHkgd2VsbCBpbg0KICAgcG9pbnQgdG8gbXVsdGktcG9pbnQgZW52aXJvbm1lbnRz IGFzIGl0IGRvZXMgcG9pbnQgdG8gcG9pbnQgb25lcy4gIEl0DQogICBoYXMgYmVlbiB1c2VkIGFz IGJvdGggYSBsaW5rIGxldmVsIGFuZCBhIHRyYW5zcG9ydCBsZXZlbCBwcm90b2NvbC4NCg0KU3Rh dHVzIG9mIHRoaXMgTWVtbw0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBp biBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlDQogICBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQg QkNQIDc5Lg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRo ZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUNCiAgIHdvcmtpbmcgZG9jdW1lbnRzIGFz IEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtDQogICBEcmFm dHMgaXMgYXQgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly4NCg0K ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11 bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNv bGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0IGlzIGluYXBwcm9w cmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAgIG1hdGVyaWFsIG9y IHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiINCg0KICAgVGhp cyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBNYXJjaCAxLCAyMDEzLg0KDQpDb3B5cmln aHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAxMiBJRVRGIFRydXN0IGFuZCB0aGUgcGVy c29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMg cmVzZXJ2ZWQuDQoNCg0KDQoNClNhYmF0aW5pICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJj aCAxLCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgIFRETEMgVGhlb3J5ICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDEyDQoN Cg0KICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1 c3QncyBMZWdhbA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAg KGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBk YXRlIG9mDQogICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHJldmlldyB0 aGVzZSBkb2N1bWVudHMNCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0 cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdA0KICAgdG8gdGhpcyBkb2N1bWVudC4gIENv ZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QNCiAgIGluY2x1 ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQu ZSBvZg0KICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRo b3V0IHdhcnJhbnR5IGFzDQogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vu c2UuDQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAgIDEuMS4g IFJlcXVpcmVtZW50cyBMYW5ndWFnZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDMNCiAgIDIuICBIaXN0b3J5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMy4gIFVuZGVybHlpbmcgQ29uY2VwdHMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICA0LiAgVGhlIEhETEMg KG9yIFguMjUpIHByb3RvY29sICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQN CiAgIDUuICBDb25zaWRlcmF0aW9ucyBpbiBkZXNpZ25pbmcgVERMQyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgNQ0KICAgICA1LjEuICBSZS1UcmFuc21pc3Npb24gIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICAgIDUuMi4gIFNlcXVlbmNlIHN0 YXRlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgICAg NS4zLiAgVHJhbnNtaXQgc2VxdWVuY2UgbnVtYmVyaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgNg0KICAgICA1LjQuICBXaW5kb3cgU2l6ZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICAgIDUuNS4gIENvbm5lY3Rpb24gYW5kIFJl LUNvbm5lY3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgNS42LiAg VXNlIG9mIFJlY2VpdmUgUmVhZHkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOA0KICAgICA1LjcuICBQb2ludCB0byBNdWx0aXBvaW50ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAgIDUuOC4gIENhbGN1bGF0aW9uIG9mIHJvdW5kIHRy aXAgZGVsYXkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIDYuICBQZXJmb3JtYW5j ZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0K ICAgNy4gIENvbmNsdXNpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDEwDQogICA4LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgIDkuICBTZWN1cml0eSBDb25zaWRl cmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgMTAu IFJlZmVyZW5jZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDEwDQogICAgIDEwLjEuIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANCiAgICAgMTAuMi4gSW5mb3JtYXRpdmUgUmVmZXJl bmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMQ0KICAgQXBwZW5kaXgg QS4gIFJlbGF0ZWQgUmVhZGluZ3MgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDExDQogICBBdXRob3IncyBBZGRyZXNzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMTINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClNhYmF0 aW5pICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAxLCAyMDEzICAgICAgICAgICAgICAg ICBbUGFnZSAyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFRETEMgVGhlb3J5 ICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDEyDQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQog ICBBbHRob3VnaCBrbm93biBhbmQgdXNlZCBpbiB0aGUgZmluYW5jaWFsIGNvbW11bml0eSBmb3Ig b3ZlciAyMCB5ZWFycywNCiAgIGFuZCB0aGUgc3ViamVjdCBvZiBwcmVzZW50YXRpb25zIHRvIGJv dGggaW5kdXN0cnkgYW5kIGFjYWRlbWljIGdyb3Vwcw0KICAgdGhlcmUgaGFzIG5ldmVyIGJlZW4g YW4gYWNhZGVtaWMgcGFwZXIgd3JpdHRlbiBvbiB0aGlzIHByb3RvY29sLiAgQXMNCiAgIGJvdGgg dGhlIGludmVudG9yIG9mIHRoaXMgcHJvdG9jb2wgYW5kIHRoZSBvcmlnaW5hbCBpbXBsZW1lbnRl ciBJDQogICBmZWx0IGl0IHdhcyBteSByZXNwb25zaWJpbGl0eSB0byBjb3JyZWN0IHRoaXMgb3Zl cnNpZ2h0LiAgVGhpcw0KICAgcHJvdG9jb2wgaXMgYSBkaXJlY3QgcmVzdWx0IG9mIG15IHN0dWRp ZXMgb2YgdGhlIFl1LUxpbiBwcm90b2NvbCBhbmQNCiAgIHRoZSBmaXJzdCBpbXBsZW1lbnRhdGlv biBvZiBpdCB3YXMgaW4gMTk4My4gIE9uIHRoZSBmaXJzdCBhbm5pdmVyc2FyeQ0KICAgb2YgaXRz IGluZHVzdHJ5IHB1YmxpY2F0aW9uIGluIDE5ODQsIFRlbGVyYXRlIGRlY2lkZWQgbm90IHRvIGFz c2VydA0KICAgaW50ZWxsZWN0dWFsIHByb3BlcnR5IHJpZ2h0cyBhbmQgdG8gYWRkIGl0IHRvIHRo ZSBwdWJsaWMgZG9tYWluLiAgVHdvDQogICBhdHRlbXB0cyB3ZXJlIG1hZGUgdG8gY29tbWVyY2lh bGl6ZSBpdCBvdXRzaWRlIG9mIHRoZSBmaW5hbmNpYWwNCiAgIGluZHVzdHJ5LCBvbmNlIGJ5IEFU JlQgaW4gMTk4OCBhbmQgYnkgQVQmVCBQYXJhZHluZSBpbiAxOTkxIGJ1dCBsYWNrDQogICBvZiBh biBhcHByb3ZlZCBzdGFuZGFyZCB1bHRpbWF0ZWx5IGxlYWQgaW4gYm90aCBjYXNlcyB0byBBVCZU DQogICBhYmFuZG9uaW5nIHRoZSBwcm9qZWN0Lg0KDQogICBTaW5jZSBUZWxlcmF0ZSBvcGVyYXRl ZCB3b3JsZHdpZGUgb3ZlciBhbiBhbWF6aW5nIG51bWJlciBvZg0KICAgY29tbXVuaWNhdGlvbnMg dGVjaG5vbG9naWVzLCBURExDIHdhcyBib3JuIG91dCBvZiB0aGUgbmVlZCBmb3IgYQ0KICAgcHJv dG9jb2wgdGhhdCB3b3VsZCBoYW5kbGUgYW55IGNvbW11bmljYXRpb25zIGVudmlyb25tZW50IG5v IG1hdHRlcg0KICAgaG93IG5vaXN5LCBob3cgc2xvdyBvciBob3cgbXVjaCBkZWxheSAoaW5jbHVk aW5nIG11bHRpcGxlIHNhdGVsbGl0ZQ0KICAgaG9wcykgd2FzIGluIHRoZSBwYXRoLiAgSW4gbGF0 ZXIgeWVhcnMgaXRzIHByb3BlcnRpZXMgd2VyZSBmb3VuZA0KICAgdmFsdWFibGUgaW4gY29uZ2Vz dGlvbiBzaXR1YXRpb25zIHdoZXJlIHBhY2tldHMgd2VyZSBkcm9wcGVkLg0KDQoxLjEuICBSZXF1 aXJlbWVudHMgTGFuZ3VhZ2UNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs ICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQg Tk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRv Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkgW1JG QzIxMTldLg0KDQoNCjIuICBIaXN0b3J5DQoNCiAgIEJvdGggbWFqb3IgY2xhc3NlcyBvZiBhdXRv bWF0aWMgcmVwZWF0IHJlcXVlc3QgKEFSUSkgdHJhbnNwb3J0DQogICBwcm90b2NvbHMsIHJlcHJl c2VudGVkIGJ5IFNETEMvSERMQy9YLjI1IGFuZCBUQ1AsIGhhdmUgYW4gaW1wbGljaXQNCiAgIGFz c3VtcHRpb24gdGhhdCB0aGUgZGVsYXkgYmV0d2VlbiBzZW5kZXIgYW5kIHJlY2VpdmVyIGlzIHZl cnkgc21hbGwuDQogICBCZWNhdXNlIG9mIHRoaXMgYXNzdW1wdGlvbiB3aGVuIHVzZWQgb3ZlciBh IGxpbmsgd2l0aCBjb25zaWRlcmFibGUNCiAgIGRlbGF5IHRoZWlyIGVycm9yIHJlY292ZXJ5IG1l Y2hhbmlzbXMgYXJlIGluYWRlcXVhdGUgdG8gaW5zdXJlDQogICBvcHRpbXVtIHVzZSBvZiB0aGUg bGluayBvciBjb25zaXN0ZW50IGRlbGl2ZXJ5IHRpbWVzLg0KDQogICBPdmVyIHRoZSB5ZWFycyBh IG51bWJlciBvZiBwYXBlcnMgc3VnZ2VzdGluZyBpbXByb3ZlZCAiR08gQkFDSyBOIiwNCiAgIGFu ZCBzZWxlY3RpdmUgcmVwZWF0IChTUikgcHJvY2VkdXJlcyBhbmQgYSBudW1iZXIgb2YgcHJvdG9j b2xzIChzdWNoDQogICBhcyBTQUNLLCBYVFAsIE5FVEJMVCkgaGF2ZSBiZWVuIHByb3Bvc2VkIGJ1 dCBub25lIGFkZHJlc3NlZCB0aGUNCiAgIHVuZGVybHlpbmcgY29uc2lkZXJhdGlvbnMgb2YgcmVj cmVhdGluZyB0aGUgY3VycmVudCBzdGF0ZSBvZiB0aGUNCiAgIHJlY2VpdmVyIGF0IHRoZSB0cmFu c21pdHRlci4NCg0KDQoNCg0KDQoNCg0KU2FiYXRpbmkgICAgICAgICAgICAgICAgICBFeHBpcmVz IE1hcmNoIDEsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgICAgICAgVERMQyBUaGVvcnkgICAgICAgICAgICAgICAgICAgQXVndXN0IDIw MTINCg0KDQozLiAgVW5kZXJseWluZyBDb25jZXB0cw0KDQogICBJbiBvcmRlciBmb3IgYSBzZW5k ZXIgdG8ga25vdyBob3cgdG8gb3B0aW1hbGx5IHRyYW5zbWl0IG1lc3NhZ2VzIHRvIGENCiAgIHJl Y2VpdmVyIHRoZSBzZW5kZXIgbXVzdCByZWNyZWF0ZSB0aGUgc3RhdGUgb2YgdGhlIHJlY2VpdmVy IGFzIG9mIHRoZQ0KICAgbGFzdCBhY2tub3dsZWRnZW1lbnQgcmVjZWl2ZWQgYW5kIHRoZW4gImFn ZSIgb3IgbW9kaWZ5IHRoYXQgc3RhdGUgYnkNCiAgIHVwZGF0aW5nIGl0IGJhc2VkIHVwb24gdGhl IG1lc3NhZ2VzIHNlbnQgc2luY2UgdGhlIHN0YXRlIGltcGxpY2l0IGluDQogICB0aGUgYWNrbm93 bGVkZ2VtZW50IHdhcyBjdXJyZW50LiAgSW4gb3JkZXIgdG8gZG8gdGhpcyB0aGUgc2VuZGVyIG11 c3QNCiAgIG1haW50YWluIGEgdHJhbnNtaXNzaW9uIG9yZGVyIGJ1ZmZlciB3aGljaCBsaXN0cyB0 aGUgbWVzc2FnZSBudW1iZXINCiAgIG9mIGVhY2ggbWVzc2FnZSBhcyBpdCBpcyBzZW50LiAgSW4g VERMQyB3ZSBjYWxsZWQgdGhlIGluZGV4IGludG8gdGhlDQogICB0cmFuc21pc3Npb24gb3JkZXIg YnVmZmVyICJTZW5kIFN0YXRlIiBhbmQgdHJhbnNtaXR0ZWQgdGhpcyBzdGF0ZQ0KICAgdmFyaWFi bGUgd2l0aCBlYWNoIG1lc3NhZ2UuICBUaGUgcmVjZWl2ZXIsIGFmdGVyIGNvcnJlY3RseSByZWNl aXZpbmcNCiAgIHRoZSBtZXNzYWdlLCBzYXZlcyB0aGlzIHZhbHVlIGFuZCByZXR1cm5zIGl0IChu b3cgY2FsbGVkICJSZXR1cm5lZA0KICAgU3RhdGUiKSBhbmQgdGhlIGxpc3Qgb2Ygb3V0c3RhbmRp bmcgbWVzc2FnZXMgYW5kIHRoZWlyIHN0YXR1cyB3aXRoDQogICBlYWNoIGFja25vd2xlZGdlbWVu dC4gIFdoZW4gdGhlIHNlbmRlciByZWNlaXZlcyB0aGlzIGluZm9ybWF0aW9uIGl0DQogICBpcyB0 aGVuIGNhcGFibGUgb2YgY29uc3RydWN0aW5nIGEgbGlzdCBvZiBtaXNzaW5nIG1lc3NhZ2VzIGJ5 IHRha2luZw0KICAgdGhlIGxpc3Qgb2Ygc3VjaCBtZXNzYWdlcyBmcm9tIHRoZSByZWNlaXZlZCBh Y2tub3dsZWRnZW1lbnQgYW5kIHRoZW4NCiAgIHJlbW92aW5nIGZyb20gdGhhdCBsaXN0IGFsbCBt ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiB0cmFuc21pdHRlZCBzaW5jZQ0KICAgdGhlIG1lc3NhZ2Ug d2hpY2ggY2F1c2VkIHRoZSBhY2tub3dsZWRnZW1lbnQgd2hpY2ggaXMgYWxsIG1lc3NhZ2VzDQog ICBzZW50IHdpdGggaW5kZXhlcyBiZXR3ZWVuIHRoZSBjdXJyZW50ICJTZW5kIFN0YXRlIiBhbmQg dGhlICJSZXR1cm5lZA0KICAgU3RhdGUiIGluIHRoZSBhY2tub3dsZWRnZW1lbnQgbWVzc2FnZS4g IFRoZSBsaXN0IG9mIG91dHN0YW5kaW5nDQogICBtZXNzYWdlcyBpcyBzZW50IGFzIHR3byBpbmRl eGVzIGFuZCBhIGJpdCBhcnJheSB3aG9zZSBsZW5ndGggaXMgdGhlDQogICBkaWZmZXJlbmNlIGJl dHdlZW4gdGhlc2UgdHdvIGluZGV4ZXMuICBUaGUgZmlyc3QgaW5kZXggaXMgdGhlICJOZXh0DQog ICBDb25maXJtZWQiLCB0aGlzIHZhbHVlIGNvbmZpcm1zIHRoYXQgYWxsIG1lc3NhZ2VzIHVwIHRv IChidXQgbm90DQogICBpbmNsdWRpbmcpIHRoaXMgdmFsdWUgaGF2ZSBiZWVuIHJlY2VpdmVkIGNv cnJlY3RseS4gIFRoZSBzZWNvbmQgaW5kZXgNCiAgIGlzIHRoZSB2YWx1ZSBvZiB0aGUgIk5leHQg SGlnaGVzdCIgd2hpY2ggaXMgdGhlIGhpZ2hlc3QgbWVzc2FnZQ0KICAgbnVtYmVyIHJlY2VpdmVk IHBsdXMgb25lLiAgVGhlIHJlYXNvbiB0aGF0IHRoZXNlIGFyZSBib3RoICJwbHVzIG9uZSINCiAg IGlzIHRvIGZhY2lsaXRhdGUgbGluayBzdGFydCB3aGVyZSB0aGVyZSBhcmUgbm8gcHJldmlvdXMg bWVzc2FnZXMgYW5kDQogICB0aHVzIHRoZSB2YWx1ZXMgd291bGQgYmVjb21lIHVuZGVmaW5lZC4g IFRoZSBiaXQgYXJyYXkgaGFzIGEgb25lIGJpdA0KICAgaWYgdGhlIG1lc3NhZ2UgaXMgYmVpbmcg YWNrbm93bGVkZ2VkOyBhIHplcm8gaWYgaGFzIG5vdCBiZWVuDQogICByZWNlaXZlZC4NCg0KICAg VGh1cyBieSB0cmFuc21pdHRpbmcgdGhlIGNvbXBsZXRlIGFja25vd2xlZGdlbWVudCBpbmZvcm1h dGlvbiBmcm9tDQogICB0aGUgcmVjZWl2ZXIgYWxvbmcgd2l0aCBhbiBpbmRpY2F0b3IgdG8gdGhl IHNlbmRlciBhcyB0byBpdHMgc3RhdGUNCiAgIGN1cnJlbnQgYXQgdGhlIHRpbWUgb2YgdGhlIGFj a25vd2xlZGdlbWVudCB0aGUgc2VuZGVyIGNhbiBhY2N1cmF0ZWx5DQogICByZWNyZWF0ZSB0aGUg Y3VycmVudCBzdGF0dXMgb2YgdGhlIHJlY2VpdmVyIGFzc3VtaW5nIGFsbCAiaW4gZmxpZ2h0Ig0K ICAgbWVzc2FnZXMgd2VyZSByZWNlaXZlZCBhbmQgdGh1cyBvbmx5IHNlbmQgdGhlIHVuYWNrbm93 bGVkZ2VkIG1lc3NhZ2VzDQogICBzdGFydGluZyB3aXRoIHRoZSBvbGRlc3QgYWxvbmcgd2l0aCBh bnkgbmV3IG1lc3NhZ2VzIHdob3NlDQogICByZXRyYW5zbWlzc2lvbiBpcyByZXF1ZXN0ZWQuDQoN Cg0KNC4gIFRoZSBIRExDIChvciBYLjI1KSBwcm90b2NvbA0KDQogICBBbGwgIlNlbGVjdGl2ZSBS ZXBlYXQiIHByb3RvY29scyBtdXN0IHJlY3JlYXRlIHRoZSBzdGF0ZSBvZiB0aGUNCiAgIHJlY2Vp dmVyIGFuZCB1bHRpbWF0ZWx5IGltcGxlbWVudCwgcGVyaGFwcyBpbXBsaWNpdGx5LCB0aGUgY29u Y2VwdHMNCiAgIG91dGxpbmVkIGFib3ZlLiAgSXQgaXMgdGhlcmVmb3JlIGluc3RydWN0aXZlIHRv IGxvb2sgYXQgaG93IEhETEMNCiAgIGFjdHVhbGx5IHdvcmtzLiAgT25lIG9mIHRoZSBsZWFzdCB1 bmRlcnN0b29kIGFzcGVjdHMgb2YgdGhpcyBwcm90b2NvbA0KICAgaXMgdGhhdCB0aGUgcmVjZWl2 ZSBzZXF1ZW5jZSBudW1iZXIgcGVyZm9ybXMgdGhyZWUgZnVuY3Rpb25zDQogICBzaW11bHRhbmVv dXNseSwgaXQgcHJvdmlkZXMgYSBmbG9vciBmb3IgdGhlIGFja25vd2xlZGdlbWVudCBzeXN0ZW0N Cg0KDQoNClNhYmF0aW5pICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAxLCAyMDEzICAg ICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAg IFRETEMgVGhlb3J5ICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDEyDQoNCg0KICAgKGl0IGFj a25vd2xlZGdlcyBhbGwgbWVzc2FnZXMgdXAgdG8gdGhpcyBvbmUpLCBpdCBpbmRpY2F0ZXMgdGhl IGxhc3QNCiAgIG1lc3NhZ2UgcmVjZWl2ZWQgY29ycmVjdGx5IChoaWdoZXN0IGluIHNlcXVlbmNl KSBhbmQgaXQgZXN0YWJsaXNoZXMNCiAgIHRoZSBzZXF1ZW5jZSBvZiB0aGUgbWVzc2FnZXMgcmVj ZWl2ZWQgKGFuZCB0aHVzIHRyYW5zbWl0dGVkKS4gIFRoaXMNCiAgIGlzIGFjY29tcGxpc2hlZCBi eSB0aGUgcnVsZXMgb2YgaXRzIHVzZS4gIFNpbmNlIHlvdSBvbmx5IGV2ZXINCiAgIGFja25vd2xl ZGdlIHRoZSBsYXN0IGluIHNlcXVlbmNlIG1lc3NhZ2UgeW91IHJlY2VpdmVkLCB5b3UgaW1wbGlj aXRseQ0KICAgYWNrbm93bGVkZ2UgYWxsIHRoYXQgcHJlY2VkZWQgaXQuICBTaW5jZSBIRExDIGlz IGEgIkdPIEJBQ0sgTiINCiAgIHByb3RvY29sLCB0aGUgc2VxdWVuY2Ugb2YgdGhlIG1lc3NhZ2Vz IGlzIGFsd2F5cyBpZGVudGljYWwgdG8gdGhlDQogICBvcmRlciBvZiB0cmFuc21pc3Npb24gKHlv dSBkaXNjYXJkIHRob3NlIG1lc3NhZ2VzIHdoaWNoIGFyZSBvdXQgb2YNCiAgIG1lc3NhZ2Ugc2Vx dWVuY2UpLiAgRXZlbiB3aXRoIHRoZSBpbmNsdXNpb24gb2YgYSBzZWxlY3RpdmUgcmVqZWN0DQog ICBjb25zdHJ1Y3QgeW91IGNhbiBvbmx5IHNlbGVjdGl2ZWx5IHJlamVjdCB0aGUgZmlyc3QgcG9z c2libGUgbWlzc2luZw0KICAgbWVzc2FnZSAodGhlIG1lc3NhZ2UgYXQgIk4iKS4NCg0KICAgVGh1 cyB0byBwcm92aWRlIGFueSBlbmhhbmNlbWVudHMgdG8gdGhpcyBjbGFzcyBvZiBwcm90b2NvbHMs IGFzIHdlDQogICBoYXZlIGRvbmUgaW4gVERMQywgd2UgbXVzdCBmaXJzdCBzcGxpdCB0aGVzZSBm dW5jdGlvbnMgaW50byB0aHJlZQ0KICAgc2VwYXJhdGUgZW50aXRpZXMsIG5hbWVseSBhICJDb25m aXJtZWQiIHdoaWNoIGluZGljYXRlcyB0aGF0IGFsbCB0aGUNCiAgIG1lc3NhZ2VzIHVwIHRocm91 Z2ggdGhpcyBvbmUgaGF2ZSBiZWVuIHJlY2VpdmVkIHByb3Blcmx5LCBhICJIaWdoZXN0DQogICBS ZWNlaXZlZCIgd2hpY2ggaW5kaWNhdGVzIHRoZSBoaWdoZXN0IG1lc3NhZ2UgbnVtYmVyIG9mIGFu eSBtZXNzYWdlDQogICBwcm9wZXJseSByZWNlaXZlZCB0aGF0IGlzIHdpdGhpbiB0aGUgd2luZG93 LCBhbmQgYSBzZXF1ZW5jZSBzdGF0ZQ0KICAgdG9rZW4gd2hpY2ggZGVub3RlcyB0aGUgb3JkZXIg aW4gd2hpY2ggdGhlIG1lc3NhZ2VzIHdlcmUgc2VudC4NCg0KDQo1LiAgQ29uc2lkZXJhdGlvbnMg aW4gZGVzaWduaW5nIFRETEMNCg0KNS4xLiAgUmUtVHJhbnNtaXNzaW9uDQoNCiAgIEdpdmVuIHRo YXQgd2UgbXVzdCByZXRyYW5zbWl0IGEgc2VyaWVzIG9mIG1lc3NhZ2VzIHdob3NlIG51bWJlcg0K ICAgY2VydGFpbmx5IGV4Y2VlZHMgOCwgd2UgbXVzdCBmaW5kIHNvbWUgY29udmVuaWVudCBidXQg Y29tcGFjdA0KICAgbWV0aG9kb2xvZ3kgdG8gZXhwcmVzcyB3aGljaCBtZXNzYWdlcyBuZWVkIHRv IGJlIHJlLXRyYW5zbWl0dGVkLiAgVGhlDQogICB0d28gbW9zdCBvYnZpb3VzIGFyZSBlaXRoZXIg YSBiaXQgbWFwIG9yIG9yZGVyZWQgcGFpcnMgb2YgaW5kZXhlcy4NCiAgIFNpbmNlIHRoZXJlIGlz IGEgaGlnaCBwcm9iYWJpbGl0eSB0aGF0IHRoZSBudW1iZXIgb2YgbWVzc2FnZXMgd2hpY2gNCiAg IG5lZWRzIHRvIGJlIHRyYW5zbWl0dGVkIGlzIGZhaXJseSBzbWFsbCwgdGhlIG1vc3QgY29tcGFj dCBzeXN0ZW0sIGENCiAgIGJpdCBtYXAsIHdhcyBjaG9zZW4uICBTaW5jZSBpdCBpcyBpbmVsZWdh bnQgdG8gc2VuZCBtb3JlIGJpdHMgdGhhbg0KICAgYXJlIGFjdHVhbGx5IG5lZWRlZCB3ZSBzaG91 bGQgb25seSB0cmFuc21pdCB0aG9zZSBiaXRzIGJldHdlZW4gdGhlDQogICBsaW1pdHMgIk5leHQg Q29uZmlybWVkIiBhbmQgIk5leHQgaGlnaGVzdCByZWNlaXZlZCIuICBBbHRob3VnaCBpdCBoYXMN CiAgIGJlZW4gZm91bmQgbW9yZSBwcmFjdGljYWwgdG8gdHJhbnNtaXQgYWxsIG9mIHRoZXNlIGJp dHMsIG9uZSBuZWVkIG5vdA0KICAgc2VuZCB0aGUgYml0IGZvciAiTmV4dCBDb25maXJtZWQiLCB3 aGljaCBieSBkZWZpbml0aW9uIHlvdSBrbm93IGlzDQogICBtaXNzaW5nLiAgIkhpZ2hlc3QgUmVj ZWl2ZWQiIGlzIGEgZGlmZmVyZW50IGNhc2Ugc2luY2UgaXQgbWF5IGhhdmUNCiAgIGJlZW4gc2V0 IGJ5IGFuICJSUiIgbWVzc2FnZSBhbmQgdGh1cyB0aGUgbWVzc2FnZSBpdHNlbGYgbWF5IG5vdCBo YXZlDQogICBiZWVuIHJlY2VpdmVkLg0KDQo1LjIuICBTZXF1ZW5jZSBzdGF0ZQ0KDQogICBPbmUg cHJvcGVydHkgb2YgYW55IHRyYW5zbWlzc2lvbiBlbnZpcm9ubWVudCB3aGljaCBpcyBvZnRlbiBp Z25vcmVkDQogICBpcyB0aGF0IG9mIGRlbGF5LiAgRXZlbiBvbiBhIGxvY2FsbHkgYXR0YWNoZWQg bGluayB0aGUgdGltZSBpbnZvbHZlZA0KICAgaW4gcGh5c2ljYWxseSBzZW5kaW5nIGFuZCByZWNl aXZpbmcgdGhlIG1lc3NhZ2UgYWxvbmcgd2l0aCB0aGUgZGVsYXkNCiAgIGJlZm9yZSBpdCBpcyBh Y3R1YWxseSBwcm9jZXNzZWQgaW50cm9kdWNlcyBhbiBlbGVtZW50IG9mIHVuY2VydGFpbnR5DQog ICBhcyB0byB3aGF0IHRoZSBvdGhlciBlbmQgb2YgdGhlIGxpbmsgaXMgZG9pbmcsIHdoYXQgbWVz c2FnZXMgaXQgaGFzDQogICBzZWVuIGFuZCB3aGV0aGVyIGl0IGhhcyByZWNlaXZlZCBhIHJlcXVl c3QgZm9yIHJldHJhbnNtaXNzaW9uLiAgVGhpcw0KDQoNCg0KU2FiYXRpbmkgICAgICAgICAgICAg ICAgICBFeHBpcmVzIE1hcmNoIDEsIDIwMTMgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgVERMQyBUaGVvcnkgICAgICAgICAgICAgICAg ICAgQXVndXN0IDIwMTINCg0KDQogICBwcm9ibGVtIGNhbiBiZSBzb2x2ZWQgcmVsYXRpdmVseSBl YXNpbHkgYnkgaW5jbHVkaW5nIGEgc2VxdWVuY2Ugc3RhdGUNCiAgIGluZGV4IHdpdGggZWFjaCBt ZXNzYWdlIHNlbnQuICBUaGlzIHRva2VuLCB3aGljaCBpcyByZXR1cm5lZCB3aXRoIHRoZQ0KICAg bmV4dCB0cmFuc21pc3Npb24gZnJvbSB0aGUgb3RoZXIgZW5kIG9mIHRoZSBsaW5rLCB0ZWxscyB0 aGUNCiAgIHRyYW5zbWl0dGVyIHdoaWNoIG1lc3NhZ2VzIHdlcmUgc2VudCBhZnRlciB0aGUgcG9p bnQgdGhhdCB0aGUNCiAgIHJlY2VpdmVyIGlzIGFja25vd2xlZGdpbmcuICBUaHVzIGVhY2ggbWVz c2FnZSBiZWluZyB0cmFuc21pdHRlZCwNCiAgIHdoZXRoZXIgYW4gb3JpZ2luYWwgdHJhbnNtaXNz aW9uIG9yIGEgcmUtdHJhbnNtaXNzaW9uLCBpbmNyZW1lbnRzIHRoZQ0KICAgc2VxdWVuY2Ugc3Rh dGUuICBCeSBtYWludGFpbmluZyBhIHZlY3Rvciwgd2hvc2UgaW5kZXggaXMgc2VxdWVuY2UNCiAg IHN0YXRlLCBvZiB0aGUgbWVzc2FnZSBudW1iZXJzIGluIHRoZSBvcmRlciBpbiB3aGljaCB0aGUg bWVzc2FnZXMgd2VyZQ0KICAgdHJhbnNtaXR0ZWQgb3IgcmV0cmFuc21pdHRlZCwgd2hlbiB0aGUg c2VxdWVuY2Ugc3RhdGUgaXMgcmV0dXJuZWQgdG8NCiAgIHRoZSB0cmFuc21pdHRpbmcgZW5kLCB0 aGUgdHJhbnNtaXR0ZXIga25vd3Mgd2hpY2ggbWVzc2FnZXMgdGhlDQogICByZWNlaXZlciBzaG91 bGQgaGF2ZSBzZWVuIGFuZCBpZiB0aGUgcmVjZWl2ZXIgc3RpbGwgaW5kaWNhdGVzIHRoYXQgaXQN CiAgIGhhcyBub3QgeWV0IHJlY2VpdmVkIGEgcGFydGljdWxhciBtZXNzYWdlIHRoYXQgd2FzIHRy YW5zbWl0dGVkIHRoZW4NCiAgIGl0IG11c3QgYmUgcXVldWVkIGZvciB0cmFuc21pc3Npb24gYWdh aW4uDQoNCiAgIEluIGEgcHJhY3RpY2FsIGFwcGxpY2F0aW9uIG9mIHRoaXMgdGVjaG5vbG9neSwg YSBiaXQgbWFwDQogICBjb3JyZXNwb25kaW5nIHRvIGFsbCBtZXNzYWdlIG51bWJlcnMgaXMga2Vw dCBieSB0aGUgdHJhbnNtaXR0ZXIuICBBcw0KICAgZWFjaCBtZXNzYWdlIGlzIGFkZGVkIHRvIHRo ZSBxdWV1ZSB0byBiZSB0cmFuc21pdHRlZCwgaXRzDQogICBjb3JyZXNwb25kaW5nIGJpdCBpbiB0 aGUgYml0IG1hcCBpcyB0dXJuZWQgb2ZmLCBhbmQgYXMgaXQgaXMNCiAgIHRyYW5zbWl0dGVkIGl0 IGlzIHR1cm5lZCBvbi4gIFdoZW4gYSBiaXQgbWFwIHJlcHJlc2VudGluZyBtZXNzYWdlDQogICBz dGF0dXMgaXMgcmVjZWl2ZWQsIHRoZSBiaXRzIGZvciBhbGwgdW5hY2tub3dsZWRnZWQgbWVzc2Fn ZXMgYXJlDQogICB0dXJuZWQgb2ZmIGluIHRoZSB0cmFuc21pdHRlciBiaXRtYXAuICBUaGVuIHVz aW5nIHRoZSByZWNlaXZlZCBzdGF0ZQ0KICAgYXMgYW4gaW5kZXggaW50byB0aGUgdmVjdG9yIG9m IHRyYW5zbWl0dGVkIG1lc3NhZ2VzLCBhbnkgbWVzc2FnZXMNCiAgIHRoYXQgdGhlIHRyYW5zbWl0 dGVyIGhhcyBzZW50IHNpbmNlIHRoZW4gYXJlIHR1cm5lZCBiYWNrIG9uLiAgVGhlIGJpdA0KICAg bWFwIG9mIG91dGdvaW5nIG1lc3NhZ2VzIGlzIHRoZW4gcmVzY2FubmVkIHN0YXJ0aW5nIGF0IG1l c3NhZ2UgIk5leHQNCiAgIENvbmZpcm1lZCIgYW5kIHRoZSBtZXNzYWdlIGFzc29jaWF0ZWQgd2l0 aCB0aGUgZmlyc3QgemVybyBiaXQgaXMgc2V0DQogICBhcyB0aGUgbmV4dCBtZXNzYWdlIHRvIHRy YW5zbWl0LiAgVGhlIHRyYW5zbWl0dGluZyBwcm9jZXNzIHRoZW4NCiAgIGNvbnRpbnVlcyBwcm9j ZXNzaW5nIHRoZSBiaXQgbWFwIHRyYW5zbWl0dGluZyBtZXNzYWdlcyB3aGljaCBoYXZlIGENCiAg IHplcm8gYml0IHVudGlsIGl0IHJlYWNoZXMgIk5leHQgSGlnaGVzdCBRdWV1ZWQiLg0KDQogICBB IHZhcmlhbnQgb2YgVERMQyBmb3IgaGlnaGVyIHNwZWVkIGxpbmtzIHdhcyBkZXNpZ25lZCB3aGlj aCB1c2VkIHR3bw0KICAgYnl0ZSBtZXNzYWdlIG51bWJlcnMgYW5kIGEgbGlzdCBvZiBhY2tub3ds ZWRnZWQgbWVzc2FnZSByYW5nZXMgaW4NCiAgIHBsYWNlIG9mIHRoZSBiaXQgbWFwIGluIHRoZSBv cmlnaW5hbCBwcm90b2NvbA0KDQo1LjMuICBUcmFuc21pdCBzZXF1ZW5jZSBudW1iZXJpbmcNCg0K ICAgT25lIHByb2JsZW0gYXNzb2NpYXRlZCB3aXRoIFNETEMgd2hpY2ggZG9lcyBub3QgZXhpc3Qs IGZvciBleGFtcGxlLA0KICAgaW4gREVDTkVUIGlzIHRoYXQgb2YgbG9zaW5nIHRoZSBsYXN0IG1l c3NhZ2Ugb3Igc2VyaWVzIG9mIG1lc3NhZ2VzDQogICB3aXRoIG5vIGluZGljYXRpb24gdW50aWwg dGhlIGxpbmsgdGltZXMgb3V0LiAgVGhpcyBpcyBhIHNtYWxsIHByb2JsZW0NCiAgIGF0IGxvdyBk YXRhIHJhdGVzIGFuZCBzaG9ydCB0cmFuc21pc3Npb24gZGVsYXkgZW52aXJvbm1lbnRzLCBidXQg Y2FuDQogICBzZXZlcmVseSBkZWdyYWRlIHRoZSBsaW5rIHVuZGVyIGFueSBvdGhlciBjaXJjdW1z dGFuY2VzLiAgVGhpcyBpcyBkdWUNCiAgIHRvIHRoZSBmYWN0IHRoYXQgb25seSB0aGUgIkkiIGZy YW1lIGhhcyBhIHRyYW5zbWl0IHNlcXVlbmNlIG51bWJlciBhcw0KICAgd2VsbCBhcyBhIHJlY2Vp dmUgc2VxdWVuY2UgbnVtYmVyLCB0aHVzIHRoZXJlIGlzIG5vIHdheSB0byB0ZWxsIGZyb20NCiAg IHRoZSAibGluayBpZGxlIiBSUiB0aGF0IGEgbWVzc2FnZSBpcyBpbiBmYWN0IG1pc3NpbmcuICBU aGUgb2J2aW91cw0KICAgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtIGlzIHRvIGluY2x1ZGUgYSBz ZWNvbmQsIHRyYW5zbWl0IHNlcXVlbmNlDQogICBudW1iZXIgb24gdGhlICJSUiIsICJSRUoiIGFu ZCAiU1JFSiIgcGFja2V0cyAod2hpY2ggYXJlIHZlcnkgc2hvcnQNCiAgIGFueXdheSkgdG8gZmFj aWxpdGF0ZSByZWNvdmVyeS4gIEluIFRETEMgd2UgdHJlYXQgYWxsIG1lc3NhZ2VzLA0KICAgd2hl dGhlciBkYXRhIGNhcnJ5aW5nIG9yIG5vdCwgZXF1YWxseSB0aHVzIHRoZSBjb21wbGV0ZSBzdGF0 ZSBpcw0KICAgdHJhbnNtaXR0ZWQgd2l0aCBlYWNoIG1lc3NhZ2UuICBTaW5jZSB3ZSBhcmUgc2Vu ZGluZyB0aGUgY29tcGxldGUNCg0KDQoNClNhYmF0aW5pICAgICAgICAgICAgICAgICAgRXhwaXJl cyBNYXJjaCAxLCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgIFRETEMgVGhlb3J5ICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAy MDEyDQoNCg0KICAgc3RhdGUgb25seSBhICJSUiIgbWVzc2FnZSBpcyBuZWVkZWQsIHRoZSAiUkVK IiBhbmQgIlNSRUoiIGFyZQ0KICAgaW1wbGljaXQuDQoNCjUuNC4gIFdpbmRvdyBTaXplDQoNCiAg IE9uZSBjb25jZXB0IHRoYXQgaGFzIG5vdCBiZWVuIHdlbGwgZXhwbG9yZWQgZm9yICJHTyBCQUNL IE4iIHByb3RvY29scw0KICAgaXMgdGhlIGVmZmVjdCBvZiB3aW5kb3cgc2l6ZSBvbiBkYXRhIHJl Y292ZXJ5LiAgV2hlbiBub3QgZXhwbGljaXRseQ0KICAgYWNrbm93bGVkZ2luZyBhbGwgbWVtYmVy cyBpbiBhIHNlcXVlbmNlLCBidXQgcmF0aGVyIGluZGl2aWR1YWwNCiAgIG1lc3NhZ2VzIHlvdSBj cmVhdGUgYSB6b25lIG9mIHVuY2VydGFpbnR5IGFzIHRvIHdoaWNoIG1lc3NhZ2UgbnVtYmVycw0K ICAgYXJlIG1lcmVseSBsYXRlIGFja25vd2xlZGdtZW50cyBvciByZXRyYW5zbWlzc2lvbnMgYW5k IHdoaWNoIGFyZQ0KICAgZXJyb3JlZCBidXQgQ1JDIGNvcnJlY3QgbWVzc2FnZXMgKGVpdGhlciB0 aHJvdWdoIHRoZSB0cmFuc21pc3Npb24NCiAgIG1lZGlhIG9yIHByb2dyYW0gcHJvYmxlbSkuICBU aHVzIGJlY2F1c2Ugb2YgdGhlc2UgdHdvIGZlYXR1cmVzIG9uZQ0KICAgbXVzdCBhc3N1bWUgYSBt aW5pbXVtIG9mIGEgIndpbmRvdy1zaXplIiBsZWFkaW5nIGFuZCBhICJ3aW5kb3ctc2l6ZSINCiAg IHRyYWlsaW5nIGludGVydmFsIGluIHdoaWNoIHRoZSBtZXNzYWdlIG51bWJlciBjYW4gbGVnYWxs eSByZXNpZGUuDQogICBUaHVzIHdpdGggTk8gcHJvdGVjdGlvbiBmcm9tIGVycm9yZWQgbWVzc2Fn ZXMsIHRoZSB3aW5kb3cgc2l6ZSBjYW4gYmUNCiAgIGF0IG1vc3QgaGFsZiB0aGUgbWVzc2FnZSBt b2R1bHVzIGFuZCBnb29kIHByYWN0aWNlLCBiZWNhdXNlIGl0IGlzDQogICBlYXNpZXIgYW5kIGZh c3RlciB0byBkZWFsIHdpdGggcG93ZXJzIG9mIDIsIGRpY3RhdGVzIHdlIHNob3VsZCBrZWVwDQog ICBpdCBhdCBvbmUgcXVhcnRlciBvZiBtb2R1bHVzLCB0aHVzIGFsbG93aW5nIHVzIHRvIGtub3cg d2l0aCBjZXJ0YWludHkNCiAgIHRoYXQgbWVzc2FnZXMgb3V0c2lkZSBvZiB0aGlzIHJhbmdlIHNo b3VsZCBiZSBpZ25vcmVkLg0KDQo1LjUuICBDb25uZWN0aW9uIGFuZCBSZS1Db25uZWN0aW9uDQoN CiAgIE9uZSBvZiB0aGUga25vd24gcHJvYmxlbXMgaW4gU0RMQyBpcyB0aGF0IG9mIGxpbmsgZXN0 YWJsaXNobWVudC4gIEluDQogICBub3JtYWwgU0RMQyBzaW5jZSB0aGVyZSBpcyBubyBpbmZvcm1h dGlvbiBwYXNzZWQgaW4gdGhlIFNBQk0gcGFja2V0DQogICBvdGhlciB0aGFuIHRoZSByZXF1ZXN0 IGZvciBjb25uZWN0aW9uLCBpdCBpcyBpbXBvc3NpYmxlIHRvIGV4cGxpY2l0bHkNCiAgIHRpZSBV QSByZXBsaWVzIHRvIHRoZWlyIHJlc3BlY3RpdmUgU0FCTSBvdGhlciB0aGFuIGJ5IGFsbG93aW5n DQogICBzdWZmaWNpZW50IHRpbWUgdG8gZWxhcHNlIHN1Y2ggdGhhdCBpdCBpcyBpbXBvc3NpYmxl IGZvciBtb3JlIHRoYW4NCiAgIG9uZSBTQUJNIG9yIFVBIHRvIGJlIG91dHN0YW5kaW5nIChpbnRl cmVzdGluZ2x5IHRoZSBzYW1lIGVycm9yDQogICByZXNvbHV0aW9uIGJ5IHdhaXRpbmcgZm9yIGV4 dGVuZGVkIHBlcmlvZHMgaXMgdGhlIHVsdGltYXRlIGhlYXJ0IG9mDQogICBhbGwgQmluYXJ5IFN5 bmNocm9ub3VzIFByb3RvY29scykuICBUaGlzIGxlYWRzIHRvIGV4Y2Vzc2l2ZSBsaW5lIHRpbWUN CiAgIG9uIGxvbmcgZGVsYXkgY2lyY3VpdHMgYW5kIHN0aWxsIGRvZXMgbm90IGd1YXJkIGFnYWlu c3QgU0FCTQ0KICAgY29sbGlzaW9ucyB3aGVyZSBlYWNoIHNpZGUgaW5pdGlhbGl6ZXMgc2VwYXJh dGVseSBhbmQgdHJpZXMgdG8gc2VuZA0KICAgU0FCTSdzIHNpbXVsdGFuZW91c2x5LiAgVGhpcyBw cm9ibGVtIHdvdWxkIGp1c3QgYmUgb2YgdGhlb3JldGljYWwNCiAgIGludGVyZXN0IGlmIGl0IG9u bHkgb2NjdXJyZWQgd2hlbiBvbmUgc2lkZSBvciB0aGUgb3RoZXIgYWNjb21wbGlzaGVkDQogICBh IHBoeXNpY2FsIHJlc3RhcnQgb2YgdGhlIGxpbmssIGhvd2V2ZXIgd2l0aCB0aGUgbGFjayBvZiBh IGxvZ2ljYWwNCiAgIHJlc3RhcnQgbWVjaGFuaXNtIHRoZSBwaHlzaWNhbCByZXN0YXJ0IHVzaW5n IFNBQk0gb2NjdXJzIG11Y2ggbW9yZQ0KICAgZnJlcXVlbnRseSBpbiB0aGUgcmVhbCB3b3JsZCBh bmQgcmVzdWx0cyBpbiBhIHRvdGFsIGRlc3RydWN0aW9uIGFuZA0KICAgcmUtZXN0YWJsaXNobWVu dCBvZiB0aGUgbGluayBldmVyeSB0aW1lIHRoZXJlIGlzIGEgY29tbXVuaWNhdGlvbnMNCiAgIGlu dGVycnVwdGlvbiB3aGljaCBleGNlZWRzIHRoZSBsaW1pdHMgb2YgaXQncyB0aW1lcnMgYXMgb2Z0 ZW4gaGFwcGVucw0KICAgd2l0aCBub2lzeSBzYXRlbGxpdGUgZW52aXJvbm1lbnRzIG9yIGZyYW1l IHJlbGF5IHRyYW5zbWlzc2lvbnMgaW4gYQ0KICAgY29uZ2VzdGVkIGVudmlyb25tZW50LiAgQW5v dGhlciBmcmlnaHRmdWwgYnktcHJvZHVjdCBvZiB0aGlzIGJlaGF2aW9yDQogICBpcyB0aGF0IG9m IHRoZSBsaW5rIGxheWVyIG9mIEhETEMgbWFrZXMgdW4tT1NJIGRlbWFuZHMgb24gdGhlIGxheWVy cw0KICAgYWJvdmU7IGRlbGl2ZXJpbmcgcmVzdGFydCBpbmRpY2F0aW9ucyBhbGwgdGhlIHdheSB1 cCB0aHJvdWdoIHRoZQ0KICAgcHJvdG9jb2wgc3RhY2suICBUaGUgYW5zd2VyIHRvIHRoZXNlIHBy b2JsZW1zIGlzIHRoZSBpbnRyb2R1Y3Rpb24gb2YNCiAgIHR3byBuZXcgY29tbWFuZHMgYW5kIHR3 byBuZXcgcmVwbGllcywgIklOSVRJQUwgQ09OTkVDVCIgKElDTiksICJSRS0NCiAgIENPTk5FQ1Qi IChSQ04pLCAiSU5JVElBTCBDT05ORUNUIEFDS05PV0xFREdFIiAoSUNBKSwgYW5kICJSRS1DT05O RUNUDQogICBBQ0tOT1dMRURHRSIgKFJDQSkuICBUaGVzZSBuZXcgY29tbWFuZHMgYWxsb3cgdGhl IGNvbm5lY3RlZCBsaW5rDQogICBsYXllcnMgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGEgUGh5 c2ljYWwgUmVzdGFydCBieSB1c2luZyBhbiBJQ04NCg0KDQoNClNhYmF0aW5pICAgICAgICAgICAg ICAgICAgRXhwaXJlcyBNYXJjaCAxLCAyMDEzICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgIFRETEMgVGhlb3J5ICAgICAgICAgICAgICAg ICAgIEF1Z3VzdCAyMDEyDQoNCg0KICAgY29tbWFuZCBvciBhbiBJQ0EgcmVwbHkgYW5kIGEgTG9n aWNhbCBSZXN0YXJ0IGJ5IHVzaW5nIGEgUkNOIGNvbW1hbmQNCiAgIG9yIGEgUkNBIHJlcGx5LiAg V2hlbiBhIGxpbmsgaXMgcmUtZXN0YWJsaXNoZWQgYWZ0ZXIgYW4gaW50ZXJydXB0aW9uLA0KICAg dGhlIGV4Y2hhbmdlIG9mIFJDTi9SQ0EgcmVjb25uZWN0cyB0aGUgbGluayB3aXRob3V0IGFmZmVj dGluZyB0aGUNCiAgIHVwcGVyIGxheWVycyBvZiB0aGUgcHJvdG9jb2wuICBJZiBlaXRoZXIgc2lk ZSBuZWVkcyB0byBoYXZlIHRoZSBsaW5rDQogICBjb3VudGVycyBpbml0aWFsaXplZCBvciB0aGUg bWVzc2FnZSBidWZmZXJzIGZsdXNoZWQgaXQgbmVlZCBvbmx5IHNlbmQNCiAgIGFuIElDTiBvciwg aW4gcmVzcG9uc2UgdG8gYW4gUkNOLCBhbiBJQ0EgdG8gZm9yY2UgbGluaw0KICAgaW5pdGlhbGl6 YXRpb24uDQoNCiAgIFRvIGd1YXJkIGFnYWluc3QgcG9zc2libGUgbGluayByZS1lc3RhYmxpc2ht ZW50IHdoZXJlIHRoZSBjaXJjdWl0IG1heQ0KICAgaGF2ZSBiZWVuIGxvb3BlZCBiYWNrIGNhdXNp bmcgYWNrbm93bGVkZ21lbnQgYW5kIGRpc3Bvc2FsIG9mIG1lc3NhZ2VzDQogICB0aGF0IHdlcmVu J3QgYWN0dWFsbHkgcmVjZWl2ZWQgYW5kIHRoZSBwb3NzaWJpbGl0eSBvZiB0aGUgcGh5c2ljYWwN CiAgIHN3aXRjaGluZyBvZiBhIGNpcmN1aXQgZnJvbSBvbmUgYWN0aXZlIHBvcnQgdG8gYW5vdGhl ciwgdGhlIGRhdGENCiAgIGZpZWxkIGluIHRoZSBJQ04gb3IgUkNOIGNvbW1hbmQgd2lsbCBoYXZl IGEgcmFuZG9tIGlkZW50aXR5IHN0YW1wIGFuZA0KICAgSUNBIG9yIFJDQSB3aWxsIHJldHVybiB0 aGVzZSBzdGFtcHMgc28gdGhhdCByZXBsaWVzIGNhbiBiZSBtYXRjaGVkLg0KICAgQnkgY29tcGFy aXNvbiBvZiB0aGVzZSBzdGFtcHMgb25lIGNhbiBlc3RhYmxpc2gvZGV0ZXJtaW5lIHRoZQ0KICAg YWJzb2x1dGUgbGluayBzZXNzaW9uIGluZm9ybWF0aW9uLg0KDQo1LjYuICBVc2Ugb2YgUmVjZWl2 ZSBSZWFkeQ0KDQogICBTaW5jZSB0aGUgZ29hbCBvZiBhIHJlYWwgdGltZSBwcm90b2NvbCBpcyB0 byBiZSBldmVudCBkcml2ZW4gKCJBQ0sNCiAgIENsb2NrZWQiIGluIFRDUCBub21lbmNsYXR1cmUp IGFuZCB0aHVzIG11Y2ggbGVzcyBkZXBlbmRlbnQgb24gdGltZXJzDQogICB0byBjb3JyZWN0IG1p c3NpbmcgbWVzc2FnZSBzaXR1YXRpb25zIHRoZSBydWxlcyBvZiBhYm91dCB1c2luZw0KICAgUmVj ZWl2ZSBSZWFkeSBoYXZlIGJlZW4gYnJvYWRlbmVkIGluIG9yZGVyIHRvIG1heGltaXplIHRoZQ0K ICAgcHJvYmFiaWxpdHkgb2YgZXJyb3IgY29ycmVjdGlvbiB3aXRob3V0IHRpbWVyIGV4cGlyYXRp b24uDQoNCiAgIE5vdGUgdGhhdCByZWNlaXZpbmcgYSAiUlIiIHBhY2tldCB3aXRoIGEgY2hhbmdl ZCBzZW5kIHRva2VuIGlzIGENCiAgIGNoYW5nZSBpbiB0aGUgc3RhdGUgb2YgdGhlIHJlY2VpdmVy IHNvIHRoZSByZWNlaXZlciBtdXN0IHJldHVybiBhDQogICAiUlIiIGluIHJlc3BvbnNlLg0KDQog ICBUaGUgZmlyc3QgcnVsZSBhYm91dCB1c2luZyBSZWNlaXZlIFJlYWR5IGlzIHRoYXQgYWZ0ZXIg dGhlIHJlY2VpcHQgb2YNCiAgIGFuIElDQSBvciBSQ0EgcGFja2V0IHRoZSByZWNlaXZpbmcgZW5k IHdpbGwgaW1tZWRpYXRlbHkgc2VuZCBhbiAiUlIiDQogICBwYWNrZXQuICBUaGlzIGlzIGluIG9y ZGVyIHRvIGFsbG93IHRoZSBmYXIgZW5kIHRvIHN0YXJ0IHRyYW5zbWl0dGluZywNCiAgIHRoZSBm YXIgZW5kLCBvbmNlIGl0IGlzIGluIGNvbm5lY3Rpb24gc3RhdGUsIGNhbiBub3QgdHJhbnNtaXQg dW50aWwNCiAgIGFuICJSUiIgaXMgcmVjZWl2ZWQuICBMaWtlIHdpc2UgaWYgYW4gZW5kIHNlbmRz IGFuIElDQSBvciBSQ0EgaXQgbXVzdA0KICAgaW1tZWRpYXRlbHkgZm9sbG93IHdpdGggYSAiUlIi IHRvIGFsbG93IHRoZSBmYXIgZW5kIHRvIHN0YXJ0DQogICB0cmFuc21pdHRpbmcgZGF0YS4NCg0K ICAgVGhlIHNlY29uZCBydWxlIGlzIHRoYXQgYWZ0ZXIgdGhlIHRyYW5zbWlzc2lvbiBvZiB0aGUg bGFzdA0KICAgaW5mb3JtYXRpb24gcGFja2V0ICJJIiBhICJSUiIgcGFja2V0IGlzIGFsd2F5cyBz ZW50LiAgU2luY2UgYSBsb3NzIG9mDQogICB0aGUgbGFzdCBpbmZvcm1hdGlvbiBwYWNrZXQgd2ls bCBub3QgYmUgbm90aWNlZCB1bnRpbCBhICJSUiIgb3IgIkkiDQogICBpcyByZWNlaXZlZCwgaWYg d2Ugc2VuZCBvbmUgaW1tZWRpYXRlbHkgd2UgY2FuIGhlbHAgaW5zdXJlIHRoZQ0KICAgZGV0ZWN0 aW9uIG9mIHRoZSBsb3NzIG9mIHRoZSBsYXN0IGRhdGEgcGFja2V0IGltbWVkaWF0ZWx5Lg0KDQog ICBUaGUgdGhpcmQgcnVsZSBpcyB0aGF0IGlmIHRoZXJlIGFyZSBtZXNzYWdlcyB0aGF0IGFyZSB1 bmFja25vd2xlZGdlZA0KICAgb3IgdW5kZWxpdmVyZWQgYW5kIHRoZSBsaW5rIGhhcyBnb25lIGlk bGUsIGFub3RoZXIgIlJSIiBwYWNrZXQgaXMNCiAgIHNlbnQgYWZ0ZXIgYW4gaW50ZXJ2YWwgVDMg d2hlcmUgVDMgaXMgdHlwaWNhbGx5IG9uZSBxdWFydGVyIG9mIHRoZQ0KICAgcm91bmR0cmlwIGRl bGF5IGJldHdlZW4gdGhlIHR3byBlbmRzIChvciBkZWZhdWx0ZWQgdG8gb25lIHF1YXJ0ZXIgb2YN CiAgIFQxKSBhcyBhIG1heGltdW0uICBJZiB0aGVyZSBhcmUgbm8gbWVzc2FnZXMgb3V0c3RhbmRp bmcgIlJSIiBpcyBzZW50DQoNCg0KDQpTYWJhdGluaSAgICAgICAgICAgICAgICAgIEV4cGlyZXMg TWFyY2ggMSwgMjAxMyAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICBURExDIFRoZW9yeSAgICAgICAgICAgICAgICAgICBBdWd1c3QgMjAx Mg0KDQoNCiAgIGFzIGEgImhlYXJ0YmVhdCIgbWVzc2FnZSBhZnRlciBpbnRlcnZhbCBUMSB3aGVy ZSBUMSBpcyB0eXBpY2FsbHkNCiAgIHNsaWdodGx5IGdyZWF0ZXIgdGhhbiB0d2ljZSB0aGUgdG90 YWwgcm91bmR0cmlwIGRlbGF5IHdpdGggYSBkZWZhdWx0DQogICBvZiBmb3VyIHNlY29uZHMuICBU MiwgdGhlIGxpbmsgZGlzY29ubmVjdGVkIHRpbWVyLCBpcyB0eXBpY2FsbHkgdGVuDQogICB0aW1l cyBUMSBvciBkZWZhdWx0cyB0byA0MCBzZWNvbmRzLiAgT24gZGVkaWNhdGVkIGxpbmtzIHdoZXJl DQogICB0cmFuc21pdHRpbmcgYSAiUlIiIGhhcyBubyBjb3N0IHRoZSBwcmVmZXJyZWQgcHJhY3Rp Y2UgaXMgc2ltcGx5IHRvDQogICByZXBlYXRlZGx5IHNlbmQgIlJSIiBwYWNrZXRzIHdoZW4gdGhl IGxpbmsgaXMgaWRsZS4NCg0KNS43LiAgUG9pbnQgdG8gTXVsdGlwb2ludA0KDQogICBURExDIGhh cyBiZWVuIHVzZWQgaW4gYm90aCBwb2xsZWQgbXVsdGlwb2ludCBhbmQgYnJvYWRjYXN0IG11bHRp cG9pbnQNCiAgIHdpdGggaW5kaXZpZHVhbCBsb3cgc3BlZWQgYWNrbm93bGVkZ2VtZW50IGNoYW5u ZWxzLiAgVGhlIGluY2x1c2l2ZQ0KICAgb3Jpbmcgb2YgYWxsIHJldHJhbnNtaXNzaW9uIHJlcXVl c3RzIGFjY29tbW9kYXRlcyB0aGUgcmV0cmFuc21pc3Npb24NCiAgIG5lZWRzIG9mIGFsbCB0cmli dXRhcmllcyBhdCBvbmNlLg0KDQogICBPbmUgbWFqb3IgaXNzdWUgaW4gbXVsdGlwb2ludCBpcyBh IHNpbmdsZSBzdGF0aW9uIG1ha2luZyBzbyBtYW55DQogICByZXRyYW5zbWlzc2lvbiByZXF1ZXN0 cyB0aGF0IGl0IGltcGFpcnMgdGhlIGVudGlyZSBjaGFubmVsLiAgU2luY2UNCiAgIFRETEMgaGFk IHN0cmluZ2VudCByZWFsIHRpbWUgZGVsaXZlcnkgcmVxdWlyZW1lbnRzIGFuIHVwcGVyIGxldmVs DQogICBzdGFydGVkIGNhbmNlbGluZyBtZXNzYWdlcyB3aGljaCB3ZXJlIG5vdCByZWNlaXZlZCB3 aXRoaW4gMTAgc2Vjb25kcywNCiAgIGNhdXNpbmcgdGhlIG9mZmVuZGluZyB0ZXJtaW5hbCB0byBy ZXN0YXJ0IGJ1dCBwcm90ZWN0aW5nIHRoZQ0KICAgaW50ZWdyaXR5IG9mIHRoZSBvdmVyYWxsIGZh Y2lsaXR5LiAgU2luY2UgdGhpcyBpcyBub3QgYSBnZW5lcmFsaXplZA0KICAgc29sdXRpb24gY291 bnRzIHdlcmUgbWFpbnRhaW5lZCBvZiB0aGUgbnVtYmVyIG9mIG1lc3NhZ2VzIHJlcXVlc3RlZA0K ICAgZm9yIHJldHJhbnNtaXNzaW9uIGJ5IHN0YXRpb24gYW5kIGFuIGVycm9yIHRocmVzaG9sZCB3 YXMgZXN0YWJsaXNoZWQsDQogICB0aG9zZSBzdGF0aW9ucyBleGNlZWRpbmcgdGhlIHRocmVzaG9s ZCB3ZXJlIGRpc2Nvbm5lY3RlZC4gIEZ1cnRoZXINCiAgIHN0dWR5IGlzIHdhcnJhbnRlZCB0byBl c3RhYmxpc2ggYSBiZXR0ZXIgdGhyZXNob2xkIG1lY2hhbmlzbS4NCg0KNS44LiAgQ2FsY3VsYXRp b24gb2Ygcm91bmQgdHJpcCBkZWxheQ0KDQogICBPbmUgcGxlYXNhbnQgYmVuZWZpdCBvZiBoYXZp bmcgYSB0b2tlbiB3aGljaCBpcyBpbW1lZGlhdGVseSByZXR1cm5lZA0KICAgYnkgdGhlIGZhciBl bmQgaXMgdGhlIGVhc3kgY2FsY3VsYXRpb24gb2Ygcm91bmQgdHJpcCBkZWxheS4gIEluIFRETEMN CiAgIHdlIGNhbiBzYXZlIGEgdGltZSBzdGFtcCBhbG9uZyB3aXRoIHRoZSBtZXNzYWdlIG51bWJl ciBpbiBvdXINCiAgIHRyYW5zbWlzc2lvbiBvcmRlciBhcnJheS4gIFRoaXMgYWxsb3dzIHVzIHRv IGNhbGN1bGF0ZSByb3VuZCB0cmlwDQogICBkZWxheSB3aGVuIHdlIHJlY2VpdmUgb3VyIHRyYW5z bWlzc2lvbiBzdGF0ZSB2YWx1ZSBhbmQgdXNlIGl0IHRvDQogICBhY2Nlc3MgdGhlIHRpbWVzdGFt cC4gIFNpbmNlIG1vcmUgdGhhbiBvbmUgcmVjZWl2ZWQgbWVzc2FnZSBtaWdodA0KICAgaGF2ZSB0 aGUgc2FtZSB0cmFuc21pc3Npb24gc3RhdGUgdmFsdWUgd2UgemVybyB0aGUgdGltZXN0YW1wIGFm dGVyDQogICB1c2UgdG8gaW5kaWNhdGUgdGhhdCB0aGUgdmFsdWUgc2hvdWxkIG5vdCBiZSB1c2Vk IGFnYWluLiAgTm90ZSB0aGF0DQogICBpZiBhbiBhY2tub3dsZWRnZW1lbnQgaXMgbG9zdCB3ZSB3 aWxsIGNhbGN1bGF0ZSBhIGxvbmdlciBkZWxheSB0aGFuDQogICBpcyBhY2N1cmF0ZSB0aGVyZWZv cmUgd2UgbXVzdCBzbW9vdGggdGhlIHJldHVybmVkIHZhbHVlcywgdHlwaWNhbGx5DQogICByZXR1 cm5pbmcgdGhlIHNtYWxsZXN0IG91dCBvZiB0aGUgbGFzdCBOICh3aGVyZSBOIGluIFRETEMgd2Fz IGZvdXIpLg0KDQoNCjYuICBQZXJmb3JtYW5jZQ0KDQogICBUaGUgcG9pbnQgdG8gcG9pbnQgcGVy Zm9ybWFuY2Ugb2YgVERMQyBoYXMgYmVlbiBleHRlbnNpdmVseSB0ZXN0ZWQNCiAgIChpdCB3YXMg YSBwcm9kdWN0aW9uIHByb3RvY29sIGZvciB0d2VudHkgeWVhcnMgaW4gYSB3b3JsZHdpZGUgbmV0 d29yaw0KICAgb2YgODgsMDAwIGNvbXB1dGVycyksIHRoaXMgdGVzdGluZyBjb25maXJtaW5nIGl0 cyBuZWFyIG9wdGltYWwNCiAgIHBlcmZvcm1hbmNlIG5vIG1hdHRlciB3aGF0IHRoZSBjb21iaW5h dGlvbiBvZiBtZXNzYWdlIGxvc3MgYW5kIGRlbGF5Lg0KICAgVGhpcyB3YXMgZHVlIHRvIGVhY2gg cmVwbHkgaGF2aW5nIGJvdGggdGhlIGNvbXBsZXRlIHN0YXRlIG9mIHRoZQ0KICAgcmVjZWl2ZXIg YW5kIHRoYXQgb2YgdGhlIHNlbmRlciBhdCB0aGUgdGltZSB0aGUgcmVwbHkgd2FzIGdlbmVyYXRl ZC4NCg0KDQoNClNhYmF0aW5pICAgICAgICAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAxLCAyMDEz ICAgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAg ICAgIFRETEMgVGhlb3J5ICAgICAgICAgICAgICAgICAgIEF1Z3VzdCAyMDEyDQoNCg0KICAgRm9y IGVhY2ggcmVwbHkgdGhhdCBnb3QgdGhyb3VnaCB0aGUgbWVzc2FnZSBzdHJlYW0gY291bGQgYmUg cmUtDQogICBvcHRpbWl6ZWQgdG8gcmVmbGVjdCB0aGUgY3VycmVudCBzdGF0ZSBhdCB0aGUgZmFy IGVuZC4NCg0KICAgU2luY2UgdGhlIHBvaW50IHRvIHBvaW50IHZlcnNpb24gd2FzIGRlc2lnbmVk IGZvciBkZWRpY2F0ZWQgYmFuZHdpZHRoDQogICBzaXR1YXRpb25zIGl0IHdhcyBub3JtYWxseSBj b25maWd1cmVkIHRvIHNlbmQgIlJSIiBtZXNzYWdlcyBhdCBjbG9zZQ0KICAgdG8gY29udGludW91 cyByYXRlcy4gIFNpbmNlIHRoZSBoYXJkd2FyZSBnZW5lcmF0ZWQgYW5kIHByb2Nlc3NlZA0KICAg dGhlc2UgZGlyZWN0bHkgKGxhdGVyIHZlcnNpb25zIG9mIHRoZSBwcm90b2NvbCB3ZXJlIGltcGxl bWVudGVkDQogICBkaXJlY3RseSBpbiB0aGUgbGluZSBpbnRlcmZhY2UpIHRoZXkgaW1wb3NlZCBu byBvdmVyaGVhZCBpbiBhDQogICBkZWRpY2F0ZWQgYmFuZHdpZHRoIHNpdHVhdGlvbiBidXQgcHJv dmlkZWQgdGhlIGVhcmxpZXN0IHBvc3NpYmxlDQogICBpbmRpY2F0aW9uIG9mIG1lc3NhZ2UgbG9z cyBhbmQgdGh1cyB0aGUgbGVhc3Qgb3ZlcmFsbCBsYXRlbmN5Lg0KDQoNCjcuICBDb25jbHVzaW9u DQoNCiAgIFRETEMgcmVwcmVzZW50cyBhbiBlbnRpcmVseSBuZXcgd2F5IGF0IGxvb2tpbmcgYXQg c2VsZWN0aXZlDQogICBhY2tub3dsZWRnZW1lbnQgcHJvdG9jb2xzLiAgVXNpbmcgdGhlIGNvbmNl cHRzIG91dGxpbmVkIGEgd2hvbGUgbmV3DQogICBmYW1pbHkgb2YgcHJvdG9jb2xzIG9wdGltaXpl ZCBmb3IgbG9uZyBkZWxheSBvciBoaWdoIGxvc3MgcmF0ZXMNCiAgIChlc3BlY2lhbGx5IGR1ZSB0 byBub2lzZSBvciBjb25nZXN0aW9uKSBpcyBwb3NzaWJsZS4gIFRETEMgaXRzZWxmDQogICByZXBy ZXNlbnRzIGEgbGFyZ2UgaW1wcm92ZW1lbnQgb3ZlciBIRExDIGJhc2VkIHByb3RvY29scyBhbmQg Y2FuIGJlDQogICB1c2VkIGFzIGEgcmVwbGFjZW1lbnQgdHJhbnNwb3J0IHByb3RvY29sIHdpdGgg bGl0dGxlIGFkZGl0aW9uYWwNCiAgIG92ZXJoZWFkIGFueXdoZXJlIHRoYXQgSERMQyBjb3VsZCBi ZSB1c2VkLg0KDQoNCjguICBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgbWVtbyBpbmNs dWRlcyBubyByZXF1ZXN0IHRvIElBTkEuDQoNCiAgIEFsbCBkcmFmdHMgYXJlIHJlcXVpcmVkIHRv IGhhdmUgYW4gSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIChzZWUNCiAgIHRoZSB1cGRhdGUg b2YgUkZDIDI0MzQgW0ktRC5uYXJ0ZW4taWFuYS1jb25zaWRlcmF0aW9ucy1yZmMyNDM0YmlzXQ0K ICAgZm9yIGEgZ3VpZGUpLiAgSWYgdGhlIGRyYWZ0IGRvZXMgbm90IHJlcXVpcmUgSUFOQSB0byBk byBhbnl0aGluZywgdGhlDQogICBzZWN0aW9uIGNvbnRhaW5zIGFuIGV4cGxpY2l0IHN0YXRlbWVu dCB0aGF0IHRoaXMgaXMgdGhlIGNhc2UgKGFzDQogICBhYm92ZSkuICBJZiB0aGVyZSBhcmUgbm8g cmVxdWlyZW1lbnRzIGZvciBJQU5BLCB0aGUgc2VjdGlvbiB3aWxsIGJlDQogICByZW1vdmVkIGR1 cmluZyBjb252ZXJzaW9uIGludG8gYW4gUkZDIGJ5IHRoZSBSRkMgRWRpdG9yLg0KDQoNCjkuICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBBbGwgZHJhZnRzIGFyZSByZXF1aXJlZCB0byBo YXZlIGEgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCiAgIFNlZSBSRkMgMzU1MiBb UkZDMzU1Ml0gZm9yIGEgZ3VpZGUuDQoNCg0KMTAuICBSZWZlcmVuY2VzDQoNCjEwLjEuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRz IGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBM ZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQoNCg0KDQpTYWJhdGluaSAg ICAgICAgICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMSwgMjAxMyAgICAgICAgICAgICAgICBbUGFn ZSAxMF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICBURExDIFRoZW9yeSAgICAg ICAgICAgICAgICAgICBBdWd1c3QgMjAxMg0KDQoNCjEwLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVu Y2VzDQoNCiAgIFtJLUQubmFydGVuLWlhbmEtY29uc2lkZXJhdGlvbnMtcmZjMjQzNGJpc10NCiAg ICAgICAgICAgICAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMgZm9y IFdyaXRpbmcgYW4NCiAgICAgICAgICAgICAgSUFOQSBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGlu IFJGQ3MiLA0KICAgICAgICAgICAgICBkcmFmdC1uYXJ0ZW4taWFuYS1jb25zaWRlcmF0aW9ucy1y ZmMyNDM0YmlzLTA5ICh3b3JrIGluDQogICAgICAgICAgICAgIHByb2dyZXNzKSwgTWFyY2ggMjAw OC4NCg0KICAgW1JGQzA3OTNdICBQb3N0ZWwsIEouLCAiVHJhbnNtaXNzaW9uIENvbnRyb2wgUHJv dG9jb2wiLCBTVEQgNywNCiAgICAgICAgICAgICAgUkZDIDc5MywgU2VwdGVtYmVyIDE5ODEuDQoN CiAgIFtSRkMwOTk4XSAgQ2xhcmssIEQuLCBMYW1iZXJ0LCBNLiwgYW5kIEwuIFpoYW5nLCAiTkVU QkxUOiBBIGJ1bGsgZGF0YQ0KICAgICAgICAgICAgICB0cmFuc2ZlciBwcm90b2NvbCIsIFJGQyA5 OTgsIE1hcmNoIDE5ODcuDQoNCiAgIFtSRkMxMDcyXSAgSmFjb2Jzb24sIFYuIGFuZCBSLiBCcmFk ZW4sICJUQ1AgZXh0ZW5zaW9ucyBmb3IgbG9uZy1kZWxheQ0KICAgICAgICAgICAgICBwYXRocyIs IFJGQyAxMDcyLCBPY3RvYmVyIDE5ODguDQoNCiAgIFtSRkMyMDE4XSAgTWF0aGlzLCBNLiwgTWFo ZGF2aSwgSi4sIEZsb3lkLCBTLiwgYW5kIEEuIFJvbWFub3csICJUQ1ANCiAgICAgICAgICAgICAg U2VsZWN0aXZlIEFja25vd2xlZGdtZW50IE9wdGlvbnMiLCBSRkMgMjAxOCwgT2N0b2JlciAxOTk2 Lg0KDQogICBbUkZDMjYyOV0gIFJvc2UsIE0uLCAiV3JpdGluZyBJLURzIGFuZCBSRkNzIHVzaW5n IFhNTCIsIFJGQyAyNjI5LA0KICAgICAgICAgICAgICBKdW5lIDE5OTkuDQoNCiAgIFtSRkMzNTUy XSAgUmVzY29ybGEsIEUuIGFuZCBCLiBLb3J2ZXIsICJHdWlkZWxpbmVzIGZvciBXcml0aW5nIFJG Qw0KICAgICAgICAgICAgICBUZXh0IG9uIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIiwgQkNQIDcy LCBSRkMgMzU1MiwNCiAgICAgICAgICAgICAgSnVseSAyMDAzLg0KDQoNCkFwcGVuZGl4IEEuICBS ZWxhdGVkIFJlYWRpbmdzDQoNCiAgIFMuIExpbiBhbmQgUC4gUy4gWXUsICJBbiBlZmZlY3RpdmUg ZXJyb3IgY29udHJvbCBzY2hlbWUgZm9yIHNhdGVsbGl0ZQ0KICAgY29tbXVuaWNhdGlvbnMiLCBJ RUVFIFRyYW5zYWN0aW9ucyBvbiBDb21tdW5pY2F0aW9ucywgdm9sLiAgQ09NLTI4LA0KICAgbm8u IDMsIHBwLiAzOTUtLTQwMSwgTWFyLiAxOTgwLg0KDQogICBQLiBTLiBZdSBhbmQgUy4gTGluLCAi QW4gZWZmaWNpZW50IHNlbGVjdGl2ZS1yZXBlYXQgQVJRIHNjaGVtZSBmb3INCiAgIHNhdGVsbGl0 ZSBjaGFubmVscyBhbmQgaXRzIHRocm91Z2hwdXQgYW5hbHlzaXMsIiBJRUVFIFRyYW5zYWN0aW9u cyBvbg0KICAgQ29tbXVuaWNhdGlvbnMsIHZvbC4gMjksIG5vLiAzLCBwcC4gMzUzLS0zNjMsIE1h cmNoIDE5ODEuDQoNCiAgIFMuIExpbiBhbmQgUC4gUy4gWXUsICJBIGh5YnJpZCBBUlEgc2NoZW1l IHdpdGggcGFyaXR5IHJldHJhbnNtaXNzaW9uDQogICBmb3IgZXJyb3IgY29udHJvbCBvZiBzYXRl bGxpdGUgY2hhbm5lbHMsIiBJRUVFIFRyYW5zLiAgQ29tbXVuLiwgdm9sLg0KICAgMzAsIHBwLiAx NzAxLTE3MTksIEp1bHkgMTk4Mi4NCg0KICAgTS4gSi4gTWlsbGVyIGFuZCBTLiBMLiBMaW4uICJU aGUgYW5hbHlzaXMgb2Ygc29tZSBzZWxlY3RpdmUtcmVwZWF0DQogICBBUlEgc2NoZW1lcyB3aXRo IGZpbml0ZSByZWNlaXZlciBidWZmZXIiLCBJRUVFIFRyYW5zYWN0aW9ucyBvbg0KICAgQ29tbXVu aWNhdGlvbnMsIFZvbC4gQ09NLTI5LCBOby4gOSwgcGFnZXMgMTMwNy0tMTMxNSwgU2VwdGVtYmVy IDE5ODEuDQoNCiAgIFMuIFIuIENoYW5kcmFuIGFuZCBTLiBMaW4sICJBIHNlbGVjdGl2ZSByZXBl YXQgQVJRIHNjaGVtZSBmb3IgcG9pbnQtDQogICB0by1tdWx0aXBvaW50IGNvbW11bmljYXRpb25z IGFuZCBpdHMgdGhyb3VnaHB1dCBhbmFseXNpcywiIEFDTQ0KDQoNCg0KU2FiYXRpbmkgICAgICAg ICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDEsIDIwMTMgICAgICAgICAgICAgICAgW1BhZ2UgMTFd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgVERMQyBUaGVvcnkgICAgICAgICAg ICAgICAgICAgQXVndXN0IDIwMTINCg0KDQogICBDb21wdXRlciBDb21tdW5pY2F0aW9ucyBSZXZp ZXcsIHZvbC4gMTYsIHBwLiAyOTItLTMwMSwgQXVnLiAxOTg2Lg0KDQogICBTLiBSLiBDaGFuZHJh biBhbmQgUy4gTGluLCAiU2VsZWN0aXZlLXJlcGVhdC1BUlEgc2NoZW1lcyBmb3INCiAgIGJyb2Fk Y2FzdCBsaW5rcywiIElFRUUgVHJhbnMuICBDb21tdW4uLCB2b2wuIDQwLCBuby4gMSwgcHAuIDEy LTE5LA0KICAgSmFuLiAxOTkyLg0KDQogICBILiBNLiBkZSBMaW1hLCBPLiBDYXJsb3MgYW5kIE0u IEIuIER1YXJ0ZSwgIkEgUG9pbnQtdG8tTXVsdGlwb2ludCBBUlENCiAgIFNjaGVtZSB3aXRoIE11 bHRpY29weSBSZXRyYW5zbWlzc2lvbiBmb3IgSGlnaCBTcGVlZCBTYXRlbGxpdGUNCiAgIENvbW11 bmljYXRpb25zIiBJRUVFIEludGVybmF0aW9uYWwgVGVsZWNvbW11bmljYXRpb24gU3ltcG9zaXVt DQogICBJVFMnOTQsIChSaW8gZGUgSmFuZWlybywgMTk5NCkNCg0KICAgQS4gTi4gTmV0cmF2YWxp LCBXLiBELiBSb29tZSwgYW5kIEsuIFNhYm5hbmksICJEZXNpZ24gYW5kDQogICBpbXBsZW1lbnRh dGlvbiBvZiBhIGhpZ2gtc3BlZWQgdHJhbnNwb3J0IHByb3RvY29sLCIgSUVFRSBUcmFuc2FjdGlv bnMNCiAgIG9uIENvbW11bmljYXRpb25zLCB2b2wuICBDT00zOCwgcHAuIDIwMTAuDQoNCiAgIEsu IEsuIFNhYm5hbmkgYW5kIEEuIE4uIE5ldHJhdmFsaSwgIkEgaGlnaCBzcGVlZCB0cmFuc3BvcnQg cHJvdG9jb2wNCiAgIGZvciBkYXRhZ3JhbS92aXJ0dWFsIGNpcmN1aXQgbmV0d29ya3MiLCBBQ00g U0lHQ09NTSBDb21wdXRlcg0KICAgQ29tbXVuaWNhdGlvbiBSZXZpZXcgLCBTeW1wb3NpdW0gcHJv Y2VlZGluZ3Mgb24gQ29tbXVuaWNhdGlvbnMNCiAgIGFyY2hpdGVjdHVyZXMgJiBwcm90b2NvbHMg U0lHQ09NTSAnODksIFZvbHVtZSAxOSBJc3N1ZSA0LCBBdWcuIDE5ODkuDQoNCiAgIEQuIFRvd3Ns ZXkgYW5kIFMuIE1pdGhhbCwgIkEgc2VsZWN0aXZlIHJlcGVhdCBBUlEgcHJvdG9jb2wgZm9yIGEN CiAgIHBvaW50IHRvIG11bHRpcG9pbnQgY2hhbm5lbCwiIGluIElFRUUgSW50ZXJuYXRpb25hbCBD b25mZXJlbmNlIG9uDQogICBDb21tdW5pY2F0aW9ucyBJTkZPQ09NJzg3LCAoU2FuIEZyYW5jaXNj byxDQSksIHBwLiA1MjEtLTUyNiwgQXByLg0KICAgMTk4Ny4NCg0KICAgRS4gV2VsZG9uLCAiQW4g aW1wcm92ZWQgc2VsZWN0aXZlIHJlcGVhdCBBUlEgc3RyYXRlZ3kiLCBJRUVFDQogICBUcmFuc2Fj dGlvbnMgb24gQ29tbXVuaWNhdGlvbnMsIHZvbC4gIENPTS0zMCwgbm8uIDMsIHBwLiA0ODAtLTQ4 NiwNCiAgIE1hci4gMTk4Mi4NCg0KICAgSi4gTC4gV2FuZyBhbmQgSi4gQS4gU2lsdmVzdGVyLCAi T3B0aW1hbCBhZGFwdGF0aXZlIG11bHRpcmVjZWl2ZXIgQVJRDQogICBwcm90b2NvbHMsIiBJRUVF IFRyYW5zYWN0aW9ucyBvbiBDb21tdW5pY2F0aW9ucywgdm9sLiAgQ09NLTQxLCBwcC4NCiAgIDE4 MTYtLTE4MjksIERlYy4gMTk5My4NCg0KICAgVC4gU2hpa2FtYSBhbmQgVC4gTWl6dW5vLCAiUmVz ZXF1ZW5jaW5nIHNjaGVtZXMgZm9yIHNlbGVjdGl2ZS1yZXBlYXQNCiAgIEFSUSBhbmQgdGhlaXIg cGVyZm9ybWFuY2UiLCBBZHZhbmNlZCBJbmZvcm1hdGlvbiBOZXR3b3JraW5nIGFuZA0KICAgQXBw bGljYXRpb25zLCAyMDA1LiAgQUlOQSAyMDA1LiAxOXRoIEludGVybmF0aW9uYWwgQ29uZmVyZW5j ZSBvbg0KICAgVm9sdW1lIDIsIElzc3VlICwgUGFnZShzKTogNDkxIC0gNDk0IHZvbC4yLCBNYXIu IDIwMDUuDQoNCiAgIFIuIFNhbmRlcnMgYW5kIEEuIFdlYXZlciAxOTkwLiAgIlRoZSBYcHJlc3Mg dHJhbnNmZXIgcHJvdG9jb2wgKFhUUCk6DQogICBBIHR1dG9yaWFsIiwgU0lHQ09NTSBDb21wLiAg Q29tbS4gIFJldi4gMjAsIDUsIFBnIDY3LTgwLCBPY3QuIDE5OTAuDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KU2FiYXRpbmkgICAgICAgICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDEsIDIwMTMgICAg ICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg VERMQyBUaGVvcnkgICAgICAgICAgICAgICAgICAgQXVndXN0IDIwMTINCg0KDQpBdXRob3IncyBB ZGRyZXNzDQoNCiAgIEFudGhvbnkgU2FiYXRpbmkNCiAgIEJyb2tlciBDb21tdW5pY2F0aW9ucyBJ bmMuDQogICAyMDAgV2VzdCAyMHRoIFN0cmVldA0KICAgQXB0LiAxMjE2DQogICBOZXcgWW9yaywg TlkgIDEwMDExDQogICBVUw0KDQogICBQaG9uZTogKzEgMjEyIDg2NyA3MTc5DQogICBFbWFpbDog dHNhYmF0aW5pQGhvdG1haWwuY29tDQogICBVUkk6ICAgaHR0cDovL3RzYWJhdGluaS5jb20vDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQpTYWJhdGluaSAgICAgICAgICAgICAgICAgIEV4cGlyZXMgTWFy Y2ggMSwgMjAxMyAgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCg== --_d72115f6-159f-40f2-96e9-411bf0a4c0f7_-- From michael.scharf@alcatel-lucent.com Fri Sep 14 00:32:35 2012 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 15DBF21F8505 for ; Fri, 14 Sep 2012 00:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb0nSe2k2-4A for ; Fri, 14 Sep 2012 00:32:34 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9EE21F84FC for ; Fri, 14 Sep 2012 00:32:33 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8E7Vhep014924 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 14 Sep 2012 09:32:30 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 14 Sep 2012 09:32:03 +0200 From: "Scharf, Michael (Michael)" To: "tcpm@ietf.org" Date: Fri, 14 Sep 2012 09:32:02 +0200 Thread-Topic: Removal of TCPM charter milestone on hardening TCP implementations Thread-Index: Ac2SSwgu1mXtsHeIQgaNtn5IXsAFqA== Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891AAE40D0@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [tcpm] Removal of TCPM charter milestone on hardening TCP implementations X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2012 07:32:35 -0000 As announced in the last meeting, the following milestone has been removed = from the TCPM charter upon request of the TCPM chairs, due to lack of WG en= ergy: Aug 2010 Submit document on security hardening of TCP implementations to t= he IESG for publication as a Best Current Practices RFC Thanks Michael= From udeshpa1@binghamton.edu Sat Sep 15 19:50:25 2012 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 E4D8621F84FD for ; Sat, 15 Sep 2012 19:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cFaQVJLtBXx for ; Sat, 15 Sep 2012 19:50:25 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E186121F84FC for ; Sat, 15 Sep 2012 19:50:24 -0700 (PDT) Received: by qafi29 with SMTP id i29so782419qaf.10 for ; Sat, 15 Sep 2012 19:50:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=KTO2KgNdWlmCEU9xdI49br1w8OrtGeUtGSnBR/rpRU4=; b=lTBvOADkFIrOS6406P99tyC2zUCzm+jnNPVOWoipJw/QebY8cit1oxK6GBalaZu4p4 KRzCCuf6QoxI4WuioxVwRv5fqWpCF6QZYZ3TOhAILlIP133UmOrNW6u9oMk7x4dsjW6Y vsmSm5+6n4MQkLmYaTLvbWhfeLPJsugtoidxxcj7eTw7pgjl44pFHqB7sH2OpDLzL5x/ kcmigzbA8bZddS6g1yYhF8101L8OIp16PpQeXNz0YepQ44Q8FgHNrr4hiaceVpSKvufP Z6SKQxg2oVvDmN6WY5Atxb7qonZ+eIL7GIuZMdZ4fBGd0mb8nYkqPEhRZ2ESm9dUhA4/ xggg== Received: by 10.224.117.82 with SMTP id p18mr18325162qaq.21.1347763824300; Sat, 15 Sep 2012 19:50:24 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by mx.google.com with ESMTPS id ca8sm9255494qab.20.2012.09.15.19.50.22 (version=SSLv3 cipher=OTHER); Sat, 15 Sep 2012 19:50:23 -0700 (PDT) Received: by qafi29 with SMTP id i29so782412qaf.10 for ; Sat, 15 Sep 2012 19:50:22 -0700 (PDT) Received: by 10.224.168.83 with SMTP id t19mr18448178qay.8.1347763822032; Sat, 15 Sep 2012 19:50:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.233.205 with HTTP; Sat, 15 Sep 2012 19:50:06 -0700 (PDT) From: Umesh Deshpande Date: Sat, 15 Sep 2012 22:50:06 -0400 Message-ID: To: tcpm@ietf.org Content-Type: multipart/alternative; boundary=20cf3074b5ceda772b04c9c8b74a X-Gm-Message-State: ALoCoQntrFVhnkvgZH7XAg1MqBIf6/l+RF+89lLSgqrKmUyLjTyRfWs6UC2xQIViyvw3icnXEfuS X-Mailman-Approved-At: Sun, 16 Sep 2012 08:04:43 -0700 Subject: [tcpm] TCP duplex bandwidth X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2012 02:51:57 -0000 --20cf3074b5ceda772b04c9c8b74a Content-Type: text/plain; charset=ISO-8859-1 Hi, I'm testing TCP duplex bandwidth with the following scenario. Consider 3 machines A, B, C. One sender thread on A is sending data to B, multiple sender threads (2) on B are sending data to C simultaneously. I observed that under this scenario, (B receiving data while sending data to C), B couldn't receive data with 1Gbps from A. However, addition of bandwidths of individual threads from B -> C was close to 1Gbps. I was expecting that B should be able to receive and send with 1Gbps simultaneously. (1Gbps RX, and 1Gbps TX). A -> B : 503 Mbps B -> C : 490 Mbps x 2 threads = 880Mbps If I increase A->B thread from 1 to 2, each thread can send with more bandwidth. Also, I didn't observe this problem when A->B sender was UDP, i.e. rate of UDP remained closed to 1Gbps. Setup Used All machines were running kernel 3.1.0-030100-generic of Ubuntu. Each machine has 8 CPUs. Broadcom BCM5721 Ethernet card. Above test was verified with a custom program and netperf. Sorry if this is not a relevant mailing list. Thanks Umesh --20cf3074b5ceda772b04c9c8b74a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I'm testing TCP duplex bandwidth with the following scenario= .

Consider 3 machines A, B, C.
One sender thread on A is sending = data to B, multiple sender threads (2) on B are sending data to C simultane= ously.
I observed that under this scenario, (B receiving data while sending data t= o C), B couldn't receive data with 1Gbps from A. However, addition of b= andwidths of individual threads from B -> C was close to 1Gbps. I was ex= pecting that B should be able to receive and send with 1Gbps simultaneously= . (1Gbps RX, and 1Gbps TX).

A -> B : 503 Mbps
B -> C : 490 Mbps x 2 threads =3D 880Mbps
If I increase A->B thread from 1 to 2, each thread can send with mo= re bandwidth. Also, I didn't observe this problem when A->B sender w= as UDP, i.e. rate of UDP remained closed to 1Gbps.

Setup Used
All machines were running kernel 3.1.0-030100-generic of = Ubuntu.
Each machine has 8 CPUs.
Broadcom BCM5721 Ethernet card.
A= bove test was verified with a custom program and netperf.

Sorry if t= his is not a relevant mailing list.

Thanks
Umesh


--20cf3074b5ceda772b04c9c8b74a-- From michael.scharf@alcatel-lucent.com Sun Sep 16 08:30:38 2012 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 91C2E21F84DE for ; Sun, 16 Sep 2012 08:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4p4gR8788a-t for ; Sun, 16 Sep 2012 08:30:38 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id D6DD521F84DC for ; Sun, 16 Sep 2012 08:30:37 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q8GFUWPx002501 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 16 Sep 2012 17:30:32 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sun, 16 Sep 2012 17:30:32 +0200 From: "Scharf, Michael (Michael)" To: Umesh Deshpande , "tcpm@ietf.org" Date: Sun, 16 Sep 2012 17:30:30 +0200 Thread-Topic: [tcpm] TCP duplex bandwidth Thread-Index: Ac2UHMQByHvSs5jLSc+SRAJ3NdK6BwAAPHHw Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891AAE4102@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: Re: [tcpm] TCP duplex bandwidth X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2012 15:30:38 -0000 The analysis of such performance issues is not trivial. And not always (in = fact, seldom) the root cause is TCP. For instance, in a scenario like this,= there can be issues with the NIC drivers or the Ethernet switch (e. g., Et= hernet flow control). Given that this list deals with TCP only, it would make sense to exclude al= l non-TCP issues first. Reverse-engineering TCP's behavior in such a setup would really benefit fro= m further information, e. g., the packet losses and RTT seen by each connec= tion. Linux makes some useful information available in the /proc system and= by tcp_info. Michael > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On=20 > Behalf Of Umesh Deshpande > Sent: Sunday, September 16, 2012 4:50 AM > To: tcpm@ietf.org > Subject: [tcpm] TCP duplex bandwidth >=20 > Hi, >=20 > I'm testing TCP duplex bandwidth with the following scenario. >=20 > Consider 3 machines A, B, C. > One sender thread on A is sending data to B, multiple sender=20 > threads (2) on B are sending data to C simultaneously. > I observed that under this scenario, (B receiving data while=20 > sending data to C), B couldn't receive data with 1Gbps from=20 > A. However, addition of bandwidths of individual threads from=20 > B -> C was close to 1Gbps. I was expecting that B should be=20 > able to receive and send with 1Gbps simultaneously. (1Gbps=20 > RX, and 1Gbps TX). >=20 > A -> B : 503 Mbps > B -> C : 490 Mbps x 2 threads =3D 880Mbps >=20 > If I increase A->B thread from 1 to 2, each thread can send=20 > with more bandwidth. Also, I didn't observe this problem when=20 > A->B sender was UDP, i.e. rate of UDP remained closed to 1Gbps. >=20 > Setup Used > All machines were running kernel 3.1.0-030100-generic of Ubuntu. > Each machine has 8 CPUs. > Broadcom BCM5721 Ethernet card. > Above test was verified with a custom program and netperf. >=20 > Sorry if this is not a relevant mailing list. >=20 > Thanks > Umesh >=20 >=20 >=20 > = From perfgeek@mac.com Sun Sep 16 10:12:48 2012 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 85D9F21F8440 for ; Sun, 16 Sep 2012 10:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEcwVOTpL7VQ for ; Sun, 16 Sep 2012 10:12:48 -0700 (PDT) Received: from nk11p00mm-asmtp008.mac.com (nk11p00mm-asmtp008.mac.com [17.158.161.7]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF3C21F8421 for ; Sun, 16 Sep 2012 10:12:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.65] (76-220-56-223.lightspeed.sntcca.sbcglobal.net [76.220.56.223]) by nk11p00mm-asmtp008.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0MAG000A3D5A5J00@nk11p00mm-asmtp008.mac.com> for tcpm@ietf.org; Sun, 16 Sep 2012 17:12:47 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855,1.0.431,0.0.0000 definitions=2012-09-16_06:2012-09-14, 2012-09-16, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1209160214 From: rick jones In-reply-to: Date: Sun, 16 Sep 2012 10:12:44 -0700 Message-id: <3277C8F1-E65F-4244-B276-476CC3AAA653@mac.com> References: To: Umesh Deshpande X-Mailer: Apple Mail (2.1084) Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP duplex bandwidth X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2012 17:12:48 -0000 On Sep 15, 2012, at 7:50 PM, Umesh Deshpande wrote: > Hi, > > I'm testing TCP duplex bandwidth with the following scenario. > > Consider 3 machines A, B, C. > One sender thread on A is sending data to B, multiple sender threads (2) on B are sending data to C simultaneously. > I observed that under this scenario, (B receiving data while sending data to C), B couldn't receive data with 1Gbps from A. However, addition of bandwidths of individual threads from B -> C was close to 1Gbps. I was expecting that B should be able to receive and send with 1Gbps simultaneously. (1Gbps RX, and 1Gbps TX). > > A -> B : 503 Mbps > B -> C : 490 Mbps x 2 threads = 880Mbps > > If I increase A->B thread from 1 to 2, each thread can send with more bandwidth. Also, I didn't observe this problem when A->B sender was UDP, i.e. rate of UDP remained closed to 1Gbps. > > Setup Used > All machines were running kernel 3.1.0-030100-generic of Ubuntu. > Each machine has 8 CPUs. > Broadcom BCM5721 Ethernet card. > Above test was verified with a custom program and netperf. > > Sorry if this is not a relevant mailing list. If indeed tcpm is not an appropriate list (not sure I can say really), since netperf was involved, you might consider netperf-talk@netperf.org. There you would probably be asked clarifying questions such as: *) If B sending to C required two streams, what led you to believe that A sending to be would require only one? *) What were your exact netperf command lines? *) What were the utilizations of each of the CPUs on each system during the test? *) What is the latency between A and B? *) Others that I cannot think of just now :) Alternatively, since a linux kernel is involved, it may be appropriate to ask in something like the netdev mailing list. Though your use of what to them would be considered an "old" kernel might lead to their first asking you to use a newer one. happy benchmarking, rick jones From mattmathis@google.com Sun Sep 16 12:59:48 2012 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 A025521F84D3 for ; Sun, 16 Sep 2012 12:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5avtEJIq1-A for ; Sun, 16 Sep 2012 12:59:48 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7F321F843A for ; Sun, 16 Sep 2012 12:59:47 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so1261784wib.13 for ; Sun, 16 Sep 2012 12:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-system-of-record; bh=XaZ2bDKo13y+ATTh8AK/pJg7Chg3DVme793AZZUO1s8=; b=GVJsmqL9L/Xea4tksMXG2lfRpl5Zh6uav6XOQ+LKXghmvkmqJVsAa8rhRy+jBnmlNh xvcwCvxY8IpNfV7LzFtfG9ww7TfztVBVAMEbrSiUMlAf5xSSmhou52zg8lKpE76t2AMe bsBSHerofwOSQaMfYoCQZTjFLGXoBtVDdVnBlJq1iDnujbWizNqYsIkqUokyUUMXUj/I 8uAeaPjxAs/FWNpaTailuq3fsSim0QzVh0BDcXpXpuRB6TBfrGRZBsxgKvaO+1gs23P3 nw2RTa4LhqAxudc4vROhDfhOF5mB2tDg/pd710Z4bTpe+irkC8V79UxyvUHFxH5d0+eE a0ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=XaZ2bDKo13y+ATTh8AK/pJg7Chg3DVme793AZZUO1s8=; b=RHMDfZ6fqr6wwf9NZX55ZLAx0DsESSgR7R8kuJzk9q401wR+EhYGa+YH9gWwKIOtsl OJ8itjoOZ5+SjkGMndHi53KushT50XLcD5RhREwuxxbnozm2f0M26+DncEYwK1AIcUzR 9CcWA3ZD8dFPrS+/TXdX9Ao79tRnoXsmA2N+71IdtcSncqvkiQSqx9Foa3QNz53FTEY1 5RH7xJym6l1qGQ7uH7nvw5K2J/8H3KI8Pl3MOD/LtVHNf73H2OPKtzkvG6cNwfq4sEtj wDeglksdX4eTfysCXlpUPmnRdqwgHZ1hF9KNBdrlsLEmP0YnY59HQPpPf1EK4EhymjSH ahtw== Received: by 10.180.82.230 with SMTP id l6mr11327961wiy.21.1347825586700; Sun, 16 Sep 2012 12:59:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.82.230 with SMTP id l6mr11327949wiy.21.1347825586427; Sun, 16 Sep 2012 12:59:46 -0700 (PDT) Received: by 10.217.0.9 with HTTP; Sun, 16 Sep 2012 12:59:46 -0700 (PDT) In-Reply-To: <3277C8F1-E65F-4244-B276-476CC3AAA653@mac.com> References: <3277C8F1-E65F-4244-B276-476CC3AAA653@mac.com> Date: Sun, 16 Sep 2012 12:59:46 -0700 Message-ID: From: Matt Mathis To: TCP Maintenance and Minor Extensions WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQktIx9El9WFkJRZ8O+1nWwmnTUNNd9OEd0PQ7RLrk6gn/Y+vvXMGELw9C9laHP+4TEeUWAaC20aj2rT0GxnORtYcyeS9xhBOhaWn+pqhmPB3Fbbu34RhLEMnWVG/tOKBIJtbZ1YoDl5NT38FZy9B90TEeWN2YtOgmv5WbLZckshrFaHQwqeZzWZ8dwd+mgL4IsFW3F/ Subject: Re: [tcpm] TCP duplex bandwidth X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2012 19:59:48 -0000 You may have rediscovered a long know problem that is a fairly direct consequence of TCP's self clock, but made worse by some combination of: channel acquisition algorithm that have hysteresis (current sender is most likely to be the next sender) plus the lack of AQM and explicit scheduling (how does fq_codel play here?), and probably other effects. See: Zhang, L., Shenker, S., and D. D. Clark, "Observations and Dynamics of a Congestion Control Algorithm: The Effects of Two-Way Traffic", Proc. ACM SIGCOMM, ACM Computer Communications Review (CCR), Vol 21, No 4, 1991, pp.133- 147. I point out that device driver polling (aka interrupt coalescing) causes channel acquisition hysteresis, and that all of the link effects discussed in the above paper might be happening within the operating system itself. I would start with a forward literature search from the above paper. It would be extremely useful to see if/how fq_codel might change this story. At least in the Linux world there have been enough recent changes in this space where you must be working at the HEAD to have relevant results. Otherwise you are at risk of doing an extensive study of an already obsolete OS. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Sun, Sep 16, 2012 at 10:12 AM, rick jones wrote: > > On Sep 15, 2012, at 7:50 PM, Umesh Deshpande wrote: > >> Hi, >> >> I'm testing TCP duplex bandwidth with the following scenario. >> >> Consider 3 machines A, B, C. >> One sender thread on A is sending data to B, multiple sender threads (2)= on B are sending data to C simultaneously. >> I observed that under this scenario, (B receiving data while sending dat= a to C), B couldn't receive data with 1Gbps from A. However, addition of ba= ndwidths of individual threads from B -> C was close to 1Gbps. I was expect= ing that B should be able to receive and send with 1Gbps simultaneously. (1= Gbps RX, and 1Gbps TX). >> >> A -> B : 503 Mbps >> B -> C : 490 Mbps x 2 threads =3D 880Mbps >> >> If I increase A->B thread from 1 to 2, each thread can send with more ba= ndwidth. Also, I didn't observe this problem when A->B sender was UDP, i.e.= rate of UDP remained closed to 1Gbps. >> >> Setup Used >> All machines were running kernel 3.1.0-030100-generic of Ubuntu. >> Each machine has 8 CPUs. >> Broadcom BCM5721 Ethernet card. >> Above test was verified with a custom program and netperf. >> >> Sorry if this is not a relevant mailing list. > > If indeed tcpm is not an appropriate list (not sure I can say really), si= nce netperf was involved, you might consider netperf-talk@netperf.org. The= re you would probably be asked clarifying questions such as: > > *) If B sending to C required two streams, what led you to believe that A= sending to be would require only one? > *) What were your exact netperf command lines? > *) What were the utilizations of each of the CPUs on each system during t= he test? > *) What is the latency between A and B? > *) Others that I cannot think of just now :) > > Alternatively, since a linux kernel is involved, it may be appropriate to= ask in something like the netdev mailing list. Though your use of what to= them would be considered an "old" kernel might lead to their first asking = you to use a newer one. > > happy benchmarking, > > rick jones > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From gettysjim@gmail.com Sun Sep 16 13:56:53 2012 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 C828521F84B6 for ; Sun, 16 Sep 2012 13:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9GEnqymIGJg for ; Sun, 16 Sep 2012 13:56:53 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E203F21F84AE for ; Sun, 16 Sep 2012 13:56:52 -0700 (PDT) Received: by qcac10 with SMTP id c10so4690218qca.31 for ; Sun, 16 Sep 2012 13:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=FtvLt1/wrZ5oE0UBks2RfXMH2FD7MRCMRKYtcgx0//U=; b=1JwnXaRfca6GrfFUg+fC73vm99/NjMNn/5R5iE81Wopu0LET4RJraLW9kpj2ZPzG7m gM5QQkuwmtY0umv21k08fh8cswzNa03PDy6IMT/bLottnR7lPQoEwORYumjvpT5lsXD8 K3LUtTSvN0hWyIHWMmZ/f2ZrhTsiPvRjRsCpogBtS/Ri0BmeUexA0BQGxyQ2vESoDYJV +9hBLWaj3T+4wrZMnbnDO+Q43kriL30TLvPJG1jrOg58XUi37a9abjT0s/p9lrIyP6J8 cwnTsYesb0WWCo8JdKKlMTvxMzJAsyocczw5WXXTZ1lgdXdGzXIZmEik2ddoQikxW42y hLsw== Received: by 10.224.183.79 with SMTP id cf15mr23093372qab.16.1347829012423; Sun, 16 Sep 2012 13:56:52 -0700 (PDT) Received: from [192.168.1.80] (c-50-138-166-22.hsd1.ma.comcast.net. [50.138.166.22]) by mx.google.com with ESMTPS id d11sm10271568qaj.18.2012.09.16.13.56.51 (version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 13:56:51 -0700 (PDT) Sender: Jim Gettys Message-ID: <50563D13.2020007@freedesktop.org> Date: Sun, 16 Sep 2012 16:56:51 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Matt Mathis References: <3277C8F1-E65F-4244-B276-476CC3AAA653@mac.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: TCP Maintenance and Minor Extensions WG Subject: Re: [tcpm] TCP duplex bandwidth X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2012 20:56:53 -0000 On 09/16/2012 03:59 PM, Matt Mathis wrote: > You may have rediscovered a long know problem that is a fairly direct > consequence of TCP's self clock, but made worse by some combination > of: channel acquisition algorithm that have hysteresis (current sender > is most likely to be the next sender) plus the lack of AQM and > explicit scheduling (how does fq_codel play here?), and probably other > effects. > See: Zhang, L., Shenker, S., and D. D. Clark, "Observations and > Dynamics of a Congestion Control Algorithm: The Effects of > Two-Way Traffic", Proc. ACM SIGCOMM, ACM Computer > Communications Review (CCR), Vol 21, No 4, 1991, pp.133- > 147. > > I point out that device driver polling (aka interrupt coalescing) > causes channel acquisition hysteresis, and that all of the link > effects discussed in the above paper might be happening within the > operating system itself. > > I would start with a forward literature search from the above paper. > > It would be extremely useful to see if/how fq_codel might change this > story. At least in the Linux world there have been enough recent > changes in this space where you must be working at the HEAD to have > relevant results. Otherwise you are at risk of doing an extensive > study of an already obsolete OS. > > Thanks, > --MM-- My memory of some data Dave Taht took two months ago was that fq_codel did spectacularly well in this case; both directions were fully saturated; without fq_codel, performance was asymmetric and one direction lost 10-20% of bandwidth or more. Eric Dumazet's TCP small queues work by itself did almost as well at bandwidth utilisation, but left 17ms of latency, which I then complained about to Dave, triggering his post of my complaint to G+, about it being way too much of a decent VOIP latency budget, which 17ms is...). Best of all, was both in combination, saturating the NIC in both directions while preserving low latency for other traffic and keeping TCP buffer sizes more sane in sized. In any case, any data taken on any version of Linux is seriously out of date, given all the work which has been done to fix bufferbloat over the last 18 months: e.g. fq_codel, TCP small queues, and BQL. For any data in this area to be relevant, you'd better be running Linus' kernel. TSQ I think is in the latest bits, IIRC. - Jim > The best way to predict the future is to create it. - Alan Kay > > > On Sun, Sep 16, 2012 at 10:12 AM, rick jones wrote: >> On Sep 15, 2012, at 7:50 PM, Umesh Deshpande wrote: >> >>> Hi, >>> >>> I'm testing TCP duplex bandwidth with the following scenario. >>> >>> Consider 3 machines A, B, C. >>> One sender thread on A is sending data to B, multiple sender threads (2) on B are sending data to C simultaneously. >>> I observed that under this scenario, (B receiving data while sending data to C), B couldn't receive data with 1Gbps from A. However, addition of bandwidths of individual threads from B -> C was close to 1Gbps. I was expecting that B should be able to receive and send with 1Gbps simultaneously. (1Gbps RX, and 1Gbps TX). >>> >>> A -> B : 503 Mbps >>> B -> C : 490 Mbps x 2 threads = 880Mbps >>> >>> If I increase A->B thread from 1 to 2, each thread can send with more bandwidth. Also, I didn't observe this problem when A->B sender was UDP, i.e. rate of UDP remained closed to 1Gbps. >>> >>> Setup Used >>> All machines were running kernel 3.1.0-030100-generic of Ubuntu. >>> Each machine has 8 CPUs. >>> Broadcom BCM5721 Ethernet card. >>> Above test was verified with a custom program and netperf. >>> >>> Sorry if this is not a relevant mailing list. >> If indeed tcpm is not an appropriate list (not sure I can say really), since netperf was involved, you might consider netperf-talk@netperf.org. There you would probably be asked clarifying questions such as: >> >> *) If B sending to C required two streams, what led you to believe that A sending to be would require only one? >> *) What were your exact netperf command lines? >> *) What were the utilizations of each of the CPUs on each system during the test? >> *) What is the latency between A and B? >> *) Others that I cannot think of just now :) >> >> Alternatively, since a linux kernel is involved, it may be appropriate to ask in something like the netdev mailing list. Though your use of what to them would be considered an "old" kernel might lead to their first asking you to use a newer one. >> >> happy benchmarking, >> >> rick jones >> _______________________________________________ >> 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 From Karen.Nielsen@tieto.com Tue Sep 25 00:01:59 2012 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 D89D821F8927; Tue, 25 Sep 2012 00:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GGwuRRo2WTv; Tue, 25 Sep 2012 00:01:58 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id 8057921F890D; Tue, 25 Sep 2012 00:01:57 -0700 (PDT) X-AuditID: 83cfa824-b7f2c6d0000009fa-fb-506156e36c14 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id F0.06.02554.3E651605; Tue, 25 Sep 2012 10:01:55 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.121]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Tue, 25 Sep 2012 10:01:54 +0300 From: To: Date: Tue, 25 Sep 2012 10:01:53 +0300 Thread-Topic: rtorestart applicable for SCTP ? Thread-Index: Ac2a66T5VBzC+ClCTlufoA0AU1T12A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B2554B8D17BEXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsXSfL5DS/dxWGKAweGvehafV15gtdh2cj6T xbE3d9kcmD2WLPnJ5PH3QitbAFMUl01Kak5mWWqRvl0CV8bZW3cZC1amVGxuvMzSwHg0qouR k0NCwETi9f83jBC2mMSFe+vZuhi5OIQEVjFK3Hy8nBnCmcIoce3VBFaQKjYBeYm5e1exg9gi AuISa+c/BOrg4GAWUJVY/ywWJMwCZHad38AEYgsLaEr8b1zNBFGuJ3G5ZwEzjL31/RuwMbwC PhJtzSvYQGxGoCO+n1oDVs8MNP7Wk/lMEMcJSCzZc54ZwhaVePn4HytEvajEnfb1jBD1+RLT lsxhhpgpKHFy5hOWCYzCs5CMmoWkbBaSMoi4nsSNqVPYIGxtiWULXzND2LoSM/4dYkEWX8DI voqRPzUpycBUryQztSRfLzk/dxMjOHpWqOxgPPtA6hCjAAejEg/vjdaEACHWxLLiytxDjJIc TEqivGxBiQFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHh3ywDleFMSK6tSi/JhUtIcLErivLum Ak0SSE8sSc1OTS1ILYLJynBwKEnwJoQCNQoWpaanVqRl5pQgpJk4OEGG8wANjwap4S0uSMwt zkyHyJ9iVJQS510KkhAASWSU5sH1wpLbK0ZxoFeEeWtBqniAiRGu+xXQYCagwfx74kAGlyQi pKQaGDV+v3DeUz835ewro3nLjtvVNxjLb7u3b5fpv/woC9XNFlKtfde36ajo7/uc4X7l3Nsr vxMrP82Lmn5upZTzGftvbfncv2ozNSaL/O7mPTf/j9K82R/lWy68Om1ovq7p4SaZhJv1rP9L c4yPFuyVEWK0Uy7TDBBX4Dq/caFHUo1R4w7PDSf99JRYijMSDbWYi4oTAXx+sCtJAwAA Cc: tcpm@ietf.org, tsvwg@ietf.org Subject: [tcpm] rtorestart applicable for SCTP ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2012 07:02:00 -0000 --_000_CF340E42AED0874C81947E18863DE77B2554B8D17BEXMB03eutieto_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This comment is related to draft-hurtig-tcpm-rtorestart-02. The work seems to assume that SCTP T3 handling is as in TCP, which it is no= t. By prescription SCTP should already implement "almost" the mechanism descri= bed in the draft as indeed it is prescribed to: Section 6.3.2: R3) Whenever a SACK is received that acknowledges the DATA chunk with the earliest outstanding TSN for that address, restart the T3-rtx timer for that address with its current RTO (if there is still outstanding data on that address). The difference in between the Rtorestart draft and existing SCTP prescripti= on then seems to be that SCTP does it always not only under special circumstances - ? The latter perhaps then should be questioned - in particular if STCP, as TC= P, is to start using larger initial CWNDs. BR, Karen PS: I have not followed discussions on the work, draft-hurtig-tcpm-rtorestart-02, in the past, so my comment may already have been discussed. If so than I apologize in advance ! ***************************************************************************= ************** Karen Egede Nielsen Software Architect, Ph.D. Tieto Denmark A/S IP Solutions, R&D Services =C5have Parkvej 27, 2nd, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com Please note: The information contained in this message may be legally privi= leged and confidential and protected from disclosure. If the reader of this= message is not the intended recipient, you are hereby notified that any un= authorised use, distribution or copying of this communication is strictly p= rohibited. If you have received this communication in error, please notify = us immediately by replying to the message and deleting it from your compute= r. Thank You. --_000_CF340E42AED0874C81947E18863DE77B2554B8D17BEXMB03eutieto_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

=

 

This comment is related= to draft-hurtig-tcpm-rtorestart-02.

=  

The work seems to assume that SCTP T3 ha= ndling is as in TCP, which it is not.

By p= rescription SCTP should already implement “almost” the mechanis= m described in the draft as indeed

it is = prescribed to:

 

Section 6.3.2:

<= o:p> 

=A0=A0 R3)=A0 Whenever a SACK is received th= at acknowledges the DATA chunk

=A0=A0=A0=A0=A0=A0= =A0 with the earliest outstanding TSN for that address, restart the<= o:p>

=A0=A0=A0=A0=A0=A0=A0 T3-rtx timer for that addres= s with its current RTO (if there is

=A0=A0=A0=A0= =A0=A0=A0 still outstanding data on that address).

 

=  

The difference in be= tween the Rtorestart draft and existing SCTP prescription then seems to be = that SCTP does it always not

= only under special circumstances - ?

 

The latter per= haps then should be questioned – in particular if STCP, as TCP, is to= start using larger initial CWNDs.

 

BR, Karen

 

&nb= sp;

PS: =A0I have not followed discussions on t= he work,

draft-hurtig-tcpm-rtorestart-02, = in the past, so my comment

may already hav= e been discussed. If so than I apologize in advance !

=

 

 

 

******************************= ***********************************************************

Karen Egede Nielsen

Software Archi= tect, Ph.D.

 

Tiet= o Denmark A/S

IP Solutions, R&D Service= s

=C5have Parkvej 27, 2nd, 8260 Viby J, DK-Denm= ark

Direct Phone / Mobile +45 25134336<= /o:p>

E-mail: karen.nielsen@tieto.com

****************************************************************= *************************

www.tieto.com=A0=

 

Please note: The i= nformation contained in this message may be legally privileged and confiden= tial and protected from disclosure. If the reader of this message is not th= e intended recipient, you are hereby notified that any unauthorised use, di= stribution or copying of this communication is strictly prohibited. If you = have received this communication in error, please notify us immediately by = replying to the message and deleting it from your computer. <= span lang=3DDA style=3D'font-size:7.5pt;font-family:"Arial","sans-serif"'>T= hank You.

 

 

= --_000_CF340E42AED0874C81947E18863DE77B2554B8D17BEXMB03eutieto_-- From Karen.Nielsen@tieto.com Tue Sep 25 08:55:17 2012 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 CC6BB21F8809; Tue, 25 Sep 2012 08:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9x23DeJjdnu; Tue, 25 Sep 2012 08:55:15 -0700 (PDT) Received: from ebb05.tieto.com (ebb05.tieto.com [131.207.168.36]) by ietfa.amsl.com (Postfix) with ESMTP id EB8EF21F879C; Tue, 25 Sep 2012 08:55:10 -0700 (PDT) X-AuditID: 83cfa824-b7f2c6d0000009fa-92-5061d3ddb671 Received: from FIVLA-EXHUB02.eu.tieto.com ( [131.207.136.42]) by ebb05.tieto.com (SMTP Mailer) with SMTP id 1C.2E.02554.DD3D1605; Tue, 25 Sep 2012 18:55:09 +0300 (EEST) Received: from EXMB03.eu.tieto.com ([169.254.1.121]) by FIVLA-EXHUB02.eu.tieto.com ([131.207.136.42]) with mapi; Tue, 25 Sep 2012 18:55:09 +0300 From: To: Date: Tue, 25 Sep 2012 18:55:04 +0300 Thread-Topic: rtorestart applicable for SCTP ? Thread-Index: Ac2a66T5VBzC+ClCTlufoA0AU1T12AASlqSw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF340E42AED0874C81947E18863DE77B2554B8D4B2EXMB03eutieto_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNKsWRmVeSWpSXmKPExsXSfL5DS/fu5cQAg7Z9qhafV15gtdh2cj6T xbE3d9kcmD2WLPnJ5PH3QitbAFMUl01Kak5mWWqRvl0CV8bNiX4FH0orTjSsYG1gPJ/VxcjJ ISFgInH/7x9mCFtM4sK99WwgtpDAKkaJO+eCuhi5gOwpjBKfpn0ES7AJyEvM3buKHcQWERCX WDv/IVCcg4NZQFVi/bNYkDALkLmp9wUjiC0soCtx49kcqHI9ics9C5ghbCOJKxNmMoHYvAI+ Em3/ulkg9vpIXFo4jwVkJKeAr8Tzn2BjGIFO+35qDVg5M9DWW0/mM0GcLCCxZM95qPNFJV4+ /scKUS8qcad9PSNEfb7E3I272CBWCUqcnPmEZQKj6Cwko2YhKZuFpAwiridxY+oUNghbW2LZ wtfMELauxIx/h1iQxRcwsq9i5E9NSjIw1SvJTC3J10vOz93ECI6zFSo7GM8+kDrEKMDBqMTD e6M1IUCINbGsuDL3EKMkB5OSKG/5kcQAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8sseAcrwp iZVVqUX5MClpDhYlcd5dU4EmCaQnlqRmp6YWpBbBZGU4OJQkeFddAmoULEpNT61Iy8wpQUgz cXCCDOcBGr4bpIa3uCAxtzgzHSJ/ilFRSpz3CEhCACSRUZoH1wtLg68YxYFeEeZdDlLFA0yh cN2vgAYzAQ3m3xMHMrgkESEl1cDI/EM4UXuayknju/1ZIZFZVuIOB7fL6Dkm8n/94ZraV8Es NTHTR2IBZ2eToVPZgtoogZwlP1la0ycK9e9n7bf/4J623r78yqP1N55s+80348xUBql7bvJr 7mS9z6mwf+2221ft6dI7RjtfBb23b1l/zneWqqpXf/HruodPeBpkJnjdfVBh+0yJpTgj0VCL uag4EQBn+RP1XgMAAA== Cc: tcpm@ietf.org, tsvwg@ietf.org Subject: Re: [tcpm] rtorestart applicable for SCTP ? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2012 15:55:17 -0000 --_000_CF340E42AED0874C81947E18863DE77B2554B8D4B2EXMB03eutieto_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please disregard the email below. TCP and SCTP indeed do share the issue. BR, Karen From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Kar= en.Nielsen@tieto.com Sent: 25. september 2012 09:02 To: per.hurtig@kau.se Cc: tcpm@ietf.org; tsvwg@ietf.org Subject: [tcpm] rtorestart applicable for SCTP ? Hi, This comment is related to draft-hurtig-tcpm-rtorestart-02. The work seems to assume that SCTP T3 handling is as in TCP, which it is no= t. By prescription SCTP should already implement "almost" the mechanism descri= bed in the draft as indeed it is prescribed to: Section 6.3.2: R3) Whenever a SACK is received that acknowledges the DATA chunk with the earliest outstanding TSN for that address, restart the T3-rtx timer for that address with its current RTO (if there is still outstanding data on that address). The difference in between the Rtorestart draft and existing SCTP prescripti= on then seems to be that SCTP does it always not only under special circumstances - ? The latter perhaps then should be questioned - in particular if STCP, as TC= P, is to start using larger initial CWNDs. BR, Karen PS: I have not followed discussions on the work, draft-hurtig-tcpm-rtorestart-02, in the past, so my comment may already have been discussed. If so than I apologize in advance ! ***************************************************************************= ************** Karen Egede Nielsen Software Architect, Ph.D. Tieto Denmark A/S IP Solutions, R&D Services =C5have Parkvej 27, 2nd, 8260 Viby J, DK-Denmark Direct Phone / Mobile +45 25134336 E-mail: karen.nielsen@tieto.com ***************************************************************************= ************** www.tieto.com Please note: The information contained in this message may be legally privi= leged and confidential and protected from disclosure. If the reader of this= message is not the intended recipient, you are hereby notified that any un= authorised use, distribution or copying of this communication is strictly p= rohibited. If you have received this communication in error, please notify = us immediately by replying to the message and deleting it from your compute= r. Thank You. --_000_CF340E42AED0874C81947E18863DE77B2554B8D4B2EXMB03eutieto_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please disregard the email below.

<= p class=3DMsoNormal>TCP and SCTP indeed do share the issue.=

 

BR, Karen

=  

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> tcpm-bou= nces@ietf.org [mailto:tcpm-bounces@ietf.org] On Behalf Of Karen.Niel= sen@tieto.com
Sent: 25. september 2012 09:02
To: per.hu= rtig@kau.se
Cc: tcpm@ietf.org; tsvwg@ietf.org
Subject: = [tcpm] rtorestart applicable for SCTP ?

 

Hi,

 

This comment is rela= ted to draft-hurtig-tcpm-rtorestart-02.

 

The work seems to assume that SCTP T3= handling is as in TCP, which it is not.

B= y prescription SCTP should already implement “almost” the mecha= nism described in the draft as indeed

it = is prescribed to:

 =

Section 6.3.2:

   R3)  Whenever a SACK is= received that acknowledges the DATA chunk

 &= nbsp;      with the earliest outstanding TS= N for that address, restart the

   =      T3-rtx timer for that address with its current RTO= (if there is

      =   still outstanding data on that address).

 

 

The difference in between= the Rtorestart draft and existing SCTP prescription then seems to be that = SCTP does it always not

only = under special circumstances - ?

<= span lang=3DEN-GB style=3D'font-size:10.0pt;font-family:"Arial","sans-serif= "'> 

The latter perhaps = then should be questioned – in particular if STCP, as TCP, is to star= t using larger initial CWNDs.

 

BR, Karen=

 

 <= /o:p>

PS:  I have not followed discussions on th= e work,

draft-hurtig-tcpm-rtorestart-02, i= n the past, so my comment

may already have= been discussed. If so than I apologize in advance !

<= p class=3DMsoNormal> 

 =

 

*******************************= **********************************************************

Karen Egede Nielsen

Software Archit= ect, Ph.D.

 

Tieto= Denmark A/S

IP Solutions, R&D Services=

=C5have Parkvej 27, 2nd, 8260 Viby J, DK-Denma= rk

Direct Phone / Mobile +45 25134336

E-mail: karen.nielsen@tieto.com

=

*****************************************************************= ************************

www.tieto.com =

 

Please note: The i= nformation contained in this message may be legally privileged and confiden= tial and protected from disclosure. If the reader of this message is not th= e intended recipient, you are hereby notified that any unauthorised use, di= stribution or copying of this communication is strictly prohibited. If you = have received this communication in error, please notify us immediately by = replying to the message and deleting it from your computer. <= span lang=3DDA style=3D'font-size:7.5pt;font-family:"Arial","sans-serif"'>T= hank You.

 

 

= --_000_CF340E42AED0874C81947E18863DE77B2554B8D4B2EXMB03eutieto_--