From nobody Sun Nov 1 09:10:08 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BA41B89EC for ; Sun, 1 Nov 2015 09:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_hgguN9lOkz for ; Sun, 1 Nov 2015 09:10:05 -0800 (PST) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E158F1B2B77 for ; Sun, 1 Nov 2015 09:10:04 -0800 (PST) X-Spam-Processed: mail.kau.se, Sun, 01 Nov 2015 18:09:58 +0100 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 83.253.134.124 X-MDArrival-Date: Sun, 01 Nov 2015 18:09:58 +0100 X-Authenticated-Sender: per.hurtig@kau.se X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F907996C-1D3B-4416-8EE8-5192931C187F"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Per Hurtig In-Reply-To: <655C07320163294895BBADA28372AF5D485360EA@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Sun, 1 Nov 2015 18:09:54 +0100 Message-Id: <30BD13BD-232E-4837-865E-B9238BB853E0@kau.se> References: <20151020193954.12955.50870.idtracker@ietfa.amsl.com> <3500BC2B-A986-4AC8-BEF0-4709DEFE5D35@kau.se> <655C07320163294895BBADA28372AF5D48524F8A@FR712WXCHMBA15.zeu.alcatel-lucent.com> <562AAB5E.40502@kau.se> <655C07320163294895BBADA28372AF5D485360EA@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: "Scharf, Michael (Michael)" X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 01 Nov 2015 17:10:08 -0000 --Apple-Mail=_F907996C-1D3B-4416-8EE8-5192931C187F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, if there are no objections we=E2=80=99d go for =E2=80=9Ctimeout = duration=E2=80=9D? Cheers, Per > On 31 Oct 2015, at 01:49, Scharf, Michael (Michael) = wrote: >=20 > Maybe the authors could propose an alternative phrasing on the mailing = list, picking one of the potential alternative wordings, and update the = draft if there is no objection? >=20 > Since this is in the abstract, this seems to me better than waiting = for the RFC editor. >=20 > Michael >=20 > ________________________________________ > Von: Anna Brunstrom [anna.brunstrom@kau.se] > Gesendet: Freitag, 23. Oktober 2015 23:49 > An: Scharf, Michael (Michael); spencerdawkins.ietf@gmail.com > Cc: tcpm@ietf.org > Betreff: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-09.txt >=20 > Hi Michael, >=20 > I am not a native speaker either, but I agree with you that "timeout > duration" or "timeout value" sounds more clear. >=20 > BR, > Anna >=20 > On 2015-10-23 19:38, Scharf, Michael (Michael) wrote: >> Sorry for speaking up late... Just to cross-check with others. Is the = new wording in the abstract... >>=20 >> The modification, RTO Restart (RTOR), allows the >> transport to restart its retransmission timer using a smaller = delay, >> so that the effective RTO becomes more aggressive in situations = where >> fast retransmit cannot be used. This enables faster loss = detection >> and recovery for connections that are short-lived or application- >> limited. >>=20 >> ... indeed clear to everybody? To me (as a non-native speaker) this = use of "delay" in the context of the RTO is a bit confusing. >>=20 >> To me, a wording like replacing "delay" by "timeout duration", = "timeout value", etc. would sound more familiar. I'd rather use "delay" = as a measure between packet (re) transmissions, etc. >>=20 >> For instance, to me the following wording would fit a bit better ... >>=20 >> The modification, RTO Restart (RTOR), allows the >> transport to restart its retransmission timer using a smaller = timeout duration, >> so that the effective RTO becomes more aggressive in situations = where >> fast retransmit cannot be used. This smaller delay before the = retransmission enables faster loss detection >> and recovery for connections that are short-lived or application- >> limited. >>=20 >> But I am not a native speaker. Any thoughts? >>=20 >> (I guess the RFC editor could just review that.) >>=20 >> Michael >>=20 >>=20 >>> -----Original Message----- >>> From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Per Hurtig >>> Sent: Wednesday, October 21, 2015 9:55 AM >>> To: tcpm@ietf.org Extensions >>> Cc: bclaise@cisco.com; barryleiba@computer.org >>> Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-09.txt >>>=20 >>> Hi, >>>=20 >>> the new draft on RTO restart address the following comments from the >>> IESG (thanks for the feedback): >>>=20 >>> o Clarified, in the abstract, that the modified restart causes a >>> smaller retransmission delay in total. >>>=20 >>> o Clarified, in the introduction, that the fast retransmit = algorithm >>> may cause retransmissions upon >>> receiving duplicate acknowledgments, not that it unconditionally >>> does so. >>>=20 >>> o Changed wording from "to proposed standard" to "to the standards >>> track". >>>=20 >>> o Changed algorithm description so that a TCP sender MUST track the >>> time elapsed since the >>> transmission of the earliest outstanding segment. This was not >>> explicitly stated in previous >>> versions of the draft. >>>=20 >>>=20 >>> Cheers, >>> Per >>>=20 >>>> On 20 Oct 2015, at 21:39, internet-drafts@ietf.org wrote: >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>> This draft is a work item of the TCP Maintenance and Minor = Extensions >>> Working Group of the IETF. >>>> Title : TCP and SCTP RTO Restart >>>> Authors : Per Hurtig >>>> Anna Brunstrom >>>> Andreas Petlund >>>> Michael Welzl >>>> Filename : draft-ietf-tcpm-rtorestart-09.txt >>>> Pages : 17 >>>> Date : 2015-10-20 >>>>=20 >>>> Abstract: >>>> This document describes a modified sender-side algorithm for >>> managing >>>> the TCP and SCTP retransmission timers that provides faster loss >>>> recovery when there is a small amount of outstanding data for a >>>> connection. The modification, RTO Restart (RTOR), allows the >>>> transport to restart its retransmission timer using a smaller >>> delay, >>>> so that the effective RTO becomes more aggressive in situations >>> where >>>> fast retransmit cannot be used. This enables faster loss = detection >>>> and recovery for connections that are short-lived or application- >>>> limited. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ >>>>=20 >>>> There's also a htmlized version available at: >>>> https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-09 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rtorestart-09 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of >>> submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>>=20 >>>> _______________________________________________ >>>> 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 >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_F907996C-1D3B-4416-8EE8-5192931C187F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWNkdmAAoJEMzXVkqMT/z20QgIAK7PBqwGlRlxNeI4DzTFmeRN hG1lQDikk5k8NUHPT2hiw8kZgmcPdVWKzfYggEvvsxZoOsXqvoEaEQ+dhVCnWO0S 9a+PmrIrkG41qu2HlxsQzKgocenT1gohEIQAuvPYwJazyy/Yio/zJc2goRsS9zzN pPuv7oaYv0lpnKdF4yqZYBDxz7KjUdFgYcMFv5RroJ1th7gDbo9p6XsU4+lhj1p5 4eMKuES/D27qygHwLEUFTm1HEHpVFA9pJY62DOea/icjsRmEtldDMU+vXQpwAvkO nZ+qd0oAKRybau8+wP5cGuX7ZU/Wzn7n5twEwAV2VGS7GdfqSazNPlpkSlUgpg8= =5qzh -----END PGP SIGNATURE----- --Apple-Mail=_F907996C-1D3B-4416-8EE8-5192931C187F-- From nobody Sun Nov 1 15:38:03 2015 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD3C1B3A9C; Sun, 1 Nov 2015 15:38:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151101233801.27010.85072.idtracker@ietfa.amsl.com> Date: Sun, 01 Nov 2015 15:38:01 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-dctcp-01.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 23:38:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters Authors : Stephen Bensley Lars Eggert Dave Thaler Praveen Balasubramanian Glenn Judd Filename : draft-ietf-tcpm-dctcp-01.txt Pages : 14 Date : 2015-11-01 Abstract: This informational memo describes Datacenter TCP (DCTCP), an improvement to TCP congestion control for datacenter traffic. DCTCP uses improved Explicit Congestion Notification (ECN) processing to estimate the fraction of bytes that encounter congestion, rather than simply detecting that some congestion has occurred. DCTCP then scales the TCP congestion window based on this estimate. This method achieves high burst tolerance, low latency, and high throughput with shallow-buffered switches. This memo also discusses deployment issues related to the coexistence of DCTCP and conventional TCP, the lack of a negotiating mechanism between sender and receiver, and presents some possible mitigations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-dctcp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-dctcp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-dctcp-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 1 16:50:14 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D931B3EA6; Sun, 1 Nov 2015 16:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n06_WW92VfxK; Sun, 1 Nov 2015 16:50:01 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8921B3EA0; Sun, 1 Nov 2015 16:50:01 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 751B5180006; Sun, 1 Nov 2015 16:49:09 -0800 (PST) To: mjl@caida.org, ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151102004909.751B5180006@rfc-editor.org> Date: Sun, 1 Nov 2015 16:49:09 -0800 (PST) Archived-At: Cc: mls.ietf@gmail.com, tcpm@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] [Errata Verified] RFC7413 (4238) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 00:50:05 -0000 The following errata report has been verified for RFC7413, "TCP Fast Open". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7413&eid=4238 -------------------------------------- Status: Verified Type: Technical Reported by: Matthew Luckie Date Reported: 2015-01-22 Verified by: Martin Stiemerling (IESG) Section: 4.1.1 Original Text ------------- Kind 1 byte: value = 34 Length 1 byte: range 6 to 18 (bytes); limited by remaining space in the options field. The number MUST be even. Cookie 0, or 4 to 16 bytes (Length - 2) Corrected Text -------------- Kind 1 byte: value = 34 Length 1 byte: range 2 to 18 (bytes); limited by remaining space in the options field. The number MUST be even. Cookie 0, or 4 to 16 bytes in length (Length - 2) Notes ----- A Nil cookie is a fast open option with no cookie value. A length range of 6 to 18 bytes excludes a Nil cookie. -------------------------------------- RFC7413 (draft-ietf-tcpm-fastopen-10) -------------------------------------- Title : TCP Fast Open Publication Date : December 2014 Author(s) : Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain Category : EXPERIMENTAL Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Sun Nov 1 23:51:11 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7D1B3455 for ; Sun, 1 Nov 2015 23:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.514 X-Spam-Level: * X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQVffC23020f for ; Sun, 1 Nov 2015 23:51:09 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EF21B343F for ; Sun, 1 Nov 2015 23:51:08 -0800 (PST) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C4038278161 for ; Mon, 2 Nov 2015 16:51:06 +0900 (JST) Received: by oiad129 with SMTP id d129so90646367oia.0 for ; Sun, 01 Nov 2015 23:51:05 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.3.6 with SMTP id 6mr11428746oid.4.1446450665260; Sun, 01 Nov 2015 23:51:05 -0800 (PST) Received: by 10.202.218.213 with HTTP; Sun, 1 Nov 2015 23:51:05 -0800 (PST) Date: Sun, 1 Nov 2015 23:51:05 -0800 Message-ID: From: Yoshifumi Nishida To: "tcpm@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [tcpm] slides for Yokohama meeting X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 02 Nov 2015 07:51:10 -0000 Hello presenters for Yokohama meeting. Please make sure to send your slide by ** Wednesday (11/4) noon ** to chairs. We appreciate your cooperation! Thanks, -- Yoshi From nobody Mon Nov 2 08:59:07 2015 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3C41B49BA; Mon, 2 Nov 2015 08:59:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.7.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151102165905.17257.98085.idtracker@ietfa.amsl.com> Date: Mon, 02 Nov 2015 08:59:05 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-tcp-edo-04.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 16:59:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP Extended Data Offset Option Authors : Joe Touch Wesley M. Eddy Filename : draft-ietf-tcpm-tcp-edo-04.txt Pages : 23 Date : 2015-11-02 Abstract: TCP segments include a Data Offset field to indicate space for TCP options but the size of the field can limit the space available for complex options such as SACK and Multipath TCP and can limit the combination of such options supported in a single connection. This document updates RFC 793 with an optional TCP extension to that space to support the use of multiple large options. It also explains why the initial SYN of a connection cannot be extending a single segment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-tcp-edo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-tcp-edo-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-tcp-edo-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 3 05:04:52 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801EF1B3343 for ; Tue, 3 Nov 2015 05:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9aOKb4f_2bT for ; Tue, 3 Nov 2015 05:04:48 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FCD71B333C for ; Tue, 3 Nov 2015 05:04:48 -0800 (PST) X-AuditID: c1b4fb3a-f79136d0000071e2-49-5638b0ee239f Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.1B.29154.EE0B8365; Tue, 3 Nov 2015 14:04:46 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.152]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Tue, 3 Nov 2015 14:03:57 +0100 From: Ingemar Johansson S To: Neal Cardwell Thread-Topic: New Version Notification for draft-cheng-tcpm-rack-00.txt Thread-Index: AQHRDnYmRuHtiOYliUy6k+19xhevN56BFH8g///+voCACTykMA== Date: Tue, 3 Nov 2015 13:03:56 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA34EB085F@ESESSMB205.ericsson.se> References: <20151019201145.14841.30865.idtracker@ietfa.amsl.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34C0F674@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbHdXvfdBoswg3NvpCw67uxlsdh2cj6T xZfHV9kcmD0WbCr1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxuzDW1gKOsQrXu7uZW9g3CPWxcjB ISFgIvH2TGgXIyeQKSZx4d56ti5GLg4hgcOMEu9+XoJyFjNKPF+wnhmkik3ARmLloe+MILaI gIbE3UUPwGxmATeJnsv32UFsYSB76suLTBA17hKz385hg7CdJKbcOckCYrMIqEhMnNgBZvMK +ErM+PCRGWLZZCaJ+Z2PwYZyCgRKnH//B6yZUUBW4v73eywQy8Qlbj2ZzwRxtoDEkj3nmSFs UYmXj/+xQtiKEh9f7WME+ZJZQFNi/S59iFZFiSndD9kh9gpKnJz5hGUCo9gsJFNnIXTMQtIx C0nHAkaWVYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiBUXRwy2+rHYwHnzseYhTgYFTi4d2w yTxMiDWxrLgy9xCjBAezkgjv7rkWYUK8KYmVValF+fFFpTmpxYcYpTlYlMR5m5kehAoJpCeW pGanphakFsFkmTg4pRoYUyaK+QfzJN9cGtW4g7PaOPV3JfM75vY9oua3o+/2beVw3njfxVC9 7fJ6L2aOtKPJfG8jjmydWLBNKD+U6e1eaw6tbyHiOxdNe+FS8Z3jytdlL6Yx7Zn9Qcp5j+6b K/rJ+bv//6559WKqvjhDqan4DDfvmT8s2xfefSS+9rDEt0sBgeumzXu2XomlOCPRUIu5qDgR AL5BPa6eAgAA Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] New Version Notification for draft-cheng-tcpm-rack-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 13:04:50 -0000 SGkNCg0KQ29tbWVudHMgaW5saW5lDQpJbmdlbWFyDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogTmVhbCBDYXJkd2VsbCBbbWFpbHRvOm5jYXJkd2VsbEBnb29nbGUuY29t XQ0KPiBTZW50OiBkZW4gMjggb2t0b2JlciAyMDE1IDE3OjQ4DQo+IFRvOiBJbmdlbWFyIEpvaGFu c3NvbiBTDQo+IENjOiBZdWNodW5nIENoZW5nOyB0Y3BtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNoZW5nLXRjcG0tcmFjay0wMC50 eHQNCj4gDQo+IE9uIFdlZCwgT2N0IDI4LCAyMDE1IGF0IDEyOjAxIFBNLCBJbmdlbWFyIEpvaGFu c3NvbiBTDQo+IDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+ID4N Cj4gPiBUaGFua3MsIHJlYWxseSBpbnRlcmVzdGluZy4NCj4gPg0KPiA+IE9uZSBxdWVzdGlvbiAu DQo+ID4gUXVvdGUgIldoZW4gdGhlIHNlbmRlciBkZXRlY3RzIHBhY2tldCAgcmVvcmRlcmluZyBS QUNLLnJlb193bmQgTUFZDQo+IGJlIGNoYW5nZWQgdG8gUkFDSy5taW5fUlRULzQuIg0KPiA+IFdo eSB0aGUgdmFsdWUgTWluUlRULzQgPyBJcyB0aGlzIHJlbGF0ZWQgdG8gVExQID8uDQo+IA0KPiBH b29kIHF1ZXN0aW9uLiBUaGUgcmF0aW9uYWxlIGlzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDUuMywg IkFkanVzdGluZyB0aGUNCj4gcmVvcmRlcmluZyB3aW5kb3ciOg0KPiANCj4gICAgUkFDSyB1c2Vz IGEgcXVhcnRlciBvZiBtaW5pbXVtIFJUVCBiZWNhdXNlIExpbnV4IFRDUCB1c2VzIHRoZSBzYW1l DQo+ICAgIGZhY3RvciBpbiBpdHMgaW1wbGVtZW50YXRpb24gdG8gZGVsYXkgRWFybHkgUmV0cmFu c21pdCBbUkZDNTgyN10gdG8NCj4gICAgcmVkdWNlIHNwdXJpb3VzIGxvc3MgZGV0ZWN0aW9ucyBp biB0aGUgcHJlc2VuY2Ugb2YgcmVvcmRlcmluZywgYW5kDQo+ICAgIGV4cGVyaWVuY2Ugc2hvd3Mg dGhhdCB0aGlzIHNlZW1zIHRvIHdvcmsgcmVhc29uYWJseSB3ZWxsLg0KPiANCj4gPiBPbmUgb3B0 aW9uIG1heSBiZSB0byBzZXQgUkFDSy5yZW9fd25kIGFjY29yZGluZyB0byB0aGUgZXhwZXJpZW5j ZWQNCj4gPiBhbW91bnQgb2YgcmVvcmRlcmluZyBidXQgdGhhdCBjYW4gb2YgY291cnNlIGRlbGF5 IHJldHJhbnNtaXNzaW9uIG9mDQo+ID4gbG9zdCBwYWNrZXQuDQo+IA0KPiBZZXMsIHdlIGFncmVl IHRoYXQgaW52ZXN0aWdhdGluZyB0aGlzIGtpbmQgb2YgYXBwcm9hY2ggaXMgYXBwZWFsaW5nLCBh bmQgdGhpcyBpcw0KPiBhbHNvIGRpc2N1c3NlZCBpbiBzZWN0aW9uIDUuMywgIkFkanVzdGluZyB0 aGUgcmVvcmRlcmluZw0KPiB3aW5kb3ciOg0KPiANCj4gICAgT25lIHBvdGVudGlhbCBpbXByb3Zl bWVudCBpcyB0byBmdXJ0aGVyIGFkYXB0IHRoZSByZW9yZGVyaW5nIHdpbmRvdw0KPiAgICBieSBt ZWFzdXJpbmcgdGhlIGRlZ3JlZSBvZiByZW9yZGVyaW5nIGluIHRpbWUsIGluc3RlYWQgb2YgcGFj a2V0DQo+ICAgIGRpc3RhbmNlcy4gIEJ1dCB0aGF0IHJlcXVpcmVzIHN0b3JpbmcgdGhlIGRlbGl2 ZXJ5IHRpbWVzdGFtcCBvZiBlYWNoDQo+ICAgIHBhY2tldC4gIFNvbWUgc2NvcmVib2FyZCBpbXBs ZW1lbnRhdGlvbnMgY3VycmVudGx5IG1lcmdlIFNBQ0tlZA0KPiAgICBwYWNrZXRzIHRvZ2V0aGVy IHRvIHN1cHBvcnQgVFNPIChUQ1AgU2VnbWVudGF0aW9uIE9mZmxvYWQpIGZvciBmYXN0ZXINCj4g ICAgc2NvcmVib2FyZCBpbmRleGluZy4gIFN1cHBvcnRpbmcgcGVyLXBhY2tldCBkZWxpdmVyeSB0 aW1lc3RhbXBzIGlzDQo+ICAgIGRpZmZpY3VsdCBpbiBzdWNoIGltcGxlbWVudGF0aW9ucy4gIEhv d2V2ZXIsIHdlIGFja25vd2xlZGdlIHRoYXQgdGhlDQo+ICAgIGN1cnJlbnQgbWV0cmljIGNhbiBi ZSBpbXByb3ZlZCBieSBmdXJ0aGVyIHJlc2VhcmNoLg0KT0ssIHVuZGVyc3RhbmQsIEl0IG1heSB3 ZWxsIGJlIHRoYXQgYW4gYWRhcHRpdmUgcmVvcmRlcmluZyB3aW5kb3cgbWF5IGJlY29tZSB0b28g Y29tcGxleCB0byBtYWludGFpbi4gDQpJIGd1ZXNzIFFVSUMgZGVsaXZlcnMgdGhlIHN0b3JlIHRp bWVzdGFtcHMgZm9yIGZyZWUgYXMgaXQgb3BlcmF0ZXMgb24gcGVyIHBhY2tldCBiYXNpcyA/DQoN Cg0KPiANCj4gVGhhbmtzIGZvciB0aGUgZmVlZGJhY2shDQo+IA0KPiBuZWFsDQo= From nobody Tue Nov 3 05:19:04 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AA71B3352 for ; Tue, 3 Nov 2015 05:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mycDwj_Dnbh for ; Tue, 3 Nov 2015 05:19:02 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78B621B3364 for ; Tue, 3 Nov 2015 05:18:54 -0800 (PST) X-AuditID: c1b4fb25-f79a26d00000149a-de-5638b43c1c7e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 89.15.05274.C34B8365; Tue, 3 Nov 2015 14:18:52 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.152]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Tue, 3 Nov 2015 14:18:35 +0100 From: Ingemar Johansson S To: Veaceslav ROMAN , Neal Cardwell Thread-Topic: [tcpm] [e2e] TCP HyStart patch deployment Thread-Index: AdCXp+zNDAZ7zydkTra0wALqZYyJLQH+JqqAA0qsYsAOCTWagAADKaaAABZGAgAAAuJsAABGVozQ///TRACAAB/3AIAAKj8AgAEIjoCAABVIgP//hZhA/9ZLHXD/q+ph8P9XvOWw/q9KtpD9XnrA8Pq87vsQ9Xnw1wDq7PsqANXZxFgAq6D0qADXJ4+XAA== Date: Tue, 3 Nov 2015 13:18:34 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA34EB08A1@ESESSMB205.ericsson.se> References: <81564C0D7D4D2A4B9A86C8C7404A13DA32145DE4@ESESSMB205.ericsson.se> <1FFD9A11-ADF2-4BA6-A9D3-D8997E1A13E5@gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34B2E666@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E64B65@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E65133@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E676EF@XCHSRV01.main.orange.md> <1441314842.8932.222.camel@edumazet-glaptop2.roam.corp.google.com> <1441385297.17208.6.camel@edumazet-glaptop2.roam.corp.google.com> <7DBBB686E19D2049ADAACD210B474BB10166E856CA@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD84BC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E859FB@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD86EC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E85C4E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD880B@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E8BDBA@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10167E64F3E@XCHSRV01.main.orange.md> In-Reply-To: <7DBBB686E19D2049ADAACD210B474BB10167E64F3E@XCHSRV01.main.orange.md> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM+Jvra7NFoswg6evNSyeHnvEbrH73FQW i33vz7JZdNzZC2TNmMhoceTKMUaLbSfnM1m8/7+R2YHDY+esu+weCzaVeixZ8pPJY8myp4we Hcc3MAewRnHZpKTmZJalFunbJXBlvG36yFLwRbHi7dbvjA2MLYpdjJwcEgImEjO/HWSDsMUk LtxbD2RzcQgJHGGUOL5pDTOEs5hR4uOkzUwgVWwCNhIrD31nBLFFBMIlprbeYAcpYhbYwiRx dsM/sFHCAmYSt5reMUMUmUtMOt0GNklE4ByjxNJnF1lAEiwCKhK3G58BTeLg4BXwlXg32QJi 2yEeib49f8A2cAoESrzsWs8OYjMKyErc/34PrJdZQFzi1pP5TBB3C0gs2XOeGcIWlXj5+B8r hK0o8fHVPrD5zAKaEut36UO0KkpM6X4INpJXQFDi5MwnLBMYxWYhmToLoWMWko5ZSDoWMLKs YhQtTi1Oyk03MtZLLcpMLi7Oz9PLSy3ZxAiMzINbfqvuYLz8xvEQowAHoxIP74ZN5mFCrIll xZW5hxglOJiVRHh3z7UIE+JNSaysSi3Kjy8qzUktPsQozcGiJM7bzPQgVEggPbEkNTs1tSC1 CCbLxMEp1cCY8PyT/wnZ/0vVPH9MiNf12Kp1V23u6V/bw5dovzbb11mcbZnN8S/lx+u2lJ3T Htxc0HdDIcTv+fc9zu/jFZjuiPXKPpt0WIhlQgunpuTWv4cmsBWXzN225PvfkmPuM815nz/R 4SqRM5ZwlZrek7V3+WRh5tfloY57jU3NA1V3Rsb9SMubceOEEktxRqKhFnNRcSIAodD4BMgC AAA= Archived-At: Cc: "tcpm@ietf.org" , Piers O'Hanlon , Sangtae Ha , Ingemar Johansson S , Eric Dumazet , "end2end-interest@postel.org" Subject: Re: [tcpm] [e2e] TCP HyStart patch deployment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 13:19:03 -0000 SGkNCg0KVGhhbmtzIGZvciBkb2luZyB0aGUgZXhwZXJpbWVudHMuIA0KSXQgbWF5IGJlIHBvc3Np YmxlIHRoYXQgSHlTdGFydCBtYXkgbmVlZCBtb3JlIGV4dGVuc2l2ZSBtb2RpZmljYXRpb25zLiAN Ck5lZWQgdG8gYXNrIHRoZSBkdW1iIHF1ZXN0aW9uIGZpcnN0IHRob3VnaC4gSXMgSFlTVEFSVF9E RUxBWV9NQVggbW9kaWZpZWQgaW4geW91ciBleHBlcmltZW50IG9yIGlzIGl0IHN0aWxsIDE2bXMg Pw0KSSBndWVzcyBIWVNUQVJUX0RFTEFZX01BWCBtYXkgbmVlZCB0byBiZSBzZXQgdG8gDQogICAg SFlTVEFSVF9ERUxBWV9NQVggPSBNQVgoMTZtcywgSFlTVEFSVF9ERUxBWV9NSU4qMikgDQpPciBz b21ldGhpbmcgc2ltaWxhciwgb25lIGNhbiBhbHdheXMgYXJndWUgYXJvdW5kIHRoZSBmYWN0b3Ig MiBhYm92ZS4NCg0KL0luZ2VtYXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBWZWFjZXNsYXYgUk9NQU4gW21haWx0bzpWZWFjZXNsYXYuUm9tYW5Ab3JhbmdlLm1kXQ0K PiBTZW50OiBkZW4gMTcgb2t0b2JlciAyMDE1IDIyOjQ4DQo+IFRvOiBOZWFsIENhcmR3ZWxsDQo+ IENjOiBFcmljIER1bWF6ZXQ7IEluZ2VtYXIgSm9oYW5zc29uIFM7IEVyaWMgRHVtYXpldDsgdGNw bUBpZXRmLm9yZzsgUGllcnMNCj4gTydIYW5sb247IFNhbmd0YWUgSGE7IGVuZDJlbmQtaW50ZXJl c3RAcG9zdGVsLm9yZw0KPiBTdWJqZWN0OiBSRTogW3RjcG1dIFtlMmVdIFRDUCBIeVN0YXJ0IHBh dGNoIGRlcGxveW1lbnQNCj4gDQo+IEhpLA0KPiBSZWNvbXBpbGVkIGtlcm5lbCB0byBIWVNUQVJU X0RFTEFZX01JTiAgMjAgbXM6DQo+IA0KPiAgIERvd25sb2FkIDEwTUIsIEhpZ2ggQmFuZHdpZHRo cywgSFlTVEFSVF9ERUxBWV9NSU4gIDIwIG1zOg0KPiAgICAgICAgICAgIEh5c3RhcnQgYXZlcmFn ZSBkb3dubG9hZCB0aW1lOiAxLjE4IHMNCj4gICAgICAgICAgICBOb0h5c3RhcnQgYXZlcmFnZSBk b3dubG9hZCB0aW1lOiAxLjAwICBzDQo+IA0KPiBObyBzaWduaWZpY2FudCBpbXByb3ZlbWVudCBh Z2FpbnN0IHRoZSBjYXNlIHdpdGggSFlTVEFSVF9ERUxBWV9NSU4gIDEwDQo+IG1zLg0KPiANCj4g U2lsbCBIeXN0YXJ0IGVhcmx5IGV4aXQgaXMgdmlzaWJsZS4NCj4gDQo+IE90aGVyIHRlc3RzIHdp dGggSFlTVEFSVF9ERUxBWV9NSU4gIDIwIG1zIGFuZCBmaWxlcyBvZiAzTUIuDQo+IA0KPiAgIERv d25sb2FkIDNNQiwgSGlnaCBCYW5kd2lkdGhzLCBIWVNUQVJUX0RFTEFZX01JTiAgMjAgbXM6DQo+ ICAgICAgICAgICAgSHlzdGFydCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6IDAuNDcgcw0KPiAgICAg ICAgICAgIE5vSHlzdGFydCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6IDAuMzkgIHMNCj4gDQo+IGNv bXBhcmUgd2l0aCA0IG1zDQo+IA0KPiAgIERvd25sb2FkIDNNQiwgSGlnaCBCYW5kd2lkdGhzLCBI WVNUQVJUX0RFTEFZX01JTiAgNCBtczoNCj4gICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2UgZG93 bmxvYWQgdGltZTogMC42NSBzDQo+ICAgICAgICAgICAgTm9IeXN0YXJ0IGF2ZXJhZ2UgZG93bmxv YWQgdGltZTogMC4zNyAgcw0KPiANCj4gRmV3IG1vcmUgY29tbWVudDogSGlnaCBCYW5kd2lkdGgg aXMgdHlwaWNhbGx5IGFib3ZlIDMwLTQwIE1icHMuDQo+IEZvciBMb3cgQmFuZHdpZHRoLCB3aGVu IHJhZGlvIGRvIG5vdCBwZXJtaXQgYWJvdmUgNDAgTWJwcyBIeXN0YXJ0IGVhcmx5DQo+IGV4aXQg ZG9lcyBub3QgaGF2ZSBhIHNpZ25pZmljYW50IGltcGFjdC4gSSBkbyBleHBsYWluIGl0IHdpdGgg dGhlIGZhY3QgdGhhdCB0aGUNCj4gbWluaW11bSBleGl0IENXTkQgZm9yIEh5c3N0YXJ0IGlzIDI5 IHdoaWNoLCBmb3IgUlRUIG9mIH4xNW1zIChtaW5pbXVtDQo+IHBvc3NpYmxlIGluIExURSBhbmQg dmlzaWJsZSBpbiBtYWpvcml0eSBvZiB0cmFjZXMpIGxlYWRzIHRvIH4yNSBNYnBzLCBzbyBIeXN0 YXJ0DQo+IGV4aXQsIGF0IGxlYXN0LCBhdCAyNSBNYnBzIGFuZCB0aGVuIGl0IHRha2VzIG5vdCB0 b28gbG9uZyB0byBjdWJpYyB0byByZWFjaCAzMC00MA0KPiBNYnBzLg0KPiANCj4gVmVhY2VzbGF2 IFJvbWFuDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOZWFsIENh cmR3ZWxsIFttYWlsdG86bmNhcmR3ZWxsQGdvb2dsZS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIDA2 IE9jdG9iZXIgMjAxNSAwNDowNg0KPiBUbzogVmVhY2VzbGF2IFJPTUFODQo+IENjOiBFcmljIER1 bWF6ZXQ7IEluZ2VtYXIgSm9oYW5zc29uIFM7IEVyaWMgRHVtYXpldDsgdGNwbUBpZXRmLm9yZzsg UGllcnMNCj4gTydIYW5sb247IFNhbmd0YWUgSGE7IGVuZDJlbmQtaW50ZXJlc3RAcG9zdGVsLm9y Zw0KPiBTdWJqZWN0OiBSZTogW3RjcG1dIFtlMmVdIFRDUCBIeVN0YXJ0IHBhdGNoIGRlcGxveW1l bnQNCj4gDQo+IE9uIE1vbiwgT2N0IDUsIDIwMTUgYXQgNjowNyBQTSwgVmVhY2VzbGF2IFJPTUFO DQo+IDxWZWFjZXNsYXYuUm9tYW5Ab3JhbmdlLm1kPiB3cm90ZToNCj4gPiBXZSd2ZSBtYW5hZ2Vk IHRvIHJlY29tcGlsZSB0aGUga2VybmVsIDQuMSB3aXRoIHRjcF9jdWJpYw0KPiBIWVNUQVJUX0RF TEFZX01JTiAgKDEwVTw8MykgLCAxMG1zLg0KPiA+IFdlbGwsIHdlIGhhZCB0aW1lIG9ubHkgZm9y IG9uZSB0ZXN0IGN5Y2xlLCBidXQgcmVzdWx0cyBhcmUgdmVyeSBwcm9taXNpbmc6DQo+ID4NCj4g PiBEb3dubG9hZCAxME1CLCBIaWdoIEJhbmR3aWR0aHMsIEhZU1RBUlRfREVMQVlfTUlOICAxMCBt czoNCj4gPiAgICAgICAgICAgIEh5c3RhcnQgYXZlcmFnZSBkb3dubG9hZCB0aW1lOiAxLjE2IHMN Cj4gPiAgICAgICAgICAgIE5vSHlzdGFydCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6IDAuOTMgIHMN Cj4gLi4uDQo+ID4gIERvd25sb2FkIDEwTUIsIEhpZ2ggQmFuZHdpZHRocywgSFlTVEFSVF9ERUxB WV9NSU4gIDQgbXM6DQo+ID4gICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2UgZG93bmxvYWQgdGlt ZTogMS40MiBzDQo+ID4gICAgICAgICAgICBOb0h5c3RhcnQgYXZlcmFnZSBkb3dubG9hZCB0aW1l OiAwLjg5ICBzDQo+IA0KPiBUaGFua3MhIFRoYXQgaXMgdmVyeSB1c2VmdWwgYW5kIGludGVyZXN0 aW5nIGRhdGEuIFdvdWxkIHlvdSBiZSBhYmxlIHRvIHRyeSBhDQo+IGZldyBvdGhlciB2YWx1ZXMs IGxpa2UgMTVtcyBhbmQgMjBtcz8NCj4gDQo+IG5lYWwNCg== From nobody Tue Nov 3 11:06:02 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3421A3BA6 for ; Tue, 3 Nov 2015 11:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVDneNEH4zHS for ; Tue, 3 Nov 2015 11:05:57 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by ietfa.amsl.com (Postfix) with ESMTP id F203D1A3BA7 for ; Tue, 3 Nov 2015 11:05:56 -0800 (PST) Received: from localhost.localdomain (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with ESMTP id 050293B27BE; Tue, 3 Nov 2015 21:06:08 +0200 (EET) Received: from antispam.orange.md by antispam.orange.md with queue id 253271-1; Tue, 03 Nov 2015 19:06:07 GMT Received: from XCHSRV04.main.orange.md (unknown [192.168.200.64]) by mailfilter.orange.md (Postfix) with ESMTP id D21973B27AC; Tue, 3 Nov 2015 21:06:07 +0200 (EET) Received: from XCHSRV01.main.orange.md ([fe80::685f:aef6:93b0:dea7]) by XCHSRV04.main.orange.md ([fe80::bdbd:3bcd:a0d2:9b6%14]) with mapi id 14.02.0328.009; Tue, 3 Nov 2015 21:05:37 +0200 From: Veaceslav ROMAN To: Ingemar Johansson S , Neal Cardwell Thread-Topic: [tcpm] [e2e] TCP HyStart patch deployment Thread-Index: AdCXp+zNDAZ7zydkTra0wALqZYyJLQH+JqqAA0qsYsAOCTWagAADKaaAABZGAgAAAuJsAABGVozQ///TRACAAB/3AIAAKj8AgAEIjoCAABVIgP//hZhA/9ZLHXD/q+ph8P9XvOWw/q9KtpD9XnrA8Pq87vsQ9XoBmgDq7PdWOtXZ4gsAq6EW+gDXJ/xTAK5Pg/vg Date: Tue, 3 Nov 2015 19:05:36 +0000 Message-ID: <7DBBB686E19D2049ADAACD210B474BB10167E8DC6E@XCHSRV01.main.orange.md> References: <81564C0D7D4D2A4B9A86C8C7404A13DA32145DE4@ESESSMB205.ericsson.se> <1FFD9A11-ADF2-4BA6-A9D3-D8997E1A13E5@gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34B2E666@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E64B65@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E65133@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E676EF@XCHSRV01.main.orange.md> <1441314842.8932.222.camel@edumazet-glaptop2.roam.corp.google.com> <1441385297.17208.6.camel@edumazet-glaptop2.roam.corp.google.com> <7DBBB686E19D2049ADAACD210B474BB10166E856CA@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD84BC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E859FB@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD86EC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E85C4E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD880B@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E8BDBA@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10167E64F3E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB08A1@ESESSMB205.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA34EB08A1@ESESSMB205.ericsson.se> Accept-Language: en-US, ro-RO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.107.165] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , Piers O'Hanlon , Sangtae Ha , Eric Dumazet , "end2end-interest@postel.org" Subject: Re: [tcpm] [e2e] TCP HyStart patch deployment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 03 Nov 2015 19:06:00 -0000 WW91IGFyZSByaWdodCwgaXQgd2Fzbid0IG1vZGlmaWVkIGFuZCBzdGF5ZWQgYXQgMTYuIFRoYW5r IHlvdSBmb3Igc3VnZ2VzdGlvbi4NCkN1cnJlbnRseSB3ZSBhcmUgdHJ5aW5nIHRvIG1ha2UgYW4g ZXhwZXJpbWVudGFsIHZlcnNpb24gd2VyZSB0aGlzIHdvdWxkIGJlIHBvc3NpYmxlIHRvIG1ha2Ug dGhlc2UgcGFyYW1ldGVycyBhbmQgZmV3IG90aGVyIHRoaW5ncyBleHRlcm5hbGx5IHNldHRhYmxl Lg0KDQpCdXQsIGhvbmVzdGx5LCB0aGUgZnVydGhlciB3ZSBkaWcgaW4gdGhlIGNvZGUgYW5kIHRy YWNlcyB0aGUgbW9yZSB0aGUgY29uZnVzaW9uIGFuZCBtb3JlIHF1ZXN0aW9ucyBhcmlzZXMuDQoJ SHlzdGFydCByZWx5IG9uIGNvcnJlY3QgaWRlbnRpZmljYXRpb24gb2Ygcm91bmQgYm9yZGVycy4g Rm9yIHRoaXMgaHlzdGFydF9yZXNldCBzZXRzIHRoZSBib3JkZXIgYXQgc25kX254dC4gDQpCdXQs IGlmIHNldmVyYWwgQUNLIGFycml2ZSBhdCBoaWdoIHNwZWVkIHdoZW4gdGhlIGN1cnJlbnQgcm91 bmQgYm9yZGVyIGlzIGNyb3NzZWQgYW5kIHRoZSBzZW5kZXIgaGFzIG5vdCB0aW1lIHRvIHRyYW5z bWl0IHR3byBwYWNrZXRzIGltbWVkaWF0ZWx5IGFmdGVyIEFDSywgdGhlbiB0aGUgc25kX254dCBk b2VzIG5vdCBwcm9ncmVzcyBhbmQgaHlzdGFydF9yZXNldCBzZXRzIHRoZSByb3VuZCBvZiB0aGUg Ym9yZGVyIHRvIGEgcHJldHR5IHJhbmRvbSB2YWx1ZSBhbmQgdGhlbiBpbiB0aGUgbmV4dCByb3Vu ZCB0aGUgaHlzdGFydCBtZWFzdXJlIHBpZWNlcyBvZiB0d28gcm91bmRzLg0KCUFsc28sIHRoZSBj b2RlIGlzIGNhbGxpbmcgaHlzdGFydF91cGRhdGUgb24gZWFjaCBBQ0sgYmVmb3JlIHRoZSBoeXN0 YXJ0X3Jlc2V0LCBhcyBhIHJlc3VsdCBhdCB0aGUgYm9yZGVyIG9mIHJvdW5kcyB0aGUgaGVhZCBv ZiBsaW5lIChIT0wpIEFDSyBkZWxheSBvZiByb3VuZCBOKzEgaXMgYWNjb3VudGVkIGluIHRoZSBy b3VuZCBOIGFuZCwgYmVjYXVzZSwgdGhlIEhPTCB1c3VhbGx5IGhhcyBsZXNzIGRlbGF5LCBpdCBp cyBmcmVxdWVudGx5IGJlY29tZSBkZWxheV9taW4gYnV0IG5vdCBpbiByb3VuZCBOKzEgYW5kLCBh cyBhIHJlc3VsdCBlYXJseSBleGl0IGluIHJvdW5kIE4rMSBhZnRlciBjb3VudGluZyBkZWxheXMg b2YgcGFja2V0cyAyIHRocm91Z2ggOS4gDQoJVGhpcyBzaG91bGQgYWxzbyBhZmZlY3QgdHJhaW4g ZGV0ZWN0IGFzLCB3aGVuIGNyb3NzaW5nIHRoZSByb3VuZCBib3JkZXIsIGluc3RlYWQgb2Ygc3Vi dHJhY3RpbmcgdGhlIHRpbWUgb2YgdGhlIGZpcnN0IGFuZCB0aGUgbGFzdCBBQ0sgb2YgdGhlIHRy YWluIE4gdGhlcmUgd2lsbCBiZSBzdWJ0cmFjdGVkIHRpbWVzIG9mIGZpcnN0IEFDSyBvZiB0cmFp biBOIGFuZCBmaXJzdCBBQ0sgb2YgdGhlIHRyYWluIE4rMSB3aGljaCB3aWxsIGJlIGFwcHJveGlt YXRlbHkgZXF1YWwgdG8gUlRUIGFuZCBkZWZpbml0ZWx5IGJpZ2dlciB0aGFuIFJUVC8yIGFzIHBl ciBleHBlY3RlZCBhbGdvcml0aG0uIFRoaXMgc2hhbGwgdHlwaWNhbGx5IGxlYWQgdG8gYWx3YXlz IGV4aXQgaW4gdHJhaW4gMi4gVGhpcyB3aWxsIGFmZmVjdCBoaWdoIHNwZWVkIG5ldHdvcmtzIHdp dGggUlRUIGxlc3MgdGhhbiBoeXN0YXJ0X2Fja19kZWx0YSAoMm1zKS4NCiAgICAgICAgICAgICBU aGVuIGNhbGwgb2YgaHlzdGFydF9yZXNldCBpcyBzdWJqZWN0IG9mIGNoZWNrIG9mIHNldmVyYWwg Y29uZGl0aW9ucyBsaWtlIG1heV9yaXNlX2N3bmQgb3IgaXNfY3duZF9saW1pdGVkLCB3aGlsZSBp dCBkb2Vzbid0IGxvb2sgdGhhdCBoeXN0YXJ0X3VwZGF0ZSBpcywgc28gdGhhdCBpdCBtYXkgYmVj b21lIHRvdGFsbHkgb3V0IG9mIHN5bmMgd2l0aCByb3VuZCBib3JkZXIuDQogDQoJV2UgYXJlIHN0 aWxsIGRvaW5nIGVmZm9ydHMgdG8gdHJ5IHRvIGZpbmQgcGFyYW1ldGVycyB3aGljaCB3b3VsZCBt YWtlIGh5c3RhcnQgYmV0dGVyLCBidXQgYW5hbHlzaXMgb2YgbWFueSB0cmFjZXMgbWFrZSBtdWNo IGltcHJlc3Npb24gb2YgcmFuZG9tbmVzcyBvZiBleGl0IGFuZCBub3Qgc3VyZSB3aGV0aGVyIHBh cmFtZXRlcnMgbWF5IGhlbHAuIA0KDQpWZWFjZXNsYXYgUm9tYW4NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEluZ2VtYXIgSm9oYW5zc29uIFMgW21haWx0bzppbmdlbWFyLnMu am9oYW5zc29uQGVyaWNzc29uLmNvbV0gDQpTZW50OiBUdWVzZGF5LCAwMyBOb3ZlbWJlciAyMDE1 IDE1OjE5DQpUbzogVmVhY2VzbGF2IFJPTUFOOyBOZWFsIENhcmR3ZWxsDQpDYzogRXJpYyBEdW1h emV0OyBFcmljIER1bWF6ZXQ7IHRjcG1AaWV0Zi5vcmc7IFBpZXJzIE8nSGFubG9uOyBTYW5ndGFl IEhhOyBlbmQyZW5kLWludGVyZXN0QHBvc3RlbC5vcmc7IEluZ2VtYXIgSm9oYW5zc29uIFMNClN1 YmplY3Q6IFJFOiBbdGNwbV0gW2UyZV0gVENQIEh5U3RhcnQgcGF0Y2ggZGVwbG95bWVudA0KDQpI aQ0KDQpUaGFua3MgZm9yIGRvaW5nIHRoZSBleHBlcmltZW50cy4gDQpJdCBtYXkgYmUgcG9zc2li bGUgdGhhdCBIeVN0YXJ0IG1heSBuZWVkIG1vcmUgZXh0ZW5zaXZlIG1vZGlmaWNhdGlvbnMuIA0K TmVlZCB0byBhc2sgdGhlIGR1bWIgcXVlc3Rpb24gZmlyc3QgdGhvdWdoLiBJcyBIWVNUQVJUX0RF TEFZX01BWCBtb2RpZmllZCBpbiB5b3VyIGV4cGVyaW1lbnQgb3IgaXMgaXQgc3RpbGwgMTZtcyA/ DQpJIGd1ZXNzIEhZU1RBUlRfREVMQVlfTUFYIG1heSBuZWVkIHRvIGJlIHNldCB0byANCiAgICBI WVNUQVJUX0RFTEFZX01BWCA9IE1BWCgxNm1zLCBIWVNUQVJUX0RFTEFZX01JTioyKSBPciBzb21l dGhpbmcgc2ltaWxhciwgb25lIGNhbiBhbHdheXMgYXJndWUgYXJvdW5kIHRoZSBmYWN0b3IgMiBh Ym92ZS4NCg0KL0luZ2VtYXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBWZWFjZXNsYXYgUk9NQU4gW21haWx0bzpWZWFjZXNsYXYuUm9tYW5Ab3JhbmdlLm1kXQ0KPiBT ZW50OiBkZW4gMTcgb2t0b2JlciAyMDE1IDIyOjQ4DQo+IFRvOiBOZWFsIENhcmR3ZWxsDQo+IENj OiBFcmljIER1bWF6ZXQ7IEluZ2VtYXIgSm9oYW5zc29uIFM7IEVyaWMgRHVtYXpldDsgdGNwbUBp ZXRmLm9yZzsgDQo+IFBpZXJzIE8nSGFubG9uOyBTYW5ndGFlIEhhOyBlbmQyZW5kLWludGVyZXN0 QHBvc3RlbC5vcmcNCj4gU3ViamVjdDogUkU6IFt0Y3BtXSBbZTJlXSBUQ1AgSHlTdGFydCBwYXRj aCBkZXBsb3ltZW50DQo+IA0KPiBIaSwNCj4gUmVjb21waWxlZCBrZXJuZWwgdG8gSFlTVEFSVF9E RUxBWV9NSU4gIDIwIG1zOg0KPiANCj4gICBEb3dubG9hZCAxME1CLCBIaWdoIEJhbmR3aWR0aHMs IEhZU1RBUlRfREVMQVlfTUlOICAyMCBtczoNCj4gICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2Ug ZG93bmxvYWQgdGltZTogMS4xOCBzDQo+ICAgICAgICAgICAgTm9IeXN0YXJ0IGF2ZXJhZ2UgZG93 bmxvYWQgdGltZTogMS4wMCAgcw0KPiANCj4gTm8gc2lnbmlmaWNhbnQgaW1wcm92ZW1lbnQgYWdh aW5zdCB0aGUgY2FzZSB3aXRoIEhZU1RBUlRfREVMQVlfTUlOICAxMCANCj4gbXMuDQo+IA0KPiBT aWxsIEh5c3RhcnQgZWFybHkgZXhpdCBpcyB2aXNpYmxlLg0KPiANCj4gT3RoZXIgdGVzdHMgd2l0 aCBIWVNUQVJUX0RFTEFZX01JTiAgMjAgbXMgYW5kIGZpbGVzIG9mIDNNQi4NCj4gDQo+ICAgRG93 bmxvYWQgM01CLCBIaWdoIEJhbmR3aWR0aHMsIEhZU1RBUlRfREVMQVlfTUlOICAyMCBtczoNCj4g ICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2UgZG93bmxvYWQgdGltZTogMC40NyBzDQo+ICAgICAg ICAgICAgTm9IeXN0YXJ0IGF2ZXJhZ2UgZG93bmxvYWQgdGltZTogMC4zOSAgcw0KPiANCj4gY29t cGFyZSB3aXRoIDQgbXMNCj4gDQo+ICAgRG93bmxvYWQgM01CLCBIaWdoIEJhbmR3aWR0aHMsIEhZ U1RBUlRfREVMQVlfTUlOICA0IG1zOg0KPiAgICAgICAgICAgIEh5c3RhcnQgYXZlcmFnZSBkb3du bG9hZCB0aW1lOiAwLjY1IHMNCj4gICAgICAgICAgICBOb0h5c3RhcnQgYXZlcmFnZSBkb3dubG9h ZCB0aW1lOiAwLjM3ICBzDQo+IA0KPiBGZXcgbW9yZSBjb21tZW50OiBIaWdoIEJhbmR3aWR0aCBp cyB0eXBpY2FsbHkgYWJvdmUgMzAtNDAgTWJwcy4NCj4gRm9yIExvdyBCYW5kd2lkdGgsIHdoZW4g cmFkaW8gZG8gbm90IHBlcm1pdCBhYm92ZSA0MCBNYnBzIEh5c3RhcnQgDQo+IGVhcmx5IGV4aXQg ZG9lcyBub3QgaGF2ZSBhIHNpZ25pZmljYW50IGltcGFjdC4gSSBkbyBleHBsYWluIGl0IHdpdGgg DQo+IHRoZSBmYWN0IHRoYXQgdGhlIG1pbmltdW0gZXhpdCBDV05EIGZvciBIeXNzdGFydCBpcyAy OSB3aGljaCwgZm9yIFJUVCANCj4gb2YgfjE1bXMgKG1pbmltdW0gcG9zc2libGUgaW4gTFRFIGFu ZCB2aXNpYmxlIGluIG1ham9yaXR5IG9mIHRyYWNlcykgDQo+IGxlYWRzIHRvIH4yNSBNYnBzLCBz byBIeXN0YXJ0IGV4aXQsIGF0IGxlYXN0LCBhdCAyNSBNYnBzIGFuZCB0aGVuIGl0IA0KPiB0YWtl cyBub3QgdG9vIGxvbmcgdG8gY3ViaWMgdG8gcmVhY2ggMzAtNDAgTWJwcy4NCj4gDQo+IFZlYWNl c2xhdiBSb21hbg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmVh bCBDYXJkd2VsbCBbbWFpbHRvOm5jYXJkd2VsbEBnb29nbGUuY29tXQ0KPiBTZW50OiBUdWVzZGF5 LCAwNiBPY3RvYmVyIDIwMTUgMDQ6MDYNCj4gVG86IFZlYWNlc2xhdiBST01BTg0KPiBDYzogRXJp YyBEdW1hemV0OyBJbmdlbWFyIEpvaGFuc3NvbiBTOyBFcmljIER1bWF6ZXQ7IHRjcG1AaWV0Zi5v cmc7IA0KPiBQaWVycyBPJ0hhbmxvbjsgU2FuZ3RhZSBIYTsgZW5kMmVuZC1pbnRlcmVzdEBwb3N0 ZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbdGNwbV0gW2UyZV0gVENQIEh5U3RhcnQgcGF0Y2ggZGVw bG95bWVudA0KPiANCj4gT24gTW9uLCBPY3QgNSwgMjAxNSBhdCA2OjA3IFBNLCBWZWFjZXNsYXYg Uk9NQU4gDQo+IDxWZWFjZXNsYXYuUm9tYW5Ab3JhbmdlLm1kPiB3cm90ZToNCj4gPiBXZSd2ZSBt YW5hZ2VkIHRvIHJlY29tcGlsZSB0aGUga2VybmVsIDQuMSB3aXRoIHRjcF9jdWJpYw0KPiBIWVNU QVJUX0RFTEFZX01JTiAgKDEwVTw8MykgLCAxMG1zLg0KPiA+IFdlbGwsIHdlIGhhZCB0aW1lIG9u bHkgZm9yIG9uZSB0ZXN0IGN5Y2xlLCBidXQgcmVzdWx0cyBhcmUgdmVyeSBwcm9taXNpbmc6DQo+ ID4NCj4gPiBEb3dubG9hZCAxME1CLCBIaWdoIEJhbmR3aWR0aHMsIEhZU1RBUlRfREVMQVlfTUlO ICAxMCBtczoNCj4gPiAgICAgICAgICAgIEh5c3RhcnQgYXZlcmFnZSBkb3dubG9hZCB0aW1lOiAx LjE2IHMNCj4gPiAgICAgICAgICAgIE5vSHlzdGFydCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6IDAu OTMgIHMNCj4gLi4uDQo+ID4gIERvd25sb2FkIDEwTUIsIEhpZ2ggQmFuZHdpZHRocywgSFlTVEFS VF9ERUxBWV9NSU4gIDQgbXM6DQo+ID4gICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2UgZG93bmxv YWQgdGltZTogMS40MiBzDQo+ID4gICAgICAgICAgICBOb0h5c3RhcnQgYXZlcmFnZSBkb3dubG9h ZCB0aW1lOiAwLjg5ICBzDQo+IA0KPiBUaGFua3MhIFRoYXQgaXMgdmVyeSB1c2VmdWwgYW5kIGlu dGVyZXN0aW5nIGRhdGEuIFdvdWxkIHlvdSBiZSBhYmxlIHRvIA0KPiB0cnkgYSBmZXcgb3RoZXIg dmFsdWVzLCBsaWtlIDE1bXMgYW5kIDIwbXM/DQo+IA0KPiBuZWFsDQo= From nobody Wed Nov 4 05:28:05 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7941B2F47; Wed, 4 Nov 2015 05:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaysQiuASLAY; Wed, 4 Nov 2015 05:27:57 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1BF71B2F3E; Wed, 4 Nov 2015 05:27:55 -0800 (PST) X-AuditID: c1b4fb2d-f79626d000004282-ea-563a07d8e5d4 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 15.6F.17026.8D70A365; Wed, 4 Nov 2015 14:27:53 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.152]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Wed, 4 Nov 2015 14:27:52 +0100 From: Ingemar Johansson S To: Bob Briscoe , "iccrg@irtf.org" , "tcpm@ietf.org" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt Thread-Index: AQHRBqyIURyzaqIT1UWeXHewI01EFJ5rS8UAgBd7pYCACSDxgA== Date: Wed, 4 Nov 2015 13:27:51 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658@ESESSMB205.ericsson.se> References: <20151014181702.10618.83714.idtracker@ietfa.amsl.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34BF4F0F@ESESSMB205.ericsson.se> <56325D2D.1070107@bobbriscoe.net> In-Reply-To: <56325D2D.1070107@bobbriscoe.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658ESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUyM+Jvre5Ndqswg6N/mC0OLNjJbnH04QJW i20n5zNZHHtzl82BxePV/QusHkuW/GTymLzxMFsAcxSXTUpqTmZZapG+XQJXxrX+eewF7x4y VzRuvsncwLjmKnMXIweHhICJxLRt9V2MnECmmMSFe+vZuhi5OIQEjjBKzGu+zgjhLGaUuHnh FjNIFZuAjcTKQ9/BEiICfYwSE6c+YQRJMAtYSXw5/hesSFggWuL71s1sILaIQIxE380zLBC2 k8T2uQ/B6lkEVCTaTz9jBbF5BXwljl/pZILYtpJRYsrsB0wgCU4BPYnej31gDYwCshL3v99j gVgmLnHryXwmiLsFJJbsOc8MYYtKvHz8jxXCVpRof9oAdVy+xKKeKywQywQlTs58wjKBUXQW klGzkJTNQlI2CxhKzAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFxbrqRsV5q UWZycXF+nl5easkmRmBMHtzyW3cH4+rXjocYBTgYlXh4DVgsw4RYE8uKK3MPMUpwMCuJ8Jqe AgrxpiRWVqUW5ccXleakFh9ilOZgURLnbWF6ECokkJ5YkpqdmlqQWgSTZeLglGpgXH+mpf+i RrQ/u2VFPD+/wSsb2wcL9ogxWU2omzTvZ6zg8bMBvns/mqes6vrOt/xtuyXX+r0dqz9F1Ktd z5LY3Hygqar6/583f3SDlxWsbvSfLRqw9X/p65x9r8PcxPcz72KoaZm2xVHw+VIb/ngLgXv6 PceNHvv+emPM3L+8/dryV6fuXJ25WomlOCPRUIu5qDgRAAOoaHHFAgAA Archived-At: Cc: Ingemar Johansson S Subject: Re: [tcpm] [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Nov 2015 13:28:02 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658ESESSMB205erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KQW5kIHRoYW5rcyBmb3IgdGhlIHJldmlldywgY29tbWVudHMvYW5zd2Vycy9xdWVzdGlv bnMgaW5saW5lIGJlbG93DQoNCi9JbmdlbWFyDQoNCkZyb206IEJvYiBCcmlzY29lIFttYWlsdG86 aWV0ZkBib2JicmlzY29lLm5ldF0NClNlbnQ6IGRlbiAyOSBva3RvYmVyIDIwMTUgMTg6NTQNClRv OiBJbmdlbWFyIEpvaGFuc3NvbiBTOyBpY2NyZ0BpcnRmLm9yZzsgdGNwbUBpZXRmLm9yZzsgdHN2 d2dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdHN2d2ddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWpvaGFuc3Nvbi1jYy1mb3ItNGctNWctMDAudHh0DQoNCkluZ2VtYXIs DQoNCkFzIHByb21pc2VkLCBoZXJlJ3MgbXkgY29tbWVudHMuIFRoZXkgYXJlIGEgbWl4IG9mIHN1 Z2dlc3RlZCBpbXByb3ZlbWVudHMgdG8gdGhlIGRyYWZ0LCBzdWdnZXN0ZWQgaW1wcm92ZW1lbnRz IHRvIDVHLCBvciByZXF1ZXN0cyBmb3IgY2xhcmlmaWNhdGlvbi4gSSBhbHNvIGFncmVlIHdpdGgg YWxsIEtldmluIFNtaXRoJ3MgY29tbWVudHMsIHNvIEkgZGlkbid0IHJlcGVhdCBhbnkuDQpbU29y cnkgZm9yIGRlbGF5IC0gSSBoYWQgdG8gZmluZCB0aW1lIHRvIHJlLXR5cGUgYWZ0ZXIgbG9zaW5n IG15IHJldmlldyBkdXJpbmcgYSBwb3dlciBvdXRhZ2VdDQoNCkNvbnRleHQgcXVlc3Rpb25zLg0K UTEuIElzIHRoaXMgZXhlcmNpc2UgdHJlYXRpbmcgdGhlIDVHIHNwZWNzIHNvbGVseSBpbiByZWFk LW9ubHkgbW9kZT8gT3IsIGlmIHNvbWUgdXNlZnVsIGRlc2lnbiBzdWdnZXN0aW9ucyBhcmlzZSwg aXMgdGhlcmUgYW55IGNoYW5jZSB0aGF0IHRoZSAzR1BQIG1pZ2h0IHRha2UgdGhlbSBvbiBib2Fy ZCwgZ2l2ZW4gNUcgaXMgbm90IGZ1bGx5IGJha2VkIHlldD8NCltJSl0gR3Vlc3MgaXQgZGVwZW5k cywgbmVlZCB0byBzYXkgdGhhdCBJIHByb2JhYmx5IHRoZSBzbWFsbCBjb2cgaW4gdGhlIHdoZWVs LiBJIHdvdWxkIHNheSB0aGF0IGEgbG90IG9mIHRoZSBzdGFuZGFyZHMgd29yayBpbiBJRVRGIGhh cyBiZWVuIHBpY2tlZCB1cCBieSAzR1BQIGFuZCwgSSBjYW5ub3Qgc2F5IHdoYXQgd2lsbCBoYXBw ZW4gaW4gdGhlIDVHIGNvbnRleHQuDQoNCkl0J3MgZ3JlYXQgdGhhdCB5b3UgaGF2ZSB0YWtlbiB0 aGlzIGluaXRpYXRpdmUuIERvZXMgdGhlIDNHUFAgZXZlciBmb3JtYWxseSBhc2sgdGhlIElFVEYg Zm9yIGNvbW1lbnRzIG9uIGl0cyBpZGVhcyBmb3IgZWFjaCBuZXcgZ2VuZXJhdGlvbiBvZiByYWRp bz8gR2l2ZW4gdGhlIGxheWVycyBhYm92ZSBjYW4gYmUgdGhvdWdodCBvZiBhcyB0aGUgJ2N1c3Rv bWVycycgb2YgdGhlIDNHUFAsIGFuZCB0aGVzZSAnY3VzdG9tZXInIGxheWVycyBhcmUgcHJldHR5 IG11Y2ggYWxsIG1haW50YWluZWQgYnkgdGhlIElFVEYsIGl0IHdvdWxkIHNlZW0gZXNzZW50aWFs IChhbmQgY291cnRlb3VzKSBmb3IgdGhlIDNHUFAgdG8gYXNrIGZvciBjdXN0b21lciBjb21tZW50 LCBub3QgbGVhc3QgdG8gY28tb3JkaW5hdGUgd2l0aCB3aGF0ZXZlciBmdXR1cmUgcGxhbnMgdGhl IElFVEYgbWlnaHQgaGF2ZSBmb3IgdGhlIGhpZ2hlciBsYXllcnMuDQpbSUpdIFdoYXQgeW91IHNh eSBtYWtlcyBtdWNoIHNlbnNlLiBJIGd1ZXNzIHRoZXJlIGlzIHNvbWUgbmF0dXJhbCBsZWFrYWdl IGJldHdlZW4gM0dQUCBhbmQgSUVURiBhcyBtYW55IG9mIHRoZSBJRVRGZXJzIGFyZSBhbHNvIGFj dGl2ZSBpbiAzR1BQIHN0YW5kYXJkaXphdGlvbi4gSSBkb27igJl0IGhhdmUgZnVsbCBpbnNpZ2h0 IGluIHRoZSBmb3JtYWwgcmVsYXRpb24gYmV0d2VlbiAzR1BQIGFuZCBJRVRGIGluIHRoZXNlIGFy ZWFzLCBub3Qgc3VyZSBpZiB0aGF0IG5lZWQgdG8gYmUgYmV0dGVyLCBidXQgaWYgdGhhdCBpcyB0 aGUgY2FzZSwgdGhlbiBpdCBpcyBwcm9iYWJseSBhIHF1ZXN0aW9uIGZvciB0aGUgYXJlYSBkaXJl Y3RvcnMuIE5lZWQgdG8gc2F5IHRoYXQgZXZlbiB0aG91Z2ggdGhlIGZvcm1hbCBjaGFubmVscyBh cmUgc2NhcmNlIGl0IGRvZXMgcHJvYmFibHkgbm90IG1lYW4gdGhhdCAzR1BQIGlnbm9yZXMgSUVU RiBvciB3aGF0IGhhcHBlbnMgYWJvdmUgSVAgaW4gZ2VuZXJhbC4gRm9yIGluc3RhbmNlIHRoZSBy ZWNlbnQgd29yayBhcm91bmQgVENQIFJBQ0sgcmFpc2VzIHRoZSBxdWVzdGlvbiBpZiBpdCBpcyBu ZWNlc3NhcnkgdGhhdCBMVEUgZGVmYXVsdCByYWRpbyBiZWFyZXJzIGVuc3VyZSBpbiBvcmRlciBk ZWxpdmVyeS4NCg0KDQpRMi4gV2hhdCBhcmUgeW91ciBwbGFucyBmb3IgdGhpcyBkcmFmdD8gQXJl IHlvdSBhc2tpbmcgZm9yIGFkb3B0aW9uPyBBbmQgaWYgc28sIGluIHdoaWNoIFdHIG9yIFJHPyBJ Q0NSRyBsb29rcyB0aGUgbW9zdCBhcHByb3ByaWF0ZSwgZ2l2ZW4gdGhlIGNoYXJ0ZXJzIG9mIGFs bCB0aGUgSUVURiBjYyBXR3MgKFRTVldHLCBUQ1BNLCBSTUNBVCwgZXRjKSBhcmUgc2NvcGVkIG9u IGp1c3QgYSBzdWJzZXQgb2YgeW91ciBkb2MuDQpbSUpdIEZpcnN0IG9iamVjdGl2ZSBpcyB0byBn ZXQgYW4gaW5jcmVhc2VkIGludGVyZXN0IGluIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG0g d29yayBpbiB0aGUgSUVURi4gVHJhZGl0aW9uYWxseSB0aGlzIGtpbmQgb2Ygd29yayBzZWVtIHRv IGJlIG1vcmUgaW4gdGhlIHRlcm1zIG9mIGNvbmZlcmVuY2UgcGFwZXJzIGluIGUuZy4gU2lnY29t bSwgdGhlIGJlbmVmaXQgd2l0aCBoYXZpbmcgc3VjaCB3b3JrIGluIElFVEYgaXMgdGhhdCBpbnB1 dCBmcm9tIHBlb3BsZSB3aXRoIGEgd2lkZXIgZXhwZXJ0aXNlIGFyZWEgKGluY2x1ZGluZyAzR1BQ IGV4cGVyaXRpc2UpIGNhbiBnaXZlIGFsZ29yaXRobSBwcm9wb3NhbHMgdGhhdCB3b3JrIHdlbGwg Zm9yIGEgd2lkZXIgc2V0IG9mIGFjY2VzcyB0eXBlcy4gVGhlIHdvcmsgYXJvdW5kIEN1YmljIGlz IGEgZmlyc3QgZ29vZCBzdGVwIGFzIGlzIHRoZSB3b3JrIGFyb3VuZCBEQ1RDUC4gV2hhdCBJIHdv bmRlciBpcyBpZiBpdCBmZWFzaWJsZSB0byB0YWtlIHRoaXMgYSBiaXQgZnVydGhlciA/IEkgd291 bGQgdG9vIGJlbGlldmUgdGhhdCB0aGUgY3VycmVudCBkb2MgZml0cyBiZXR0ZXIgaW4gSUNDUkcu ICBUaGUgYWxnb3JpdGhtIGV4YW1wbGVzIGFyZSBqdXN0Li4gZXhhbXBsZXMuIE1vcmUgZnJ1aXRm dWwgd29yayBpcyBwcm9iYWJseSB0byBkb2N1bWVudCBkaWZmZXJlbnQgYWNjZXNzIHR5cGVzIGFu ZCBmcm9tIHRoZXJlIGRlcml2ZSBhIHNldCBvZiBiZXN0IGN1cnJlbnQgcHJhY3RpY2VzIGZvciBj b25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtcw0KDQoNClNlY3Rpb24gYnkgU2VjdGlvbiBSZXZp ZXcNCg0KQWxsIHNlY3Rpb25zDQoNClRoZSBkb2N1bWVudCBnZW5lcmFsbHkgdGFsa3MgYWJvdXQg dGhlIExURSBwcm90b2NvbCBzdGFjayBhcyBpZiBkYXRhIGlzIHRyYXZlbGxpbmcgZG93biBpdC4g QXJlIHlvdSBpbXBseWluZyB0aGF0IG1vc3Qgc291cmNlcyBvZiBidWZmZXJpbmcgZGVsYXkgYXJl IGF0IHRoZSBzZW5kaW5nIGVuZCwgYW5kIHRoZSBmZWVkYmFjayBlbmQgaXMgcHJldHR5IHVuZW5j dW1iZXJlZCBieSBkZWxheXM/IEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGV4cGxpY2l0 bHkgc2F5IHNvbWV0aGluZyBhYm91dCB0aGlzICh3aGV0aGVyIHRydWUgb3Igbm90KSwgdG8gZXhw bGFpbiB3aHkgb25seSBvbmUgZGlyZWN0aW9uIG9mIHRyYXZlbCBpcyBkaXNjdXNzZWQgaW4gdGhl IGRvYy4NCltJSl0gVGhlIGZlZWRiYWNrIHBhdGggaXMgZW5jdW1iZXJlZCBieSBkZWxheXMsIGl0 IGlzIHBlcmhhcHMgbm90IHRoYXQgY2xlYXIgYnV0IHNlY3Rpb24gMi4zLjIgaW1wbGllcyB0aGF0 IGRlbGF5ICh2YXJpYXRpb24pIGluIHVwbGluayB3aWxsIGFmZmVjdCB0aGUgQUNLcyBmb3IgZG93 bmxpbmsgZGF0YSB0cmFmZmljLiBUaGF0IHNhaWQsIHRoZSBkaWZmZXJlbmNlIGluIERML1VMIHRy YWZmaWMgaXMgdG9kYXkgc29tZXRoaW5nIGxpa2UgMTA6MSBhbmQgdGhhdCBpcyBwcm9iYWJseSBv bmUgcmVhc29uIHdoeSBvbmUgY2FuIGdldCB0aGUgZmVlbGluZyB0aGF0IHRoZSBkcmFmdCBpcyBz bGFudGVkIHRvd2FyZHMgZG93bmxpbmsgZGF0YSB0cmFmZmljLCB0aGlzIG1heSBob3dldmVyIGNo YW5nZSB3aXRoIHRpbWUgYXMgbW9yZSBtYWNoaW5lIHR5cGUgdHJhZmZpYyBtYXkgZW50ZXIgdGhl IHN5c3RlbS4NCg0KDQoyLjEgUERDUCBsYXllcg0KDQogICAgUERDUCBhbHNvIGVuc3VyZXMgdGhh dCBhbGwNCiAgIHBhY2tldHMgYXJlIGRlbGl2ZXJlZCBpbiBvcmRlciB1cCB0byBoaWdoZXIgbGF5 ZXJzLg0KSSB0aGluayB0aGlzIG1lYW5zICJpbiB0aGUgb3JkZXIgc2VudCBpbnRvIHRoZSBsaW5r IChQRENQKSBsYXllciIuIFRoaXMgb3VnaHQgdG8gYmUgY2xhcmlmaWVkLCBvdGhlcndpc2UsIHdo ZW4gd3JpdGluZyBpbiB0aGUgY29udGV4dCBvZiBhIGxheWVyIDQgYXVkaWVuY2UsIGl0IG1pZ2h0 IGJlIGFzc3VtZWQgdGhpcyBtZWFucyBpbiB0aGUgb3JkZXIgc2VudCBieSB0aGUgb3JpZ2luYWwg dHJhbnNwb3J0IGxheWVyIHNvdXJjZS4NCltJSl0gWWVzLCB5b3UgYXJlIHJpZ2h0ICwgcmVvcmRl cmluZyBjYW4gc3RpbGwgb2NjdXIgZS5nLiBpbiB0aGUgd2lyZWxlc3MgYmFja2hhdWwNCg0KDQog ICBrZWVwIHRoZSBhbW91bnQgb2YgZGF0YSBpbiBmbGlnaHQgYXMgc21hbGwgYXMgcG9zc2libGUs IHdpdGhvdXQgc2FjcmlmaWNpbmcgdGhyb3VnaHB1dC4NCklzIHRoaXMganVzdCBhIHJhdGhlciBj b252b2x1dGVkIHdheSBvZiBzYXlpbmcgImtlZXAgdGhlIFJUVCBhcyBsb3cgYXMgcG9zc2libGUi PyAod2hpY2ggaW4gdHVybiBpbXBsaWVzIGtlZXBpbmcgcXVldWluZyBkZWxheSBhcyBsb3cgYXMg cG9zc2libGUgYXNzdW1pbmcgeW91IGNhbm5vdCBpbmZsdWVuY2UgdGhlIHBoeXNpY2FsIHBhdGgu KSBPciB3ZXJlIHlvdSB0cnlpbmcgdG8gbWFrZSBhIG1vcmUgc3VidGxlIHBvaW50PyAtIGlmIHNv LCBpdCB3YXMgbG9zdCBvbiBtZS4NCltJSl0gTm8sIGl0IGlzIGV4YWN0bHkgYXMgeW91IGRlc2Ny aWJlIGJlbG93DQoNCg0KICAgUmVsaWFibGUgZGVsaXZlcnkgYXQgaGFuZG92ZXIgbWF5IGhvd2V2 ZXIgYmUgdHVybmVkIG9mZiBvciBpcyBzaW1wbHkgbm90IGltcGxlbWVudGVkLA0KSXQgd291bGQg YmUgdXNlZnVsIGlmIHlvdSBjb3VsZCBnaXZlIGEgZmVlbCBmb3Igcm91Z2hseSBob3cgb2Z0ZW4g KGluICUpIHRoZXNlIGNhc2VzIGhvbGQuDQpbSUpdIEkgZG9u4oCZdCBiZWxpZXZlIHRoYXQgaXQg aXMgcG9zc2libGUgdG8gZ2l2ZSBhIGZpZ3VyZSBhcyB0aGlzIGlzIHZlbmRvciBzcGVjaWZpYy4N Cg0KDQoyLjIgUkxDIGxheWVyDQoNCiAgIHJvbGUgLi4uIGlzIHRvIGVuc3VyZSB0aGF0IHBhY2tl dHMgYXJlIGRlbGl2ZXJlZCBpbiBvcmRlciB1cCB0byB0aGUgaGlnaGVyIGxheWVycw0KRWg/IFRo ZSBQRENQIHNlY3Rpb24ganVzdCBzYWlkIGl0IGRpZCBvcmRlcmluZy4gQW5kIHRoZSByZXN0IG9m IHRoZSBSTEMgc2VjdGlvbiB0YWxrcyBleGNsdXNpdmVseSBhYm91dCBidWZmZXJpbmcgZGVsYXlz IG5lY2Vzc2FyeSB3aGlsZSBmaWxsaW5nIHRyYW5zcG9ydCBibG9ja3MuIElmIG9yZGVyaW5nIGlz IHRoZSByb2xlIG9mIGJvdGggbGF5ZXJzLCBzdXJlbHkgb25lIHdpbGwgaGF2ZSBub3RoaW5nIHRv IGRvIG9uY2UgdGhlIG90aGVyIGhhcyBnb3QgZXZlcnl0aGluZyBpbiBvcmRlcj8NCltJSl0gUkxD IGhhbmRsZXMgb3JkZXJpbmcgZHVlIHRvIHZhcmlvdXMgTUFDIGxheWVyIGZhaWx1cmVzLiBQRENQ IGhhbmRsZXMgb3JkZXJpbmcgIHdoZW4gaGFuZG92ZXIgb2NjdXJzDQoNCg0KICAgdmFyeWluZyBz aXplIG9mIHRoZSBhdmFpbGFibGUgdHJhbnNwb3J0DQpOaXQ6IEdpdmVuICd0cmFuc3BvcnQnIG1l YW5zIGUyZSBmb3IgdGhlIGF1ZGllbmNlIG9mIHRoaXMgZHJhZnQsIHBscyB1c2UgYmVhcmVyIG9y IHNvbWVob3cgZGlzYW1iaWd1YXRlIHRoaXMgd29yZC4NCltJSl0gT0sNCg0KDQoNCkdhcCMxOiBJ biB0aGUgZHJhZnQsIGl0IHNlZW1zIGxpa2UgdHJhbnNwb3J0IGJsb2NrcyBhcnJpdmUgYnkgbWFn aWMsIHRvIGJlIGZpbGxlZCBieSBkYXRhIGJ1ZmZlcmVkIGluIHRoZSBSTEMgbGF5ZXIuIFRvIHVu ZGVyc3RhbmQgdGhlIGRlbGF5IGNvbXByb21pc2VzIGhlcmUsIEkgdGhpbmsgdGhlIGRyYWZ0IG5l ZWRzIHRvIGV4cGxhaW4gd2hhdCBkZXRlcm1pbmVzIGhvdyBtdWNoIHRyYW5zcG9ydCBibG9jayBj YXBhY2l0eSBlYWNoIGZsb3cgaXMgZ2l2ZW4sIGFuZCBob3cgdGhleSBjYW4gaW5mbHVlbmNlIGl0 LiBJbiAzRywgSSBiZWxpZXZlIHRoYXQgdGhlIHRyYW5zcG9ydCBsYXllciBjb3VsZCBhc2sgdGhl IHJhZGlvIHJlc291cmNlIGNvbnRyb2xsZXIgdG8gY2hhbmdlIHJhZGlvIHJlc291cmNlIGFsbG9j YXRpb24uIElzIHRoaXMgdGhlIHNhbWUgaW4gNEcgJiA1Rz8gRG9lcyB0aGUgYmFja2xvZyBvZiB0 aGUgYnVmZmVyIGludG8gdGhlIFJMQyBsYXllciBoYXZlIGFueSBhdXRvbWF0aWMgaW5mbHVlbmNl IG92ZXIgYWxsb2NhdGlvbiBvZiBhdmFpbGFibGUgcmVzb3VyY2VzPyBJIGFzc3VtZSB0cmFmZmlj IGNsYXNzIGNhbiBhbHNvIGJlIHVzZWQgdG8gaW5mbHVlbmNlIGFsbG9jYXRpb24uDQpbSUpdIFdp bGwgdXBkYXRlZCB3aXRoIG1vcmUgZGV0YWlsDQoNCg0KR2FwIzI6IEluIGEgM0cgc3RhY2ssIHRo ZSBSTEMgbGF5ZXIgbXVsdGlwbGV4ZXMgYWxsIHRoZSBhY3RpdmUgYXBwbGljYXRpb24gc3RyZWFt cyBpbnRvIE1BQyBsYXllciB0cmFuc3BvcnQgYmxvY2sgYnkgZGljaW5nIHVwIGJ1ZmZlcmVkIHBh Y2tldHMgYW5kIHBhY2tpbmcgdGhlIHBpZWNlcyBpbnRvIGVhY2ggdHJhbnNwb3J0IGJsb2NrLiBU aGVuLCBhdCB0aGUgb3RoZXIgZW5kIG9mIHRoZSBsaW5rLCBlYWNoIHBpZWNlIGhhcyB0byBiZSBo ZWxkIHVudGlsIHRoZSByZXN0IG9mIHRoZSBwYWNrZXQgYXJyaXZlcy4gVGhpcyBzYWNyaWZpY2Vz IGRlbGF5IGZvciBiYW5kd2lkdGggZWZmaWNpZW5jeS4gSXMgdGhpcyBzdGlsbCBkb25lIGluIDRH IGFuZCA1Rz8gSWYgc28sIGl0IHdvdWxkIGJlIGdvb2QgdG8gd3JpdGUgYWJvdXQgbXV4IGRlbGF5 IGluIHRoZSBkcmFmdCB0b28uDQpbSUpdIE9LLCB3aWxsIGFkZCBtb3JlIGluZm8NCg0KDQoyLjMg TUFDIGxheWVyDQoNCiAgIHRoZSBtYXhpbXVtIG51bWJlciBvZiByZXRyYW5zbWlzc2lvbnMgaXMg Y29uZmlndXJhYmxlDQoNCldvdWxkbid0IGl0IGJlIGJldHRlciB0byBzZXQgYSBsaW1pdCBvbiB0 aGUgdGltZSBzcGVudCByZXRyYW5zbWl0dGluZywgc28gaXQgd291bGQgYXV0b21hdGljYWxseSBn aXZlIHVwIHdpdGggbGVzcyByZXRyYW5zbWlzc2lvbnMgZm9yIGxvbmdlciB0cmFuc21pc3Npb24g ZGlzdGFuY2VzPw0KW0lKXSBQb3NzaWJsZSwgNEcgc3BlY2lmaWVzIGEgbGltaXQgdG8gdGhlIG51 bWJlciBvZiByZXRyYW5zbWlzc2lvbnMsIGluIHByYWN0aWNlIGl0IGNhbiBiZSB0cmFuc2xhdGVk IHRvIHRpbWUgYXMgZWFjaCByZXRyYW5zbWlzc2lvbiBpcyA4bXMgbGF0ZXIuDQoNCg0Kcy9vbmx5 IGNoZWNrcyBmb3IgdGhlIHByZXNlbmNlIG9uIGRvd25sb2FkIGRhdGEgb25seSBhdCByZWd1bGFy IGludGVydmFscy8NCiAvb25seSBjaGVja3MgZm9yIHRoZSBwcmVzZW5jZSBvZiBkb3dubG9hZCBk YXRhIGF0IHJlZ3VsYXIgaW50ZXJ2YWxzLw0KW09LXQ0KDQoNCjIuMy4yIFVwbGluayBzY2hlZHVs aW5nDQoNCiAgIFRoZSBzY2hlZHVsaW5nIHJlcXVlc3QgZG9lcyBub3QgaW5kaWNhdGUgaG93IG1h bnkgYnl0ZXMgdGhlcmUgYXJlIGluIHRoZSB1cGxpbmsgcXVldWUuDQpTZWVtcyBsaWtlIGEgYmFk IG9taXNzaW9uLiBJcyB0aGVyZSBhIHJlYXNvbj8gSWYgdGhlcmUgYXJlIGxlc3MgYnl0ZXMgcXVl dWVkIHRoYW4gdGhlIGJhc2Ugc3RhdGlvbidzIGdyYW50LCBzdXJlbHkgaXQgd291bGQgYmUgdXNl ZnVsIGZvciB0aGUgYmFzZSBzdGF0aW9uIHRvIGtub3csIHNvIHRoYXQgaXQgY2FuIGdyYW50IG1v cmUgdG8gc29tZXRoaW5nIGVsc2Ugd2hpbGUgdGhlIHByZXZpb3VzIHNob3J0IHRyYW5zbWlzc2lv biBpcyBjb21wbGV0aW5nLg0KW0lKXSBJdCBpcyBhIGRlc2lnbiBjaG9pY2UuIEEgYnVmZmVyIHN0 YXR1cyByZXBvcnQgaXMgbW9yZSBidWxreSwgYSBzY2hlZHVsaW5nIHJlcXVlc3QgaXMganVzdCBv bmUgYml0Lg0KDQoNCllvdSBzYXkgdGhhdCB3aGVuIEhBUlEgYnJlYWtzIHVwIGEgc2VxdWVuY2Ug b2YgQUNLcywgaXQgY2FuIGFsc28gdHJpZ2dlciAiY29hbGVzY2luZyBpc3N1ZXMiLiBJIGNhbiB1 bmRlcnN0YW5kIHRoYXQgaXQgY291bGQgY2F1c2UgQUNLIGNvbXByZXNzaW9uLCBidXQgYXJlIHlv dSBpbXBseWluZyBzb21ldGhpbmcgY29hbGVzY2VzIHRoZSBBQ0tzIG9yIHRoZSBzdWJzZXF1ZW50 IGRhdGE/IFdoYXQgZG9lcyB0aGUgY29hbGVzY2luZz8gU2ltaWxhcmx5LCBpbiB0aGUgbGFzdCBw YXJhIG9mIDIuMy4yIHlvdSBzYXkgIlJlZHVjZWQgQUNLcyBjYW4gdW5mb3J0dW5hdGVseSBjYXVz ZSBjb2FsZXNjaW5nLiIgYW5kIGFnYWluIEknbSBub3Qgc3VyZSB3aGF0IGlzIGNvYWxlc2Npbmcg d2hhdCBoZXJlLg0KW0lKXSBXaGF0IEkgY2FuIHNlZSBpbiBzaW11bGF0aW9ucyBpcyB0aGF0IHRo ZSBBQ0sgY29tcHJlc3Npb24gbGVhZHMgdG8gY29hbGVzY2luZyB3aGljaCBmdXJ0aGVyIGNhbiBp bmNyZWFzZSBqaXR0ZXIuDQoNClRoZXJlIGNvdWxkIGJlIGEgcG9zaXRpdmUgc2lkZSB0byB0aGUg aW50ZXJhY3Rpb24gYmV0d2VlbiBBQ0sgY2xvY2tpbmcgYW5kIGxpbmsgYWdncmVnYXRpb24sIGF0 IGxlYXN0IGZvciBsb25nLXJ1bm5pbmcgZmxvd3MuIFRoaXMgaGFzIGJlZW4gb2JzZXJ2ZWQgaW4g ODAyLjExbiBXaUZpIHdoZXJlIHRoZSBidWZmZXJpbmcgYW5kIGFnZ3JlZ2F0aW9uIG9mIG11bHRp cGxlIEFDS3MgaW50byBvbmUgdHJhbnNtaXNzaW9uIGdyYW50IHRlbmQgdG8gbGVhZCB0aGUgc2Vu ZGVyIHRvIGJ1bmNoIG11bHRpcGxlIGRhdGEgc2VnbWVudHMgc28gdGhhdCB0aGV5IGFsbCBuaWNl bHkgZmlsbCBvbmUgdHJhbnNtaXNzaW9uIGdyYW50IGluIHRoZSBvdGhlciBkaXJlY3Rpb24gW1No b3dhaWwxNF0uIEFzIGxvbmcgYXMgdGhlIHRyYW5zbWlzc2lvbiBncmFudCBkb2VzIG5vdCB3YWl0 IGZvciBtb3JlIGRhdGEgKHdoaWNoIHVuZm9ydHVuYXRlbHkgSSBkb24ndCB0aGluayBpcyB0aGUg Y2FzZSBpbiAzRy80Ry81RyksIHRoaXMgY291bGQgYmUgZ29vZCBmb3IgYmFuZHdpZHRoIHV0aWxp c2F0aW9uIG9mIGVsZXBoYW50cyBhbmQgbGF0ZW5jeSBvZiBtaWNlLCBpbmNsdWRpbmcgd2hlbiB0 aGV5IGFyZSBtaXhlZC4NCg0KW1Nob3dhaWwxNF0gU2hvd2FpbCwgQS4sIEphbXNoYWlkLCBLLiAm IFNoaWhhZGEsIEIuLCAiV1FNOiBBbiBBZ2dyZWdhdGlvbi1hd2FyZSBRdWV1ZSBNYW5hZ2VtZW50 IFNjaGVtZSBmb3IgSUVFRSA4MDIuMTFOIEJhc2VkIE5ldHdvcmtzLCIgSW46IFByb2NlZWRpbmdz IG9mIHRoZSAyMDE0IEFDTSBTSUdDT01NIFdvcmtzaG9wIG9uIENhcGFjaXR5IFNoYXJpbmcgV29y a3Nob3AgQ1NXUyAnMTQgcHAuMTUtMjAgQUNNICgyMDE0KQ0KPGh0dHA6Ly9kbC5hY20ub3JnL2Np dGF0aW9uLmNmbT9pZD0yNjMwMDk3Pg0KW0lKXSBJbnRlcmVzdGluZyAsd2lsbCBsb29rIGF0IGl0 LCBub3Qgc3VyZSB0aG91Z2ggdGhhdCBpdCB3aWxsIHdvcmsgdGhhdCB3ZWxsIHdpdGggNEcgKGNh bnQgc2F5IGFueXRoaW5nIGFib3V0IDVHKSwgaW4gNEcgdGhlIHRyYW5zbWlzc2lvbiBncmFudHMg Y2FuIHZhcnkgcXVpdGUgYSBsb3Qgb3ZlciBzaG9ydCB0aW1lIHNwYW5zLg0KDQoNCjMuICA0RyBh bmQgNUcgZXZvbHV0aW9uDQoNCnMvYSBleHBsaWNpdC9hbiBleHBsaWNpdC8NCg0KNC4gIFJlcXVp cmVtZW50cyBmb3IgaW1wcm92ZWQgcGVyZm9ybWFuY2UNCg0Kcy9idWZmZXJibG9hdC9idWZmZXIv DQoNCjUuICBDb25nZXN0aW9uIGNvbnRyb2wgZXhhbXBsZXMNCg0KUmVnYXJkaW5nIEh5YnJpZCBD dWJpYyB1c2luZyBPV0QgbWVhc3VyZW1lbnRzLCBJIGhhdmUgc2VlbiBhIHBhcGVyICh1bmRlciBz dWJtaXNzaW9uKSBhYm91dCBnZXR0aW5nIGRlbGF5LWJhc2VkIGNvbmdlc3Rpb24gY29udHJvbHMg KGUuZy4gTEVEQkFUIG9yIENBSUEgRGVsYXkgR3JhZGllbnQpIHRvIGludGVyd29yayB3aXRoIEFR TXMgd2l0aCB2YXJpb3VzIGxvdyBkZWxheSB0YXJnZXRzLiBJdCdzIG5vdCBpbiB0aGUgY29udGV4 dCBvZiBjZWxsdWxhciBuZXR3b3JrcywgYnV0IEknbGwgdHJ5IHRvIHJlbWVtYmVyIHRvIHBvaW50 IGl0IG91dCBvbmNlIGl0IGdldHMgcHVibGlzaGVkLg0KW0lKXSBTb3VuZHMgaW50ZXJlc3Rpbmcg LCBsb29raW5nIGZvcndhcmQgdG8gc2VlIHRoZSBwYXBlci4NCg0KDQo1LjEgSHlTdGFydFJlc3Rh cnQNCg0Kcy9hbGdvcml0aG0gdXNlZC9hbGdvcml0aG0gaXMgdXNlZC8NCg0KSW4gdGhlIG5ldyBj b2RlLCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZXhwbGFpbiB3aHkgdGhlIHNlY29uZCB0ZXN0IGJl Zm9yZSBkb3VibGluZyBzc3RocmVzaCwgaWUsIHRoZSB0ZXN0IGZvciBob3cgbG9uZyBpdCBoYXMg YmVlbiBzaW5jZSB0aGUgbGFzdCBoeXJlc3RhcnQuIEFsc28sIGluIHRoZSBoZWFkZXIgZGVmaW5p dGlvbnMsIGlmIHlvdSBpbnRlbmQgdGhlcmUgdG8gYmUgY29uc3RyYWludHMgb24gdGhlIHJlbGF0 aW9uIGJldHdlZW4gTl9SVFRfSFlSRVNUQVJUIGFuZCBOX1JUVF9MT1cgKGUuZy4gIE5fUlRUX0hZ UkVTVEFSVCA+IE5fUlRUX0xPVykgeW91IG91Z2h0IHRvIHNheSwgYmVjYXVzZSBwZW9wbGUgd2ls bCB0cnkgb3RoZXIgdmFsdWVzLg0KDQpSYXRoZXIgdGhhbiB0aGUgcmF0aGVyIGFyYml0cmFyeSB3 YWl0IGJlZm9yZSBhbiBhcmJpdHJhcnkgZG91Ymxpbmcgb2Ygc3N0aHJlc2gsIHdvdWxkbid0IGl0 IGJlIGJldHRlciB0byBjb250aW51YWxseSBpbmNyZWFzZSBzc3RocmVzaCAobm90IG5lY2Vzc2Fy aWx5IGxpbmVhcmx5KSB0aGUgbG9uZ2VyIHRoZSBSVFQgaGFzIHJlbWFpbmVkIG9ubHkganVzdCBo aWdoZXIgdGhhbiB0aGUgbWluIFJUVD8NCltJSl0gWWVzLCBjb3VsZCBiZSBhbiBvcHRpb24NCg0K DQooQlRXLCBzdXJlbHkgdGhlIG1haW4gcHJvYmxlbSB3aXRoIHRoaXMgbW9kaWZpY2F0aW9uIHRv IEh5U3RhcnRSZXN0YXJ0IGlzIHRoYXQgaXMgcmVxdWlyZXMgYSBudW1iZXIgb2Ygcm91bmQgdHJp cHMgdG8gcmVkdWNlIGRlbGF5IC0gYSBzb3J0LW9mIG94eW1vcm9uLikNCltJSl0gWWVzLCBoYXZl IHRyaWVkIHNvbWUgbW9yZSBleHBlcmltZW50cyB3aXRoIHRoaXMgYWxnb3JpdGhtLiBBbmQgSSBh bSBnZXR0aW5nIG1vcmUgaGVzaXRhbnQuIFRoZSBwcm9ibGVtIGlzIHRoYXQgd2hlbiBJIGFkZCBt b3JlIG5vaXNlIChtb2RlbGluZyBvZiBzbWFsbCBvYmplY3RzIHRyYWZmaWMpIGludG8gdGhlIHN5 c3RlbSBzaW11bGF0aW9uLCB0aGVuIEkgYWxzbyBnZXQgbW9yZSBkZWxheSBqaXR0ZXIgYW5kIHRo ZSBkZWxheSBkZXRlY3Rpb24gYWxnb3JpdGhtIGluIEh5U3RhcnQgaXMgbm90b3Jpb3VzbHkgc2Vu c2l0aXZlIHRvIGRlbGF5IGppdHRlci4NCg0KDQo1LjIuICBIeWJyaWQgQ3ViaWMNCg0KICAgRnVy dGhlcm1vcmUgaXQgaXMgYXNzdW1lZCB0aGFuIHRoZSB0aW1lc3RhbXAgY2xvY2sgZnJlcXVlbmN5 IGluDQoNCiAgIHNlbmRlciBhbmQgcmVjZWl2ZXIgYXJlIGlkZW50aWNhbCBvciB0aGF0IHRoZSBz ZW5kZXIgY2FuIGluZmVyIHRoZQ0KDQogICB0aW1lc3RhbXAgY2xvY2sgZnJlcXVlbmN5IG9mIHRo ZSByZWNlaXZlciBhbmQgcmVjb21wdXRlIHRpbWVzdGFtcA0KDQogICB2YWx1ZXMgYmFzZWQgb24g dGhpcyBpbmZvcm1hdGlvbi4NClJlY2VudGx5IG9uIHRjcG0gSSBzZW50IHlvdSBhIHBvaW50ZXIg dG8gdGhlIGNoaXJwaW5nIHBhcGVyIE1pcmphICYgSSBkaWQsIHdoaWNoIGFsc28gbWFkZSB0aGlz IGFzc3VtcHRpb24uIFBhcnRseSBwcm9tcHRlZCBieSB0aGF0LCBSaWNoYXJkIFNjaGVmZmVuZWdn ZXIgdHJpZWQgdG8gZ2V0IHBlb3BsZSBpbnRlcmVzdGVkIGluIHN0YW5kYXJkaXNpbmcgdXNlIG9m IHRoZSB0aW1lc3RhbXAgb3B0aW9uIG9uIGEgU1lOIHRvIG5lZ290aWF0ZSBzdHVmZiBsaWtlIHRp bWVyIHJlc29sdXRpb24uIEkgZG9uJ3QgdGhpbmsgaXQgd2VudCBhbnl3aGVyZS4gRG8geW91IHRo aW5rIHdlIG91Z2h0IHRvIHJldml0YWxpc2UgdGhhdD8gWW91IG1lbnRpb24gaW5mZXJlbmNlIC0g aGF2ZSB5b3UgdHJpZWQgdGhhdCAtIGFyZSB0aGVyZSBjYXNlcyB3aGVyZSBpdCBkb2Vzbid0IHdv cms/DQpbSUpdIFllcywgYWN0dWFsbHkgd29uZGVyZWQgd2hhdCBoYXBwZW5lZCB0byBSaWNoYXJk cyBkcmFmdC4gSSBvbmx5IGJyaWVmbHkgdHJpZWQgb3V0IHRoZSBpbmZlcmVuY2UgYWxnb3JpdGht IHdpdGggYSBUQ1AgTEVEQkFUIGltcGxlbWVudGF0aW9uIChodHRwczovL2dpdGh1Yi5jb20vc2ls dmlvdi9UQ1AtTEVEQkFUL2Jsb2IvbWFzdGVyL3NyYy90Y3BfbGVkYmF0LmMpLiBJIHJlY2FsbCB0 aGF0IGl0IHRvb2sgYSB3aGlsZSB0byBjb252ZXJnZS4gQWxzbyBJIGFtIG5vdCBzdXJlIGhlcmUu IElzIEh6IGluIGUuZyBhIGxpbnV4IHN0YWNrIGZpeGVkLiA/DQoNCg0KDQpUaGF0J3MgaXQuIFRo YW5rcyBhZ2FpbiBmb3IgdGhlIGRyYWZ0LiBWIHVzZWZ1bC4NCg0KDQoNCkJvYg0KDQoNCk9uIDE1 LzEwLzE1IDA2OjA4LCBJbmdlbWFyIEpvaGFuc3NvbiBTIHdyb3RlOg0KDQpIaQ0KDQoNCg0KQSBu ZXcgSUVURiBkcmFmdCBpcyBzdWJtaXR0ZWQgaW4gcmVzcG9uc2UgdG8gZ2VuZXJhbCBkaXNjdXNz aW9uIHRoYXQgZm9yIGluc3RhbmNlIFRDUCBDdWJpYyBpcyBub3QgYW4gYXBwcm9wcmlhdGUgY29u Z2VzdGlvbiBjb250cm9sIGFsZ29yaXRobSBmb3IgTFRFLg0KDQpUaGUgZHJhZnQgYnJpZWZseSBv dXRsaW5lcyB0eXBpY2FsIDRHIGFjY2VzcyBiZWhhdmlvciBvbiB0aGUgUERDUCwgUkxDIGFuZCBN QUMgIGxheWVycyB0aGF0IGNhbiBoYXZlIGFuIGltcGFjdCBvbiB0cmFuc3BvcnQgcHJvdG9jb2wg cGVyZm9ybWFuY2UuIFRoZSBkcmFmdCBhbHNvIG91dGxpbmVzIHR3byByZWxhdGl2ZWx5IHNpbXBs ZSBtb2RpZmljYXRpb25zIHRvIHRoZSBDdWJpYyBjb25nZXN0aW9uIGNvbnRyb2wuDQoNCg0KDQov SW5nZW1hcg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KDQpTZW50OiBkZW4gMTQgb2t0b2JlciAyMDE1 IDIwOjE3DQoNClRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTDQoNClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtam9oYW5zc29uLWNjLWZvci00Zy01Zy0wMC50eHQNCg0K DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtam9oYW5zc29uLWNjLWZvci00Zy01 Zy0wMC50eHQNCg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBJbmdlbWFyIEpv aGFuc3NvbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCg0KDQpOYW1lOiAg ICAgICAgICAgZHJhZnQtam9oYW5zc29uLWNjLWZvci00Zy01Zw0KDQpSZXZpc2lvbjogICAgICAg MDANCg0KVGl0bGU6ICAgICAgICAgIENvbmdlc3Rpb24gY29udHJvbCBmb3IgNEcgYW5kIDVHIGFj Y2Vzcw0KDQpEb2N1bWVudCBkYXRlOiAgMjAxNS0xMC0xNA0KDQpHcm91cDogICAgICAgICAgSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQoNClBhZ2VzOiAgICAgICAgICAxNA0KDQpVUkw6ICAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWpvaGFuc3Nvbi1j Yy1mb3ItNGctNWctMDAudHh0DQoNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLw0KDQpIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvaGFuc3Nvbi1jYy1mb3It NGctNWctMDANCg0KDQoNCg0KDQpBYnN0cmFjdDoNCg0KICAgVGhpcyBtZW1vIG91dGxpbmVzIHRo ZSBjaGFsbGVuZ2UgdGhhdCA0RyBhbmQgNUcgYWNjZXNzIGJyaW5ncyBmb3INCg0KICAgdHJhbnNw b3J0IHByb3RvY29sIGNvbmdlc3Rpb24gY29udHJvbCBhbmQgYWxzbyBvdXRsaW5lcyBhIGZldyBz aW1wbGUNCg0KICAgZXhhbXBsZXMgdGhhdCBjYW4gaW1wcm92ZSB0cmFuc3BvcnQgcHJvdG9jb2wg Y29uZ2VzdGlvbiBjb250cm9sDQoNCiAgIHBlcmZvcm1hbmNlIGluIDRHIGFuZCA1RyBhY2Nlc3Mu DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg0KDQoNCi0tDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K Qm9iIEJyaXNjb2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNj b2UubmV0Lw0K --_000_81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658ESESSMB205erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s b3I6YmxhY2s7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0 ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9y OmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymxh Y2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iU1YiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5kIHRoYW5rcyBmb3IgdGhlIHJldmlldywgY29tbWVudHMv YW5zd2Vycy9xdWVzdGlvbnMgaW5saW5lIGJlbG93PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPi9JbmdlbWFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0 ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBCb2IgQnJpc2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2Nv ZS5uZXRdDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDI5IG9rdG9iZXIgMjAxNSAxODo1NDxicj4N CjxiPlRvOjwvYj4gSW5nZW1hciBKb2hhbnNzb24gUzsgaWNjcmdAaXJ0Zi5vcmc7IHRjcG1AaWV0 Zi5vcmc7IHRzdndnQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHN2d2ddIEZX OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWpvaGFuc3Nvbi1jYy1mb3ItNGct NWctMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JbmdlbWFyLDxicj4NCjxicj4NCkFzIHByb21p c2VkLCBoZXJlJ3MgbXkgY29tbWVudHMuIFRoZXkgYXJlIGEgbWl4IG9mIHN1Z2dlc3RlZCBpbXBy b3ZlbWVudHMgdG8gdGhlIGRyYWZ0LCBzdWdnZXN0ZWQgaW1wcm92ZW1lbnRzIHRvIDVHLCBvciBy ZXF1ZXN0cyBmb3IgY2xhcmlmaWNhdGlvbi4gSSBhbHNvIGFncmVlIHdpdGggYWxsIEtldmluIFNt aXRoJ3MgY29tbWVudHMsIHNvIEkgZGlkbid0IHJlcGVhdCBhbnkuPGJyPg0KW1NvcnJ5IGZvciBk ZWxheSAtIEkgaGFkIHRvIGZpbmQgdGltZSB0byByZS10eXBlIGFmdGVyIGxvc2luZyBteSByZXZp ZXcgZHVyaW5nIGEgcG93ZXIgb3V0YWdlXTxicj4NCjxicj4NCjxiPjx1PkNvbnRleHQgcXVlc3Rp b25zLjwvdT48YnI+DQo8L2I+UTEuIElzIHRoaXMgZXhlcmNpc2UgdHJlYXRpbmcgdGhlIDVHIHNw ZWNzIHNvbGVseSBpbiByZWFkLW9ubHkgbW9kZT8gT3IsIGlmIHNvbWUgdXNlZnVsIGRlc2lnbiBz dWdnZXN0aW9ucyBhcmlzZSwgaXMgdGhlcmUgYW55IGNoYW5jZSB0aGF0IHRoZSAzR1BQIG1pZ2h0 IHRha2UgdGhlbSBvbiBib2FyZCwgZ2l2ZW4gNUcgaXMgbm90IGZ1bGx5IGJha2VkIHlldD88c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltJSl0gR3Vlc3MgaXQgZGVw ZW5kcywgbmVlZCB0byBzYXkgdGhhdCBJIHByb2JhYmx5IHRoZSBzbWFsbCBjb2cgaW4gdGhlIHdo ZWVsLiBJIHdvdWxkIHNheSB0aGF0IGEgbG90IG9mIHRoZSBzdGFuZGFyZHMNCiB3b3JrIGluIElF VEYgaGFzIGJlZW4gcGlja2VkIHVwIGJ5IDNHUFAgYW5kLCBJIGNhbm5vdCBzYXkgd2hhdCB3aWxs IGhhcHBlbiBpbiB0aGUgNUcgY29udGV4dC4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KPGJyPg0KSXQncyBncmVhdCB0aGF0IHlvdSBoYXZlIHRha2VuIHRoaXMgaW5pdGlhdGl2ZS4g PC9zcGFuPkRvZXMgdGhlIDNHUFAgZXZlciBmb3JtYWxseSBhc2sgdGhlIElFVEYgZm9yIGNvbW1l bnRzIG9uIGl0cyBpZGVhcyBmb3IgZWFjaCBuZXcgZ2VuZXJhdGlvbiBvZiByYWRpbz8gR2l2ZW4g dGhlIGxheWVycyBhYm92ZSBjYW4gYmUgdGhvdWdodCBvZiBhcyB0aGUgJ2N1c3RvbWVycycgb2Yg dGhlIDNHUFAsIGFuZCB0aGVzZSAnY3VzdG9tZXInIGxheWVycw0KIGFyZSBwcmV0dHkgbXVjaCBh bGwgbWFpbnRhaW5lZCBieSB0aGUgSUVURiwgaXQgd291bGQgc2VlbSBlc3NlbnRpYWwgKGFuZCBj b3VydGVvdXMpIGZvciB0aGUgM0dQUCB0byBhc2sgZm9yIGN1c3RvbWVyIGNvbW1lbnQsIG5vdCBs ZWFzdCB0byBjby1vcmRpbmF0ZSB3aXRoIHdoYXRldmVyIGZ1dHVyZSBwbGFucyB0aGUgSUVURiBt aWdodCBoYXZlIGZvciB0aGUgaGlnaGVyIGxheWVycy48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltJSl0gV2hhdCB5b3Ugc2F5IG1ha2VzIG11Y2ggc2Vuc2UuIEkg Z3Vlc3MgdGhlcmUgaXMgc29tZSBuYXR1cmFsIGxlYWthZ2UgYmV0d2VlbiAzR1BQIGFuZCBJRVRG IGFzIG1hbnkgb2YgdGhlIElFVEZlcnMNCiBhcmUgYWxzbyBhY3RpdmUgaW4gM0dQUCBzdGFuZGFy ZGl6YXRpb24uIEkgZG9u4oCZdCBoYXZlIGZ1bGwgaW5zaWdodCBpbiB0aGUgZm9ybWFsIHJlbGF0 aW9uIGJldHdlZW4gM0dQUCBhbmQgSUVURiBpbiB0aGVzZSBhcmVhcywgbm90IHN1cmUgaWYgdGhh dCBuZWVkIHRvIGJlIGJldHRlciwgYnV0IGlmIHRoYXQgaXMgdGhlIGNhc2UsIHRoZW4gaXQgaXMg cHJvYmFibHkgYSBxdWVzdGlvbiBmb3IgdGhlIGFyZWEgZGlyZWN0b3JzLiBOZWVkIHRvIHNheQ0K IHRoYXQgZXZlbiB0aG91Z2ggdGhlIGZvcm1hbCBjaGFubmVscyBhcmUgc2NhcmNlIGl0IGRvZXMg cHJvYmFibHkgbm90IG1lYW4gdGhhdCAzR1BQIGlnbm9yZXMgSUVURiBvciB3aGF0IGhhcHBlbnMg YWJvdmUgSVAgaW4gZ2VuZXJhbC4gRm9yIGluc3RhbmNlIHRoZSByZWNlbnQgd29yayBhcm91bmQg VENQIFJBQ0sgcmFpc2VzIHRoZSBxdWVzdGlvbiBpZiBpdCBpcyBuZWNlc3NhcnkgdGhhdCBMVEUg ZGVmYXVsdCByYWRpbyBiZWFyZXJzIGVuc3VyZQ0KIGluIG9yZGVyIGRlbGl2ZXJ5LiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQpRMi4gV2hhdCBhcmUgeW91 ciBwbGFucyBmb3IgdGhpcyBkcmFmdD8gPC9zcGFuPkFyZSB5b3UgYXNraW5nIGZvciBhZG9wdGlv bj8gQW5kIGlmIHNvLCBpbiB3aGljaCBXRyBvciBSRz8gSUNDUkcgbG9va3MgdGhlIG1vc3QgYXBw cm9wcmlhdGUsIGdpdmVuIHRoZSBjaGFydGVycyBvZiBhbGwgdGhlIElFVEYgY2MgV0dzIChUU1ZX RywgVENQTSwgUk1DQVQsIGV0YykgYXJlIHNjb3BlZCBvbiBqdXN0IGEgc3Vic2V0IG9mIHlvdXIg ZG9jLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0lKXSBGaXJz dCBvYmplY3RpdmUgaXMgdG8gZ2V0IGFuIGluY3JlYXNlZCBpbnRlcmVzdCBpbiBjb25nZXN0aW9u IGNvbnRyb2wgYWxnb3JpdGhtIHdvcmsgaW4gdGhlIElFVEYuIFRyYWRpdGlvbmFsbHkNCiB0aGlz IGtpbmQgb2Ygd29yayBzZWVtIHRvIGJlIG1vcmUgaW4gdGhlIHRlcm1zIG9mIGNvbmZlcmVuY2Ug cGFwZXJzIGluIGUuZy4gU2lnY29tbSwgdGhlIGJlbmVmaXQgd2l0aCBoYXZpbmcgc3VjaCB3b3Jr IGluIElFVEYgaXMgdGhhdCBpbnB1dCBmcm9tIHBlb3BsZSB3aXRoIGEgd2lkZXIgZXhwZXJ0aXNl IGFyZWEgKGluY2x1ZGluZyAzR1BQIGV4cGVyaXRpc2UpIGNhbiBnaXZlIGFsZ29yaXRobSBwcm9w b3NhbHMgdGhhdCB3b3JrIHdlbGwgZm9yDQogYSB3aWRlciBzZXQgb2YgYWNjZXNzIHR5cGVzLiBU aGUgd29yayBhcm91bmQgQ3ViaWMgaXMgYSBmaXJzdCBnb29kIHN0ZXAgYXMgaXMgdGhlIHdvcmsg YXJvdW5kIERDVENQLiBXaGF0IEkgd29uZGVyIGlzIGlmIGl0IGZlYXNpYmxlIHRvIHRha2UgdGhp cyBhIGJpdCBmdXJ0aGVyID8gSSB3b3VsZCB0b28gYmVsaWV2ZSB0aGF0IHRoZSBjdXJyZW50IGRv YyBmaXRzIGJldHRlciBpbiBJQ0NSRy4gJm5ic3A7VGhlIGFsZ29yaXRobSBleGFtcGxlcyBhcmUg anVzdC4uDQogZXhhbXBsZXMuIE1vcmUgZnJ1aXRmdWwgd29yayBpcyBwcm9iYWJseSB0byBkb2N1 bWVudCBkaWZmZXJlbnQgYWNjZXNzIHR5cGVzIGFuZCBmcm9tIHRoZXJlIGRlcml2ZSBhIHNldCBv ZiBiZXN0IGN1cnJlbnQgcHJhY3RpY2VzIGZvciBjb25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGht czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxiPjx1PlNl Y3Rpb24gYnkgU2VjdGlvbiBSZXZpZXc8L3U+PGJyPg0KPC9iPjxicj4NCjxiPkFsbCBzZWN0aW9u czxicj4NCjwvYj48YnI+DQpUaGUgZG9jdW1lbnQgZ2VuZXJhbGx5IHRhbGtzIGFib3V0IHRoZSBM VEUgcHJvdG9jb2wgc3RhY2sgYXMgaWYgZGF0YSBpcyB0cmF2ZWxsaW5nIGRvd24gaXQuDQo8L3Nw YW4+QXJlIHlvdSBpbXBseWluZyB0aGF0IG1vc3Qgc291cmNlcyBvZiBidWZmZXJpbmcgZGVsYXkg YXJlIGF0IHRoZSBzZW5kaW5nIGVuZCwgYW5kIHRoZSBmZWVkYmFjayBlbmQgaXMgcHJldHR5IHVu ZW5jdW1iZXJlZCBieSBkZWxheXM/IEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGV4cGxp Y2l0bHkgc2F5IHNvbWV0aGluZyBhYm91dCB0aGlzICh3aGV0aGVyIHRydWUgb3Igbm90KSwgdG8g ZXhwbGFpbiB3aHkgb25seSBvbmUgZGlyZWN0aW9uDQogb2YgdHJhdmVsIGlzIGRpc2N1c3NlZCBp biB0aGUgZG9jLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0lK XSBUaGUgZmVlZGJhY2sgcGF0aCBpcyBlbmN1bWJlcmVkIGJ5IGRlbGF5cywgaXQgaXMgcGVyaGFw cyBub3QgdGhhdCBjbGVhciBidXQgc2VjdGlvbiAyLjMuMiBpbXBsaWVzIHRoYXQgZGVsYXkNCiAo dmFyaWF0aW9uKSBpbiB1cGxpbmsgd2lsbCBhZmZlY3QgdGhlIEFDS3MgZm9yIGRvd25saW5rIGRh dGEgdHJhZmZpYy4gVGhhdCBzYWlkLCB0aGUgZGlmZmVyZW5jZSBpbiBETC9VTCB0cmFmZmljIGlz IHRvZGF5IHNvbWV0aGluZyBsaWtlIDEwOjEgYW5kIHRoYXQgaXMgcHJvYmFibHkgb25lIHJlYXNv biB3aHkgb25lIGNhbiBnZXQgdGhlIGZlZWxpbmcgdGhhdCB0aGUgZHJhZnQgaXMgc2xhbnRlZCB0 b3dhcmRzIGRvd25saW5rIGRhdGEgdHJhZmZpYywNCiB0aGlzIG1heSBob3dldmVyIGNoYW5nZSB3 aXRoIHRpbWUgYXMgbW9yZSBtYWNoaW5lIHR5cGUgdHJhZmZpYyBtYXkgZW50ZXIgdGhlIHN5c3Rl bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8Yj4yLjEg UERDUCBsYXllcjxicj4NCjwvYj48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjx0dD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlBEQ1AgYWxzbyBlbnN1 cmVzIHRoYXQgYWxsPC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8dHQ+ Jm5ic3A7Jm5ic3A7IHBhY2tldHMgYXJlIGRlbGl2ZXJlZCBpbiBvcmRlciB1cCB0byBoaWdoZXIg bGF5ZXJzLjwvdHQ+PGJyPg0KPC9zcGFuPkkgdGhpbmsgdGhpcyBtZWFucyAmcXVvdDtpbiB0aGUg b3JkZXIgc2VudCBpbnRvIHRoZSBsaW5rIChQRENQKSBsYXllciZxdW90Oy4gVGhpcyBvdWdodCB0 byBiZSBjbGFyaWZpZWQsIG90aGVyd2lzZSwgd2hlbiB3cml0aW5nIGluIHRoZSBjb250ZXh0IG9m IGEgbGF5ZXIgNCBhdWRpZW5jZSwgaXQgbWlnaHQgYmUgYXNzdW1lZCB0aGlzIG1lYW5zIGluIHRo ZSBvcmRlciBzZW50IGJ5IHRoZSBvcmlnaW5hbCB0cmFuc3BvcnQgbGF5ZXIgc291cmNlLg0KPHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bSUpdIFllcywgeW91IGFy ZSByaWdodCAsIHJlb3JkZXJpbmcgY2FuIHN0aWxsIG9jY3VyIGUuZy4gaW4gdGhlIHdpcmVsZXNz IGJhY2toYXVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0K PC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZu YnNwOyZuYnNwOyBrZWVwIHRoZSBhbW91bnQgb2YgZGF0YSBpbiBmbGlnaHQgYXMgc21hbGwgYXMg cG9zc2libGUsIHdpdGhvdXQgc2FjcmlmaWNpbmcgdGhyb3VnaHB1dC48L3NwYW4+PC90dD48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj5JcyB0aGlzIGp1c3QgYSByYXRoZXIgY29u dm9sdXRlZCB3YXkgb2Ygc2F5aW5nICZxdW90O2tlZXAgdGhlIFJUVCBhcyBsb3cgYXMgcG9zc2li bGUmcXVvdDs/ICh3aGljaCBpbiB0dXJuIGltcGxpZXMga2VlcGluZyBxdWV1aW5nIGRlbGF5IGFz IGxvdyBhcyBwb3NzaWJsZSBhc3N1bWluZyB5b3UgY2Fubm90IGluZmx1ZW5jZSB0aGUgcGh5c2lj YWwgcGF0aC4pIE9yIHdlcmUgeW91IHRyeWluZyB0byBtYWtlIGEgbW9yZSBzdWJ0bGUgcG9pbnQ/ IC0gaWYgc28sDQogaXQgd2FzIGxvc3Qgb24gbWUuPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bSUpdIE5vLCBpdCBpcyBleGFjdGx5IGFzIHlvdSBkZXNjcmliZSBi ZWxvdzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjwvc3Bh bj48dHQ+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsm bmJzcDsgUmVsaWFibGUgZGVsaXZlcnkgYXQgaGFuZG92ZXIgbWF5IGhvd2V2ZXIgYmUgdHVybmVk IG9mZiBvciBpcyBzaW1wbHkgbm90IGltcGxlbWVudGVkLDwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5JdCB3b3VsZCBiZSB1 c2VmdWwgaWYgeW91IGNvdWxkIGdpdmUgYSBmZWVsIGZvciByb3VnaGx5IGhvdyBvZnRlbiAoaW4g JSkgdGhlc2UgY2FzZXMgaG9sZC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0lKXSBJIGRvbuKAmXQgYmVsaWV2ZSB0aGF0IGl0 IGlzIHBvc3NpYmxlIHRvIGdpdmUgYSBmaWd1cmUgYXMgdGhpcyBpcyB2ZW5kb3Igc3BlY2lmaWMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPGI+Mi4yIFJM QyBsYXllcjwvYj48YnI+DQo8YnI+DQo8L3NwYW4+PHR0PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IHJvbGUgLi4uIGlzIHRvIGVuc3VyZSB0 aGF0IHBhY2tldHMgYXJlIGRlbGl2ZXJlZCBpbiBvcmRlciB1cCB0byB0aGUgaGlnaGVyIGxheWVy czwvc3Bhbj48L3R0PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj5FaD8gPC9zcGFuPlRoZSBQRENQIHNlY3Rpb24ganVzdCBzYWlkIGl0IGRpZCBv cmRlcmluZy4gQW5kIHRoZSByZXN0IG9mIHRoZSBSTEMgc2VjdGlvbiB0YWxrcyBleGNsdXNpdmVs eSBhYm91dCBidWZmZXJpbmcgZGVsYXlzIG5lY2Vzc2FyeSB3aGlsZSBmaWxsaW5nIHRyYW5zcG9y dCBibG9ja3MuIElmIG9yZGVyaW5nIGlzIHRoZSByb2xlIG9mIGJvdGggbGF5ZXJzLCBzdXJlbHkg b25lIHdpbGwgaGF2ZQ0KIG5vdGhpbmcgdG8gZG8gb25jZSB0aGUgb3RoZXIgaGFzIGdvdCBldmVy eXRoaW5nIGluIG9yZGVyPzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+W0lKXSBSTEMgaGFuZGxlcyBvcmRlcmluZyBkdWUgdG8gdmFyaW91cyBNQUMgbGF5ZXIgZmFp bHVyZXMuIFBEQ1AgaGFuZGxlcyBvcmRlcmluZyAmbmJzcDt3aGVuIGhhbmRvdmVyIG9jY3Vyczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjwvc3Bhbj48dHQ+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsg dmFyeWluZyBzaXplIG9mIHRoZSBhdmFpbGFibGUgdHJhbnNwb3J0PC9zcGFuPjwvdHQ+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPk5pdDogR2l2 ZW4gJ3RyYW5zcG9ydCcgbWVhbnMgZTJlIGZvciB0aGUgYXVkaWVuY2Ugb2YgdGhpcyBkcmFmdCwg cGxzIHVzZSBiZWFyZXIgb3Igc29tZWhvdyBkaXNhbWJpZ3VhdGUgdGhpcyB3b3JkLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b SUpdIE9LPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPGJy Pg0KR2FwIzE6IEluIHRoZSBkcmFmdCwgaXQgc2VlbXMgbGlrZSB0cmFuc3BvcnQgYmxvY2tzIGFy cml2ZSBieSBtYWdpYywgdG8gYmUgZmlsbGVkIGJ5IGRhdGEgYnVmZmVyZWQgaW4gdGhlIFJMQyBs YXllci4NCjwvc3Bhbj5UbyB1bmRlcnN0YW5kIHRoZSBkZWxheSBjb21wcm9taXNlcyBoZXJlLCBJ IHRoaW5rIHRoZSBkcmFmdCBuZWVkcyB0byBleHBsYWluIHdoYXQgZGV0ZXJtaW5lcyBob3cgbXVj aCB0cmFuc3BvcnQgYmxvY2sgY2FwYWNpdHkgZWFjaCBmbG93IGlzIGdpdmVuLCBhbmQgaG93IHRo ZXkgY2FuIGluZmx1ZW5jZSBpdC4gSW4gM0csIEkgYmVsaWV2ZSB0aGF0IHRoZSB0cmFuc3BvcnQg bGF5ZXIgY291bGQgYXNrIHRoZSByYWRpbyByZXNvdXJjZSBjb250cm9sbGVyDQogdG8gY2hhbmdl IHJhZGlvIHJlc291cmNlIGFsbG9jYXRpb24uIElzIHRoaXMgdGhlIHNhbWUgaW4gNEcgJmFtcDsg NUc/IERvZXMgdGhlIGJhY2tsb2cgb2YgdGhlIGJ1ZmZlciBpbnRvIHRoZSBSTEMgbGF5ZXIgaGF2 ZSBhbnkgYXV0b21hdGljIGluZmx1ZW5jZSBvdmVyIGFsbG9jYXRpb24gb2YgYXZhaWxhYmxlIHJl c291cmNlcz8gSSBhc3N1bWUgdHJhZmZpYyBjbGFzcyBjYW4gYWxzbyBiZSB1c2VkIHRvIGluZmx1 ZW5jZSBhbGxvY2F0aW9uLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+W0lKXSBXaWxsIHVwZGF0ZWQgd2l0aCBtb3JlIGRldGFpbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCkdhcCMyOiBJbiBhIDNHIHN0YWNrLCB0aGUgUkxD IGxheWVyIG11bHRpcGxleGVzIGFsbCB0aGUgYWN0aXZlIGFwcGxpY2F0aW9uIHN0cmVhbXMgaW50 byBNQUMgbGF5ZXIgdHJhbnNwb3J0IGJsb2NrIGJ5IGRpY2luZyB1cCBidWZmZXJlZCBwYWNrZXRz IGFuZCBwYWNraW5nIHRoZSBwaWVjZXMgaW50byBlYWNoIHRyYW5zcG9ydCBibG9jay4NCjwvc3Bh bj5UaGVuLCBhdCB0aGUgb3RoZXIgZW5kIG9mIHRoZSBsaW5rLCBlYWNoIHBpZWNlIGhhcyB0byBi ZSBoZWxkIHVudGlsIHRoZSByZXN0IG9mIHRoZSBwYWNrZXQgYXJyaXZlcy4gVGhpcyBzYWNyaWZp Y2VzIGRlbGF5IGZvciBiYW5kd2lkdGggZWZmaWNpZW5jeS4gSXMgdGhpcyBzdGlsbCBkb25lIGlu IDRHIGFuZCA1Rz8gSWYgc28sIGl0IHdvdWxkIGJlIGdvb2QgdG8gd3JpdGUgYWJvdXQgbXV4IGRl bGF5IGluIHRoZSBkcmFmdCB0b28uPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5bSUpdIE9LLCB3aWxsIGFkZCBtb3JlIGluZm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8Yj4yLjMgTUFDIGxheWVyPGJyPg0KPC9iPjxicj4N Cjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m bmJzcDsmbmJzcDsgdGhlIG1heGltdW0gbnVtYmVyIG9mIHJldHJhbnNtaXNzaW9ucyBpcyBjb25m aWd1cmFibGU8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KV291bGRuJ3QgaXQgYmUgYmV0dGVyIHRvIHNldCBhIGxp bWl0IG9uIHRoZSA8aT50aW1lPC9pPiBzcGVudCByZXRyYW5zbWl0dGluZywgc28gaXQgd291bGQg YXV0b21hdGljYWxseSBnaXZlIHVwIHdpdGggbGVzcyByZXRyYW5zbWlzc2lvbnMgZm9yIGxvbmdl ciB0cmFuc21pc3Npb24gZGlzdGFuY2VzPzxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltJSl0gUG9zc2libGUsIDRHIHNwZWNpZmllcyBhIGxpbWl0 IHRvIHRoZSBudW1iZXIgb2YgcmV0cmFuc21pc3Npb25zLCBpbiBwcmFjdGljZSBpdCBjYW4gYmUg dHJhbnNsYXRlZCB0byB0aW1lIGFzIGVhY2ggcmV0cmFuc21pc3Npb24gaXMgOG1zIGxhdGVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48 YnI+DQpzL29ubHkgY2hlY2tzIGZvciB0aGUgcHJlc2VuY2Ugb24gZG93bmxvYWQgZGF0YSBvbmx5 IGF0IHJlZ3VsYXIgaW50ZXJ2YWxzLzxicj4NCiZuYnNwOy9vbmx5IGNoZWNrcyBmb3IgdGhlIHBy ZXNlbmNlIG9mIGRvd25sb2FkIGRhdGEgYXQgcmVndWxhciBpbnRlcnZhbHMvPGJyPg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+W09LXTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8Yj4y LjMuMiBVcGxpbmsgc2NoZWR1bGluZzxicj4NCjwvYj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFRoZSBzY2hl ZHVsaW5nIHJlcXVlc3QgZG9lcyBub3QgaW5kaWNhdGUgaG93IG1hbnkgYnl0ZXMgdGhlcmUgYXJl IGluIHRoZSB1cGxpbmsgcXVldWUuPC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQo8L3NwYW4+U2VlbXMgbGlrZSBhIGJhZCBvbWlzc2lvbi4gSXMgdGhlcmUgYSByZWFzb24/ IElmIHRoZXJlIGFyZSBsZXNzIGJ5dGVzIHF1ZXVlZCB0aGFuIHRoZSBiYXNlIHN0YXRpb24ncyBn cmFudCwgc3VyZWx5IGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgdGhlIGJhc2Ugc3RhdGlvbiB0byBr bm93LCBzbyB0aGF0IGl0IGNhbiBncmFudCBtb3JlIHRvIHNvbWV0aGluZyBlbHNlIHdoaWxlIHRo ZSBwcmV2aW91cyBzaG9ydCB0cmFuc21pc3Npb24gaXMgY29tcGxldGluZy48YnI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltJSl0gSXQgaXMgYSBkZXNpZ24gY2hv aWNlLiBBIGJ1ZmZlciBzdGF0dXMgcmVwb3J0IGlzIG1vcmUgYnVsa3ksIGEgc2NoZWR1bGluZyBy ZXF1ZXN0IGlzIGp1c3Qgb25lIGJpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KWW91IHNheSB0aGF0IHdoZW4gSEFSUSBicmVh a3MgdXAgYSBzZXF1ZW5jZSBvZiBBQ0tzLCBpdCBjYW4gYWxzbyB0cmlnZ2VyICZxdW90O2NvYWxl c2NpbmcgaXNzdWVzJnF1b3Q7Lg0KPC9zcGFuPkkgY2FuIHVuZGVyc3RhbmQgdGhhdCBpdCBjb3Vs ZCBjYXVzZSBBQ0sgY29tcHJlc3Npb24sIGJ1dCBhcmUgeW91IGltcGx5aW5nIHNvbWV0aGluZyBj b2FsZXNjZXMgdGhlIEFDS3Mgb3IgdGhlIHN1YnNlcXVlbnQgZGF0YT8gV2hhdCBkb2VzIHRoZSBj b2FsZXNjaW5nPw0KPHNwYW4gbGFuZz0iRU4tVVMiPlNpbWlsYXJseSwgaW4gdGhlIGxhc3QgcGFy YSBvZiAyLjMuMiB5b3Ugc2F5ICZxdW90O1JlZHVjZWQgQUNLcyBjYW4gdW5mb3J0dW5hdGVseSBj YXVzZSBjb2FsZXNjaW5nLiZxdW90OyBhbmQgYWdhaW4gSSdtIG5vdCBzdXJlIHdoYXQgaXMgY29h bGVzY2luZyB3aGF0IGhlcmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltJSl0gV2hhdCBJIGNhbiBzZWUgaW4gc2ltdWxhdGlv bnMgaXMgdGhhdCB0aGUgQUNLIGNvbXByZXNzaW9uIGxlYWRzIHRvIGNvYWxlc2Npbmcgd2hpY2gg ZnVydGhlciBjYW4gaW5jcmVhc2Ugaml0dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NClRoZXJlIGNvdWxkIGJlIGEgcG9zaXRpdmUgc2lkZSB0byB0aGUgaW50ZXJh Y3Rpb24gYmV0d2VlbiBBQ0sgY2xvY2tpbmcgYW5kIGxpbmsgYWdncmVnYXRpb24sIGF0IGxlYXN0 IGZvciBsb25nLXJ1bm5pbmcgZmxvd3MuDQo8L3NwYW4+VGhpcyBoYXMgYmVlbiBvYnNlcnZlZCBp biA4MDIuMTFuIFdpRmkgd2hlcmUgdGhlIGJ1ZmZlcmluZyBhbmQgYWdncmVnYXRpb24gb2YgbXVs dGlwbGUgQUNLcyBpbnRvIG9uZSB0cmFuc21pc3Npb24gZ3JhbnQgdGVuZCB0byBsZWFkIHRoZSBz ZW5kZXIgdG8gYnVuY2ggbXVsdGlwbGUgZGF0YSBzZWdtZW50cyBzbyB0aGF0IHRoZXkgYWxsIG5p Y2VseSBmaWxsIG9uZSB0cmFuc21pc3Npb24gZ3JhbnQgaW4gdGhlIG90aGVyIGRpcmVjdGlvbg0K IFtTaG93YWlsMTRdLiA8c3BhbiBsYW5nPSJFTi1VUyI+QXMgbG9uZyBhcyB0aGUgdHJhbnNtaXNz aW9uIGdyYW50IGRvZXMgbm90IHdhaXQgZm9yIG1vcmUgZGF0YSAod2hpY2ggdW5mb3J0dW5hdGVs eSBJIGRvbid0IHRoaW5rIGlzIHRoZSBjYXNlIGluIDNHLzRHLzVHKSwgdGhpcyBjb3VsZCBiZSBn b29kIGZvciBiYW5kd2lkdGggdXRpbGlzYXRpb24gb2YgZWxlcGhhbnRzIGFuZCBsYXRlbmN5IG9m IG1pY2UsIGluY2x1ZGluZyB3aGVuIHRoZXkgYXJlDQogbWl4ZWQuPGJyPg0KPGJyPg0KW1Nob3dh aWwxNF0gU2hvd2FpbCwgQS4sIEphbXNoYWlkLCBLLiAmYW1wOyBTaGloYWRhLCBCLiwgJnF1b3Q7 V1FNOiBBbiBBZ2dyZWdhdGlvbi1hd2FyZSBRdWV1ZSBNYW5hZ2VtZW50IFNjaGVtZSBmb3IgSUVF RSA4MDIuMTFOIEJhc2VkIE5ldHdvcmtzLCZxdW90OyBJbjogUHJvY2VlZGluZ3Mgb2YgdGhlIDIw MTQgQUNNIFNJR0NPTU0gV29ya3Nob3Agb24gQ2FwYWNpdHkgU2hhcmluZyBXb3Jrc2hvcCBDU1dT ICcxNCBwcC4xNS0yMCBBQ00gKDIwMTQpPGJyPg0KJmx0Ozwvc3Bhbj48YSBocmVmPSJodHRwOi8v ZGwuYWNtLm9yZy9jaXRhdGlvbi5jZm0/aWQ9MjYzMDA5NyI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0 dHA6Ly9kbC5hY20ub3JnL2NpdGF0aW9uLmNmbT9pZD0yNjMwMDk3PC9zcGFuPjwvYT48c3BhbiBs YW5nPSJFTi1VUyI+Jmd0Ozxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPltJSl0gSW50ZXJlc3RpbmcgLHdpbGwgbG9vayBhdCBpdCwgbm90IHN1cmUg dGhvdWdoIHRoYXQgaXQgd2lsbCB3b3JrIHRoYXQgd2VsbCB3aXRoIDRHIChjYW50IHNheSBhbnl0 aGluZyBhYm91dCA1RyksIGluIDRHIHRoZSB0cmFuc21pc3Npb24gZ3JhbnRzIGNhbiB2YXJ5IHF1 aXRlIGEgbG90IG92ZXIgc2hvcnQgdGltZSBzcGFucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPC9zcGFuPjxiPjMuJm5ic3A7 IDRHIGFuZCA1RyBldm9sdXRpb248YnI+DQo8L2I+PGJyPg0Kcy9hIGV4cGxpY2l0L2FuIGV4cGxp Y2l0Lzxicj4NCjxicj4NCjxiPjQuJm5ic3A7IFJlcXVpcmVtZW50cyBmb3IgaW1wcm92ZWQgcGVy Zm9ybWFuY2U8YnI+DQo8L2I+PGJyPg0Kcy9idWZmZXJibG9hdC9idWZmZXIvPGJyPg0KPGJyPg0K PGI+NS4mbmJzcDsgQ29uZ2VzdGlvbiBjb250cm9sIGV4YW1wbGVzPGJyPg0KPC9iPjxicj4NClJl Z2FyZGluZyBIeWJyaWQgQ3ViaWMgdXNpbmcgT1dEIG1lYXN1cmVtZW50cywgSSBoYXZlIHNlZW4g YSBwYXBlciAodW5kZXIgc3VibWlzc2lvbikgYWJvdXQgZ2V0dGluZyBkZWxheS1iYXNlZCBjb25n ZXN0aW9uIGNvbnRyb2xzIChlLmcuIExFREJBVCBvciBDQUlBIERlbGF5IEdyYWRpZW50KSB0byBp bnRlcndvcmsgd2l0aCBBUU1zIHdpdGggdmFyaW91cyBsb3cgZGVsYXkgdGFyZ2V0cy4gSXQncyBu b3QgaW4gdGhlIGNvbnRleHQgb2YgY2VsbHVsYXINCiBuZXR3b3JrcywgYnV0IEknbGwgdHJ5IHRv IHJlbWVtYmVyIHRvIHBvaW50IGl0IG91dCBvbmNlIGl0IGdldHMgcHVibGlzaGVkLjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0lKXSBTb3VuZHMgaW50ZXJlc3Rp bmcgLCBsb29raW5nIGZvcndhcmQgdG8gc2VlIHRoZSBwYXBlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8Yj41LjEgSHlTdGFydFJlc3RhcnQ8YnI+DQo8 L2I+PGJyPg0Kcy9hbGdvcml0aG0gdXNlZC9hbGdvcml0aG0gaXMgdXNlZC88YnI+DQo8YnI+DQpJ biB0aGUgbmV3IGNvZGUsIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBleHBsYWluIHdoeSB0aGUgc2Vj b25kIHRlc3QgYmVmb3JlIGRvdWJsaW5nIHNzdGhyZXNoLCBpZSwgdGhlIHRlc3QgZm9yIGhvdyBs b25nIGl0IGhhcyBiZWVuIHNpbmNlIHRoZSBsYXN0IGh5cmVzdGFydC4NCjwvc3Bhbj5BbHNvLCBp biB0aGUgaGVhZGVyIGRlZmluaXRpb25zLCBpZiB5b3UgaW50ZW5kIHRoZXJlIHRvIGJlIGNvbnN0 cmFpbnRzIG9uIHRoZSByZWxhdGlvbiBiZXR3ZWVuIE5fUlRUX0hZUkVTVEFSVCBhbmQgTl9SVFRf TE9XIChlLmcuJm5ic3A7IE5fUlRUX0hZUkVTVEFSVCAmZ3Q7IE5fUlRUX0xPVykgeW91IG91Z2h0 IHRvIHNheSwgYmVjYXVzZSBwZW9wbGUgd2lsbCB0cnkgb3RoZXIgdmFsdWVzLjxicj4NCjxicj4N ClJhdGhlciB0aGFuIHRoZSByYXRoZXIgYXJiaXRyYXJ5IHdhaXQgYmVmb3JlIGFuIGFyYml0cmFy eSBkb3VibGluZyBvZiBzc3RocmVzaCwgd291bGRuJ3QgaXQgYmUgYmV0dGVyIHRvIGNvbnRpbnVh bGx5IGluY3JlYXNlIHNzdGhyZXNoIChub3QgbmVjZXNzYXJpbHkgbGluZWFybHkpIHRoZSBsb25n ZXIgdGhlIFJUVCBoYXMgcmVtYWluZWQgb25seSBqdXN0IGhpZ2hlciB0aGFuIHRoZSBtaW4gUlRU PzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0lKXSBZZXMsIGNv dWxkIGJlIGFuIG9wdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N Cjxicj4NCihCVFcsIHN1cmVseSB0aGUgbWFpbiBwcm9ibGVtIHdpdGggdGhpcyBtb2RpZmljYXRp b24gdG8gSHlTdGFydFJlc3RhcnQgaXMgdGhhdCBpcyByZXF1aXJlcyBhIG51bWJlciBvZiByb3Vu ZCB0cmlwcyB0byByZWR1Y2UgZGVsYXkgLSBhIHNvcnQtb2Ygb3h5bW9yb24uKTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bSUpd IFllcywgaGF2ZSB0cmllZCBzb21lIG1vcmUgZXhwZXJpbWVudHMgd2l0aCB0aGlzIGFsZ29yaXRo bS4gQW5kIEkgYW0gZ2V0dGluZyBtb3JlIGhlc2l0YW50LiBUaGUgcHJvYmxlbSBpcyB0aGF0DQog d2hlbiBJIGFkZCBtb3JlIG5vaXNlIChtb2RlbGluZyBvZiBzbWFsbCBvYmplY3RzIHRyYWZmaWMp IGludG8gdGhlIHN5c3RlbSBzaW11bGF0aW9uLCB0aGVuIEkgYWxzbyBnZXQgbW9yZSBkZWxheSBq aXR0ZXIgYW5kIHRoZSBkZWxheSBkZXRlY3Rpb24gYWxnb3JpdGhtIGluIEh5U3RhcnQgaXMgbm90 b3Jpb3VzbHkgc2Vuc2l0aXZlIHRvIGRlbGF5IGppdHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8L3NwYW4+PGI+NS4yLiZuYnNwOyBIeWJyaWQgQ3Vi aWM8L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBGdXJ0aGVybW9yZSBpdCBpcyBhc3N1bWVk IHRoYW4gdGhlIHRpbWVzdGFtcCBjbG9jayBmcmVxdWVuY3kgaW48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgc2VuZGVyIGFuZCByZWNlaXZlciBhcmUgaWRlbnRpY2FsIG9yIHRo YXQgdGhlIHNlbmRlciBjYW4gaW5mZXIgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IHRpbWVzdGFtcCBjbG9jayBmcmVxdWVuY3kgb2YgdGhlIHJlY2VpdmVyIGFuZCByZWNv bXB1dGUgdGltZXN0YW1wPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHZhbHVl cyBiYXNlZCBvbiB0aGlzIGluZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlJlY2VudGx5IG9uIHRjcG0g SSBzZW50IHlvdSBhIHBvaW50ZXIgdG8gdGhlIGNoaXJwaW5nIHBhcGVyIE1pcmphICZhbXA7IEkg ZGlkLCB3aGljaCBhbHNvIG1hZGUgdGhpcyBhc3N1bXB0aW9uLiBQYXJ0bHkgcHJvbXB0ZWQgYnkg dGhhdCwgUmljaGFyZCBTY2hlZmZlbmVnZ2VyIHRyaWVkIHRvIGdldCBwZW9wbGUgaW50ZXJlc3Rl ZCBpbiBzdGFuZGFyZGlzaW5nIHVzZQ0KIG9mIHRoZSB0aW1lc3RhbXAgb3B0aW9uIG9uIGEgU1lO IHRvIG5lZ290aWF0ZSBzdHVmZiBsaWtlIHRpbWVyIHJlc29sdXRpb24uIEkgZG9uJ3QgdGhpbmsg aXQgd2VudCBhbnl3aGVyZS4gRG8geW91IHRoaW5rIHdlIG91Z2h0IHRvIHJldml0YWxpc2UgdGhh dD8gWW91IG1lbnRpb24gaW5mZXJlbmNlIC0gaGF2ZSB5b3UgdHJpZWQgdGhhdCAtIGFyZSB0aGVy ZSBjYXNlcyB3aGVyZSBpdCBkb2Vzbid0IHdvcms/PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5bSUpdIFllcywgYWN0dWFsbHkgd29uZGVyZWQgd2hhdCBoYXBwZW5l ZCB0byBSaWNoYXJkcyBkcmFmdC4gSSBvbmx5IGJyaWVmbHkgdHJpZWQgb3V0IHRoZSBpbmZlcmVu Y2UgYWxnb3JpdGhtIHdpdGgNCiBhIFRDUCBMRURCQVQgaW1wbGVtZW50YXRpb24gKDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjojOTY5ODk2O2JhY2tncm91bmQ6d2hpdGUiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0 aHViLmNvbS9zaWx2aW92L1RDUC1MRURCQVQvYmxvYi9tYXN0ZXIvc3JjL3RjcF9sZWRiYXQuYyI+ aHR0cHM6Ly9naXRodWIuY29tL3NpbHZpb3YvVENQLUxFREJBVC9ibG9iL21hc3Rlci9zcmMvdGNw X2xlZGJhdC5jPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPikuDQogSSByZWNhbGwgdGhhdCBpdCB0b29rIGEgd2hpbGUgdG8g Y29udmVyZ2UuIEFsc28gSSBhbSBub3Qgc3VyZSBoZXJlLiBJcyBIeiBpbiBlLmcgYSBsaW51eCBz dGFjayBmaXhlZC4gPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxi cj4NCjxicj4NClRoYXQncyBpdC4gVGhhbmtzIGFnYWluIGZvciB0aGUgZHJhZnQuIFYgdXNlZnVs Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCkJvYjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+T24gMTUvMTAvMTUgMDY6MDgsIEluZ2VtYXIgSm9oYW5zc29uIFMgPC9zcGFuPg0Kd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5IaTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkEgbmV3IElFVEYgZHJhZnQgaXMgc3VibWl0 dGVkIGluIHJlc3BvbnNlIHRvIGdlbmVyYWwgZGlzY3Vzc2lvbiB0aGF0IGZvciBpbnN0YW5jZSBU Q1AgQ3ViaWMgaXMgbm90IGFuIGFwcHJvcHJpYXRlIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0 aG0gZm9yIExURS4gPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlIGRyYWZ0IGJyaWVmbHkgb3V0 bGluZXMgdHlwaWNhbCA0RyBhY2Nlc3MgYmVoYXZpb3Igb24gdGhlIFBEQ1AsIFJMQyBhbmQgTUFD Jm5ic3A7IGxheWVycyB0aGF0IGNhbiBoYXZlIGFuIGltcGFjdCBvbiB0cmFuc3BvcnQgcHJvdG9j b2wgcGVyZm9ybWFuY2UuIFRoZSBkcmFmdCBhbHNvIG91dGxpbmVzIHR3byByZWxhdGl2ZWx5IHNp bXBsZSBtb2RpZmljYXRpb25zIHRvIHRoZSBDdWJpYyBjb25nZXN0aW9uIGNvbnRyb2wuPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+L0luZ2VtYXIm bmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gcm9t OiA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn Ij5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl0gPG86cD48L286cD48L3ByZT4N CjxwcmU+U2VudDogZGVuIDE0IG9rdG9iZXIgMjAxNSAyMDoxNzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTPG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVj dDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qb2hhbnNzb24tY2MtZm9yLTRn LTVnLTAwLnR4dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLTAwLnR4dDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSW5nZW1hciBKb2hhbnNzb24g YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWpvaGFuc3Nvbi1j Yy1mb3ItNGctNWc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZXZpc2lvbjombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaXRsZTom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29u Z2VzdGlvbiBjb250cm9sIGZvciA0RyBhbmQgNUcgYWNjZXNzPG86cD48L286cD48L3ByZT4NCjxw cmU+RG9jdW1lbnQgZGF0ZTombmJzcDsgMjAxNS0xMC0xNDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pkdyb3VwOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5QYWdlczom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTQ8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLTAw LnR4dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWpvaGFuc3Nv bi1jYy1mb3ItNGctNWctMDAudHh0PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN0YXR1czom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9oYW5zc29uLWNjLWZvci00 Zy01Zy8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpvaGFuc3Nvbi1j Yy1mb3ItNGctNWcvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkh0bWxpemVkOiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtam9oYW5zc29uLWNjLWZvci00Zy01Zy0wMCI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWpvaGFuc3Nvbi1jYy1mb3ItNGctNWctMDA8L2E+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+QWJzdHJhY3Q6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IFRoaXMgbWVtbyBvdXRsaW5lcyB0aGUgY2hhbGxlbmdlIHRoYXQgNEcgYW5kIDVHIGFj Y2VzcyBicmluZ3MgZm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRyYW5z cG9ydCBwcm90b2NvbCBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIGFsc28gb3V0bGluZXMgYSBmZXcg c2ltcGxlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGV4YW1wbGVzIHRoYXQg Y2FuIGltcHJvdmUgdHJhbnNwb3J0IHByb3RvY29sIGNvbmdlc3Rpb24gY29udHJvbDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBwZXJmb3JtYW5jZSBpbiA0RyBhbmQgNUcgYWNj ZXNzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQvIj5odHRwOi8vYm9iYnJpc2NvZS5uZXQvPC9h PjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658ESESSMB205erics_-- From nobody Wed Nov 4 14:27:24 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF741B34B9; Wed, 4 Nov 2015 14:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vesW_C5tVlxD; Wed, 4 Nov 2015 14:27:16 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2771E1B34B7; Wed, 4 Nov 2015 14:27:14 -0800 (PST) Received: from x104183.dynamic.ppp.asahi-net.or.jp ([122.249.104.183]:48462 helo=[192.168.1.118]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1Zu6WL-0000Mf-Vl; Wed, 04 Nov 2015 22:27:11 +0000 To: Ingemar Johansson S , "iccrg@irtf.org" , "tcpm@ietf.org" , "tsvwg@ietf.org" References: <20151014181702.10618.83714.idtracker@ietfa.amsl.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34BF4F0F@ESESSMB205.ericsson.se> <56325D2D.1070107@bobbriscoe.net> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658@ESESSMB205.ericsson.se> From: Bob Briscoe Message-ID: <563A8635.3000400@bobbriscoe.net> Date: Wed, 4 Nov 2015 22:27:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658@ESESSMB205.ericsson.se> Content-Type: multipart/alternative; boundary="------------040700010104070701040704" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tcpm] [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 04 Nov 2015 22:27:22 -0000 This is a multi-part message in MIME format. --------------040700010104070701040704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ingemar, On 04/11/15 13:27, Ingemar Johansson S wrote: > > Hi > > And thanks for the review, comments/answers/questions inline below > > /Ingemar > > *From:*Bob Briscoe [mailto:ietf@bobbriscoe.net] > *Sent:* den 29 oktober 2015 18:54 > *To:* Ingemar Johansson S; iccrg@irtf.org; tcpm@ietf.org; tsvwg@ietf.org > *Subject:* Re: [tsvwg] FW: New Version Notification for > draft-johansson-cc-for-4g-5g-00.txt > > Ingemar, > > As promised, here's my comments. They are a mix of suggested > improvements to the draft, suggested improvements to 5G, or requests > for clarification. I also agree with all Kevin Smith's comments, so I > didn't repeat any. > [Sorry for delay - I had to find time to re-type after losing my > review during a power outage] > > *_Context questions._ > *Q1. Is this exercise treating the 5G specs solely in read-only mode? > Or, if some useful design suggestions arise, is there any chance that > the 3GPP might take them on board, given 5G is not fully baked yet? > > [IJ] Guess it depends, need to say that I probably the small cog in > the wheel. I would say that a lot of the standards work in IETF has > been picked up by 3GPP and, I cannot say what will happen in the 5G > context. > > It's great that you have taken this initiative. Does the 3GPP ever > formally ask the IETF for comments on its ideas for each new > generation of radio? Given the layers above can be thought of as the > 'customers' of the 3GPP, and these 'customer' layers are pretty much > all maintained by the IETF, it would seem essential (and courteous) > for the 3GPP to ask for customer comment, not least to co-ordinate > with whatever future plans the IETF might have for the higher layers. > > [IJ] What you say makes much sense. I guess there is some natural > leakage between 3GPP and IETF as many of the IETFers are also active > in 3GPP standardization. I don’t have full insight in the formal > relation between 3GPP and IETF in these areas, not sure if that need > to be better, but if that is the case, then it is probably a question > for the area directors. Need to say that even though the formal > channels are scarce it does probably not mean that 3GPP ignores IETF > or what happens above IP in general. For instance the recent work > around TCP RACK raises the question if it is necessary that LTE > default radio bearers ensure in order delivery. > I suspect that 3GPP radio resource control people do not cross-fertilize much with the IETF. So maybe it is as much a question of how to co-ordinate between these radio people and L4, which I would imagine is as much a problem within 3GPP as between 3GPP and IETF. > > > > Q2. What are your plans for this draft? Are you asking for adoption? > And if so, in which WG or RG? ICCRG looks the most appropriate, given > the charters of all the IETF cc WGs (TSVWG, TCPM, RMCAT, etc) are > scoped on just a subset of your doc. > > [IJ] First objective is to get an increased interest in congestion > control algorithm work in the IETF. Traditionally this kind of work > seem to be more in the terms of conference papers in e.g. Sigcomm, the > benefit with having such work in IETF is that input from people with a > wider expertise area (including 3GPP experitise) can give algorithm > proposals that work well for a wider set of access types. The work > around Cubic is a first good step as is the work around DCTCP. What I > wonder is if it feasible to take this a bit further ? I would too > believe that the current doc fits better in ICCRG. The algorithm > examples are just.. examples. More fruitful work is probably to > document different access types and from there derive a set of best > current practices for congestion control algorithms > I'm sure the iccrg chairs would like this to happen. And initiatives like yours to come with proposals to propose specific code to take account of L2 I think generate the right level of dialogue. > > > > *_Section by Section Review_ > * > *All sections > * > The document generally talks about the LTE protocol stack as if data > is travelling down it. Are you implying that most sources of buffering > delay are at the sending end, and the feedback end is pretty > unencumbered by delays? I think it would be useful to explicitly say > something about this (whether true or not), to explain why only one > direction of travel is discussed in the doc. > > [IJ] The feedback path is encumbered by delays, it is perhaps not that > clear but section 2.3.2 implies that delay (variation) in uplink will > affect the ACKs for downlink data traffic. That said, the difference > in DL/UL traffic is today something like 10:1 and that is probably one > reason why one can get the feeling that the draft is slanted towards > downlink data traffic, this may however change with time as more > machine type traffic may enter the system. > I was thinking more in terms of up the stack vs. down the stack, not uplink/downlink. I.e. for both cases: * downlink direction: are there any buffering concerns coming up the stack at the UE, or on the feedback back-channel from the UE? * uplink direction: are there any buffering concerns coming up the stack at the eNodeB, or on the feedback back-channel from the eNodeB? For instance, in the UE, perhaps one app blocking the read of another due to the way {3-5}G multiplexes different streams into the same PDCP frames? > > > > *2.1 PDCP layer > * > PDCP also ensures that all > packets are delivered in order up to higher layers. > I think this means "in the order sent into the link (PDCP) layer". > This ought to be clarified, otherwise, when writing in the context of > a layer 4 audience, it might be assumed this means in the order sent > by the original transport layer source. > > [IJ] Yes, you are right , reordering can still occur e.g. in the > wireless backhaul > > > > keep the amount of data in flight as small as possible, without > sacrificing throughput. > Is this just a rather convoluted way of saying "keep the RTT as low as > possible"? (which in turn implies keeping queuing delay as low as > possible assuming you cannot influence the physical path.) Or were you > trying to make a more subtle point? - if so, it was lost on me. > > [IJ] No, it is exactly as you describe below > > > > Reliable delivery at handover may however be turned off or is simply > not implemented, > It would be useful if you could give a feel for roughly how often (in > %) these cases hold. > > [IJ] I don’t believe that it is possible to give a figure as this is > vendor specific. > > > > *2.2 RLC layer* > > role ... is to ensure that packets are delivered in order up to the > higher layers > Eh? The PDCP section just said it did ordering. And the rest of the > RLC section talks exclusively about buffering delays necessary while > filling transport blocks. If ordering is the role of both layers, > surely one will have nothing to do once the other has got everything > in order? > > [IJ] RLC handles ordering due to various MAC layer failures. PDCP > handles ordering when handover occurs > > > > varying size of the available transport > Nit: Given 'transport' means e2e for the audience of this draft, pls > use bearer or somehow disambiguate this word. > > [IJ] OK > > > > > Gap#1: In the draft, it seems like transport blocks arrive by magic, > to be filled by data buffered in the RLC layer. To understand the > delay compromises here, I think the draft needs to explain what > determines how much transport block capacity each flow is given, and > how they can influence it. In 3G, I believe that the transport layer > could ask the radio resource controller to change radio resource > allocation. Is this the same in 4G & 5G? Does the backlog of the > buffer into the RLC layer have any automatic influence over allocation > of available resources? I assume traffic class can also be used to > influence allocation. > > [IJ] Will updated with more detail > > > > Gap#2: In a 3G stack, the RLC layer multiplexes all the active > application streams into MAC layer transport block by dicing up > buffered packets and packing the pieces into each transport block. > Then, at the other end of the link, each piece has to be held until > the rest of the packet arrives. This sacrifices delay for bandwidth > efficiency. Is this still done in 4G and 5G? If so, it would be good > to write about mux delay in the draft too. > > [IJ] OK, will add more info > > > > *2.3 MAC layer > * > the maximum number of retransmissions is configurable > > Wouldn't it be better to set a limit on the /time/ spent > retransmitting, so it would automatically give up with less > retransmissions for longer transmission distances? > [IJ] Possible, 4G specifies a limit to the number of retransmissions, > in practice it can be translated to time as each retransmission is 8ms > later. > I didn't realise it was independent of link-RTT. Then the more basic question is why is it independent of link-RTT? Surely on a short link it can assume that it needs to retransmit more quickly than on a long link? You can see that my question was assuming that retransmission happened more often on a short link, then I was saying it should still be allowed the same amount of time to keep retrying (so on a short link it would be allowed to retransmit more times before giving up, but the max delay would be the same). 8ms! I was assuming it would be rather much less than that. Surely a link-layer ACK could never take that long if the frame was going to get through. > > > s/only checks for the presence on download data only at regular intervals/ > /only checks for the presence of download data at regular intervals/ > [OK] > > > *2.3.2 Uplink scheduling > * > The scheduling request does not indicate how many bytes there are in > the uplink queue. > Seems like a bad omission. Is there a reason? If there are less bytes > queued than the base station's grant, surely it would be useful for > the base station to know, so that it can grant more to something else > while the previous short transmission is completing. > [IJ] It is a design choice. A buffer status report is more bulky, a > scheduling request is just one bit. > > > You say that when HARQ breaks up a sequence of ACKs, it can also > trigger "coalescing issues". I can understand that it could cause ACK > compression, but are you implying something coalesces the ACKs or the > subsequent data? What does the coalescing? Similarly, in the last para > of 2.3.2 you say "Reduced ACKs can unfortunately cause coalescing." > and again I'm not sure what is coalescing what here. > > [IJ] What I can see in simulations is that the ACK compression leads > to coalescing which further can increase jitter. > I still don't understand. The question was "What is coalescing what?" > > > There could be a positive side to the interaction between ACK clocking > and link aggregation, at least for long-running flows. This has been > observed in 802.11n WiFi where the buffering and aggregation of > multiple ACKs into one transmission grant tend to lead the sender to > bunch multiple data segments so that they all nicely fill one > transmission grant in the other direction [Showail14]. As long as the > transmission grant does not wait for more data (which unfortunately I > don't think is the case in 3G/4G/5G), this could be good for bandwidth > utilisation of elephants and latency of mice, including when they are > mixed. > > [Showail14] Showail, A., Jamshaid, K. & Shihada, B., "WQM: An > Aggregation-aware Queue Management Scheme for IEEE 802.11N Based > Networks," In: Proceedings of the 2014 ACM SIGCOMM Workshop on > Capacity Sharing Workshop CSWS '14 pp.15-20 ACM (2014) > > [IJ] Interesting ,will look at it, not sure though that it will work > that well with 4G (cant say anything about 5G), in 4G the transmission > grants can vary quite a lot over short time spans. > > > *3. 4G and 5G evolution > * > s/a explicit/an explicit/ > > *4. Requirements for improved performance > * > s/bufferbloat/buffer/ > > *5. Congestion control examples > * > Regarding Hybrid Cubic using OWD measurements, I have seen a paper > (under submission) about getting delay-based congestion controls (e.g. > LEDBAT or CAIA Delay Gradient) to interwork with AQMs with various low > delay targets. It's not in the context of cellular networks, but I'll > try to remember to point it out once it gets published. > > [IJ] Sounds interesting , looking forward to see the paper. > > > > *5.1 HyStartRestart > * > s/algorithm used/algorithm is used/ > > In the new code, it would be useful to explain why the second test > before doubling ssthresh, ie, the test for how long it has been since > the last hyrestart. Also, in the header definitions, if you intend > there to be constraints on the relation between N_RTT_HYRESTART and > N_RTT_LOW (e.g. N_RTT_HYRESTART > N_RTT_LOW) you ought to say, > because people will try other values. > > Rather than the rather arbitrary wait before an arbitrary doubling of > ssthresh, wouldn't it be better to continually increase ssthresh (not > necessarily linearly) the longer the RTT has remained only just higher > than the min RTT? > > [IJ] Yes, could be an option > > > > (BTW, surely the main problem with this modification to HyStartRestart > is that is requires a number of round trips to reduce delay - a > sort-of oxymoron.) > > [IJ] Yes, have tried some more experiments with this algorithm. And I > am getting more hesitant. The problem is that when I add more noise > (modeling of small objects traffic) into the system simulation, then I > also get more delay jitter and the delay detection algorithm in > HyStart is notoriously sensitive to delay jitter. > > > > *5.2. Hybrid Cubic* > > Furthermore it is assumed than the timestamp clock frequency in > sender and receiver are identical or that the sender can infer the > timestamp clock frequency of the receiver and recompute timestamp > values based on this information. > > Recently on tcpm I sent you a pointer to the chirping paper Mirja & I > did, which also made this assumption. Partly prompted by that, Richard > Scheffenegger tried to get people interested in standardising use of > the timestamp option on a SYN to negotiate stuff like timer > resolution. I don't think it went anywhere. Do you think we ought to > revitalise that? You mention inference - have you tried that - are > there cases where it doesn't work? > > [IJ] Yes, actually wondered what happened to Richards draft. I only > briefly tried out the inference algorithm with a TCP LEDBAT > implementation > (https://github.com/silviov/TCP-LEDBAT/blob/master/src/tcp_ledbat.c). > I recall that it took a while to converge. Also I am not sure here. Is > Hz in e.g a linux stack fixed. ? > I believe so. But I don't know about embedded systems etc. Cheers Bob > > > > > That's it. Thanks again for the draft. V useful. > > > > Bob > > > On 15/10/15 06:08, Ingemar Johansson S wrote: > > Hi > > A new IETF draft is submitted in response to general discussion that for instance TCP Cubic is not an appropriate congestion control algorithm for LTE. > > The draft briefly outlines typical 4G access behavior on the PDCP, RLC and MAC layers that can have an impact on transport protocol performance. The draft also outlines two relatively simple modifications to the Cubic congestion control. > > /Ingemar > > -----Original Message----- > > From:internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: den 14 oktober 2015 20:17 > > To: Ingemar Johansson S > > Subject: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt > > A new version of I-D, draft-johansson-cc-for-4g-5g-00.txt > > has been successfully submitted by Ingemar Johansson and posted to the IETF repository. > > Name: draft-johansson-cc-for-4g-5g > > Revision: 00 > > Title: Congestion control for 4G and 5G access > > Document date: 2015-10-14 > > Group: Individual Submission > > Pages: 14 > > URL:https://www.ietf.org/internet-drafts/draft-johansson-cc-for-4g-5g-00.txt > > Status:https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-5g/ > > Htmlized:https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-00 > > Abstract: > > This memo outlines the challenge that 4G and 5G access brings for > > transport protocol congestion control and also outlines a few simple > > examples that can improve transport protocol congestion control > > performance in 4G and 5G access. > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------040700010104070701040704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Ingemar,

On 04/11/15 13:27, Ingemar Johansson S wrote:

Hi

 

And thanks for the review, comments/answers/questions inline below

 

/Ingemar

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: den 29 oktober 2015 18:54
To: Ingemar Johansson S; iccrg@irtf.org; tcpm@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt

 

Ingemar,

As promised, here's my comments. They are a mix of suggested improvements to the draft, suggested improvements to 5G, or requests for clarification. I also agree with all Kevin Smith's comments, so I didn't repeat any.
[Sorry for delay - I had to find time to re-type after losing my review during a power outage]

Context questions.
Q1. Is this exercise treating the 5G specs solely in read-only mode? Or, if some useful design suggestions arise, is there any chance that the 3GPP might take them on board, given 5G is not fully baked yet?

[IJ] Guess it depends, need to say that I probably the small cog in the wheel. I would say that a lot of the standards work in IETF has been picked up by 3GPP and, I cannot say what will happen in the 5G context.

It's great that you have taken this initiative. Does the 3GPP ever formally ask the IETF for comments on its ideas for each new generation of radio? Given the layers above can be thought of as the 'customers' of the 3GPP, and these 'customer' layers are pretty much all maintained by the IETF, it would seem essential (and courteous) for the 3GPP to ask for customer comment, not least to co-ordinate with whatever future plans the IETF might have for the higher layers.

[IJ] What you say makes much sense. I guess there is some natural leakage between 3GPP and IETF as many of the IETFers are also active in 3GPP standardization. I don’t have full insight in the formal relation between 3GPP and IETF in these areas, not sure if that need to be better, but if that is the case, then it is probably a question for the area directors. Need to say that even though the formal channels are scarce it does probably not mean that 3GPP ignores IETF or what happens above IP in general. For instance the recent work around TCP RACK raises the question if it is necessary that LTE default radio bearers ensure in order delivery.

I suspect that 3GPP radio resource control people do not cross-fertilize much with the IETF.
So maybe it is as much a question of how to co-ordinate between these radio people and L4, which I would imagine is as much a problem within 3GPP as between 3GPP and IETF.



Q2. What are your plans for this draft? Are you asking for adoption? And if so, in which WG or RG? ICCRG looks the most appropriate, given the charters of all the IETF cc WGs (TSVWG, TCPM, RMCAT, etc) are scoped on just a subset of your doc.

[IJ] First objective is to get an increased interest in congestion control algorithm work in the IETF. Traditionally this kind of work seem to be more in the terms of conference papers in e.g. Sigcomm, the benefit with having such work in IETF is that input from people with a wider expertise area (including 3GPP experitise) can give algorithm proposals that work well for a wider set of access types. The work around Cubic is a first good step as is the work around DCTCP. What I wonder is if it feasible to take this a bit further ? I would too believe that the current doc fits better in ICCRG.  The algorithm examples are just.. examples. More fruitful work is probably to document different access types and from there derive a set of best current practices for congestion control algorithms

I'm sure the iccrg chairs would like this to happen. And initiatives like yours to come with proposals to propose specific code to take account of L2 I think generate the right level of dialogue.



Section by Section Review

All sections

The document generally talks about the LTE protocol stack as if data is travelling down it. Are you implying that most sources of buffering delay are at the sending end, and the feedback end is pretty unencumbered by delays? I think it would be useful to explicitly say something about this (whether true or not), to explain why only one direction of travel is discussed in the doc.

[IJ] The feedback path is encumbered by delays, it is perhaps not that clear but section 2.3.2 implies that delay (variation) in uplink will affect the ACKs for downlink data traffic. That said, the difference in DL/UL traffic is today something like 10:1 and that is probably one reason why one can get the feeling that the draft is slanted towards downlink data traffic, this may however change with time as more machine type traffic may enter the system.

I was thinking more in terms of up the stack vs. down the stack, not uplink/downlink. I.e. for both cases:
* downlink direction: are there any buffering concerns coming up the stack at the UE, or on the feedback back-channel from the UE?
* uplink direction: are there any buffering concerns coming up the stack at the eNodeB, or on the feedback back-channel from the eNodeB?

For instance, in the UE, perhaps one app blocking the read of another due to the way {3-5}G multiplexes different streams into the same PDCP frames?



2.1 PDCP layer

    PDCP also ensures that all
   packets are delivered in order up to higher layers.
I think this means "in the order sent into the link (PDCP) layer". This ought to be clarified, otherwise, when writing in the context of a layer 4 audience, it might be assumed this means in the order sent by the original transport layer source.

[IJ] Yes, you are right , reordering can still occur e.g. in the wireless backhaul



   keep the amount of data in flight as small as possible, without sacrificing throughput.
Is this just a rather convoluted way of saying "keep the RTT as low as possible"? (which in turn implies keeping queuing delay as low as possible assuming you cannot influence the physical path.) Or were you trying to make a more subtle point? - if so, it was lost on me.

[IJ] No, it is exactly as you describe below



   Reliable delivery at handover may however be turned off or is simply not implemented,
It would be useful if you could give a feel for roughly how often (in %) these cases hold.

[IJ] I don’t believe that it is possible to give a figure as this is vendor specific.



2.2 RLC layer

   role ... is to ensure that packets are delivered in order up to the higher layers
Eh? The PDCP section just said it did ordering. And the rest of the RLC section talks exclusively about buffering delays necessary while filling transport blocks. If ordering is the role of both layers, surely one will have nothing to do once the other has got everything in order?

[IJ] RLC handles ordering due to various MAC layer failures. PDCP handles ordering  when handover occurs



   varying size of the available transport
Nit: Given 'transport' means e2e for the audience of this draft, pls use bearer or somehow disambiguate this word.

[IJ] OK




Gap#1: In the draft, it seems like transport blocks arrive by magic, to be filled by data buffered in the RLC layer. To understand the delay compromises here, I think the draft needs to explain what determines how much transport block capacity each flow is given, and how they can influence it. In 3G, I believe that the transport layer could ask the radio resource controller to change radio resource allocation. Is this the same in 4G & 5G? Does the backlog of the buffer into the RLC layer have any automatic influence over allocation of available resources? I assume traffic class can also be used to influence allocation.

[IJ] Will updated with more detail



Gap#2: In a 3G stack, the RLC layer multiplexes all the active application streams into MAC layer transport block by dicing up buffered packets and packing the pieces into each transport block. Then, at the other end of the link, each piece has to be held until the rest of the packet arrives. This sacrifices delay for bandwidth efficiency. Is this still done in 4G and 5G? If so, it would be good to write about mux delay in the draft too.

[IJ] OK, will add more info



2.3 MAC layer

   the maximum number of retransmissions is configurable

Wouldn't it be better to set a limit on the time spent retransmitting, so it would automatically give up with less retransmissions for longer transmission distances?
[IJ] Possible, 4G specifies a limit to the number of retransmissions, in practice it can be translated to time as each retransmission is 8ms later.

I didn't realise it was independent of link-RTT. Then the more basic question is why is it independent of link-RTT? Surely on a short link it can assume that it needs to retransmit more quickly than on a long link?

You can see that my question was assuming that retransmission happened more often on a short link, then I was saying it should still be allowed the same amount of time to keep retrying (so on a short link it would be allowed to retransmit more times before giving up, but the max delay would be the same).

8ms! I was assuming it would be rather much less than that. Surely a link-layer ACK could never take that long if the frame was going to get through.

 


s/only checks for the presence on download data only at regular intervals/
 /only checks for the presence of download data at regular intervals/
[OK]

 


2.3.2 Uplink scheduling

   The scheduling request does not indicate how many bytes there are in the uplink queue.
Seems like a bad omission. Is there a reason? If there are less bytes queued than the base station's grant, surely it would be useful for the base station to know, so that it can grant more to something else while the previous short transmission is completing.
[IJ] It is a design choice. A buffer status report is more bulky, a scheduling request is just one bit.

 


You say that when HARQ breaks up a sequence of ACKs, it can also trigger "coalescing issues". I can understand that it could cause ACK compression, but are you implying something coalesces the ACKs or the subsequent data? What does the coalescing? Similarly, in the last para of 2.3.2 you say "Reduced ACKs can unfortunately cause coalescing." and again I'm not sure what is coalescing what here.

[IJ] What I can see in simulations is that the ACK compression leads to coalescing which further can increase jitter.

I still don't understand. The question was "What is coalescing what?"


There could be a positive side to the interaction between ACK clocking and link aggregation, at least for long-running flows. This has been observed in 802.11n WiFi where the buffering and aggregation of multiple ACKs into one transmission grant tend to lead the sender to bunch multiple data segments so that they all nicely fill one transmission grant in the other direction [Showail14]. As long as the transmission grant does not wait for more data (which unfortunately I don't think is the case in 3G/4G/5G), this could be good for bandwidth utilisation of elephants and latency of mice, including when they are mixed.

[Showail14] Showail, A., Jamshaid, K. & Shihada, B., "WQM: An Aggregation-aware Queue Management Scheme for IEEE 802.11N Based Networks," In: Proceedings of the 2014 ACM SIGCOMM Workshop on Capacity Sharing Workshop CSWS '14 pp.15-20 ACM (2014)
<http://dl.acm.org/citation.cfm?id=2630097>
[IJ] Interesting ,will look at it, not sure though that it will work that well with 4G (cant say anything about 5G), in 4G the transmission grants can vary quite a lot over short time spans.

 


3.  4G and 5G evolution

s/a explicit/an explicit/

4.  Requirements for improved performance

s/bufferbloat/buffer/

5.  Congestion control examples

Regarding Hybrid Cubic using OWD measurements, I have seen a paper (under submission) about getting delay-based congestion controls (e.g. LEDBAT or CAIA Delay Gradient) to interwork with AQMs with various low delay targets. It's not in the context of cellular networks, but I'll try to remember to point it out once it gets published.

[IJ] Sounds interesting , looking forward to see the paper.



5.1 HyStartRestart

s/algorithm used/algorithm is used/

In the new code, it would be useful to explain why the second test before doubling ssthresh, ie, the test for how long it has been since the last hyrestart. Also, in the header definitions, if you intend there to be constraints on the relation between N_RTT_HYRESTART and N_RTT_LOW (e.g.  N_RTT_HYRESTART > N_RTT_LOW) you ought to say, because people will try other values.

Rather than the rather arbitrary wait before an arbitrary doubling of ssthresh, wouldn't it be better to continually increase ssthresh (not necessarily linearly) the longer the RTT has remained only just higher than the min RTT?

[IJ] Yes, could be an option



(BTW, surely the main problem with this modification to HyStartRestart is that is requires a number of round trips to reduce delay - a sort-of oxymoron.)

[IJ] Yes, have tried some more experiments with this algorithm. And I am getting more hesitant. The problem is that when I add more noise (modeling of small objects traffic) into the system simulation, then I also get more delay jitter and the delay detection algorithm in HyStart is notoriously sensitive to delay jitter.



5.2.  Hybrid Cubic

   Furthermore it is assumed than the timestamp clock frequency in
   sender and receiver are identical or that the sender can infer the
   timestamp clock frequency of the receiver and recompute timestamp
   values based on this information.

Recently on tcpm I sent you a pointer to the chirping paper Mirja & I did, which also made this assumption. Partly prompted by that, Richard Scheffenegger tried to get people interested in standardising use of the timestamp option on a SYN to negotiate stuff like timer resolution. I don't think it went anywhere. Do you think we ought to revitalise that? You mention inference - have you tried that - are there cases where it doesn't work?

[IJ] Yes, actually wondered what happened to Richards draft. I only briefly tried out the inference algorithm with a TCP LEDBAT implementation (https://github.com/silviov/TCP-LEDBAT/blob/master/src/tcp_ledbat.c). I recall that it took a while to converge. Also I am not sure here. Is Hz in e.g a linux stack fixed. ?

I believe so. But I don't know about embedded systems etc.

Cheers



Bob




That's it. Thanks again for the draft. V useful.



Bob


On 15/10/15 06:08, Ingemar Johansson S wrote:

Hi
 
A new IETF draft is submitted in response to general discussion that for instance TCP Cubic is not an appropriate congestion control algorithm for LTE. 
The draft briefly outlines typical 4G access behavior on the PDCP, RLC and MAC  layers that can have an impact on transport protocol performance. The draft also outlines two relatively simple modifications to the Cubic congestion control.
 
/Ingemar  
 
-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: den 14 oktober 2015 20:17
To: Ingemar Johansson S
Subject: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt
 
 
A new version of I-D, draft-johansson-cc-for-4g-5g-00.txt
has been successfully submitted by Ingemar Johansson and posted to the IETF repository.
 
Name:           draft-johansson-cc-for-4g-5g
Revision:       00
Title:          Congestion control for 4G and 5G access
Document date:  2015-10-14
Group:          Individual Submission
Pages:          14
URL:            https://www.ietf.org/internet-drafts/draft-johansson-cc-for-4g-5g-00.txt
Status:         https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-5g/
Htmlized:       https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-00
 
 
Abstract:
   This memo outlines the challenge that 4G and 5G access brings for
   transport protocol congestion control and also outlines a few simple
   examples that can improve transport protocol congestion control
   performance in 4G and 5G access.
 
 
                                                                                  
 
 
Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
 
The IETF Secretariat
 




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

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------040700010104070701040704-- From nobody Wed Nov 4 17:36:49 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693DC1A8749 for ; Wed, 4 Nov 2015 17:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VokutOJeFxqn for ; Wed, 4 Nov 2015 17:36:42 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DF671A8742 for ; Wed, 4 Nov 2015 17:36:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.20,245,1444719600"; d="asc'?scan'208";a="79474068" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx141-out.netapp.com with ESMTP; 04 Nov 2015 17:36:26 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 Nov 2015 17:36:24 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::e1d9:911e:3048:d510%21]) with mapi id 15.00.1104.000; Wed, 4 Nov 2015 17:36:24 -0800 From: "Eggert, Lars" To: tcpm IETF list Thread-Topic: Papers I mentioned in the session Thread-Index: AQHRF2phJWLx4Nutr0iBYuDOFpHXJQ== Date: Thu, 5 Nov 2015 01:36:24 +0000 Message-ID: <882A2085-A336-413A-85C1-B0A926060C4F@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3096.5) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_5BF12F69-0593-43B4-ABF1-9EEB117C6AB7"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [tcpm] Papers I mentioned in the session X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 01:36:45 -0000 --Apple-Mail=_5BF12F69-0593-43B4-ABF1-9EEB117C6AB7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is the paper I mentioned in the discussion for = draft-kitamura-tcp-sharp-close: The TIME_WAIT state in TCP and Its Effect on Busy Servers http://www.isi.edu/touch/pubs/infocomm99/ This is the Ensemble-TCP paper related to RFC2140 (mentioned in the = discussion for draft-welzl-tcpm-tcb-sharing): Effects of Ensemble-TCP https://www.isi.edu/~johnh/PAPERS/Eggert00a/ Finally, this is the RTT study from IMC, mentioned when discussing = draft-nishida-tcpm-apaws: Timeouts: Beware Surprisingly High Delay = http://www.cs.umd.edu/~ramapad/docs/timeouts_imc_15_camera_ready.pdf Lars --Apple-Mail=_5BF12F69-0593-43B4-ABF1-9EEB117C6AB7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQCVAwUBVjqyl9ZcnpRveo1xAQgU3QQAiUVCEXO84Fgo/2gqhMTe65SwlX0FY8uz 8UV4/PCOkHb2vCHyReeSb9pmccvXj1zjydtHuu7011uMCip43wP0MMotFlchfBAB lp1grXFWZ6nLktHPmSZPHzfy7an6mbgGJu8/yLs/pS8cLqT7uOpr/8yl5I9myC7D WGocEGkfaGU= =+GAI -----END PGP SIGNATURE----- --Apple-Mail=_5BF12F69-0593-43B4-ABF1-9EEB117C6AB7-- From nobody Wed Nov 4 20:09:02 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA2A1A9023 for ; Wed, 4 Nov 2015 20:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3Rb7g5peVsK for ; Wed, 4 Nov 2015 20:09:00 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029741A8BB0 for ; Wed, 4 Nov 2015 20:09:00 -0800 (PST) Received: from dhcp-25-140.meeting.ietf94.jp ([133.93.25.140]:42553) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1ZuBr7-0006DX-5T for tcpm@ietf.org; Thu, 05 Nov 2015 04:08:58 +0000 From: Bob Briscoe To: tcpm IETF list References: <040D8495-90E2-4419-AA33-938BD51DF179@iki.fi> Message-ID: <563AD656.4010101@bobbriscoe.net> Date: Thu, 5 Nov 2015 04:08:54 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <040D8495-90E2-4419-AA33-938BD51DF179@iki.fi> Content-Type: multipart/alternative; boundary="------------070802030604090208000104" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [tcpm] Fwd: Re: Promises to review draft-...-tcpm-accurate-ecn X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 04:09:01 -0000 This is a multi-part message in MIME format. --------------070802030604090208000104 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit tcpm note-takers, and the list, Pls shout if I missed anyone, or if you were scratching your head rather than putting up your hand. Bob -------- Forwarded Message -------- Subject: Re: Promises to review draft-...-tcpm-accurate-ecn Date: Thu, 5 Nov 2015 10:18:40 +0900 From: Pasi Sarolahti To: Bob Briscoe CC: Mirja Kühlewind , Richard Scheffenegger , Yoshifumi Nishida , Michael Scharf Thanks, very helpful! (you could also post it to list, so people know they are tagged :-) - Pasi On 05 Nov 2015, at 10:14, Bob Briscoe wrote: > Mirja, Richard, > > I noted the following promises to review AccECN (I'll check this gets into the minutes): > > Gorry Fairhurst > Praveen Balasubramian > Koen De Schepper > Brian Trammell > Tommy Pauly > Karen Nielsen? > > Promise to test: > CableLabs guy (sorry don't know his name) > > > Bob > > > -- > ________________________________________________________________ > Bob Briscoehttp://bobbriscoe.net/ > -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/ --------------070802030604090208000104 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit tcpm note-takers, and the list,

Pls shout if I missed anyone, or if you were scratching your head rather than putting up your hand.


Bob

-------- Forwarded Message --------
Subject: Re: Promises to review draft-...-tcpm-accurate-ecn
Date: Thu, 5 Nov 2015 10:18:40 +0900
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
To: Bob Briscoe <research@bobbriscoe.net>
CC: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Richard Scheffenegger <rs@netapp.com>, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, Michael Scharf <Michael.SCHARF@alcatel-lucent.com> 


Thanks, very helpful! (you could also post it to list, so people know they are tagged :-)

- Pasi


On 05 Nov 2015, at 10:14, Bob Briscoe <research@bobbriscoe.net> wrote:

> Mirja, Richard,
> 
> I noted the following promises to review AccECN (I'll check this gets into the minutes):
> 
> Gorry Fairhurst
> Praveen Balasubramian
> Koen De Schepper
> Brian Trammell
> Tommy Pauly
> Karen Nielsen?
> 
> Promise to test:
> CableLabs guy (sorry don't know his name)
> 
> 
> Bob
> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 





-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------070802030604090208000104-- From nobody Wed Nov 4 21:13:09 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B8A1B3996 for ; Wed, 4 Nov 2015 21:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inWrVtFhPJ5j for ; Wed, 4 Nov 2015 21:12:45 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2C31B397E for ; Wed, 4 Nov 2015 21:12:39 -0800 (PST) Received: by ykek133 with SMTP id k133so113165906yke.2 for ; Wed, 04 Nov 2015 21:12:39 -0800 (PST) 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; bh=NWsihxsYalpIltSh1RtGmVBIBuel+AMbqzLUNqfTio4=; b=HZPIOFdpIGRjdjfaMLD66Y4ycc1/sBvoCYhbPmFpg/mUKdI5S+Y+khLwCPQQzB8PF6 n7hZ3tf9dMXOtpyZw02WQfVEglaHcgmwfokJr3JwlCR2UaiA0yzwfaS0DM6KYqUcTxEW FGexLPmrWwbh/z2A1vHpuTdyk+Pb3D1ia2JDkBf7z4ISKzgEXJzjcZBnE6M8d1l/0MVz t5Cx7i7ihcJdXTiGl4xJRuW0OF6OapEoEeKhuYN8mVs/M1fLfnGaldYEhoGUS61CSy/4 I0flGk3HK/uDyBbIHQMhyCgHWIA/SaG8vOrJfBFUAWpyR6/eeXlTLn96UEIr4GybBhr5 Ocsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NWsihxsYalpIltSh1RtGmVBIBuel+AMbqzLUNqfTio4=; b=ZaSgYEEwPPcn0EGcW9uZ/SnF7WxdYB35CPgDG+W7/A86oyin2yN0obNsD1et9Y1uMw 0rflo0rm6RMIkqjPJhtwFbn+urH29MqObu/aN1qtdkwFt1V9ZM2nAkIl0i6Wy4tuegzd 5+ePZKw3qKeobEGur1MLqy8FpRlIEvcyrQn6zv9UExGq26q11ZDxXO7CEPBD2Is4Fyr6 FIDn9R8tP1TmeGCsLjQX2YyXjPOLM1aF4O+v8A/pl6c5p6G9eTFTnZV0uor0Mj2jMO41 2p2u+8kRd4Non7oaX4omR73ml8g/TS0bZ/ZbJsGJgXt6OVVMIgYKJzOLNHWR7Vhdqq8A MFDg== X-Gm-Message-State: ALoCoQmhVKbsJY3Zz4mtk0i+EvlVnQfxZm6RQE6Oc9xWC8GrNekQJm53ajsg47weJt4hyuswVp8R MIME-Version: 1.0 X-Received: by 10.31.41.149 with SMTP id p143mr5170320vkp.4.1446700359011; Wed, 04 Nov 2015 21:12:39 -0800 (PST) Received: by 10.31.189.19 with HTTP; Wed, 4 Nov 2015 21:12:37 -0800 (PST) Received: by 10.31.189.19 with HTTP; Wed, 4 Nov 2015 21:12:37 -0800 (PST) In-Reply-To: <563A8635.3000400@bobbriscoe.net> References: <20151014181702.10618.83714.idtracker@ietfa.amsl.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34BF4F0F@ESESSMB205.ericsson.se> <56325D2D.1070107@bobbriscoe.net> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658@ESESSMB205.ericsson.se> <563A8635.3000400@bobbriscoe.net> Date: Thu, 5 Nov 2015 14:12:37 +0900 Message-ID: From: Yuchung Cheng To: Bob Briscoe Content-Type: multipart/alternative; boundary=001a113ee6a4fefe3f0523c42c11 Archived-At: Cc: Ingemar Johansson S , "tcpm@ietf.org Extensions" , "tsvwg@ietf.org" , "iccrg@irtf.org" Subject: Re: [tcpm] [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 05:12:52 -0000 --001a113ee6a4fefe3f0523c42c11 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have a question re: how much buffer or backlog is needed to prevent the schedular from reducing the rate or even increase the rate. I think this key why cubic or bufferbloat cc wins bc other queue controlling cc would lose out. For example if the scheduler needs 1mb backlog to maintain at 40mbps. A dctcp or vegas keeping the queue well below will get say 5mbps. The draft mentions about this but the advise is a bit vague for cc designer= . On Nov 5, 2015 7:27 AM, "Bob Briscoe" wrote: > Ingemar, > > On 04/11/15 13:27, Ingemar Johansson S wrote: > > Hi > > > > And thanks for the review, comments/answers/questions inline below > > > > /Ingemar > > > > *From:* Bob Briscoe [mailto:ietf@bobbriscoe.net ] > *Sent:* den 29 oktober 2015 18:54 > *To:* Ingemar Johansson S; iccrg@irtf.org; tcpm@ietf.org; tsvwg@ietf.org > *Subject:* Re: [tsvwg] FW: New Version Notification for > draft-johansson-cc-for-4g-5g-00.txt > > > > Ingemar, > > As promised, here's my comments. They are a mix of suggested improvements > to the draft, suggested improvements to 5G, or requests for clarification= . > I also agree with all Kevin Smith's comments, so I didn't repeat any. > [Sorry for delay - I had to find time to re-type after losing my review > during a power outage] > > > *Context questions. *Q1. Is this exercise treating the 5G specs solely in > read-only mode? Or, if some useful design suggestions arise, is there any > chance that the 3GPP might take them on board, given 5G is not fully bake= d > yet? > > [IJ] Guess it depends, need to say that I probably the small cog in the > wheel. I would say that a lot of the standards work in IETF has been pick= ed > up by 3GPP and, I cannot say what will happen in the 5G context. > > It's great that you have taken this initiative. Does the 3GPP ever > formally ask the IETF for comments on its ideas for each new generation o= f > radio? Given the layers above can be thought of as the 'customers' of the > 3GPP, and these 'customer' layers are pretty much all maintained by the > IETF, it would seem essential (and courteous) for the 3GPP to ask for > customer comment, not least to co-ordinate with whatever future plans the > IETF might have for the higher layers. > > [IJ] What you say makes much sense. I guess there is some natural leakage > between 3GPP and IETF as many of the IETFers are also active in 3GPP > standardization. I don=E2=80=99t have full insight in the formal relation= between > 3GPP and IETF in these areas, not sure if that need to be better, but if > that is the case, then it is probably a question for the area directors. > Need to say that even though the formal channels are scarce it does > probably not mean that 3GPP ignores IETF or what happens above IP in > general. For instance the recent work around TCP RACK raises the question > if it is necessary that LTE default radio bearers ensure in order deliver= y. > > I suspect that 3GPP radio resource control people do not cross-fertilize > much with the IETF. > So maybe it is as much a question of how to co-ordinate between these > radio people and L4, which I would imagine is as much a problem within 3G= PP > as between 3GPP and IETF. > > > > Q2. What are your plans for this draft? Are you asking for adoption? And > if so, in which WG or RG? ICCRG looks the most appropriate, given the > charters of all the IETF cc WGs (TSVWG, TCPM, RMCAT, etc) are scoped on > just a subset of your doc. > > [IJ] First objective is to get an increased interest in congestion contro= l > algorithm work in the IETF. Traditionally this kind of work seem to be mo= re > in the terms of conference papers in e.g. Sigcomm, the benefit with havin= g > such work in IETF is that input from people with a wider expertise area > (including 3GPP experitise) can give algorithm proposals that work well f= or > a wider set of access types. The work around Cubic is a first good step a= s > is the work around DCTCP. What I wonder is if it feasible to take this a > bit further ? I would too believe that the current doc fits better in > ICCRG. The algorithm examples are just.. examples. More fruitful work is > probably to document different access types and from there derive a set o= f > best current practices for congestion control algorithms > > I'm sure the iccrg chairs would like this to happen. And initiatives like > yours to come with proposals to propose specific code to take account of = L2 > I think generate the right level of dialogue. > > > > > *Section by Section Review * > > *All sections * > The document generally talks about the LTE protocol stack as if data is > travelling down it. Are you implying that most sources of buffering delay > are at the sending end, and the feedback end is pretty unencumbered by > delays? I think it would be useful to explicitly say something about this > (whether true or not), to explain why only one direction of travel is > discussed in the doc. > > [IJ] The feedback path is encumbered by delays, it is perhaps not that > clear but section 2.3.2 implies that delay (variation) in uplink will > affect the ACKs for downlink data traffic. That said, the difference in > DL/UL traffic is today something like 10:1 and that is probably one reaso= n > why one can get the feeling that the draft is slanted towards downlink da= ta > traffic, this may however change with time as more machine type traffic m= ay > enter the system. > > I was thinking more in terms of up the stack vs. down the stack, not > uplink/downlink. I.e. for both cases: > * downlink direction: are there any buffering concerns coming up the stac= k > at the UE, or on the feedback back-channel from the UE? > * uplink direction: are there any buffering concerns coming up the stack > at the eNodeB, or on the feedback back-channel from the eNodeB? > > For instance, in the UE, perhaps one app blocking the read of another due > to the way {3-5}G multiplexes different streams into the same PDCP frames= ? > > > > > *2.1 PDCP layer * > PDCP also ensures that all > packets are delivered in order up to higher layers. > I think this means "in the order sent into the link (PDCP) layer". This > ought to be clarified, otherwise, when writing in the context of a layer = 4 > audience, it might be assumed this means in the order sent by the origina= l > transport layer source. > > [IJ] Yes, you are right , reordering can still occur e.g. in the wireless > backhaul > > > > keep the amount of data in flight as small as possible, without > sacrificing throughput. > Is this just a rather convoluted way of saying "keep the RTT as low as > possible"? (which in turn implies keeping queuing delay as low as possibl= e > assuming you cannot influence the physical path.) Or were you trying to > make a more subtle point? - if so, it was lost on me. > > [IJ] No, it is exactly as you describe below > > > > Reliable delivery at handover may however be turned off or is simply > not implemented, > It would be useful if you could give a feel for roughly how often (in %) > these cases hold. > > [IJ] I don=E2=80=99t believe that it is possible to give a figure as this= is > vendor specific. > > > > *2.2 RLC layer* > > role ... is to ensure that packets are delivered in order up to the > higher layers > Eh? The PDCP section just said it did ordering. And the rest of the RLC > section talks exclusively about buffering delays necessary while filling > transport blocks. If ordering is the role of both layers, surely one will > have nothing to do once the other has got everything in order? > > [IJ] RLC handles ordering due to various MAC layer failures. PDCP handles > ordering when handover occurs > > > > varying size of the available transport > Nit: Given 'transport' means e2e for the audience of this draft, pls use > bearer or somehow disambiguate this word. > > [IJ] OK > > > > > Gap#1: In the draft, it seems like transport blocks arrive by magic, to b= e > filled by data buffered in the RLC layer. To understand the delay > compromises here, I think the draft needs to explain what determines how > much transport block capacity each flow is given, and how they can > influence it. In 3G, I believe that the transport layer could ask the rad= io > resource controller to change radio resource allocation. Is this the same > in 4G & 5G? Does the backlog of the buffer into the RLC layer have any > automatic influence over allocation of available resources? I assume > traffic class can also be used to influence allocation. > > [IJ] Will updated with more detail > > > > Gap#2: In a 3G stack, the RLC layer multiplexes all the active applicatio= n > streams into MAC layer transport block by dicing up buffered packets and > packing the pieces into each transport block. Then, at the other end of > the link, each piece has to be held until the rest of the packet arrives. > This sacrifices delay for bandwidth efficiency. Is this still done in 4G > and 5G? If so, it would be good to write about mux delay in the draft too= . > > [IJ] OK, will add more info > > > > > *2.3 MAC layer * > the maximum number of retransmissions is configurable > > Wouldn't it be better to set a limit on the *time* spent retransmitting, > so it would automatically give up with less retransmissions for longer > transmission distances? > [IJ] Possible, 4G specifies a limit to the number of retransmissions, in > practice it can be translated to time as each retransmission is 8ms later= . > > I didn't realise it was independent of link-RTT. Then the more basic > question is why is it independent of link-RTT? Surely on a short link it > can assume that it needs to retransmit more quickly than on a long link? > > You can see that my question was assuming that retransmission happened > more often on a short link, then I was saying it should still be allowed > the same amount of time to keep retrying (so on a short link it would be > allowed to retransmit more times before giving up, but the max delay woul= d > be the same). > > 8ms! I was assuming it would be rather much less than that. Surely a > link-layer ACK could never take that long if the frame was going to get > through. > > > > > s/only checks for the presence on download data only at regular intervals= / > /only checks for the presence of download data at regular intervals/ > [OK] > > > > > > *2.3.2 Uplink scheduling * > The scheduling request does not indicate how many bytes there are in > the uplink queue. > Seems like a bad omission. Is there a reason? If there are less bytes > queued than the base station's grant, surely it would be useful for the > base station to know, so that it can grant more to something else while t= he > previous short transmission is completing. > [IJ] It is a design choice. A buffer status report is more bulky, a > scheduling request is just one bit. > > > > > You say that when HARQ breaks up a sequence of ACKs, it can also trigger > "coalescing issues". I can understand that it could cause ACK > compression, but are you implying something coalesces the ACKs or the > subsequent data? What does the coalescing? Similarly, in the last para of > 2.3.2 you say "Reduced ACKs can unfortunately cause coalescing." and agai= n > I'm not sure what is coalescing what here. > > [IJ] What I can see in simulations is that the ACK compression leads to > coalescing which further can increase jitter. > > I still don't understand. The question was "What is coalescing what?" > > > There could be a positive side to the interaction between ACK clocking an= d > link aggregation, at least for long-running flows. This has been observed > in 802.11n WiFi where the buffering and aggregation of multiple ACKs into > one transmission grant tend to lead the sender to bunch multiple data > segments so that they all nicely fill one transmission grant in the other > direction [Showail14]. As long as the transmission grant does not wait > for more data (which unfortunately I don't think is the case in 3G/4G/5G)= , > this could be good for bandwidth utilisation of elephants and latency of > mice, including when they are mixed. > > [Showail14] Showail, A., Jamshaid, K. & Shihada, B., "WQM: An > Aggregation-aware Queue Management Scheme for IEEE 802.11N Based Networks= ," > In: Proceedings of the 2014 ACM SIGCOMM Workshop on Capacity Sharing > Workshop CSWS '14 pp.15-20 ACM (2014) > > [IJ] Interesting ,will look at it, not sure though that it will work that > well with 4G (cant say anything about 5G), in 4G the transmission grants > can vary quite a lot over short time spans. > > > > > > *3. 4G and 5G evolution * > s/a explicit/an explicit/ > > > *4. Requirements for improved performance * > s/bufferbloat/buffer/ > > > *5. Congestion control examples * > Regarding Hybrid Cubic using OWD measurements, I have seen a paper (under > submission) about getting delay-based congestion controls (e.g. LEDBAT or > CAIA Delay Gradient) to interwork with AQMs with various low delay target= s. > It's not in the context of cellular networks, but I'll try to remember to > point it out once it gets published. > > [IJ] Sounds interesting , looking forward to see the paper. > > > > > *5.1 HyStartRestart * > s/algorithm used/algorithm is used/ > > In the new code, it would be useful to explain why the second test before > doubling ssthresh, ie, the test for how long it has been since the last > hyrestart. Also, in the header definitions, if you intend there to be > constraints on the relation between N_RTT_HYRESTART and N_RTT_LOW (e.g. > N_RTT_HYRESTART > N_RTT_LOW) you ought to say, because people will try > other values. > > Rather than the rather arbitrary wait before an arbitrary doubling of > ssthresh, wouldn't it be better to continually increase ssthresh (not > necessarily linearly) the longer the RTT has remained only just higher th= an > the min RTT? > > [IJ] Yes, could be an option > > > > (BTW, surely the main problem with this modification to HyStartRestart is > that is requires a number of round trips to reduce delay - a sort-of > oxymoron.) > > [IJ] Yes, have tried some more experiments with this algorithm. And I am > getting more hesitant. The problem is that when I add more noise (modelin= g > of small objects traffic) into the system simulation, then I also get mor= e > delay jitter and the delay detection algorithm in HyStart is notoriously > sensitive to delay jitter. > > > > *5.2. Hybrid Cubic* > > Furthermore it is assumed than the timestamp clock frequency in > > sender and receiver are identical or that the sender can infer the > > timestamp clock frequency of the receiver and recompute timestamp > > values based on this information. > > Recently on tcpm I sent you a pointer to the chirping paper Mirja & I did= , > which also made this assumption. Partly prompted by that, Richard > Scheffenegger tried to get people interested in standardising use of the > timestamp option on a SYN to negotiate stuff like timer resolution. I don= 't > think it went anywhere. Do you think we ought to revitalise that? You > mention inference - have you tried that - are there cases where it doesn'= t > work? > > [IJ] Yes, actually wondered what happened to Richards draft. I only > briefly tried out the inference algorithm with a TCP LEDBAT implementatio= n ( > https://github.com/silviov/TCP-LEDBAT/blob/master/src/tcp_ledbat.c). I > recall that it took a while to converge. Also I am not sure here. Is Hz i= n > e.g a linux stack fixed. ? > > I believe so. But I don't know about embedded systems etc. > > Cheers > > > > Bob > > > > > That's it. Thanks again for the draft. V useful. > > > > Bob > > > On 15/10/15 06:08, Ingemar Johansson S wrote: > > Hi > > > > A new IETF draft is submitted in response to general discussion that for = instance TCP Cubic is not an appropriate congestion control algorithm for L= TE. > > The draft briefly outlines typical 4G access behavior on the PDCP, RLC an= d MAC layers that can have an impact on transport protocol performance. Th= e draft also outlines two relatively simple modifications to the Cubic cong= estion control. > > > > /Ingemar > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org ] > > Sent: den 14 oktober 2015 20:17 > > To: Ingemar Johansson S > > Subject: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt > > > > > > A new version of I-D, draft-johansson-cc-for-4g-5g-00.txt > > has been successfully submitted by Ingemar Johansson and posted to the IE= TF repository. > > > > Name: draft-johansson-cc-for-4g-5g > > Revision: 00 > > Title: Congestion control for 4G and 5G access > > Document date: 2015-10-14 > > Group: Individual Submission > > Pages: 14 > > URL: https://www.ietf.org/internet-drafts/draft-johansson-cc-f= or-4g-5g-00.txt > > Status: https://datatracker.ietf.org/doc/draft-johansson-cc-for-4= g-5g/ > > Htmlized: https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-= 00 > > > > > > Abstract: > > This memo outlines the challenge that 4G and 5G access brings for > > transport protocol congestion control and also outlines a few simple > > examples that can improve transport protocol congestion control > > performance in 4G and 5G access. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --001a113ee6a4fefe3f0523c42c11 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have a question re: how much buffer or backlog is needed t= o prevent the schedular from reducing the rate or even increase the rate. I= think this key why cubic or bufferbloat cc wins bc other queue controlling= cc would lose out.

For example if the scheduler needs 1mb backlog to maintain a= t 40mbps. A dctcp or vegas keeping the queue well below will get say 5mbps.=

The draft mentions about this but the advise is a bit vague = for cc designer.

On Nov 5, 2015 7:27 AM, "Bob Briscoe" = <ietf@bobbriscoe.net> wrot= e:
=20 =20 =20
Ingemar,

On 04/11/15 13:27, Ingemar Johansson S wrote:
=20 =20 =20

Hi=

=C2=A0

An= d thanks for the review, comments/answers/questions inline below

=C2=A0

/I= ngemar

=C2=A0

From: Bob= Briscoe [mailto:i= etf@bobbriscoe.net]
Sent: den 29 oktober 2015 18:54
To: Ingemar Johansson S; iccrg@irtf.org; tcpm@i= etf.org; tsvwg@ietf= .org
Subject: Re: [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt

=C2=A0

Ingemar,
As promised, here's my comments. They are a mix of suggeste= d improvements to the draft, suggested improvements to 5G, or requests for clarification. I also agree with all Kevin Smith's comments, so I didn't repeat any.
[Sorry for delay - I had to find time to re-type after losing my review during a power outage]

Context questions.
Q1. Is this exercise treating the 5G specs solely in read-only mode? Or, if some useful design suggestions arise, is there any chance that the 3GPP might take them on board, given 5G is not fully baked yet?<= u>

[IJ] Guess it depends, need to say that I probably the small cog in the wheel. I would say that a lot of the standards work in IETF has been picked up by 3GPP and, I cannot say what will happen in the 5G context.

It's great that you have taken this initiative. Do= es the 3GPP ever formally ask the IETF for comments on its ideas for each new generation of radio? Given the layers above can be thought of as the 'customers' of the 3GPP,= and these 'customer' layers are pretty much all maintained = by the IETF, it would seem essential (and courteous) for the 3GPP to ask for customer comment, not least to co-ordinate with whatever future plans the IETF might have for the higher layers.

[IJ] What you say makes much sense. I guess there is some natural leakage between 3GPP and IETF as many of the IETFers are also active in 3GPP standardization. I don=E2=80=99t have full insight in the for= mal relation between 3GPP and IETF in these areas, not sure if that need to be better, but if that is the case, then it is probably a question for the area directors. Need to say that even though the formal channels are scarce it does probably not mean that 3GPP ignores IETF or what happens above IP in general. For instance the recent work around TCP RACK raises the question if it is necessary that LTE default radio bearers ensure in order delivery.

I suspect that 3GPP radio resource control people do not cross-fertilize much with the IETF.
So maybe it is as much a question of how to co-ordinate between these radio people and L4, which I would imagine is as much a problem within 3GPP as between 3GPP and IETF.



Q2. What are your plans for this draft? Are you asking for adoption? And if so, in which WG or RG? ICCRG looks the most appropriate, given the charters of all the IETF cc WGs (TSVWG, TCPM, RMCAT, etc) are scoped on just a subset of your doc.=

[IJ] First objective is to get an increased interest in congestion control algorithm work in the IETF. Traditionally this kind of work seem to be more in the terms of conference papers in e.g. Sigcomm, the benefit with having such work in IETF is that input from people with a wider expertise area (including 3GPP experitise) can give algorithm proposals that work well for a wider set of access types. The work around Cubic is a first good step as is the work around DCTCP. What I wonder is if it feasible to take this a bit further ? I would too believe that the current doc fits better in ICCRG.=C2=A0 The algorith= m examples are just.. examples. More fruitful work is probably to document different access types and from there derive a set of best current practices for congestion control algorithms

I'm sure the iccrg chairs would like this to happen. And initiative= s like yours to come with proposals to propose specific code to take account of L2 I think generate the right level of dialogue.



Section by Section Review

All sections

The document generally talks about the LTE protocol stack as if data is travelling down it. Are you implying that most sources of buffering delay are at the sending end, and the feedback end is pretty unencumbered by delays? I think it would be useful to explicitly say something about this (whether true or not), to explain why only one direction of travel is discussed in the doc.

[IJ] The feedback path is encumbered by delays, it is perhaps not that clear but section 2.3.2 implies that delay (variation) in uplink will affect the ACKs for downlink data traffic. That said, the difference in DL/UL traffic is today something like 10:1 and that is probably one reason why one can get the feeling that the draft is slanted towards downlink data traffic, this may however change with time as more machine type traffic may enter the system.

I was thinking more in terms of up the stack vs. down the stack, not uplink/downlink. I.e. for both cases:
* downlink direction: are there any buffering concerns coming up the stack at the UE, or on the feedback back-channel from the UE?
* uplink direction: are there any buffering concerns coming up the stack at the eNodeB, or on the feedback back-channel from the eNodeB?

For instance, in the UE, perhaps one app blocking the read of another due to the way {3-5}G multiplexes different streams into the same PDCP frames?



2.1 PDCP layer

=C2=A0=C2=A0=C2=A0 PDCP also ensures that all
=C2=A0=C2=A0 packets are delivered in order up to higher = layers.
I think this means "in the order sent into the link (PDCP) layer". This ought to be clarified, otherwise, when writing in the context of a layer 4 audience, it might be assumed this means in the order sent by the original transport layer source.

[IJ] Yes, you are right , reordering can still occur e.g. in the wireless backhaul



=C2= =A0=C2=A0 keep the amount of data in flight as small as possible, without sacrificing throughput.
Is this just a rather convoluted way of saying "kee= p the RTT as low as possible"? (which in turn implies keepin= g queuing delay as low as possible assuming you cannot influence the physical path.) Or were you trying to make a more subtle point? - if so, it was lost on me.

[IJ] No, it is exactly as you describe below=



=C2= =A0=C2=A0 Reliable delivery at handover may however be turned off or is simply not implemented,
It would be useful if you could give a feel for roughly how often (in %) these cases hold.

[IJ] I don=E2=80=99t believe that it is poss= ible to give a figure as this is vendor specific.



2.2 RLC layer

=C2= =A0=C2=A0 role ... is to ensure that packets are delivered in order up to the higher layers
Eh? The PDCP section just said it did ordering. And the rest of the RLC section talks exclusively about buffering delays necessary while filling transport blocks. If ordering is the role of both layers, surely one will have nothing to do once the other has got everything in order?

[IJ] RLC handles ordering due to various MAC layer failures. PDCP handles ordering =C2=A0when handover occurs



=C2= =A0=C2=A0 varying size of the available transport
Nit: Given 'transport' mean= s e2e for the audience of this draft, pls use bearer or somehow disambiguate this word.

[IJ] OK




Gap#1: In the draft, it seems like transport blocks arrive by magic, to be filled by data buffered in the RLC layer. To understand the delay compromises here, I think the draft needs to explain what determines how much transport block capacity each flow is given, and how they can influence it. In 3G, I believe that the transport layer could ask the radio resource controller to change radio resource allocation. Is this the same in 4G & 5G? Does the backlog of the buffer into the RLC layer have any automatic influence over allocation of available resources? I assume traffic class can also be used to influence allocation.<= /p>

[IJ] Will updated with more detail=



Gap#2: In a 3G stack, the RLC layer multiplexes all the active application streams into MAC layer transport block by dicing up buffered packets and packing the pieces into each transport block. Then, at the other end of the link, each piece has to be held until the rest of the packet arrives. This sacrifices delay for bandwidth efficiency. Is this still done in 4G and 5G? If so, it would be good to write about mux delay in the draft too.

[IJ] OK, will add more info



2.3 MAC layer

=C2= =A0=C2=A0 the maximum number of retransmissions is configurable

Wouldn't it be better to set a limit on the time spent retransmitting, so it would automatically give up with less retransmissions for longer transmission distances?
[IJ] Possible, 4G specifies a limit to the number of retransmissions, in practice it can be translated to time as each retransmission is 8ms later.

I didn't realise it was independent of link-RTT. Then the more basi= c question is why is it independent of link-RTT? Surely on a short link it can assume that it needs to retransmit more quickly than on a long link?

You can see that my question was assuming that retransmission happened more often on a short link, then I was saying it should still be allowed the same amount of time to keep retrying (so on a short link it would be allowed to retransmit more times before giving up, but the max delay would be the same).

8ms! I was assuming it would be rather much less than that. Surely a link-layer ACK could never take that long if the frame was going to get through.

=C2=A0


s/only checks for the presence on download data only at regular intervals/
=C2=A0/only checks for the presence of download data at regul= ar intervals/
[OK]=

=C2=A0


2.3.2 Uplink scheduling

=C2= =A0=C2=A0 The scheduling request does not indicate how many bytes there are in the uplink queue.
Seems like a bad omission. Is there a reason? If there are less bytes queued than the base station's grant, surely it would be useful for the base station to know, so that it can grant more to something else while the previous short transmission is completing.
[IJ] It is a desig= n choice. A buffer status report is more bulky, a scheduling request is just one bit.

=C2=A0


You say that when HARQ breaks up a sequence of ACKs, it can also trigger "coalescing issues". I can understand that it could cause ACK compression, but are you implying something coalesces the ACKs or the subsequent data? What does the coalescing? Similarly, in the last para of 2.3.2 you say "Reduced ACKs can unfortunately cause coalescing.&qu= ot; and again I'm not sure what is coalescing what here.

[IJ] What I can see in simulations is that the ACK compression leads to coalescing which further can increase jitter.

I still don't understand. The question was "What is coalescing what?"


There could be a positive side to the interaction between ACK clocking and link aggregation, at least for long-running flows. This has been observed in 802.11n WiFi where the buffering and aggregation of multiple ACKs into one transmission grant tend to lead the sender to bunch multiple data segments so that they all nicely fill one transmission grant in the other direction [Showail14]. = As long as the transmission grant does not wait for more data (which unfortunately I don't think is the case in 3G/4G/5G), this could be good for bandwidth utilisation of elephants and latency of mice, including when they are mixed.

[Showail14] Showail, A., Jamshaid, K. & Shihada, B., "WQM: An Aggregation-aware Queue Management Scheme for IEEE 802.11N Based Networks," In: Proceedings of the 201= 4 ACM SIGCOMM Workshop on Capacity Sharing Workshop CSWS '1= 4 pp.15-20 ACM (2014)
<http://dl.acm.org/citation.cfm= ?id=3D2630097>
[IJ] Interesting ,will look at it, not sure though that it will work that well with 4G (cant say anything about 5G), in 4G the transmission grants can vary quite a lot over short time spans.

=C2=A0


3.=C2=A0 4G and 5G evolution

s/a explicit/an explicit/

4.=C2=A0 Requirements for improved performance

s/bufferbloat/buffer/

5.=C2=A0 Congestion control examples

Regarding Hybrid Cubic using OWD measurements, I have seen a paper (under submission) about getting delay-based congestion controls (e.g. LEDBAT or CAIA Delay Gradient) to interwork with AQMs with various low delay targets. It's no= t in the context of cellular networks, but I'll try to remember to point it out once it gets published.

[IJ] Sounds interesting , looking forward to see the paper.



5.1 HyStartRestart

s/algorithm used/algorithm is used/

In the new code, it would be useful to explain why the second test before doubling ssthresh, ie, the test for how long it has been since the last hyrestart. Also, in the header definitions, if you intend there to be constraints on the relation between N_RTT_HYRESTART and N_RTT_LOW (e.g.=C2=A0 N_RTT_HYRESTART > N_RTT_LOW) you ought to say, because people will try other values.

Rather than the rather arbitrary wait before an arbitrary doubling of ssthresh, wouldn't it be better to continually increase ssthresh (not necessarily linearly) the longer the RTT has remained only just higher than the min RTT?

[IJ] Yes, could be an option



(BTW, surely the main problem with this modification to HyStartRestart is that is requires a number of round trips to reduce delay - a sort-of oxymoron.)

[IJ] Yes, have tried some more experiments with this algorithm. And I am getting more hesitant. The problem is that when I add more noise (modeling of small objects traffic) into the system simulation, then I also get more delay jitter and the delay detection algorithm in HyStart is notoriously sensitive to delay jitter.



5.2.=C2=A0 Hybrid Cubic

=C2=A0=C2=A0 Furthermore it is assumed than the timestamp cl=
ock frequency in
=C2=A0=C2=A0 sender and receiver are identical or that the s=
ender can infer the
=C2=A0=C2=A0 timestamp clock frequency of the receiver and r=
ecompute timestamp
=C2=A0=C2=A0 values based on this information.=

Recently on tcpm I sent you a pointer to the chirping paper Mirja & I did, which also made this assumption. Partly prompted by that, Richard Scheffenegger tried to get people interested in standardising use of the timestamp option on a SYN to negotiate stuff like timer resolution. I don't think it wen= t anywhere. Do you think we ought to revitalise that? You mention inference - have you tried that - are there cases where it doesn't work?=

[IJ] Yes, actually wondered what happened to Richards draft. I only briefly tried out the inference algorithm with a TCP LEDBAT implementation (https://github.com/silviov/TCP-LEDBAT/b= lob/master/src/tcp_ledbat.c). I recall that it took a while to converge. Also I am not sure here. Is Hz in e.g a linux stack fixed. ?

I believe so. But I don't know about embedded systems etc.

Cheers



Bob




That's it. Thanks again for the draft. V useful.



Bob


On 15/10/15 06:08, Ingemar Johansson S wrote:

Hi
=C2=A0
A new IETF draft is submitted in response to general discu=
ssion that for instance TCP Cubic is not an appropriate congestion control =
algorithm for LTE. 
The draft briefly outlines typical 4G access behavior on t=
he PDCP, RLC and MAC=C2=A0 layers that can have an impact on transport prot=
ocol performance. The draft also outlines two relatively simple modificatio=
ns to the Cubic congestion control.
=C2=A0
/Ingemar=C2=A0 
=C2=A0
-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: den 14 oktober 2015 20:17
To: Ingemar Johansson S
Subject: New Version Notification for draft-johansson-cc-f=
or-4g-5g-00.txt
=C2=A0
=C2=A0
A new version of I-D, draft-johansson-cc-for-4g-5g-00.txt<=
u>
has been successfully submitted by Ingemar Johansson and p=
osted to the IETF repository.
=C2=A0
Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 draft-johansson-cc-for-4g-5g
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00=

Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Congestion control for 4G and 5G access
Document date:=C2=A0 2015-10-14
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Individual Submission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 14
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 https://www.ietf.org/internet-draf=
ts/draft-johansson-cc-for-4g-5g-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-=
5g/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-00
=C2=A0
=C2=A0
Abstract:
=C2=A0=C2=A0 This memo outlines the challenge that 4G and =
5G access brings for
=C2=A0=C2=A0 transport protocol congestion control and als=
o outlines a few simple
=C2=A0=C2=A0 examples that can improve transport protocol =
congestion control
=C2=A0=C2=A0 performance in 4G and 5G access.
=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
=C2=A0
=C2=A0
Please note that it may take a couple of minutes from the =
time of submission until the htmlized version and diff are available at tools.ietf.org.=

=C2=A0
The IETF Secretariat
=C2=A0




-- 
____________________________________________________________=
____
Bob Briscoe=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://bobbriscoe.net/

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--001a113ee6a4fefe3f0523c42c11-- From nobody Wed Nov 4 21:26:50 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D6D1B39AC for ; Wed, 4 Nov 2015 21:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-nE9GKGf-He for ; Wed, 4 Nov 2015 21:26:42 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9134C1B39A5 for ; Wed, 4 Nov 2015 21:26:41 -0800 (PST) Received: by ykek133 with SMTP id k133so113538067yke.2 for ; Wed, 04 Nov 2015 21:26:41 -0800 (PST) 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; bh=937eR3wdR5NtftmDAiJukiOayEafXo6NR668CVQfM5k=; b=PpByRcO30tIYQVJ3k+T5aCk57DUgI5bAYexkkJHjPe7x2N/CluDyS7O5UQVnyvYnfh +QXkpXyZVqrHDRJnE9PYBPQ5lZYAcMofZ7cZyjdyw2UtAzgyiCr54OrR6gUdaftNeRpu BIXP7UTAB5FcRiw2WCCaO4GILQSRoZ1Mmt1aLjUOqro764IYeVWrGKUK8rmhMvoWXCVY 44N7bW//eRErQXtydfup8R9SWylgHXzFEo7+Z/of7ASz+AFwb3SbBbMcWpaLRAKLfjmd V73qu8W5fxitdr9qODpQUdPjPAl3OR6FEDnVG4+Vurd+vYETyLGuvwhNlBEx+9mYhP4w g4Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=937eR3wdR5NtftmDAiJukiOayEafXo6NR668CVQfM5k=; b=fxMyOUsYXjrHH6oOdLNCBoxSst5t9LSvUTYgBAFw62bRWLCQpOT7A+lKN2iFF/74Z4 vyoa802Bfi16XNc0JGZzqj3lc+ZvHgbhw6rwa4jktbwdaHtbfOtbU7MbJRa21HybFn9W CCVl1sksSBbuYfQUqX7x6+a2E+DF7X4Q3dQlLXRyCjMcJHEk058KkcJla8xrc+3xmKb9 VUjBEfNLCVH46mmNfCA1IC3+H6AQan1aUxaciBa04FF7HdoWEcaqFcDPk/lb6ECtSda0 wo2g1DUnq3JUCceVo5q8dV4YGwTAcFUlvTWp0ckhj4RcvYlV9jCkn6AUYSVhNLNlnaKV NWOQ== X-Gm-Message-State: ALoCoQkL6ei+hnpSQNJF7B4iRQNg1tPyGekD2QflM3EAORfnA8XqTcXdK+Q4suHJTewqEAs6lXpZ MIME-Version: 1.0 X-Received: by 10.31.16.24 with SMTP id g24mr3788266vki.158.1446701200811; Wed, 04 Nov 2015 21:26:40 -0800 (PST) Received: by 10.31.189.19 with HTTP; Wed, 4 Nov 2015 21:26:40 -0800 (PST) Received: by 10.31.189.19 with HTTP; Wed, 4 Nov 2015 21:26:40 -0800 (PST) In-Reply-To: <563A8635.3000400@bobbriscoe.net> References: <20151014181702.10618.83714.idtracker@ietfa.amsl.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34BF4F0F@ESESSMB205.ericsson.se> <56325D2D.1070107@bobbriscoe.net> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658@ESESSMB205.ericsson.se> <563A8635.3000400@bobbriscoe.net> Date: Thu, 5 Nov 2015 14:26:40 +0900 Message-ID: From: Yuchung Cheng To: Bob Briscoe Content-Type: multipart/alternative; boundary=001a114302422be62b0523c45f83 Archived-At: Cc: Ingemar Johansson S , "tcpm@ietf.org Extensions" , "tsvwg@ietf.org" , "iccrg@irtf.org" Subject: Re: [tcpm] [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 05:26:47 -0000 --001a114302422be62b0523c45f83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also support this doc to be adopted by iccrg or tsvwg On Nov 5, 2015 7:27 AM, "Bob Briscoe" wrote: > Ingemar, > > On 04/11/15 13:27, Ingemar Johansson S wrote: > > Hi > > > > And thanks for the review, comments/answers/questions inline below > > > > /Ingemar > > > > *From:* Bob Briscoe [mailto:ietf@bobbriscoe.net ] > *Sent:* den 29 oktober 2015 18:54 > *To:* Ingemar Johansson S; iccrg@irtf.org; tcpm@ietf.org; tsvwg@ietf.org > *Subject:* Re: [tsvwg] FW: New Version Notification for > draft-johansson-cc-for-4g-5g-00.txt > > > > Ingemar, > > As promised, here's my comments. They are a mix of suggested improvements > to the draft, suggested improvements to 5G, or requests for clarification= . > I also agree with all Kevin Smith's comments, so I didn't repeat any. > [Sorry for delay - I had to find time to re-type after losing my review > during a power outage] > > > *Context questions. *Q1. Is this exercise treating the 5G specs solely in > read-only mode? Or, if some useful design suggestions arise, is there any > chance that the 3GPP might take them on board, given 5G is not fully bake= d > yet? > > [IJ] Guess it depends, need to say that I probably the small cog in the > wheel. I would say that a lot of the standards work in IETF has been pick= ed > up by 3GPP and, I cannot say what will happen in the 5G context. > > It's great that you have taken this initiative. Does the 3GPP ever > formally ask the IETF for comments on its ideas for each new generation o= f > radio? Given the layers above can be thought of as the 'customers' of the > 3GPP, and these 'customer' layers are pretty much all maintained by the > IETF, it would seem essential (and courteous) for the 3GPP to ask for > customer comment, not least to co-ordinate with whatever future plans the > IETF might have for the higher layers. > > [IJ] What you say makes much sense. I guess there is some natural leakage > between 3GPP and IETF as many of the IETFers are also active in 3GPP > standardization. I don=E2=80=99t have full insight in the formal relation= between > 3GPP and IETF in these areas, not sure if that need to be better, but if > that is the case, then it is probably a question for the area directors. > Need to say that even though the formal channels are scarce it does > probably not mean that 3GPP ignores IETF or what happens above IP in > general. For instance the recent work around TCP RACK raises the question > if it is necessary that LTE default radio bearers ensure in order deliver= y. > > I suspect that 3GPP radio resource control people do not cross-fertilize > much with the IETF. > So maybe it is as much a question of how to co-ordinate between these > radio people and L4, which I would imagine is as much a problem within 3G= PP > as between 3GPP and IETF. > > > > Q2. What are your plans for this draft? Are you asking for adoption? And > if so, in which WG or RG? ICCRG looks the most appropriate, given the > charters of all the IETF cc WGs (TSVWG, TCPM, RMCAT, etc) are scoped on > just a subset of your doc. > > [IJ] First objective is to get an increased interest in congestion contro= l > algorithm work in the IETF. Traditionally this kind of work seem to be mo= re > in the terms of conference papers in e.g. Sigcomm, the benefit with havin= g > such work in IETF is that input from people with a wider expertise area > (including 3GPP experitise) can give algorithm proposals that work well f= or > a wider set of access types. The work around Cubic is a first good step a= s > is the work around DCTCP. What I wonder is if it feasible to take this a > bit further ? I would too believe that the current doc fits better in > ICCRG. The algorithm examples are just.. examples. More fruitful work is > probably to document different access types and from there derive a set o= f > best current practices for congestion control algorithms > > I'm sure the iccrg chairs would like this to happen. And initiatives like > yours to come with proposals to propose specific code to take account of = L2 > I think generate the right level of dialogue. > > > > > *Section by Section Review * > > *All sections * > The document generally talks about the LTE protocol stack as if data is > travelling down it. Are you implying that most sources of buffering delay > are at the sending end, and the feedback end is pretty unencumbered by > delays? I think it would be useful to explicitly say something about this > (whether true or not), to explain why only one direction of travel is > discussed in the doc. > > [IJ] The feedback path is encumbered by delays, it is perhaps not that > clear but section 2.3.2 implies that delay (variation) in uplink will > affect the ACKs for downlink data traffic. That said, the difference in > DL/UL traffic is today something like 10:1 and that is probably one reaso= n > why one can get the feeling that the draft is slanted towards downlink da= ta > traffic, this may however change with time as more machine type traffic m= ay > enter the system. > > I was thinking more in terms of up the stack vs. down the stack, not > uplink/downlink. I.e. for both cases: > * downlink direction: are there any buffering concerns coming up the stac= k > at the UE, or on the feedback back-channel from the UE? > * uplink direction: are there any buffering concerns coming up the stack > at the eNodeB, or on the feedback back-channel from the eNodeB? > > For instance, in the UE, perhaps one app blocking the read of another due > to the way {3-5}G multiplexes different streams into the same PDCP frames= ? > > > > > *2.1 PDCP layer * > PDCP also ensures that all > packets are delivered in order up to higher layers. > I think this means "in the order sent into the link (PDCP) layer". This > ought to be clarified, otherwise, when writing in the context of a layer = 4 > audience, it might be assumed this means in the order sent by the origina= l > transport layer source. > > [IJ] Yes, you are right , reordering can still occur e.g. in the wireless > backhaul > > > > keep the amount of data in flight as small as possible, without > sacrificing throughput. > Is this just a rather convoluted way of saying "keep the RTT as low as > possible"? (which in turn implies keeping queuing delay as low as possibl= e > assuming you cannot influence the physical path.) Or were you trying to > make a more subtle point? - if so, it was lost on me. > > [IJ] No, it is exactly as you describe below > > > > Reliable delivery at handover may however be turned off or is simply > not implemented, > It would be useful if you could give a feel for roughly how often (in %) > these cases hold. > > [IJ] I don=E2=80=99t believe that it is possible to give a figure as this= is > vendor specific. > > > > *2.2 RLC layer* > > role ... is to ensure that packets are delivered in order up to the > higher layers > Eh? The PDCP section just said it did ordering. And the rest of the RLC > section talks exclusively about buffering delays necessary while filling > transport blocks. If ordering is the role of both layers, surely one will > have nothing to do once the other has got everything in order? > > [IJ] RLC handles ordering due to various MAC layer failures. PDCP handles > ordering when handover occurs > > > > varying size of the available transport > Nit: Given 'transport' means e2e for the audience of this draft, pls use > bearer or somehow disambiguate this word. > > [IJ] OK > > > > > Gap#1: In the draft, it seems like transport blocks arrive by magic, to b= e > filled by data buffered in the RLC layer. To understand the delay > compromises here, I think the draft needs to explain what determines how > much transport block capacity each flow is given, and how they can > influence it. In 3G, I believe that the transport layer could ask the rad= io > resource controller to change radio resource allocation. Is this the same > in 4G & 5G? Does the backlog of the buffer into the RLC layer have any > automatic influence over allocation of available resources? I assume > traffic class can also be used to influence allocation. > > [IJ] Will updated with more detail > > > > Gap#2: In a 3G stack, the RLC layer multiplexes all the active applicatio= n > streams into MAC layer transport block by dicing up buffered packets and > packing the pieces into each transport block. Then, at the other end of > the link, each piece has to be held until the rest of the packet arrives. > This sacrifices delay for bandwidth efficiency. Is this still done in 4G > and 5G? If so, it would be good to write about mux delay in the draft too= . > > [IJ] OK, will add more info > > > > > *2.3 MAC layer * > the maximum number of retransmissions is configurable > > Wouldn't it be better to set a limit on the *time* spent retransmitting, > so it would automatically give up with less retransmissions for longer > transmission distances? > [IJ] Possible, 4G specifies a limit to the number of retransmissions, in > practice it can be translated to time as each retransmission is 8ms later= . > > I didn't realise it was independent of link-RTT. Then the more basic > question is why is it independent of link-RTT? Surely on a short link it > can assume that it needs to retransmit more quickly than on a long link? > > You can see that my question was assuming that retransmission happened > more often on a short link, then I was saying it should still be allowed > the same amount of time to keep retrying (so on a short link it would be > allowed to retransmit more times before giving up, but the max delay woul= d > be the same). > > 8ms! I was assuming it would be rather much less than that. Surely a > link-layer ACK could never take that long if the frame was going to get > through. > > > > > s/only checks for the presence on download data only at regular intervals= / > /only checks for the presence of download data at regular intervals/ > [OK] > > > > > > *2.3.2 Uplink scheduling * > The scheduling request does not indicate how many bytes there are in > the uplink queue. > Seems like a bad omission. Is there a reason? If there are less bytes > queued than the base station's grant, surely it would be useful for the > base station to know, so that it can grant more to something else while t= he > previous short transmission is completing. > [IJ] It is a design choice. A buffer status report is more bulky, a > scheduling request is just one bit. > > > > > You say that when HARQ breaks up a sequence of ACKs, it can also trigger > "coalescing issues". I can understand that it could cause ACK > compression, but are you implying something coalesces the ACKs or the > subsequent data? What does the coalescing? Similarly, in the last para of > 2.3.2 you say "Reduced ACKs can unfortunately cause coalescing." and agai= n > I'm not sure what is coalescing what here. > > [IJ] What I can see in simulations is that the ACK compression leads to > coalescing which further can increase jitter. > > I still don't understand. The question was "What is coalescing what?" > > > There could be a positive side to the interaction between ACK clocking an= d > link aggregation, at least for long-running flows. This has been observed > in 802.11n WiFi where the buffering and aggregation of multiple ACKs into > one transmission grant tend to lead the sender to bunch multiple data > segments so that they all nicely fill one transmission grant in the other > direction [Showail14]. As long as the transmission grant does not wait > for more data (which unfortunately I don't think is the case in 3G/4G/5G)= , > this could be good for bandwidth utilisation of elephants and latency of > mice, including when they are mixed. > > [Showail14] Showail, A., Jamshaid, K. & Shihada, B., "WQM: An > Aggregation-aware Queue Management Scheme for IEEE 802.11N Based Networks= ," > In: Proceedings of the 2014 ACM SIGCOMM Workshop on Capacity Sharing > Workshop CSWS '14 pp.15-20 ACM (2014) > > [IJ] Interesting ,will look at it, not sure though that it will work that > well with 4G (cant say anything about 5G), in 4G the transmission grants > can vary quite a lot over short time spans. > > > > > > *3. 4G and 5G evolution * > s/a explicit/an explicit/ > > > *4. Requirements for improved performance * > s/bufferbloat/buffer/ > > > *5. Congestion control examples * > Regarding Hybrid Cubic using OWD measurements, I have seen a paper (under > submission) about getting delay-based congestion controls (e.g. LEDBAT or > CAIA Delay Gradient) to interwork with AQMs with various low delay target= s. > It's not in the context of cellular networks, but I'll try to remember to > point it out once it gets published. > > [IJ] Sounds interesting , looking forward to see the paper. > > > > > *5.1 HyStartRestart * > s/algorithm used/algorithm is used/ > > In the new code, it would be useful to explain why the second test before > doubling ssthresh, ie, the test for how long it has been since the last > hyrestart. Also, in the header definitions, if you intend there to be > constraints on the relation between N_RTT_HYRESTART and N_RTT_LOW (e.g. > N_RTT_HYRESTART > N_RTT_LOW) you ought to say, because people will try > other values. > > Rather than the rather arbitrary wait before an arbitrary doubling of > ssthresh, wouldn't it be better to continually increase ssthresh (not > necessarily linearly) the longer the RTT has remained only just higher th= an > the min RTT? > > [IJ] Yes, could be an option > > > > (BTW, surely the main problem with this modification to HyStartRestart is > that is requires a number of round trips to reduce delay - a sort-of > oxymoron.) > > [IJ] Yes, have tried some more experiments with this algorithm. And I am > getting more hesitant. The problem is that when I add more noise (modelin= g > of small objects traffic) into the system simulation, then I also get mor= e > delay jitter and the delay detection algorithm in HyStart is notoriously > sensitive to delay jitter. > > > > *5.2. Hybrid Cubic* > > Furthermore it is assumed than the timestamp clock frequency in > > sender and receiver are identical or that the sender can infer the > > timestamp clock frequency of the receiver and recompute timestamp > > values based on this information. > > Recently on tcpm I sent you a pointer to the chirping paper Mirja & I did= , > which also made this assumption. Partly prompted by that, Richard > Scheffenegger tried to get people interested in standardising use of the > timestamp option on a SYN to negotiate stuff like timer resolution. I don= 't > think it went anywhere. Do you think we ought to revitalise that? You > mention inference - have you tried that - are there cases where it doesn'= t > work? > > [IJ] Yes, actually wondered what happened to Richards draft. I only > briefly tried out the inference algorithm with a TCP LEDBAT implementatio= n ( > https://github.com/silviov/TCP-LEDBAT/blob/master/src/tcp_ledbat.c). I > recall that it took a while to converge. Also I am not sure here. Is Hz i= n > e.g a linux stack fixed. ? > > I believe so. But I don't know about embedded systems etc. > > Cheers > > > > Bob > > > > > That's it. Thanks again for the draft. V useful. > > > > Bob > > > On 15/10/15 06:08, Ingemar Johansson S wrote: > > Hi > > > > A new IETF draft is submitted in response to general discussion that for = instance TCP Cubic is not an appropriate congestion control algorithm for L= TE. > > The draft briefly outlines typical 4G access behavior on the PDCP, RLC an= d MAC layers that can have an impact on transport protocol performance. Th= e draft also outlines two relatively simple modifications to the Cubic cong= estion control. > > > > /Ingemar > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org ] > > Sent: den 14 oktober 2015 20:17 > > To: Ingemar Johansson S > > Subject: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt > > > > > > A new version of I-D, draft-johansson-cc-for-4g-5g-00.txt > > has been successfully submitted by Ingemar Johansson and posted to the IE= TF repository. > > > > Name: draft-johansson-cc-for-4g-5g > > Revision: 00 > > Title: Congestion control for 4G and 5G access > > Document date: 2015-10-14 > > Group: Individual Submission > > Pages: 14 > > URL: https://www.ietf.org/internet-drafts/draft-johansson-cc-f= or-4g-5g-00.txt > > Status: https://datatracker.ietf.org/doc/draft-johansson-cc-for-4= g-5g/ > > Htmlized: https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-= 00 > > > > > > Abstract: > > This memo outlines the challenge that 4G and 5G access brings for > > transport protocol congestion control and also outlines a few simple > > examples that can improve transport protocol congestion control > > performance in 4G and 5G access. > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > > -- > > ________________________________________________________________ > > Bob Briscoe http://bobbriscoe.net/ > > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > > --001a114302422be62b0523c45f83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I also support this doc to be adopted by iccrg or tsvwg

On Nov 5, 2015 7:27 AM, "Bob Briscoe" = <ietf@bobbriscoe.net> wrot= e:
=20 =20 =20
Ingemar,

On 04/11/15 13:27, Ingemar Johansson S wrote:
=20 =20 =20

Hi=

=C2=A0

An= d thanks for the review, comments/answers/questions inline below

=C2=A0

/I= ngemar

=C2=A0

From: Bob= Briscoe [mailto:i= etf@bobbriscoe.net]
Sent: den 29 oktober 2015 18:54
To: Ingemar Johansson S; iccrg@irtf.org; tcpm@i= etf.org; tsvwg@ietf= .org
Subject: Re: [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt

=C2=A0

Ingemar,
As promised, here's my comments. They are a mix of suggeste= d improvements to the draft, suggested improvements to 5G, or requests for clarification. I also agree with all Kevin Smith's comments, so I didn't repeat any.
[Sorry for delay - I had to find time to re-type after losing my review during a power outage]

Context questions.
Q1. Is this exercise treating the 5G specs solely in read-only mode? Or, if some useful design suggestions arise, is there any chance that the 3GPP might take them on board, given 5G is not fully baked yet?<= u>

[IJ] Guess it depends, need to say that I probably the small cog in the wheel. I would say that a lot of the standards work in IETF has been picked up by 3GPP and, I cannot say what will happen in the 5G context.

It's great that you have taken this initiative. Do= es the 3GPP ever formally ask the IETF for comments on its ideas for each new generation of radio? Given the layers above can be thought of as the 'customers' of the 3GPP,= and these 'customer' layers are pretty much all maintained = by the IETF, it would seem essential (and courteous) for the 3GPP to ask for customer comment, not least to co-ordinate with whatever future plans the IETF might have for the higher layers.

[IJ] What you say makes much sense. I guess there is some natural leakage between 3GPP and IETF as many of the IETFers are also active in 3GPP standardization. I don=E2=80=99t have full insight in the for= mal relation between 3GPP and IETF in these areas, not sure if that need to be better, but if that is the case, then it is probably a question for the area directors. Need to say that even though the formal channels are scarce it does probably not mean that 3GPP ignores IETF or what happens above IP in general. For instance the recent work around TCP RACK raises the question if it is necessary that LTE default radio bearers ensure in order delivery.

I suspect that 3GPP radio resource control people do not cross-fertilize much with the IETF.
So maybe it is as much a question of how to co-ordinate between these radio people and L4, which I would imagine is as much a problem within 3GPP as between 3GPP and IETF.



Q2. What are your plans for this draft? Are you asking for adoption? And if so, in which WG or RG? ICCRG looks the most appropriate, given the charters of all the IETF cc WGs (TSVWG, TCPM, RMCAT, etc) are scoped on just a subset of your doc.=

[IJ] First objective is to get an increased interest in congestion control algorithm work in the IETF. Traditionally this kind of work seem to be more in the terms of conference papers in e.g. Sigcomm, the benefit with having such work in IETF is that input from people with a wider expertise area (including 3GPP experitise) can give algorithm proposals that work well for a wider set of access types. The work around Cubic is a first good step as is the work around DCTCP. What I wonder is if it feasible to take this a bit further ? I would too believe that the current doc fits better in ICCRG.=C2=A0 The algorith= m examples are just.. examples. More fruitful work is probably to document different access types and from there derive a set of best current practices for congestion control algorithms

I'm sure the iccrg chairs would like this to happen. And initiative= s like yours to come with proposals to propose specific code to take account of L2 I think generate the right level of dialogue.



Section by Section Review

All sections

The document generally talks about the LTE protocol stack as if data is travelling down it. Are you implying that most sources of buffering delay are at the sending end, and the feedback end is pretty unencumbered by delays? I think it would be useful to explicitly say something about this (whether true or not), to explain why only one direction of travel is discussed in the doc.

[IJ] The feedback path is encumbered by delays, it is perhaps not that clear but section 2.3.2 implies that delay (variation) in uplink will affect the ACKs for downlink data traffic. That said, the difference in DL/UL traffic is today something like 10:1 and that is probably one reason why one can get the feeling that the draft is slanted towards downlink data traffic, this may however change with time as more machine type traffic may enter the system.

I was thinking more in terms of up the stack vs. down the stack, not uplink/downlink. I.e. for both cases:
* downlink direction: are there any buffering concerns coming up the stack at the UE, or on the feedback back-channel from the UE?
* uplink direction: are there any buffering concerns coming up the stack at the eNodeB, or on the feedback back-channel from the eNodeB?

For instance, in the UE, perhaps one app blocking the read of another due to the way {3-5}G multiplexes different streams into the same PDCP frames?



2.1 PDCP layer

=C2=A0=C2=A0=C2=A0 PDCP also ensures that all
=C2=A0=C2=A0 packets are delivered in order up to higher = layers.
I think this means "in the order sent into the link (PDCP) layer". This ought to be clarified, otherwise, when writing in the context of a layer 4 audience, it might be assumed this means in the order sent by the original transport layer source.

[IJ] Yes, you are right , reordering can still occur e.g. in the wireless backhaul



=C2= =A0=C2=A0 keep the amount of data in flight as small as possible, without sacrificing throughput.
Is this just a rather convoluted way of saying "kee= p the RTT as low as possible"? (which in turn implies keepin= g queuing delay as low as possible assuming you cannot influence the physical path.) Or were you trying to make a more subtle point? - if so, it was lost on me.

[IJ] No, it is exactly as you describe below=



=C2= =A0=C2=A0 Reliable delivery at handover may however be turned off or is simply not implemented,
It would be useful if you could give a feel for roughly how often (in %) these cases hold.

[IJ] I don=E2=80=99t believe that it is poss= ible to give a figure as this is vendor specific.



2.2 RLC layer

=C2= =A0=C2=A0 role ... is to ensure that packets are delivered in order up to the higher layers
Eh? The PDCP section just said it did ordering. And the rest of the RLC section talks exclusively about buffering delays necessary while filling transport blocks. If ordering is the role of both layers, surely one will have nothing to do once the other has got everything in order?

[IJ] RLC handles ordering due to various MAC layer failures. PDCP handles ordering =C2=A0when handover occurs



=C2= =A0=C2=A0 varying size of the available transport
Nit: Given 'transport' mean= s e2e for the audience of this draft, pls use bearer or somehow disambiguate this word.

[IJ] OK




Gap#1: In the draft, it seems like transport blocks arrive by magic, to be filled by data buffered in the RLC layer. To understand the delay compromises here, I think the draft needs to explain what determines how much transport block capacity each flow is given, and how they can influence it. In 3G, I believe that the transport layer could ask the radio resource controller to change radio resource allocation. Is this the same in 4G & 5G? Does the backlog of the buffer into the RLC layer have any automatic influence over allocation of available resources? I assume traffic class can also be used to influence allocation.<= /p>

[IJ] Will updated with more detail=



Gap#2: In a 3G stack, the RLC layer multiplexes all the active application streams into MAC layer transport block by dicing up buffered packets and packing the pieces into each transport block. Then, at the other end of the link, each piece has to be held until the rest of the packet arrives. This sacrifices delay for bandwidth efficiency. Is this still done in 4G and 5G? If so, it would be good to write about mux delay in the draft too.

[IJ] OK, will add more info



2.3 MAC layer

=C2= =A0=C2=A0 the maximum number of retransmissions is configurable

Wouldn't it be better to set a limit on the time spent retransmitting, so it would automatically give up with less retransmissions for longer transmission distances?
[IJ] Possible, 4G specifies a limit to the number of retransmissions, in practice it can be translated to time as each retransmission is 8ms later.

I didn't realise it was independent of link-RTT. Then the more basi= c question is why is it independent of link-RTT? Surely on a short link it can assume that it needs to retransmit more quickly than on a long link?

You can see that my question was assuming that retransmission happened more often on a short link, then I was saying it should still be allowed the same amount of time to keep retrying (so on a short link it would be allowed to retransmit more times before giving up, but the max delay would be the same).

8ms! I was assuming it would be rather much less than that. Surely a link-layer ACK could never take that long if the frame was going to get through.

=C2=A0


s/only checks for the presence on download data only at regular intervals/
=C2=A0/only checks for the presence of download data at regul= ar intervals/
[OK]=

=C2=A0


2.3.2 Uplink scheduling

=C2= =A0=C2=A0 The scheduling request does not indicate how many bytes there are in the uplink queue.
Seems like a bad omission. Is there a reason? If there are less bytes queued than the base station's grant, surely it would be useful for the base station to know, so that it can grant more to something else while the previous short transmission is completing.
[IJ] It is a desig= n choice. A buffer status report is more bulky, a scheduling request is just one bit.

=C2=A0


You say that when HARQ breaks up a sequence of ACKs, it can also trigger "coalescing issues". I can understand that it could cause ACK compression, but are you implying something coalesces the ACKs or the subsequent data? What does the coalescing? Similarly, in the last para of 2.3.2 you say "Reduced ACKs can unfortunately cause coalescing.&qu= ot; and again I'm not sure what is coalescing what here.

[IJ] What I can see in simulations is that the ACK compression leads to coalescing which further can increase jitter.

I still don't understand. The question was "What is coalescing what?"


There could be a positive side to the interaction between ACK clocking and link aggregation, at least for long-running flows. This has been observed in 802.11n WiFi where the buffering and aggregation of multiple ACKs into one transmission grant tend to lead the sender to bunch multiple data segments so that they all nicely fill one transmission grant in the other direction [Showail14]. = As long as the transmission grant does not wait for more data (which unfortunately I don't think is the case in 3G/4G/5G), this could be good for bandwidth utilisation of elephants and latency of mice, including when they are mixed.

[Showail14] Showail, A., Jamshaid, K. & Shihada, B., "WQM: An Aggregation-aware Queue Management Scheme for IEEE 802.11N Based Networks," In: Proceedings of the 201= 4 ACM SIGCOMM Workshop on Capacity Sharing Workshop CSWS '1= 4 pp.15-20 ACM (2014)
<http://dl.acm.org/citation.cfm= ?id=3D2630097>
[IJ] Interesting ,will look at it, not sure though that it will work that well with 4G (cant say anything about 5G), in 4G the transmission grants can vary quite a lot over short time spans.

=C2=A0


3.=C2=A0 4G and 5G evolution

s/a explicit/an explicit/

4.=C2=A0 Requirements for improved performance

s/bufferbloat/buffer/

5.=C2=A0 Congestion control examples

Regarding Hybrid Cubic using OWD measurements, I have seen a paper (under submission) about getting delay-based congestion controls (e.g. LEDBAT or CAIA Delay Gradient) to interwork with AQMs with various low delay targets. It's no= t in the context of cellular networks, but I'll try to remember to point it out once it gets published.

[IJ] Sounds interesting , looking forward to see the paper.



5.1 HyStartRestart

s/algorithm used/algorithm is used/

In the new code, it would be useful to explain why the second test before doubling ssthresh, ie, the test for how long it has been since the last hyrestart. Also, in the header definitions, if you intend there to be constraints on the relation between N_RTT_HYRESTART and N_RTT_LOW (e.g.=C2=A0 N_RTT_HYRESTART > N_RTT_LOW) you ought to say, because people will try other values.

Rather than the rather arbitrary wait before an arbitrary doubling of ssthresh, wouldn't it be better to continually increase ssthresh (not necessarily linearly) the longer the RTT has remained only just higher than the min RTT?

[IJ] Yes, could be an option



(BTW, surely the main problem with this modification to HyStartRestart is that is requires a number of round trips to reduce delay - a sort-of oxymoron.)

[IJ] Yes, have tried some more experiments with this algorithm. And I am getting more hesitant. The problem is that when I add more noise (modeling of small objects traffic) into the system simulation, then I also get more delay jitter and the delay detection algorithm in HyStart is notoriously sensitive to delay jitter.



5.2.=C2=A0 Hybrid Cubic

=C2=A0=C2=A0 Furthermore it is assumed than the timestamp cl=
ock frequency in
=C2=A0=C2=A0 sender and receiver are identical or that the s=
ender can infer the
=C2=A0=C2=A0 timestamp clock frequency of the receiver and r=
ecompute timestamp
=C2=A0=C2=A0 values based on this information.=

Recently on tcpm I sent you a pointer to the chirping paper Mirja & I did, which also made this assumption. Partly prompted by that, Richard Scheffenegger tried to get people interested in standardising use of the timestamp option on a SYN to negotiate stuff like timer resolution. I don't think it wen= t anywhere. Do you think we ought to revitalise that? You mention inference - have you tried that - are there cases where it doesn't work?=

[IJ] Yes, actually wondered what happened to Richards draft. I only briefly tried out the inference algorithm with a TCP LEDBAT implementation (https://github.com/silviov/TCP-LEDBAT/b= lob/master/src/tcp_ledbat.c). I recall that it took a while to converge. Also I am not sure here. Is Hz in e.g a linux stack fixed. ?

I believe so. But I don't know about embedded systems etc.

Cheers



Bob




That's it. Thanks again for the draft. V useful.



Bob


On 15/10/15 06:08, Ingemar Johansson S wrote:

Hi
=C2=A0
A new IETF draft is submitted in response to general discu=
ssion that for instance TCP Cubic is not an appropriate congestion control =
algorithm for LTE. 
The draft briefly outlines typical 4G access behavior on t=
he PDCP, RLC and MAC=C2=A0 layers that can have an impact on transport prot=
ocol performance. The draft also outlines two relatively simple modificatio=
ns to the Cubic congestion control.
=C2=A0
/Ingemar=C2=A0 
=C2=A0
-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: den 14 oktober 2015 20:17
To: Ingemar Johansson S
Subject: New Version Notification for draft-johansson-cc-f=
or-4g-5g-00.txt
=C2=A0
=C2=A0
A new version of I-D, draft-johansson-cc-for-4g-5g-00.txt<=
u>
has been successfully submitted by Ingemar Johansson and p=
osted to the IETF repository.
=C2=A0
Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 draft-johansson-cc-for-4g-5g
Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00=

Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Congestion control for 4G and 5G access
Document date:=C2=A0 2015-10-14
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 Individual Submission
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 14
URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 https://www.ietf.org/internet-draf=
ts/draft-johansson-cc-for-4g-5g-00.txt
Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-=
5g/
Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-00
=C2=A0
=C2=A0
Abstract:
=C2=A0=C2=A0 This memo outlines the challenge that 4G and =
5G access brings for
=C2=A0=C2=A0 transport protocol congestion control and als=
o outlines a few simple
=C2=A0=C2=A0 examples that can improve transport protocol =
congestion control
=C2=A0=C2=A0 performance in 4G and 5G access.
=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
=C2=A0
=C2=A0
Please note that it may take a couple of minutes from the =
time of submission until the htmlized version and diff are available at tools.ietf.org.=

=C2=A0
The IETF Secretariat
=C2=A0




-- 
____________________________________________________________=
____
Bob Briscoe=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://bobbriscoe.net/

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--001a114302422be62b0523c45f83-- From nobody Thu Nov 5 02:13:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99901AC3F5 for ; Thu, 5 Nov 2015 02:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZgeP7b9-Jf6 for ; Thu, 5 Nov 2015 02:13:12 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEB51AC3EE for ; Thu, 5 Nov 2015 02:13:12 -0800 (PST) Received: by padhx2 with SMTP id hx2so75645707pad.1 for ; Thu, 05 Nov 2015 02:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=simula_no.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hnc8eEH6d+AGFflB2bRneRd/YR+1Ya3pS+pxNQK+kBM=; b=n4OblLgf0i+zQ9jWx7jNr53Gb2Nfo2DuTn9BW5/HOCzhv/O85VEa6FIOYs3M2D4x4u +TdwmfRM2hVWfEHkdW8YVH9xwXoPTHTKu+GCWFQTuRsZvrArb2RhPlvQS9nICyUPSuHS E7bYjjmMTy0cdLu5VnX2tpmvnJNUx3fBr5+gQLmiI/3M3s4czFokvOF2W308MaqUQiiu Hewo6TZXowvWwfBsABBUXP7T4B/TmQA7O8Vm9aPrSyyP478BokBE1+6w1Ap3K0SlVCT9 QfsW4TDRjaEUxN0+/A6oR8TwSgc+uzEjhgWPF855CTyUDvwfIJoV6t1hC/e8OmkbBRVZ J5aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hnc8eEH6d+AGFflB2bRneRd/YR+1Ya3pS+pxNQK+kBM=; b=hf0SIeCWoUISRvNGtUftKdwgocnJ5VN6DJsQE4OL1MnGXzYmfXUuzjep+gxVYvh6vY O+aDsK9ri8fWq/7E5nDXIec0bswROhWAykZWM7E+BNQLSemiTee8ShXwoiJ//Hr9KBhG dfOhHOEBfoNk54PsCZrSpe0fvEw5lkG89LAh7403HlUmzZ4vBw8GrHL4xa/ZooL+QcOY lounMzSNZM0Uy+fZ3VUelOaJHPHysXK92wb4jAoszBvulsZwox+9d0l0H3zrsTpPDQ9B 2tAKf+fAuvIz9p+r73QUhT3vUK9Ryj8nXI3s2bXCrdWwp6sk0+ItmjxNj2l4gnwPEw+T CApQ== X-Gm-Message-State: ALoCoQlPZpVa9R7YsMlkpzSlVRHxhkjMtcpHRQuRuGk0BJPPgDRS3SDhQxR0mrdeCXG+Iz3BTrHU X-Received: by 10.68.131.201 with SMTP id oo9mr8387091pbb.74.1446718391933; Thu, 05 Nov 2015 02:13:11 -0800 (PST) Received: from [192.168.2.101] (i121-112-35-81.s41.a014.ap.plala.or.jp. [121.112.35.81]) by smtp.gmail.com with ESMTPSA id sb6sm6970022pbc.66.2015.11.05.02.13.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 05 Nov 2015 02:13:11 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1D330CE2-C433-4C5B-BC63-F9FE19C98D61" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Ros In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658@ESESSMB205.ericsson.se> Date: Thu, 5 Nov 2015 19:13:08 +0900 Message-Id: References: <20151014181702.10618.83714.idtracker@ietfa.amsl.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34BF4F0F@ESESSMB205.ericsson.se> <56325D2D.1070107@bobbriscoe.net> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658@ESESSMB205.ericsson.se> To: Ingemar Johansson S X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tcpm@ietf.org" , "iccrg@irtf.org" , "tsvwg@ietf.org" , Michael Welzl Subject: Re: [tcpm] [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 10:13:18 -0000 --Apple-Mail=_1D330CE2-C433-4C5B-BC63-F9FE19C98D61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ingemar, We believe this is a useful document, agree that it's a good match for = ICCRG, and would be happy with ICCRG being the home of this draft. Thanks, Michael & David (as ICCRG chairs) On 04 Nov 2015, at 22:27, Ingemar Johansson S = wrote: > Hi > =20 > And thanks for the review, comments/answers/questions inline below > =20 > /Ingemar > =20 > From: Bob Briscoe [mailto:ietf@bobbriscoe.net]=20 > Sent: den 29 oktober 2015 18:54 > To: Ingemar Johansson S; iccrg@irtf.org; tcpm@ietf.org; tsvwg@ietf.org > Subject: Re: [tsvwg] FW: New Version Notification for = draft-johansson-cc-for-4g-5g-00.txt > =20 > Ingemar, >=20 > As promised, here's my comments. They are a mix of suggested = improvements to the draft, suggested improvements to 5G, or requests for = clarification. I also agree with all Kevin Smith's comments, so I didn't = repeat any. > [Sorry for delay - I had to find time to re-type after losing my = review during a power outage] >=20 > Context questions. > Q1. Is this exercise treating the 5G specs solely in read-only mode? = Or, if some useful design suggestions arise, is there any chance that = the 3GPP might take them on board, given 5G is not fully baked yet? >=20 > [IJ] Guess it depends, need to say that I probably the small cog in = the wheel. I would say that a lot of the standards work in IETF has been = picked up by 3GPP and, I cannot say what will happen in the 5G context.=20= >=20 > It's great that you have taken this initiative. Does the 3GPP ever = formally ask the IETF for comments on its ideas for each new generation = of radio? Given the layers above can be thought of as the 'customers' of = the 3GPP, and these 'customer' layers are pretty much all maintained by = the IETF, it would seem essential (and courteous) for the 3GPP to ask = for customer comment, not least to co-ordinate with whatever future = plans the IETF might have for the higher layers. >=20 > [IJ] What you say makes much sense. I guess there is some natural = leakage between 3GPP and IETF as many of the IETFers are also active in = 3GPP standardization. I don=92t have full insight in the formal relation = between 3GPP and IETF in these areas, not sure if that need to be = better, but if that is the case, then it is probably a question for the = area directors. Need to say that even though the formal channels are = scarce it does probably not mean that 3GPP ignores IETF or what happens = above IP in general. For instance the recent work around TCP RACK raises = the question if it is necessary that LTE default radio bearers ensure in = order delivery. >=20 >=20 >=20 > Q2. What are your plans for this draft? Are you asking for adoption? = And if so, in which WG or RG? ICCRG looks the most appropriate, given = the charters of all the IETF cc WGs (TSVWG, TCPM, RMCAT, etc) are scoped = on just a subset of your doc. >=20 > [IJ] First objective is to get an increased interest in congestion = control algorithm work in the IETF. Traditionally this kind of work seem = to be more in the terms of conference papers in e.g. Sigcomm, the = benefit with having such work in IETF is that input from people with a = wider expertise area (including 3GPP experitise) can give algorithm = proposals that work well for a wider set of access types. The work = around Cubic is a first good step as is the work around DCTCP. What I = wonder is if it feasible to take this a bit further ? I would too = believe that the current doc fits better in ICCRG. The algorithm = examples are just.. examples. More fruitful work is probably to document = different access types and from there derive a set of best current = practices for congestion control algorithms >=20 >=20 >=20 > Section by Section Review >=20 > All sections >=20 > The document generally talks about the LTE protocol stack as if data = is travelling down it. Are you implying that most sources of buffering = delay are at the sending end, and the feedback end is pretty = unencumbered by delays? I think it would be useful to explicitly say = something about this (whether true or not), to explain why only one = direction of travel is discussed in the doc. >=20 > [IJ] The feedback path is encumbered by delays, it is perhaps not that = clear but section 2.3.2 implies that delay (variation) in uplink will = affect the ACKs for downlink data traffic. That said, the difference in = DL/UL traffic is today something like 10:1 and that is probably one = reason why one can get the feeling that the draft is slanted towards = downlink data traffic, this may however change with time as more machine = type traffic may enter the system. >=20 >=20 >=20 > 2.1 PDCP layer >=20 > PDCP also ensures that all > packets are delivered in order up to higher layers. > I think this means "in the order sent into the link (PDCP) layer". = This ought to be clarified, otherwise, when writing in the context of a = layer 4 audience, it might be assumed this means in the order sent by = the original transport layer source. >=20 > [IJ] Yes, you are right , reordering can still occur e.g. in the = wireless backhaul >=20 >=20 >=20 > keep the amount of data in flight as small as possible, without = sacrificing throughput. > Is this just a rather convoluted way of saying "keep the RTT as low as = possible"? (which in turn implies keeping queuing delay as low as = possible assuming you cannot influence the physical path.) Or were you = trying to make a more subtle point? - if so, it was lost on me. >=20 > [IJ] No, it is exactly as you describe below >=20 >=20 >=20 > Reliable delivery at handover may however be turned off or is = simply not implemented, > It would be useful if you could give a feel for roughly how often (in = %) these cases hold. >=20 > [IJ] I don=92t believe that it is possible to give a figure as this is = vendor specific. >=20 >=20 >=20 > 2.2 RLC layer >=20 > role ... is to ensure that packets are delivered in order up to the = higher layers > Eh? The PDCP section just said it did ordering. And the rest of the = RLC section talks exclusively about buffering delays necessary while = filling transport blocks. If ordering is the role of both layers, surely = one will have nothing to do once the other has got everything in order? >=20 > [IJ] RLC handles ordering due to various MAC layer failures. PDCP = handles ordering when handover occurs >=20 >=20 >=20 > varying size of the available transport > Nit: Given 'transport' means e2e for the audience of this draft, pls = use bearer or somehow disambiguate this word. >=20 > [IJ] OK >=20 >=20 >=20 >=20 > Gap#1: In the draft, it seems like transport blocks arrive by magic, = to be filled by data buffered in the RLC layer. To understand the delay = compromises here, I think the draft needs to explain what determines how = much transport block capacity each flow is given, and how they can = influence it. In 3G, I believe that the transport layer could ask the = radio resource controller to change radio resource allocation. Is this = the same in 4G & 5G? Does the backlog of the buffer into the RLC layer = have any automatic influence over allocation of available resources? I = assume traffic class can also be used to influence allocation. >=20 > [IJ] Will updated with more detail >=20 >=20 >=20 > Gap#2: In a 3G stack, the RLC layer multiplexes all the active = application streams into MAC layer transport block by dicing up buffered = packets and packing the pieces into each transport block. Then, at the = other end of the link, each piece has to be held until the rest of the = packet arrives. This sacrifices delay for bandwidth efficiency. Is this = still done in 4G and 5G? If so, it would be good to write about mux = delay in the draft too. >=20 > [IJ] OK, will add more info >=20 >=20 >=20 > 2.3 MAC layer >=20 > the maximum number of retransmissions is configurable >=20 > Wouldn't it be better to set a limit on the time spent retransmitting, = so it would automatically give up with less retransmissions for longer = transmission distances? > [IJ] Possible, 4G specifies a limit to the number of retransmissions, = in practice it can be translated to time as each retransmission is 8ms = later. >=20 > =20 >=20 >=20 > s/only checks for the presence on download data only at regular = intervals/ > /only checks for the presence of download data at regular intervals/ > [OK] >=20 > =20 >=20 >=20 > 2.3.2 Uplink scheduling >=20 > The scheduling request does not indicate how many bytes there are = in the uplink queue. > Seems like a bad omission. Is there a reason? If there are less bytes = queued than the base station's grant, surely it would be useful for the = base station to know, so that it can grant more to something else while = the previous short transmission is completing. > [IJ] It is a design choice. A buffer status report is more bulky, a = scheduling request is just one bit. >=20 > =20 >=20 >=20 > You say that when HARQ breaks up a sequence of ACKs, it can also = trigger "coalescing issues". I can understand that it could cause ACK = compression, but are you implying something coalesces the ACKs or the = subsequent data? What does the coalescing? Similarly, in the last para = of 2.3.2 you say "Reduced ACKs can unfortunately cause coalescing." and = again I'm not sure what is coalescing what here. >=20 > [IJ] What I can see in simulations is that the ACK compression leads = to coalescing which further can increase jitter. >=20 >=20 > There could be a positive side to the interaction between ACK clocking = and link aggregation, at least for long-running flows. This has been = observed in 802.11n WiFi where the buffering and aggregation of multiple = ACKs into one transmission grant tend to lead the sender to bunch = multiple data segments so that they all nicely fill one transmission = grant in the other direction [Showail14]. As long as the transmission = grant does not wait for more data (which unfortunately I don't think is = the case in 3G/4G/5G), this could be good for bandwidth utilisation of = elephants and latency of mice, including when they are mixed. >=20 > [Showail14] Showail, A., Jamshaid, K. & Shihada, B., "WQM: An = Aggregation-aware Queue Management Scheme for IEEE 802.11N Based = Networks," In: Proceedings of the 2014 ACM SIGCOMM Workshop on Capacity = Sharing Workshop CSWS '14 pp.15-20 ACM (2014) > > [IJ] Interesting ,will look at it, not sure though that it will work = that well with 4G (cant say anything about 5G), in 4G the transmission = grants can vary quite a lot over short time spans. >=20 > =20 >=20 >=20 > 3. 4G and 5G evolution >=20 > s/a explicit/an explicit/ >=20 > 4. Requirements for improved performance >=20 > s/bufferbloat/buffer/ >=20 > 5. Congestion control examples >=20 > Regarding Hybrid Cubic using OWD measurements, I have seen a paper = (under submission) about getting delay-based congestion controls (e.g. = LEDBAT or CAIA Delay Gradient) to interwork with AQMs with various low = delay targets. It's not in the context of cellular networks, but I'll = try to remember to point it out once it gets published. >=20 > [IJ] Sounds interesting , looking forward to see the paper. >=20 >=20 >=20 > 5.1 HyStartRestart >=20 > s/algorithm used/algorithm is used/ >=20 > In the new code, it would be useful to explain why the second test = before doubling ssthresh, ie, the test for how long it has been since = the last hyrestart. Also, in the header definitions, if you intend there = to be constraints on the relation between N_RTT_HYRESTART and N_RTT_LOW = (e.g. N_RTT_HYRESTART > N_RTT_LOW) you ought to say, because people = will try other values. >=20 > Rather than the rather arbitrary wait before an arbitrary doubling of = ssthresh, wouldn't it be better to continually increase ssthresh (not = necessarily linearly) the longer the RTT has remained only just higher = than the min RTT? >=20 > [IJ] Yes, could be an option >=20 >=20 >=20 > (BTW, surely the main problem with this modification to HyStartRestart = is that is requires a number of round trips to reduce delay - a sort-of = oxymoron.) >=20 > [IJ] Yes, have tried some more experiments with this algorithm. And I = am getting more hesitant. The problem is that when I add more noise = (modeling of small objects traffic) into the system simulation, then I = also get more delay jitter and the delay detection algorithm in HyStart = is notoriously sensitive to delay jitter. >=20 >=20 >=20 > 5.2. Hybrid Cubic >=20 > Furthermore it is assumed than the timestamp clock frequency in > sender and receiver are identical or that the sender can infer the > timestamp clock frequency of the receiver and recompute timestamp > values based on this information. > Recently on tcpm I sent you a pointer to the chirping paper Mirja & I = did, which also made this assumption. Partly prompted by that, Richard = Scheffenegger tried to get people interested in standardising use of the = timestamp option on a SYN to negotiate stuff like timer resolution. I = don't think it went anywhere. Do you think we ought to revitalise that? = You mention inference - have you tried that - are there cases where it = doesn't work? >=20 > [IJ] Yes, actually wondered what happened to Richards draft. I only = briefly tried out the inference algorithm with a TCP LEDBAT = implementation = (https://github.com/silviov/TCP-LEDBAT/blob/master/src/tcp_ledbat.c). I = recall that it took a while to converge. Also I am not sure here. Is Hz = in e.g a linux stack fixed. ? >=20 >=20 >=20 >=20 > That's it. Thanks again for the draft. V useful. >=20 >=20 >=20 > Bob >=20 >=20 >=20 > On 15/10/15 06:08, Ingemar Johansson S wrote: > Hi > =20 > A new IETF draft is submitted in response to general discussion that = for instance TCP Cubic is not an appropriate congestion control = algorithm for LTE.=20 > The draft briefly outlines typical 4G access behavior on the PDCP, RLC = and MAC layers that can have an impact on transport protocol = performance. The draft also outlines two relatively simple modifications = to the Cubic congestion control. > =20 > /Ingemar =20 > =20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: den 14 oktober 2015 20:17 > To: Ingemar Johansson S > Subject: New Version Notification for = draft-johansson-cc-for-4g-5g-00.txt > =20 > =20 > A new version of I-D, draft-johansson-cc-for-4g-5g-00.txt > has been successfully submitted by Ingemar Johansson and posted to the = IETF repository. > =20 > Name: draft-johansson-cc-for-4g-5g > Revision: 00 > Title: Congestion control for 4G and 5G access > Document date: 2015-10-14 > Group: Individual Submission > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-johansson-cc-for-4g-5g-00.txt > Status: = https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-5g/ > Htmlized: = https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-00 > =20 > =20 > Abstract: > This memo outlines the challenge that 4G and 5G access brings for > transport protocol congestion control and also outlines a few = simple > examples that can improve transport protocol congestion control > performance in 4G and 5G access. > =20 > =20 > = =20 > =20 > =20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. > =20 > The IETF Secretariat > =20 >=20 >=20 >=20 > --=20 > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_1D330CE2-C433-4C5B-BC63-F9FE19C98D61 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Ingemar,

We believe = this is a useful document, agree that it's a good match for ICCRG, and = would be happy with ICCRG being the home of this = draft.

Thanks,

Michael = & David (as ICCRG chairs)


On 04 = Nov 2015, at 22:27, Ingemar Johansson S <ingemar.s.johansson@erics= son.com> wrote:

Hi
 
And thanks for the review, = comments/answers/questions inline below
 
/Ingemar
 
From: Bob Briscoe [mailto:ietf@bobbriscoe.net] 
Sent: den 29 oktober 2015 = 18:54
To: Ingemar Johansson S; iccrg@irtf.org; tcpm@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvwg] FW: New Version = Notification for = draft-johansson-cc-for-4g-5g-00.txt
 

Ingemar,

As promised, here's my comments. They = are a mix of suggested improvements to the draft, suggested improvements = to 5G, or requests for clarification. I also agree with all Kevin = Smith's comments, so I didn't repeat any.
[Sorry for delay - I had to = find time to re-type after losing my review during a power = outage]

Context questions.
Q1. Is this exercise = treating the 5G specs solely in read-only mode? Or, if some useful = design suggestions arise, is there any chance that the 3GPP might take = them on board, given 5G is not fully baked yet?

[IJ] Guess = it depends, need to say that I probably the small cog in the wheel. I = would say that a lot of the standards work in IETF has been picked up by = 3GPP and, I cannot say what will happen in the 5G context. 

It's great that you have taken this = initiative. Does = the 3GPP ever formally ask the IETF for comments on its ideas for each = new generation of radio? Given the layers above can be thought of as the = 'customers' of the 3GPP, and these 'customer' layers are pretty much all = maintained by the IETF, it would seem essential (and courteous) for the = 3GPP to ask for customer comment, not least to co-ordinate with whatever = future plans the IETF might have for the higher layers.

[IJ] What you say makes much sense. I guess there is = some natural leakage between 3GPP and IETF as many of the IETFers are = also active in 3GPP standardization. I don=92t have full insight in the = formal relation between 3GPP and IETF in these areas, not sure if that = need to be better, but if that is the case, then it is probably a = question for the area directors. Need to say that even though the formal = channels are scarce it does probably not mean that 3GPP ignores IETF or = what happens above IP in general. For instance the recent work around = TCP RACK raises the question if it is necessary that LTE default radio = bearers ensure in order delivery.



Q2. = What are your plans for this draft? Are you asking for = adoption? And if so, in which WG or RG? ICCRG looks the most = appropriate, given the charters of all the IETF cc WGs (TSVWG, TCPM, = RMCAT, etc) are scoped on just a subset of your doc.

[IJ] First = objective is to get an increased interest in congestion control = algorithm work in the IETF. Traditionally this kind of work seem to be = more in the terms of conference papers in e.g. Sigcomm, the benefit with = having such work in IETF is that input from people with a wider = expertise area (including 3GPP experitise) can give algorithm proposals = that work well for a wider set of access types. The work around Cubic is = a first good step as is the work around DCTCP. What I wonder is if it = feasible to take this a bit further ? I would too believe that the = current doc fits better in ICCRG.  The algorithm examples are = just.. examples. More fruitful work is probably to document different = access types and from there derive a set of best current practices for = congestion control algorithms



Section by Section = Review

All sections

The document generally = talks about the LTE protocol stack as if data is travelling down = it. Are you = implying that most sources of buffering delay are at the sending end, = and the feedback end is pretty unencumbered by delays? I think it would = be useful to explicitly say something about this (whether true or not), = to explain why only one direction of travel is discussed in the = doc.

[IJ] The feedback path is encumbered by delays, it is = perhaps not that clear but section 2.3.2 implies that delay (variation) = in uplink will affect the ACKs for downlink data traffic. That said, the = difference in DL/UL traffic is today something like 10:1 and that is = probably one reason why one can get the feeling that the draft is = slanted towards downlink data traffic, this may however change with time = as more machine type traffic may enter the = system.



2.1 PDCP = layer

    PDCP also ensures that all
   = packets are delivered in order up to higher layers.
I = think this means "in the order sent into the link (PDCP) layer". This = ought to be clarified, otherwise, when writing in the context of a layer = 4 audience, it might be assumed this means in the order sent by the = original transport layer source.

[IJ] Yes, you are right , = reordering can still occur e.g. in the wireless = backhaul



   keep the amount of data in flight as small as = possible, without sacrificing throughput.
Is = this just a rather convoluted way of saying "keep the RTT as low as = possible"? (which in turn implies keeping queuing delay as low as = possible assuming you cannot influence the physical path.) Or were you = trying to make a more subtle point? - if so, it was lost on me.

[IJ] No, it is exactly as you describe = below



   = Reliable delivery at handover may however be turned off or is simply not = implemented,
It would be = useful if you could give a feel for roughly how often (in %) these cases = hold.

[IJ] I don=92t believe that it is = possible to give a figure as this is vendor = specific.



2.2 RLC = layer

   role ... is to = ensure that packets are delivered in order up to the higher = layers
Eh? The PDCP section = just said it did ordering. And the rest of the RLC section talks = exclusively about buffering delays necessary while filling transport = blocks. If ordering is the role of both layers, surely one will have = nothing to do once the other has got everything in order?

[IJ] RLC handles ordering due to various MAC layer = failures. PDCP handles ordering  when handover = occurs



   = varying size of the available transport
Nit: Given 'transport' means e2e for the audience of this = draft, pls use bearer or somehow disambiguate this word.

[IJ] OK




Gap#1: In the draft, it seems like transport = blocks arrive by magic, to be filled by data buffered in the RLC = layer. To = understand the delay compromises here, I think the draft needs to = explain what determines how much transport block capacity each flow is = given, and how they can influence it. In 3G, I believe that the = transport layer could ask the radio resource controller to change radio = resource allocation. Is this the same in 4G & 5G? Does the backlog = of the buffer into the RLC layer have any automatic influence over = allocation of available resources? I assume traffic class can also be = used to influence allocation.

[IJ] Will updated with more = detail



Gap#2: In a 3G stack, the RLC layer multiplexes = all the active application streams into MAC layer transport block by = dicing up buffered packets and packing the pieces into each transport = block. Then, at = the other end of the link, each piece has to be held until the rest of = the packet arrives. This sacrifices delay for bandwidth efficiency. Is = this still done in 4G and 5G? If so, it would be good to write about mux = delay in the draft too.

[IJ] OK, will add more = info



2.3 MAC layer

   the maximum number of = retransmissions is configurable

Wouldn't it be better to set a limit on the time spent retransmitting, so it = would automatically give up with less retransmissions for longer = transmission distances?
[IJ] Possible, 4G specifies a limit to the number of = retransmissions, in practice it can be translated to time as each = retransmission is 8ms later.

 


s/only checks for the presence on download data only = at regular intervals/
 /only checks for the presence of download = data at regular intervals/
[OK]

 


2.3.2 Uplink scheduling

   The scheduling request does not = indicate how many bytes there are in the uplink queue.
Seems like a bad omission. Is there a reason? If there = are less bytes queued than the base station's grant, surely it would be = useful for the base station to know, so that it can grant more to = something else while the previous short transmission is = completing.
[IJ] It is a design choice. A buffer status report is more bulky, = a scheduling request is just one bit.

 


You say that when HARQ breaks = up a sequence of ACKs, it can also trigger "coalescing issues". I can understand = that it could cause ACK compression, but are you implying something = coalesces the ACKs or the subsequent data? What does the = coalescing? Similarly, in the last para of 2.3.2 you say "Reduced = ACKs can unfortunately cause coalescing." and again I'm not sure what is = coalescing what here.

[IJ] What I can see in = simulations is that the ACK compression leads to coalescing which = further can increase jitter.


There could be a positive side = to the interaction between ACK clocking and link aggregation, at least = for long-running flows. This has been = observed in 802.11n WiFi where the buffering and aggregation of multiple = ACKs into one transmission grant tend to lead the sender to bunch = multiple data segments so that they all nicely fill one transmission = grant in the other direction [Showail14]. As = long as the transmission grant does not wait for more data (which = unfortunately I don't think is the case in 3G/4G/5G), this could be good = for bandwidth utilisation of elephants and latency of mice, including = when they are mixed.

[Showail14] Showail, A., Jamshaid, K. & = Shihada, B., "WQM: An Aggregation-aware Queue Management Scheme for IEEE = 802.11N Based Networks," In: Proceedings of the 2014 ACM SIGCOMM = Workshop on Capacity Sharing Workshop CSWS '14 pp.15-20 ACM = (2014)
<http://dl.acm.org/citation.cfm?id=3D2630097>
[IJ] Interesting ,will look at it, not sure though = that it will work that well with 4G (cant say anything about 5G), in 4G = the transmission grants can vary quite a lot over short time = spans.

 


3.  4G and 5G evolution

s/a = explicit/an explicit/

4.  Requirements for improved = performance

s/bufferbloat/buffer/

5.  = Congestion control examples

Regarding Hybrid Cubic using OWD = measurements, I have seen a paper (under submission) about getting = delay-based congestion controls (e.g. LEDBAT or CAIA Delay Gradient) to = interwork with AQMs with various low delay targets. It's not in the = context of cellular networks, but I'll try to remember to point it out = once it gets published.

[IJ] Sounds interesting , looking = forward to see the paper.



5.1 = HyStartRestart

s/algorithm used/algorithm is used/

In = the new code, it would be useful to explain why the second test before = doubling ssthresh, ie, the test for how long it has been since the last = hyrestart. Also, = in the header definitions, if you intend there to be constraints on the = relation between N_RTT_HYRESTART and N_RTT_LOW (e.g.  = N_RTT_HYRESTART > N_RTT_LOW) you ought to say, because people will = try other values.

Rather than the rather arbitrary wait before an = arbitrary doubling of ssthresh, wouldn't it be better to continually = increase ssthresh (not necessarily linearly) the longer the RTT has = remained only just higher than the min RTT?

[IJ] Yes, could be an = option



(BTW, surely the main problem with this = modification to HyStartRestart is that is requires a number of round = trips to reduce delay - a sort-of oxymoron.)

[IJ] Yes, have tried some more experiments with this = algorithm. And I am getting more hesitant. The problem is that when I = add more noise (modeling of small objects traffic) into the system = simulation, then I also get more delay jitter and the delay detection = algorithm in HyStart is notoriously sensitive to delay = jitter.



5.2.  Hybrid Cubic

   Furthermore =
it is assumed than the timestamp clock frequency in
   sender and receiver are identical or that =
the sender can infer the
   =
timestamp clock frequency of the receiver and recompute =
timestamp
   values based =
on this information.

Recently on tcpm I sent you a pointer to the chirping = paper Mirja & I did, which also made this assumption. Partly = prompted by that, Richard Scheffenegger tried to get people interested = in standardising use of the timestamp option on a SYN to negotiate stuff = like timer resolution. I don't think it went anywhere. Do you think we = ought to revitalise that? You mention inference - have you tried that - = are there cases where it doesn't work?

[IJ] Yes, actually wondered what = happened to Richards draft. I only briefly tried out the inference = algorithm with a TCP LEDBAT implementation (https://github.com/silviov/TCP-LEDBAT/blob/master/src/tcp_ledb= at.c). I recall = that it took a while to converge. Also I am not sure here. Is Hz in e.g = a linux stack fixed. ?




That's it. Thanks again = for the draft. V = useful.



Bob


On 15/10/15 06:08, Ingemar = Johansson S wrote:
Hi
 
A new IETF draft is =
submitted in response to general discussion that for instance TCP Cubic =
is not an appropriate congestion control algorithm for LTE. =

The draft briefly outlines typical 4G =
access behavior on the PDCP, RLC and MAC  layers that can have an =
impact on transport protocol performance. The draft also outlines two =
relatively simple modifications to the Cubic congestion =
control.
 
/Ingemar  =

 
-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] =

Sent: den 14 oktober 2015 =
20:17
To: Ingemar Johansson =
S
Subject: New Version Notification for =
draft-johansson-cc-for-4g-5g-00.txt
 
 
A new version of I-D, =
draft-johansson-cc-for-4g-5g-00.txt
has been =
successfully submitted by Ingemar Johansson and posted to the IETF =
repository.
 
Name:           =
draft-johansson-cc-for-4g-5g
Revision:       =
00
Title:          =
Congestion control for 4G and 5G access
Document date:  2015-10-14
Group:          =
Individual Submission
Pages:          =
14
URL:          &nb=
sp; https://www.ietf.org/internet-drafts/draft-johansson-cc-for-4g=
-5g-00.txt
Status:         https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-5g/=

Htmlized:       https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-00
 
 
Abstract:
   This memo =
outlines the challenge that 4G and 5G access brings =
for
   transport protocol =
congestion control and also outlines a few simple
   examples that can improve transport =
protocol congestion control
   =
performance in 4G and 5G access.
 
 
           &=
nbsp;           &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;         
 
 
Please note that it may =
take a couple of minutes from the time of submission until the htmlized =
version and diff are available at tools.ietf.org.
 
The IETF =
Secretariat
 



-- =

________________________________________________________________
Bob =
Briscoe           &=
nbsp;           &nb=
sp;       http://bobbriscoe.net/
_______= ________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_1D330CE2-C433-4C5B-BC63-F9FE19C98D61-- From nobody Thu Nov 5 03:18:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403541ACE34 for ; Thu, 5 Nov 2015 03:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zmh9kpQTPUVO for ; Thu, 5 Nov 2015 03:18:37 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33C8A1ACE50 for ; Thu, 5 Nov 2015 03:18:37 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZuIYt-0006vK-HB for tcpm@ietf.org; Thu, 05 Nov 2015 12:18:35 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZuIYs-0007C4-U5 for tcpm@ietf.org; Thu, 05 Nov 2015 12:18:35 +0100 From: Michael Welzl Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 5 Nov 2015 12:18:34 +0100 To: tcpm@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 9 sum msgs/h 3 total rcpts 34843 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8966F2418D987289B55E127D676326F22D7E0D41 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 8236 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 11:18:39 -0000 Hi all, I just watched the video of TCPM and noticed a minor confusion at the = end about what the plan really is - because draft-welzl-tcpm-tcb-sharing = just contains a table contrasting RFC 2140 to implementations, and are = we aiming at Informational or a recommendation? Our plan is to update RFC 2140 to bring it in line with today's reality = - what is currently implemented. I think Informational is still fine as = status (but open to debate if people feel otherwise). Why didn't we write RFC2140bis but a separate document? Because one of = the chairs suggested this as a way forward, rather than doing a full = first version of RFC2140bis, given that we believed that just showing = this table and opening it for discussion is the best way to get this = started. Cheers, Michael From nobody Thu Nov 5 04:34:36 2015 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7851AD35D; Thu, 5 Nov 2015 04:34:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.8.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151105123434.28554.91757.idtracker@ietfa.amsl.com> Date: Thu, 05 Nov 2015 04:34:34 -0800 Archived-At: Cc: tcpm@ietf.org Subject: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 12:34:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : TCP and SCTP RTO Restart Authors : Per Hurtig Anna Brunstrom Andreas Petlund Michael Welzl Filename : draft-ietf-tcpm-rtorestart-10.txt Pages : 17 Date : 2015-11-05 Abstract: This document describes a modified sender-side algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer using a smaller timeout duration, so that the effective RTO becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rtorestart-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 5 04:41:16 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD80B1B29BD for ; Thu, 5 Nov 2015 04:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPEzzqbWv4PZ for ; Thu, 5 Nov 2015 04:41:13 -0800 (PST) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400821B29AF for ; Thu, 5 Nov 2015 04:41:13 -0800 (PST) X-Spam-Processed: mail.kau.se, Thu, 05 Nov 2015 13:41:10 +0100 (not processed: spam filter heuristic analysis disabled) X-MDRemoteIP: 130.243.29.171 X-MDHelo: nod168.wlanp.kau.se X-MDArrival-Date: Thu, 05 Nov 2015 13:41:10 +0100 X-Authenticated-Sender: per.hurtig@kau.se X-Return-Path: per.hurtig@kau.se X-Envelope-From: per.hurtig@kau.se X-MDaemon-Deliver-To: tcpm@ietf.org Content-Type: multipart/signed; boundary="Apple-Mail=_20195024-AF1E-4C75-8C0B-3254EB366630"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Pgp-Agent: GPGMail 2.6b2 From: Per Hurtig In-Reply-To: <20151105123434.28554.91757.idtracker@ietfa.amsl.com> Date: Thu, 5 Nov 2015 13:41:02 +0100 Message-Id: References: <20151105123434.28554.91757.idtracker@ietfa.amsl.com> To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 12:41:16 -0000 --Apple-Mail=_20195024-AF1E-4C75-8C0B-3254EB366630 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, as no objections were made to the suggested change in the abstract, = we=E2=80=99ve now submitted a new version of the draft. That is, changed from draft-ietf-...-09 to -10 o Changed wording in abstract, from "delay" to "timeout duration=E2=80= =9D. Cheers, Per Hurtig > On 05 Nov 2015, at 13:34, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the TCP Maintenance and Minor Extensions = Working Group of the IETF. >=20 > Title : TCP and SCTP RTO Restart > Authors : Per Hurtig > Anna Brunstrom > Andreas Petlund > Michael Welzl > Filename : draft-ietf-tcpm-rtorestart-10.txt > Pages : 17 > Date : 2015-11-05 >=20 > Abstract: > This document describes a modified sender-side algorithm for = managing > the TCP and SCTP retransmission timers that provides faster loss > recovery when there is a small amount of outstanding data for a > connection. The modification, RTO Restart (RTOR), allows the > transport to restart its retransmission timer using a smaller = timeout > duration, so that the effective RTO becomes more aggressive in > situations where fast retransmit cannot be used. This enables = faster > loss detection and recovery for connections that are short-lived or > application-limited. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tcpm-rtorestart-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-rtorestart-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --Apple-Mail=_20195024-AF1E-4C75-8C0B-3254EB366630 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWO05jAAoJEMzXVkqMT/z2Qr0H/RCBQIyoxGrAmXTulAvE8re1 rzCNg/KZmURL0XxkP/zgNGxkUESxulb+9TbuSEVHbUiYDj1Lj+ajQD2bJ0YDPzuQ T6b6uLSDQ/wJVpK3HjvkQsAgic48Hp4GTpOxG2LflCRRFZ6aopi5UL+YSFa9DSm8 +Q+lDFqRmBdaCFZCJvq6yBgKFS1y/Y5Ex9Um/4hBrSiyhD4mF0RqSpsm4STa+cLc cY1DYJCVFoAIntE2p7yL+4PKd+rFxrBwjOXQ6Bq8eUS8RU1e+u6Yrnv4qjgCf9Is BTo2YXA7aPYdGdWLtm6fTWui9qIEkoY5Q2U2utC/miUPt92oXt+sHIus0D+ynQE= =8TOE -----END PGP SIGNATURE----- --Apple-Mail=_20195024-AF1E-4C75-8C0B-3254EB366630-- From nobody Thu Nov 5 10:55:10 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDBA1A8941 for ; Thu, 5 Nov 2015 10:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOl80EKzn656 for ; Thu, 5 Nov 2015 10:55:07 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF5C1A891F for ; Thu, 5 Nov 2015 10:55:06 -0800 (PST) Received: by ykdr3 with SMTP id r3so147694654ykd.1 for ; Thu, 05 Nov 2015 10:55:06 -0800 (PST) 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; bh=LWb4Vx2p3u3wtGC6wbu+8vUa3LOQWLX+2XenWWsBLY8=; b=dFsgu5w1qdWw+gipHojXu3o9I+pexVFhcpM1d4QcW+OwRBU+M550g7joVSGfj0jH5Q 6iSlBOJ76y8K4xpMR+wj77Ggy65gqH1AmDwad3lEB5H+57kP3AA4qmHyusbn30GuMYun Y/Lvgy6DDsCneOIpq1vfICl7R06/vCTIEeEhcAmeKbc5K+lUHc7X0pN+NkFTpFQT3LBN wDqZ2kVeMY69fitEyUhEou1HZ+ut6iDKyBT1kXMoy5AlXJWIgOtmN7KDfJzN7yBqXSp6 Sd97rLlbr8y2zzqVo0omSH1qUph3O1k/acZs4Kb/1spUCCKE7COeh2Wo3GaZsp3/c9Nd Hwgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LWb4Vx2p3u3wtGC6wbu+8vUa3LOQWLX+2XenWWsBLY8=; b=EgIwitX6aXx8f859W+w1pHPSsF/e1NMsOcBCUTONp5DZTyOksElUQazaPD9eNnYy0c EAFZw3PrNWjwd2czBtgSWad2b1W0fwamhX4KAnvF/7uxMp180Qqezo7+O66CigIGMFgk n8GSrxXy1x3uFFcFqpecYCbGALGxn2/x9cmh/BSSrXOweMNqKmUtfYCnMEaDYoVs5hOv /g7nn7IHzQnwKhi0KBXLVC/lb6RU0dIllUPR6xbnCnCEX8zoLiuLpfXCCOhcKaZfQCMX oktF1DCyLU6iigj65Tz070hRwszA24yL4Ofvq9tM+UYiGIPU6H3Y6tYNFcP27hg3S8hh 2Xvw== X-Gm-Message-State: ALoCoQnGVnujGi5TJDVl6NRerzzRgK7E8k8RaxIxf/gKwaNq6/T29nZULyTyoXU7f0lp3KHKxApb X-Received: by 10.31.47.207 with SMTP id v198mr8513917vkv.145.1446749705822; Thu, 05 Nov 2015 10:55:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.189.19 with HTTP; Thu, 5 Nov 2015 10:54:26 -0800 (PST) In-Reply-To: References: From: Yuchung Cheng Date: Thu, 5 Nov 2015 10:54:26 -0800 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=001a114336bc4c18660523cfaa0b Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 18:55:08 -0000 --001a114336bc4c18660523cfaa0b Content-Type: text/plain; charset=UTF-8 Some data points to the Linux implementation: we've found it more harmful than useful, and have disabled it at Google (internal/external) for years. Externally: IP no longer serves a good index. e.g., DHCP, NAT. Therefore most if not all metrics are brittle. Even for places where IP indexing still works: reusing ssthresh from TCP just recovered from timeout will force the new TCP to exit slow start right away On Thu, Nov 5, 2015 at 3:18 AM, Michael Welzl wrote: > Hi all, > > I just watched the video of TCPM and noticed a minor confusion at the end > about what the plan really is - because draft-welzl-tcpm-tcb-sharing just > contains a table contrasting RFC 2140 to implementations, and are we aiming > at Informational or a recommendation? > > Our plan is to update RFC 2140 to bring it in line with today's reality - > what is currently implemented. I think Informational is still fine as > status (but open to debate if people feel otherwise). > > Why didn't we write RFC2140bis but a separate document? Because one of the > chairs suggested this as a way forward, rather than doing a full first > version of RFC2140bis, given that we believed that just showing this table > and opening it for discussion is the best way to get this started. > > Cheers, > Michael > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a114336bc4c18660523cfaa0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Some data points to the Linux implementation: we've fo= und it more harmful than useful, and have disabled it at Google (internal/e= xternal) for years.=C2=A0

Externally: IP no longer serve= s a good index. e.g., DHCP, NAT. Therefore most if not all metrics are brit= tle.
Even for places where IP indexing still works: reusing ssthr= esh from TCP just recovered from timeout will force the new TCP to exit slo= w start right away

=C2=A0

=C2=A0 =C2=A0 =C2=A0

On Thu, Nov 5, 2015 at 3:18 AM, Michael Welzl &= lt;michawe@ifi.uio.= no> wrote:
Hi all,

I just watched the video of TCPM and noticed a minor confusion at the end a= bout what the plan really is - because draft-welzl-tcpm-tcb-sharing just co= ntains a table contrasting RFC 2140 to implementations, and are we aiming a= t Informational or a recommendation?

Our plan is to update RFC 2140 to bring it in line with today's reality= - what is currently implemented. I think Informational is still fine as st= atus (but open to debate if people feel otherwise).

Why didn't we write RFC2140bis but a separate document? Because one of = the chairs suggested this as a way forward, rather than doing a full first = version of RFC2140bis, given that we believed that just showing this table = and opening it for discussion is the best way to get this started.

Cheers,
Michael

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--001a114336bc4c18660523cfaa0b-- From nobody Thu Nov 5 13:51:19 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D071B3374 for ; Thu, 5 Nov 2015 13:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrys_5SEQfzs for ; Thu, 5 Nov 2015 13:51:16 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF791B335F for ; Thu, 5 Nov 2015 13:51:16 -0800 (PST) Received: from [10.123.88.103] (usc-secure-wireless-088-103.usc.edu [68.181.88.103]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id tA5LoWAc025383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Nov 2015 13:50:46 -0800 (PST) To: Yuchung Cheng , Michael Welzl References: From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <563BCF27.1010107@isi.edu> Date: Thu, 5 Nov 2015 13:50:31 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org Extensions" , touch@isi.edu Subject: Re: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 21:51:18 -0000 On 11/5/2015 10:54 AM, Yuchung Cheng wrote: ... > Externally: IP no longer serves a good index. e.g., DHCP, NAT. That's not necessarily true. In both cases, the machines that might share an IP address often share the dominant aspects of their network paths - delay, loss, max bandwidth, etc. Additionally, the shared information is used only for connection initialization. That shared information doesn't have to be accurate, only somewhat better than the current default initial values. > Therefore > most if not all metrics are brittle. > Even for places where IP indexing still works: reusing ssthresh from TCP > just recovered from timeout will force the new TCP to exit slow start > right away Agreed; that's one of the issues we're hoping to learn more about and include in the update. E.g., SSTHRESH from steady-state is a better predictor of future behavior than an immediate anomalous value - low or high. That's true for most parameters. Joe From nobody Thu Nov 5 14:51:12 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC00D1B3CE2 for ; Thu, 5 Nov 2015 14:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJBeKnID37EX for ; Thu, 5 Nov 2015 14:51:09 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95751B3CDF for ; Thu, 5 Nov 2015 14:51:09 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 024663C0AD2C3; Thu, 5 Nov 2015 22:51:03 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tA5Mp6X8027170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Nov 2015 23:51:06 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.114]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 5 Nov 2015 23:51:06 +0100 From: "Scharf, Michael (Michael)" To: Michael Welzl , "tcpm@ietf.org" Thread-Topic: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing Thread-Index: AQHRF7u9jgkMj1nC0UWDKmyHbgooBp6OCFqQ Date: Thu, 5 Nov 2015 22:51:05 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4853F73D@FR712WXCHMBA15.zeu.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: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 22:51:11 -0000 > I just watched the video of TCPM and noticed a minor confusion at the > end about what the plan really is - because draft-welzl-tcpm-tcb- > sharing just contains a table contrasting RFC 2140 to implementations, > and are we aiming at Informational or a recommendation? >=20 > Our plan is to update RFC 2140 to bring it in line with today's reality > - what is currently implemented. I think Informational is still fine as > status (but open to debate if people feel otherwise). >=20 > Why didn't we write RFC2140bis but a separate document? Because one of > the chairs suggested this as a way forward, rather than doing a full > first version of RFC2140bis, given that we believed that just showing > this table and opening it for discussion is the best way to get this > started. And this chair somehow believes that having a very short I-D is much better= than a presentation w/o any I-D... Michael From nobody Thu Nov 5 17:08:14 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05EB1A8AAA for ; Thu, 5 Nov 2015 17:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIjC2uHW06DS for ; Thu, 5 Nov 2015 17:08:10 -0800 (PST) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.232]) by ietfa.amsl.com (Postfix) with ESMTP id 547581A8BB2 for ; Thu, 5 Nov 2015 17:08:10 -0800 (PST) Received: from [10.21.68.49] (210.164.9.12) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as saropa-1) id 5613C7B100BA592B; Fri, 6 Nov 2015 03:06:57 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <13121_1446763884_563BDD6B_13121_127_1_655C07320163294895BBADA28372AF5D4853F73D@FR712WXCHMBA15.zeu.alcatel-lucent.com> Date: Fri, 6 Nov 2015 10:08:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <64E2AEB1-B61D-4C9E-85C8-C8F9C466C8B5@iki.fi> References: <13121_1446763884_563BDD6B_13121_127_1_655C07320163294895BBADA28372AF5D4853F73D@FR712WXCHMBA15.zeu.alcatel-lucent.com> To: Michael Scharf X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tcpm@ietf.org" , Michael Welzl Subject: Re: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 01:08:12 -0000 Yep, I was only interested to hear about your future plans about the = document and rfc2140bis work in general. Understood that the current = version was mainly to support the discussion, which is good. - Pasi On 06 Nov 2015, at 07:51, Scharf, Michael (Michael) = wrote: >> I just watched the video of TCPM and noticed a minor confusion at the >> end about what the plan really is - because draft-welzl-tcpm-tcb- >> sharing just contains a table contrasting RFC 2140 to = implementations, >> and are we aiming at Informational or a recommendation? >>=20 >> Our plan is to update RFC 2140 to bring it in line with today's = reality >> - what is currently implemented. I think Informational is still fine = as >> status (but open to debate if people feel otherwise). >>=20 >> Why didn't we write RFC2140bis but a separate document? Because one = of >> the chairs suggested this as a way forward, rather than doing a full >> first version of RFC2140bis, given that we believed that just showing >> this table and opening it for discussion is the best way to get this >> started. >=20 > And this chair somehow believes that having a very short I-D is much = better than a presentation w/o any I-D... >=20 > Michael >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Nov 5 19:58:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F841A884F for ; Thu, 5 Nov 2015 19:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvySa_jUKP0G for ; Thu, 5 Nov 2015 19:58:18 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3BA91A884C for ; Thu, 5 Nov 2015 19:58:17 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 8CF673EAB3D6F; Fri, 6 Nov 2015 03:58:15 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id tA63wERW011136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Nov 2015 04:58:15 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.114]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 6 Nov 2015 04:58:14 +0100 From: "Scharf, Michael (Michael)" To: Per Hurtig , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-10.txt Thread-Index: AQHRF8ZY5LBbBYtn8E6yyM1N2lrc2p6NTiUAgAEQ5HA= Date: Fri, 6 Nov 2015 03:58:14 +0000 Message-ID: <655C07320163294895BBADA28372AF5D4853FE8A@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20151105123434.28554.91757.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rtorestart-10.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 03:58:20 -0000 TG9va3MgZ29vZCB0byBtZQ0KDQpUaHgNCg0KTWljaGFlbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IHRjcG0gW21haWx0bzp0Y3BtLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBQZXIgSHVydGlnDQo+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwNSwgMjAx NSAxOjQxIFBNDQo+IFRvOiB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMNCj4gU3ViamVjdDogUmU6 IFt0Y3BtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXRjcG0tcnRvcmVzdGFydC0xMC50eHQNCj4g DQo+IEhpIGFsbCwNCj4gDQo+IGFzIG5vIG9iamVjdGlvbnMgd2VyZSBtYWRlIHRvIHRoZSBzdWdn ZXN0ZWQgY2hhbmdlIGluIHRoZSBhYnN0cmFjdCwNCj4gd2XigJl2ZSBub3cgc3VibWl0dGVkIGEg bmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KPiANCj4gDQo+IFRoYXQgaXMsIGNoYW5nZWQgZnJv bSBkcmFmdC1pZXRmLS4uLi0wOSB0byAtMTANCj4gDQo+ICAgIG8gIENoYW5nZWQgd29yZGluZyBp biBhYnN0cmFjdCwgZnJvbSAiZGVsYXkiIHRvICJ0aW1lb3V0IGR1cmF0aW9u4oCdLg0KPiANCj4g DQo+IENoZWVycywNCj4gUGVyIEh1cnRpZw0KPiA+IE9uIDA1IE5vdiAyMDE1LCBhdCAxMzozNCwg aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiA+DQo+ID4NCj4gPiBBIE5ldyBJbnRl cm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMN Cj4gZGlyZWN0b3JpZXMuDQo+ID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgVENQ IE1haW50ZW5hbmNlIGFuZCBNaW5vciBFeHRlbnNpb25zDQo+IFdvcmtpbmcgR3JvdXAgb2YgdGhl IElFVEYuDQo+ID4NCj4gPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogVENQIGFuZCBTQ1RQIFJU TyBSZXN0YXJ0DQo+ID4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFBlciBIdXJ0aWcNCj4gPiAg ICAgICAgICAgICAgICAgICAgICAgICAgQW5uYSBCcnVuc3Ryb20NCj4gPiAgICAgICAgICAgICAg ICAgICAgICAgICAgQW5kcmVhcyBQZXRsdW5kDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAg IE1pY2hhZWwgV2VsemwNCj4gPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi10Y3BtLXJ0 b3Jlc3RhcnQtMTAudHh0DQo+ID4gCVBhZ2VzICAgICAgICAgICA6IDE3DQo+ID4gCURhdGUgICAg ICAgICAgICA6IDIwMTUtMTEtMDUNCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgVGhpcyBkb2N1 bWVudCBkZXNjcmliZXMgYSBtb2RpZmllZCBzZW5kZXItc2lkZSBhbGdvcml0aG0gZm9yDQo+IG1h bmFnaW5nDQo+ID4gICB0aGUgVENQIGFuZCBTQ1RQIHJldHJhbnNtaXNzaW9uIHRpbWVycyB0aGF0 IHByb3ZpZGVzIGZhc3RlciBsb3NzDQo+ID4gICByZWNvdmVyeSB3aGVuIHRoZXJlIGlzIGEgc21h bGwgYW1vdW50IG9mIG91dHN0YW5kaW5nIGRhdGEgZm9yIGENCj4gPiAgIGNvbm5lY3Rpb24uICBU aGUgbW9kaWZpY2F0aW9uLCBSVE8gUmVzdGFydCAoUlRPUiksIGFsbG93cyB0aGUNCj4gPiAgIHRy YW5zcG9ydCB0byByZXN0YXJ0IGl0cyByZXRyYW5zbWlzc2lvbiB0aW1lciB1c2luZyBhIHNtYWxs ZXINCj4gdGltZW91dA0KPiA+ICAgZHVyYXRpb24sIHNvIHRoYXQgdGhlIGVmZmVjdGl2ZSBSVE8g YmVjb21lcyBtb3JlIGFnZ3Jlc3NpdmUgaW4NCj4gPiAgIHNpdHVhdGlvbnMgd2hlcmUgZmFzdCBy ZXRyYW5zbWl0IGNhbm5vdCBiZSB1c2VkLiAgVGhpcyBlbmFibGVzDQo+IGZhc3Rlcg0KPiA+ICAg bG9zcyBkZXRlY3Rpb24gYW5kIHJlY292ZXJ5IGZvciBjb25uZWN0aW9ucyB0aGF0IGFyZSBzaG9y dC1saXZlZCBvcg0KPiA+ICAgYXBwbGljYXRpb24tbGltaXRlZC4NCj4gPg0KPiA+DQo+ID4gVGhl IElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10Y3BtLXJ0b3Jlc3RhcnQv DQo+ID4NCj4gPiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoN Cj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10Y3BtLXJ0b3Jlc3Rh cnQtMTANCj4gPg0KPiA+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWls YWJsZSBhdDoNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0 Zi10Y3BtLXJ0b3Jlc3RhcnQtMTANCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lv bg0KPiA+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZh aWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy8NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gPiB0Y3BtQGlldGYub3JnDQo+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQoNCg== From nobody Thu Nov 5 20:59:32 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C713A1B358D for ; Thu, 5 Nov 2015 20:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDCYua-qnBGx for ; Thu, 5 Nov 2015 20:59:29 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E2A1B358C for ; Thu, 5 Nov 2015 20:59:29 -0800 (PST) Received: by ykba4 with SMTP id a4so170861584ykb.3 for ; Thu, 05 Nov 2015 20:59:29 -0800 (PST) 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; bh=iGdxBOg6Cl66dZGJXBT+jxxif3mMPJSS4XbNn1qOamk=; b=DE65XHq/Qe/5PBQDTTs/HT0cc3P35nhajFd02dSz9i472+jXc2uc7ftMXPFhwFczYn Vq4PnZ8crD0/LJ6qnoFgjeqRtQQE7S3AkflzuDRa2rBZQcoJRS1b+YNiznlx3+8FR8ec 4uLLn8RLOXEn+euy1iwdLa2Eib2D7Lqahgv7g6RMOuxEoQAtAxGysKik5yxPin+v6Jqp j4h4b0UTPJTcVFbpjhLrH2CI9Oh0rF6a1PNrxWvYuUswtGOvPVKUYsZ+OtI7zIKRSXLs ejwAVx7/ynKBpftVrD5VyrqkaOv90TaB/bCSohdiS0d4KgDfmZ/xp/yMDeIp5322Giw7 NFQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iGdxBOg6Cl66dZGJXBT+jxxif3mMPJSS4XbNn1qOamk=; b=IMDD5+OC60FnThwv/WVQzb8cJM0tPavKaCqlf3fCipeBTIvJRGA1xIEv4HzzBJrAEo 6DZz2BaSK6FlgOqCsHIUPAT8OWqXadkOE0Sw9yF/MSQ/ptqE3dT+3RLGeenytXMd8qWI qG7a1A3ozxjTchRoeEsbuUPYmUPUTxvEvEuuy3vhKzaBs918q5WOVPPah4zm4d/P/e8B 8qbmSEYr8jbrIklYlZgcoBLtwUNttR92kDZKDrB2SaemLtioXSJdXxJSkms079vQiAce kGcIb3GAEH7dttUaRzCma+a1kGKhdJ1fE1BZTcq+JifswToINovh++PfuFwfM9KWytEK z9jw== X-Gm-Message-State: ALoCoQkfR75MtEuvuiFmxYTfCMxoOSVf7BjVKc2tfMB4yoMdtd8GJO0z6R6k/jKMfRvCN7TYcraW X-Received: by 10.31.5.144 with SMTP id 138mr10671679vkf.62.1446785968851; Thu, 05 Nov 2015 20:59:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.189.19 with HTTP; Thu, 5 Nov 2015 20:58:49 -0800 (PST) In-Reply-To: <563BCF27.1010107@isi.edu> References: <563BCF27.1010107@isi.edu> From: Yuchung Cheng Date: Thu, 5 Nov 2015 20:58:49 -0800 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org Extensions" , Michael Welzl Subject: Re: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 04:59:30 -0000 On Thu, Nov 5, 2015 at 1:50 PM, Joe Touch wrote: > > > > On 11/5/2015 10:54 AM, Yuchung Cheng wrote: > ... > > Externally: IP no longer serves a good index. e.g., DHCP, NAT. > > That's not necessarily true. In both cases, the machines that might > share an IP address often share the dominant aspects of their network > paths - delay, loss, max bandwidth, etc. > > Additionally, the shared information is used only for connection > initialization. That shared information doesn't have to be accurate, > only somewhat better than the current default initial values. Intuitively yes. But our tests show little difference in terms of latency, loss rate, etc with or without the Linux IP metrics cache. And disabling not only save cache write/read but also skip the pathological cases. Today a phone can have multiple public IP addresses and an IP address can be used for multiple phones simultaneously (with different ports). The RTT, link quality, and BW can all be very different. This makes IP a less reliable index for server cache or CB sharing even only for seeding phase. I am not claiming it's universally useless. I am presenting a data point primarily on servers. > > > > Therefore > > most if not all metrics are brittle. > > Even for places where IP indexing still works: reusing ssthresh from TCP > > just recovered from timeout will force the new TCP to exit slow start > > right away > > Agreed; that's one of the issues we're hoping to learn more about and > include in the update. E.g., SSTHRESH from steady-state is a better > predictor of future behavior than an immediate anomalous value - low or > high. That's true for most parameters. > > Joe From nobody Thu Nov 5 23:57:30 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA95B1B3681 for ; Thu, 5 Nov 2015 23:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDxe5tBcP839 for ; Thu, 5 Nov 2015 23:57:28 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895D81B36B0 for ; Thu, 5 Nov 2015 23:57:28 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zubtm-0008Mx-Cr; Fri, 06 Nov 2015 08:57:26 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zubtl-0003Ib-V3; Fri, 06 Nov 2015 08:57:26 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Fri, 6 Nov 2015 08:57:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6E47AFA6-5BC9-43BB-BA9D-912F171F6A2D@ifi.uio.no> References: <563BCF27.1010107@isi.edu> To: Yuchung Cheng X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 4 sum rcpts/h 13 sum msgs/h 5 total rcpts 34877 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8D6DD4FAD97C833E5CC3298F6F3B3A7BA82529CA X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 8255 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org Extensions" , Joe Touch Subject: Re: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 07:57:30 -0000 > On 06 Nov 2015, at 05:58, Yuchung Cheng wrote: >=20 > On Thu, Nov 5, 2015 at 1:50 PM, Joe Touch wrote: >>=20 >>=20 >>=20 >> On 11/5/2015 10:54 AM, Yuchung Cheng wrote: >> ... >>> Externally: IP no longer serves a good index. e.g., DHCP, NAT. >>=20 >> That's not necessarily true. In both cases, the machines that might >> share an IP address often share the dominant aspects of their network >> paths - delay, loss, max bandwidth, etc. >>=20 >> Additionally, the shared information is used only for connection >> initialization. That shared information doesn't have to be accurate, >> only somewhat better than the current default initial values. > Intuitively yes. But our tests show little difference in terms of > latency, loss rate, etc with or without the Linux IP metrics cache. > And disabling not only save cache write/read but also skip the = pathological > cases. >=20 > Today a phone can have multiple public IP addresses and an IP address > can be used for multiple phones simultaneously (with different ports). > The RTT, link > quality, and BW can all be very different. This makes IP a less > reliable index for server cache or CB sharing even only for seeding = phase. >=20 > I am not claiming it's universally useless. I am presenting a data > point primarily on servers. Sounds like at least some text explaining these potential problems with = relying on the IP address is needed for the planned RFC2140bis. Which I = think is quite appropriate. Thanks for the data point! Cheers, Michael From nobody Fri Nov 6 09:05:48 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B061B3C3E; Thu, 5 Nov 2015 14:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGhaJ7suQXvH; Thu, 5 Nov 2015 14:12:47 -0800 (PST) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B7A1B3C5C; Thu, 5 Nov 2015 14:12:34 -0800 (PST) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA5MCPfs011130 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Nov 2015 17:12:29 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com tA5MCPfs011130 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1446761550; bh=p7slh11xCBPZW7UKivI93ISssgM=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=qzohdkRB0VIqrUJxFDDyfhjVQhOoQhy5jsM/hn8o3lOoA1zFtiyydgE1XXW+ba5ti HfGsEHt5xjlvUj+wHPA2BuyBa4JFryNo2cZR1zgxbtPg4tOyZJRBkNniwQF7GYtrkW Of+b4fbpSfxvC6Zv69zHC0hPKdbXGFtf5xtdjdWc= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com tA5MCPfs011130 Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd52.lss.emc.com (RSA Interceptor); Thu, 5 Nov 2015 17:09:21 -0500 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tA5MC0iP021227 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Nov 2015 17:12:00 -0500 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub12.corp.emc.com (10.254.92.107) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 5 Nov 2015 17:12:00 -0500 Received: from MX104CL02.corp.emc.com ([169.254.8.60]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.03.0266.001; Thu, 5 Nov 2015 17:11:59 -0500 From: "Black, David" To: David Ros , Ingemar Johansson S Thread-Topic: [tsvwg] [tcpm] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt Thread-Index: AQHRF7Ki3vC7vQ9vN0Sh5QFpKTDhQp6N/lPQ Date: Thu, 5 Nov 2015 22:11:57 +0000 Message-ID: References: <20151014181702.10618.83714.idtracker@ietfa.amsl.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34BF4F0F@ESESSMB205.ericsson.se> <56325D2D.1070107@bobbriscoe.net> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658@ESESSMB205.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.42.75] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362137FE78MX104CL02corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public Archived-At: X-Mailman-Approved-At: Fri, 06 Nov 2015 09:05:46 -0800 Cc: Michael Welzl , "Black, David" , "tcpm@ietf.org" , "tsvwg@ietf.org" , "iccrg@irtf.org" Subject: Re: [tcpm] [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 05 Nov 2015 22:12:58 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362137FE78MX104CL02corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a tsvwg chair, I concur that ICCRG would be a good initial home for this= draft. Thanks, --David From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of David Ros Sent: Thursday, November 05, 2015 5:13 AM To: Ingemar Johansson S Cc: tcpm@ietf.org; iccrg@irtf.org; tsvwg@ietf.org; Michael Welzl Subject: Re: [tsvwg] [tcpm] FW: New Version Notification for draft-johansso= n-cc-for-4g-5g-00.txt Ingemar, We believe this is a useful document, agree that it's a good match for ICCR= G, and would be happy with ICCRG being the home of this draft. Thanks, Michael & David (as ICCRG chairs) On 04 Nov 2015, at 22:27, Ingemar Johansson S > wrote: Hi And thanks for the review, comments/answers/questions inline below /Ingemar From: Bob Briscoe [mailto:ietf@bobbriscoe.net] Sent: den 29 oktober 2015 18:54 To: Ingemar Johansson S; iccrg@irtf.org; tcpm@ietf.o= rg; tsvwg@ietf.org Subject: Re: [tsvwg] FW: New Version Notification for draft-johansson-cc-fo= r-4g-5g-00.txt Ingemar, As promised, here's my comments. They are a mix of suggested improvements t= o the draft, suggested improvements to 5G, or requests for clarification. I= also agree with all Kevin Smith's comments, so I didn't repeat any. [Sorry for delay - I had to find time to re-type after losing my review dur= ing a power outage] Context questions. Q1. Is this exercise treating the 5G specs solely in read-only mode? Or, if= some useful design suggestions arise, is there any chance that the 3GPP mi= ght take them on board, given 5G is not fully baked yet? [IJ] Guess it depends, need to say that I probably the small cog in the whe= el. I would say that a lot of the standards work in IETF has been picked up= by 3GPP and, I cannot say what will happen in the 5G context. It's great that you have taken this initiative. Does the 3GPP ever formally= ask the IETF for comments on its ideas for each new generation of radio? G= iven the layers above can be thought of as the 'customers' of the 3GPP, and= these 'customer' layers are pretty much all maintained by the IETF, it wou= ld seem essential (and courteous) for the 3GPP to ask for customer comment,= not least to co-ordinate with whatever future plans the IETF might have fo= r the higher layers. [IJ] What you say makes much sense. I guess there is some natural leakage b= etween 3GPP and IETF as many of the IETFers are also active in 3GPP standar= dization. I don't have full insight in the formal relation between 3GPP and= IETF in these areas, not sure if that need to be better, but if that is th= e case, then it is probably a question for the area directors. Need to say = that even though the formal channels are scarce it does probably not mean t= hat 3GPP ignores IETF or what happens above IP in general. For instance the= recent work around TCP RACK raises the question if it is necessary that LT= E default radio bearers ensure in order delivery. Q2. What are your plans for this draft? Are you asking for adoption? And if= so, in which WG or RG? ICCRG looks the most appropriate, given the charter= s of all the IETF cc WGs (TSVWG, TCPM, RMCAT, etc) are scoped on just a sub= set of your doc. [IJ] First objective is to get an increased interest in congestion control = algorithm work in the IETF. Traditionally this kind of work seem to be more= in the terms of conference papers in e.g. Sigcomm, the benefit with having= such work in IETF is that input from people with a wider expertise area (i= ncluding 3GPP experitise) can give algorithm proposals that work well for a= wider set of access types. The work around Cubic is a first good step as i= s the work around DCTCP. What I wonder is if it feasible to take this a bit= further ? I would too believe that the current doc fits better in ICCRG. = The algorithm examples are just.. examples. More fruitful work is probably = to document different access types and from there derive a set of best curr= ent practices for congestion control algorithms Section by Section Review All sections The document generally talks about the LTE protocol stack as if data is tra= velling down it. Are you implying that most sources of buffering delay are = at the sending end, and the feedback end is pretty unencumbered by delays? = I think it would be useful to explicitly say something about this (whether = true or not), to explain why only one direction of travel is discussed in t= he doc. [IJ] The feedback path is encumbered by delays, it is perhaps not that clea= r but section 2.3.2 implies that delay (variation) in uplink will affect th= e ACKs for downlink data traffic. That said, the difference in DL/UL traffi= c is today something like 10:1 and that is probably one reason why one can = get the feeling that the draft is slanted towards downlink data traffic, th= is may however change with time as more machine type traffic may enter the = system. 2.1 PDCP layer PDCP also ensures that all packets are delivered in order up to higher layers. I think this means "in the order sent into the link (PDCP) layer". This oug= ht to be clarified, otherwise, when writing in the context of a layer 4 aud= ience, it might be assumed this means in the order sent by the original tra= nsport layer source. [IJ] Yes, you are right , reordering can still occur e.g. in the wireless b= ackhaul keep the amount of data in flight as small as possible, without sacrific= ing throughput. Is this just a rather convoluted way of saying "keep the RTT as low as poss= ible"? (which in turn implies keeping queuing delay as low as possible assu= ming you cannot influence the physical path.) Or were you trying to make a = more subtle point? - if so, it was lost on me. [IJ] No, it is exactly as you describe below Reliable delivery at handover may however be turned off or is simply not= implemented, It would be useful if you could give a feel for roughly how often (in %) th= ese cases hold. [IJ] I don't believe that it is possible to give a figure as this is vendor= specific. 2.2 RLC layer role ... is to ensure that packets are delivered in order up to the high= er layers Eh? The PDCP section just said it did ordering. And the rest of the RLC sec= tion talks exclusively about buffering delays necessary while filling trans= port blocks. If ordering is the role of both layers, surely one will have n= othing to do once the other has got everything in order? [IJ] RLC handles ordering due to various MAC layer failures. PDCP handles o= rdering when handover occurs varying size of the available transport Nit: Given 'transport' means e2e for the audience of this draft, pls use be= arer or somehow disambiguate this word. [IJ] OK Gap#1: In the draft, it seems like transport blocks arrive by magic, to be = filled by data buffered in the RLC layer. To understand the delay compromis= es here, I think the draft needs to explain what determines how much transp= ort block capacity each flow is given, and how they can influence it. In 3G= , I believe that the transport layer could ask the radio resource controlle= r to change radio resource allocation. Is this the same in 4G & 5G? Does th= e backlog of the buffer into the RLC layer have any automatic influence ove= r allocation of available resources? I assume traffic class can also be use= d to influence allocation. [IJ] Will updated with more detail Gap#2: In a 3G stack, the RLC layer multiplexes all the active application = streams into MAC layer transport block by dicing up buffered packets and pa= cking the pieces into each transport block. Then, at the other end of the l= ink, each piece has to be held until the rest of the packet arrives. This s= acrifices delay for bandwidth efficiency. Is this still done in 4G and 5G? = If so, it would be good to write about mux delay in the draft too. [IJ] OK, will add more info 2.3 MAC layer the maximum number of retransmissions is configurable Wouldn't it be better to set a limit on the time spent retransmitting, so i= t would automatically give up with less retransmissions for longer transmis= sion distances? [IJ] Possible, 4G specifies a limit to the number of retransmissions, in pr= actice it can be translated to time as each retransmission is 8ms later. s/only checks for the presence on download data only at regular intervals/ /only checks for the presence of download data at regular intervals/ [OK] 2.3.2 Uplink scheduling The scheduling request does not indicate how many bytes there are in the= uplink queue. Seems like a bad omission. Is there a reason? If there are less bytes queue= d than the base station's grant, surely it would be useful for the base sta= tion to know, so that it can grant more to something else while the previou= s short transmission is completing. [IJ] It is a design choice. A buffer status report is more bulky, a schedul= ing request is just one bit. You say that when HARQ breaks up a sequence of ACKs, it can also trigger "c= oalescing issues". I can understand that it could cause ACK compression, bu= t are you implying something coalesces the ACKs or the subsequent data? Wha= t does the coalescing? Similarly, in the last para of 2.3.2 you say "Reduce= d ACKs can unfortunately cause coalescing." and again I'm not sure what is = coalescing what here. [IJ] What I can see in simulations is that the ACK compression leads to coa= lescing which further can increase jitter. There could be a positive side to the interaction between ACK clocking and = link aggregation, at least for long-running flows. This has been observed i= n 802.11n WiFi where the buffering and aggregation of multiple ACKs into on= e transmission grant tend to lead the sender to bunch multiple data segment= s so that they all nicely fill one transmission grant in the other directio= n [Showail14]. As long as the transmission grant does not wait for more dat= a (which unfortunately I don't think is the case in 3G/4G/5G), this could b= e good for bandwidth utilisation of elephants and latency of mice, includin= g when they are mixed. [Showail14] Showail, A., Jamshaid, K. & Shihada, B., "WQM: An Aggregation-a= ware Queue Management Scheme for IEEE 802.11N Based Networks," In: Proceedi= ngs of the 2014 ACM SIGCOMM Workshop on Capacity Sharing Workshop CSWS '14 = pp.15-20 ACM (2014) [IJ] Interesting ,will look at it, not sure though that it will work that w= ell with 4G (cant say anything about 5G), in 4G the transmission grants can= vary quite a lot over short time spans. 3. 4G and 5G evolution s/a explicit/an explicit/ 4. Requirements for improved performance s/bufferbloat/buffer/ 5. Congestion control examples Regarding Hybrid Cubic using OWD measurements, I have seen a paper (under s= ubmission) about getting delay-based congestion controls (e.g. LEDBAT or CA= IA Delay Gradient) to interwork with AQMs with various low delay targets. I= t's not in the context of cellular networks, but I'll try to remember to po= int it out once it gets published. [IJ] Sounds interesting , looking forward to see the paper. 5.1 HyStartRestart s/algorithm used/algorithm is used/ In the new code, it would be useful to explain why the second test before d= oubling ssthresh, ie, the test for how long it has been since the last hyre= start. Also, in the header definitions, if you intend there to be constrain= ts on the relation between N_RTT_HYRESTART and N_RTT_LOW (e.g. N_RTT_HYRES= TART > N_RTT_LOW) you ought to say, because people will try other values. Rather than the rather arbitrary wait before an arbitrary doubling of ssthr= esh, wouldn't it be better to continually increase ssthresh (not necessaril= y linearly) the longer the RTT has remained only just higher than the min R= TT? [IJ] Yes, could be an option (BTW, surely the main problem with this modification to HyStartRestart is t= hat is requires a number of round trips to reduce delay - a sort-of oxymoro= n.) [IJ] Yes, have tried some more experiments with this algorithm. And I am ge= tting more hesitant. The problem is that when I add more noise (modeling of= small objects traffic) into the system simulation, then I also get more de= lay jitter and the delay detection algorithm in HyStart is notoriously sens= itive to delay jitter. 5.2. Hybrid Cubic Furthermore it is assumed than the timestamp clock frequency in sender and receiver are identical or that the sender can infer the timestamp clock frequency of the receiver and recompute timestamp values based on this information. Recently on tcpm I sent you a pointer to the chirping paper Mirja & I did, = which also made this assumption. Partly prompted by that, Richard Scheffene= gger tried to get people interested in standardising use of the timestamp o= ption on a SYN to negotiate stuff like timer resolution. I don't think it w= ent anywhere. Do you think we ought to revitalise that? You mention inferen= ce - have you tried that - are there cases where it doesn't work? [IJ] Yes, actually wondered what happened to Richards draft. I only briefly= tried out the inference algorithm with a TCP LEDBAT implementation (https:= //github.com/silviov/TCP-LEDBAT/blob/master/src/tcp_ledbat.c). I recall tha= t it took a while to converge. Also I am not sure here. Is Hz in e.g a linu= x stack fixed. ? That's it. Thanks again for the draft. V useful. Bob On 15/10/15 06:08, Ingemar Johansson S wrote: Hi A new IETF draft is submitted in response to general discussion that for in= stance TCP Cubic is not an appropriate congestion control algorithm for LTE= . The draft briefly outlines typical 4G access behavior on the PDCP, RLC and = MAC layers that can have an impact on transport protocol performance. The = draft also outlines two relatively simple modifications to the Cubic conges= tion control. /Ingemar -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: den 14 oktober 2015 20:17 To: Ingemar Johansson S Subject: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt A new version of I-D, draft-johansson-cc-for-4g-5g-00.txt has been successfully submitted by Ingemar Johansson and posted to the IETF= repository. Name: draft-johansson-cc-for-4g-5g Revision: 00 Title: Congestion control for 4G and 5G access Document date: 2015-10-14 Group: Individual Submission Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-johansson-cc-for= -4g-5g-00.txt Status: https://datatracker.ietf.org/doc/draft-johansson-cc-for-4g-= 5g/ Htmlized: https://tools.ietf.org/html/draft-johansson-cc-for-4g-5g-00 Abstract: This memo outlines the challenge that 4G and 5G access brings for transport protocol congestion control and also outlines a few simple examples that can improve transport protocol congestion control performance in 4G and 5G access. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --_000_CE03DB3D7B45C245BCA0D243277949362137FE78MX104CL02corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As a tsvwg chair, I concur t= hat ICCRG would be a good initial home for this draft.

 

Thanks,
--David

 

From: tsvwg [m= ailto:tsvwg-bounces@ietf.org] On Behalf Of David Ros
Sent: Thursday, November 05, 2015 5:13 AM
To: Ingemar Johansson S
Cc: tcpm@ietf.org; iccrg@irtf.org; tsvwg@ietf.org; Michael Welzl
Subject: Re: [tsvwg] [tcpm] FW: New Version Notification for draft-j= ohansson-cc-for-4g-5g-00.txt

 

Ingemar,

 

We believe this is a useful document, agree that it'= s a good match for ICCRG, and would be happy with ICCRG being the home of t= his draft.

 

Thanks,

 

Michael & David (as ICCRG chairs)

 

 

On 04 Nov 2015, at 22:27, Ingemar Johansson S <ingemar.s.johansson@erics= son.com> wrote:



Hi

 

And thanks for the review= , comments/answers/questions inline below

 

/Ingemar

 

From: Bob Briscoe [mailto:ietf@bobbriscoe.net] 
Sent: den 29 oktob= er 2015 18:54
To: Ingemar Johans= son S; iccrg@irtf.org; tcpm@ietf.org; tsvwg@ietf.org
Subject: Re: [tsvw= g] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt

 

Ing= emar,

As promised, here's my comments. They are a mix of suggested improvements t= o the draft, suggested improvements to 5G, or requests for clarification. I= also agree with all Kevin Smith's comments, so I didn't repeat any.
[Sorry for delay - I had to find time to re-type after losing my review dur= ing a power outage]

Context questions.
Q1. Is this exercise treating the 5G specs solely in read-only mode? Or= , if some useful design suggestions arise, is there any chance that the 3GP= P might take them on board, given 5G is not fully baked yet?

[IJ] Guess it depends, need to say that I probably the small cog in t= he wheel. I would say that a lot of the standards work in IETF has been picked up by 3GPP and, I cannot say what will happen in the = 5G context. 

It's great that you have taken this initiative. Does the 3GPP ever formally ask th= e IETF for comments on its ideas for each new generation of radio? Given th= e layers above can be thought of as the 'customers' of the 3GPP, and these 'customer' layers are pretty much all maintained by= the IETF, it would seem essential (and courteous) for the 3GPP to ask for = customer comment, not least to co-ordinate with whatever future plans the I= ETF might have for the higher layers.

[IJ] What you say makes much sense. I guess there is some natural lea= kage between 3GPP and IETF as many of the IETFers are also active in 3GPP standardization. I don’t have full insight in the for= mal relation between 3GPP and IETF in these areas, not sure if that need to= be better, but if that is the case, then it is probably a question for the= area directors. Need to say that even though the formal channels are scarce it does probably not mean that 3GPP = ignores IETF or what happens above IP in general. For instance the recent w= ork around TCP RACK raises the question if it is necessary that LTE default= radio bearers ensure in order delivery.



Q2. What are your plans for this draft? Are you asking for adoption? And if so, in= which WG or RG? ICCRG looks the most appropriate, given the charters of al= l the IETF cc WGs (TSVWG, TCPM, RMCAT, etc) are scoped on just a subset of your doc.

[IJ] First objective is to get an increased interest in congestion co= ntrol algorithm work in the IETF. Traditionally this kind of work seem to be more in the terms of conference papers in e.g. Sigcomm,= the benefit with having such work in IETF is that input from people with a= wider expertise area (including 3GPP experitise) can give algorithm propos= als that work well for a wider set of access types. The work around Cubic is a first good step as is the work= around DCTCP. What I wonder is if it feasible to take this a bit further ?= I would too believe that the current doc fits better in ICCRG.  The a= lgorithm examples are just.. examples. More fruitful work is probably to document different access types and from= there derive a set of best current practices for congestion control algori= thms



Section by Section Review

All sections

The document generally talks about the LTE protocol stack as if data is tra= velling down it. Are you implying that most sources of buffering delay are at the = sending end, and the feedback end is pretty unencumbered by delays? I think it would be useful to explicitly say somet= hing about this (whether true or not), to explain why only one direction of= travel is discussed in the doc.

[IJ] The feedback path is encumbered by delays, it is perhaps not tha= t clear but section 2.3.2 implies that delay (variation) in uplink will affect the ACKs for downlink data traffic. That said, the diff= erence in DL/UL traffic is today something like 10:1 and that is probably o= ne reason why one can get the feeling that the draft is slanted towards dow= nlink data traffic, this may however change with time as more machine type traffic may enter the system.=



2.1 PDCP layer

    PDCP also ensures that all
   packets are delivered in order up to higher layers. I think this means "in the order sent into th= e link (PDCP) layer". This ought to be clarified, otherwise, when writ= ing in the context of a layer 4 audience, it might be assumed this means in= the order sent by the original transport layer source.

[IJ] Yes, you are right , reordering can still occur e.g. in the wire= less backhaul



   keep the amount of data i= n flight as small as possible, without sacrificing throughput.<= span style=3D"font-size:10.0pt;font-family:"Courier New","se= rif"">
Is this just a rather convoluted way of saying &qu= ot;keep the RTT as low as possible"? (which in turn implies keeping qu= euing delay as low as possible assuming you cannot influence the physical p= ath.) Or were you trying to make a more subtle point? - if so, it was lost on me.

[IJ] No, it is exactly as you describe below=



   Reliable delivery at hand= over may however be turned off or is simply not implemented,
It would be useful if you could give a feel for roughly how often (i= n %) these cases hold.

[IJ] I don’t believe that it is possible to give a figure as th= is is vendor specific.



2.2 RLC layer

   role ... is to ensure tha= t packets are delivered in order up to the higher layers
Eh? The PDCP section just said it did ordering. And the rest of the RLC sec= tion talks exclusively about buffering delays necessary while filling trans= port blocks. If ordering is the role of both layers, surely one will have nothing to do once the other has got everythi= ng in order?

[IJ] RLC handles ordering due to various MAC layer failures. PDCP han= dles ordering  when handover occurs



   varying size of the avail= able transport
Nit: Given 'transport' means e2e for the audience of this draft, pls= use bearer or somehow disambiguate this word.=

[IJ] OK




Gap#1: In the draft, it seems like transport blocks arrive by magic, to be = filled by data buffered in the RLC layer. To understand the delay compromises here= , I think the draft needs to explain what determines how much transport block capacity each flow is given, and how t= hey can influence it. In 3G, I believe that the transport layer could ask t= he radio resource controller to change radio resource allocation. Is this t= he same in 4G & 5G? Does the backlog of the buffer into the RLC layer have any automatic influence over allocat= ion of available resources? I assume traffic class can also be used to infl= uence allocation.

[IJ] Will updated with more detail



Gap#2: In a 3G stack, the RLC layer multiplexes all the active application = streams into MAC layer transport block by dicing up buffered packets and pa= cking the pieces into each transport block. Then, at the other end of the link, each piece has to be held until the rest of = the packet arrives. This sacrifices delay for bandwidth efficiency. Is this= still done in 4G and 5G? If so, it would be good to write about mux delay = in the draft too.

[IJ] OK, will add more info



2.3 MAC layer

   the maximum number of ret= ransmissions is configurable

Wouldn't it be better to set a limit on the time <= /span>spent retransmitting, so it would automatically give up with less ret= ransmissions for longer transmission distances?
[IJ] Possible, 4G specifies a limit to the nu= mber of retransmissions, in practice it can be translated to time as each r= etransmission is 8ms later.

 


s/only checks for the presence on download data only at regular intervals/<= br>  /only checks for the presence of download data at regular intervals/<= br> [OK]

 


2.3.2 Uplink scheduling

   The scheduling request do= es not indicate how many bytes there are in the uplink queue.
Seems like a bad omission. Is there a reason? If t= here are less bytes queued than the base station's grant, surely it would b= e useful for the base station to know, so that it can grant more to somethi= ng else while the previous short transmission is completing.
[IJ] It is a design choice. A buffer s= tatus report is more bulky, a scheduling request is just one bit.

 


You say that when HARQ breaks up a sequence of ACKs, it can also trigger &q= uot;coalescing issues". I can understand that it could cause ACK compression,= but are you implying something coalesces the ACKs or the subsequent data? What does the coalescing? Similarly, in the last para of 2.3.2 you s= ay "Reduced ACKs can unfortunately cause coalescing." and again I= 'm not sure what is coalescing what here.

[IJ] What I can see in simulations is that the ACK compression leads = to coalescing which further can increase jitter.


There could be a positive side to the interaction between ACK clocking and = link aggregation, at least for long-running flows. This has been observed in 802.1= 1n WiFi where the buffering and aggregation of multiple ACKs into one transmission grant tend to lead the sender to bu= nch multiple data segments so that they all nicely fill one transmission gr= ant in the other direction [Showail14]. As long as the transmission grant does not wait for more data (which unfortunately I don't think is th= e case in 3G/4G/5G), this could be good for bandwidth utilisation of elepha= nts and latency of mice, including when they are mixed.

[Showail14] Showail, A., Jamshaid, K. & Shihada, B., "WQM: An Aggr= egation-aware Queue Management Scheme for IEEE 802.11N Based Networks,"= ; In: Proceedings of the 2014 ACM SIGCOMM Workshop on Capacity Sharing Work= shop CSWS '14 pp.15-20 ACM (2014)
<http://dl.acm.org/citation.c= fm?id=3D2630097>
[IJ] Interesting ,will look at it, not sure t= hough that it will work that well with 4G (cant say anything about 5G), in = 4G the transmission grants can vary quite a lot over short time spans.

 


3.  4G and 5G evolution

s/a explicit/an explicit/

4.  Requirements for improved performance

s/bufferbloat/buffer/

5.  Congestion control examples

Regarding Hybrid Cubic using OWD measurements, I have seen a paper (under s= ubmission) about getting delay-based congestion controls (e.g. LEDBAT or CA= IA Delay Gradient) to interwork with AQMs with various low delay targets. I= t's not in the context of cellular networks, but I'll try to remember to point it out once it gets published.=

[IJ] Sounds interesting , looking forward to see the paper.



5.1 HyStartRestart

s/algorithm used/algorithm is used/

In the new code, it would be useful to explain why the second test before d= oubling ssthresh, ie, the test for how long it has been since the last hyre= start. = Also, in the header definitions, if you intend there to be constraints on the relation between N_RTT_HYRESTART and N_RTT_= LOW (e.g.  N_RTT_HYRESTART > N_RTT_LOW) you ought to say, because p= eople will try other values.

Rather than the rather arbitrary wait before an arbitrary doubling of ssthr= esh, wouldn't it be better to continually increase ssthresh (not necessaril= y linearly) the longer the RTT has remained only just higher than the min R= TT?

[IJ] Yes, could be an option



(BTW, surely the main problem with this modification to HyStartRestart is t= hat is requires a number of round trips to reduce delay - a sort-of oxymoro= n.)

[IJ] Yes, have tried some more experiments with this algorithm. And I= am getting more hesitant. The problem is that when I add more noise (modeling of small objects traffic) into the system simulation,= then I also get more delay jitter and the delay detection algorithm in HyS= tart is notoriously sensitive to delay jitter.



5.2.  Hybrid Cubic

   Furthermore it is assumed than the time=
stamp clock frequency in
   sender and receiver are identical or th=
at the sender can infer the
   timestamp clock frequency of the receiv=
er and recompute timestamp
   values based on this information.<=
/o:p>

Rec= ently on tcpm I sent you a pointer to the chirping paper Mirja & I did,= which also made this assumption. Partly prompted by that, Richard Scheffen= egger tried to get people interested in standardising use of the timestamp option on a SYN to negotiate stuff like timer resolut= ion. I don't think it went anywhere. Do you think we ought to revitalise th= at? You mention inference - have you tried that - are there cases where it = doesn't work?

[IJ] Yes, actually wondered what happened to Richards draft. I only b= riefly tried out the inference algorithm with a TCP LEDBAT implementation (https://g= ithub.com/silviov/TCP-LEDBAT/blob/master/src/tcp_ledbat.c= ). I recall that it took a while to converge. Also I am not sure here. Is Hz = in e.g a linux stack fixed. ?




That's it. Thanks again for the draft. V useful.



Bob



On 15/10/15 06:08, Ingemar Johansson S wrote:

Hi
 
A new IETF draft is submitted in response to general=
 discussion that for instance TCP Cubic is not an appropriate congestion co=
ntrol algorithm for LTE. 
The draft briefly outlines typical 4G access behavio=
r on the PDCP, RLC and MAC  layers that can have an impact on transpor=
t protocol performance. The draft also outlines two relatively simple modif=
ications to the Cubic congestion control.
 
/Ingemar  
 
-----Original Message-----
From: internet-drafts@ietf.org [mailto:intern=
et-drafts@ietf.org] 
Sent: den 14 oktober 2015 20:17

To: Ingemar Johansson S


Subject: New Version Notification for draft-johansso=
n-cc-for-4g-5g-00.txt


 


 


A new version of I-D, draft-johansson-cc-for-4g-5g-0=
0.txt


has been successfully submitted by Ingemar Johansson=
 and posted to the IETF repository.


 


Name:        =
;   draft-johansson-cc-for-4g-5g


Revision:       00


Title:       &nbs=
p;  Congestion control for 4G and 5G access


Document date:  2015-10-14

Group:       &nbs=
p;  Individual Submission


Pages:       &nbs=
p;  14


URL:        =
    https://www.ietf.=
org/internet-drafts/draft-johansson-cc-for-4g-5g-00.txt


Status:       &nb=
sp; https://datatracker.ietf.org/doc/draft-joh=
ansson-cc-for-4g-5g/


Htmlized:       https://tools.ietf.org/html/draft-johansson-cc-for-4g-5=
g-00


 


 


Abstract:


   This memo outlines the challenge that 4=
G and 5G access brings for


   transport protocol congestion control a=
nd also outlines a few simple


   examples that can improve transport pro=
tocol congestion control


   performance in 4G and 5G access.


 


 


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;          


 


 


Please note that it may take a couple of minutes fro=
m the time of submission until the htmlized version and diff are available =
at tools.ie=
tf.org.


 


The IETF Secretariat


 







-- 
____________________________________________________=
____________
Bob Briscoe       =
;            &n=
bsp;           http://bobbriscoe.net=
/

_________________________= ______________________
tcpm mailing list
tcpm@ietf.org=
https://www.ietf.org/mailman/listinfo/tcpm

 

--_000_CE03DB3D7B45C245BCA0D243277949362137FE78MX104CL02corpem_-- From nobody Fri Nov 6 09:19:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A0F1B2C74 for ; Fri, 6 Nov 2015 09:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpWgbwASPg6M for ; Fri, 6 Nov 2015 09:19:36 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3011B2C27 for ; Fri, 6 Nov 2015 09:18:05 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 7025856CADE69; Fri, 6 Nov 2015 17:18:00 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tA6HHbBk032710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Nov 2015 18:17:50 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.114]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 6 Nov 2015 18:15:42 +0100 From: "Scharf, Michael (Michael)" To: Cory Benfield , Daniel Stenberg , "tcpm@ietf.org Extensions" Thread-Topic: TCP Tuning for HTTP Thread-Index: AQHRGH8zEPMvd+b/q0yXA9NOzRbTi56OxJcAgAB2pJA= Date: Fri, 6 Nov 2015 17:15:42 +0000 Message-ID: <655C07320163294895BBADA28372AF5D485417FE@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <88103DD2-02E7-4265-BC2B-F4526A15FC54@lukasa.co.uk> In-Reply-To: <88103DD2-02E7-4265-BC2B-F4526A15FC54@lukasa.co.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: HTTP Working Group Subject: Re: [tcpm] TCP Tuning for HTTP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 17:19:38 -0000 RGFuaWVsLCBhbGwsDQoNCkknZCBzdWdnZXN0IHRvIENDIHRoZSB0Y3BtIGxpc3Qgd2hlbiBkaXNj dXNzaW5nIHRoaXMgZHJhZnQuIEJhc2ljYWxseSBhbGwgbWFqb3IgVENQIGltcGxlbWVudGVycyBt b25pdG9yIHRjcG0sIGFuZCB5b3Ugc2hvdWxkIGZpbmQgdXNlZnVsIGV4cGVydGlzZSB0aGVyZS4g SG93ZXZlciwgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIGFsbCB0Y3BtIGNvbnRyaWJ1dG9ycyBsb3Zl IGRhbmNpbmcgOykNCg0KVGhhbmtzDQoNCk1pY2hhZWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IENvcnkgQmVuZmllbGQgW21haWx0bzpjb3J5QGx1a2FzYS5jby51 a10NCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAwNiwgMjAxNSAxMjowNiBQTQ0KPiBUbzogRGFu aWVsIFN0ZW5iZXJnDQo+IENjOiBIVFRQIFdvcmtpbmcgR3JvdXANCj4gU3ViamVjdDogUmU6IFRD UCBUdW5pbmcgZm9yIEhUVFANCj4gDQo+IA0KPiA+IE9uIDYgTm92IDIwMTUsIGF0IDEwOjMzLCBE YW5pZWwgU3RlbmJlcmcgPGRhbmllbEBoYXh4LnNlPiB3cm90ZToNCj4gPg0KPiA+IEhpIGZyaWVu ZHMhDQo+ID4NCj4gPiBJJ3ZlIGp1c3Qgc3VibWl0dGVkIHRoZSAwMC12ZXJzaW9uIG9mIHRoZSBk b2N1bWVudCAiVENQIFR1bmluZyBmb3INCj4gSFRUUCJbMV0gYW5kIEkgd2lsbCBhcHByZWNpYXRl IGFueSBhbmQgYWxsIHNvcnRzIG9mIGZlZWRiYWNrIGFuZA0KPiBhZGRpdGlvbmFsIGdvb2QgYWR2 aWNlIHlvdSBjYW4gcHJvdmlkZS4gVGhlIGdvb2QgaWRlYXMgd2UgbmVlZCB0byB0ZWxsDQo+IG91 ciBmZWxsb3cgSFRUUCBpbXBsZW1lbnRlcnMgb24gaG93IHdlIHBva2Ugb24gdGhlIFRDUCBzdGFj ayB0byBtYWtlIGl0DQo+IGRhbmNlIGZvciB1cy4NCj4gPg0KPiA+IEl0IGlzIHN0aWxsIGEgYml0 IHRoaW4gYW5kIHRoZXJlIGFyZSBzb21lIHdoaXRlIHNwb3RzIGluIGl0LiBJJ20NCj4gY291bnRp bmcgb24gc29tZSBoZWxwIHRoZXJlISA9KQ0KPiA+DQo+ID4gWzFdID0gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvaWQvZHJhZnQtc3RlbmJlcmctaHR0cGJpcy10Y3AtMDAudHh0DQo+IA0KPiBEYW5pZWws DQo+IA0KPiBUaGUgZmlyc3QgZHJhZnQgbG9va3MgZ3JlYXQhIFRoaXMgaXMgYSByZWFsbHkgZ29v ZCBzdGFydC4gSSBoYXZlIGEgZmV3DQo+IHNtYWxsIHN0eWxpc3RpYyBjaGFuZ2VzIHRoYXQgSeKA mWxsIHByb3Bvc2UgYXMgUFJzIHRvIHlvdXIgcmVwbywgYnV0DQo+IHdhbnRlZCB0byBhZGQgc29t ZSBtb3JlIGRldGFpbCBmb3Igc3R1ZmYgdGhhdCBzZWVtcyBtaXNzaW5nIG9yIG5lZWRzDQo+IGVs YWJvcmF0aW9uLg0KPiANCj4gMS4gbmV0LmNvcmUuc29tYXhjb25uDQo+IA0KPiBJIGRpZCBzb21l IGRpZ2dpbmcgaGVyZSBiZWNhdXNlIEkgd2FzIGludGVyZXN0ZWQgaW4gaG93IHRoaXMgaW50ZXJh Y3RlZA0KPiB3aXRoIHRoZSDigJhiYWNrbG9n4oCZIHBhcmFtZXRlciB0byBsaXN0ZW4oKS4gSXQg c2VlbXMgdGhhdCwgb24gTGludXgsDQo+IG5ldC5jb3JlLnNvbWF4Y29ubiByZXByZXNlbnRzIHRo ZSBtYXhpbXVtIHZhbHVlLiBUaGlzIG1lYW5zIHRoYXQgdGhlDQo+IG1heGltdW0gYmFja2xvZyBv biBhIGxpc3RlbmluZyBzb2NrZXQgaXMgbWluKGJhY2tsb2csIHNvbWF4Y29ubikuIEl0DQo+IHdv dWxkIHByb2JhYmx5IGhlbHAgdG8gZWxhYm9yYXRlIHRoaXMgc2VjdGlvbiwgYnV0IGVsYWJvcmF0 aW5nIHRoYXQNCj4gc2VjdGlvbiBwcm9iYWJseSBkb2VzbuKAmXQgbWFrZSBzZW5zZSB3aXRob3V0 IGFsc28gdGFsa2luZyBhYm91dCB0aGUNCj4gYmFja2xvZyBhcmd1bWVudCB0byBsaXN0ZW4oKSBp dHNlbGYuIEnigJltIHdpbGxpbmcgdG8gc3VibWl0IHNvbWUgdGV4dA0KPiBmb3IgdGhhdCBpZiB5 b3XigJlyZSBpbnRlcmVzdGVkLg0KPiANCj4gWW91ciBkZXNjcmlwdGlvbiBvZiBzb21heGNvbm4g KOKAnHRoZSBudW1iZXIgb2YgaW5jb21pbmcgVENQIFNZTnMgYWxsb3dlZA0KPiB0byBiYWNrbG9n 4oCdKSBpcyBub3QgYWN0dWFsbHkgYWNjdXJhdGUsIEkgZG9u4oCZdCB0aGluaywgYmVjYXVzZSBv ZiB0aGUNCj4gbmV4dCBzZWN0aW9uLg0KPiANCj4gMi4gdGNwX21heF9zeW5fYmFja2xvZw0KPiAN Cj4gWW91IGRvbuKAmXQgbWVudGlvbiB0aGUgc2V0dGluZyByZWxhdGVkIHRvIG5ldC5jb3JlLnNv bWF4Y29ubiwgd2hpY2ggaXMNCj4gbmV0LmlwdjQudGNwX21heF9zeW5fYmFja2xvZy4gc29tYXhj b25uIGFuZCB0aGUgbGlzdGVuIGJhY2tsb2cgb24gTGludXgNCj4gYXBwbHkgdG8gYWNrbm93bGVk Z2VkIGNvbm5lY3Rpb25zICh0aGF0IGlzLCB0aGUgaGFuZHNoYWtlIGlzDQo+IGNvbXBsZXRlZCku IHRjcF9tYXhfc3luX2JhY2tsb2cgYXBwbGllcyB0byBjb25uZWN0aW9ucyB0aGF0IGhhdmUgbm90 DQo+IHlldCBiZWVuIGFja25vd2xlZGdlZCBieSB0aGUgY2xpZW50LiBJIGNhbuKAmXQgZmluZCBh IGNvcnJlc3BvbmRpbmcgSVB2Ng0KPiBzZXR0aW5nLCBzbyB3ZSBtaWdodCBuZWVkIHRvIGRvIHNv bWUgbW9yZSBkaWdnaW5nIGhlcmUgdG8gc2VlIGlmIHRoaXMNCj4gaXMgc3RpbGwgdXNlZDogZG9l cyBhbnlvbmUgZWxzZSBvbiB0aGlzIGxpc3Qga25vdz8NCj4gDQo+IDMuIFNlcGFyYXRlIGludG8g Y2xpZW50LCBzZXJ2ZXIsIGFuZCBib3RoIG9wdGltaXNhdGlvbnMuDQo+IA0KPiBTb21lIG9mIHRo ZSBvcHRpbWlzYXRpb25zIGFuZCB0d2Vha3Mgc3VnZ2VzdGVkIGhlcmUgb25seSBtYWtlIHNlbnNl IGZvcg0KPiBzZXJ2ZXJzIChlLmcuIHNvbWF4Y29ubiksIGJ1dCBzb21lIGFyZSBnb29kIGZvciBi b3RoIGNsaWVudHMgYW5kDQo+IHNlcnZlcnMuIEl0IHdvdWxkIGJlIGdvb2QgaWYgd2UgY291bGQg Y2FsbCB0aGlzIG91dCBhIGJpdCBtb3JlLg0KPiANCj4gT3RoZXJ3aXNlLCBJ4oCZbSByZWFsbHkg bG9va2luZyBmb3J3YXJkIHRvIHNlZWluZyB0aGlzIGRldmVsb3AhDQo+IA0KPiBDb3J5DQo+IA0K PiANCg0K From nobody Fri Nov 6 10:27:23 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2109B1B2E0C for ; Fri, 6 Nov 2015 10:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HELwQIHHi2lo for ; Fri, 6 Nov 2015 10:27:14 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113A11B2E09 for ; Fri, 6 Nov 2015 10:27:07 -0800 (PST) Received: from host86-141-67-124.range86-141.btcentralplus.com ([86.141.67.124]:47062 helo=[192.168.1.82]) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1Zulj6-0003EG-Fj; Fri, 06 Nov 2015 18:27:04 +0000 To: Praveen Balasubramanian , "EGGERT, Lars" , Stephen Bensley , Dave THALER , glenn.judd@morganstanley.com From: Bob Briscoe Message-ID: <563CF0F7.6070302@bobbriscoe.net> Date: Fri, 6 Nov 2015 18:27:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080106020308050004020908" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Cc: tcpm IETF list Subject: [tcpm] Review of draft-ietf-tcpm-dctcp-01 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 18:27:21 -0000 This is a multi-part message in MIME format. --------------080106020308050004020908 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Praveen & co-authors, As promised, here's my review of draft-ietf-tcpm-dctcp-01 _*General Comments*__* *_ In general, in the comments below I have tried to reduce the multiple assumptions about controlled environments down to the one assumption that they are controlled by a single authority. I believe DCTCP can work without the other assumptions, so the following do not apply in all controlled environments: * not always low RTT (e.g. inter-DC scenarios, or global private networks) * not always no risk of traffic attacks (e.g. internally arranged attacks) I may have missed some other occurrences of these assumptions, so pls feel free to seek out them all. Many of the comments argue with your choices of MUST, SHOULD, MAY etc. This might seem nit-picking, given the primary purpose is to document the algo. However, it would be wrong to require things that aren't required or to allow exceptions when exceptions would not be interoperable. An alternative approach would be to just remove all capitalised language. _*Section-by-section review.*__* *_ *Abstract** * I think it needs to have an applicability statement in the abstract (and introduction) that refers to the deployment and implementation status sections at the end. Something like: "This is an informational specification of the implementation of DCTCP in Microsoft Windows Server 2012. It is applicable to deployments in controlled environments like data centres but it MUST NOT be deployed over the public Internet without additional measures, as detailed in sections 4-6. " *1. Intro** *s/its many servers/ /their many servers/ "...limited queue capacities..." I understand that the motivation has been abbreviated, but I think this has lost too much. Perhaps mention memory shared between interfaces, so either bloated buffers or too little, making traffic susceptible to packet losses? [RFC3168] describes a mechanism for using Explicit Congestion Notification (ECN) from the switches for early detection of congestion, rather than waiting for packet loss to occur. This isn't correct. 3168 requires ECN marking to occur no earlier than drop. It is precisely that 3168 does not allow early marking unless there is also early drop that is the problem. It is recommended that DCTCP be deployed... "recommended" is too weak. I suggest you use something like the applicability text given above, both here and in the abstract. *2. Terminology** * Suggest you explain that capitalised words are not quite the same as in most RFCs: "Normative language is used to describe how necessary the various aspects of the Microsoft implementation are for interoperability, but even compliant implementations without the measures in sections 4-6 would still only be safe to deploy in controlled environments." *3. DCTCP Algo** * The three bullets say no more than "this is normal stuff". Would it be better to supplement each sentence with a brief phrase saying what is different about each aspect compared to RFC3168? *3.1 Marking** * This needs to say something about how you mark the IP header from L2. I suggest you refer to the up-and-forward mode of draft-ietf-tsvwg-ecn-encap. s/sending rate/ /link rate/ *3.2 ** * CURRENT: 1. If the CE codepoint is set and DCTCP.CE is false, send an ACK for any previously unacknowledged packets and set DCTCP.CE to true. 2. If the CE codepoint is not set and DCTCP.CE is true, send an ACK for any previously unacknowledged packets and set DCTCP.CE to false. SUGGESTED: 1. If the CE codepoint is set and DCTCP.CE is false, set DCTCP.CE to true and send an ACK for any previously unacknowledged packets. 2. If the CE codepoint is not set and DCTCP.CE is true, set DCTCP.CE to false and send an ACK for any previously unacknowledged packets. The figure would have to be changed to be consistent too. RATIONALE: If the receiver changes DCTCP.CE /after/ sending the ACK like this, it delays each signal until the following ACK is sent. That could add a delay of anything from 1 to m packets. I've never understood why the order of these operations was specified in this way. If there is no reason, then I suggest that it is specified in the opposite order, as I describe above. A note could be added to say the Windows Server 12 implementation does these steps in reverse order, but the order specified is preferred because it reduces signalling delay and has no interoperability issues with the original Windows implementation. The handling of the "Congestion Window Reduced" (CWR) bit is also exactly as per [RFC3168 ] including [RFC3168-ERRATA3639 ]. That is, on receipt of a segment with both the CE and CWR bits set, CWR is processed first and then ECE is processed. Even tho this is the receiver section, I suggest: s/The handling/Receiver handling/ Whatever, this cannot be correct. A DCTCP receiver surely does nothing on receipt of CWR, whereas an RFC3168 receiver does something. A DCTCP receiver certainly cannot do exactly what RFC3168 says, because that says stop setting ECE on receipt of CWR until the next CE arrives, which would surely break this feedback protocol. *3.3 ** * DCTCP.Alpha, which is initialized to 1 and MUST be updated as follows: s/MUST/SHOULD/ And add "An alternative congestion avoidance algorithm MAY be used, but it MUST lead to flow rate inversely proportional to 1/M". Rationale: There are many ways to implement interoperable 1/p cc. This is just one. DCTCP.BytesSent This variable actually counts bytes received. it's pretty confusing to call it BytesSent. s/TCP SACK options [RFC2018] are ignored./ /The sender MUST ignore TCP SACK options [RFC2018] for this computation./ RATIONALE: a) I think the idea is to ignore CE marks after a gap because, if the gap becomes considered a loss, the response to loss will override any need to count incoming CE marks for the following round trip. However, if the gap is filled before it is considered a loss {Note 1}, then CE marks that were ignored because they arrived after a gap will need to be "unignored". b) We need to make clear that SACK is not ignored altogether, only for this computation. {Note 1}: I can think of two cases: * Less than three dupacks then the gap is filled * The gap is filled by a delayed segment so that an earlier retransmission was spurious the sender MUST update cwnd as follows: cwnd = cwnd * (1 - DCTCP.Alpha / 2) s/MUST/SHOULD/ Rationale: Alternative interoperable response functions are possible. For instance an algorithm like Relentless TCP that simply reduces cwnd by half the size of any CE-marked segment. Then there is no Alpha and no g variable. CURRENT: Just as specified in [RFC3168 ], TCP should not react to congestion indications more than once for every window of data. SUGGESTED: Just as specified in [RFC3168 ], DCTCP does not react to congestion indications more than once for every window of data. I don't know whether you intended this to be an upper-case SHOULD NOT. If so, I would argue against this being normative, because it isn't necessary for interop; therefore I've suggested avoiding he 'should' word. The setting of the "Congestion Window Reduced" (CWR) bit is also exactly as per [RFC3168 ]. It is wrong to say "exactly". The sender certainly sets CWR when it does a congestion response. But in DCTCP the congestion response occurs every RTT, triggered by its own measurement-period logic, whereas in RFC3168 it is triggered by the arrival of an ECE after the ACK of any previous segment it sent with CWR set. I think it is worth saying that setting CWR is necessary for safety, otherwise in the case where there has been a configuration management error and the receiver complies with RFC 3168 not DCTCP, it will continue sending ECE for ever and starve the session. It might help to explicitly confirm that: "Other aspects of TCP congestion avoidance and control such as the slow start phase are no different to those in RFC5681." *3.4 SYN, SYN-ACK, RST** * [RFC3168] requires that a compliant TCP MUST NOT set ECT on SYN or SYN-ACK packets. s/MUST NOT/'MUST NOT'/ Rationale: Best to make it clear this is quoting a normative statement in another RFC, because it is going to be contradicted. CURRENT These RFCs, however, are intended for general Internet use, and do not directly apply to a controlled datacenter environment. ... For DCTCP connections, the sender SHOULD set ECT for SYN, SYN-ACK and RST packets. SUGGESTED: Also, a SYN is sent before the ECN-capability has been negotiated, so if it is CE-marked, a non-ECN TCP server would not recognise the marking. RFC 3168 does not specify the ECN field on a RST. The security concerns addressed by these RFCs might not apply in controlled environments like data centres, and it might not be necessary to cater for the presence of non-ECN servers. ... Therefore, the sender MUST set ECT for SYN/ACK and RST packets and a configuration option SHOULD be provided to set ECT for SYNs. RATIONALE: The draft should avoid assuming that security concerns do not apply in all controlled environments. NOTE: This might not reflect the way your implementation is coded, so you might want to make that clear. *4. Implementation Issues** * CURRENT: the implementation MUST choose a suitable estimation gain. [DCTCP10 ] provides a theoretical basis SUGGEST: the implementation will need to choose a suitable estimation gain. [ADCTCP10 ] provides a theoretical basis ... RATIONALE: a) As above, this is only one way to implement the cc, and others could well prove to be interoperable when tested. b) More particularly, it would be better for an implementation to adapt the estimation gain to the RTT, so the spec ought not to imply that one value has to be chosen. c) The later paper [ADCTCP10] provides a corrected way to determine the gain. From memory (I'm offline at the mo) it at least makes throughput inversely proportional to 1/RTT, whereas the approach in [DCTCP10] made it inversely proportional to 1/(RTT^2). I believe the Linux implementation uses the [ADCTCP10] approach. The implementation must also decide when to use DCTCP. ... likely in the same datacenter network. The 2nd & 3rd paras are a mix of implementation and deployment issues, but mostly deployment, so they might be better moved to the deployment issues section. CURRENT: It is RECOMMENDED that an implementation deal with loss episodes in the same way as conventional TCP. ... DCTCP implementation MAY also allow configuration of resetting the value of DCTCP.Alpha as part of processing any loss episodes. SUGGESTED: Move this whole para to 3.3 Sender Behaviour section, and: An implementation MUST deal with loss episodes in the same way as conventional TCP. ... DCTCP implementation SHOULD also reset the value of DCTCP.Alpha as part of processing any loss episodes. This aspect of the behaviour MAY be configurable. RATIONALE: a) There would never be a case for not falling back to conventional TCP (or do you have one?), so "RECOMMENDED" is too weak. b) I have tried to interpret what you might have meant about resetting Alpha. I'm not sure why you think it might need to be configurable though? ...it is also RECOMMENDED that an implementation allow configuration of restarting the congestion window (cwnd) of idle DCTCP connections Where special implementation measures are necessary for low RTT, these should be related to the measured RTT, not hard-coded. There is an assumption in a number of places that "data centre" implies low RTT. Of course this is true in a single DC, but I believe the the single admin aspect of a DC is what characterises DCTCP, not the low RTT aspect. With the modifications in [ADCTCP], DCTCP generalises to a network with larger RTTs as long as it is still operated by a single admin. CURRENT: [RFC3168] forbids the ECN-marking of pure ACK packets, because of the inability of TCP to mitigate ACK-path congestion and protocol-wise preferential treatment by routers. However, dropping pure ACKs - rather than ECN marking them - has disadvantages for typical datacenter traffic patterns. Because of the prevalence of bursty traffic patterns that feature transient congestion, dropping of ACKs causes subsequent retransmissions. It is RECOMMENDED that an implementation provide a configuration knob that will cause ECT to be set on such control packes, which can be used in environments where such concerns do not apply. SUGGESTED: [RFC3168] forbids the ECN-marking of pure ACK packets, because of the inability of TCP to mitigate ACK-path congestion and the extra advantage to injection attackers that ECN is perceived to offer. For the latter reason RFC 3168 also forbids ECN-marking of retransmissions, window probes and RSTs. However, dropping all these control packets - rather than ECN marking them - has considerable performance disadvantages. It is RECOMMENDED that an implementation provide a configuration knob that will cause ECT to be set on such control packes, which can be used in environments where such concerns do not apply. NOTE: This might not reflect the way your implementation is coded, so you might want to make that clear. *5. Deployment Issues** * If the traffic in the datacenter is a mix of conventional TCP and DCTCP, it is RECOMMENDED that DCTCP traffic be segregated from conventional TCP traffic. In a data centre (or anywhere), is there any case where not segregating them would make sense? If not, this needs to be a MUST, not just a RECOMMENDED. I can imagine cases where there is no long-running conventional TCP or no long-running DCTCP, but that's covered by the "if" at the start of the sentence. You might want to refer to draft-briscoe-aqm-dualq-coupled as another segregation approach here too. Since DCTCP relies on congestion marking by the switches, DCTCP can only be deployed in datacenters where the entire network infrastructure supports ECN. Surely, the "fall-back to conventional TCP on loss" rule means you can delete this constraint. A variant of DCTCP that can be deployed unilaterally and only requires standard ECN behavior has been described in [ODCTCP ][BSDCAN], Which part of "standard ECN behaviour" do you mean? The host part? The network part? The receiver part? And "can be deployed unilaterally" ought to be in the active voice not the passive, which would help resolve the ambiguity too. I haven't read [ODCTCP] and [BSDCAN] (I'm offline on a plane at the mo). Are they similar to "Instant ECN" in [Wu12] listed below? If not, that could be referred to as well for a technique that uses the regular ECN host behaviour. *6. Known Issues** * First para could refer to appendix A of RFC7560, which describes the problem precisely. A method for improving the fairness of DCTCP has been proposed in [ADCTCP ], but requires additional experimental evaluation. s/fairness/RTT fairness/ (In our experiments, it's much better than without.) *11. References** * I think the following are cited normatively, not just informatively: RFC5681, RFC5562. Additional informational Reference: [Wu12] Wu, H., Ju, J., Lu, G., Guo, C., Xiong, Y. & Zhang, Y., "Tuning ECN for Data Center Networks," In: Proceedings of the 8th International Conference on Emerging Networking Experiments and Technologies CoNEXT '12 pp.25-36 ACM (2012) That's it. HTH. Bob -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------080106020308050004020908 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Review of draft-ietf-tcpm-dctcp-01 Praveen & co-authors,

As promised, here's my review of draft-ietf-tcpm-dctcp-01

General Comments

In general, in the comments below I have tried to reduce the multiple assumptions about controlled environments down to the one assumption that they are controlled by a single authority. I believe DCTCP can work without the other assumptions, so the following do not apply in all controlled environments:
  * not always low RTT (e.g. inter-DC scenarios, or global private networks)
  * not always no risk of traffic attacks (e.g. internally arranged attacks)
I may have missed some other occurrences of these assumptions, so pls feel free to seek out them all.

Many of the comments argue with your choices of MUST, SHOULD, MAY etc. This might seem nit-picking, given the primary purpose is to document the algo. However, it would be wrong to require things that aren't required or to allow exceptions when exceptions would not be interoperable. An alternative approach would be to just remove all capitalised language.

Section-by-section review.

Abstract

I think it needs to have an applicability statement in the abstract (and introduction) that refers to the deployment and implementation status sections at the end. Something like:

"This is an informational specification of the implementation of DCTCP in Microsoft Windows Server 2012. It is applicable to deployments in controlled environments like data centres but it MUST NOT be deployed over the public Internet without additional measures, as detailed in sections 4-6. "

1. Intro
s/its many servers/
 /their many servers/

"...limited queue capacities..."
I understand that the motivation has been abbreviated, but I think this has lost too much. Perhaps mention memory shared between interfaces, so either bloated buffers or too little, making traffic susceptible to packet losses?

   [RFC3168] describes a mechanism for using Explicit Congestion
   Notification (ECN) from the switches for early detection of
   congestion, rather than waiting for packet loss to occur.

This isn't correct. 3168 requires ECN marking to occur no earlier than drop. It is precisely that 3168 does not allow early marking unless there is also early drop that is the problem.

   It is recommended that DCTCP be deployed...

"recommended" is too weak. I suggest you use something like the applicability text given above, both here and in the abstract.

2. Terminology

Suggest you explain that capitalised words are not quite the same as in most RFCs:
"Normative language is used to describe how necessary the various aspects of the Microsoft implementation are for interoperability, but even compliant implementations without the measures in sections 4-6 would still only be safe to deploy in controlled environments."

3. DCTCP Algo

The three bullets say no more than "this is normal stuff". Would it be better to supplement each sentence with a brief phrase saying what is different about each aspect compared to RFC3168?

3.1 Marking

This needs to say something about how you mark the IP header from L2. I suggest you refer to the up-and-forward mode of draft-ietf-tsvwg-ecn-encap.

s/sending rate/
 /link rate/

3.2

CURRENT:
   1.  If the CE codepoint is set and DCTCP.CE is false, send an ACK for
       any previously unacknowledged packets and set DCTCP.CE to true.

   2.  If the CE codepoint is not set and DCTCP.CE is true, send an ACK
       for any previously unacknowledged packets and set DCTCP.CE to
       false.
SUGGESTED:
   1.  If the CE codepoint is set and DCTCP.CE is false, set DCTCP.CE to 
       true and send an ACK for any previously unacknowledged packets.

   2.  If the CE codepoint is not set and DCTCP.CE is true, set DCTCP.CE
       to false and send an ACK for any previously unacknowledged packets.
    The figure would have to be changed to be consistent too.
RATIONALE:
If the receiver changes DCTCP.CE /after/ sending the ACK like this, it delays each signal until the following ACK is sent. That could add a delay of anything from 1 to m packets. I've never understood why the order of these operations was specified in this way. If there is no reason, then I suggest that it is specified in the opposite order, as I describe above.

A note could be added to say the Windows Server 12 implementation does these steps in reverse order, but the order specified is preferred because it reduces signalling delay and has no interoperability issues with the original Windows implementation. 

   The handling of the "Congestion Window Reduced" (CWR) bit is also
   exactly as per [RFC3168] including [RFC3168-ERRATA3639].  That is, on
   receipt of a segment with both the CE and CWR bits set, CWR is
   processed first and then ECE is processed.
Even tho this is the receiver section, I suggest:
s/The handling/Receiver handling/

Whatever, this cannot be correct. A DCTCP receiver surely does nothing on receipt of CWR, whereas an RFC3168 receiver does something. A DCTCP receiver certainly cannot do exactly what RFC3168 says, because that says stop setting ECE on receipt of CWR until the next CE arrives, which would surely break this feedback protocol.

3.3 
   DCTCP.Alpha, which is initialized to 1 and MUST be updated
   as follows:
s/MUST/SHOULD/
And add "An alternative congestion avoidance algorithm MAY be used, but it MUST lead to flow rate inversely proportional to 1/M".

Rationale: There are many ways to implement interoperable 1/p cc. This is just one. 
   DCTCP.BytesSent
This variable actually counts bytes received. it's pretty confusing to call it BytesSent.

s/TCP SACK options [RFC2018] are ignored./
 /The sender MUST ignore TCP SACK options [RFC2018] for this computation./
RATIONALE:
  a) I think the idea is to ignore CE marks after a gap because, if the gap becomes considered a loss, the response to loss will override any need to count incoming CE marks for the following round trip. However, if the gap is filled before it is considered a loss {Note 1}, then CE marks that were ignored because they arrived after a gap will need to be "unignored".
  b) We need to make clear that SACK is not ignored altogether, only for this computation.

{Note 1}: I can think of two cases:
* Less than three dupacks then the gap is filled
* The gap is filled by a delayed segment so that an earlier retransmission was spurious

the sender MUST update cwnd as follows:
      cwnd = cwnd * (1 - DCTCP.Alpha / 2)
s/MUST/SHOULD/
Rationale: Alternative interoperable response functions are possible. For instance an algorithm like Relentless TCP that simply reduces cwnd by half the size of any CE-marked segment. Then there is no Alpha and no g variable.

CURRENT:
   Just as specified in [RFC3168], TCP should not react to congestion
   indications more than once for every window of data.
SUGGESTED:
   Just as specified in [RFC3168], DCTCP does not react to congestion
   indications more than once for every window of data.
I don't know whether you intended this to be an upper-case SHOULD NOT. If so, I would argue against this being normative, because it isn't necessary for interop; therefore I've suggested avoiding he 'should' word.
   The setting of
   the "Congestion Window Reduced" (CWR) bit is also exactly as per
   [RFC3168].
It is wrong to say "exactly". The sender certainly sets CWR when it does a congestion response. But in DCTCP the congestion response occurs every RTT, triggered by its own measurement-period logic, whereas in RFC3168 it is triggered by the arrival of an ECE after the ACK of any previous segment it sent with CWR set.

I think it is worth saying that setting CWR is necessary for safety, otherwise in the case where there has been a configuration management error and the receiver complies with RFC 3168 not DCTCP, it will continue sending ECE for ever and starve the session.

It might help to explicitly confirm that:
"Other aspects of TCP congestion avoidance and control such as the slow start phase are no different to those in RFC5681."

3.4 SYN, SYN-ACK, RST

   [RFC3168] requires that a compliant TCP MUST NOT set ECT on SYN or
   SYN-ACK packets.

s/MUST NOT/'MUST NOT'/
Rationale: Best to make it clear this is quoting a normative statement in another RFC, because it is going to be contradicted.

CURRENT
   These RFCs, however, are
   intended for general Internet use, and do not directly apply to a
   controlled datacenter environment.
...
   For DCTCP connections, the sender
   SHOULD set ECT for SYN, SYN-ACK and RST packets.
SUGGESTED:

   Also, a SYN is sent before the ECN-capability has been
   negotiated, so if it is CE-marked, a non-ECN TCP server would not
   recognise the marking. RFC 3168 does not specify the ECN field on
   a RST. The security concerns addressed by these RFCs
   might not apply in controlled environments like data centres, and
   it might not be necessary to cater for the presence of non-ECN
   servers.
...
   Therefore, the sender MUST set ECT for SYN/ACK and RST packets and a 
   configuration option SHOULD be provided to set ECT for SYNs.
RATIONALE:
   The draft should avoid assuming that security concerns do not apply in all controlled environments.
NOTE:
   This might not reflect the way your implementation is coded, so you might want to make that clear.

4. Implementation Issues

CURRENT:
   the implementation MUST choose a suitable
   estimation gain.  [DCTCP10] provides a theoretical basis
SUGGEST:
   the implementation will need to choose a suitable
   estimation gain.  [ADCTCP10] provides a theoretical basis ...
RATIONALE:
   a) As above, this is only one way to implement the cc, and others could well prove to be interoperable when tested.
   b) More particularly, it would be better for an implementation to adapt the estimation gain to the RTT, so the spec ought not to imply that one value has to be chosen.
   c) The later paper [ADCTCP10] provides a corrected way to determine the gain. From memory (I'm offline at the mo) it at least makes throughput inversely proportional to 1/RTT, whereas the approach in [DCTCP10] made it inversely proportional to 1/(RTT^2). I believe the Linux implementation uses the [ADCTCP10] approach.

   The implementation must also decide when to use DCTCP.
...
   likely in the same datacenter network.
The 2nd & 3rd paras are a mix of implementation and deployment issues, but mostly deployment, so they might be better moved to the deployment issues section.

CURRENT:
   It is RECOMMENDED that an implementation deal with loss episodes in
   the same way as conventional TCP.
...
   DCTCP implementation MAY also allow configuration of resetting the
   value of DCTCP.Alpha as part of processing any loss episodes.
SUGGESTED: Move this whole para to 3.3 Sender Behaviour section, and:
   An implementation MUST deal with loss episodes in
   the same way as conventional TCP.
...
   DCTCP implementation SHOULD also reset the
   value of DCTCP.Alpha as part of processing any loss episodes. 
   This aspect of the behaviour MAY be configurable.
RATIONALE:
   a) There would never be a case for not falling back to conventional TCP  (or do you have one?), so "RECOMMENDED" is too weak.
   b) I have tried to interpret what you might have meant about resetting Alpha. I'm not sure why you think it might need to be configurable though?

   ...it is also RECOMMENDED that an implementation allow
   configuration of restarting the congestion window (cwnd) of idle
   DCTCP connections
Where special implementation measures are necessary for low RTT, these should be related to the measured RTT, not hard-coded. There is an assumption in a number of places  that "data centre" implies low RTT. Of course this is true in a single DC, but I believe the the single admin aspect of a DC is what characterises DCTCP, not the low RTT aspect. With the modifications in [ADCTCP], DCTCP generalises to a network with larger RTTs as long as it is still  operated by a single admin.

CURRENT:
   [RFC3168] forbids the ECN-marking of pure ACK packets, because of the
   inability of TCP to mitigate ACK-path congestion and protocol-wise
   preferential treatment by routers.  However, dropping pure ACKs -
   rather than ECN marking them - has disadvantages for typical
   datacenter traffic patterns.  Because of the prevalence of bursty
   traffic patterns that feature transient congestion, dropping of ACKs
   causes subsequent retransmissions. It is RECOMMENDED that an
   implementation provide a configuration knob that will cause ECT to be set
   on such control packes, which can be used in environments where such
   concerns do not apply.
SUGGESTED:
   [RFC3168] forbids the ECN-marking of pure ACK packets, because of the
   inability of TCP to mitigate ACK-path congestion and the extra
   advantage to injection attackers that ECN is perceived to offer.
   For the latter reason RFC 3168 also forbids ECN-marking of
   retransmissions, window probes and RSTs.

   However, dropping all these control packets -
   rather than ECN marking them - has considerable performance
   disadvantages.  It is RECOMMENDED that an
   implementation provide a configuration knob that will cause ECT to be set
   on such control packes, which can be used in environments where such
   concerns do not apply.
NOTE:
   This might not reflect the way your implementation is coded, so you might want to make that clear.


5. Deployment Issues
 
   If
   the traffic in the datacenter is a mix of conventional TCP and DCTCP,
   it is RECOMMENDED that DCTCP traffic be segregated from conventional
   TCP traffic.
In a data centre (or anywhere), is there any case where not segregating them would make sense? If not, this needs to be a MUST, not just a RECOMMENDED. I can imagine cases where there is no long-running conventional TCP or no long-running DCTCP, but that's covered by the "if" at the start of the sentence.

You might want to refer to draft-briscoe-aqm-dualq-coupled as another segregation approach here too.

   Since DCTCP relies on congestion marking by the switches, DCTCP can
   only be deployed in datacenters where the entire network
   infrastructure supports ECN.
Surely, the "fall-back to conventional TCP on loss" rule means you can delete this constraint.

   A
   variant of DCTCP that can be deployed unilaterally and only requires
   standard ECN behavior has been described in [ODCTCP][BSDCAN],

Which part of "standard ECN behaviour" do you mean? The host part? The network part? The receiver part? And "can be deployed unilaterally" ought to be in the active voice not the passive, which would help resolve the ambiguity too.

I haven't read [ODCTCP] and [BSDCAN] (I'm offline on a plane at the mo). Are they similar to "Instant ECN" in [Wu12] listed below? If not, that could be referred to as well for a technique that uses the regular ECN host behaviour.

6. Known Issues

First para could refer to appendix A of RFC7560, which describes the problem precisely.
A method for improving the fairness of DCTCP has been proposed
   in [ADCTCP], but requires additional experimental evaluation.
s/fairness/RTT fairness/

(In our experiments, it's much better than without.)

11. References

I think the following are cited normatively, not just informatively:
RFC5681, RFC5562.

Additional informational Reference:

[Wu12] Wu, H., Ju, J., Lu, G., Guo, C., Xiong, Y. & Zhang, Y., "Tuning ECN for Data Center Networks," In: Proceedings of the 8th International Conference on Emerging Networking Experiments and Technologies CoNEXT '12 pp.25-36 ACM (2012)

That's it. HTH.


Bob
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------080106020308050004020908-- From nobody Fri Nov 6 11:05:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8618F1ACF0A for ; Fri, 6 Nov 2015 11:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vobk8sUaagjj for ; Fri, 6 Nov 2015 11:05:38 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 384F51ACEF7 for ; Fri, 6 Nov 2015 11:05:30 -0800 (PST) Received: from [128.9.184.146] ([128.9.184.146]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id tA6J4xUA003387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Nov 2015 11:04:59 -0800 (PST) To: Michael Welzl , Yuchung Cheng References: <563BCF27.1010107@isi.edu> <6E47AFA6-5BC9-43BB-BA9D-912F171F6A2D@ifi.uio.no> From: Joe Touch Message-ID: <563CF9DB.1090401@isi.edu> Date: Fri, 6 Nov 2015 11:04:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <6E47AFA6-5BC9-43BB-BA9D-912F171F6A2D@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: tA6J4xUA003387 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org Extensions" , touch@isi.edu Subject: Re: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 19:05:39 -0000 FWIW, we also need to differentiate the impact of these issues on temporal vs. ensemble sharing. On 11/5/2015 11:57 PM, Michael Welzl wrote: > >> On 06 Nov 2015, at 05:58, Yuchung Cheng wrote: >> >> On Thu, Nov 5, 2015 at 1:50 PM, Joe Touch wrote: >>> >>> >>> >>> On 11/5/2015 10:54 AM, Yuchung Cheng wrote: >>> ... >>>> Externally: IP no longer serves a good index. e.g., DHCP, NAT. >>> >>> That's not necessarily true. In both cases, the machines that might >>> share an IP address often share the dominant aspects of their network >>> paths - delay, loss, max bandwidth, etc. >>> >>> Additionally, the shared information is used only for connection >>> initialization. That shared information doesn't have to be accurate, >>> only somewhat better than the current default initial values. >> Intuitively yes. But our tests show little difference in terms of >> latency, loss rate, etc with or without the Linux IP metrics cache. >> And disabling not only save cache write/read but also skip the pathological >> cases. >> >> Today a phone can have multiple public IP addresses and an IP address >> can be used for multiple phones simultaneously (with different ports). >> The RTT, link >> quality, and BW can all be very different. This makes IP a less >> reliable index for server cache or CB sharing even only for seeding phase. >> >> I am not claiming it's universally useless. I am presenting a data >> point primarily on servers. > > Sounds like at least some text explaining these potential problems with relying on the IP address is needed for the planned RFC2140bis. Which I think is quite appropriate. Thanks for the data point! > > Cheers, > Michael > From nobody Fri Nov 6 11:34:06 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148531B2F69 for ; Fri, 6 Nov 2015 11:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN8ncREFj331 for ; Fri, 6 Nov 2015 11:34:02 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756751B2F75 for ; Fri, 6 Nov 2015 11:33:58 -0800 (PST) Received: by vkgs66 with SMTP id s66so21579516vkg.1 for ; Fri, 06 Nov 2015 11:33:57 -0800 (PST) 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; bh=RieVlo0/fCMniirMQjSEYznT5pgzeZSUVF80NH0Wbik=; b=JWQmvJxLjEMB/xe+/CbtekJUULkMoFZocs0pT3LxgHsASa9ey8hTwi1OtBAHnQHZTp D5WCHJJb6ROFg6W3BJOBOE447YReV0XX4OgABfFMYGiRWzbXnxlXvD24Hqvj+lSdk5Cu /XeKSyU7KAxiga11XG39ByMhHTrntOW5cPOKfx5i2g6OkILtYoUNP/DYi6odCUgZHZfT VFle5xvXo/R8tf+0ZV6IB0jc3+h8CKF37jCkzug4UJvjM9O8p+uI4hNXlDgx2Tgz9ZId RwgmgmTnZLMzKk20SUl5gmKVbyZGb+C6fEf3Rk21kgN2rFf4xONbNM4UeSrEJnE0mnUf CM5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RieVlo0/fCMniirMQjSEYznT5pgzeZSUVF80NH0Wbik=; b=dpyMUlWluoVLac3O2M2YAKKsyZfGLrUQnzR8PNXekLGV3eERRsXCtpt3gcSNJ9brqE Sdb+WCpNKFonnYxZDeBmpF56Z7g1cMXNXwjrEW3om1VuWLH7S9vVcPWqV0ZQDZqNV8t9 DuhzY6ap4fp/Lr5NEHb73Dan8vhFCStz8ADYOSaOV+x6H6XVywfKPvOBBbaxEiiv3kzm lBtietplCbVg/UH9yb/m7UUv9zt/ZIvLFCuprRZhyGQZNJZH4OIR20ZZto5OcSwHQvYI +/SO3dtZotpE/7MXuGveRbn5PV/XadPLRBp+RNt7dWoqN04Pz0jdUxd7+VVNJSSN82hl u6tw== X-Gm-Message-State: ALoCoQkSuiCTEl7cuCXIszQe4S6iu1Tb0yUNoh6mxs74JeRR7Eh8nVoAwlD8bZvEFBswphy3RaXi X-Received: by 10.31.41.23 with SMTP id p23mr9308280vkp.4.1446838437427; Fri, 06 Nov 2015 11:33:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.189.19 with HTTP; Fri, 6 Nov 2015 11:33:17 -0800 (PST) In-Reply-To: <563CF9DB.1090401@isi.edu> References: <563BCF27.1010107@isi.edu> <6E47AFA6-5BC9-43BB-BA9D-912F171F6A2D@ifi.uio.no> <563CF9DB.1090401@isi.edu> From: Yuchung Cheng Date: Fri, 6 Nov 2015 11:33:17 -0800 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a113ef4be1c73e20523e45359 Archived-At: Cc: "tcpm@ietf.org Extensions" , Michael Welzl Subject: Re: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 19:34:04 -0000 --001a113ef4be1c73e20523e45359 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 6, 2015 at 11:04 AM, Joe Touch wrote: > FWIW, we also need to differentiate the impact of these issues on > temporal vs. ensemble sharing. > I also think it's more useful to analyze the impact of existing implementations, instead of documenting code. the metrics cache isn't hard to understand at all in Linux and the code changes over time. What we document today can be obsolete tomorrow, so in the end one still need to read the code to get the latest info. In other word I think this draft is a waste of time honestly speaking. > > On 11/5/2015 11:57 PM, Michael Welzl wrote: > > > >> On 06 Nov 2015, at 05:58, Yuchung Cheng wrote: > >> > >> On Thu, Nov 5, 2015 at 1:50 PM, Joe Touch wrote: > >>> > >>> > >>> > >>> On 11/5/2015 10:54 AM, Yuchung Cheng wrote: > >>> ... > >>>> Externally: IP no longer serves a good index. e.g., DHCP, NAT. > >>> > >>> That's not necessarily true. In both cases, the machines that might > >>> share an IP address often share the dominant aspects of their network > >>> paths - delay, loss, max bandwidth, etc. > >>> > >>> Additionally, the shared information is used only for connection > >>> initialization. That shared information doesn't have to be accurate, > >>> only somewhat better than the current default initial values. > >> Intuitively yes. But our tests show little difference in terms of > >> latency, loss rate, etc with or without the Linux IP metrics cache. > >> And disabling not only save cache write/read but also skip the > pathological > >> cases. > >> > >> Today a phone can have multiple public IP addresses and an IP address > >> can be used for multiple phones simultaneously (with different ports). > >> The RTT, link > >> quality, and BW can all be very different. This makes IP a less > >> reliable index for server cache or CB sharing even only for seeding > phase. > >> > >> I am not claiming it's universally useless. I am presenting a data > >> point primarily on servers. > > > > Sounds like at least some text explaining these potential problems with > relying on the IP address is needed for the planned RFC2140bis. Which I > think is quite appropriate. Thanks for the data point! > > > > Cheers, > > Michael > > > --001a113ef4be1c73e20523e45359 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 6, 2015 at 11:04 AM, Joe Touch <touch@isi.edu> w= rote:
FWIW, we also need to differentiate= the impact of these issues on
temporal vs. ensemble sharing.
I also think it's m= ore useful to analyze the impact of existing implementations, instead of do= cumenting code. the metrics cache isn't hard to understand at all in Li= nux and the code changes over time. What we document today can be obsolete = tomorrow, so in the end one still need to read the code to get the latest i= nfo. In other word I think this draft is a waste of time honestly speaking.=
=C2=A0

On 11/5/2015 11:57 PM, Michael Welzl wrote:
>
>> On 06 Nov 2015, at 05:58, Yuchung Cheng <ycheng@google.com> wrote:
>>
>> On Thu, Nov 5, 2015 at 1:50 PM, Joe Touch <touch@isi.edu> wrote:
>>>
>>>
>>>
>>> On 11/5/2015 10:54 AM, Yuchung Cheng wrote:
>>> ...
>>>> Externally: IP no longer serves a good index. e.g., DHCP, = NAT.
>>>
>>> That's not necessarily true. In both cases, the machines t= hat might
>>> share an IP address often share the dominant aspects of their = network
>>> paths - delay, loss, max bandwidth, etc.
>>>
>>> Additionally, the shared information is used only for connecti= on
>>> initialization. That shared information doesn't have to be= accurate,
>>> only somewhat better than the current default initial values.<= br> >> Intuitively yes. But our tests show little difference in terms of<= br> >> latency, loss rate, etc with or without the Linux IP metrics cache= .
>> And disabling not only save cache write/read but also skip the pat= hological
>> cases.
>>
>> Today a phone can have multiple public IP addresses and an IP addr= ess
>> can be used for multiple phones simultaneously (with different por= ts).
>> The RTT, link
>> quality, and BW can all be very different. This makes IP a less >> reliable index for server cache or CB sharing even only for seedin= g phase.
>>
>> I am not claiming it's universally useless. I am presenting a = data
>> point primarily on servers.
>
> Sounds like at least some text explaining these potential problems wit= h relying on the IP address is needed for the planned RFC2140bis. Which I t= hink is quite appropriate. Thanks for the data point!
>
> Cheers,
> Michael
>

--001a113ef4be1c73e20523e45359-- From nobody Fri Nov 6 12:16:53 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC47A1B2FF3 for ; Fri, 6 Nov 2015 12:16:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOHiuE8BO5Ul for ; Fri, 6 Nov 2015 12:16:50 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E141B2FF2 for ; Fri, 6 Nov 2015 12:16:50 -0800 (PST) Received: from [128.9.184.146] ([128.9.184.146]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tA6KGFwh003249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Nov 2015 12:16:15 -0800 (PST) To: Yuchung Cheng References: <563BCF27.1010107@isi.edu> <6E47AFA6-5BC9-43BB-BA9D-912F171F6A2D@ifi.uio.no> <563CF9DB.1090401@isi.edu> From: Joe Touch Message-ID: <563D0A8E.5020008@isi.edu> Date: Fri, 6 Nov 2015 12:16:14 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org Extensions" , Michael Welzl , touch@isi.edu Subject: Re: [tcpm] A clarification about draft-welzl-tcpm-tcb-sharing X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2015 20:16:51 -0000 On 11/6/2015 11:33 AM, Yuchung Cheng wrote: > > > On Fri, Nov 6, 2015 at 11:04 AM, Joe Touch > wrote: > > FWIW, we also need to differentiate the impact of these issues on > temporal vs. ensemble sharing. > > I also think it's more useful to analyze the impact of existing > implementations, instead of documenting code. Right; this is the IETF, and code documentation isn't the goal. > the metrics cache isn't > hard to understand at all in Linux and the code changes over time. What > we document today can be obsolete tomorrow, so in the end one still need > to read the code to get the latest info. In other word I think this > draft is a waste of time honestly speaking. The draft is the starting point; it is intended to gather information about the impact of existing implementations, exactly as you describe. Joe > > > > On 11/5/2015 11:57 PM, Michael Welzl wrote: > > > >> On 06 Nov 2015, at 05:58, Yuchung Cheng > wrote: > >> > >> On Thu, Nov 5, 2015 at 1:50 PM, Joe Touch > wrote: > >>> > >>> > >>> > >>> On 11/5/2015 10:54 AM, Yuchung Cheng wrote: > >>> ... > >>>> Externally: IP no longer serves a good index. e.g., DHCP, NAT. > >>> > >>> That's not necessarily true. In both cases, the machines that might > >>> share an IP address often share the dominant aspects of their > network > >>> paths - delay, loss, max bandwidth, etc. > >>> > >>> Additionally, the shared information is used only for connection > >>> initialization. That shared information doesn't have to be accurate, > >>> only somewhat better than the current default initial values. > >> Intuitively yes. But our tests show little difference in terms of > >> latency, loss rate, etc with or without the Linux IP metrics cache. > >> And disabling not only save cache write/read but also skip the > pathological > >> cases. > >> > >> Today a phone can have multiple public IP addresses and an IP address > >> can be used for multiple phones simultaneously (with different > ports). > >> The RTT, link > >> quality, and BW can all be very different. This makes IP a less > >> reliable index for server cache or CB sharing even only for > seeding phase. > >> > >> I am not claiming it's universally useless. I am presenting a data > >> point primarily on servers. > > > > Sounds like at least some text explaining these potential problems > with relying on the IP address is needed for the planned RFC2140bis. > Which I think is quite appropriate. Thanks for the data point! > > > > Cheers, > > Michael > > > > From nobody Tue Nov 10 12:29:48 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D170F1B3EF0; Tue, 10 Nov 2015 12:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBDGZK33s-u6; Tue, 10 Nov 2015 12:29:38 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4871B3EEA; Tue, 10 Nov 2015 12:29:36 -0800 (PST) X-AuditID: c1b4fb3a-f79136d0000071e2-e5-564253aedc7c Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 20.49.29154.EA352465; Tue, 10 Nov 2015 21:29:34 +0100 (CET) Received: from ESESSMB205.ericsson.se ([169.254.5.152]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Tue, 10 Nov 2015 21:29:02 +0100 From: Ingemar Johansson S To: Yuchung Cheng , Bob Briscoe Thread-Topic: [tcpm] [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt Thread-Index: AQHRBqyIURyzaqIT1UWeXHewI01EFJ5rS8UAgBd7pYCACSDxgIAAmWGAgABxU4CACNAukA== Date: Tue, 10 Nov 2015 20:29:01 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA34EB59DE@ESESSMB205.ericsson.se> References: <20151014181702.10618.83714.idtracker@ietfa.amsl.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34BF4F0F@ESESSMB205.ericsson.se> <56325D2D.1070107@bobbriscoe.net> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB1658@ESESSMB205.ericsson.se> <563A8635.3000400@bobbriscoe.net> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA34EB59DEESESSMB205erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM2K7h+66YKcwgwPzpS0OLNjJbnH04QJW i20n5zNZHHtzl83iy+OrbA6sHq/uX2D1WLCp1GPJkp9MHpM3HmYLYInisklJzcksSy3St0vg ynix7DxTQctrloodJy6zNjA23GbpYuTkkBAwkTix/jQzhC0mceHeerYuRi4OIYHDjBKnG28w QThLGCVez5vBDlLFJmAjsfLQd0YQW0TAQ6J15Q9GkCJmgQ2MEu2zZoAlhAWSJP6dugY0lgOo KFli2gRTiPowifVv34GVsAioSizY/pENxOYV8JW4vHMnK8SyG0wSL993soIkOAUCJf4+nc4E YjMKyErc/34P7GxmAXGJW0/mM0GcLSCxZM95qBdEJV4+/scKYStJ/NhwCao+X2LZ6sPMEMsE JU7OfMIygVF0FpJRs5CUzUJSNgvoBWYBTYn1u/QhShQlpnQ/ZIewNSRa58xlRxZfwMi+ilG0 OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwSg9u+W21g/Hgc8dDjAIcjEo8vBvsnMKEWBPLiitz DzFKcDArifA+cQUK8aYkVlalFuXHF5XmpBYfYpTmYFES521mehAqJJCeWJKanZpakFoEk2Xi 4JRqYNw03TY7/FR07+Xc5ecqam7ombf/m7FAWupk5ZJe6zgF15pi/YqPuin9rpy7779jj4qd P8nz+cN7Anyb0oMy934q9e5ff0nrPvsnBuEbMs1Bmauf1Pxq3P76xaaL7V7bsuW8X5t+474h 9fPJBMXNqczaL06t73t5wMHMLSk32n+OiBnrZtuzcUosxRmJhlrMRcWJAIFsX07OAgAA Archived-At: Cc: Ingemar Johansson S , "tcpm@ietf.org Extensions" , "tsvwg@ietf.org" , "iccrg@irtf.org" Subject: Re: [tcpm] [tsvwg] FW: New Version Notification for draft-johansson-cc-for-4g-5g-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 10 Nov 2015 20:29:45 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA34EB59DEESESSMB205erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KWW91IGFyZSByaWdodCB0aGF0IHRoZSBtZXNzYWdlIGlzIHF1aXRlIHZhZ3VlLCB0aGUg cmVhc29uIGlzIHRoYXQgYXQgbGVhc3QgSSBkb27igJl0IGhhdmUgYW4gZXhhY3QgYW5zd2VyIHRv IHRoYXQgcXVlc3Rpb24uDQpBbiBhdHRlbXB0IGF0IGFuIGV4YWN0IHJ1bGUgaXMgdGhhdCB0aGVy ZSBzaG91bGQgYmUgZXhhY3RseSBhcyBtdWNoIGRhdGEgYXZhaWxhYmxlIGFzIGNhbiBiZSBzY2hl ZHVsZWQgaW4gdGhlIG5leHQgc2NoZWR1bGluZyBldmVudC4NClRoZSBwcm9ibGVtIGlzIHRoYXQg aXQgaXMgbm90IG9idmlvdXMgd2hlbiB0aGF0IHNjaGVkdWxpbmcgZXZlbnQgb2NjdXJzIChkZXBl bmRzIG9uIHNjaGVkdWxpbmcgYWxnb3JpdGhtKSBvciBob3cgbXVjaCBkYXRhIGNhbiBiZSBzY2hl ZHVsZWQuDQpTbywgaWYgb25lIGxvb2sgYXQgcGVhayB0aHJvdWdocHV0IGFsb25lIGl0IGlzIHRy dWUgdGhhdCBpdCBwYXlzIG9mZiB0byB1c2UgQ0MgYWxnb3JpdGhtcyB0aGF0IGdlbmVyYXRlIGxh cmdlciBzdGFuZGluZyBxdWV1ZXMgKEN1YmljIGlzIGJldHRlciB0aGFuIExFREJBVCBvciBWZWdh cykuIFRoZSBwcmljZSBwYWlkIGZvciB0aGlzIGlzIG9mIGNvdXJzZSB0aGF0IGxhdGVuY3kgc2Vu c2l0aXZlIHNlcnZpY2VzIGNhbiBzdWZmZXIgd2hlbiBsYXJnZSBzdGFuZGluZyBxdWV1ZXMgYXJl IGFsbG93ZWQuDQpJbiBzaG9ydCwgb25lIG5lZWQgdG8gY29tcHJvbWlzZSwgaWYgb25lIHRha2Ug dGhlIGV4YW1wbGUgdGhhdCBXZWJSVEMgbWVkaWEgdHJhdmVyc2VzIHRoZSBzYW1lIGFjY2Vzcywg dGhlbiBpdCBpcyBsaWtlbGt5IGJldHRlciB0byBhY2NlcHQgdGhhdCB0aGUgZmlsZSB0cmFuc2Zl ciB0YWtlcyBhIHdoaWxlIGxvbmdlci4NCg0KL0luZ2VtYXINCg0KRnJvbTogWXVjaHVuZyBDaGVu ZyBbbWFpbHRvOnljaGVuZ0Bnb29nbGUuY29tXQ0KU2VudDogZGVuIDUgbm92ZW1iZXIgMjAxNSAw NjoxMw0KVG86IEJvYiBCcmlzY29lDQpDYzogdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zOyBJbmdl bWFyIEpvaGFuc3NvbiBTOyB0c3Z3Z0BpZXRmLm9yZzsgaWNjcmdAaXJ0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbdGNwbV0gW3RzdndnXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLTAwLnR4dA0KDQoNCkkgaGF2ZSBhIHF1ZXN0aW9uIHJl OiBob3cgbXVjaCBidWZmZXIgb3IgYmFja2xvZyBpcyBuZWVkZWQgdG8gcHJldmVudCB0aGUgc2No ZWR1bGFyIGZyb20gcmVkdWNpbmcgdGhlIHJhdGUgb3IgZXZlbiBpbmNyZWFzZSB0aGUgcmF0ZS4g SSB0aGluayB0aGlzIGtleSB3aHkgY3ViaWMgb3IgYnVmZmVyYmxvYXQgY2Mgd2lucyBiYyBvdGhl ciBxdWV1ZSBjb250cm9sbGluZyBjYyB3b3VsZCBsb3NlIG91dC4NCg0KRm9yIGV4YW1wbGUgaWYg dGhlIHNjaGVkdWxlciBuZWVkcyAxbWIgYmFja2xvZyB0byBtYWludGFpbiBhdCA0MG1icHMuIEEg ZGN0Y3Agb3IgdmVnYXMga2VlcGluZyB0aGUgcXVldWUgd2VsbCBiZWxvdyB3aWxsIGdldCBzYXkg NW1icHMuDQoNClRoZSBkcmFmdCBtZW50aW9ucyBhYm91dCB0aGlzIGJ1dCB0aGUgYWR2aXNlIGlz IGEgYml0IHZhZ3VlIGZvciBjYyBkZXNpZ25lci4NCk9uIE5vdiA1LCAyMDE1IDc6MjcgQU0sICJC b2IgQnJpc2NvZSIgPGlldGZAYm9iYnJpc2NvZS5uZXQ8bWFpbHRvOmlldGZAYm9iYnJpc2NvZS5u ZXQ+PiB3cm90ZToNCkluZ2VtYXIsDQpPbiAwNC8xMS8xNSAxMzoyNywgSW5nZW1hciBKb2hhbnNz b24gUyB3cm90ZToNCkhpDQoNCkFuZCB0aGFua3MgZm9yIHRoZSByZXZpZXcsIGNvbW1lbnRzL2Fu c3dlcnMvcXVlc3Rpb25zIGlubGluZSBiZWxvdw0KDQovSW5nZW1hcg0KDQpGcm9tOiBCb2IgQnJp c2NvZSBbbWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXRdDQpTZW50OiBkZW4gMjkgb2t0b2JlciAy MDE1IDE4OjU0DQpUbzogSW5nZW1hciBKb2hhbnNzb24gUzsgaWNjcmdAaXJ0Zi5vcmc8bWFpbHRv OmljY3JnQGlydGYub3JnPjsgdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz47IHRz dndnQGlldGYub3JnPG1haWx0bzp0c3Z3Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdHN2d2dd IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWpvaGFuc3Nvbi1jYy1mb3It NGctNWctMDAudHh0DQoNCkluZ2VtYXIsDQoNCkFzIHByb21pc2VkLCBoZXJlJ3MgbXkgY29tbWVu dHMuIFRoZXkgYXJlIGEgbWl4IG9mIHN1Z2dlc3RlZCBpbXByb3ZlbWVudHMgdG8gdGhlIGRyYWZ0 LCBzdWdnZXN0ZWQgaW1wcm92ZW1lbnRzIHRvIDVHLCBvciByZXF1ZXN0cyBmb3IgY2xhcmlmaWNh dGlvbi4gSSBhbHNvIGFncmVlIHdpdGggYWxsIEtldmluIFNtaXRoJ3MgY29tbWVudHMsIHNvIEkg ZGlkbid0IHJlcGVhdCBhbnkuDQpbU29ycnkgZm9yIGRlbGF5IC0gSSBoYWQgdG8gZmluZCB0aW1l IHRvIHJlLXR5cGUgYWZ0ZXIgbG9zaW5nIG15IHJldmlldyBkdXJpbmcgYSBwb3dlciBvdXRhZ2Vd DQoNCkNvbnRleHQgcXVlc3Rpb25zLg0KUTEuIElzIHRoaXMgZXhlcmNpc2UgdHJlYXRpbmcgdGhl IDVHIHNwZWNzIHNvbGVseSBpbiByZWFkLW9ubHkgbW9kZT8gT3IsIGlmIHNvbWUgdXNlZnVsIGRl c2lnbiBzdWdnZXN0aW9ucyBhcmlzZSwgaXMgdGhlcmUgYW55IGNoYW5jZSB0aGF0IHRoZSAzR1BQ IG1pZ2h0IHRha2UgdGhlbSBvbiBib2FyZCwgZ2l2ZW4gNUcgaXMgbm90IGZ1bGx5IGJha2VkIHll dD8NCltJSl0gR3Vlc3MgaXQgZGVwZW5kcywgbmVlZCB0byBzYXkgdGhhdCBJIHByb2JhYmx5IHRo ZSBzbWFsbCBjb2cgaW4gdGhlIHdoZWVsLiBJIHdvdWxkIHNheSB0aGF0IGEgbG90IG9mIHRoZSBz dGFuZGFyZHMgd29yayBpbiBJRVRGIGhhcyBiZWVuIHBpY2tlZCB1cCBieSAzR1BQIGFuZCwgSSBj YW5ub3Qgc2F5IHdoYXQgd2lsbCBoYXBwZW4gaW4gdGhlIDVHIGNvbnRleHQuDQoNCkl0J3MgZ3Jl YXQgdGhhdCB5b3UgaGF2ZSB0YWtlbiB0aGlzIGluaXRpYXRpdmUuIERvZXMgdGhlIDNHUFAgZXZl ciBmb3JtYWxseSBhc2sgdGhlIElFVEYgZm9yIGNvbW1lbnRzIG9uIGl0cyBpZGVhcyBmb3IgZWFj aCBuZXcgZ2VuZXJhdGlvbiBvZiByYWRpbz8gR2l2ZW4gdGhlIGxheWVycyBhYm92ZSBjYW4gYmUg dGhvdWdodCBvZiBhcyB0aGUgJ2N1c3RvbWVycycgb2YgdGhlIDNHUFAsIGFuZCB0aGVzZSAnY3Vz dG9tZXInIGxheWVycyBhcmUgcHJldHR5IG11Y2ggYWxsIG1haW50YWluZWQgYnkgdGhlIElFVEYs IGl0IHdvdWxkIHNlZW0gZXNzZW50aWFsIChhbmQgY291cnRlb3VzKSBmb3IgdGhlIDNHUFAgdG8g YXNrIGZvciBjdXN0b21lciBjb21tZW50LCBub3QgbGVhc3QgdG8gY28tb3JkaW5hdGUgd2l0aCB3 aGF0ZXZlciBmdXR1cmUgcGxhbnMgdGhlIElFVEYgbWlnaHQgaGF2ZSBmb3IgdGhlIGhpZ2hlciBs YXllcnMuDQpbSUpdIFdoYXQgeW91IHNheSBtYWtlcyBtdWNoIHNlbnNlLiBJIGd1ZXNzIHRoZXJl IGlzIHNvbWUgbmF0dXJhbCBsZWFrYWdlIGJldHdlZW4gM0dQUCBhbmQgSUVURiBhcyBtYW55IG9m IHRoZSBJRVRGZXJzIGFyZSBhbHNvIGFjdGl2ZSBpbiAzR1BQIHN0YW5kYXJkaXphdGlvbi4gSSBk b27igJl0IGhhdmUgZnVsbCBpbnNpZ2h0IGluIHRoZSBmb3JtYWwgcmVsYXRpb24gYmV0d2VlbiAz R1BQIGFuZCBJRVRGIGluIHRoZXNlIGFyZWFzLCBub3Qgc3VyZSBpZiB0aGF0IG5lZWQgdG8gYmUg YmV0dGVyLCBidXQgaWYgdGhhdCBpcyB0aGUgY2FzZSwgdGhlbiBpdCBpcyBwcm9iYWJseSBhIHF1 ZXN0aW9uIGZvciB0aGUgYXJlYSBkaXJlY3RvcnMuIE5lZWQgdG8gc2F5IHRoYXQgZXZlbiB0aG91 Z2ggdGhlIGZvcm1hbCBjaGFubmVscyBhcmUgc2NhcmNlIGl0IGRvZXMgcHJvYmFibHkgbm90IG1l YW4gdGhhdCAzR1BQIGlnbm9yZXMgSUVURiBvciB3aGF0IGhhcHBlbnMgYWJvdmUgSVAgaW4gZ2Vu ZXJhbC4gRm9yIGluc3RhbmNlIHRoZSByZWNlbnQgd29yayBhcm91bmQgVENQIFJBQ0sgcmFpc2Vz IHRoZSBxdWVzdGlvbiBpZiBpdCBpcyBuZWNlc3NhcnkgdGhhdCBMVEUgZGVmYXVsdCByYWRpbyBi ZWFyZXJzIGVuc3VyZSBpbiBvcmRlciBkZWxpdmVyeS4NCkkgc3VzcGVjdCB0aGF0IDNHUFAgcmFk aW8gcmVzb3VyY2UgY29udHJvbCBwZW9wbGUgZG8gbm90IGNyb3NzLWZlcnRpbGl6ZSBtdWNoIHdp dGggdGhlIElFVEYuDQpTbyBtYXliZSBpdCBpcyBhcyBtdWNoIGEgcXVlc3Rpb24gb2YgaG93IHRv IGNvLW9yZGluYXRlIGJldHdlZW4gdGhlc2UgcmFkaW8gcGVvcGxlIGFuZCBMNCwgd2hpY2ggSSB3 b3VsZCBpbWFnaW5lIGlzIGFzIG11Y2ggYSBwcm9ibGVtIHdpdGhpbiAzR1BQIGFzIGJldHdlZW4g M0dQUCBhbmQgSUVURi4NCg0KDQoNClEyLiBXaGF0IGFyZSB5b3VyIHBsYW5zIGZvciB0aGlzIGRy YWZ0PyBBcmUgeW91IGFza2luZyBmb3IgYWRvcHRpb24/IEFuZCBpZiBzbywgaW4gd2hpY2ggV0cg b3IgUkc/IElDQ1JHIGxvb2tzIHRoZSBtb3N0IGFwcHJvcHJpYXRlLCBnaXZlbiB0aGUgY2hhcnRl cnMgb2YgYWxsIHRoZSBJRVRGIGNjIFdHcyAoVFNWV0csIFRDUE0sIFJNQ0FULCBldGMpIGFyZSBz Y29wZWQgb24ganVzdCBhIHN1YnNldCBvZiB5b3VyIGRvYy4NCltJSl0gRmlyc3Qgb2JqZWN0aXZl IGlzIHRvIGdldCBhbiBpbmNyZWFzZWQgaW50ZXJlc3QgaW4gY29uZ2VzdGlvbiBjb250cm9sIGFs Z29yaXRobSB3b3JrIGluIHRoZSBJRVRGLiBUcmFkaXRpb25hbGx5IHRoaXMga2luZCBvZiB3b3Jr IHNlZW0gdG8gYmUgbW9yZSBpbiB0aGUgdGVybXMgb2YgY29uZmVyZW5jZSBwYXBlcnMgaW4gZS5n LiBTaWdjb21tLCB0aGUgYmVuZWZpdCB3aXRoIGhhdmluZyBzdWNoIHdvcmsgaW4gSUVURiBpcyB0 aGF0IGlucHV0IGZyb20gcGVvcGxlIHdpdGggYSB3aWRlciBleHBlcnRpc2UgYXJlYSAoaW5jbHVk aW5nIDNHUFAgZXhwZXJpdGlzZSkgY2FuIGdpdmUgYWxnb3JpdGhtIHByb3Bvc2FscyB0aGF0IHdv cmsgd2VsbCBmb3IgYSB3aWRlciBzZXQgb2YgYWNjZXNzIHR5cGVzLiBUaGUgd29yayBhcm91bmQg Q3ViaWMgaXMgYSBmaXJzdCBnb29kIHN0ZXAgYXMgaXMgdGhlIHdvcmsgYXJvdW5kIERDVENQLiBX aGF0IEkgd29uZGVyIGlzIGlmIGl0IGZlYXNpYmxlIHRvIHRha2UgdGhpcyBhIGJpdCBmdXJ0aGVy ID8gSSB3b3VsZCB0b28gYmVsaWV2ZSB0aGF0IHRoZSBjdXJyZW50IGRvYyBmaXRzIGJldHRlciBp biBJQ0NSRy4gIFRoZSBhbGdvcml0aG0gZXhhbXBsZXMgYXJlIGp1c3QuLiBleGFtcGxlcy4gTW9y ZSBmcnVpdGZ1bCB3b3JrIGlzIHByb2JhYmx5IHRvIGRvY3VtZW50IGRpZmZlcmVudCBhY2Nlc3Mg dHlwZXMgYW5kIGZyb20gdGhlcmUgZGVyaXZlIGEgc2V0IG9mIGJlc3QgY3VycmVudCBwcmFjdGlj ZXMgZm9yIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG1zDQpJJ20gc3VyZSB0aGUgaWNjcmcg Y2hhaXJzIHdvdWxkIGxpa2UgdGhpcyB0byBoYXBwZW4uIEFuZCBpbml0aWF0aXZlcyBsaWtlIHlv dXJzIHRvIGNvbWUgd2l0aCBwcm9wb3NhbHMgdG8gcHJvcG9zZSBzcGVjaWZpYyBjb2RlIHRvIHRh a2UgYWNjb3VudCBvZiBMMiBJIHRoaW5rIGdlbmVyYXRlIHRoZSByaWdodCBsZXZlbCBvZiBkaWFs b2d1ZS4NCg0KDQoNClNlY3Rpb24gYnkgU2VjdGlvbiBSZXZpZXcNCg0KQWxsIHNlY3Rpb25zDQoN ClRoZSBkb2N1bWVudCBnZW5lcmFsbHkgdGFsa3MgYWJvdXQgdGhlIExURSBwcm90b2NvbCBzdGFj ayBhcyBpZiBkYXRhIGlzIHRyYXZlbGxpbmcgZG93biBpdC4gQXJlIHlvdSBpbXBseWluZyB0aGF0 IG1vc3Qgc291cmNlcyBvZiBidWZmZXJpbmcgZGVsYXkgYXJlIGF0IHRoZSBzZW5kaW5nIGVuZCwg YW5kIHRoZSBmZWVkYmFjayBlbmQgaXMgcHJldHR5IHVuZW5jdW1iZXJlZCBieSBkZWxheXM/IEkg dGhpbmsgaXQgd291bGQgYmUgdXNlZnVsIHRvIGV4cGxpY2l0bHkgc2F5IHNvbWV0aGluZyBhYm91 dCB0aGlzICh3aGV0aGVyIHRydWUgb3Igbm90KSwgdG8gZXhwbGFpbiB3aHkgb25seSBvbmUgZGly ZWN0aW9uIG9mIHRyYXZlbCBpcyBkaXNjdXNzZWQgaW4gdGhlIGRvYy4NCltJSl0gVGhlIGZlZWRi YWNrIHBhdGggaXMgZW5jdW1iZXJlZCBieSBkZWxheXMsIGl0IGlzIHBlcmhhcHMgbm90IHRoYXQg Y2xlYXIgYnV0IHNlY3Rpb24gMi4zLjIgaW1wbGllcyB0aGF0IGRlbGF5ICh2YXJpYXRpb24pIGlu IHVwbGluayB3aWxsIGFmZmVjdCB0aGUgQUNLcyBmb3IgZG93bmxpbmsgZGF0YSB0cmFmZmljLiBU aGF0IHNhaWQsIHRoZSBkaWZmZXJlbmNlIGluIERML1VMIHRyYWZmaWMgaXMgdG9kYXkgc29tZXRo aW5nIGxpa2UgMTA6MSBhbmQgdGhhdCBpcyBwcm9iYWJseSBvbmUgcmVhc29uIHdoeSBvbmUgY2Fu IGdldCB0aGUgZmVlbGluZyB0aGF0IHRoZSBkcmFmdCBpcyBzbGFudGVkIHRvd2FyZHMgZG93bmxp bmsgZGF0YSB0cmFmZmljLCB0aGlzIG1heSBob3dldmVyIGNoYW5nZSB3aXRoIHRpbWUgYXMgbW9y ZSBtYWNoaW5lIHR5cGUgdHJhZmZpYyBtYXkgZW50ZXIgdGhlIHN5c3RlbS4NCkkgd2FzIHRoaW5r aW5nIG1vcmUgaW4gdGVybXMgb2YgdXAgdGhlIHN0YWNrIHZzLiBkb3duIHRoZSBzdGFjaywgbm90 IHVwbGluay9kb3dubGluay4gSS5lLiBmb3IgYm90aCBjYXNlczoNCiogZG93bmxpbmsgZGlyZWN0 aW9uOiBhcmUgdGhlcmUgYW55IGJ1ZmZlcmluZyBjb25jZXJucyBjb21pbmcgdXAgdGhlIHN0YWNr IGF0IHRoZSBVRSwgb3Igb24gdGhlIGZlZWRiYWNrIGJhY2stY2hhbm5lbCBmcm9tIHRoZSBVRT8N CiogdXBsaW5rIGRpcmVjdGlvbjogYXJlIHRoZXJlIGFueSBidWZmZXJpbmcgY29uY2VybnMgY29t aW5nIHVwIHRoZSBzdGFjayBhdCB0aGUgZU5vZGVCLCBvciBvbiB0aGUgZmVlZGJhY2sgYmFjay1j aGFubmVsIGZyb20gdGhlIGVOb2RlQj8NCg0KRm9yIGluc3RhbmNlLCBpbiB0aGUgVUUsIHBlcmhh cHMgb25lIGFwcCBibG9ja2luZyB0aGUgcmVhZCBvZiBhbm90aGVyIGR1ZSB0byB0aGUgd2F5IHsz LTV9RyBtdWx0aXBsZXhlcyBkaWZmZXJlbnQgc3RyZWFtcyBpbnRvIHRoZSBzYW1lIFBEQ1AgZnJh bWVzPw0KDQoNCg0KMi4xIFBEQ1AgbGF5ZXINCg0KICAgIFBEQ1AgYWxzbyBlbnN1cmVzIHRoYXQg YWxsDQogICBwYWNrZXRzIGFyZSBkZWxpdmVyZWQgaW4gb3JkZXIgdXAgdG8gaGlnaGVyIGxheWVy cy4NCkkgdGhpbmsgdGhpcyBtZWFucyAiaW4gdGhlIG9yZGVyIHNlbnQgaW50byB0aGUgbGluayAo UERDUCkgbGF5ZXIiLiBUaGlzIG91Z2h0IHRvIGJlIGNsYXJpZmllZCwgb3RoZXJ3aXNlLCB3aGVu IHdyaXRpbmcgaW4gdGhlIGNvbnRleHQgb2YgYSBsYXllciA0IGF1ZGllbmNlLCBpdCBtaWdodCBi ZSBhc3N1bWVkIHRoaXMgbWVhbnMgaW4gdGhlIG9yZGVyIHNlbnQgYnkgdGhlIG9yaWdpbmFsIHRy YW5zcG9ydCBsYXllciBzb3VyY2UuDQpbSUpdIFllcywgeW91IGFyZSByaWdodCAsIHJlb3JkZXJp bmcgY2FuIHN0aWxsIG9jY3VyIGUuZy4gaW4gdGhlIHdpcmVsZXNzIGJhY2toYXVsDQoNCg0KICAg a2VlcCB0aGUgYW1vdW50IG9mIGRhdGEgaW4gZmxpZ2h0IGFzIHNtYWxsIGFzIHBvc3NpYmxlLCB3 aXRob3V0IHNhY3JpZmljaW5nIHRocm91Z2hwdXQuDQpJcyB0aGlzIGp1c3QgYSByYXRoZXIgY29u dm9sdXRlZCB3YXkgb2Ygc2F5aW5nICJrZWVwIHRoZSBSVFQgYXMgbG93IGFzIHBvc3NpYmxlIj8g KHdoaWNoIGluIHR1cm4gaW1wbGllcyBrZWVwaW5nIHF1ZXVpbmcgZGVsYXkgYXMgbG93IGFzIHBv c3NpYmxlIGFzc3VtaW5nIHlvdSBjYW5ub3QgaW5mbHVlbmNlIHRoZSBwaHlzaWNhbCBwYXRoLikg T3Igd2VyZSB5b3UgdHJ5aW5nIHRvIG1ha2UgYSBtb3JlIHN1YnRsZSBwb2ludD8gLSBpZiBzbywg aXQgd2FzIGxvc3Qgb24gbWUuDQpbSUpdIE5vLCBpdCBpcyBleGFjdGx5IGFzIHlvdSBkZXNjcmli ZSBiZWxvdw0KDQoNCiAgIFJlbGlhYmxlIGRlbGl2ZXJ5IGF0IGhhbmRvdmVyIG1heSBob3dldmVy IGJlIHR1cm5lZCBvZmYgb3IgaXMgc2ltcGx5IG5vdCBpbXBsZW1lbnRlZCwNCkl0IHdvdWxkIGJl IHVzZWZ1bCBpZiB5b3UgY291bGQgZ2l2ZSBhIGZlZWwgZm9yIHJvdWdobHkgaG93IG9mdGVuIChp biAlKSB0aGVzZSBjYXNlcyBob2xkLg0KW0lKXSBJIGRvbuKAmXQgYmVsaWV2ZSB0aGF0IGl0IGlz IHBvc3NpYmxlIHRvIGdpdmUgYSBmaWd1cmUgYXMgdGhpcyBpcyB2ZW5kb3Igc3BlY2lmaWMuDQoN Cg0KMi4yIFJMQyBsYXllcg0KDQogICByb2xlIC4uLiBpcyB0byBlbnN1cmUgdGhhdCBwYWNrZXRz IGFyZSBkZWxpdmVyZWQgaW4gb3JkZXIgdXAgdG8gdGhlIGhpZ2hlciBsYXllcnMNCkVoPyBUaGUg UERDUCBzZWN0aW9uIGp1c3Qgc2FpZCBpdCBkaWQgb3JkZXJpbmcuIEFuZCB0aGUgcmVzdCBvZiB0 aGUgUkxDIHNlY3Rpb24gdGFsa3MgZXhjbHVzaXZlbHkgYWJvdXQgYnVmZmVyaW5nIGRlbGF5cyBu ZWNlc3Nhcnkgd2hpbGUgZmlsbGluZyB0cmFuc3BvcnQgYmxvY2tzLiBJZiBvcmRlcmluZyBpcyB0 aGUgcm9sZSBvZiBib3RoIGxheWVycywgc3VyZWx5IG9uZSB3aWxsIGhhdmUgbm90aGluZyB0byBk byBvbmNlIHRoZSBvdGhlciBoYXMgZ290IGV2ZXJ5dGhpbmcgaW4gb3JkZXI/DQpbSUpdIFJMQyBo YW5kbGVzIG9yZGVyaW5nIGR1ZSB0byB2YXJpb3VzIE1BQyBsYXllciBmYWlsdXJlcy4gUERDUCBo YW5kbGVzIG9yZGVyaW5nICB3aGVuIGhhbmRvdmVyIG9jY3Vycw0KDQoNCiAgIHZhcnlpbmcgc2l6 ZSBvZiB0aGUgYXZhaWxhYmxlIHRyYW5zcG9ydA0KTml0OiBHaXZlbiAndHJhbnNwb3J0JyBtZWFu cyBlMmUgZm9yIHRoZSBhdWRpZW5jZSBvZiB0aGlzIGRyYWZ0LCBwbHMgdXNlIGJlYXJlciBvciBz b21laG93IGRpc2FtYmlndWF0ZSB0aGlzIHdvcmQuDQpbSUpdIE9LDQoNCg0KDQpHYXAjMTogSW4g dGhlIGRyYWZ0LCBpdCBzZWVtcyBsaWtlIHRyYW5zcG9ydCBibG9ja3MgYXJyaXZlIGJ5IG1hZ2lj LCB0byBiZSBmaWxsZWQgYnkgZGF0YSBidWZmZXJlZCBpbiB0aGUgUkxDIGxheWVyLiBUbyB1bmRl cnN0YW5kIHRoZSBkZWxheSBjb21wcm9taXNlcyBoZXJlLCBJIHRoaW5rIHRoZSBkcmFmdCBuZWVk cyB0byBleHBsYWluIHdoYXQgZGV0ZXJtaW5lcyBob3cgbXVjaCB0cmFuc3BvcnQgYmxvY2sgY2Fw YWNpdHkgZWFjaCBmbG93IGlzIGdpdmVuLCBhbmQgaG93IHRoZXkgY2FuIGluZmx1ZW5jZSBpdC4g SW4gM0csIEkgYmVsaWV2ZSB0aGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIgY291bGQgYXNrIHRoZSBy YWRpbyByZXNvdXJjZSBjb250cm9sbGVyIHRvIGNoYW5nZSByYWRpbyByZXNvdXJjZSBhbGxvY2F0 aW9uLiBJcyB0aGlzIHRoZSBzYW1lIGluIDRHICYgNUc/IERvZXMgdGhlIGJhY2tsb2cgb2YgdGhl IGJ1ZmZlciBpbnRvIHRoZSBSTEMgbGF5ZXIgaGF2ZSBhbnkgYXV0b21hdGljIGluZmx1ZW5jZSBv dmVyIGFsbG9jYXRpb24gb2YgYXZhaWxhYmxlIHJlc291cmNlcz8gSSBhc3N1bWUgdHJhZmZpYyBj bGFzcyBjYW4gYWxzbyBiZSB1c2VkIHRvIGluZmx1ZW5jZSBhbGxvY2F0aW9uLg0KW0lKXSBXaWxs IHVwZGF0ZWQgd2l0aCBtb3JlIGRldGFpbA0KDQoNCkdhcCMyOiBJbiBhIDNHIHN0YWNrLCB0aGUg UkxDIGxheWVyIG11bHRpcGxleGVzIGFsbCB0aGUgYWN0aXZlIGFwcGxpY2F0aW9uIHN0cmVhbXMg aW50byBNQUMgbGF5ZXIgdHJhbnNwb3J0IGJsb2NrIGJ5IGRpY2luZyB1cCBidWZmZXJlZCBwYWNr ZXRzIGFuZCBwYWNraW5nIHRoZSBwaWVjZXMgaW50byBlYWNoIHRyYW5zcG9ydCBibG9jay4gVGhl biwgYXQgdGhlIG90aGVyIGVuZCBvZiB0aGUgbGluaywgZWFjaCBwaWVjZSBoYXMgdG8gYmUgaGVs ZCB1bnRpbCB0aGUgcmVzdCBvZiB0aGUgcGFja2V0IGFycml2ZXMuIFRoaXMgc2FjcmlmaWNlcyBk ZWxheSBmb3IgYmFuZHdpZHRoIGVmZmljaWVuY3kuIElzIHRoaXMgc3RpbGwgZG9uZSBpbiA0RyBh bmQgNUc/IElmIHNvLCBpdCB3b3VsZCBiZSBnb29kIHRvIHdyaXRlIGFib3V0IG11eCBkZWxheSBp biB0aGUgZHJhZnQgdG9vLg0KW0lKXSBPSywgd2lsbCBhZGQgbW9yZSBpbmZvDQoNCg0KMi4zIE1B QyBsYXllcg0KDQogICB0aGUgbWF4aW11bSBudW1iZXIgb2YgcmV0cmFuc21pc3Npb25zIGlzIGNv bmZpZ3VyYWJsZQ0KDQpXb3VsZG4ndCBpdCBiZSBiZXR0ZXIgdG8gc2V0IGEgbGltaXQgb24gdGhl IHRpbWUgc3BlbnQgcmV0cmFuc21pdHRpbmcsIHNvIGl0IHdvdWxkIGF1dG9tYXRpY2FsbHkgZ2l2 ZSB1cCB3aXRoIGxlc3MgcmV0cmFuc21pc3Npb25zIGZvciBsb25nZXIgdHJhbnNtaXNzaW9uIGRp c3RhbmNlcz8NCltJSl0gUG9zc2libGUsIDRHIHNwZWNpZmllcyBhIGxpbWl0IHRvIHRoZSBudW1i ZXIgb2YgcmV0cmFuc21pc3Npb25zLCBpbiBwcmFjdGljZSBpdCBjYW4gYmUgdHJhbnNsYXRlZCB0 byB0aW1lIGFzIGVhY2ggcmV0cmFuc21pc3Npb24gaXMgOG1zIGxhdGVyLg0KSSBkaWRuJ3QgcmVh bGlzZSBpdCB3YXMgaW5kZXBlbmRlbnQgb2YgbGluay1SVFQuIFRoZW4gdGhlIG1vcmUgYmFzaWMg cXVlc3Rpb24gaXMgd2h5IGlzIGl0IGluZGVwZW5kZW50IG9mIGxpbmstUlRUPyBTdXJlbHkgb24g YSBzaG9ydCBsaW5rIGl0IGNhbiBhc3N1bWUgdGhhdCBpdCBuZWVkcyB0byByZXRyYW5zbWl0IG1v cmUgcXVpY2tseSB0aGFuIG9uIGEgbG9uZyBsaW5rPw0KDQpZb3UgY2FuIHNlZSB0aGF0IG15IHF1 ZXN0aW9uIHdhcyBhc3N1bWluZyB0aGF0IHJldHJhbnNtaXNzaW9uIGhhcHBlbmVkIG1vcmUgb2Z0 ZW4gb24gYSBzaG9ydCBsaW5rLCB0aGVuIEkgd2FzIHNheWluZyBpdCBzaG91bGQgc3RpbGwgYmUg YWxsb3dlZCB0aGUgc2FtZSBhbW91bnQgb2YgdGltZSB0byBrZWVwIHJldHJ5aW5nIChzbyBvbiBh IHNob3J0IGxpbmsgaXQgd291bGQgYmUgYWxsb3dlZCB0byByZXRyYW5zbWl0IG1vcmUgdGltZXMg YmVmb3JlIGdpdmluZyB1cCwgYnV0IHRoZSBtYXggZGVsYXkgd291bGQgYmUgdGhlIHNhbWUpLg0K DQo4bXMhIEkgd2FzIGFzc3VtaW5nIGl0IHdvdWxkIGJlIHJhdGhlciBtdWNoIGxlc3MgdGhhbiB0 aGF0LiBTdXJlbHkgYSBsaW5rLWxheWVyIEFDSyBjb3VsZCBuZXZlciB0YWtlIHRoYXQgbG9uZyBp ZiB0aGUgZnJhbWUgd2FzIGdvaW5nIHRvIGdldCB0aHJvdWdoLg0KDQoNCg0Kcy9vbmx5IGNoZWNr cyBmb3IgdGhlIHByZXNlbmNlIG9uIGRvd25sb2FkIGRhdGEgb25seSBhdCByZWd1bGFyIGludGVy dmFscy8NCiAvb25seSBjaGVja3MgZm9yIHRoZSBwcmVzZW5jZSBvZiBkb3dubG9hZCBkYXRhIGF0 IHJlZ3VsYXIgaW50ZXJ2YWxzLw0KW09LXQ0KDQoNCjIuMy4yIFVwbGluayBzY2hlZHVsaW5nDQoN CiAgIFRoZSBzY2hlZHVsaW5nIHJlcXVlc3QgZG9lcyBub3QgaW5kaWNhdGUgaG93IG1hbnkgYnl0 ZXMgdGhlcmUgYXJlIGluIHRoZSB1cGxpbmsgcXVldWUuDQpTZWVtcyBsaWtlIGEgYmFkIG9taXNz aW9uLiBJcyB0aGVyZSBhIHJlYXNvbj8gSWYgdGhlcmUgYXJlIGxlc3MgYnl0ZXMgcXVldWVkIHRo YW4gdGhlIGJhc2Ugc3RhdGlvbidzIGdyYW50LCBzdXJlbHkgaXQgd291bGQgYmUgdXNlZnVsIGZv ciB0aGUgYmFzZSBzdGF0aW9uIHRvIGtub3csIHNvIHRoYXQgaXQgY2FuIGdyYW50IG1vcmUgdG8g c29tZXRoaW5nIGVsc2Ugd2hpbGUgdGhlIHByZXZpb3VzIHNob3J0IHRyYW5zbWlzc2lvbiBpcyBj b21wbGV0aW5nLg0KW0lKXSBJdCBpcyBhIGRlc2lnbiBjaG9pY2UuIEEgYnVmZmVyIHN0YXR1cyBy ZXBvcnQgaXMgbW9yZSBidWxreSwgYSBzY2hlZHVsaW5nIHJlcXVlc3QgaXMganVzdCBvbmUgYml0 Lg0KDQoNCllvdSBzYXkgdGhhdCB3aGVuIEhBUlEgYnJlYWtzIHVwIGEgc2VxdWVuY2Ugb2YgQUNL cywgaXQgY2FuIGFsc28gdHJpZ2dlciAiY29hbGVzY2luZyBpc3N1ZXMiLiBJIGNhbiB1bmRlcnN0 YW5kIHRoYXQgaXQgY291bGQgY2F1c2UgQUNLIGNvbXByZXNzaW9uLCBidXQgYXJlIHlvdSBpbXBs eWluZyBzb21ldGhpbmcgY29hbGVzY2VzIHRoZSBBQ0tzIG9yIHRoZSBzdWJzZXF1ZW50IGRhdGE/ IFdoYXQgZG9lcyB0aGUgY29hbGVzY2luZz8gU2ltaWxhcmx5LCBpbiB0aGUgbGFzdCBwYXJhIG9m IDIuMy4yIHlvdSBzYXkgIlJlZHVjZWQgQUNLcyBjYW4gdW5mb3J0dW5hdGVseSBjYXVzZSBjb2Fs ZXNjaW5nLiIgYW5kIGFnYWluIEknbSBub3Qgc3VyZSB3aGF0IGlzIGNvYWxlc2Npbmcgd2hhdCBo ZXJlLg0KW0lKXSBXaGF0IEkgY2FuIHNlZSBpbiBzaW11bGF0aW9ucyBpcyB0aGF0IHRoZSBBQ0sg Y29tcHJlc3Npb24gbGVhZHMgdG8gY29hbGVzY2luZyB3aGljaCBmdXJ0aGVyIGNhbiBpbmNyZWFz ZSBqaXR0ZXIuDQpJIHN0aWxsIGRvbid0IHVuZGVyc3RhbmQuIFRoZSBxdWVzdGlvbiB3YXMgIldo YXQgaXMgY29hbGVzY2luZyB3aGF0PyINCg0KDQpUaGVyZSBjb3VsZCBiZSBhIHBvc2l0aXZlIHNp ZGUgdG8gdGhlIGludGVyYWN0aW9uIGJldHdlZW4gQUNLIGNsb2NraW5nIGFuZCBsaW5rIGFnZ3Jl Z2F0aW9uLCBhdCBsZWFzdCBmb3IgbG9uZy1ydW5uaW5nIGZsb3dzLiBUaGlzIGhhcyBiZWVuIG9i c2VydmVkIGluIDgwMi4xMW4gV2lGaSB3aGVyZSB0aGUgYnVmZmVyaW5nIGFuZCBhZ2dyZWdhdGlv biBvZiBtdWx0aXBsZSBBQ0tzIGludG8gb25lIHRyYW5zbWlzc2lvbiBncmFudCB0ZW5kIHRvIGxl YWQgdGhlIHNlbmRlciB0byBidW5jaCBtdWx0aXBsZSBkYXRhIHNlZ21lbnRzIHNvIHRoYXQgdGhl eSBhbGwgbmljZWx5IGZpbGwgb25lIHRyYW5zbWlzc2lvbiBncmFudCBpbiB0aGUgb3RoZXIgZGly ZWN0aW9uIFtTaG93YWlsMTRdLiBBcyBsb25nIGFzIHRoZSB0cmFuc21pc3Npb24gZ3JhbnQgZG9l cyBub3Qgd2FpdCBmb3IgbW9yZSBkYXRhICh3aGljaCB1bmZvcnR1bmF0ZWx5IEkgZG9uJ3QgdGhp bmsgaXMgdGhlIGNhc2UgaW4gM0cvNEcvNUcpLCB0aGlzIGNvdWxkIGJlIGdvb2QgZm9yIGJhbmR3 aWR0aCB1dGlsaXNhdGlvbiBvZiBlbGVwaGFudHMgYW5kIGxhdGVuY3kgb2YgbWljZSwgaW5jbHVk aW5nIHdoZW4gdGhleSBhcmUgbWl4ZWQuDQoNCltTaG93YWlsMTRdIFNob3dhaWwsIEEuLCBKYW1z aGFpZCwgSy4gJiBTaGloYWRhLCBCLiwgIldRTTogQW4gQWdncmVnYXRpb24tYXdhcmUgUXVldWUg TWFuYWdlbWVudCBTY2hlbWUgZm9yIElFRUUgODAyLjExTiBCYXNlZCBOZXR3b3JrcywiIEluOiBQ cm9jZWVkaW5ncyBvZiB0aGUgMjAxNCBBQ00gU0lHQ09NTSBXb3Jrc2hvcCBvbiBDYXBhY2l0eSBT aGFyaW5nIFdvcmtzaG9wIENTV1MgJzE0IHBwLjE1LTIwIEFDTSAoMjAxNCkNCjxodHRwOi8vZGwu YWNtLm9yZy9jaXRhdGlvbi5jZm0/aWQ9MjYzMDA5Nz4NCltJSl0gSW50ZXJlc3RpbmcgLHdpbGwg bG9vayBhdCBpdCwgbm90IHN1cmUgdGhvdWdoIHRoYXQgaXQgd2lsbCB3b3JrIHRoYXQgd2VsbCB3 aXRoIDRHIChjYW50IHNheSBhbnl0aGluZyBhYm91dCA1RyksIGluIDRHIHRoZSB0cmFuc21pc3Np b24gZ3JhbnRzIGNhbiB2YXJ5IHF1aXRlIGEgbG90IG92ZXIgc2hvcnQgdGltZSBzcGFucy4NCg0K DQozLiAgNEcgYW5kIDVHIGV2b2x1dGlvbg0KDQpzL2EgZXhwbGljaXQvYW4gZXhwbGljaXQvDQoN CjQuICBSZXF1aXJlbWVudHMgZm9yIGltcHJvdmVkIHBlcmZvcm1hbmNlDQoNCnMvYnVmZmVyYmxv YXQvYnVmZmVyLw0KDQo1LiAgQ29uZ2VzdGlvbiBjb250cm9sIGV4YW1wbGVzDQoNClJlZ2FyZGlu ZyBIeWJyaWQgQ3ViaWMgdXNpbmcgT1dEIG1lYXN1cmVtZW50cywgSSBoYXZlIHNlZW4gYSBwYXBl ciAodW5kZXIgc3VibWlzc2lvbikgYWJvdXQgZ2V0dGluZyBkZWxheS1iYXNlZCBjb25nZXN0aW9u IGNvbnRyb2xzIChlLmcuIExFREJBVCBvciBDQUlBIERlbGF5IEdyYWRpZW50KSB0byBpbnRlcndv cmsgd2l0aCBBUU1zIHdpdGggdmFyaW91cyBsb3cgZGVsYXkgdGFyZ2V0cy4gSXQncyBub3QgaW4g dGhlIGNvbnRleHQgb2YgY2VsbHVsYXIgbmV0d29ya3MsIGJ1dCBJJ2xsIHRyeSB0byByZW1lbWJl ciB0byBwb2ludCBpdCBvdXQgb25jZSBpdCBnZXRzIHB1Ymxpc2hlZC4NCltJSl0gU291bmRzIGlu dGVyZXN0aW5nICwgbG9va2luZyBmb3J3YXJkIHRvIHNlZSB0aGUgcGFwZXIuDQoNCg0KNS4xIEh5 U3RhcnRSZXN0YXJ0DQoNCnMvYWxnb3JpdGhtIHVzZWQvYWxnb3JpdGhtIGlzIHVzZWQvDQoNCklu IHRoZSBuZXcgY29kZSwgaXQgd291bGQgYmUgdXNlZnVsIHRvIGV4cGxhaW4gd2h5IHRoZSBzZWNv bmQgdGVzdCBiZWZvcmUgZG91Ymxpbmcgc3N0aHJlc2gsIGllLCB0aGUgdGVzdCBmb3IgaG93IGxv bmcgaXQgaGFzIGJlZW4gc2luY2UgdGhlIGxhc3QgaHlyZXN0YXJ0LiBBbHNvLCBpbiB0aGUgaGVh ZGVyIGRlZmluaXRpb25zLCBpZiB5b3UgaW50ZW5kIHRoZXJlIHRvIGJlIGNvbnN0cmFpbnRzIG9u IHRoZSByZWxhdGlvbiBiZXR3ZWVuIE5fUlRUX0hZUkVTVEFSVCBhbmQgTl9SVFRfTE9XIChlLmcu ICBOX1JUVF9IWVJFU1RBUlQgPiBOX1JUVF9MT1cpIHlvdSBvdWdodCB0byBzYXksIGJlY2F1c2Ug cGVvcGxlIHdpbGwgdHJ5IG90aGVyIHZhbHVlcy4NCg0KUmF0aGVyIHRoYW4gdGhlIHJhdGhlciBh cmJpdHJhcnkgd2FpdCBiZWZvcmUgYW4gYXJiaXRyYXJ5IGRvdWJsaW5nIG9mIHNzdGhyZXNoLCB3 b3VsZG4ndCBpdCBiZSBiZXR0ZXIgdG8gY29udGludWFsbHkgaW5jcmVhc2Ugc3N0aHJlc2ggKG5v dCBuZWNlc3NhcmlseSBsaW5lYXJseSkgdGhlIGxvbmdlciB0aGUgUlRUIGhhcyByZW1haW5lZCBv bmx5IGp1c3QgaGlnaGVyIHRoYW4gdGhlIG1pbiBSVFQ/DQpbSUpdIFllcywgY291bGQgYmUgYW4g b3B0aW9uDQoNCg0KKEJUVywgc3VyZWx5IHRoZSBtYWluIHByb2JsZW0gd2l0aCB0aGlzIG1vZGlm aWNhdGlvbiB0byBIeVN0YXJ0UmVzdGFydCBpcyB0aGF0IGlzIHJlcXVpcmVzIGEgbnVtYmVyIG9m IHJvdW5kIHRyaXBzIHRvIHJlZHVjZSBkZWxheSAtIGEgc29ydC1vZiBveHltb3Jvbi4pDQpbSUpd IFllcywgaGF2ZSB0cmllZCBzb21lIG1vcmUgZXhwZXJpbWVudHMgd2l0aCB0aGlzIGFsZ29yaXRo bS4gQW5kIEkgYW0gZ2V0dGluZyBtb3JlIGhlc2l0YW50LiBUaGUgcHJvYmxlbSBpcyB0aGF0IHdo ZW4gSSBhZGQgbW9yZSBub2lzZSAobW9kZWxpbmcgb2Ygc21hbGwgb2JqZWN0cyB0cmFmZmljKSBp bnRvIHRoZSBzeXN0ZW0gc2ltdWxhdGlvbiwgdGhlbiBJIGFsc28gZ2V0IG1vcmUgZGVsYXkgaml0 dGVyIGFuZCB0aGUgZGVsYXkgZGV0ZWN0aW9uIGFsZ29yaXRobSBpbiBIeVN0YXJ0IGlzIG5vdG9y aW91c2x5IHNlbnNpdGl2ZSB0byBkZWxheSBqaXR0ZXIuDQoNCg0KNS4yLiAgSHlicmlkIEN1Ymlj DQoNCiAgIEZ1cnRoZXJtb3JlIGl0IGlzIGFzc3VtZWQgdGhhbiB0aGUgdGltZXN0YW1wIGNsb2Nr IGZyZXF1ZW5jeSBpbg0KDQogICBzZW5kZXIgYW5kIHJlY2VpdmVyIGFyZSBpZGVudGljYWwgb3Ig dGhhdCB0aGUgc2VuZGVyIGNhbiBpbmZlciB0aGUNCg0KICAgdGltZXN0YW1wIGNsb2NrIGZyZXF1 ZW5jeSBvZiB0aGUgcmVjZWl2ZXIgYW5kIHJlY29tcHV0ZSB0aW1lc3RhbXANCg0KICAgdmFsdWVz IGJhc2VkIG9uIHRoaXMgaW5mb3JtYXRpb24uDQpSZWNlbnRseSBvbiB0Y3BtIEkgc2VudCB5b3Ug YSBwb2ludGVyIHRvIHRoZSBjaGlycGluZyBwYXBlciBNaXJqYSAmIEkgZGlkLCB3aGljaCBhbHNv IG1hZGUgdGhpcyBhc3N1bXB0aW9uLiBQYXJ0bHkgcHJvbXB0ZWQgYnkgdGhhdCwgUmljaGFyZCBT Y2hlZmZlbmVnZ2VyIHRyaWVkIHRvIGdldCBwZW9wbGUgaW50ZXJlc3RlZCBpbiBzdGFuZGFyZGlz aW5nIHVzZSBvZiB0aGUgdGltZXN0YW1wIG9wdGlvbiBvbiBhIFNZTiB0byBuZWdvdGlhdGUgc3R1 ZmYgbGlrZSB0aW1lciByZXNvbHV0aW9uLiBJIGRvbid0IHRoaW5rIGl0IHdlbnQgYW55d2hlcmUu IERvIHlvdSB0aGluayB3ZSBvdWdodCB0byByZXZpdGFsaXNlIHRoYXQ/IFlvdSBtZW50aW9uIGlu ZmVyZW5jZSAtIGhhdmUgeW91IHRyaWVkIHRoYXQgLSBhcmUgdGhlcmUgY2FzZXMgd2hlcmUgaXQg ZG9lc24ndCB3b3JrPw0KW0lKXSBZZXMsIGFjdHVhbGx5IHdvbmRlcmVkIHdoYXQgaGFwcGVuZWQg dG8gUmljaGFyZHMgZHJhZnQuIEkgb25seSBicmllZmx5IHRyaWVkIG91dCB0aGUgaW5mZXJlbmNl IGFsZ29yaXRobSB3aXRoIGEgVENQIExFREJBVCBpbXBsZW1lbnRhdGlvbiAoaHR0cHM6Ly9naXRo dWIuY29tL3NpbHZpb3YvVENQLUxFREJBVC9ibG9iL21hc3Rlci9zcmMvdGNwX2xlZGJhdC5jKS4g SSByZWNhbGwgdGhhdCBpdCB0b29rIGEgd2hpbGUgdG8gY29udmVyZ2UuIEFsc28gSSBhbSBub3Qg c3VyZSBoZXJlLiBJcyBIeiBpbiBlLmcgYSBsaW51eCBzdGFjayBmaXhlZC4gPw0KSSBiZWxpZXZl IHNvLiBCdXQgSSBkb24ndCBrbm93IGFib3V0IGVtYmVkZGVkIHN5c3RlbXMgZXRjLg0KDQpDaGVl cnMNCg0KDQoNCkJvYg0KDQoNCg0KDQpUaGF0J3MgaXQuIFRoYW5rcyBhZ2FpbiBmb3IgdGhlIGRy YWZ0LiBWIHVzZWZ1bC4NCg0KDQoNCkJvYg0KDQpPbiAxNS8xMC8xNSAwNjowOCwgSW5nZW1hciBK b2hhbnNzb24gUyB3cm90ZToNCg0KSGkNCg0KDQoNCkEgbmV3IElFVEYgZHJhZnQgaXMgc3VibWl0 dGVkIGluIHJlc3BvbnNlIHRvIGdlbmVyYWwgZGlzY3Vzc2lvbiB0aGF0IGZvciBpbnN0YW5jZSBU Q1AgQ3ViaWMgaXMgbm90IGFuIGFwcHJvcHJpYXRlIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0 aG0gZm9yIExURS4NCg0KVGhlIGRyYWZ0IGJyaWVmbHkgb3V0bGluZXMgdHlwaWNhbCA0RyBhY2Nl c3MgYmVoYXZpb3Igb24gdGhlIFBEQ1AsIFJMQyBhbmQgTUFDICBsYXllcnMgdGhhdCBjYW4gaGF2 ZSBhbiBpbXBhY3Qgb24gdHJhbnNwb3J0IHByb3RvY29sIHBlcmZvcm1hbmNlLiBUaGUgZHJhZnQg YWxzbyBvdXRsaW5lcyB0d28gcmVsYXRpdmVseSBzaW1wbGUgbW9kaWZpY2F0aW9ucyB0byB0aGUg Q3ViaWMgY29uZ2VzdGlvbiBjb250cm9sLg0KDQoNCg0KL0luZ2VtYXINCg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQoNCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10NCg0KU2VudDogZGVuIDE0IG9rdG9iZXIgMjAxNSAyMDoxNw0KDQpUbzogSW5nZW1hciBK b2hhbnNzb24gUw0KDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWpvaGFuc3Nvbi1jYy1mb3ItNGctNWctMDAudHh0DQoNCg0KDQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWpvaGFuc3Nvbi1jYy1mb3ItNGctNWctMDAudHh0DQoNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSW5nZW1hciBKb2hhbnNzb24gYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KTmFtZTogICAgICAgICAgIGRyYWZ0LWpvaGFuc3Nv bi1jYy1mb3ItNGctNWcNCg0KUmV2aXNpb246ICAgICAgIDAwDQoNClRpdGxlOiAgICAgICAgICBD b25nZXN0aW9uIGNvbnRyb2wgZm9yIDRHIGFuZCA1RyBhY2Nlc3MNCg0KRG9jdW1lbnQgZGF0ZTog IDIwMTUtMTAtMTQNCg0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KDQpQ YWdlczogICAgICAgICAgMTQNCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLTAwLnR4dA0KDQpT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9o YW5zc29uLWNjLWZvci00Zy01Zy8NCg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLTAwDQoNCg0KDQoNCg0KQWJz dHJhY3Q6DQoNCiAgIFRoaXMgbWVtbyBvdXRsaW5lcyB0aGUgY2hhbGxlbmdlIHRoYXQgNEcgYW5k IDVHIGFjY2VzcyBicmluZ3MgZm9yDQoNCiAgIHRyYW5zcG9ydCBwcm90b2NvbCBjb25nZXN0aW9u IGNvbnRyb2wgYW5kIGFsc28gb3V0bGluZXMgYSBmZXcgc2ltcGxlDQoNCiAgIGV4YW1wbGVzIHRo YXQgY2FuIGltcHJvdmUgdHJhbnNwb3J0IHByb3RvY29sIGNvbmdlc3Rpb24gY29udHJvbA0KDQog ICBwZXJmb3JtYW5jZSBpbiA0RyBhbmQgNUcgYWNjZXNzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0K DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCg0KDQotLQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkJv YiBCcmlzY29lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9ib2JicmlzY29l Lm5ldC8NCg0KDQoNCi0tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQm9iIEJyaXNjb2UgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgaHR0cDovL2JvYmJyaXNjb2UubmV0Lw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1A aWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RjcG0NCg== --_000_81564C0D7D4D2A4B9A86C8C7404A13DA34EB59DEESESSMB205erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLCJzZXJp ZiI7fQ0KdHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0 YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6U1Y7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFz dC1sYW5ndWFnZTpTVjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IlNWIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Zb3UgYXJlIHJpZ2h0IHRoYXQg dGhlIG1lc3NhZ2UgaXMgcXVpdGUgdmFndWUsIHRoZSByZWFzb24gaXMgdGhhdCBhdCBsZWFzdCBJ IGRvbuKAmXQgaGF2ZSBhbiBleGFjdCBhbnN3ZXIgdG8gdGhhdCBxdWVzdGlvbi4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW4gYXR0ZW1wdCBhdCBhbiBleGFj dCBydWxlIGlzIHRoYXQgdGhlcmUgc2hvdWxkIGJlIGV4YWN0bHkgYXMgbXVjaCBkYXRhIGF2YWls YWJsZSBhcyBjYW4gYmUgc2NoZWR1bGVkIGluIHRoZSBuZXh0IHNjaGVkdWxpbmcgZXZlbnQuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm9ibGVtIGlz IHRoYXQgaXQgaXMgbm90IG9idmlvdXMgd2hlbiB0aGF0IHNjaGVkdWxpbmcgZXZlbnQgb2NjdXJz IChkZXBlbmRzIG9uIHNjaGVkdWxpbmcgYWxnb3JpdGhtKSBvciBob3cgbXVjaCBkYXRhIGNhbiBi ZSBzY2hlZHVsZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNvLCBpZiBvbmUgbG9vayBhdCBwZWFrIHRocm91Z2hwdXQgYWxvbmUgaXQgaXMgdHJ1ZSB0aGF0 IGl0IHBheXMgb2ZmIHRvIHVzZSBDQyBhbGdvcml0aG1zIHRoYXQgZ2VuZXJhdGUgbGFyZ2VyIHN0 YW5kaW5nIHF1ZXVlcyAoQ3ViaWMgaXMgYmV0dGVyDQogdGhhbiBMRURCQVQgb3IgVmVnYXMpLiBU aGUgcHJpY2UgcGFpZCBmb3IgdGhpcyBpcyBvZiBjb3Vyc2UgdGhhdCBsYXRlbmN5IHNlbnNpdGl2 ZSBzZXJ2aWNlcyBjYW4gc3VmZmVyIHdoZW4gbGFyZ2Ugc3RhbmRpbmcgcXVldWVzIGFyZSBhbGxv d2VkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBzaG9y dCwgb25lIG5lZWQgdG8gY29tcHJvbWlzZSwgaWYgb25lIHRha2UgdGhlIGV4YW1wbGUgdGhhdCBX ZWJSVEMgbWVkaWEgdHJhdmVyc2VzIHRoZSBzYW1lIGFjY2VzcywgdGhlbiBpdCBpcyBsaWtlbGt5 IGJldHRlciB0byBhY2NlcHQgdGhhdA0KIHRoZSBmaWxlIHRyYW5zZmVyIHRha2VzIGEgd2hpbGUg bG9uZ2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4vSW5nZW1hcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBZdWNodW5nIENoZW5nIFttYWlsdG86eWNoZW5nQGdvb2ds ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDUgbm92ZW1iZXIgMjAxNSAwNjoxMzxicj4N CjxiPlRvOjwvYj4gQm9iIEJyaXNjb2U8YnI+DQo8Yj5DYzo8L2I+IHRjcG1AaWV0Zi5vcmcgRXh0 ZW5zaW9uczsgSW5nZW1hciBKb2hhbnNzb24gUzsgdHN2d2dAaWV0Zi5vcmc7IGljY3JnQGlydGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdGNwbV0gW3RzdndnXSBGVzogTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLTAwLnR4dDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+SSBo YXZlIGEgcXVlc3Rpb24gcmU6IGhvdyBtdWNoIGJ1ZmZlciBvciBiYWNrbG9nIGlzIG5lZWRlZCB0 byBwcmV2ZW50IHRoZSBzY2hlZHVsYXIgZnJvbSByZWR1Y2luZyB0aGUgcmF0ZSBvciBldmVuIGlu Y3JlYXNlIHRoZSByYXRlLiBJIHRoaW5rIHRoaXMga2V5IHdoeSBjdWJpYyBvciBidWZmZXJibG9h dCBjYyB3aW5zIGJjIG90aGVyIHF1ZXVlIGNvbnRyb2xsaW5nIGNjIHdvdWxkIGxvc2Ugb3V0Ljxv OnA+PC9vOnA+PC9wPg0KPHA+Rm9yIGV4YW1wbGUgaWYgdGhlIHNjaGVkdWxlciBuZWVkcyAxbWIg YmFja2xvZyB0byBtYWludGFpbiBhdCA0MG1icHMuIEEgZGN0Y3Agb3IgdmVnYXMga2VlcGluZyB0 aGUgcXVldWUgd2VsbCBiZWxvdyB3aWxsIGdldCBzYXkgNW1icHMuDQo8bzpwPjwvbzpwPjwvcD4N CjxwPlRoZSBkcmFmdCBtZW50aW9ucyBhYm91dCB0aGlzIGJ1dCB0aGUgYWR2aXNlIGlzIGEgYml0 IHZhZ3VlIGZvciBjYyBkZXNpZ25lci48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBOb3YgNSwgMjAxNSA3OjI3IEFNLCAmcXVvdDtCb2IgQnJpc2NvZSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiPmlldGZAYm9iYnJpc2Nv ZS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkluZ2VtYXIsPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDQvMTEvMTUgMTM6MjcsIEluZ2Vt YXIgSm9oYW5zc29uIFMgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+QW5kIHRoYW5rcyBmb3IgdGhlIHJldmlldywgY29tbWVudHMvYW5zd2Vycy9xdWVzdGlv bnMgaW5saW5lIGJlbG93PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4v SW5nZW1hcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQm9iDQogQnJpc2NvZSBbPGEg aHJlZj0ibWFpbHRvOmlldGZAYm9iYnJpc2NvZS5uZXQiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86 aWV0ZkBib2JicmlzY29lLm5ldDwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDI5IG9rdG9i ZXIgMjAxNSAxODo1NDxicj4NCjxiPlRvOjwvYj4gSW5nZW1hciBKb2hhbnNzb24gUzsgPGEgaHJl Zj0ibWFpbHRvOmljY3JnQGlydGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNjcmdAaXJ0Zi5vcmc8 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50Y3Bt QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRzdndnQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+DQp0c3Z3Z0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0c3Z3 Z10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtam9oYW5zc29uLWNjLWZv ci00Zy01Zy0wMC50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+SW5nZW1hciw8YnI+DQo8YnI+DQpBcyBwcm9taXNlZCwgaGVyZSdzIG15IGNvbW1lbnRzLiBU aGV5IGFyZSBhIG1peCBvZiBzdWdnZXN0ZWQgaW1wcm92ZW1lbnRzIHRvIHRoZSBkcmFmdCwgc3Vn Z2VzdGVkIGltcHJvdmVtZW50cyB0byA1Rywgb3IgcmVxdWVzdHMgZm9yIGNsYXJpZmljYXRpb24u IEkgYWxzbyBhZ3JlZSB3aXRoIGFsbCBLZXZpbiBTbWl0aCdzIGNvbW1lbnRzLCBzbyBJIGRpZG4n dCByZXBlYXQgYW55Ljxicj4NCltTb3JyeSBmb3IgZGVsYXkgLSBJIGhhZCB0byBmaW5kIHRpbWUg dG8gcmUtdHlwZSBhZnRlciBsb3NpbmcgbXkgcmV2aWV3IGR1cmluZyBhIHBvd2VyIG91dGFnZV08 YnI+DQo8YnI+DQo8Yj48dT5Db250ZXh0IHF1ZXN0aW9ucy48L3U+PGJyPg0KPC9iPlExLiBJcyB0 aGlzIGV4ZXJjaXNlIHRyZWF0aW5nIHRoZSA1RyBzcGVjcyBzb2xlbHkgaW4gcmVhZC1vbmx5IG1v ZGU/IE9yLCBpZiBzb21lIHVzZWZ1bCBkZXNpZ24gc3VnZ2VzdGlvbnMgYXJpc2UsIGlzIHRoZXJl IGFueSBjaGFuY2UgdGhhdCB0aGUgM0dQUCBtaWdodCB0YWtlIHRoZW0gb24gYm9hcmQsIGdpdmVu IDVHIGlzIG5vdCBmdWxseSBiYWtlZCB5ZXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+W0lKXSBHdWVzcyBpdCBkZXBlbmRzLCBuZWVkIHRvIHNheSB0aGF0IEkgcHJvYmFibHkgdGhl IHNtYWxsIGNvZyBpbiB0aGUgd2hlZWwuIEkgd291bGQgc2F5DQogdGhhdCBhIGxvdCBvZiB0aGUg c3RhbmRhcmRzIHdvcmsgaW4gSUVURiBoYXMgYmVlbiBwaWNrZWQgdXAgYnkgM0dQUCBhbmQsIEkg Y2Fubm90IHNheSB3aGF0IHdpbGwgaGFwcGVuIGluIHRoZSA1RyBjb250ZXh0Lg0KPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQpJdCdzIGdyZWF0IHRoYXQgeW91IGhhdmUgdGFr ZW4gdGhpcyBpbml0aWF0aXZlLiA8L3NwYW4+RG9lcyB0aGUgM0dQUCBldmVyIGZvcm1hbGx5IGFz ayB0aGUgSUVURiBmb3IgY29tbWVudHMgb24gaXRzIGlkZWFzIGZvciBlYWNoIG5ldyBnZW5lcmF0 aW9uIG9mIHJhZGlvPyBHaXZlbiB0aGUgbGF5ZXJzIGFib3ZlIGNhbiBiZSB0aG91Z2h0IG9mIGFz IHRoZSAnY3VzdG9tZXJzJyBvZiB0aGUgM0dQUCwgYW5kIHRoZXNlICdjdXN0b21lcicgbGF5ZXJz DQogYXJlIHByZXR0eSBtdWNoIGFsbCBtYWludGFpbmVkIGJ5IHRoZSBJRVRGLCBpdCB3b3VsZCBz ZWVtIGVzc2VudGlhbCAoYW5kIGNvdXJ0ZW91cykgZm9yIHRoZSAzR1BQIHRvIGFzayBmb3IgY3Vz dG9tZXIgY29tbWVudCwgbm90IGxlYXN0IHRvIGNvLW9yZGluYXRlIHdpdGggd2hhdGV2ZXIgZnV0 dXJlIHBsYW5zIHRoZSBJRVRGIG1pZ2h0IGhhdmUgZm9yIHRoZSBoaWdoZXIgbGF5ZXJzLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltJSl0gV2hhdCB5b3Ugc2F5IG1ha2VzIG11Y2gg c2Vuc2UuIEkgZ3Vlc3MgdGhlcmUgaXMgc29tZSBuYXR1cmFsIGxlYWthZ2UgYmV0d2VlbiAzR1BQ IGFuZA0KIElFVEYgYXMgbWFueSBvZiB0aGUgSUVURmVycyBhcmUgYWxzbyBhY3RpdmUgaW4gM0dQ UCBzdGFuZGFyZGl6YXRpb24uIEkgZG9u4oCZdCBoYXZlIGZ1bGwgaW5zaWdodCBpbiB0aGUgZm9y bWFsIHJlbGF0aW9uIGJldHdlZW4gM0dQUCBhbmQgSUVURiBpbiB0aGVzZSBhcmVhcywgbm90IHN1 cmUgaWYgdGhhdCBuZWVkIHRvIGJlIGJldHRlciwgYnV0IGlmIHRoYXQgaXMgdGhlIGNhc2UsIHRo ZW4gaXQgaXMgcHJvYmFibHkgYSBxdWVzdGlvbiBmb3IgdGhlDQogYXJlYSBkaXJlY3RvcnMuIE5l ZWQgdG8gc2F5IHRoYXQgZXZlbiB0aG91Z2ggdGhlIGZvcm1hbCBjaGFubmVscyBhcmUgc2NhcmNl IGl0IGRvZXMgcHJvYmFibHkgbm90IG1lYW4gdGhhdCAzR1BQIGlnbm9yZXMgSUVURiBvciB3aGF0 IGhhcHBlbnMgYWJvdmUgSVAgaW4gZ2VuZXJhbC4gRm9yIGluc3RhbmNlIHRoZSByZWNlbnQgd29y ayBhcm91bmQgVENQIFJBQ0sgcmFpc2VzIHRoZSBxdWVzdGlvbiBpZiBpdCBpcyBuZWNlc3Nhcnkg dGhhdCBMVEUgZGVmYXVsdA0KIHJhZGlvIGJlYXJlcnMgZW5zdXJlIGluIG9yZGVyIGRlbGl2ZXJ5 LiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdXNwZWN0IHRoYXQgM0dQUCByYWRpbyByZXNvdXJjZSBj b250cm9sIHBlb3BsZSBkbyBub3QgY3Jvc3MtZmVydGlsaXplIG11Y2ggd2l0aCB0aGUgSUVURi48 YnI+DQpTbyBtYXliZSBpdCBpcyBhcyBtdWNoIGEgcXVlc3Rpb24gb2YgaG93IHRvIGNvLW9yZGlu YXRlIGJldHdlZW4gdGhlc2UgcmFkaW8gcGVvcGxlIGFuZCBMNCwgd2hpY2ggSSB3b3VsZCBpbWFn aW5lIGlzIGFzIG11Y2ggYSBwcm9ibGVtIHdpdGhpbiAzR1BQIGFzIGJldHdlZW4gM0dQUCBhbmQg SUVURi48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0K UTIuIFdoYXQgYXJlIHlvdXIgcGxhbnMgZm9yIHRoaXMgZHJhZnQ/IDwvc3Bhbj5BcmUgeW91IGFz a2luZyBmb3IgYWRvcHRpb24/IEFuZCBpZiBzbywgaW4gd2hpY2ggV0cgb3IgUkc/IElDQ1JHIGxv b2tzIHRoZSBtb3N0IGFwcHJvcHJpYXRlLCBnaXZlbiB0aGUgY2hhcnRlcnMgb2YgYWxsIHRoZSBJ RVRGIGNjIFdHcyAoVFNWV0csIFRDUE0sIFJNQ0FULCBldGMpIGFyZSBzY29wZWQgb24ganVzdCBh IHN1YnNldCBvZiB5b3VyIGRvYy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bSUpd IEZpcnN0IG9iamVjdGl2ZSBpcyB0byBnZXQgYW4gaW5jcmVhc2VkIGludGVyZXN0IGluIGNvbmdl c3Rpb24gY29udHJvbCBhbGdvcml0aG0gd29yaw0KIGluIHRoZSBJRVRGLiBUcmFkaXRpb25hbGx5 IHRoaXMga2luZCBvZiB3b3JrIHNlZW0gdG8gYmUgbW9yZSBpbiB0aGUgdGVybXMgb2YgY29uZmVy ZW5jZSBwYXBlcnMgaW4gZS5nLiBTaWdjb21tLCB0aGUgYmVuZWZpdCB3aXRoIGhhdmluZyBzdWNo IHdvcmsgaW4gSUVURiBpcyB0aGF0IGlucHV0IGZyb20gcGVvcGxlIHdpdGggYSB3aWRlciBleHBl cnRpc2UgYXJlYSAoaW5jbHVkaW5nIDNHUFAgZXhwZXJpdGlzZSkgY2FuIGdpdmUgYWxnb3JpdGht IHByb3Bvc2Fscw0KIHRoYXQgd29yayB3ZWxsIGZvciBhIHdpZGVyIHNldCBvZiBhY2Nlc3MgdHlw ZXMuIFRoZSB3b3JrIGFyb3VuZCBDdWJpYyBpcyBhIGZpcnN0IGdvb2Qgc3RlcCBhcyBpcyB0aGUg d29yayBhcm91bmQgRENUQ1AuIFdoYXQgSSB3b25kZXIgaXMgaWYgaXQgZmVhc2libGUgdG8gdGFr ZSB0aGlzIGEgYml0IGZ1cnRoZXIgPyBJIHdvdWxkIHRvbyBiZWxpZXZlIHRoYXQgdGhlIGN1cnJl bnQgZG9jIGZpdHMgYmV0dGVyIGluIElDQ1JHLiZuYnNwOyBUaGUgYWxnb3JpdGhtDQogZXhhbXBs ZXMgYXJlIGp1c3QuLiBleGFtcGxlcy4gTW9yZSBmcnVpdGZ1bCB3b3JrIGlzIHByb2JhYmx5IHRv IGRvY3VtZW50IGRpZmZlcmVudCBhY2Nlc3MgdHlwZXMgYW5kIGZyb20gdGhlcmUgZGVyaXZlIGEg c2V0IG9mIGJlc3QgY3VycmVudCBwcmFjdGljZXMgZm9yIGNvbmdlc3Rpb24gY29udHJvbCBhbGdv cml0aG1zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkknbSBzdXJlIHRoZSBpY2NyZyBjaGFpcnMgd291bGQgbGlrZSB0aGlzIHRvIGhh cHBlbi4gQW5kIGluaXRpYXRpdmVzIGxpa2UgeW91cnMgdG8gY29tZSB3aXRoIHByb3Bvc2FscyB0 byBwcm9wb3NlIHNwZWNpZmljIGNvZGUgdG8gdGFrZSBhY2NvdW50IG9mIEwyIEkgdGhpbmsgZ2Vu ZXJhdGUgdGhlIHJpZ2h0IGxldmVsIG9mIGRpYWxvZ3VlLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8Yj48dT5TZWN0aW9uIGJ5IFNlY3Rpb24gUmV2 aWV3PC91Pjxicj4NCjwvYj48YnI+DQo8Yj5BbGwgc2VjdGlvbnM8YnI+DQo8L2I+PGJyPg0KVGhl IGRvY3VtZW50IGdlbmVyYWxseSB0YWxrcyBhYm91dCB0aGUgTFRFIHByb3RvY29sIHN0YWNrIGFz IGlmIGRhdGEgaXMgdHJhdmVsbGluZyBkb3duIGl0Lg0KPC9zcGFuPkFyZSB5b3UgaW1wbHlpbmcg dGhhdCBtb3N0IHNvdXJjZXMgb2YgYnVmZmVyaW5nIGRlbGF5IGFyZSBhdCB0aGUgc2VuZGluZyBl bmQsIGFuZCB0aGUgZmVlZGJhY2sgZW5kIGlzIHByZXR0eSB1bmVuY3VtYmVyZWQgYnkgZGVsYXlz PyBJIHRoaW5rIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBleHBsaWNpdGx5IHNheSBzb21ldGhpbmcg YWJvdXQgdGhpcyAod2hldGhlciB0cnVlIG9yIG5vdCksIHRvIGV4cGxhaW4gd2h5IG9ubHkgb25l IGRpcmVjdGlvbg0KIG9mIHRyYXZlbCBpcyBkaXNjdXNzZWQgaW4gdGhlIGRvYy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bSUpdIFRoZSBmZWVkYmFjayBwYXRoIGlzIGVuY3VtYmVy ZWQgYnkgZGVsYXlzLCBpdCBpcyBwZXJoYXBzIG5vdCB0aGF0IGNsZWFyIGJ1dCBzZWN0aW9uIDIu My4yDQogaW1wbGllcyB0aGF0IGRlbGF5ICh2YXJpYXRpb24pIGluIHVwbGluayB3aWxsIGFmZmVj dCB0aGUgQUNLcyBmb3IgZG93bmxpbmsgZGF0YSB0cmFmZmljLiBUaGF0IHNhaWQsIHRoZSBkaWZm ZXJlbmNlIGluIERML1VMIHRyYWZmaWMgaXMgdG9kYXkgc29tZXRoaW5nIGxpa2UgMTA6MSBhbmQg dGhhdCBpcyBwcm9iYWJseSBvbmUgcmVhc29uIHdoeSBvbmUgY2FuIGdldCB0aGUgZmVlbGluZyB0 aGF0IHRoZSBkcmFmdCBpcyBzbGFudGVkIHRvd2FyZHMgZG93bmxpbmsNCiBkYXRhIHRyYWZmaWMs IHRoaXMgbWF5IGhvd2V2ZXIgY2hhbmdlIHdpdGggdGltZSBhcyBtb3JlIG1hY2hpbmUgdHlwZSB0 cmFmZmljIG1heSBlbnRlciB0aGUgc3lzdGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhcyB0aGlua2luZyBtb3JlIGluIHRl cm1zIG9mIHVwIHRoZSBzdGFjayB2cy4gZG93biB0aGUgc3RhY2ssIG5vdCB1cGxpbmsvZG93bmxp bmsuIEkuZS4gZm9yIGJvdGggY2FzZXM6PGJyPg0KKiBkb3dubGluayBkaXJlY3Rpb246IGFyZSB0 aGVyZSBhbnkgYnVmZmVyaW5nIGNvbmNlcm5zIGNvbWluZyB1cCB0aGUgc3RhY2sgYXQgdGhlIFVF LCBvciBvbiB0aGUgZmVlZGJhY2sgYmFjay1jaGFubmVsIGZyb20gdGhlIFVFPzxicj4NCiogdXBs aW5rIGRpcmVjdGlvbjogYXJlIHRoZXJlIGFueSBidWZmZXJpbmcgY29uY2VybnMgY29taW5nIHVw IHRoZSBzdGFjayBhdCB0aGUgZU5vZGVCLCBvciBvbiB0aGUgZmVlZGJhY2sgYmFjay1jaGFubmVs IGZyb20gdGhlIGVOb2RlQj88YnI+DQo8YnI+DQpGb3IgaW5zdGFuY2UsIGluIHRoZSBVRSwgcGVy aGFwcyBvbmUgYXBwIGJsb2NraW5nIHRoZSByZWFkIG9mIGFub3RoZXIgZHVlIHRvIHRoZSB3YXkg ezMtNX1HIG11bHRpcGxleGVzIGRpZmZlcmVudCBzdHJlYW1zIGludG8gdGhlIHNhbWUgUERDUCBm cmFtZXM/PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4N CjxiPjIuMSBQRENQIGxheWVyPGJyPg0KPC9iPjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+PHR0PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+UERDUCBh bHNvIGVuc3VyZXMgdGhhdCBhbGw8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0K PC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZu YnNwOyZuYnNwOyBwYWNrZXRzIGFyZSBkZWxpdmVyZWQgaW4gb3JkZXIgdXAgdG8gaGlnaGVyIGxh eWVycy48L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPC9zcGFuPkkgdGhpbmsg dGhpcyBtZWFucyAmcXVvdDtpbiB0aGUgb3JkZXIgc2VudCBpbnRvIHRoZSBsaW5rIChQRENQKSBs YXllciZxdW90Oy4gVGhpcyBvdWdodCB0byBiZSBjbGFyaWZpZWQsIG90aGVyd2lzZSwgd2hlbiB3 cml0aW5nIGluIHRoZSBjb250ZXh0IG9mIGEgbGF5ZXIgNCBhdWRpZW5jZSwgaXQgbWlnaHQgYmUg YXNzdW1lZCB0aGlzIG1lYW5zIGluIHRoZSBvcmRlciBzZW50IGJ5IHRoZSBvcmlnaW5hbCB0cmFu c3BvcnQgbGF5ZXIgc291cmNlLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0lK XSBZZXMsIHlvdSBhcmUgcmlnaHQgLCByZW9yZGVyaW5nIGNhbiBzdGlsbCBvY2N1ciBlLmcuIGlu IHRoZSB3aXJlbGVzcyBiYWNraGF1bDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsga2VlcCB0aGUg YW1vdW50IG9mIGRhdGEgaW4gZmxpZ2h0IGFzIHNtYWxsIGFzIHBvc3NpYmxlLCB3aXRob3V0IHNh Y3JpZmljaW5nIHRocm91Z2hwdXQuPC9zcGFuPjwvdHQ+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N Cjwvc3Bhbj5JcyB0aGlzIGp1c3QgYSByYXRoZXIgY29udm9sdXRlZCB3YXkgb2Ygc2F5aW5nICZx dW90O2tlZXAgdGhlIFJUVCBhcyBsb3cgYXMgcG9zc2libGUmcXVvdDs/ICh3aGljaCBpbiB0dXJu IGltcGxpZXMga2VlcGluZyBxdWV1aW5nIGRlbGF5IGFzIGxvdyBhcyBwb3NzaWJsZSBhc3N1bWlu ZyB5b3UgY2Fubm90IGluZmx1ZW5jZSB0aGUgcGh5c2ljYWwgcGF0aC4pIE9yIHdlcmUgeW91IHRy eWluZyB0byBtYWtlIGEgbW9yZSBzdWJ0bGUgcG9pbnQ/IC0gaWYgc28sDQogaXQgd2FzIGxvc3Qg b24gbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0lKXSBObywgaXQgaXMgZXhh Y3RseSBhcyB5b3UgZGVzY3JpYmUgYmVsb3c8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8L3NwYW4+PHR0PjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7IFJlbGlh YmxlIGRlbGl2ZXJ5IGF0IGhhbmRvdmVyIG1heSBob3dldmVyIGJlIHR1cm5lZCBvZmYgb3IgaXMg c2ltcGx5IG5vdCBpbXBsZW1lbnRlZCw8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KSXQgd291bGQgYmUgdXNlZnVsIGlmIHlvdSBjb3VsZCBnaXZlIGEgZmVlbCBmb3Igcm91Z2hs eSBob3cgb2Z0ZW4gKGluICUpIHRoZXNlIGNhc2VzIGhvbGQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltJSl0gSSBkb27igJl0IGJlbGlldmUgdGhhdCBpdCBpcyBwb3Nz aWJsZSB0byBnaXZlIGEgZmlndXJlIGFzIHRoaXMgaXMgdmVuZG9yIHNwZWNpZmljLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N Cjxicj4NCjxiPjIuMiBSTEMgbGF5ZXI8L2I+PGJyPg0KPGJyPg0KPC9zcGFuPjx0dD48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyByb2xlIC4u LiBpcyB0byBlbnN1cmUgdGhhdCBwYWNrZXRzIGFyZSBkZWxpdmVyZWQgaW4gb3JkZXIgdXAgdG8g dGhlIGhpZ2hlciBsYXllcnM8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KRWg/ IDwvc3Bhbj5UaGUgUERDUCBzZWN0aW9uIGp1c3Qgc2FpZCBpdCBkaWQgb3JkZXJpbmcuIEFuZCB0 aGUgcmVzdCBvZiB0aGUgUkxDIHNlY3Rpb24gdGFsa3MgZXhjbHVzaXZlbHkgYWJvdXQgYnVmZmVy aW5nIGRlbGF5cyBuZWNlc3Nhcnkgd2hpbGUgZmlsbGluZyB0cmFuc3BvcnQgYmxvY2tzLiBJZiBv cmRlcmluZyBpcyB0aGUgcm9sZSBvZiBib3RoIGxheWVycywgc3VyZWx5IG9uZSB3aWxsIGhhdmUg bm90aGluZyB0byBkbyBvbmNlIHRoZSBvdGhlcg0KIGhhcyBnb3QgZXZlcnl0aGluZyBpbiBvcmRl cj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bSUpdIFJMQyBoYW5kbGVzIG9yZGVy aW5nIGR1ZSB0byB2YXJpb3VzIE1BQyBsYXllciBmYWlsdXJlcy4gUERDUCBoYW5kbGVzIG9yZGVy aW5nICZuYnNwO3doZW4gaGFuZG92ZXINCiBvY2N1cnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8L3NwYW4+PHR0 PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7Jm5ic3A7 IHZhcnlpbmcgc2l6ZSBvZiB0aGUgYXZhaWxhYmxlIHRyYW5zcG9ydDwvc3Bhbj48L3R0PjxzcGFu IGxhbmc9IkVOLVVTIj48YnI+DQpOaXQ6IEdpdmVuICd0cmFuc3BvcnQnIG1lYW5zIGUyZSBmb3Ig dGhlIGF1ZGllbmNlIG9mIHRoaXMgZHJhZnQsIHBscyB1c2UgYmVhcmVyIG9yIHNvbWVob3cgZGlz YW1iaWd1YXRlIHRoaXMgd29yZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+W0lKXSBPSzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxicj4NCkdhcCMxOiBJbiB0aGUgZHJhZnQsIGl0IHNl ZW1zIGxpa2UgdHJhbnNwb3J0IGJsb2NrcyBhcnJpdmUgYnkgbWFnaWMsIHRvIGJlIGZpbGxlZCBi eSBkYXRhIGJ1ZmZlcmVkIGluIHRoZSBSTEMgbGF5ZXIuDQo8L3NwYW4+VG8gdW5kZXJzdGFuZCB0 aGUgZGVsYXkgY29tcHJvbWlzZXMgaGVyZSwgSSB0aGluayB0aGUgZHJhZnQgbmVlZHMgdG8gZXhw bGFpbiB3aGF0IGRldGVybWluZXMgaG93IG11Y2ggdHJhbnNwb3J0IGJsb2NrIGNhcGFjaXR5IGVh Y2ggZmxvdyBpcyBnaXZlbiwgYW5kIGhvdyB0aGV5IGNhbiBpbmZsdWVuY2UgaXQuIEluIDNHLCBJ IGJlbGlldmUgdGhhdCB0aGUgdHJhbnNwb3J0IGxheWVyIGNvdWxkIGFzayB0aGUgcmFkaW8gcmVz b3VyY2UgY29udHJvbGxlcg0KIHRvIGNoYW5nZSByYWRpbyByZXNvdXJjZSBhbGxvY2F0aW9uLiBJ cyB0aGlzIHRoZSBzYW1lIGluIDRHICZhbXA7IDVHPyBEb2VzIHRoZSBiYWNrbG9nIG9mIHRoZSBi dWZmZXIgaW50byB0aGUgUkxDIGxheWVyIGhhdmUgYW55IGF1dG9tYXRpYyBpbmZsdWVuY2Ugb3Zl ciBhbGxvY2F0aW9uIG9mIGF2YWlsYWJsZSByZXNvdXJjZXM/IEkgYXNzdW1lIHRyYWZmaWMgY2xh c3MgY2FuIGFsc28gYmUgdXNlZCB0byBpbmZsdWVuY2UgYWxsb2NhdGlvbi48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5bSUpdIFdpbGwgdXBkYXRlZCB3aXRoIG1vcmUgZGV0YWlsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ PGJyPg0KPGJyPg0KR2FwIzI6IEluIGEgM0cgc3RhY2ssIHRoZSBSTEMgbGF5ZXIgbXVsdGlwbGV4 ZXMgYWxsIHRoZSBhY3RpdmUgYXBwbGljYXRpb24gc3RyZWFtcyBpbnRvIE1BQyBsYXllciB0cmFu c3BvcnQgYmxvY2sgYnkgZGljaW5nIHVwIGJ1ZmZlcmVkIHBhY2tldHMgYW5kIHBhY2tpbmcgdGhl IHBpZWNlcyBpbnRvIGVhY2ggdHJhbnNwb3J0IGJsb2NrLg0KPC9zcGFuPlRoZW4sIGF0IHRoZSBv dGhlciBlbmQgb2YgdGhlIGxpbmssIGVhY2ggcGllY2UgaGFzIHRvIGJlIGhlbGQgdW50aWwgdGhl IHJlc3Qgb2YgdGhlIHBhY2tldCBhcnJpdmVzLiBUaGlzIHNhY3JpZmljZXMgZGVsYXkgZm9yIGJh bmR3aWR0aCBlZmZpY2llbmN5LiBJcyB0aGlzIHN0aWxsIGRvbmUgaW4gNEcgYW5kIDVHPyBJZiBz bywgaXQgd291bGQgYmUgZ29vZCB0byB3cml0ZSBhYm91dCBtdXggZGVsYXkgaW4gdGhlIGRyYWZ0 IHRvby48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bSUpdIE9LLCB3aWxsIGFkZCBt b3JlIGluZm88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8Yj4yLjMgTUFDIGxheWVyPGJyPg0KPC9iPjxicj4NCjwv c3Bhbj48dHQ+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJz cDsmbmJzcDsgdGhlIG1heGltdW0gbnVtYmVyIG9mIHJldHJhbnNtaXNzaW9ucyBpcyBjb25maWd1 cmFibGU8L3NwYW4+PC90dD48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KV291bGRuJ3Qg aXQgYmUgYmV0dGVyIHRvIHNldCBhIGxpbWl0IG9uIHRoZSA8aT50aW1lPC9pPiBzcGVudCByZXRy YW5zbWl0dGluZywgc28gaXQgd291bGQgYXV0b21hdGljYWxseSBnaXZlIHVwIHdpdGggbGVzcyBy ZXRyYW5zbWlzc2lvbnMgZm9yIGxvbmdlciB0cmFuc21pc3Npb24gZGlzdGFuY2VzPzxicj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bSUpdIFBvc3NpYmxlLCA0RyBzcGVjaWZpZXMgYSBs aW1pdCB0byB0aGUgbnVtYmVyIG9mIHJldHJhbnNtaXNzaW9ucywgaW4gcHJhY3RpY2UgaXQgY2Fu IGJlIHRyYW5zbGF0ZWQgdG8gdGltZSBhcyBlYWNoIHJldHJhbnNtaXNzaW9uIGlzIDhtcyBsYXRl ci48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgZGlkbid0IHJlYWxpc2UgaXQgd2FzIGluZGVwZW5kZW50IG9mIGxpbmst UlRULiBUaGVuIHRoZSBtb3JlIGJhc2ljIHF1ZXN0aW9uIGlzIHdoeSBpcyBpdCBpbmRlcGVuZGVu dCBvZiBsaW5rLVJUVD8gU3VyZWx5IG9uIGEgc2hvcnQgbGluayBpdCBjYW4gYXNzdW1lIHRoYXQg aXQgbmVlZHMgdG8gcmV0cmFuc21pdCBtb3JlIHF1aWNrbHkgdGhhbiBvbiBhIGxvbmcgbGluaz88 YnI+DQo8YnI+DQpZb3UgY2FuIHNlZSB0aGF0IG15IHF1ZXN0aW9uIHdhcyBhc3N1bWluZyB0aGF0 IHJldHJhbnNtaXNzaW9uIGhhcHBlbmVkIG1vcmUgb2Z0ZW4gb24gYSBzaG9ydCBsaW5rLCB0aGVu IEkgd2FzIHNheWluZyBpdCBzaG91bGQgc3RpbGwgYmUgYWxsb3dlZCB0aGUgc2FtZSBhbW91bnQg b2YgdGltZSB0byBrZWVwIHJldHJ5aW5nIChzbyBvbiBhIHNob3J0IGxpbmsgaXQgd291bGQgYmUg YWxsb3dlZCB0byByZXRyYW5zbWl0IG1vcmUgdGltZXMgYmVmb3JlDQogZ2l2aW5nIHVwLCBidXQg dGhlIG1heCBkZWxheSB3b3VsZCBiZSB0aGUgc2FtZSkuPGJyPg0KPGJyPg0KOG1zISBJIHdhcyBh c3N1bWluZyBpdCB3b3VsZCBiZSByYXRoZXIgbXVjaCBsZXNzIHRoYW4gdGhhdC4gU3VyZWx5IGEg bGluay1sYXllciBBQ0sgY291bGQgbmV2ZXIgdGFrZSB0aGF0IGxvbmcgaWYgdGhlIGZyYW1lIHdh cyBnb2luZyB0byBnZXQgdGhyb3VnaC48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4N CnMvb25seSBjaGVja3MgZm9yIHRoZSBwcmVzZW5jZSBvbiBkb3dubG9hZCBkYXRhIG9ubHkgYXQg cmVndWxhciBpbnRlcnZhbHMvPGJyPg0KJm5ic3A7L29ubHkgY2hlY2tzIGZvciB0aGUgcHJlc2Vu Y2Ugb2YgZG93bmxvYWQgZGF0YSBhdCByZWd1bGFyIGludGVydmFscy88YnI+DQo8c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+W09LXTwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGI+Mi4zLjIgVXBsaW5rIHNjaGVkdWxpbmc8YnI+ DQo8L2I+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBUaGUgc2NoZWR1bGluZyByZXF1ZXN0IGRvZXMgbm90IGlu ZGljYXRlIGhvdyBtYW55IGJ5dGVzIHRoZXJlIGFyZSBpbiB0aGUgdXBsaW5rIHF1ZXVlLjwvc3Bh bj48L3R0PjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8L3NwYW4+U2VlbXMgbGlrZSBhIGJhZCBv bWlzc2lvbi4gSXMgdGhlcmUgYSByZWFzb24/IElmIHRoZXJlIGFyZSBsZXNzIGJ5dGVzIHF1ZXVl ZCB0aGFuIHRoZSBiYXNlIHN0YXRpb24ncyBncmFudCwgc3VyZWx5IGl0IHdvdWxkIGJlIHVzZWZ1 bCBmb3IgdGhlIGJhc2Ugc3RhdGlvbiB0byBrbm93LCBzbyB0aGF0IGl0IGNhbiBncmFudCBtb3Jl IHRvIHNvbWV0aGluZyBlbHNlIHdoaWxlIHRoZSBwcmV2aW91cyBzaG9ydCB0cmFuc21pc3Npb24g aXMgY29tcGxldGluZy48YnI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPltJSl0gSXQgaXMgYSBkZXNpZ24gY2hvaWNlLiBBIGJ1ZmZlciBzdGF0dXMgcmVwb3J0IGlz IG1vcmUgYnVsa3ksIGEgc2NoZWR1bGluZyByZXF1ZXN0IGlzIGp1c3Qgb25lIGJpdC48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KWW91IHNheSB0 aGF0IHdoZW4gSEFSUSBicmVha3MgdXAgYSBzZXF1ZW5jZSBvZiBBQ0tzLCBpdCBjYW4gYWxzbyB0 cmlnZ2VyICZxdW90O2NvYWxlc2NpbmcgaXNzdWVzJnF1b3Q7Lg0KPC9zcGFuPkkgY2FuIHVuZGVy c3RhbmQgdGhhdCBpdCBjb3VsZCBjYXVzZSBBQ0sgY29tcHJlc3Npb24sIGJ1dCBhcmUgeW91IGlt cGx5aW5nIHNvbWV0aGluZyBjb2FsZXNjZXMgdGhlIEFDS3Mgb3IgdGhlIHN1YnNlcXVlbnQgZGF0 YT8gV2hhdCBkb2VzIHRoZSBjb2FsZXNjaW5nPw0KPHNwYW4gbGFuZz0iRU4tVVMiPlNpbWlsYXJs eSwgaW4gdGhlIGxhc3QgcGFyYSBvZiAyLjMuMiB5b3Ugc2F5ICZxdW90O1JlZHVjZWQgQUNLcyBj YW4gdW5mb3J0dW5hdGVseSBjYXVzZSBjb2FsZXNjaW5nLiZxdW90OyBhbmQgYWdhaW4gSSdtIG5v dCBzdXJlIHdoYXQgaXMgY29hbGVzY2luZyB3aGF0IGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltJSl0gV2hhdCBJIGNhbiBzZWUgaW4gc2ltdWxhdGlvbnMgaXMg dGhhdCB0aGUgQUNLIGNvbXByZXNzaW9uIGxlYWRzIHRvIGNvYWxlc2Npbmcgd2hpY2ggZnVydGhl cg0KIGNhbiBpbmNyZWFzZSBqaXR0ZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3RpbGwgZG9uJ3QgdW5kZXJzdGFuZC4gVGhl IHF1ZXN0aW9uIHdhcyAmcXVvdDtXaGF0IGlzIGNvYWxlc2Npbmcgd2hhdD8mcXVvdDs8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KVGhlcmUgY291bGQgYmUgYSBw b3NpdGl2ZSBzaWRlIHRvIHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIEFDSyBjbG9ja2luZyBhbmQg bGluayBhZ2dyZWdhdGlvbiwgYXQgbGVhc3QgZm9yIGxvbmctcnVubmluZyBmbG93cy4NCjwvc3Bh bj5UaGlzIGhhcyBiZWVuIG9ic2VydmVkIGluIDgwMi4xMW4gV2lGaSB3aGVyZSB0aGUgYnVmZmVy aW5nIGFuZCBhZ2dyZWdhdGlvbiBvZiBtdWx0aXBsZSBBQ0tzIGludG8gb25lIHRyYW5zbWlzc2lv biBncmFudCB0ZW5kIHRvIGxlYWQgdGhlIHNlbmRlciB0byBidW5jaCBtdWx0aXBsZSBkYXRhIHNl Z21lbnRzIHNvIHRoYXQgdGhleSBhbGwgbmljZWx5IGZpbGwgb25lIHRyYW5zbWlzc2lvbiBncmFu dCBpbiB0aGUgb3RoZXIgZGlyZWN0aW9uDQogW1Nob3dhaWwxNF0uIDxzcGFuIGxhbmc9IkVOLVVT Ij5BcyBsb25nIGFzIHRoZSB0cmFuc21pc3Npb24gZ3JhbnQgZG9lcyBub3Qgd2FpdCBmb3IgbW9y ZSBkYXRhICh3aGljaCB1bmZvcnR1bmF0ZWx5IEkgZG9uJ3QgdGhpbmsgaXMgdGhlIGNhc2UgaW4g M0cvNEcvNUcpLCB0aGlzIGNvdWxkIGJlIGdvb2QgZm9yIGJhbmR3aWR0aCB1dGlsaXNhdGlvbiBv ZiBlbGVwaGFudHMgYW5kIGxhdGVuY3kgb2YgbWljZSwgaW5jbHVkaW5nIHdoZW4gdGhleSBhcmUN CiBtaXhlZC48YnI+DQo8YnI+DQpbU2hvd2FpbDE0XSBTaG93YWlsLCBBLiwgSmFtc2hhaWQsIEsu ICZhbXA7IFNoaWhhZGEsIEIuLCAmcXVvdDtXUU06IEFuIEFnZ3JlZ2F0aW9uLWF3YXJlIFF1ZXVl IE1hbmFnZW1lbnQgU2NoZW1lIGZvciBJRUVFIDgwMi4xMU4gQmFzZWQgTmV0d29ya3MsJnF1b3Q7 IEluOiBQcm9jZWVkaW5ncyBvZiB0aGUgMjAxNCBBQ00gU0lHQ09NTSBXb3Jrc2hvcCBvbiBDYXBh Y2l0eSBTaGFyaW5nIFdvcmtzaG9wIENTV1MgJzE0IHBwLjE1LTIwIEFDTSAoMjAxNCk8YnI+DQom bHQ7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9kbC5hY20ub3JnL2NpdGF0aW9uLmNmbT9pZD0yNjMw MDk3IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHA6Ly9kbC5hY20ub3Jn L2NpdGF0aW9uLmNmbT9pZD0yNjMwMDk3PC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bSUpdIEludGVyZXN0aW5nICx3aWxs IGxvb2sgYXQgaXQsIG5vdCBzdXJlIHRob3VnaCB0aGF0IGl0IHdpbGwgd29yayB0aGF0IHdlbGwg d2l0aCA0RyAoY2FudCBzYXkgYW55dGhpbmcgYWJvdXQgNUcpLCBpbiA0RyB0aGUgdHJhbnNtaXNz aW9uIGdyYW50cyBjYW4gdmFyeSBxdWl0ZSBhIGxvdCBvdmVyIHNob3J0IHRpbWUgc3BhbnMuPC9z cGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+ DQo8L3NwYW4+PGI+My4mbmJzcDsgNEcgYW5kIDVHIGV2b2x1dGlvbjxicj4NCjwvYj48YnI+DQpz L2EgZXhwbGljaXQvYW4gZXhwbGljaXQvPGJyPg0KPGJyPg0KPGI+NC4mbmJzcDsgUmVxdWlyZW1l bnRzIGZvciBpbXByb3ZlZCBwZXJmb3JtYW5jZTxicj4NCjwvYj48YnI+DQpzL2J1ZmZlcmJsb2F0 L2J1ZmZlci88YnI+DQo8YnI+DQo8Yj41LiZuYnNwOyBDb25nZXN0aW9uIGNvbnRyb2wgZXhhbXBs ZXM8YnI+DQo8L2I+PGJyPg0KUmVnYXJkaW5nIEh5YnJpZCBDdWJpYyB1c2luZyBPV0QgbWVhc3Vy ZW1lbnRzLCBJIGhhdmUgc2VlbiBhIHBhcGVyICh1bmRlciBzdWJtaXNzaW9uKSBhYm91dCBnZXR0 aW5nIGRlbGF5LWJhc2VkIGNvbmdlc3Rpb24gY29udHJvbHMgKGUuZy4gTEVEQkFUIG9yIENBSUEg RGVsYXkgR3JhZGllbnQpIHRvIGludGVyd29yayB3aXRoIEFRTXMgd2l0aCB2YXJpb3VzIGxvdyBk ZWxheSB0YXJnZXRzLiBJdCdzIG5vdCBpbiB0aGUgY29udGV4dCBvZiBjZWxsdWxhcg0KIG5ldHdv cmtzLCBidXQgSSdsbCB0cnkgdG8gcmVtZW1iZXIgdG8gcG9pbnQgaXQgb3V0IG9uY2UgaXQgZ2V0 cyBwdWJsaXNoZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0lKXSBTb3VuZHMg aW50ZXJlc3RpbmcgLCBsb29raW5nIGZvcndhcmQgdG8gc2VlIHRoZSBwYXBlci48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8 YnI+DQo8Yj41LjEgSHlTdGFydFJlc3RhcnQ8YnI+DQo8L2I+PGJyPg0Kcy9hbGdvcml0aG0gdXNl ZC9hbGdvcml0aG0gaXMgdXNlZC88YnI+DQo8YnI+DQpJbiB0aGUgbmV3IGNvZGUsIGl0IHdvdWxk IGJlIHVzZWZ1bCB0byBleHBsYWluIHdoeSB0aGUgc2Vjb25kIHRlc3QgYmVmb3JlIGRvdWJsaW5n IHNzdGhyZXNoLCBpZSwgdGhlIHRlc3QgZm9yIGhvdyBsb25nIGl0IGhhcyBiZWVuIHNpbmNlIHRo ZSBsYXN0IGh5cmVzdGFydC4NCjwvc3Bhbj5BbHNvLCBpbiB0aGUgaGVhZGVyIGRlZmluaXRpb25z LCBpZiB5b3UgaW50ZW5kIHRoZXJlIHRvIGJlIGNvbnN0cmFpbnRzIG9uIHRoZSByZWxhdGlvbiBi ZXR3ZWVuIE5fUlRUX0hZUkVTVEFSVCBhbmQgTl9SVFRfTE9XIChlLmcuJm5ic3A7IE5fUlRUX0hZ UkVTVEFSVCAmZ3Q7IE5fUlRUX0xPVykgeW91IG91Z2h0IHRvIHNheSwgYmVjYXVzZSBwZW9wbGUg d2lsbCB0cnkgb3RoZXIgdmFsdWVzLjxicj4NCjxicj4NClJhdGhlciB0aGFuIHRoZSByYXRoZXIg YXJiaXRyYXJ5IHdhaXQgYmVmb3JlIGFuIGFyYml0cmFyeSBkb3VibGluZyBvZiBzc3RocmVzaCwg d291bGRuJ3QgaXQgYmUgYmV0dGVyIHRvIGNvbnRpbnVhbGx5IGluY3JlYXNlIHNzdGhyZXNoIChu b3QgbmVjZXNzYXJpbHkgbGluZWFybHkpIHRoZSBsb25nZXIgdGhlIFJUVCBoYXMgcmVtYWluZWQg b25seSBqdXN0IGhpZ2hlciB0aGFuIHRoZSBtaW4gUlRUPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPltJSl0gWWVzLCBjb3VsZCBiZSBhbiBvcHRpb248L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQooQlRX LCBzdXJlbHkgdGhlIG1haW4gcHJvYmxlbSB3aXRoIHRoaXMgbW9kaWZpY2F0aW9uIHRvIEh5U3Rh cnRSZXN0YXJ0IGlzIHRoYXQgaXMgcmVxdWlyZXMgYSBudW1iZXIgb2Ygcm91bmQgdHJpcHMgdG8g cmVkdWNlIGRlbGF5IC0gYSBzb3J0LW9mIG94eW1vcm9uLik8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+W0lKXSBZZXMsIGhhdmUgdHJpZWQgc29tZSBtb3JlIGV4cGVyaW1l bnRzIHdpdGggdGhpcyBhbGdvcml0aG0uIEFuZCBJIGFtIGdldHRpbmcgbW9yZSBoZXNpdGFudC4N CiBUaGUgcHJvYmxlbSBpcyB0aGF0IHdoZW4gSSBhZGQgbW9yZSBub2lzZSAobW9kZWxpbmcgb2Yg c21hbGwgb2JqZWN0cyB0cmFmZmljKSBpbnRvIHRoZSBzeXN0ZW0gc2ltdWxhdGlvbiwgdGhlbiBJ IGFsc28gZ2V0IG1vcmUgZGVsYXkgaml0dGVyIGFuZCB0aGUgZGVsYXkgZGV0ZWN0aW9uIGFsZ29y aXRobSBpbiBIeVN0YXJ0IGlzIG5vdG9yaW91c2x5IHNlbnNpdGl2ZSB0byBkZWxheSBqaXR0ZXIu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PGJyPg0KPGJyPg0KPC9zcGFuPjxiPjUuMi4mbmJzcDsgSHlicmlkIEN1YmljPC9iPjxvOnA+ PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgRnVydGhlcm1vcmUgaXQgaXMgYXNzdW1lZCB0 aGFuIHRoZSB0aW1lc3RhbXAgY2xvY2sgZnJlcXVlbmN5IGluPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IHNlbmRlciBhbmQgcmVjZWl2ZXIgYXJlIGlkZW50aWNhbCBvciB0aGF0 IHRoZSBzZW5kZXIgY2FuIGluZmVyIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyB0aW1lc3RhbXAgY2xvY2sgZnJlcXVlbmN5IG9mIHRoZSByZWNlaXZlciBhbmQgcmVjb21w dXRlIHRpbWVzdGFtcDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB2YWx1ZXMg YmFzZWQgb24gdGhpcyBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij5SZWNlbnRseSBvbiB0Y3BtIEkgc2VudCB5b3UgYSBwb2ludGVyIHRvIHRoZSBjaGlycGlu ZyBwYXBlciBNaXJqYSAmYW1wOyBJIGRpZCwgd2hpY2ggYWxzbyBtYWRlIHRoaXMgYXNzdW1wdGlv bi4gUGFydGx5IHByb21wdGVkIGJ5IHRoYXQsIFJpY2hhcmQgU2NoZWZmZW5lZ2dlciB0cmllZCB0 byBnZXQgcGVvcGxlIGludGVyZXN0ZWQNCiBpbiBzdGFuZGFyZGlzaW5nIHVzZSBvZiB0aGUgdGlt ZXN0YW1wIG9wdGlvbiBvbiBhIFNZTiB0byBuZWdvdGlhdGUgc3R1ZmYgbGlrZSB0aW1lciByZXNv bHV0aW9uLiBJIGRvbid0IHRoaW5rIGl0IHdlbnQgYW55d2hlcmUuIERvIHlvdSB0aGluayB3ZSBv dWdodCB0byByZXZpdGFsaXNlIHRoYXQ/IFlvdSBtZW50aW9uIGluZmVyZW5jZSAtIGhhdmUgeW91 IHRyaWVkIHRoYXQgLSBhcmUgdGhlcmUgY2FzZXMgd2hlcmUgaXQgZG9lc24ndCB3b3JrPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltJSl0gWWVzLCBhY3R1YWxseSB3b25kZXJlZCB3 aGF0IGhhcHBlbmVkIHRvIFJpY2hhcmRzIGRyYWZ0LiBJIG9ubHkgYnJpZWZseSB0cmllZCBvdXQg dGhlDQogaW5mZXJlbmNlIGFsZ29yaXRobSB3aXRoIGEgVENQIExFREJBVCBpbXBsZW1lbnRhdGlv biAoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiM5Njk4OTY7YmFja2dyb3VuZDp3aGl0ZSI+PGEgaHJlZj0i aHR0cHM6Ly9naXRodWIuY29tL3NpbHZpb3YvVENQLUxFREJBVC9ibG9iL21hc3Rlci9zcmMvdGNw X2xlZGJhdC5jIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL3NpbHZpb3YvVENQ LUxFREJBVC9ibG9iL21hc3Rlci9zcmMvdGNwX2xlZGJhdC5jPC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPikuDQogSSByZWNh bGwgdGhhdCBpdCB0b29rIGEgd2hpbGUgdG8gY29udmVyZ2UuIEFsc28gSSBhbSBub3Qgc3VyZSBo ZXJlLiBJcyBIeiBpbiBlLmcgYSBsaW51eCBzdGFjayBmaXhlZC4gPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgc28u IEJ1dCBJIGRvbid0IGtub3cgYWJvdXQgZW1iZWRkZWQgc3lzdGVtcyBldGMuPGJyPg0KPGJyPg0K Q2hlZXJzPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQm9iPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxicj4NClRoYXQncyBpdC4gVGhhbmtzIGFnYWlu IGZvciB0aGUgZHJhZnQuIFYgdXNlZnVsLjxicj4NCjxicj4NCjxicj4NCjxicj4NCkJvYjxicj4N Cjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAxNS8xMC8xNSAwNjowOCwgSW5nZW1hciBKb2hhbnNz b24gUw0KPC9zcGFuPndyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SGk8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BIG5ldyBJ RVRGIGRyYWZ0IGlzIHN1Ym1pdHRlZCBpbiByZXNwb25zZSB0byBnZW5lcmFsIGRpc2N1c3Npb24g dGhhdCBmb3IgaW5zdGFuY2UgVENQIEN1YmljIGlzIG5vdCBhbiBhcHByb3ByaWF0ZSBjb25nZXN0 aW9uIGNvbnRyb2wgYWxnb3JpdGhtIGZvciBMVEUuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRo ZSBkcmFmdCBicmllZmx5IG91dGxpbmVzIHR5cGljYWwgNEcgYWNjZXNzIGJlaGF2aW9yIG9uIHRo ZSBQRENQLCBSTEMgYW5kIE1BQyZuYnNwOyBsYXllcnMgdGhhdCBjYW4gaGF2ZSBhbiBpbXBhY3Qg b24gdHJhbnNwb3J0IHByb3RvY29sIHBlcmZvcm1hbmNlLiBUaGUgZHJhZnQgYWxzbyBvdXRsaW5l cyB0d28gcmVsYXRpdmVseSBzaW1wbGUgbW9kaWZpY2F0aW9ucyB0byB0aGUgQ3ViaWMgY29uZ2Vz dGlvbiBjb250cm9sLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPi9JbmdlbWFyJm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286 cD48L3ByZT4NCjxwcmU+RnJvbTogPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4gWzxhIGhy ZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPl0gPG86cD48L286cD48L3ByZT4NCjxwcmU+ U2VudDogZGVuIDE0IG9rdG9iZXIgMjAxNSAyMDoxNzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRv OiBJbmdlbWFyIEpvaGFuc3NvbiBTPG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLTAw LnR4dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLTAwLnR4dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSW5nZW1hciBKb2hhbnNzb24gYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWpvaGFuc3Nvbi1jYy1mb3It NGctNWc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5SZXZpc2lvbjombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMDA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaXRsZTombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29uZ2VzdGlv biBjb250cm9sIGZvciA0RyBhbmQgNUcgYWNjZXNzPG86cD48L286cD48L3ByZT4NCjxwcmU+RG9j dW1lbnQgZGF0ZTombmJzcDsgMjAxNS0xMC0xNDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkdyb3Vw OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJ bmRpdmlkdWFsIFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5QYWdlczombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMTQ8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLTAwLnR4dCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1qb2hhbnNzb24tY2MtZm9yLTRnLTVnLTAwLnR4dDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5TdGF0dXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWpvaGFuc3Nv bi1jYy1mb3ItNGctNWcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtam9oYW5zc29uLWNjLWZvci00Zy01Zy88L2E+PG86cD48L286cD48L3By ZT4NCjxwcmU+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb2hhbnNzb24tY2MtZm9y LTRnLTVnLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWpvaGFuc3Nvbi1jYy1mb3ItNGctNWctMDA8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+QWJzdHJhY3Q6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFRoaXMgbWVt byBvdXRsaW5lcyB0aGUgY2hhbGxlbmdlIHRoYXQgNEcgYW5kIDVHIGFjY2VzcyBicmluZ3MgZm9y PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHRyYW5zcG9ydCBwcm90b2NvbCBj b25nZXN0aW9uIGNvbnRyb2wgYW5kIGFsc28gb3V0bGluZXMgYSBmZXcgc2ltcGxlPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGV4YW1wbGVzIHRoYXQgY2FuIGltcHJvdmUgdHJh bnNwb3J0IHByb3RvY29sIGNvbmdlc3Rpb24gY29udHJvbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBwZXJmb3JtYW5jZSBpbiA0RyBhbmQgNUcgYWNjZXNzLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9m IG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dG9vbHMuaWV0Zi5vcmc8L2E+LjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBJRVRGIFNlY3JldGFy aWF0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 cHJlPi0tIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5Cb2IgQnJpc2NvZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vYm9iYnJpc2NvZS5uZXQv IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2JvYmJyaXNjb2UubmV0LzwvYT48bzpwPjwvbzpwPjwv cHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPHByZT4tLSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3ByZT4NCjxwcmU+Qm9iIEJyaXNjb2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDov L2JvYmJyaXNjb2UubmV0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9ib2JicmlzY29lLm5ldC88 L2E+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnRjcG0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOnRjcG1AaWV0Zi5vcmciPnRjcG1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_81564C0D7D4D2A4B9A86C8C7404A13DA34EB59DEESESSMB205erics_-- From nobody Wed Nov 11 07:08:48 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1CF1AD0A5 for ; Wed, 11 Nov 2015 07:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.055 X-Spam-Level: ** X-Spam-Status: No, score=2.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FRT_FUCK2=3.434, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfCaGW7rtxrY for ; Wed, 11 Nov 2015 07:08:44 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48FF1AD2D9 for ; Wed, 11 Nov 2015 07:08:42 -0800 (PST) Received: by ioc74 with SMTP id 74so35982655ioc.2 for ; Wed, 11 Nov 2015 07:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=LACuJMWley+PuB54zU1ZKBGAGYSz4fHTUgaXr37WMCI=; b=zpER7Zpda+xcfQJxRlN0yuQCliejH3/sEPomXOvoM02C1gc6IhfnI1rt+fuUzZrV7D 9T3HEX+38KOjKAJDcoNp+KJ/qKQILEv0oxu/WeyPsYCTfUwh7OVYHAGGJ/nA15bAM3A7 qPjz4t5A7CiikC/C7eC4iq+sMqRPGZsCgn7HQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=LACuJMWley+PuB54zU1ZKBGAGYSz4fHTUgaXr37WMCI=; b=UCrWit8NVon371U47+Urx118Q5msjO5pVGbQCpBsC4JF9clChlybiKzXdEIrF4afUv X7rmmsM7NWLXqj8tOv1xIgn4tU4Cjauwj0XMpQgUxAodGcLAa0As4Wnuz8R1w6shyOZq gBgFS6bMy6ALOtJSvK8httv0nAg1mxur2Gl7nn/G9S1PpCHWULZ+z97uTBltvTEgg6Hm Fm+3VyDOtVstjE1XmP7ZVrbREsyehj51E3nQYkaAMMpUhEwpd3W72Ya3fOnfXlyzXild bS5f1F/DtH6fRR6EmprYV9oPfGIhx/ovI7jjq9C/aVEjba2Ph+3J14uSaIcXCITQmQLV adTA== X-Gm-Message-State: ALoCoQnv+a4vDsWfd/SttB4y1jJcRpuhGXYn9WKRRrIlePV7KsiE0pKwM1E7oJhuZ764kPQmlZV5kj+xKNLEQO7xVxw0LPREVVGdRnaf2VOC4xvToEtfkcM= X-Received: by 10.107.155.149 with SMTP id d143mr9894221ioe.145.1447254522001; Wed, 11 Nov 2015 07:08:42 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <55C4C4CB.9080302@bobbriscoe.net> <55C4CEEF.1040504@bobbriscoe.net> <338a11745e05dd944c66be76fb925e97@mail.gmail.com> <55D36138.5060106@bobbriscoe.net> <7A2801D5E40DD64A85E38DF22117852C70B38246@wdc1exchmbxp01.hq.corp.viasat.com> <8A5507EB-07A2-46E4-8EA5-E60C1845B131@netapp.com> <7A2801D5E40DD64A85E38DF22117852C70B38ECD@wdc1exchmbxp01.hq.corp.viasat.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQF40EgN6bhQ58jZHJuzoIQYmo33WQFQ1uPnAYj6pYUCUTnvCQH+E/SjAY5t/2UB6vuFHQI/wlQpAn/BOmeezHAJIA== Date: Wed, 11 Nov 2015 16:08:39 +0100 Message-ID: <814ca62506a894c067efd7161e46d0ee@mail.gmail.com> To: Yuchung Cheng , "Eggert, Lars" , "Zimmermann, Alexander" , Jana Iyengar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-DomainID: tieto.com Archived-At: Cc: tcpm IETF list Subject: Re: [tcpm] Cubic (was Re: New I-D: draft-briscoe-aqm-dualq-coupled-00.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 11 Nov 2015 15:08:46 -0000 HI, I (also) was a bit surprised by the CUBIC fault presented in tcpm as I would have assumed that CUBIC would be implemented in the framework of RFC5681 for how to handle idle situations and also possibly in the framework of RFC7661/2861 (or this mechanism in which ever from it takes in Linux). Anyway I think that it would be great and best if the CUBIC paper would describe a CUBIC solution following these principles, but then I also see that we might derivate from existing implementations, so that is of course an issue (Though see below on pacing). In terms of how to handle CUBIC after idle situation or other where the CUBIC algorithm need to be re-calibrated, then I wonder if the situation is so simply that one would re-calibrate the CUBIC W(t) formula so that t=3D0 corresponds to re-start of transmission an= d K is adjusted so That W(0) gives the present CWND (whatever it has been left at now) - just a na=C4=ABve thought ? Perhaps you have already designed a different solution ? Something else - more general: * at the tcpm session, Lars mentioned that also Hystart should be described in this document. Is that correctly understood ? Personally I think that sounds very good. * Pacing has been recognized as a necessity and I believe even more a necessity when running CUBIC than New Reno, as CUBIC CWND increase at large RTTs may clock out large bursts. Is it valid to describe CUBIC CC (as implemented in Linux) without describing pacing ? Thanks. BR, Karen > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Yuchung Cheng > Sent: 29. september 2015 01:28 > To: Agarwal, Anil > Cc: Jana Iyengar ; tcpm IETF list > Subject: Re: [tcpm] Cubic (was Re: New I-D: draft-briscoe-aqm-dualq- > coupled-00.txt) > > On Mon, Sep 28, 2015 at 3:35 PM, Agarwal, Anil > wrote: > > Yuchung, > > > > You wrote - > > "If the TCP implementation follows RFC 5681 or RFC 2861 to reduce cwnd > after idle, the issue is masqueraded". > > > > Would it be more appropriate to state that - If the TCP implementation > > follows RFC 5681 or RFC 2861 to reduce cwnd after idle, the TCP slow-start > cwnd increase algorithm should get used, not CUBIC. > That'd be fine w/ me if the draft considers Cubic is only effective when cwnd > >=3D ssthresh. > > Jana would present the troubleshooting and results in the next mtg. > the bug was initially discovered in QUIC (which uses Cubic). > > > > > Thanks, > > Anil > > > > P.S. Sorry about the confusion created by not editing the subject line > > correctly > > > > > > -----Original Message----- > > From: Yuchung Cheng [mailto:ycheng@google.com] > > Sent: Monday, September 28, 2015 4:23 PM > > To: Eggert, Lars > > Cc: Agarwal, Anil; tcpm IETF list; Zimmermann, Alexander > > Subject: Re: [tcpm] Cubic (was Re: New I-D: > > draft-briscoe-aqm-dualq-coupled-00.txt) > > > > On Mon, Sep 28, 2015 at 6:34 AM, Eggert, Lars wrote: > >> > >> Hi, > >> > >> On 2015-09-28, at 15:28, Agarwal, Anil wrote: > >> > > >> > Question - where is the CUBIC specification documented? How will it be > updated? Is there an RFC on CUBIC? > >> > >> there is https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtcpm- > 2Dcubic_&d=3DBQIBaQ&c=3Djcv3orpCsv7C4ly8- > ubDob57ycZ4jvhoYZNDBA06fPk&r=3DFyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSh > eSGz1Jvq4&m=3DgpOIxBF_PNjCo7ij5xixz0eqOB- > Xt_ddmiwbeQmW7lI&s=3Db18CZjGX71Lsmel9s4E-8R8aFY1- > 71uvwem3J6QnMOg&e=3D . The goal was that this would document the Cubic > code currently implemented by Linux. > >> > >> This has been a slow effort, and it's getting slower since both > >> Richard and Alex probably won't have cycles in the foreseeable future > >> to work on this. So I think we're looking for someone else to take > >> over the pen (hi, Yuchung & Google folks :-) > >> > > Sorry I won't be able to help co-authoring the draft. But the fix is not that > complicated. A new subsection on section 3 should suffice. > > Something like: > > > > 3.x Dealing with application idle > > > > Cubic determines how fast to grow the window based on how long ago the > last loss event was. An oversight in the original design is that idling periods > can make Cubic arbitrarily aggressive: after an idle period, the delta of (t - k) > as well as the slope of cwnd increase become arbitrarily large in Section 3.1. > In some implementation (e.g., Linux) the maximum increase is capped to be > as fast as slow start. > > > > If the TCP implementation follows RFC 5681 or RFC 2861 to reduce cwnd > after idle, the issue is masqueraded. But if the TCP implementation does not > reduce cwnd after idle (i.e., RFC2861 or RFC5681), Cubic will slow start > without a reduced cwnd and likely to induce losses quickly. > > > > To address this issue Cubic algorithm SHOULD offset the (t - k) in Section 3.1 > by the amount of idle time. One approach (e.g., Linux) is to record the send > time of the last packet, and calculate the idle time when the amount of > inflight becomes positive again when sending the next packet after idle. > > > > > > These are the Linux patches for reference. > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__patchwork.ozlabs. > > org_patch_518918_&d=3DBQIBaQ&c=3Djcv3orpCsv7C4ly8- > ubDob57ycZ4jvhoYZNDBA06f > > > Pk&r=3DFyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=3DgpOIxBF_PNj > Co7ij5xi > > xz0eqOB-Xt_ddmiwbeQmW7lI&s=3D- > 40xAglDVsZhZJ3Cd5PncmRKZue4vz4V5sA3iTqYafo > > &e=3D > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__patchwork.ozlabs. > > org_patch_516122_&d=3DBQIBaQ&c=3Djcv3orpCsv7C4ly8- > ubDob57ycZ4jvhoYZNDBA06f > > > Pk&r=3DFyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=3DgpOIxBF_PNj > Co7ij5xi > > xz0eqOB-Xt_ddmiwbeQmW7lI&s=3DaA3H-aoHtcUBnfA- > 7s85Nu4oxArwhmM2N8tT1fV9uy0 > > &e=3D > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__patchwork.ozlabs. > > org_patch_516123_&d=3DBQIBaQ&c=3Djcv3orpCsv7C4ly8- > ubDob57ycZ4jvhoYZNDBA06f > > > Pk&r=3DFyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=3DgpOIxBF_PNj > Co7ij5xi > > xz0eqOB-Xt_ddmiwbeQmW7lI&s=3DM-8Jum- > _SDW0fVKKsSHmUto0Cw3DajRYRhxo0cdjOYw > > &e=3D > > > > HTH > > > > > >> Lars > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mai > >> l > >> man_listinfo_tcpm&d=3DBQIBaQ&c=3Djcv3orpCsv7C4ly8- > ubDob57ycZ4jvhoYZNDBA06 > >> f > >> > Pk&r=3DFyvaklKYrHaSCPjbBTdviWIW9uSbnxdNSheSGz1Jvq4&m=3DgpOIxBF_PNj > Co7ij5x > >> i > >> xz0eqOB- > Xt_ddmiwbeQmW7lI&s=3DFbVX6NYOKMRF5mIg0Z5WW4mBHmMudm1VvExLt > mTkfp > >> c > >> &e=3D > >> > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Nov 12 12:31:49 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0ED1B3528 for ; Thu, 12 Nov 2015 12:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1Dh89m0Cw7j for ; Thu, 12 Nov 2015 12:31:47 -0800 (PST) Received: from atl4mhob09.myregisteredsite.com (atl4mhob09.myregisteredsite.com [209.17.115.47]) by ietfa.amsl.com (Postfix) with ESMTP id D35701B3527 for ; Thu, 12 Nov 2015 12:31:46 -0800 (PST) Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob09.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id tACKVjkA023227 for ; Thu, 12 Nov 2015 15:31:45 -0500 Received: (qmail 6089 invoked by uid 0); 12 Nov 2015 20:31:45 -0000 X-TCPREMOTEIP: 24.166.126.82 X-Authenticated-UID: wes@mti-systems.com Received: from unknown (HELO ?192.168.0.137?) (wes@mti-systems.com@24.166.126.82) by 0 with ESMTPA; 12 Nov 2015 20:31:45 -0000 From: Wesley Eddy To: tcpm@ietf.org Message-ID: <5644F72D.4040104@mti-systems.com> Date: Thu, 12 Nov 2015 15:31:41 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tcpm] TCP API in 793 / 793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 12 Nov 2015 20:31:48 -0000 I checked out the Yokohama meeting minutes and recording (sorry I missed it in person!). We need to follow-up on the discussion of what to do (or not do) about the TCP API in RFC 793bis. I know Karen had interest in what will happen to this, for one. As I see it, the issue raised on the TAPS list earlier is that the TCP API in 793 dates from 1981 and hasn't been updated significantly since then. It is an abstract API, whereas operating systems implement concrete APIs based on sockets, primarily, and that have diverged from the description in 793 (and currently 793bis). I think our options are: 1. Leave it alone, modulo any corrections from errata, other RFCs, etc. 2. Take it out 3. Change it in more significant ways I don't think option 3 is somewhere we should go. I think that should be a separate effort, if there is desire to do that. My inclination is for option 1. It will be good to hear what others think, and understand the consensus on this though. From nobody Thu Nov 12 13:05:11 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4271B35E7 for ; Thu, 12 Nov 2015 13:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPZ1L9dKfktz for ; Thu, 12 Nov 2015 13:05:06 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0C41B35E5 for ; Thu, 12 Nov 2015 13:05:06 -0800 (PST) Received: by oiww189 with SMTP id w189so40298372oiw.3 for ; Thu, 12 Nov 2015 13:05:05 -0800 (PST) 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; bh=TcDFsaqLqzutVYCR/Xbjl/YZm7gcJDKY7A84z2Rr460=; b=m3DorrLOEhlN52hbHVFiBKwCMVv37sNX0RTJBhOv2evivIiuhyVwE2+Zrxm8GBcE8o zqE6c6tordAxURgnRMROfs9005DU9UT/4MPMMp8VT0p6b/3CqHojR+0i1Tj6BYh3bcor 2NhJM4pRT5F4JoBZQjvgJO59EYaAoEobcGAQc6zEBwVSIDvENycePADnj9wytH4y2IMt fyb8YUo0DkLQmg25U/EgzbMxxjLtmChomh0sn24cko0oV0BtxaSj+cyyjZZlVo/yHOoh jdmPAKrbm7V0toMRM37zR0YpvMZtwiHNPz6dASv5fDG81d28DDYssgN1rBqrQFY5PHhZ trhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TcDFsaqLqzutVYCR/Xbjl/YZm7gcJDKY7A84z2Rr460=; b=G7v6w4Zm6hCuJPVhANUo+ApngyazXJYqqkU4zceCViPxYldbEvcXTV0pwt+krG+Ccd vYKakcb0zRaGn7Gqa5z8nfMaa2xu+kXq3gdPsDG7txxulKHVk6sxV/s1vShU6OKWyikS Li4je5a7hqdWJmzMAgWmikc6B3seVLn4QJ8pVUREow7wDfcTTqxlExAqTGRnebLV9OUP Ca8DAHHtgp47W5a/iJ61moWMms1GUE8uWBx3YzWq1kAXwg/6XOXLNNO3v5npk11VXbBY KuqT0YFdnygiIrri0XV3s/faDiuywz3iT21pD2Jk/H0ghLw43sNwPhKVN2a9vOrvpT5H tWGg== X-Gm-Message-State: ALoCoQkPfsmwGHpWYOoa2dGwvJgYzELCKEz/+hh/1VDRZCFdDM42bu5p6GA154ubSZLyG52yl6gr MIME-Version: 1.0 X-Received: by 10.202.73.214 with SMTP id w205mr9923263oia.91.1447362305413; Thu, 12 Nov 2015 13:05:05 -0800 (PST) Received: by 10.76.144.165 with HTTP; Thu, 12 Nov 2015 13:05:05 -0800 (PST) In-Reply-To: <5644F72D.4040104@mti-systems.com> References: <5644F72D.4040104@mti-systems.com> Date: Thu, 12 Nov 2015 13:05:05 -0800 Message-ID: From: Jana Iyengar To: Wesley Eddy Content-Type: multipart/alternative; boundary=001a113dae8c13888705245e4cf1 Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP API in 793 / 793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 12 Nov 2015 21:05:09 -0000 --001a113dae8c13888705245e4cf1 Content-Type: text/plain; charset=UTF-8 I think option 1 makes sense. I wouldn't be opposed strongly to option 2, but the doc seems clear on the "advisory" nature of this API. On Thu, Nov 12, 2015 at 12:31 PM, Wesley Eddy wrote: > I checked out the Yokohama meeting minutes and recording (sorry I missed > it in person!). > > We need to follow-up on the discussion of what to do (or not do) about the > TCP API in RFC 793bis. I know Karen had interest in what will happen to > this, for one. > > As I see it, the issue raised on the TAPS list earlier is that the TCP API > in 793 dates from 1981 and hasn't been updated significantly since then. > It is an abstract API, whereas operating systems implement concrete APIs > based on sockets, primarily, and that have diverged from the description in > 793 (and currently 793bis). > > I think our options are: > 1. Leave it alone, modulo any corrections from errata, other RFCs, etc. > 2. Take it out > 3. Change it in more significant ways > > I don't think option 3 is somewhere we should go. I think that should be > a separate effort, if there is desire to do that. My inclination is for > option 1. > > It will be good to hear what others think, and understand the consensus on > this though. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --001a113dae8c13888705245e4cf1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think option 1 makes sense. I wouldn't be opposed st= rongly to option 2, but the doc seems clear on the "advisory" nat= ure of this API.

On Thu, Nov 12, 2015 at 12:31 PM, Wesley Eddy <wes@mti-systems.com<= /a>> wrote:
I checked out the Y= okohama meeting minutes and recording (sorry I missed it in person!).

We need to follow-up on the discussion of what to do (or not do) about the = TCP API in RFC 793bis.=C2=A0 I know Karen had interest in what will happen = to this, for one.

As I see it, the issue raised on the TAPS list earlier is that the TCP API = in 793 dates from 1981 and hasn't been updated significantly since then= .=C2=A0 It is an abstract API, whereas operating systems implement concrete= APIs based on sockets, primarily, and that have diverged from the descript= ion in 793 (and currently 793bis).

I think our options are:
1. Leave it alone, modulo any corrections from errata, other RFCs, etc.
2. Take it out
3. Change it in more significant ways

I don't think option 3 is somewhere we should go.=C2=A0 I think that sh= ould be a separate effort, if there is desire to do that.=C2=A0 My inclinat= ion is for option 1.

It will be good to hear what others think, and understand the consensus on = this though.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--001a113dae8c13888705245e4cf1-- From nobody Thu Nov 12 13:41:00 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E6A1B36C6 for ; Thu, 12 Nov 2015 13:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwoF1oXlA4FB for ; Thu, 12 Nov 2015 13:40:56 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B171B35D4 for ; Thu, 12 Nov 2015 13:40:56 -0800 (PST) Received: from [10.123.88.207] (usc-secure-wireless-088-207.usc.edu [68.181.88.207]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tACLeSnr023906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 12 Nov 2015 13:40:33 -0800 (PST) To: Wesley Eddy , tcpm@ietf.org References: <5644F72D.4040104@mti-systems.com> From: Joe Touch Message-ID: <5645074B.40803@isi.edu> Date: Thu, 12 Nov 2015 13:40:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5644F72D.4040104@mti-systems.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] TCP API in 793 / 793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 12 Nov 2015 21:40:58 -0000 Option 1. A protocol without an (abstract) API isn't a protocol. I don't think there's a lot that needs to change to support the requirements of 793-bis. Joe On 11/12/2015 12:31 PM, Wesley Eddy wrote: > I checked out the Yokohama meeting minutes and recording (sorry I missed > it in person!). > > We need to follow-up on the discussion of what to do (or not do) about > the TCP API in RFC 793bis. I know Karen had interest in what will > happen to this, for one. > > As I see it, the issue raised on the TAPS list earlier is that the TCP > API in 793 dates from 1981 and hasn't been updated significantly since > then. It is an abstract API, whereas operating systems implement > concrete APIs based on sockets, primarily, and that have diverged from > the description in 793 (and currently 793bis). > > I think our options are: > 1. Leave it alone, modulo any corrections from errata, other RFCs, etc. > 2. Take it out > 3. Change it in more significant ways > > I don't think option 3 is somewhere we should go. I think that should > be a separate effort, if there is desire to do that. My inclination is > for option 1. > > It will be good to hear what others think, and understand the consensus > on this though. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Nov 12 13:43:36 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66851B373E for ; Thu, 12 Nov 2015 13:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOchFKLCcQs2 for ; Thu, 12 Nov 2015 13:43:33 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBAA1B3729 for ; Thu, 12 Nov 2015 13:43:33 -0800 (PST) Received: by pabfh17 with SMTP id fh17so76986440pab.0 for ; Thu, 12 Nov 2015 13:43:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=5RFHiU/LqJcjSd4TGyIzAUJDv2LumubJ7fnxqUNx/1s=; b=hTb0tfKJPgVZTw1kq2T/0fqYYi/yHZc3GoXaS6M8Zr9kA7eZ0qEsYAwL19GTmtOSEE SHldjBhDlyC+UrUBxJv4SKwWqMdlDaiS3H77bjGz4bRPIPkcw3Ro7RkUGOkZQ5Ypa9ZS saVCsLoCp4BttmfbZGhXeJ2GdAMrJXSHtmkBuQGDA3wNGBT+/EQjcZEQ/l5iRckhzKK3 ZMnUud8DEE2YJoAvTqcPUwEEzoEECwAKzg3SdACQo8CfbKcSgK1fFB2ZG/yzxXPOEEhT 5I+QkQEsufBddibVCJ7XoFeR4KLmDFxqqzSHPlZ04bZyCs5CG0XG8OVjaMGIS5MPgWK4 rrXg== X-Received: by 10.66.150.37 with SMTP id uf5mr26978951pab.30.1447364612968; Thu, 12 Nov 2015 13:43:32 -0800 (PST) Received: from twicinski-ltm.internal.salesforce.com ([204.14.239.13]) by smtp.googlemail.com with ESMTPSA id ux3sm16529973pac.18.2015.11.12.13.43.31 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 12 Nov 2015 13:43:32 -0800 (PST) To: tcpm@ietf.org References: <5644F72D.4040104@mti-systems.com> From: Tim Wicinski Message-ID: <56450802.8070507@gmail.com> Date: Thu, 12 Nov 2015 13:43:30 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5644F72D.4040104@mti-systems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] TCP API in 793 / 793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 12 Nov 2015 21:43:35 -0000 Another vote for Option 1. On 11/12/15 12:31 PM, Wesley Eddy wrote: > I checked out the Yokohama meeting minutes and recording (sorry I missed > it in person!). > > We need to follow-up on the discussion of what to do (or not do) about > the TCP API in RFC 793bis. I know Karen had interest in what will > happen to this, for one. > > As I see it, the issue raised on the TAPS list earlier is that the TCP > API in 793 dates from 1981 and hasn't been updated significantly since > then. It is an abstract API, whereas operating systems implement > concrete APIs based on sockets, primarily, and that have diverged from > the description in 793 (and currently 793bis). > > I think our options are: > 1. Leave it alone, modulo any corrections from errata, other RFCs, etc. > 2. Take it out > 3. Change it in more significant ways > > I don't think option 3 is somewhere we should go. I think that should > be a separate effort, if there is desire to do that. My inclination is > for option 1. > > It will be good to hear what others think, and understand the consensus > on this though. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Nov 12 14:30:14 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2291A8A7B for ; Thu, 12 Nov 2015 14:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdybwPaFw6GB for ; Thu, 12 Nov 2015 14:30:11 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383FA1A8A79 for ; Thu, 12 Nov 2015 14:30:11 -0800 (PST) Received: by ykfs79 with SMTP id s79so118212871ykf.1 for ; Thu, 12 Nov 2015 14:30:10 -0800 (PST) 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; bh=iRO8OSVUXDwx0kNVDOSPomBo8/4ARZ72crk4kwJFpcw=; b=hbDTFzey69HqtxRR2ualz8L3tI7e6wHqRbhJkZ6MpUBuU8EjBNu5em03bHHGLWPdQH PQ27Qg8ZmOs+wgCYUDgKRvG24ZruBeu4np4L2iaqd+10teB7EkKbqP5oiNCAZFkdIBi8 5CmyjFYmj7/9A6DMTRPbLypY1D1QPmVG/8w6uG8rzIKZWwZEHcWGJ/Xe2rUHbVjOBzYM QQeD97/wh4qmWBWqBwbYljf3gj/A158TCQKVV8atEKN0g8iY1sdQecmuNXu/mwpRqt+j 3ZhUX0uNR0UfyIHfLnoFqnvf/okLLMes5BRYiYnoyjRAaBKVpKdBg7iOPw0dxI4AP7Ht 7+Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iRO8OSVUXDwx0kNVDOSPomBo8/4ARZ72crk4kwJFpcw=; b=BBP6CPCWZKGesnhXDaawVYp+31EXxIWgCtZd3SNx6ZHqt54Mc5pBjhMO03sfyV1I3h ocvsV8SSGtkNIV9IW5V6OVmmig5veLzK8sZjBz6uj9XOrwn3DsLJP6O4mnLDb3xiouNz RjfuWDA+avRFceW70SvrVwuqVonRglNU0LCPiUWBkYeYnPeSG2RToIatcIj4Udoa8qTp fVvUUpJEBvLEhC66ua1yYq9m0qruGCDMyDoSuku7ccneTvTiv7QvDxolmjJauBBFK+C6 IlZndLGCLmkDTpZMMz1PDoUZ+sIGYIG1lmoLOTZcmI86dqSsiSK/guEgbjiTTPzZVPvV +vnA== X-Gm-Message-State: ALoCoQmfCgWA6QdbhREEJnrW0w9DbbCVucVBQ28Z4wlXC/E8j/owwrpzOD6LiMAsP/d2t821k398 MIME-Version: 1.0 X-Received: by 10.13.252.196 with SMTP id m187mr17864243ywf.136.1447367410082; Thu, 12 Nov 2015 14:30:10 -0800 (PST) Received: by 10.31.189.19 with HTTP; Thu, 12 Nov 2015 14:30:09 -0800 (PST) Received: by 10.31.189.19 with HTTP; Thu, 12 Nov 2015 14:30:09 -0800 (PST) In-Reply-To: <56450802.8070507@gmail.com> References: <5644F72D.4040104@mti-systems.com> <56450802.8070507@gmail.com> Date: Thu, 12 Nov 2015 14:30:09 -0800 Message-ID: From: Yuchung Cheng To: Tim Wicinski Content-Type: multipart/alternative; boundary=94eb2c064ab456a25405245f7c36 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] TCP API in 793 / 793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 12 Nov 2015 22:30:12 -0000 --94eb2c064ab456a25405245f7c36 Content-Type: text/plain; charset=UTF-8 Opt 1 vote On Nov 12, 2015 1:43 PM, "Tim Wicinski" wrote: > > Another vote for Option 1. > > On 11/12/15 12:31 PM, Wesley Eddy wrote: > >> I checked out the Yokohama meeting minutes and recording (sorry I missed >> it in person!). >> >> We need to follow-up on the discussion of what to do (or not do) about >> the TCP API in RFC 793bis. I know Karen had interest in what will >> happen to this, for one. >> >> As I see it, the issue raised on the TAPS list earlier is that the TCP >> API in 793 dates from 1981 and hasn't been updated significantly since >> then. It is an abstract API, whereas operating systems implement >> concrete APIs based on sockets, primarily, and that have diverged from >> the description in 793 (and currently 793bis). >> >> I think our options are: >> 1. Leave it alone, modulo any corrections from errata, other RFCs, etc. >> 2. Take it out >> 3. Change it in more significant ways >> >> I don't think option 3 is somewhere we should go. I think that should >> be a separate effort, if there is desire to do that. My inclination is >> for option 1. >> >> It will be good to hear what others think, and understand the consensus >> on this though. >> >> _______________________________________________ >> 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 > --94eb2c064ab456a25405245f7c36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Opt 1 vote

On Nov 12, 2015 1:43 PM, "Tim Wicinski"= ; <tjw.ietf@gmail.com> wrot= e:

Another vote for Option 1.

On 11/12/15 12:31 PM, Wesley Eddy wrote:
I checked out the Yokohama meeting minutes and recording (sorry I missed it in person!).

We need to follow-up on the discussion of what to do (or not do) about
the TCP API in RFC 793bis.=C2=A0 I know Karen had interest in what will
happen to this, for one.

As I see it, the issue raised on the TAPS list earlier is that the TCP
API in 793 dates from 1981 and hasn't been updated significantly since<= br> then.=C2=A0 It is an abstract API, whereas operating systems implement
concrete APIs based on sockets, primarily, and that have diverged from
the description in 793 (and currently 793bis).

I think our options are:
1. Leave it alone, modulo any corrections from errata, other RFCs, etc.
2. Take it out
3. Change it in more significant ways

I don't think option 3 is somewhere we should go.=C2=A0 I think that sh= ould
be a separate effort, if there is desire to do that.=C2=A0 My inclination i= s
for option 1.

It will be good to hear what others think, and understand the consensus
on this though.

_______________________________________________
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
--94eb2c064ab456a25405245f7c36-- From nobody Thu Nov 12 21:49:53 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52D61B4072 for ; Thu, 12 Nov 2015 21:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRXA6_eK1m9K for ; Thu, 12 Nov 2015 21:49:48 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCC91B4071 for ; Thu, 12 Nov 2015 21:49:47 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Zx7F3-00016G-9U for tcpm@ietf.org; Fri, 13 Nov 2015 06:49:45 +0100 Received: from 180.168.202.84.customer.cdi.no ([84.202.168.180] helo=[192.168.0.101]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1Zx7F2-0001Bq-Bv for tcpm@ietf.org; Fri, 13 Nov 2015 06:49:45 +0100 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_63217E5A-166C-4700-97CF-BAE0CEE78A1D" Message-Id: <3ABAA8DB-367C-47DD-B7F0-58BEB2E5297B@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Fri, 13 Nov 2015 06:49:51 +0100 References: <5644F72D.4040104@mti-systems.com> <56450802.8070507@gmail.com> To: "tcpm@ietf.org Extensions" In-Reply-To: X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 5 sum msgs/h 1 total rcpts 35157 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 70FE67F65D08771AF16AD75B731D112E5C4130F1 X-UiO-SPAM-Test: remote_host: 84.202.168.180 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3 max/h 1 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tcpm] TCP API in 793 / 793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Nov 2015 05:49:51 -0000 --Apple-Mail=_63217E5A-166C-4700-97CF-BAE0CEE78A1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 for opt 1 > On 12. nov. 2015, at 23.30, Yuchung Cheng wrote: >=20 > Opt 1 vote >=20 > On Nov 12, 2015 1:43 PM, "Tim Wicinski" > wrote: >=20 > Another vote for Option 1. >=20 > On 11/12/15 12:31 PM, Wesley Eddy wrote: > I checked out the Yokohama meeting minutes and recording (sorry I = missed > it in person!). >=20 > We need to follow-up on the discussion of what to do (or not do) about > the TCP API in RFC 793bis. I know Karen had interest in what will > happen to this, for one. >=20 > As I see it, the issue raised on the TAPS list earlier is that the TCP > API in 793 dates from 1981 and hasn't been updated significantly since > then. It is an abstract API, whereas operating systems implement > concrete APIs based on sockets, primarily, and that have diverged from > the description in 793 (and currently 793bis). >=20 > I think our options are: > 1. Leave it alone, modulo any corrections from errata, other RFCs, = etc. > 2. Take it out > 3. Change it in more significant ways >=20 > I don't think option 3 is somewhere we should go. I think that should > be a separate effort, if there is desire to do that. My inclination = is > for option 1. >=20 > It will be good to hear what others think, and understand the = consensus > on this though. >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm = >=20 > _______________________________________________ > 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 --Apple-Mail=_63217E5A-166C-4700-97CF-BAE0CEE78A1D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii +1 for opt 1

On 12. nov. 2015, at 23.30, Yuchung Cheng <ycheng@google.com> wrote:

Opt 1 vote

On Nov 12, 2015 1:43 PM, "Tim Wicinski" <tjw.ietf@gmail.com> wrote:

Another vote for Option 1.

On 11/12/15 12:31 PM, Wesley Eddy wrote:
I checked out the Yokohama meeting minutes and recording (sorry I missed
it in person!).

We need to follow-up on the discussion of what to do (or not do) about
the TCP API in RFC 793bis.  I know Karen had interest in what will
happen to this, for one.

As I see it, the issue raised on the TAPS list earlier is that the TCP
API in 793 dates from 1981 and hasn't been updated significantly since
then.  It is an abstract API, whereas operating systems implement
concrete APIs based on sockets, primarily, and that have diverged from
the description in 793 (and currently 793bis).

I think our options are:
1. Leave it alone, modulo any corrections from errata, other RFCs, etc.
2. Take it out
3. Change it in more significant ways

I don't think option 3 is somewhere we should go.  I think that should
be a separate effort, if there is desire to do that.  My inclination is
for option 1.

It will be good to hear what others think, and understand the consensus
on this though.

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

--Apple-Mail=_63217E5A-166C-4700-97CF-BAE0CEE78A1D-- From nobody Fri Nov 13 00:28:15 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDC51A1A93 for ; Fri, 13 Nov 2015 00:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uShXI5ZQXZ84 for ; Fri, 13 Nov 2015 00:28:12 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7690E1A1A86 for ; Fri, 13 Nov 2015 00:28:12 -0800 (PST) Received: by igcph11 with SMTP id ph11so11159381igc.1 for ; Fri, 13 Nov 2015 00:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=rQADU7qVnYymd65sTLn2sscCDI5onpEYQeWwKBD5BDM=; b=mdmYuzMwFg1ojPquZZ0guCFLNdwJTyoRuOUUtdAwGUi9LP+qxPIlpyMcx7eeEjVOOi aVys6pEDJJZ0s4z+zMC8M/J1uht0TciRhPHoJHIOUKE2QyW5eLjy/L/ecRwplo3cYXCP 2kd/auOiXfGV5TOwFg5SxWfkwDEiI0ty08Rmc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=rQADU7qVnYymd65sTLn2sscCDI5onpEYQeWwKBD5BDM=; b=dcUVI3W9uIIjR5oZx9Xj2Opu+hj5WhR1t/O+TYv2/FpDUoxehesV3gkzHDPuf3DHsm g+bHL37AyHP6iQgsMR6uk7Hx0dw7i/o5TS10DzS2e1rcDAmLJnRY4RV4T5FiS3X0uE99 qDELkarSW6X+avMRdtp6rKP0krTtAW8ap2ikLJ3jos3p1dshWx/ZZPENXFb7uLAjOrQp h75W27VDtJifWDvM5hsGsxWaX2KfQ3aMXWKHNEqUUPoZuR8aBxURZpbdqabQpMmypoCD CL6ZuXzRHDnrJLYgWyp5/3XecgxyHZa1/RDsiPE4ZZsHKaRV/QRaDX21Fh5ICgAKaQZl JexQ== X-Gm-Message-State: ALoCoQnP4jeKPr94I102H0fVTdSzbIxAm3ieT9d79S32qCi94wFftb/i6Fx9bUkGf0Dr3x3ZqBzOhNV1Z2tqDluqMv93YCesG91IXJ1JODrgMkMiLUzZJPI= X-Received: by 10.50.182.7 with SMTP id ea7mr2185676igc.2.1447403291889; Fri, 13 Nov 2015 00:28:11 -0800 (PST) From: Karen Elisabeth Egede Nielsen References: <5644F72D.4040104@mti-systems.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFtPRo3Dlo9sRCvDt8o011Wr/il+QD/25uFn1leNAA= Date: Fri, 13 Nov 2015 09:28:10 +0100 Message-ID: <997cf20817e108869a6335ebc96510ab@mail.gmail.com> To: Wesley Eddy Content-Type: multipart/alternative; boundary=001a1136b07a0f74d0052467d7cf X-DomainID: tieto.com Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] TCP API in 793 / 793bis X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 13 Nov 2015 08:28:15 -0000 --001a1136b07a0f74d0052467d7cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with option 1 as well as. I am a little curious as to what the =E2=80=9Cetc.=E2=80=9D might end up in= cluding. But let us see. I agree with option 1 instead of option 3 from the perspective of achieving something good and valuable with reasonable effort. We often deal with people referring back to RFC793 API and having what is in there be correct is important. That it is not comprehensive is more acceptable. BR, Karen *From:* tcpm [mailto:tcpm-bounces@ietf.org] *On Behalf Of *Jana Iyengar *Sent:* 12. november 2015 22:05 *To:* Wesley Eddy *Cc:* tcpm@ietf.org *Subject:* Re: [tcpm] TCP API in 793 / 793bis I think option 1 makes sense. I wouldn't be opposed strongly to option 2, but the doc seems clear on the "advisory" nature of this API. On Thu, Nov 12, 2015 at 12:31 PM, Wesley Eddy wrote: I checked out the Yokohama meeting minutes and recording (sorry I missed it in person!). We need to follow-up on the discussion of what to do (or not do) about the TCP API in RFC 793bis. I know Karen had interest in what will happen to this, for one. As I see it, the issue raised on the TAPS list earlier is that the TCP API in 793 dates from 1981 and hasn't been updated significantly since then. It is an abstract API, whereas operating systems implement concrete APIs based on sockets, primarily, and that have diverged from the description in 793 (and currently 793bis). I think our options are: 1. Leave it alone, modulo any corrections from errata, other RFCs, etc. 2. Take it out 3. Change it in more significant ways I don't think option 3 is somewhere we should go. I think that should be a separate effort, if there is desire to do that. My inclination is for option 1. It will be good to hear what others think, and understand the consensus on this though. _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm --001a1136b07a0f74d0052467d7cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I = agree with option 1 as well as.

I am a little curious as to what the =E2=80=9Cetc.=E2= =80=9D might end up including.

But let us see.

=C2=A0

I agree with option 1 instead of option 3 from the pers= pective of

= achieving something good and valuable with reasonable effort.

=C2=A0

We often deal with people refe= rring back to RFC793 API and

having what is in there be correct is important.=

That it is not com= prehensive is more acceptable.

=C2=A0

BR, Karen

=C2=A0

<= b>From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: 12. november 2015 22:05
To: Wesley= Eddy <wes@mti-systems.com>= ;
Cc: tcpm@ietf.org
Su= bject: Re: [tcpm] TCP API in 793 / 793bis

=C2=A0

I think option 1 make= s sense. I wouldn't be opposed strongly to option 2, but the doc seems = clear on the "advisory" nature of this API.

=C2=A0

On Thu, Nov 12, 2015 = at 12:31 PM, Wesley Eddy <wes@mti-systems.com> wrote:

I checked out the Yokoham= a meeting minutes and recording (sorry I missed it in person!).

We n= eed to follow-up on the discussion of what to do (or not do) about the TCP = API in RFC 793bis.=C2=A0 I know Karen had interest in what will happen to t= his, for one.

As I see it, the issue raised on the TAPS list earlier= is that the TCP API in 793 dates from 1981 and hasn't been updated sig= nificantly since then.=C2=A0 It is an abstract API, whereas operating syste= ms implement concrete APIs based on sockets, primarily, and that have diver= ged from the description in 793 (and currently 793bis).

I think our = options are:
1. Leave it alone, modulo any corrections from errata, othe= r RFCs, etc.
2. Take it out
3. Change it in more significant ways
=
I don't think option 3 is somewhere we should go.=C2=A0 I think tha= t should be a separate effort, if there is desire to do that.=C2=A0 My incl= ination is for option 1.

It will be good to hear what others think, = and understand the consensus on this though.

_______________________= ________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/li= stinfo/tcpm

=C2=A0

--001a1136b07a0f74d0052467d7cf-- From nobody Mon Nov 16 12:11:10 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABD11B307B for ; Mon, 16 Nov 2015 12:11:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xB0TW-Qlaz7q for ; Mon, 16 Nov 2015 12:11:06 -0800 (PST) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.234]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB8E1B2E93 for ; Mon, 16 Nov 2015 12:11:05 -0800 (PST) Received: from t40700-la020.lan (80.223.92.46) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as saropa-1) id 5613C7B1011709CD for tcpm@ietf.org; Mon, 16 Nov 2015 22:09:30 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 16 Nov 2015 22:11:03 +0200 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [tcpm] Adoption of More Accurate ECN Feedback in TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 16 Nov 2015 20:11:08 -0000 Hi, In the Yokohama meeting we discussed adoption of "More Accurate ECN = Feedback in TCP" as Experimental RFC, with = draft-kuehlewind-tcpm-accurate-ecn-05 serving as the baseline for the = working group draft. We called a hum in the meeting that very strongly = supported adoption of the document. The chairs would now want to confirm the adoption call on the list. = Please let us know by Friday, November 27 whether you support or object = adoption of the document. The proposed milestone is "Submit specification of more accurate ECN = feedback in TCP to the IESG for publication as an Experimental RFC=94 =97 = dated for Aug 2016. - Pasi, Yoshi, Michael From nobody Mon Nov 16 12:23:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88CA1B310D for ; Mon, 16 Nov 2015 12:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41TcVjPnQOF9 for ; Mon, 16 Nov 2015 12:23:37 -0800 (PST) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1691B310C for ; Mon, 16 Nov 2015 12:23:37 -0800 (PST) Received: from t40700-la020.lan (80.223.92.46) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as saropa-1) id 5613C7B101172D0D for tcpm@ietf.org; Mon, 16 Nov 2015 22:22:04 +0200 From: Pasi Sarolahti Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7468519B-FFEE-4FDB-A34A-EFB5A2D736F6@iki.fi> Date: Mon, 16 Nov 2015 22:23:36 +0200 To: "tcpm@ietf.org Extensions" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [tcpm] TCPM notes from IETF-94 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 16 Nov 2015 20:23:38 -0000 Hi, The minutes of the Yokohama TCPM meeting are available at = https://www.ietf.org/proceedings/94/minutes/minutes-94-tcpm. Many thanks = to Christoph and David for compiling them! If you have corrections to make, please send them to list, or directly = to chairs. - Pasi From nobody Mon Nov 16 13:24:01 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39211B31B7 for ; Mon, 16 Nov 2015 13:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.886 X-Spam-Level: X-Spam-Status: No, score=-4.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27vNX91E0Lt9 for ; Mon, 16 Nov 2015 13:23:59 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F2C1B3164 for ; Mon, 16 Nov 2015 13:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1447709038; x=2311622638; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dUj9boJFcMWte4jfT2eTos3xrKHAkLi/rNQ3a4OKkws=; b=4EVFMis5/d2UHOdYFxOwEHNlTBXqpuUGim/lfJJOTOSYI7O+2KcphOWwgtW1LosN xxirvvvY8ni7wvEZbdBY3kwjNGOpS3brnssosTBIB6WA/9mAUxj2UxmtgWYQNmvq A5ZfN64bxNK7hGPr7ckXDxh/MW7lWk+XYagvsGMoKEAaNlS2XMUZz5qESYYWHdAc F2/53FX9gBIu89F3YyhUI8pki6J9GSjjxKoqYjE+xCZPAhG+OR1o1VoHLvzWaj4G cVm8TprM5KLdRnD/eaLq5Bx4TG0jPkULHhTUGHuDpnZ9m5g35Z0JjPIPLwcX6M6V ztzCee5pMt+nV/UuByGNJQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 6E.92.20021.E694A465; Mon, 16 Nov 2015 13:23:58 -0800 (PST) X-AuditID: 11973e13-f79196d000004e35-4b-564a496eb339 Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 37.5B.29392.E694A465; Mon, 16 Nov 2015 13:23:58 -0800 (PST) Received: from rui-imac.apple.com (rui-imac.apple.com [17.226.22.1]) by chicory.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NXX00D1EFFXPT50@chicory.apple.com> for tcpm@ietf.org; Mon, 16 Nov 2015 13:23:58 -0800 (PST) Sender: rpaulo@apple.com Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Rui Paulo In-reply-to: Date: Mon, 16 Nov 2015 13:23:58 -0800 Content-transfer-encoding: quoted-printable Message-id: <7B4EF8CB-5DEF-4FCD-A970-362885921FD5@apple.com> References: To: Pasi Sarolahti X-Mailer: Apple Mail (2.3096.5) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi2FAYpZvn6RVmsGmzssW2k/OZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXnKA+aCaWwVKya9YG1g/MrSxcjJISFgInHy639mCFtM4sK9 9WxdjFwcQgJ7GSX29h+GK3pw+jUrRGIWk8S/J3OZIJy5TBL9nx+yglQJC0hI7D/5kL2LkYOD WUBP4v5FLZAwr4CBxP+rjewQJY4Say9MYwOx2QSUJJ71nQAr5xSwkli1Uw4kzCKgKvFnwQqw cpApe/8fZ4awtSWevLvACjHSRqK/YzuYLSRgKXH3xQcwW0RAS+Lu+RZ2iJvlJX6ubAA7U0Lg K6vEgkub2CYwisxCuG4WkutmIVmxgJF5FaNQbmJmjm5mnqleYkFBTqpecn7uJkZQcE+3E97B eHqV1SFGAQ5GJR7ehr+eYUKsiWXFlbmHGKU5WJTEeTebeIUJCaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYCxfksy87JqAaNPUFWpXPy/eFe+VV6j6kqFLZMKdRQbr/s2UXslx+MX+DOVpktra FdmKV44eXZJmEJb166mK8NODs9NWiC5m1X1hkfZ/zYXMydZnph5o/nnfbcGPu6zMXnOShOVl eEonOpQYchhqXdrDY/XyWJFJfpvUl4YfGY253/eaHFksHaHEUpyRaKjFXFScCAB7zsa/TwIA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FCcrJvn6RVmsGOlosW2k/OZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXnKA+aCaWwVKya9YG1g/MrSxcjJISFgIvHg9GtWCFtM4sK9 9WxdjFwcQgKzmCT+PZnLBOHMZZLo//wQrEpYQEJi/8mH7F2MHBzMAnoS9y9qgYR5BQwk/l9t ZIcocZRYe2EaG4jNJqAk8azvBFg5p4CVxKqdciBhFgFViT8LVoCVg0zZ+/84M4StLfHk3QVW iJE2Ev0d28FsIQFLibsvPoDZIgJaEnfPt7BD3Cwv8XNlA9MERsFZCAfNQnLQLCRTFzAyr2IU KErNSaw000ssKMhJ1UvOz93ECA7GwqgdjA3LrQ4xCnAwKvHwNvz1DBNiTSwrrsw9xCjBwawk wutu4RUmxJuSWFmVWpQfX1Sak1p8iFGag0VJnHeBr1uYkEB6YklqdmpqQWoRTJaJg1OqgTGl 1+Pv++9ci+c5TRfNn7jm+1Wl3Q/+5j056n2h4xxXwbvFATN02n2WB2RGd18WqazdH+v9j/em ZzeHbN6hnif3LLnO/FMtEdn47Gwg3wz9LCe5K8yCVk8TtctUtnIk+3Z9eLMogXWJl8BGx9st ZsFCuUIqB/mvXP2uvvvnMRnrpuoql77XXkosxRmJhlrMRcWJAJOTjSJCAgAA Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Adoption of More Accurate ECN Feedback in TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 16 Nov 2015 21:24:00 -0000 On Nov 16, 2015, at 12:11, Pasi Sarolahti wrote: >=20 > Hi, >=20 > In the Yokohama meeting we discussed adoption of "More Accurate ECN = Feedback in TCP" as Experimental RFC, with = draft-kuehlewind-tcpm-accurate-ecn-05 serving as the baseline for the = working group draft. We called a hum in the meeting that very strongly = supported adoption of the document. >=20 > The chairs would now want to confirm the adoption call on the list. = Please let us know by Friday, November 27 whether you support or object = adoption of the document. >=20 > The proposed milestone is "Submit specification of more accurate ECN = feedback in TCP to the IESG for publication as an Experimental RFC=94 =97 = dated for Aug 2016. Support. -- Rui Paulo From nobody Mon Nov 16 14:20:04 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5921A0074 for ; Mon, 16 Nov 2015 14:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.586 X-Spam-Level: X-Spam-Status: No, score=-5.586 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOudBWGtWKNO for ; Mon, 16 Nov 2015 14:20:01 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD3C1A1A91 for ; Mon, 16 Nov 2015 14:20:01 -0800 (PST) Received: from [128.9.184.114] ([128.9.184.114]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id tAGMJPfe014841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 16 Nov 2015 14:19:26 -0800 (PST) To: "tcpm@ietf.org" From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <564A566C.7000400@isi.edu> Date: Mon, 16 Nov 2015 14:19:24 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: [tcpm] regarding draft-kitamura-tcp-sharp-close X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 16 Nov 2015 22:20:03 -0000 Hi, all, This doc was never posted to this list (although it was presented at Yokohama), so I figured I'd start a thread with some feedback (that IMO probably should have happened online before the meeting). Lars already pointed out a paper that Ted Faber and I wrote on this issue at Infocom 1999. Here's a link to that: http://www.isi.edu/touch/pubs/infocomm99/ Some other info. below. Joe ------ - I don't think the doc is correct on the purpose of SO_LINGER See: http://developerweb.net/viewtopic.php?id=2982 SO_LINGER focuses on half-closed connections, and how long to wait to deliver remaining information.TIME-WAIT is a state that occurs only after both sides have closed the connection. - TIME-WAIT's primary purpose is to avoid the impact of old packets from a previous connection corrupting the data of a new connection. I.e., it's primary purpose is to ensure that *data* packets from an old connection are not accepted by a new connection that reuses the port numbers. The only connection resource that isn't released is the socket pair - i.e., the pair of IP addresses and port numbers that uniquely identify the connection. TIME-WAIT need not consume other resources. TIME-WAIT has nothing to do with resending FINs. It can be entered only when the closing three-way FIN handshake completes. - "sharp close" appears to reinvent simultaneous close However, this doesn't avoid TIME-WAIT; in current TCP, it would require that both sides enter TIME-WAIT. The issue is that the port numbers can't be reused while there might be old data packets that could still arrive (e.g., duplicates from the previous connection that are floating around). TCP requires that these old packets be discarded when a new connection starts. Normally this would happen by the use of the ISN, but a quick enough connection might end up wrapping the sequence numbers around fast enough that the old data could end up in the valid incoming data window. As per RFC 6191, timestamps can be used to avoid this problem as well. - it's not clear how both sides would know to issue the FINs concurrently i.e., this cannot be achieved by user-level operations unless the application coordinates the close in-band; even then, TCP might exchange the FIN/FIN-ACK/ACK before the other side has a chance to start its FIN anyway. - we also already have other ways to deal with TIMEWAIT, e.g., RFC 6191, using lower TIME-WAIT timers because of known properties of port reuse or the willingness to "take a risk" on old data coming in late ---- From nobody Tue Nov 17 13:05:02 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085461A6F9D for ; Tue, 17 Nov 2015 13:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.669 X-Spam-Level: * X-Spam-Status: No, score=1.669 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WudkDIloY2La for ; Tue, 17 Nov 2015 13:04:56 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by ietfa.amsl.com (Postfix) with ESMTP id 531C31B3415 for ; Tue, 17 Nov 2015 13:04:55 -0800 (PST) Received: from localhost.localdomain (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with ESMTP id ABCFA27E03B; Tue, 17 Nov 2015 23:05:24 +0200 (EET) Received: from antispam.orange.md by antispam.orange.md with queue id 254862-1; Tue, 17 Nov 2015 21:05:24 GMT Received: from XCHSRV03.main.orange.md (unknown [192.168.200.63]) by mailfilter.orange.md (Postfix) with ESMTP id 8CAD63B26E3; Tue, 17 Nov 2015 23:05:24 +0200 (EET) Received: from XCHSRV01.main.orange.md ([fe80::685f:aef6:93b0:dea7]) by XCHSRV03.main.orange.md ([fe80::6dbc:28dd:213b:8931%14]) with mapi id 14.02.0328.009; Tue, 17 Nov 2015 23:04:50 +0200 From: Veaceslav ROMAN To: Ingemar Johansson S , Neal Cardwell Thread-Topic: [tcpm] [e2e] TCP HyStart patch deployment Thread-Index: AdCXp+zNDAZ7zydkTra0wALqZYyJLQH+JqqAA0qsYsAOCTWagAADKaaAABZGAgAAAuJsAABGVozQ///TRACAAB/3AIAAKj8AgAEIjoCAABVIgP//hZhA/9ZLHXD/q+ph8P9XvOWw/q9KtpD9XnrA8Pq87vsQ9XoBmgDq7PdWOtXZ4gsAq6EW+gDXJ/xTAK5Pg/vg3IkK9WA= Date: Tue, 17 Nov 2015 21:04:48 +0000 Message-ID: <7DBBB686E19D2049ADAACD210B474BB10167E9D85E@XCHSRV01.main.orange.md> References: <81564C0D7D4D2A4B9A86C8C7404A13DA32145DE4@ESESSMB205.ericsson.se> <1FFD9A11-ADF2-4BA6-A9D3-D8997E1A13E5@gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34B2E666@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E64B65@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E65133@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E676EF@XCHSRV01.main.orange.md> <1441314842.8932.222.camel@edumazet-glaptop2.roam.corp.google.com> <1441385297.17208.6.camel@edumazet-glaptop2.roam.corp.google.com> <7DBBB686E19D2049ADAACD210B474BB10166E856CA@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD84BC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E859FB@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD86EC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E85C4E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD880B@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E8BDBA@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10167E64F3E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB08A1@ESESSMB205.ericsson.se> Accept-Language: en-US, ro-RO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.107.165] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , Piers O'Hanlon , Sangtae Ha , Eric Dumazet , "end2end-interest@postel.org" Subject: Re: [tcpm] [e2e] TCP HyStart patch deployment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Nov 2015 21:05:00 -0000 SGkNClN0aWxsIGV4cGVyaW1lbnRpbmcgd2l0aCBIeXN0YXJ0IGluIExURSBieSB0cnlpbmcgZGlm ZmVyZW50IHBhcmFtZXRlcnMgZm9yIEhZU1RBUlRfREVMQVlfTUlOIGFuZCBIWVNUQVJUX0RFTEFZ X01BWC4NCkluIGFuIGF0dGVtcHQgdG8gZWFzeSB0aGUgdGVzdGluZyB3ZSd2ZSBtb2RpZmllZCB0 aGUgNC4xLjEwIGtlcm5lbCB0byBtYWtlIHRoZXNlIHBhcmFtZXRlcnMgZXh0ZXJuYWxseSBtb2Rp ZmlhYmxlIHBsdXMgYW4gYXR0ZW1wdCBpcyBkb25lIHRvIGZpeCB3aGF0IEkgZG8gcGVyY2VpdmUg YXMgYSBzaWduaWZpY2FuZCBkZXZpYXRpb24gb2YgaW1wbGVtZW50YXRpb24gZnJvbSB0aGUgb3Jp Z2luYWwgaWRlYSBvZiBIeXN0YXJ0LCB3aGljaCwgaW4gbXkgdmlldywgZG9lcyBoYXZlIGEgbmVn YXRpdmUgaW1wYWN0LCBlc3BlY2lhbGx5IGluIG5ldHdvcmtzIHdpdGggaGlnaCB0aHJvdWdocHV0 IGFuZCBkZWxheSB2YXJpYWJpbGl0eSwgbGlrZSByYWRpbyBuZXR3b3Jrcy4gDQpVbmZvcnR1bmF0 ZWx5IDQuMS4xMCB3YXMgdmVyeSB1bnN0YWJsZSwgc2VydmVyIGZyZXF1ZW50bHkgZnJlZXppbmcg YW5kLCBub3QgY29tcGxldGVseSB1bnN1cmUsIHdoZXRoZXIgdGhpcyBpcyBkdWUgdG8gdGhlIGtl cm5lbCBvZiBkdWUgdG8gbW9kaWZpZWQgY29kZS4gTm8ga2VybmVsIGRldmVsb3BtZW50IGV4cGVy aWVuY2UgaGVyZS4NCkFueXdheSB3ZSBkZWNpZGVkIHRvIG1vdmUgdG8gMy4xOS4wLTMzIGFuZCB3 ZSB0cnkgY3VycmVudGx5IHRvIHJlY29tcGlsZS4gDQpJIHdpbGwgYmUgZ3JhdGVmdWwgaWYgc29t ZW9uZSBjYW4gIHJldmlldyB0aGUgY29kZSBpbiB0aGUgbGluayBiZWxsb3csIGF0IGxlYXN0IHRv IGNoZWNrIGlmIHRoZXNlIG1vZGlmaWNhdGlvbiBhcmUgbm90IGlsbGVnYWwgZnJvbSB0aGUga2Vy bmVsIHBvaW50IG9mIHZpZXcuIA0KDQpodHRwczovL2RyaXZlLmdvb2dsZS5jb20vb3Blbj9pZD0w QndSQzFxenNCSzBrWVMxSlNubElhV0o0U0UwDQoNClR3byBzb3VyY2UgZmlsZXMgbW9kaWZpZWQ6 ICBpbmV0X2Nvbm5lY3Rpb25fc29jay5oIGFuZCB0Y3BfY3ViaWMuYy4NCg0KSW5ldF9jb25uZWN0 aW9uX3NvY2suaCBpcyBtb2RpZmllZCB3aXRoIHRoZSBwdXJwb3NlIHRvIGV4dGVuZCB0aGUgc2l6 ZSBvZiB0aGUgaWNza19jYV9wcml2IGluIHN0cnVjdCBpbmV0X2Nvbm5lY3Rpb25fc29jayAgdG8g YWNjb21tb2RhdGUgdHdvIG1vcmUgdTMyIHZhcmlhYmxlcyBpbiB0aGUgc3RydWN0IGJpY3RjcCBp biB0Y3BfY3ViaWMuYy4NCg0KVGNwX2N1YmljLmMgaXMgbW9kaWZpZWQgaW4gc3VjaCBhIHdheSB0 aGF0Og0KCTEuIGl0IGJlY29tZSBwb3NzaWJsZSB0byBtb2RpZnkgYnkgdXNpbmcgbW9kdWxlIHBh cmFtZXRlcnMgdGhlIHZhbHVlIG9mIHdoYXQgaW4gdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25z IGFyZSBjb25zdGFudHM6IEhZU1RBUlRfREVMQVlfTUlOIGFuZCBIWVNUQVJUX0RFTEFZX01BWC4g VGhleSBhcmUgcmVwbGFjZWQgd2l0aCB0d28gbW9kdWxlIHBhcmFtZXRlcnMgaHlzdGFydF9kZWxh eV9taW4gYW5kIGh5c3RhcnRfZGVsYXlfbWF4Lg0KCTIuIHRoZSBjdXJyZW50IGFsZ29yaXRobSBv ZiBIeXN0YXJ0LCAgd2hlcmUgdGhlIGZ1bmN0aW9uIGh5c3RhcnRfdXBkYXRlIGlzIGNhbGxlZCBi ZWZvcmUgZnVuY3Rpb24gaHlzdGFydF9yZXNldCBpcyBrZXB0LCBidXQgYWxzbyBpcyBpbnRyb2R1 Y2VkIGFuIGFsdGVybmF0aXZlIGFsZ29yaXRobSwgd2hlcmUgaHlzdGFydF91cGRhdGUgaXMgY2Fs bGVkIGFmdGVyIGh5c3RhcnRfcmVzZXQsIGFzIGluIG15IHZpZXcsIGNvcnJlc3BvbmRzIHRvIHRo ZSBvcmlnaW5hbCBpZGVhIGFuZCBsb2dpYy4gQWxnb3JpdGhtIHRvIHVzZSBjYW4gYmUgc2VsZWN0 ZWQgYnkgdXNpbmcgdGhlIG5ldyBtb2R1bGUgcGFyYW1ldGVyIGh5c3RhcnRfbmV3LiBBbiBhZGRp dGlvbmFsIG1lbWJlciBpbiB0aGUgc3RydWN0IGJpY3RjcCB1MzIgZGVsYXkgdXNlIHRvIHN0b3Jl IHRoZSBjdXJyZW50IGRlbGF5IGNhbGN1bGF0ZWQgaW4gZnVuY3Rpb24gYmljdGNwX2Fja2VkIGZv ciBmdW5jdGlvbiBiaWN0Y3BfY29uZ19hdm9pZCB3aGljaCBjYWxscyAgaHlzdGFydF9yZXNldCBh bmQgdGhlbiBoeXN0YXJ0X3VwZGF0ZSB3aXRoIHBhcmFtZXRlciBkZWxheS4NCiAgICAgICAgICAg ICAzLiB0aGUgY3VycmVudCBhbGdvcml0aG0gb2YgSHlzdGFydCBIWVNUQVJUX0RFTEFZIGRvZXMg Y29tcGFyZSBkZWxheV9taW4gb2YgdGhlIDggcGFja2V0cyBvZiB0aGUgcm91bmQgd2l0aCB0aGUg Y3Vycl9ydHQsIHNvLCB3aGlsZSB0aGUgb3JpZ2luYWwgaWRlYSBzdXBwb3NlZCB0byBjb21wYXJl IHdpdGggdGhlIGRlbGF5X21pbiBvZiB0aGUgcHJldmlvdXMgcm91bmQuIEhlcmUgdGhpcyBhbHRl cm5hdGl2ZSBpcyBhZGRlZCBhbmQgaXQgY2FuIGJlIHNlbGVjdGVkIGJ5IG1vZHVsZSAgcGFyYW1l dGVyIGh5c3RhcnRfZGVsYXlfbmV3LiAgQW4gYWRkaXRpb25hbCBtZW1iZXIgaW4gdGhlIHN0cnVj dCBiaWN0Y3AgIHUzMiBwcmV2X3JvdW5kX2RlbGF5X21pbiB1c2UgdG8gc3RvcmUgdGhlIHByZXZp b3VzIHJvdW5kIGRlbGF5X21pbiB0byBiZSB1c2VkIGluIGNvbXBhcmlzb24gaW4gdGhlIGN1cnJl bnQgcm91bmQuDQoNCkluIHRoaXMgY29kZSwgdGhlIGRlZmF1bHQgbW9kdWxlIHBhcmFtZXRlcnMg YXJlOiBoeXN0YXJ0X2RlbGF5X21pbj00IChtcyksIGh5c3RhcnRfZGVsYXlfbWF4PTE2IChtcykg KHBhcmFtZXRlcnMgdmFsdWVzIGluIG1zLCBubyBuZWVkIHRvIDw8MyBwYXJhbWV0ZXJzLCB0aGlz IGlzIGRvbmUgaW4gdGhlIGNvZGUpLCBoeXN0YXJ0X25ldz0xLCBjb3JyZXNwb25kaW5nIHRvIHRo ZSBoeXNhcnRfcmVzZXQgY2FsbGVkIGJlZm9yZSBoeXN0YXJ0X3VwZGF0ZSwgIGh5c3RhcnRfZGVs YXlfbmV3PTEgY29ycmVzcG9uZGluZyB0byBjb21wYXJpc29uIG9mIHRoZSBjdXJyZW50IGZpcnN0 IDggUlRUIHdpdGggdGhlIGRlbGF5X21pbiBvZiB0aGUgcHJldmlvdXMgcm91bmQuIFRvIGhhdmUg dGhlIGFsZ29yaXRobSBiZWhhdmluZyBsaWtlIGluIHRoZSBjdXJyZW50IHN0YW5kYXJkIGltcGxl bWVudGF0aW9uIG9uZSBkbyBuZWVkIHRvIHNldCB0aGUgaHlzdGFydF9uZXc9MCBhbmQgaHlzdGFy dF9kZWxheV9uZXc9MC4NCg0KVGhlIHJlYXNvbiBmb3Igd2hhdCBJIGJlbGlldmVkIHRoZSBjYWxs IG9mIGh5c3RhcnRfdXBkYXRlIGJlZm9yZSB0aGUgaHlzdGFydF91cGRhdGUgaXMgYSBiaWcgZGV2 aWF0aW9uIGZyb20gdGhlIGluaXRpYWwgbG9naWMgaXMgYXMgZm9sbG93Lg0KQm90aCBIWVNUQVJU X0FDS19UUkFJTiBhbmQgIEhZU1RBUlRfREVMQVkgYWxnb3JpdGhtcyBpbiBmdW5jdGlvbiBoeXN0 YXJ0X3VwZGF0ZSBhcmUgc3VwcG9zZWQgdG8gZG8gc29tZSBjb21wdXRpbmcgc3RhcnRpbmcgd2l0 aCB0aGUgZmlyc3QgQUNLIG9mIHRoZSB0cmFpbi4gVGhlIGJlZ2lubmluZyBvZiB0aGUgdHJhaW4g aXRzZWxmIGlzIGRldGVybWluZWQgYnkgdGhlIGZ1bmN0aW9uIGh5c3RhcnRfcmVzZXQuIEJ1dCwg YmVjYXVzZSwgaW4gdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gdGhlIGh5c3RhcnRfdXBkYXRl IGlzIGNhbGxlZCBmb3IgZWFjaCBBQ0sgYmVmb3JlIHRoZSBoeXN0YXJ0X3Jlc2V0LCB0aGUgZmly c3QgQUNLIG9mIHRoZSB0cmFpbiBOKzEgaXMgc3RpbGwgY29uc2lkZXJlZCBpbiBoeXN0YXJ0X3Vw ZGF0ZSBhcyBhbiBBQ0sgb2YgdGhlIHByZXZpb3VzIHRyYWluIE4uIChpbiB0Y3BfaW5wdXQuYzog dGNwX2FjaygpIC0+IHRjcF9jbGVhbl9ydHhfcXVldWUoKSAtPiAgcGt0c19hY2tlZCgpPWJpY3Rj cF9hY2tlZCgpIC0+IGh5c3RhcnRfdXBkYXRlKCk7ICB0aGVuICB0Y3BfaW5wdXQuYzogdGNwX2Fj aygpIC0+IHRjcF9jb25nX2F2b2lkKCkgLT4gY29uZ19hdm9pZD1iaWN0Y3BfY29uZ19hdm9pZCgp IC0+IGh5c3RhcnRfcmVzZXQoKTsgYW5kLCBidHcsIHRjcF9zbG93X3N0YXJ0KCkgaXMgY2FsbGVk IG5leHQgKS4gDQpUaGVyZWZvciBIWVNUQVJUX0FDS19UUkFJTiwgaW4gdGhlIGN1cnJlbnQgaW1w bGVtZW50YXRpb24sIHdpbGwgbm90IG1lYXN1cmUsIGFzIGl0IHdhcyBzdXBwb3NlZCBpbiB0aGUg b3JpZ2luYWwgcGFwZXIsIHRoZSBsZW5ndGggb2YgdGhlIEFDSyB0cmFpbiwgYnV0IGEgZHVyYXRp b24gYmV0d2VlbiB0aGUgMi1uZCBBQ0sgb2YgdGhlIHRyYWluIE4gYW5kIHRoZSBmaXJzdCBBQ0sg b2YgdGhlIHRyYWluIE4rMS4gVGhpcyB3aWxsIHVzdWFsbHkgcmVzdWx0IGluIGFwcHJveGltYXRl bHkgb25lIGZ1bGwgUlRULiBEdWUgdG8gcHJvdGVjdGlvbiAobm93IC0gY2EtPmxhc3RfYWNrKSA8 PSBoeXN0YXJ0X2Fja19kZWx0YSAoMiBtcykgdGhpcyB3b3VsZCBsZWFkOiANCgktIGluIHN1YiAy IG1zIFJUVCBuZXR3b3JrcyB0byBhbHdheXMgdG9vIGVhcmx5IGV4aXQgKGluIHRoZSBzZWNvbmQg cm91bmQpIA0KICAgICAgICAgICAgIC0gaW4gb3ZlciAyIG1zIFJUVCBuZXR3b3JrcyB0byBhbHdh eXMgdG9vIGxhdGUgZXhpdCAoZHVlIHRvIFJUVCA+IFJUVC8yIHdoaWxlICBub3cgLSBjYS0+bGFz dF9hY2spIDw9IDIgbXMgd2hlbiB0aGUgSE9MIEFDSyBvZiBOKzEgYXBwcm9hY2hlcyB0YWlsIEFD SyBvZiBOIHRvIGxlc3MgdGhhbiAyIG1zLg0KTWVhbnMgdGhhdCBjdXJyZW50IGltcGxlbWVudGF0 aW9uIG9mIEhZU1RBUlRfQUNLX1RSQUlOIGRvZXMgbm90IHdvcmsgYXMgZXhwZWN0ZWQgKGRpZCBp dCBldmVyID8pLg0KDQpIWVNUQVJUX0RFTEFZIGFsc28gc3VmZmVycyBkdWUgdG8gdGhpcyBzaGlm dDogdGhlIGZpcnN0IEFDSyBvZiB0aGUgdHJhaW4gTisxIHdpbGwgbm90IGJlIGFjY291bnRlZCBp biB0aGUgcm91bmQgTisxIGJ1dCBoYXZlIGNoYW5jZXMgdG8gYmVjb21lIGEgbmV3IGRlbGF5X21p biAoYXMgdXN1YWwgSE9MIGhhdmUgbGVzcyBSVFQgdGhlbiBmb2xsb3dpbmcgcGFja2V0cyksIHdo aWxlLCBmb2xsb3dpbmcgQUNLIDIuLi45IG9mIHRoZSByb3VuZCBOKzEgaGF2ZSBiaWdnZXIgY2hh bmNlcyB0byBleGNlZWQgdGhlIGRlbGF5X21pbiwgZXZlbiB0aG91Z2gsIHdvdWxkIHRoZSBBQ0sg Tm8gMSBiZSBhY2NvdW50ZWQgaW4gcm91bmQgTisxLCB0aGlzIGV4aXQgZnJvbSBIeXN0YXJ0IHdp bGwgbm90IHRha2UgcGxhY2UuIEZvciB0aGUgcmFkaW8gbmV0d29ya3MsIHdpdGggaGlnaCB2YXJp YWJpbGl0eSBvZiB0aHJvdWdocHV0IGFuZCBkZWxheSBhbmQgc2NoZWR1bGluZyBkZWxheSB0aGlz IG1pZ2h0IGJlIGNyaXRpY2FsIGFuZCwgbWFueSB0cmFjZXMgc2hvd3MgdGhpcyBpcyBjcml0aWNh bCBpbiBMVEUuDQoNCkZvciB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbiBjb21wYXJpc29uIGlu ICBIWVNUQVJUX0RFTEFZIG9mIHRoZSBtaW5pbXVtIG9mIHRoZSBkZWxheSBvZiB0aGUgOCBwYWNr ZXRzIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHJvdW5kIChObyAyLi4uOSwgb3IsIGlmIGZpeGVk LCBObyAxLi4uOCkgd2l0aCB0aGUgZGVsYXkgYWZ0ZXIgdGhlc2UgOCBBQ0sgbG9vayBhbmQgZXhp dCBpZiBmb2xsb3dpbmcgQUNLIGhhcyBsb3dlciBSVFQgbG9va3MgdG8gbWUgbm90IHRvdGFsbHkg bG9naWNhbDogaWYsIHRoZSBSVFQgYXQgdGhlIGVuZCBvZiB0aGUgcm91bmQgYmVjb21lIGxvd2Vy IHRoYW4gUlRUIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHJvdW5kIHRoYXQgY2FuIG9ubHkgbWVh biB0aGF0IGxpbmsgZ2FpbmVkIGFkZGl0aW9uYWwgcGVyZm9ybWFuY2UgKGVpdGhlciB0aGUgcXVl dWUgZGVjcmVhc2VkIG9yIHRocm91Z2hwdXQgaW5jcmVhc2UsIG9yIGJvdGgsIHRoZXkgYXJlIGlu dGVycmVsYXRlZCkuIElzbid0IGl0IG1vcmUgbG9naWNhbCB0byBsZXQgdGhlIHNsb3cgc3RhcnQg dG8gcHJvYmUgbW9yZSBmb3IgdGhpcyBhZGRpdGlvbmFsIGNhcGFjaXR5IGluc3RlYWQgb2YgYnJl YWtpbmcgaXQgZXhhY3RseSBhdCB0aGlzIG1vbWVudCA/DQoNClByb2JhYmx5LCB0aGVzZSBjb25z aWRlcmF0aW9ucywgaW5kdWNlZCBvbmx5IGJ5IHRlc3RzIGluIG9uZSB0eXBlIG9mIG5ldHdvcmsg KExURSkgIGFuZCBhbmFseXNpcyBvZiB0aGUgY29kZSBieSBub3QgYSBwcm9mZXNzaW9uYWwga2Vy bmVsIG1pZ2h0IGJlIG5vdCB0b3RhbGx5IGNvcnJlY3QsIGJ1dCBJIHdpbGwgYXBwcmVjaWF0ZSBh bnkgY29tbWVudHMsIGFuZCBtb3N0bHkgc3VnZ2VzdGlvbiBmb3IgaW1wcm92ZW1lbnQgd2hpY2gg bWF5IGhlbHAgdG8gaW1wcm92ZSB0aGUgYWxnb3JpdGhtLg0KICAgDQpUaGUgZmV3IHRlc3RzIGRv bmUgaW4gKHVuc3RhYmxlKSBtb2RpZmllZCA0LjEuMTAgc2hvd24gc2lnbnMgb2YgZ29vZCByZXN1 bHRzLCBidXQgd2UgYXJlIGdvaW5nIHRvIHBlcmZvcm0gZXh0ZW5zaXZlIHRlc3RzIHdpdGggMy4x OS4gIA0KDQogDQoNClZlYWNlc2xhdiBSb21hbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBWZWFjZXNsYXYgUk9NQU4gDQpTZW50OiBUdWVzZGF5LCAwMyBOb3ZlbWJlciAy MDE1IDIxOjA2DQpUbzogJ0luZ2VtYXIgSm9oYW5zc29uIFMnOyBOZWFsIENhcmR3ZWxsDQpDYzog RXJpYyBEdW1hemV0OyBFcmljIER1bWF6ZXQ7IHRjcG1AaWV0Zi5vcmc7IFBpZXJzIE8nSGFubG9u OyBTYW5ndGFlIEhhOyBlbmQyZW5kLWludGVyZXN0QHBvc3RlbC5vcmcNClN1YmplY3Q6IFJFOiBb dGNwbV0gW2UyZV0gVENQIEh5U3RhcnQgcGF0Y2ggZGVwbG95bWVudA0KDQpZb3UgYXJlIHJpZ2h0 LCBpdCB3YXNuJ3QgbW9kaWZpZWQgYW5kIHN0YXllZCBhdCAxNi4gVGhhbmsgeW91IGZvciBzdWdn ZXN0aW9uLg0KQ3VycmVudGx5IHdlIGFyZSB0cnlpbmcgdG8gbWFrZSBhbiBleHBlcmltZW50YWwg dmVyc2lvbiB3ZXJlIHRoaXMgd291bGQgYmUgcG9zc2libGUgdG8gbWFrZSB0aGVzZSBwYXJhbWV0 ZXJzIGFuZCBmZXcgb3RoZXIgdGhpbmdzIGV4dGVybmFsbHkgc2V0dGFibGUuDQoNCkJ1dCwgaG9u ZXN0bHksIHRoZSBmdXJ0aGVyIHdlIGRpZyBpbiB0aGUgY29kZSBhbmQgdHJhY2VzIHRoZSBtb3Jl IHRoZSBjb25mdXNpb24gYW5kIG1vcmUgcXVlc3Rpb25zIGFyaXNlcy4NCglIeXN0YXJ0IHJlbHkg b24gY29ycmVjdCBpZGVudGlmaWNhdGlvbiBvZiByb3VuZCBib3JkZXJzLiBGb3IgdGhpcyBoeXN0 YXJ0X3Jlc2V0IHNldHMgdGhlIGJvcmRlciBhdCBzbmRfbnh0LiANCkJ1dCwgaWYgc2V2ZXJhbCBB Q0sgYXJyaXZlIGF0IGhpZ2ggc3BlZWQgd2hlbiB0aGUgY3VycmVudCByb3VuZCBib3JkZXIgaXMg Y3Jvc3NlZCBhbmQgdGhlIHNlbmRlciBoYXMgbm90IHRpbWUgdG8gdHJhbnNtaXQgdHdvIHBhY2tl dHMgaW1tZWRpYXRlbHkgYWZ0ZXIgQUNLLCB0aGVuIHRoZSBzbmRfbnh0IGRvZXMgbm90IHByb2dy ZXNzIGFuZCBoeXN0YXJ0X3Jlc2V0IHNldHMgdGhlIHJvdW5kIG9mIHRoZSBib3JkZXIgdG8gYSBw cmV0dHkgcmFuZG9tIHZhbHVlIGFuZCB0aGVuIGluIHRoZSBuZXh0IHJvdW5kIHRoZSBoeXN0YXJ0 IG1lYXN1cmUgcGllY2VzIG9mIHR3byByb3VuZHMuDQoJQWxzbywgdGhlIGNvZGUgaXMgY2FsbGlu ZyBoeXN0YXJ0X3VwZGF0ZSBvbiBlYWNoIEFDSyBiZWZvcmUgdGhlIGh5c3RhcnRfcmVzZXQsIGFz IGEgcmVzdWx0IGF0IHRoZSBib3JkZXIgb2Ygcm91bmRzIHRoZSBoZWFkIG9mIGxpbmUgKEhPTCkg QUNLIGRlbGF5IG9mIHJvdW5kIE4rMSBpcyBhY2NvdW50ZWQgaW4gdGhlIHJvdW5kIE4gYW5kLCBi ZWNhdXNlLCB0aGUgSE9MIHVzdWFsbHkgaGFzIGxlc3MgZGVsYXksIGl0IGlzIGZyZXF1ZW50bHkg YmVjb21lIGRlbGF5X21pbiBidXQgbm90IGluIHJvdW5kIE4rMSBhbmQsIGFzIGEgcmVzdWx0IGVh cmx5IGV4aXQgaW4gcm91bmQgTisxIGFmdGVyIGNvdW50aW5nIGRlbGF5cyBvZiBwYWNrZXRzIDIg dGhyb3VnaCA5LiANCglUaGlzIHNob3VsZCBhbHNvIGFmZmVjdCB0cmFpbiBkZXRlY3QgYXMsIHdo ZW4gY3Jvc3NpbmcgdGhlIHJvdW5kIGJvcmRlciwgaW5zdGVhZCBvZiBzdWJ0cmFjdGluZyB0aGUg dGltZSBvZiB0aGUgZmlyc3QgYW5kIHRoZSBsYXN0IEFDSyBvZiB0aGUgdHJhaW4gTiB0aGVyZSB3 aWxsIGJlIHN1YnRyYWN0ZWQgdGltZXMgb2YgZmlyc3QgQUNLIG9mIHRyYWluIE4gYW5kIGZpcnN0 IEFDSyBvZiB0aGUgdHJhaW4gTisxIHdoaWNoIHdpbGwgYmUgYXBwcm94aW1hdGVseSBlcXVhbCB0 byBSVFQgYW5kIGRlZmluaXRlbHkgYmlnZ2VyIHRoYW4gUlRULzIgYXMgcGVyIGV4cGVjdGVkIGFs Z29yaXRobS4gVGhpcyBzaGFsbCB0eXBpY2FsbHkgbGVhZCB0byBhbHdheXMgZXhpdCBpbiB0cmFp biAyLiBUaGlzIHdpbGwgYWZmZWN0IGhpZ2ggc3BlZWQgbmV0d29ya3Mgd2l0aCBSVFQgbGVzcyB0 aGFuIGh5c3RhcnRfYWNrX2RlbHRhICgybXMpLg0KICAgICAgICAgICAgIFRoZW4gY2FsbCBvZiBo eXN0YXJ0X3Jlc2V0IGlzIHN1YmplY3Qgb2YgY2hlY2sgb2Ygc2V2ZXJhbCBjb25kaXRpb25zIGxp a2UgbWF5X3Jpc2VfY3duZCBvciBpc19jd25kX2xpbWl0ZWQsIHdoaWxlIGl0IGRvZXNuJ3QgbG9v ayB0aGF0IGh5c3RhcnRfdXBkYXRlIGlzLCBzbyB0aGF0IGl0IG1heSBiZWNvbWUgdG90YWxseSBv dXQgb2Ygc3luYyB3aXRoIHJvdW5kIGJvcmRlci4NCiANCglXZSBhcmUgc3RpbGwgZG9pbmcgZWZm b3J0cyB0byB0cnkgdG8gZmluZCBwYXJhbWV0ZXJzIHdoaWNoIHdvdWxkIG1ha2UgaHlzdGFydCBi ZXR0ZXIsIGJ1dCBhbmFseXNpcyBvZiBtYW55IHRyYWNlcyBtYWtlIG11Y2ggaW1wcmVzc2lvbiBv ZiByYW5kb21uZXNzIG9mIGV4aXQgYW5kIG5vdCBzdXJlIHdoZXRoZXIgcGFyYW1ldGVycyBtYXkg aGVscC4gDQoNClZlYWNlc2xhdiBSb21hbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogSW5nZW1hciBKb2hhbnNzb24gUyBbbWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJp Y3Nzb24uY29tXQ0KU2VudDogVHVlc2RheSwgMDMgTm92ZW1iZXIgMjAxNSAxNToxOQ0KVG86IFZl YWNlc2xhdiBST01BTjsgTmVhbCBDYXJkd2VsbA0KQ2M6IEVyaWMgRHVtYXpldDsgRXJpYyBEdW1h emV0OyB0Y3BtQGlldGYub3JnOyBQaWVycyBPJ0hhbmxvbjsgU2FuZ3RhZSBIYTsgZW5kMmVuZC1p bnRlcmVzdEBwb3N0ZWwub3JnOyBJbmdlbWFyIEpvaGFuc3NvbiBTDQpTdWJqZWN0OiBSRTogW3Rj cG1dIFtlMmVdIFRDUCBIeVN0YXJ0IHBhdGNoIGRlcGxveW1lbnQNCg0KSGkNCg0KVGhhbmtzIGZv ciBkb2luZyB0aGUgZXhwZXJpbWVudHMuIA0KSXQgbWF5IGJlIHBvc3NpYmxlIHRoYXQgSHlTdGFy dCBtYXkgbmVlZCBtb3JlIGV4dGVuc2l2ZSBtb2RpZmljYXRpb25zLiANCk5lZWQgdG8gYXNrIHRo ZSBkdW1iIHF1ZXN0aW9uIGZpcnN0IHRob3VnaC4gSXMgSFlTVEFSVF9ERUxBWV9NQVggbW9kaWZp ZWQgaW4geW91ciBleHBlcmltZW50IG9yIGlzIGl0IHN0aWxsIDE2bXMgPw0KSSBndWVzcyBIWVNU QVJUX0RFTEFZX01BWCBtYXkgbmVlZCB0byBiZSBzZXQgdG8gDQogICAgSFlTVEFSVF9ERUxBWV9N QVggPSBNQVgoMTZtcywgSFlTVEFSVF9ERUxBWV9NSU4qMikgT3Igc29tZXRoaW5nIHNpbWlsYXIs IG9uZSBjYW4gYWx3YXlzIGFyZ3VlIGFyb3VuZCB0aGUgZmFjdG9yIDIgYWJvdmUuDQoNCi9Jbmdl bWFyDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVmVhY2VzbGF2IFJP TUFOIFttYWlsdG86VmVhY2VzbGF2LlJvbWFuQG9yYW5nZS5tZF0NCj4gU2VudDogZGVuIDE3IG9r dG9iZXIgMjAxNSAyMjo0OA0KPiBUbzogTmVhbCBDYXJkd2VsbA0KPiBDYzogRXJpYyBEdW1hemV0 OyBJbmdlbWFyIEpvaGFuc3NvbiBTOyBFcmljIER1bWF6ZXQ7IHRjcG1AaWV0Zi5vcmc7IA0KPiBQ aWVycyBPJ0hhbmxvbjsgU2FuZ3RhZSBIYTsgZW5kMmVuZC1pbnRlcmVzdEBwb3N0ZWwub3JnDQo+ IFN1YmplY3Q6IFJFOiBbdGNwbV0gW2UyZV0gVENQIEh5U3RhcnQgcGF0Y2ggZGVwbG95bWVudA0K PiANCj4gSGksDQo+IFJlY29tcGlsZWQga2VybmVsIHRvIEhZU1RBUlRfREVMQVlfTUlOICAyMCBt czoNCj4gDQo+ICAgRG93bmxvYWQgMTBNQiwgSGlnaCBCYW5kd2lkdGhzLCBIWVNUQVJUX0RFTEFZ X01JTiAgMjAgbXM6DQo+ICAgICAgICAgICAgSHlzdGFydCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6 IDEuMTggcw0KPiAgICAgICAgICAgIE5vSHlzdGFydCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6IDEu MDAgIHMNCj4gDQo+IE5vIHNpZ25pZmljYW50IGltcHJvdmVtZW50IGFnYWluc3QgdGhlIGNhc2Ug d2l0aCBIWVNUQVJUX0RFTEFZX01JTiAgMTAgDQo+IG1zLg0KPiANCj4gU2lsbCBIeXN0YXJ0IGVh cmx5IGV4aXQgaXMgdmlzaWJsZS4NCj4gDQo+IE90aGVyIHRlc3RzIHdpdGggSFlTVEFSVF9ERUxB WV9NSU4gIDIwIG1zIGFuZCBmaWxlcyBvZiAzTUIuDQo+IA0KPiAgIERvd25sb2FkIDNNQiwgSGln aCBCYW5kd2lkdGhzLCBIWVNUQVJUX0RFTEFZX01JTiAgMjAgbXM6DQo+ICAgICAgICAgICAgSHlz dGFydCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6IDAuNDcgcw0KPiAgICAgICAgICAgIE5vSHlzdGFy dCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6IDAuMzkgIHMNCj4gDQo+IGNvbXBhcmUgd2l0aCA0IG1z DQo+IA0KPiAgIERvd25sb2FkIDNNQiwgSGlnaCBCYW5kd2lkdGhzLCBIWVNUQVJUX0RFTEFZX01J TiAgNCBtczoNCj4gICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2UgZG93bmxvYWQgdGltZTogMC42 NSBzDQo+ICAgICAgICAgICAgTm9IeXN0YXJ0IGF2ZXJhZ2UgZG93bmxvYWQgdGltZTogMC4zNyAg cw0KPiANCj4gRmV3IG1vcmUgY29tbWVudDogSGlnaCBCYW5kd2lkdGggaXMgdHlwaWNhbGx5IGFi b3ZlIDMwLTQwIE1icHMuDQo+IEZvciBMb3cgQmFuZHdpZHRoLCB3aGVuIHJhZGlvIGRvIG5vdCBw ZXJtaXQgYWJvdmUgNDAgTWJwcyBIeXN0YXJ0IA0KPiBlYXJseSBleGl0IGRvZXMgbm90IGhhdmUg YSBzaWduaWZpY2FudCBpbXBhY3QuIEkgZG8gZXhwbGFpbiBpdCB3aXRoIA0KPiB0aGUgZmFjdCB0 aGF0IHRoZSBtaW5pbXVtIGV4aXQgQ1dORCBmb3IgSHlzc3RhcnQgaXMgMjkgd2hpY2gsIGZvciBS VFQgDQo+IG9mIH4xNW1zIChtaW5pbXVtIHBvc3NpYmxlIGluIExURSBhbmQgdmlzaWJsZSBpbiBt YWpvcml0eSBvZiB0cmFjZXMpIA0KPiBsZWFkcyB0byB+MjUgTWJwcywgc28gSHlzdGFydCBleGl0 LCBhdCBsZWFzdCwgYXQgMjUgTWJwcyBhbmQgdGhlbiBpdCANCj4gdGFrZXMgbm90IHRvbyBsb25n IHRvIGN1YmljIHRvIHJlYWNoIDMwLTQwIE1icHMuDQo+IA0KPiBWZWFjZXNsYXYgUm9tYW4NCj4g DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5lYWwgQ2FyZHdlbGwgW21h aWx0bzpuY2FyZHdlbGxAZ29vZ2xlLmNvbV0NCj4gU2VudDogVHVlc2RheSwgMDYgT2N0b2JlciAy MDE1IDA0OjA2DQo+IFRvOiBWZWFjZXNsYXYgUk9NQU4NCj4gQ2M6IEVyaWMgRHVtYXpldDsgSW5n ZW1hciBKb2hhbnNzb24gUzsgRXJpYyBEdW1hemV0OyB0Y3BtQGlldGYub3JnOyANCj4gUGllcnMg TydIYW5sb247IFNhbmd0YWUgSGE7IGVuZDJlbmQtaW50ZXJlc3RAcG9zdGVsLm9yZw0KPiBTdWJq ZWN0OiBSZTogW3RjcG1dIFtlMmVdIFRDUCBIeVN0YXJ0IHBhdGNoIGRlcGxveW1lbnQNCj4gDQo+ IE9uIE1vbiwgT2N0IDUsIDIwMTUgYXQgNjowNyBQTSwgVmVhY2VzbGF2IFJPTUFOIA0KPiA8VmVh Y2VzbGF2LlJvbWFuQG9yYW5nZS5tZD4gd3JvdGU6DQo+ID4gV2UndmUgbWFuYWdlZCB0byByZWNv bXBpbGUgdGhlIGtlcm5lbCA0LjEgd2l0aCB0Y3BfY3ViaWMNCj4gSFlTVEFSVF9ERUxBWV9NSU4g ICgxMFU8PDMpICwgMTBtcy4NCj4gPiBXZWxsLCB3ZSBoYWQgdGltZSBvbmx5IGZvciBvbmUgdGVz dCBjeWNsZSwgYnV0IHJlc3VsdHMgYXJlIHZlcnkgcHJvbWlzaW5nOg0KPiA+DQo+ID4gRG93bmxv YWQgMTBNQiwgSGlnaCBCYW5kd2lkdGhzLCBIWVNUQVJUX0RFTEFZX01JTiAgMTAgbXM6DQo+ID4g ICAgICAgICAgICBIeXN0YXJ0IGF2ZXJhZ2UgZG93bmxvYWQgdGltZTogMS4xNiBzDQo+ID4gICAg ICAgICAgICBOb0h5c3RhcnQgYXZlcmFnZSBkb3dubG9hZCB0aW1lOiAwLjkzICBzDQo+IC4uLg0K PiA+ICBEb3dubG9hZCAxME1CLCBIaWdoIEJhbmR3aWR0aHMsIEhZU1RBUlRfREVMQVlfTUlOICA0 IG1zOg0KPiA+ICAgICAgICAgICAgSHlzdGFydCBhdmVyYWdlIGRvd25sb2FkIHRpbWU6IDEuNDIg cw0KPiA+ICAgICAgICAgICAgTm9IeXN0YXJ0IGF2ZXJhZ2UgZG93bmxvYWQgdGltZTogMC44OSAg cw0KPiANCj4gVGhhbmtzISBUaGF0IGlzIHZlcnkgdXNlZnVsIGFuZCBpbnRlcmVzdGluZyBkYXRh LiBXb3VsZCB5b3UgYmUgYWJsZSB0byANCj4gdHJ5IGEgZmV3IG90aGVyIHZhbHVlcywgbGlrZSAx NW1zIGFuZCAyMG1zPw0KPiANCj4gbmVhbA0K From nobody Tue Nov 17 14:48:18 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06A01B34A5 for ; Tue, 17 Nov 2015 14:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naJ9sQgAvUMH for ; Tue, 17 Nov 2015 14:48:15 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AFBB1B34A3 for ; Tue, 17 Nov 2015 14:48:15 -0800 (PST) Received: by pacej9 with SMTP id ej9so22297797pac.2 for ; Tue, 17 Nov 2015 14:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=I3Ur+zmnJ7sp+fBi/ZxNuX3OHYG9yVwBDQqX4bB5gtI=; b=WVw2Z6+hClaAys6qR8qi3rm+G8i5qvDDeNrKMasYDd3dIQs3bup3/OvKNE2DqgyB6G 3j4buaDlCz/P8IE0ZMyLh39DJwIqApD8knkA7L1UNLfVbkqE8BuQrLz1uRwS2hMXypwP oshl1DUZUPjTR3oY3dEt+fEVHK/wsFZUHrrsNLKI/CxFz7UWFjde3k/Tc8Vjz24rEacE EAnZM7ylNG5AXvBdswfUJp+EfCTIjpMaMog1EepvrqwMoEWrLVc8ZIKNL1W5UKVYyNIq eJyp3nKzXkNIwecUJD19kHYvzrfbY1VavzfqYkUvv6z8LpA82XwA2zHs5C6vbytdS5db gDNA== X-Received: by 10.66.246.225 with SMTP id xz1mr66522587pac.27.1447800493969; Tue, 17 Nov 2015 14:48:13 -0800 (PST) Received: from ?IPv6:2620:0:1000:3e02:443f:2596:7fe6:c80c? ([2620:0:1000:3e02:443f:2596:7fe6:c80c]) by smtp.gmail.com with ESMTPSA id jp1sm42728490pbc.54.2015.11.17.14.48.12 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Nov 2015 14:48:12 -0800 (PST) Message-ID: <1447800492.22599.126.camel@edumazet-glaptop2.roam.corp.google.com> From: Eric Dumazet To: Veaceslav ROMAN Date: Tue, 17 Nov 2015 14:48:12 -0800 In-Reply-To: <7DBBB686E19D2049ADAACD210B474BB10167E9D85E@XCHSRV01.main.orange.md> References: <81564C0D7D4D2A4B9A86C8C7404A13DA32145DE4@ESESSMB205.ericsson.se> <1FFD9A11-ADF2-4BA6-A9D3-D8997E1A13E5@gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34B2E666@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E64B65@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E65133@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E676EF@XCHSRV01.main.orange.md> <1441314842.8932.222.camel@edumazet-glaptop2.roam.corp.google.com> <1441385297.17208.6.camel@edumazet-glaptop2.roam.corp.google.com> <7DBBB686E19D2049ADAACD210B474BB10166E856CA@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD84BC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E859FB@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD86EC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E85C4E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD880B@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E8BDBA@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10167E64F3E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB08A1@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10167E9D85E@XCHSRV01.main.orange.md> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tcpm@ietf.org" , Piers O'Hanlon , Sangtae Ha , Ingemar Johansson S , Eric Dumazet , "end2end-interest@postel.org" Subject: Re: [tcpm] [e2e] TCP HyStart patch deployment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 17 Nov 2015 22:48:16 -0000 On Tue, 2015-11-17 at 21:04 +0000, Veaceslav ROMAN wrote: > Hi > Still experimenting with Hystart in LTE by trying different parameters for HYSTART_DELAY_MIN and HYSTART_DELAY_MAX. > In an attempt to easy the testing we've modified the 4.1.10 kernel to make these parameters externally modifiable plus an attempt is done to fix what I do perceive as a significand deviation of implementation from the original idea of Hystart, which, in my view, does have a negative impact, especially in networks with high throughput and delay variability, like radio networks. > Unfortunately 4.1.10 was very unstable, server frequently freezing and, not completely unsure, whether this is due to the kernel of due to modified code. No kernel development experience here. > Anyway we decided to move to 3.19.0-33 and we try currently to recompile. v-4.1.13 should be stable, 4.1.10 had tcp bugs. From nobody Tue Nov 17 23:37:30 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CEF1B29B1 for ; Tue, 17 Nov 2015 23:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHZf0hVyBoc7 for ; Tue, 17 Nov 2015 23:37:27 -0800 (PST) Received: from mailfilter.orange.md (mailfilter.orange.md [94.243.64.204]) by ietfa.amsl.com (Postfix) with ESMTP id ECBC81B29AC for ; Tue, 17 Nov 2015 23:37:26 -0800 (PST) Received: from localhost.localdomain (antispam.orange.md [127.0.0.1]) by localhost (Postfix) with ESMTP id 000A83B2778; Wed, 18 Nov 2015 09:37:54 +0200 (EET) Received: from antispam.orange.md by antispam.orange.md with queue id 254887-1; Wed, 18 Nov 2015 07:37:54 GMT Received: from XCHSRV03.main.orange.md (unknown [192.168.200.63]) by mailfilter.orange.md (Postfix) with ESMTP id CDBDF3B2778; Wed, 18 Nov 2015 09:37:54 +0200 (EET) Received: from XCHSRV01.main.orange.md ([fe80::685f:aef6:93b0:dea7]) by XCHSRV03.main.orange.md ([fe80::6dbc:28dd:213b:8931%14]) with mapi id 14.02.0328.009; Wed, 18 Nov 2015 09:37:20 +0200 From: Veaceslav ROMAN To: Eric Dumazet Thread-Topic: [tcpm] [e2e] TCP HyStart patch deployment Thread-Index: AdCXp+zNDAZ7zydkTra0wALqZYyJLQH+JqqAA0qsYsAOCTWagAADKaaAABZGAgAAAuJsAABGVozQ///TRACAAB/3AIAAKj8AgAEIjoCAABVIgP//hZhA/9ZLHXD/q+ph8P9XvOWw/q9KtpD9XnrA8Pq87vsQ9XoBmgDq7PdWOtXZ4gsAq6EW+gDXJ/xTAK5Pg/vg3IkK9WC5EefLAPIjGlzg Date: Wed, 18 Nov 2015 07:37:19 +0000 Message-ID: <7DBBB686E19D2049ADAACD210B474BB10167E9DC4A@XCHSRV01.main.orange.md> References: <81564C0D7D4D2A4B9A86C8C7404A13DA32145DE4@ESESSMB205.ericsson.se> <1FFD9A11-ADF2-4BA6-A9D3-D8997E1A13E5@gmail.com> <81564C0D7D4D2A4B9A86C8C7404A13DA34B2E666@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E64B65@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E65133@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10166E676EF@XCHSRV01.main.orange.md> <1441314842.8932.222.camel@edumazet-glaptop2.roam.corp.google.com> <1441385297.17208.6.camel@edumazet-glaptop2.roam.corp.google.com> <7DBBB686E19D2049ADAACD210B474BB10166E856CA@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD84BC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E859FB@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD86EC@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E85C4E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34BD880B@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10166E8BDBA@XCHSRV01.main.orange.md> <7DBBB686E19D2049ADAACD210B474BB10167E64F3E@XCHSRV01.main.orange.md> <81564C0D7D4D2A4B9A86C8C7404A13DA34EB08A1@ESESSMB205.ericsson.se> <7DBBB686E19D2049ADAACD210B474BB10167E9D85E@XCHSRV01.main.orange.md> <1447800492.22599.126.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: <1447800492.22599.126.camel@edumazet-glaptop2.roam.corp.google.com> Accept-Language: en-US, ro-RO Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.107.165] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org" , Piers O'Hanlon , Sangtae Ha , Ingemar Johansson S , Eric Dumazet , "end2end-interest@postel.org" Subject: Re: [tcpm] [e2e] TCP HyStart patch deployment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Nov 2015 07:37:29 -0000 VGhhbmsgeW91Lg0KSSB3aWxsIGdpdmUgYSB0cnkgdG8gMy4xOSB0aGVuIG1vdmUgdG8gNC4xLjEz Lg0KDQpWZWFjZXNsYXYgUm9tYW4NClRlY2huaWNhbCBhbmQgSVQgZGlyZWN0b3INCk9yYW5nZSBN b2xkb3ZhIFMuQS4NCkZpeDogKzM3MzIyNTc1NDAwDQpNb2I6ICszNzM2OTE5ODQwMA0KRmF4OiAr MzczMjI1NzUzMDYNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRXJpYyBE dW1hemV0IFttYWlsdG86ZXJpYy5kdW1hemV0QGdtYWlsLmNvbV0gDQpTZW50OiBXZWRuZXNkYXks IDE4IE5vdmVtYmVyIDIwMTUgMDA6NDgNClRvOiBWZWFjZXNsYXYgUk9NQU4NCkNjOiBJbmdlbWFy IEpvaGFuc3NvbiBTOyBOZWFsIENhcmR3ZWxsOyBFcmljIER1bWF6ZXQ7IHRjcG1AaWV0Zi5vcmc7 IFBpZXJzIE8nSGFubG9uOyBTYW5ndGFlIEhhOyBlbmQyZW5kLWludGVyZXN0QHBvc3RlbC5vcmcN ClN1YmplY3Q6IFJlOiBbdGNwbV0gW2UyZV0gVENQIEh5U3RhcnQgcGF0Y2ggZGVwbG95bWVudA0K DQpPbiBUdWUsIDIwMTUtMTEtMTcgYXQgMjE6MDQgKzAwMDAsIFZlYWNlc2xhdiBST01BTiB3cm90 ZToNCj4gSGkNCj4gU3RpbGwgZXhwZXJpbWVudGluZyB3aXRoIEh5c3RhcnQgaW4gTFRFIGJ5IHRy eWluZyBkaWZmZXJlbnQgcGFyYW1ldGVycyBmb3IgSFlTVEFSVF9ERUxBWV9NSU4gYW5kIEhZU1RB UlRfREVMQVlfTUFYLg0KPiBJbiBhbiBhdHRlbXB0IHRvIGVhc3kgdGhlIHRlc3Rpbmcgd2UndmUg bW9kaWZpZWQgdGhlIDQuMS4xMCBrZXJuZWwgdG8gbWFrZSB0aGVzZSBwYXJhbWV0ZXJzIGV4dGVy bmFsbHkgbW9kaWZpYWJsZSBwbHVzIGFuIGF0dGVtcHQgaXMgZG9uZSB0byBmaXggd2hhdCBJIGRv IHBlcmNlaXZlIGFzIGEgc2lnbmlmaWNhbmQgZGV2aWF0aW9uIG9mIGltcGxlbWVudGF0aW9uIGZy b20gdGhlIG9yaWdpbmFsIGlkZWEgb2YgSHlzdGFydCwgd2hpY2gsIGluIG15IHZpZXcsIGRvZXMg aGF2ZSBhIG5lZ2F0aXZlIGltcGFjdCwgZXNwZWNpYWxseSBpbiBuZXR3b3JrcyB3aXRoIGhpZ2gg dGhyb3VnaHB1dCBhbmQgZGVsYXkgdmFyaWFiaWxpdHksIGxpa2UgcmFkaW8gbmV0d29ya3MuIA0K PiBVbmZvcnR1bmF0ZWx5IDQuMS4xMCB3YXMgdmVyeSB1bnN0YWJsZSwgc2VydmVyIGZyZXF1ZW50 bHkgZnJlZXppbmcgYW5kLCBub3QgY29tcGxldGVseSB1bnN1cmUsIHdoZXRoZXIgdGhpcyBpcyBk dWUgdG8gdGhlIGtlcm5lbCBvZiBkdWUgdG8gbW9kaWZpZWQgY29kZS4gTm8ga2VybmVsIGRldmVs b3BtZW50IGV4cGVyaWVuY2UgaGVyZS4NCj4gQW55d2F5IHdlIGRlY2lkZWQgdG8gbW92ZSB0byAz LjE5LjAtMzMgYW5kIHdlIHRyeSBjdXJyZW50bHkgdG8gcmVjb21waWxlLiANCg0Kdi00LjEuMTMg c2hvdWxkIGJlIHN0YWJsZSwgNC4xLjEwIGhhZCB0Y3AgYnVncy4NCg0KDQo= From nobody Wed Nov 18 00:48:18 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C45A1B2A39 for ; Wed, 18 Nov 2015 00:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ldRNvcyJW6b for ; Wed, 18 Nov 2015 00:48:14 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1841A008B for ; Wed, 18 Nov 2015 00:48:13 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1ZyyPT-0004DS-Oq; Wed, 18 Nov 2015 09:48:11 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1ZyyPT-0002TV-AN; Wed, 18 Nov 2015 09:48:11 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <7468519B-FFEE-4FDB-A34A-EFB5A2D736F6@iki.fi> Date: Wed, 18 Nov 2015 09:48:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7468519B-FFEE-4FDB-A34A-EFB5A2D736F6@iki.fi> To: "tcpm@ietf.org Extensions" X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 5 sum rcpts/h 13 sum msgs/h 8 total rcpts 35330 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.061, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 740E5BC34EDB4CD6C0418244C3E6A02A9F461A5C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 8448 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [tcpm] TCPM notes from IETF-94 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 18 Nov 2015 08:48:16 -0000 Hi, nit: s/what is write/what is right Else: the transcription of what David Black said to Naeem Khademi on the = mic is misleading - it misses key bits that make it seem like a = different statement than it was: The minutes say: *** David Black: RFC3168 says: don't do anything that breaks the Internet. = If there is a ECE, react to it the same way as with packet-loss. *** ... which makes it sound like this would be his advice and he would = opposed to experimental alternatives. However, what he really said is = (transcribed from Meetecho: = http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF94_TCPM&ch= apter=3Dchapter_1 at approx. 0:31): *** As one of the authors of RFC 3168: I agree that encouraging Experimental = for congestion control is a really good idea. 3168 was written for the broad internet, hence contains some very strict = language that basically said don't do anything that would break things. = We had people react to congestion if you CE-mark as if you're dropping a = packet, we said: the only thing we know for certain is safe right now - = this was a long time ago - was: react to it as you would react to a = packet drop. I'm not opposed to interesting innovative things being done = under the guise of experimentation, I wanna provide some history for why = 3168 says what it does. *** The last sentence matters - it's really quite a different thing. Cheers, Michael > On 16 Nov 2015, at 21:23, Pasi Sarolahti = wrote: >=20 > Hi, >=20 > The minutes of the Yokohama TCPM meeting are available at = https://www.ietf.org/proceedings/94/minutes/minutes-94-tcpm. Many thanks = to Christoph and David for compiling them! >=20 > If you have corrections to make, please send them to list, or directly = to chairs. >=20 > - Pasi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Nov 19 07:46:45 2015 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F4F1B2BCC; Thu, 19 Nov 2015 07:46:39 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151119154639.28566.54717.idtracker@ietfa.amsl.com> Date: Thu, 19 Nov 2015 07:46:39 -0800 Archived-At: Cc: tcpm@ietf.org, mls.ietf@gmail.com, draft-ietf-tcpm-rtorestart@ietf.org, The IESG , tcpm-chairs@ietf.org, rfc-editor@rfc-editor.org Subject: [tcpm] Document Action: 'TCP and SCTP RTO Restart' to Experimental RFC (draft-ietf-tcpm-rtorestart-10.txt) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 15:46:39 -0000 The IESG has approved the following document: - 'TCP and SCTP RTO Restart' (draft-ietf-tcpm-rtorestart-10.txt) as Experimental RFC This document is the product of the TCP Maintenance and Minor Extensions Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rtorestart/ Technical Summary This document describes a modified sender-side algorithm for managing the TCP and SCTP retransmission timers that provides faster loss recovery when there is a small amount of outstanding data for a connection. The modification, RTO Restart (RTOR), allows the transport to restart its retransmission timer so that the effective RTO becomes more aggressive in situations where fast retransmit cannot be used. This enables faster loss detection and recovery for connections that are short-lived or application-limited. Working Group Summary It is the consensus of the TCPM working group to document this alternative algorithm, given the potential performance benefit. The work has mostly been driven by the authors, but the document has been reviewed in detail by several experts and the content has been modified accordingly. Performance experiments in simulations and testbeds have been performed and published by the authors and the experimental results have been reviewed in several TCPM meetings. At the time of writing, there is only limited deployment experience. Two issues have been discussed extensively in the working group. First, any reduction of the retransmission timeout duration inherently comes along with a risk of negative impact on TCP performance, e.g. in mobile networks with highly variable RTT. The current understanding is that this risk is low and that the algorithm is conservative and relatively robust, but further experimentation has to confirm this. Second, the Linux operation system uses the "Tail Loss Probe" method discussed in Section 6, which is similar but more complex. This method was not adopted in TCPM since it depends on FACK error recovery method, which has not been standardizes so far. Document Quality This document was also last called in TSVWG, since it specifies an algorithm that can be applied both to TCP and SCTP. As a result of WGLC comments the applicability to SCTP has been better explained, including the SCTP API. One issue is that TCP and SCTP use slightly different terminology for comparable concepts. In order to keep the document simple, it was decided not to add another, duplicated description of the algorithm using SCTP terminology. Personnel The document shepherd is Michael Scharf . The responsible Area Director is Martin Stiemerling . From nobody Fri Nov 20 06:41:06 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5F31B30FA for ; Fri, 20 Nov 2015 06:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyexXSajXtX4 for ; Fri, 20 Nov 2015 06:41:02 -0800 (PST) Received: from thsbbfxrt01p.thalesgroup.com (thsbbfxrt01p.thalesgroup.com [192.54.144.131]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF10C1B30F9 for ; Fri, 20 Nov 2015 06:41:01 -0800 (PST) Received: from thsbbfxrt01p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3p2LCb4wj1z1dR for ; Fri, 20 Nov 2015 15:40:59 +0100 (CET) X-Thales-IRT1: IRT11 From: SALLANTIN Renaud To: "'tcpm@ietf.org'" , BAUDOIN Cedric Date: Fri, 20 Nov 2015 15:40:52 +0100 Thread-Topic: How to improve TCP efficiency in a large RTT context? Thread-Index: AdEjn1fyO4nagdh2S5KX0dMpsD32Rw== Message-ID: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-pmwin-version: 3.1.3.0, Antivirus-Engine: 3.60.0, Antivirus-Data: 5.21 Content-Type: multipart/alternative; boundary="_000_9b39fe7d76ff4baabe4232d2e58833a8THSONEA01HUB02Ponegrp_" MIME-Version: 1.0 Archived-At: Subject: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 20 Nov 2015 14:41:05 -0000 --_000_9b39fe7d76ff4baabe4232d2e58833a8THSONEA01HUB02Ponegrp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, With the emergence of new generation satellite systems, including mega LEO = constellations as well as very high throughput satellite offering terabit c= apacity, the problem of the end-to end performances arise again. Indeed, th= e large RTT (larger than 500ms for geo sat) is drastically downgrading regu= lar TCP performance, notably during the beginning of the connection. Curren= tly, proxies such as T-PEPs are used to minimize the RTT impact. But, their= consequences in terms of security and mobility are preventing their usage = in many cases and can't be considered as a sustainable solution. Without proxies, the most intuitive solution is therefore to increase aga= in the IW. Our studies therefore shown that IW10 is not sufficient and that= short-lived connections continue to be the most impacted. But we do believ= e that an adequate use of Pacing and a larger IW should enable to mitigate = the Long Fat Network latency. However this raises a lot of questions that = we would like to share with you: =B7 Is there room to increase even more the Initial Window? Several= major players already use IW=3D32 or higher (with and without pacing), tha= t would really help for satellite communications. But the question here is= how to mitigate the burst impact? =B7 Can we rely on SYN-SYN/ACK RTT measurement to dynamically adapt= the slow start behavior (and notably the IW size) since it's not possible= to differentiate delay due to propagation from bufferbloat at this stage ? =B7 Can we configure pacing to adapt to different networks ? Basica= lly, 1ms is generally used in SPDY and QUIC, but is there any optimal? For= example, in case of a large RTT (either due to the delay or the congestion= ), a larger pacing value (such as 5 ms) seems to offer better results. Finally, based on several discussions we had with some of you, we are consi= dering writing an Internet Draft on the "Pacing in TCP", and we would like = to know if there are some interest for this? Regards, Renaud and C=E9dric --_000_9b39fe7d76ff4baabe4232d2e58833a8THSONEA01HUB02Ponegrp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

Wi= th the emergence of new generation satellite systems, including mega LEO co= nstellations as well as very high throughput satellite offering terabit cap= acity, the problem of the end-to end performances arise again. Indeed, the = large RTT (larger than 500ms for geo sat) is drastically downgrading regula= r TCP performance, notably during the beginning of the connection. Currentl= y, proxies such as T-PEPs are used to minimize the RTT impact. But, their c= onsequences in terms of security and mobility are preventing their usage in= many cases and can’t be considered as a sustainable solution.

Without=A0 proxies,= =A0 the most intuitive solution is therefore to increase again the IW. Our = studies therefore shown that IW10 is not sufficient and that short-lived co= nnections continue to be the most impacted. But we do believe that an adequ= ate use of Pacing and a larger IW should enable to mitigate the Long Fat Ne= twork latency. However=A0 this raises a lot of questions that we would like= to share with you:

=B7   &= nbsp;     Is there room to increase even more the Initial Window? Several major = players already use IW=3D32 or higher (with and without pacing), that would= really help for satellite communications.=A0 But the question here is how = to mitigate the burst impact?

=B7 =         <= span lang=3DEN-US>Can we rely on SYN-SYN/ACK RTT measurement to dynamically= adapt the slow start behavior (and notably the IW size)=A0 since it’= s not possible to differentiate delay due to propagation from bufferbloat a= t this stage ?

=B7    =      = Can we configure pacing to adapt to different networks ? Basically, 1ms is = generally used in SPDY and QUIC, but is there any optimal?=A0 For example, = in case of a large RTT (either due to the delay or the congestion),=A0 a la= rger pacing value (such as 5 ms) seems to offer better results.<= /span>

Finally, based on several= discussions we had with some of you, we are considering writing an Interne= t Draft on the “Pacing in TCP”, and we would like to know if th= ere are some interest for this?

<= span lang=3DEN-US>Regards,

Renaud and C=E9dric

= --_000_9b39fe7d76ff4baabe4232d2e58833a8THSONEA01HUB02Ponegrp_-- From nobody Fri Nov 20 06:50:41 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4691B3156 for ; Fri, 20 Nov 2015 06:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khyc-mXOCp9d for ; Fri, 20 Nov 2015 06:50:34 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F411B3154 for ; Fri, 20 Nov 2015 06:50:34 -0800 (PST) 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 tAKEoXvG007149; Fri, 20 Nov 2015 06:50:33 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 8E8B4329551E; Fri, 20 Nov 2015 09:50:32 -0500 (EST) To: SALLANTIN Renaud From: Mark Allman In-Reply-To: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Thunderstruck MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 20 Nov 2015 09:50:32 -0500 Message-ID: <26827.1448031032@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 20 Nov 2015 14:50:39 -0000 --=-------459435943823349593450 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > =C2=B7 Is there room to increase even more the Initial Window? Several > major players already use IW=3D32 or higher I'll just flog this again: http://www.icir.org/mallman/pubs/LAJW07/ :) (I chaired TCPM when that came out. The IETF subsequently wised up and found better people. Lars was the TSV AD at the time. His comment on the above when it was presented at the workshop was something along the lines of: can we really have a TCPM chair who would propose an arbitrary IW?! I think he meant it as a joke. I took it as a compliment. :) ) But, in all seriousness, we don't need to specify the IW. Or, how it gets set. As long as the rest of CC is in place, there are consequences for being too aggressive that will keep things reasonable. IMHO. Not to mention that the actual impact of lousy choices isn't all that bad. And, of course, if we never had to discuss the IW again, that'd be cool, too. :) allman =2D- http://www.icir.org/mallman/ --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZPMzUACgkQWyrrWs4yIs6eDQCfblskKgIrD15ONCwSQbuuctaS MzIAnjgf8O8k7iwsm2qHEETlxs2IQ2PJ =mjpx -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Fri Nov 20 08:43:15 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398651B2A97 for ; Fri, 20 Nov 2015 07:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.585, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASpoQegYucBF for ; Fri, 20 Nov 2015 07:41:01 -0800 (PST) Received: from email3-east.aero.org (email3-east.aero.org [130.221.184.167]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D791B2A96 for ; Fri, 20 Nov 2015 07:41:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aero.org; i=@aero.org; q=dns/txt; s=mailhub; t=1448034061; x=1479570061; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UOdlN/1m/QJIpTnsCqOZzJ5VQrCZ+Mql9qRRP8FTflk=; b=Z23Is5tm6dQzaZYTVcLhajJ6A7g1wJhdmF9+Wq/f85dIv0XcXwbfpaFK RfEMb5ZvInr7tUSI9B0giaNtK2+wtH/CLBhwsFDJWZxTFkGRylHeUULve x5nGcbSUQj73Fm4FUqBgOvyPtL8bblEacKLKs/5tbY+wthIwR6C68u1wM s=; x-SBRS: 5.5 x-SenderGroup: Inbound_Office365 X-IronPort-AV: E=McAfee;i="5700,7163,7990"; a="1062084" X-IronPort-AV: E=Sophos;i="5.20,323,1444708800"; d="scan'208";a="1062084" X-IPAS-Result: A2G8AAApPk9Wm4ujLs9eGQEBAQEPAQEBAQYBAQEBg1RvBr8XgWUhhW4CHIFkEgEBAQEBAQEDDgEBAQEBBgsLCSEugnIBAQEBAQEBAQFMAi4+AQEBAxIBEBFFEAIBCBoCJgICAjAVEAIEAQ0FCRmIDA2hdQGBKAEcYQUoAopvAQFwkEABAQEBBgEBAQEBAR2BAYVUhH2EWRiDBIFEAQSWTI0vnEwoAYJLFgeBVnKEJgGBBgEBAQ Received: from mail-bn1lp0139.outbound.protection.outlook.com (HELO na01-bn1-obe.outbound.protection.outlook.com) ([207.46.163.139]) by email3-east.aero.org with ESMTP/TLS/AES256-SHA; 20 Nov 2015 10:40:59 -0500 Received: from DM2PR09MB0336.namprd09.prod.outlook.com (10.160.247.153) by DM2PR09MB0334.namprd09.prod.outlook.com (10.160.247.151) with Microsoft SMTP Server (TLS) id 15.1.325.17; Fri, 20 Nov 2015 15:40:58 +0000 Received: from DM2PR09MB0336.namprd09.prod.outlook.com ([10.160.247.153]) by DM2PR09MB0336.namprd09.prod.outlook.com ([10.160.247.153]) with mapi id 15.01.0325.019; Fri, 20 Nov 2015 15:40:58 +0000 From: Theodore V Faber To: "mallman@icir.org" , SALLANTIN Renaud Thread-Topic: [tcpm] How to improve TCP efficiency in a large RTT context? Thread-Index: AQHRI6LlcquGhaYVWkiia8hzcJrhQZ6khk8A Date: Fri, 20 Nov 2015 15:40:57 +0000 Message-ID: References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <26827.1448031032@lawyers.icir.org> In-Reply-To: <26827.1448031032@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=theodore.v.faber@aero.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [130.221.224.7] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0334; 5:Hnrm2I9Q4cDhCEE8p8rftk6GBcdVYDppKBrgFbV09RMKqGmBakytlVLuQyDJRRduBTZY2icukd5FZMoMPQzTk3BiTETMbYGL12W9eVFEFUCj/HQJ1/9p5uodBNs/rA/RtWu2Uo52Xz+Rxv23GoDfNA==; 24:LQpiGMmox5CJf8F9x9NjOHhT6cs1bs17QO0qJwCePqSqn4pwCAydmseLy0obCo/Z16ngzYemI6JPZJFgCjI2uns9M0Asa+THK4WuGou5yII=; 20:csefxne6GzhCAA7AMviX4WP+GsfOCl+Xx7XOULgqG+EaqGmoWPcQEXJ6nOOVuyHl6RcRff2FwBBawWKZgxIBtg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0334; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:DM2PR09MB0334; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0334; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(479174004)(24454002)(5001770100001)(40100003)(15975445007)(66066001)(2950100001)(86362001)(106356001)(2900100001)(105586002)(54356999)(106116001)(2501003)(3846002)(76176999)(19580405001)(19580395003)(92566002)(36756003)(122556002)(77096005)(99286002)(6116002)(50986999)(189998001)(102836003)(81156007)(5004730100002)(5007970100001)(97736004)(101416001)(11100500001)(586003)(5001960100002)(87936001)(5002640100001)(5001920100001)(10400500002)(5008740100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR09MB0334; H:DM2PR09MB0336.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: aero.org X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2015 15:40:57.4886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8294700-c5a4-4ca1-a876-1457d39899fd X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0334 Archived-At: X-Mailman-Approved-At: Fri, 20 Nov 2015 08:43:14 -0800 Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 20 Nov 2015 15:41:03 -0000 DQpPbiAxMS8yMC8xNSwgMDY6NTAsICJ0Y3BtIG9uIGJlaGFsZiBvZiBNYXJrIEFsbG1hbiIgPHRj cG0tYm91bmNlc0BpZXRmLm9yZw0Kb24gYmVoYWxmIG9mIG1hbGxtYW5AaWNpci5vcmc+IHdyb3Rl Og0KDQo+DQo+PiDCtyBJcyB0aGVyZSByb29tIHRvIGluY3JlYXNlIGV2ZW4gbW9yZSB0aGUgSW5p dGlhbCBXaW5kb3c/IFNldmVyYWwNCj4+IG1ham9yIHBsYXllcnMgYWxyZWFkeSB1c2UgSVc9MzIg b3IgaGlnaGVyDQo+DQo+SSdsbCBqdXN0IGZsb2cgdGhpcyBhZ2FpbjogaHR0cDovL3d3dy5pY2ly Lm9yZy9tYWxsbWFuL3B1YnMvTEFKVzA3Lw0KPg0KPjopDQo+DQo+KEkgY2hhaXJlZCBUQ1BNIHdo ZW4gdGhhdCBjYW1lIG91dC4gIFRoZSBJRVRGIHN1YnNlcXVlbnRseSB3aXNlZCB1cA0KPmFuZCBm b3VuZCBiZXR0ZXIgcGVvcGxlLg0KDQpIZXkhIEkgcmVzZW1ibGUgdGhhdCByZW1hcmshDQoNCldl bGwsIHRoZXkgZGlkIGZpbmQgYmV0dGVyIGNoYWlycywgYW55d2F5Lg0KDQo+QnV0LCBpbiBhbGwg c2VyaW91c25lc3MsIHdlIGRvbid0IG5lZWQgdG8gc3BlY2lmeSB0aGUgSVcuICBPciwgaG93DQo+ aXQgZ2V0cyBzZXQuICBBcyBsb25nIGFzIHRoZSByZXN0IG9mIENDIGlzIGluIHBsYWNlLCB0aGVy ZSBhcmUNCj5jb25zZXF1ZW5jZXMgZm9yIGJlaW5nIHRvbyBhZ2dyZXNzaXZlIHRoYXQgd2lsbCBr ZWVwIHRoaW5ncw0KPnJlYXNvbmFibGUuICBJTUhPLiAgTm90IHRvIG1lbnRpb24gdGhhdCB0aGUg YWN0dWFsIGltcGFjdCBvZiBsb3VzeQ0KPmNob2ljZXMgaXNuJ3QgYWxsIHRoYXQgYmFkLiAgQW5k LCBvZiBjb3Vyc2UsIGlmIHdlIG5ldmVyIGhhZCB0bw0KPmRpc2N1c3MgdGhlIElXIGFnYWluLCB0 aGF0J2QgYmUgY29vbCwgdG9vLiA6KQ0KDQpJ4oCZZCBhZGQgYSArMSwgYnV0IGhlcmUgb24gYSBG cmlkYXkgbW9ybmluZywgaXTigJlsbCBiZSBhbiBBbWVuISBpbnN0ZWFkLg0KDQo= From knneth@gmail.com Sun Nov 22 17:02:54 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958CC1B2BA3 for ; Sun, 22 Nov 2015 17:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHvMjcEQvf7e for ; Sun, 22 Nov 2015 17:02:53 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73C21B2BA2 for ; Sun, 22 Nov 2015 17:02:52 -0800 (PST) Received: by wmww144 with SMTP id w144so77982477wmw.1 for ; Sun, 22 Nov 2015 17:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mT5ViXBdSAEy4fScys5cPt1jy6EtjhvcLNXNwy3ynwo=; b=atp/nUP2kf+WgHMbzYpgLmlNq+WJU8dSt/HYCkVKljQPCM4zUnXIiEMSfTftekbk7p JBZO6pRSWNt1lDoIBbl1K5DtUFcygogHmPWranhLqUOKkkzDnmr0kSa7jwNPosDovSE2 EPQU+kogHkLKpKtKmvoV+fw5UQRTiUswmud5Z0Lbxt/D3MzE08DsHrFIyXLlxiBgz+9p L/gaZgbRJkYq815ocZNdlDw6xm5hGg85exHXDcBkDLa+vvSdDCyBhxlDxLE6tZiDe9kT hUrxSUvVryWsF1OTW0ZsiNLd0oClndmur0ZUFs/N1IlOnxJJTV4gA9tAS6bqy1s4jtfG kJAQ== MIME-Version: 1.0 X-Received: by 10.194.121.7 with SMTP id lg7mr9959857wjb.90.1448240571293; Sun, 22 Nov 2015 17:02:51 -0800 (PST) Sender: knneth@gmail.com Received: by 10.194.54.35 with HTTP; Sun, 22 Nov 2015 17:02:51 -0800 (PST) Date: Mon, 23 Nov 2015 02:02:51 +0100 X-Google-Sender-Auth: XSwvNARHAWmWlE6pqUT_H5U8wNA Message-ID: From: Kenneth Klette Jonassen To: Veaceslav ROMAN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: tcpm@ietf.org, Piers O'Hanlon , Sangtae Ha , Ingemar Johansson S , Eric Dumazet , end2end-interest@postel.org Subject: Re: [tcpm] [e2e] TCP HyStart patch deployment X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2015 01:04:26 -0000 On Tue, 2015-11-17 at 21:05 +0000, Veaceslav ROMAN wrote: ... > The reason for what I believed the call of hystart_update before the hyst= art_update is a big deviation from the initial logic is as follow. > Both HYSTART_ACK_TRAIN and HYSTART_DELAY algorithms in function hystart_= update are supposed to do some computing starting with the first ACK of the= train. The beginning of the train itself is determined by the function hys= tart_reset. But, because, in the current implementation the hystart_update = is called for each ACK before the hystart_reset, the first ACK of the train= N+1 is still considered in hystart_update as an ACK of the previous train = N. (in tcp_input.c: tcp_ack() -> tcp_clean_rtx_queue() -> pkts_acked()=3Db= ictcp_acked() -> hystart_update(); then tcp_input.c: tcp_ack() -> tcp_con= g_avoid() -> cong_avoid=3Dbictcp_cong_avoid() -> hystart_reset(); and, btw,= tcp_slow_start() is called next ). > Therefor HYSTART_ACK_TRAIN, in the current implementation, will not measu= re, as it was supposed in the original paper, the length of the ACK train, = but a duration between the 2-nd ACK of the train N and the first ACK of the= train N+1. This will usually result in approximately one full RTT. Due to = protection (now - ca->last_ack) <=3D hystart_ack_delta (2 ms) this would le= ad: > - in sub 2 ms RTT networks to always too early exit (in the second round) > - in over 2 ms RTT networks to always too late exit (due to = RTT > RTT/2 while now - ca->last_ack) <=3D 2 ms when the HOL ACK of N+1 ap= proaches tail ACK of N to less than 2 ms. > Means that current implementation of HYSTART_ACK_TRAIN does not work as e= xpected (did it ever ?). +1 Would you submit a patch to netdev that fixes this? It would be nice of you to fix tcp_cdg's HyStart as well. Just move the call to tcp_cdg_hystart_update() a few lines: diff --git a/net/ipv4/tcp_cdg.c b/net/ipv4/tcp_cdg.c index 167b6a3..a02d944 100644 --- a/net/ipv4/tcp_cdg.c +++ b/net/ipv4/tcp_cdg.c @@ -264,9 +264,6 @@ static void tcp_cdg_cong_avoid(struct sock *sk, u32 ack, u32 acked) u32 prior_snd_cwnd; u32 incr; - if (tcp_in_slow_start(tp) && hystart_detect) - tcp_cdg_hystart_update(sk); - if (after(ack, ca->rtt_seq) && ca->rtt.v64) { s32 grad =3D 0; @@ -282,6 +279,9 @@ static void tcp_cdg_cong_avoid(struct sock *sk, u32 ack, u32 acked) return; } + if (tcp_in_slow_start(tp) && hystart_detect) + tcp_cdg_hystart_update(sk); + if (!tcp_is_cwnd_limited(sk)) { ca->shadow_wnd =3D min(ca->shadow_wnd, tp->snd_cwnd); return; I set up a server<>client scenario with 1 sec OWD to verify. Before the change, the last ACK of each round mistakenly gets a train length of ~1 sec: 2231665.726383: tcp_cdg_cong_avoid: round 0 train_len 0 rtt_seq 1401191661 ack_seq 1401191685 sample_cnt 0 2231665.726408: tcp_cdg_cong_avoid: round 1 train_len 0 rtt_seq 1401204717 ack_seq 1401193133 sample_cnt 0 2231665.726415: tcp_cdg_cong_avoid: round 1 train_len 8 rtt_seq 1401204717 ack_seq 1401194581 sample_cnt 1 2231665.726424: tcp_cdg_cong_avoid: round 1 train_len 16 rtt_seq 1401204717 ack_seq 1401196029 sample_cnt 2 2231665.726429: tcp_cdg_cong_avoid: round 1 train_len 22 rtt_seq 1401204717 ack_seq 1401197477 sample_cnt 3 2231665.726502: tcp_cdg_cong_avoid: round 1 train_len 95 rtt_seq 1401204717 ack_seq 1401198925 sample_cnt 4 2231665.726516: tcp_cdg_cong_avoid: round 1 train_len 108 rtt_seq 1401204717 ack_seq 1401200373 sample_cnt 5 2231665.726521: tcp_cdg_cong_avoid: round 1 train_len 114 rtt_seq 1401204717 ack_seq 1401201821 sample_cnt 6 2231665.726528: tcp_cdg_cong_avoid: round 1 train_len 121 rtt_seq 1401204717 ack_seq 1401203269 sample_cnt 7 2231665.726577: tcp_cdg_cong_avoid: round 1 train_len 167 rtt_seq 1401204717 ack_seq 1401204717 sample_cnt 8 2231666.726340: tcp_cdg_cong_avoid: round 1 train_len 999932 rtt_seq 1401204717 ack_seq 1401206165 sample_cnt 8 2231666.726363: tcp_cdg_cong_avoid: round 2 train_len 0 rtt_seq 1401233677 ack_seq 1401207613 sample_cnt 0 2231666.726369: tcp_cdg_cong_avoid: round 2 train_len 6 rtt_seq 1401233677 ack_seq 1401209061 sample_cnt 1 ... After the change: 2231763.680223: tcp_cdg_cong_avoid: round 1 train_len 0 rtt_seq 4218529922 ack_seq 4218518338 sample_cnt 0 2231763.680232: tcp_cdg_cong_avoid: round 1 train_len 12 rtt_seq 4218529922 ack_seq 4218519786 sample_cnt 1 2231763.680240: tcp_cdg_cong_avoid: round 1 train_len 21 rtt_seq 4218529922 ack_seq 4218521234 sample_cnt 2 2231763.680315: tcp_cdg_cong_avoid: round 1 train_len 96 rtt_seq 4218529922 ack_seq 4218522682 sample_cnt 3 2231763.680328: tcp_cdg_cong_avoid: round 1 train_len 109 rtt_seq 4218529922 ack_seq 4218524130 sample_cnt 4 2231763.680333: tcp_cdg_cong_avoid: round 1 train_len 114 rtt_seq 4218529922 ack_seq 4218525578 sample_cnt 5 2231763.680339: tcp_cdg_cong_avoid: round 1 train_len 119 rtt_seq 4218529922 ack_seq 4218527026 sample_cnt 6 2231763.680345: tcp_cdg_cong_avoid: round 1 train_len 126 rtt_seq 4218529922 ack_seq 4218528474 sample_cnt 7 2231763.680387: tcp_cdg_cong_avoid: round 1 train_len 167 rtt_seq 4218529922 ack_seq 4218529922 sample_cnt 8 2231764.680125: tcp_cdg_cong_avoid: round 2 train_len 0 rtt_seq 4218558882 ack_seq 4218531370 sample_cnt 0 2231764.680151: tcp_cdg_cong_avoid: round 2 train_len 28 rtt_seq 4218558882 ack_seq 4218532818 sample_cnt 1 ... From nobody Mon Nov 23 02:20:05 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50F1A89A2 for ; Mon, 23 Nov 2015 02:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yJkTnnFR0K1 for ; Mon, 23 Nov 2015 02:19:57 -0800 (PST) Received: from thsbbfxrt01p.thalesgroup.com (thsbbfxrt01p.thalesgroup.com [192.54.144.131]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928501A8967 for ; Mon, 23 Nov 2015 02:19:57 -0800 (PST) Received: from thsbbfxrt01p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3p44H008wlzjN; Mon, 23 Nov 2015 11:19:56 +0100 (CET) X-Thales-IRT1: IRT11 From: BAUDOIN Cedric To: "mallman@icir.org" , SALLANTIN Renaud Date: Mon, 23 Nov 2015 11:19:49 +0100 Thread-Topic: [tcpm] How to improve TCP efficiency in a large RTT context? Thread-Index: AdEjotd0a/5M2WGuQmqMlYkWHOgMTwAA3CGQ Message-ID: References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <26827.1448031032@lawyers.icir.org> In-Reply-To: <26827.1448031032@lawyers.icir.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-pmwin-version: 3.1.3.0, Antivirus-Engine: 3.60.0, Antivirus-Data: 5.21 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2015 10:20:03 -0000 QmFzaWNhbGx5LCB3ZSBhcmUgbm90IHRyeWluZyB0byByZW9wZW4gdGhlIElXIGRlYmF0ZSA6KSBX ZSBjYW1lIHRvIHRoaXMgcXVlc3Rpb24gbW9zdGx5IGJlY2F1c2UgDQoxLSBmb3IgbG9uZyBSVFQg bGlua3MsIHRoZSBjdXJyZW50IElXIGlzIGNsZWFybHkgc3Vib3B0aW1hbA0KMi0gcGFjaW5nIHRl Y2huaXF1ZXMgYnJpbmdzIG1ham9yIGltcHJvdmVtZW50IGluIHRlcm0gb2YgYnVyc3QgaW1wYWN0 ICwgZW5hYmxpbmcgbW9yZSBhZ2dyZXNzaXZlIHNjaGVtZXMNCk91ciBuZWVkIGlzIHRvICBlbmFi bGUgdG8gYmV0dGVyIGZpbGwgdGhlIHNhdGVsbGl0ZSBwaXBlIGVzcGVjaWFsbHkgZm9yIHNob3J0 IFRDUCBmbG93cyAuDQpOb3csIHdlIHNlZSAyIHdheSBmb3J3YXJkcy4gRmlyc3QsIGFkYXB0IHRo ZSBJVyAocG9zc2libHkgb25seSBmb3IgbG9uZyBSVFQgZmxvd3MpIHRvZ2V0aGVyIHdpdGggcGFj aW5nIHRvIGltcHJvdmUgVENQIHN0YXJ0dXAgaW4gdGhpcyBjb250ZXh0LiBTZWNvbmQsIHRha2Ug YmVuZWZpdCBmcm9tIGV2ZW4gaGlnaGVyIElXIHRoYXQgc2VlbXMgYWxyZWFkeSB1c2VkIGJ5IHNv bWUgaW1wb3J0YW50IGFjdG9ycywgd2hlcmUgb25seSBwYWNpbmcgaGFzIHRvIGJlIGFkZGVkIHNv IGFzIHRvIG1pdGlnYXRlIGJ1cnN0IGltcGFjdHMgDQoNCkPDqWRyaWMNCg0KW0BAIFRIQUxFUyBB TEVOSUEgU1BBQ0UgSU5URVJOQUwgQEBdDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K RGXCoDogbWFsbG1hbkBpY2lyLm9yZyBbbWFpbHRvOm1hbGxtYW5AaWNpci5vcmddIA0KRW52b3nD qcKgOiB2ZW5kcmVkaSAyMCBub3ZlbWJyZSAyMDE1IDE1OjUxDQrDgMKgOiBTQUxMQU5USU4gUmVu YXVkDQpDY8KgOiAndGNwbUBpZXRmLm9yZyc7IEJBVURPSU4gQ2VkcmljDQpPYmpldMKgOiBSZTog W3RjcG1dIEhvdyB0byBpbXByb3ZlIFRDUCBlZmZpY2llbmN5IGluIGEgbGFyZ2UgUlRUIGNvbnRl eHQ/IA0KDQoNCj4gwrcgSXMgdGhlcmUgcm9vbSB0byBpbmNyZWFzZSBldmVuIG1vcmUgdGhlIElu aXRpYWwgV2luZG93PyBTZXZlcmFsIA0KPiBtYWpvciBwbGF5ZXJzIGFscmVhZHkgdXNlIElXPTMy IG9yIGhpZ2hlcg0KDQpJJ2xsIGp1c3QgZmxvZyB0aGlzIGFnYWluOiBodHRwOi8vd3d3LmljaXIu b3JnL21hbGxtYW4vcHVicy9MQUpXMDcvDQoNCjopDQoNCihJIGNoYWlyZWQgVENQTSB3aGVuIHRo YXQgY2FtZSBvdXQuICBUaGUgSUVURiBzdWJzZXF1ZW50bHkgd2lzZWQgdXAgYW5kIGZvdW5kIGJl dHRlciBwZW9wbGUuICBMYXJzIHdhcyB0aGUgVFNWIEFEIGF0IHRoZSB0aW1lLiAgSGlzIGNvbW1l bnQgb24gdGhlIGFib3ZlIHdoZW4gaXQgd2FzIHByZXNlbnRlZCBhdCB0aGUgd29ya3Nob3Agd2Fz IHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2Y6IGNhbiB3ZSByZWFsbHkgaGF2ZSBhIFRDUE0g Y2hhaXIgd2hvIHdvdWxkIHByb3Bvc2UgYW4gYXJiaXRyYXJ5IElXPyEgIEkgdGhpbmsgaGUgbWVh bnQgaXQgYXMgYSBqb2tlLiAgSSB0b29rIGl0IGFzIGEgY29tcGxpbWVudC4gOikgKQ0KDQpCdXQs IGluIGFsbCBzZXJpb3VzbmVzcywgd2UgZG9uJ3QgbmVlZCB0byBzcGVjaWZ5IHRoZSBJVy4gIE9y LCBob3cgaXQgZ2V0cyBzZXQuICBBcyBsb25nIGFzIHRoZSByZXN0IG9mIENDIGlzIGluIHBsYWNl LCB0aGVyZSBhcmUgY29uc2VxdWVuY2VzIGZvciBiZWluZyB0b28gYWdncmVzc2l2ZSB0aGF0IHdp bGwga2VlcCB0aGluZ3MgcmVhc29uYWJsZS4gIElNSE8uICBOb3QgdG8gbWVudGlvbiB0aGF0IHRo ZSBhY3R1YWwgaW1wYWN0IG9mIGxvdXN5IGNob2ljZXMgaXNuJ3QgYWxsIHRoYXQgYmFkLiAgQW5k LCBvZiBjb3Vyc2UsIGlmIHdlIG5ldmVyIGhhZCB0byBkaXNjdXNzIHRoZSBJVyBhZ2FpbiwgdGhh dCdkIGJlIGNvb2wsIHRvby4gOikNCg0KYWxsbWFuDQoNCg0KLS0NCmh0dHA6Ly93d3cuaWNpci5v cmcvbWFsbG1hbi8NCg0KDQoNCg== From nobody Mon Nov 23 03:48:15 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 239AC1B31EB for ; Mon, 23 Nov 2015 03:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.486 X-Spam-Level: X-Spam-Status: No, score=-7.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qsgllmQPEVH for ; Mon, 23 Nov 2015 03:48:13 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947891B31E9 for ; Mon, 23 Nov 2015 03:48:13 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 46B1AD775B3A6; Mon, 23 Nov 2015 11:48:09 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tANBmATl011707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Nov 2015 12:48:10 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 23 Nov 2015 12:48:10 +0100 From: "De Schepper, Koen (Koen)" To: Rui Paulo , Pasi Sarolahti Thread-Topic: [tcpm] Adoption of More Accurate ECN Feedback in TCP Thread-Index: AQHRIKry8m8GtkZEskuv6LNk3IfcJ56fGBwAgApt17A= Date: Mon, 23 Nov 2015 11:48:09 +0000 Message-ID: References: <7B4EF8CB-5DEF-4FCD-A970-362885921FD5@apple.com> In-Reply-To: <7B4EF8CB-5DEF-4FCD-A970-362885921FD5@apple.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] Adoption of More Accurate ECN Feedback in TCP X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2015 11:48:15 -0000 > -----Original Message----- > From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Rui Paulo > Sent: maandag 16 november 2015 22:24 > To: Pasi Sarolahti > Cc: tcpm@ietf.org Extensions > Subject: Re: [tcpm] Adoption of More Accurate ECN Feedback in TCP >=20 > On Nov 16, 2015, at 12:11, Pasi Sarolahti wrote: > > > > Hi, > > > > In the Yokohama meeting we discussed adoption of "More Accurate ECN > Feedback in TCP" as Experimental RFC, with draft-kuehlewind-tcpm- > accurate-ecn-05 serving as the baseline for the working group draft. We > called a hum in the meeting that very strongly supported adoption of the > document. > > > > The chairs would now want to confirm the adoption call on the list. > Please let us know by Friday, November 27 whether you support or object > adoption of the document. > > > > The proposed milestone is "Submit specification of more accurate ECN > feedback in TCP to the IESG for publication as an Experimental RFC" - > dated for Aug 2016. >=20 > Support. >=20 +1 Standardization of support for a more frequent (multiple per RTT) ECN=20 feedback is important to further evolve (TCP) congestion control wrt throug= hput=20 scalability and low latency! Koen. > -- > Rui Paulo >=20 >=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Nov 23 08:04:24 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB6A91A891C for ; Mon, 23 Nov 2015 08:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvOW80aW1cUy for ; Mon, 23 Nov 2015 08:04:20 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE561A88F1 for ; Mon, 23 Nov 2015 08:04:20 -0800 (PST) Received: by ykba77 with SMTP id a77so241389909ykb.2 for ; Mon, 23 Nov 2015 08:04:19 -0800 (PST) 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; bh=wrCOVffoV+DeYlQN4t/wuqwiQwm0BwtfGwScQMMwoTA=; b=EDnSG5X2esCnAI6m8Z2SU+Ipv6aAEP38rRcEQjgny0KPkFQ3emz0lLW5VdMoLd20vv GQmTMNchmV31Ia4GZBZhRHQ6u5lCAjzlt/KmkF+kYjV7rWhIEYV3fxUe0/dM0l3Bwr+p V7bIQBdShc8xWQeX/XzYjmTvnAKlly44KWdn9c8rYF3TPuFAyR0DU3hk0d9q7m+ssaMs ubCvwf//LNkt+hDJPcPe6DWNRl8MTQOiaKB397NqSCdEBGoJQ2gjj4VXPNS7fWV0DE7I pQKjOflJrcDOvJnFetoFhz6xFMv4vnEuU3A1Re5mZbbLLZ7GEm4+cTZdmMAWMS9UfQ6w HHlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wrCOVffoV+DeYlQN4t/wuqwiQwm0BwtfGwScQMMwoTA=; b=dvb3htqGTGSrz/Jn0dPVIZFW09q5Gd7O9+qVnSfiwMlKmvC+ItmyL8LEzBCDyZ0e7B psht3oI5RUCqcVZzTWP8oJxv7hc7oViPJiYAO2BMewJZpBIeesIfmofbWxK6Sz+HnlRR /zel4D7JWerM8RCjwfk5OfYTKv1fSbvftpM2drf2FxAdjgpPvC0d9by97aT6NvpfILWF OVnSNjWWlUggwrMbnLDFWH7L+x0PfeBzSZ27+q7gxgSArqM/iikVAoQqTDe0M1I9i6Ib M3vgMmzc1ldfdWPldJEIvC8qH0ddaGoh21IAjWdCggZPJTVtHLHzEgUyg9o4LSZUCU5D GegA== X-Gm-Message-State: ALoCoQnhPfPP684To+V8EqmZyPZqxffld9cbpWVFbtEKkO1elih6Hm3Kf7FUf3nX8mDFDbY9nicb MIME-Version: 1.0 X-Received: by 10.129.97.87 with SMTP id v84mr16687527ywb.236.1448294659589; Mon, 23 Nov 2015 08:04:19 -0800 (PST) Received: by 10.129.132.18 with HTTP; Mon, 23 Nov 2015 08:04:19 -0800 (PST) In-Reply-To: References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <26827.1448031032@lawyers.icir.org> Date: Mon, 23 Nov 2015 11:04:19 -0500 Message-ID: From: Neal Cardwell To: BAUDOIN Cedric Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org" , Eric Dumazet , "mallman@icir.org" Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2015 16:04:23 -0000 On Mon, Nov 23, 2015 at 5:19 AM, BAUDOIN Cedric wrote: > Basically, we are not trying to reopen the IW debate :) We came to this q= uestion mostly because > 1- for long RTT links, the current IW is clearly suboptimal > 2- pacing techniques brings major improvement in term of burst impact , e= nabling more aggressive schemes > Our need is to enable to better fill the satellite pipe especially for s= hort TCP flows . What sorts of IW and pacing rate values are needed to achieve acceptable performance in the satellite systems you are concerned about? >From my perspective, one concern is that using a much bigger IW or default pacing rate value can create scenarios where either the server or client is vulnerable to DoS. Even if the larger IW or pacing rate are only enabled for high RTTs, eg > 500ms. For example, suppose a server sees a 500ms RTT and decides to use a larger IW or pacing rate... what if the 500ms was due not to a large propagation delay from a satellite link, but rather a low-bandwidth, congested, or bufferbloated bottleneck? Then the higher IW and pacing rate are pouring gasoline on a fire. BTW, if you are considering writing an Internet Draft on =E2=80=9CPacing in TCP", make sure you include the Linux TCP pacing work done by Eric Dumazet, which is widely deployed (e.g. on google.com and youtube.com): https://lwn.net/Articles/564978/ https://www.ietf.org/proceedings/88/slides/slides-88-tcpm-9.pdf neal From nobody Mon Nov 23 08:13:19 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39B41A899B for ; Mon, 23 Nov 2015 08:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXV55zL6dcos for ; Mon, 23 Nov 2015 08:13:16 -0800 (PST) Received: from thsbbfxrt02p.thalesgroup.com (thsbbfxrt02p.thalesgroup.com [192.93.158.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32191A8997 for ; Mon, 23 Nov 2015 08:13:15 -0800 (PST) Received: from thsbbfxrt02p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3p4D6d3R6bz7H; Mon, 23 Nov 2015 17:13:13 +0100 (CET) X-Thales-IRT1: IRT11 From: SALLANTIN Renaud To: Neal Cardwell , BAUDOIN Cedric Date: Mon, 23 Nov 2015 17:13:09 +0100 Thread-Topic: [tcpm] How to improve TCP efficiency in a large RTT context? Thread-Index: AdEmCJ3e15VTBCWdTr2RWXB8WGACpAAAD7uA Message-ID: References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <26827.1448031032@lawyers.icir.org> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-pmwin-version: 3.1.3.0, Antivirus-Engine: 3.60.0, Antivirus-Data: 5.21 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Eric Dumazet , "tcpm@ietf.org" , "mallman@icir.org" Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2015 16:13:18 -0000 SSB0b3RhbGx5IGFncmVlIHdpdGggdGhlIGZhY3QgdGhhdCBlbmxhcmdpbmcgdGhlIElXIGlzIGRh bmdlcm91cyBpbiB0aGUgc2l0dWF0aW9uIHlvdSBkZXNjcmliZWQuIEJ1dCBJIGRvbid0IHNlZSB3 aGF0IGNvdWxkIGJlIHRoZSByZXBlcmN1c3Npb25zIG9mIGluY3JlYXNpbmcgdGhlIHBhY2luZyBy YXRlPyANCg0KSWYgdGhlIGxhcmdlIFJUVCBpcyBkdWUgdG8gdGhlIHByb3BhZ2F0aW9uIGRlbGF5 LCBhbmQgbm90IHRoZSBjb25nZXN0aW9uLCB5b3Ugd2lsbCBpbmRlZWQgYWRkIGFuIHVubmVjZXNz YXJ5IGRlbGF5IChkZXBlbmRpbmcgb24geW91ciBJVyBzaXplIGFuZCBwYWNpbmcgcmF0ZSkuIEJ1 dCwgaW4gdGhlIG90aGVyIGNhc2UsIHlvdSB3aWxsIHByb2JhYmx5IGxvd2VyIHRoZSBjb25zZXF1 ZW5jZXMgb2YgdGhlIGNvbmdlc3Rpb24gb24gdGhlIHNlZ21lbnRzIHlvdSBzZW50Li4uDQoNCg0K UFM6IGRvbid0IHdvcnJ5LCB3ZSBrbm93IGFuZCBhcHByZWNpYXRlIEVyaWMncyB3b3JrIG9uIHRo ZSBwYWNpbmcgOy0pDQoNCltAQCBUSEFMRVMgQUxFTklBIFNQQUNFIElOVEVSTkFMIEBAXQ0KDQoN Ci0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogTmVhbCBDYXJkd2VsbCBbbWFpbHRv Om5jYXJkd2VsbEBnb29nbGUuY29tXSANCkVudm95w6nCoDogbHVuZGkgMjMgbm92ZW1icmUgMjAx NSAxNzowNA0Kw4DCoDogQkFVRE9JTiBDZWRyaWMNCkNjwqA6IG1hbGxtYW5AaWNpci5vcmc7IFNB TExBTlRJTiBSZW5hdWQ7IHRjcG1AaWV0Zi5vcmc7IFl1Y2h1bmcgQ2hlbmc7IEVyaWMgRHVtYXpl dA0KT2JqZXTCoDogUmU6IFt0Y3BtXSBIb3cgdG8gaW1wcm92ZSBUQ1AgZWZmaWNpZW5jeSBpbiBh IGxhcmdlIFJUVCBjb250ZXh0Pw0KDQpPbiBNb24sIE5vdiAyMywgMjAxNSBhdCA1OjE5IEFNLCBC QVVET0lOIENlZHJpYyA8Y2VkcmljLmJhdWRvaW5AdGhhbGVzYWxlbmlhc3BhY2UuY29tPiB3cm90 ZToNCj4gQmFzaWNhbGx5LCB3ZSBhcmUgbm90IHRyeWluZyB0byByZW9wZW4gdGhlIElXIGRlYmF0 ZSA6KSBXZSBjYW1lIHRvIA0KPiB0aGlzIHF1ZXN0aW9uIG1vc3RseSBiZWNhdXNlDQo+IDEtIGZv ciBsb25nIFJUVCBsaW5rcywgdGhlIGN1cnJlbnQgSVcgaXMgY2xlYXJseSBzdWJvcHRpbWFsDQo+ IDItIHBhY2luZyB0ZWNobmlxdWVzIGJyaW5ncyBtYWpvciBpbXByb3ZlbWVudCBpbiB0ZXJtIG9m IGJ1cnN0IGltcGFjdCANCj4gLCBlbmFibGluZyBtb3JlIGFnZ3Jlc3NpdmUgc2NoZW1lcyBPdXIg bmVlZCBpcyB0byAgZW5hYmxlIHRvIGJldHRlciBmaWxsIHRoZSBzYXRlbGxpdGUgcGlwZSBlc3Bl Y2lhbGx5IGZvciBzaG9ydCBUQ1AgZmxvd3MgLg0KDQpXaGF0IHNvcnRzIG9mIElXIGFuZCBwYWNp bmcgcmF0ZSB2YWx1ZXMgYXJlIG5lZWRlZCB0byBhY2hpZXZlIGFjY2VwdGFibGUgcGVyZm9ybWFu Y2UgaW4gdGhlIHNhdGVsbGl0ZSBzeXN0ZW1zIHlvdSBhcmUgY29uY2VybmVkIGFib3V0Pw0KDQpG cm9tIG15IHBlcnNwZWN0aXZlLCBvbmUgY29uY2VybiBpcyB0aGF0IHVzaW5nIGEgbXVjaCBiaWdn ZXIgSVcgb3IgZGVmYXVsdCBwYWNpbmcgcmF0ZSB2YWx1ZSBjYW4gY3JlYXRlIHNjZW5hcmlvcyB3 aGVyZSBlaXRoZXIgdGhlIHNlcnZlciBvciBjbGllbnQgaXMgdnVsbmVyYWJsZSB0byBEb1MuIEV2 ZW4gaWYgdGhlIGxhcmdlciBJVyBvciBwYWNpbmcgcmF0ZSBhcmUgb25seSBlbmFibGVkIGZvciBo aWdoIFJUVHMsIGVnID4gNTAwbXMuIEZvciBleGFtcGxlLCBzdXBwb3NlIGEgc2VydmVyIHNlZXMg YSA1MDBtcyBSVFQgYW5kIGRlY2lkZXMgdG8gdXNlIGEgbGFyZ2VyIElXIG9yIHBhY2luZyByYXRl Li4uIHdoYXQgaWYgdGhlIDUwMG1zIHdhcyBkdWUgbm90IHRvIGEgbGFyZ2UgcHJvcGFnYXRpb24g ZGVsYXkgZnJvbSBhIHNhdGVsbGl0ZSBsaW5rLCBidXQgcmF0aGVyIGEgbG93LWJhbmR3aWR0aCwg Y29uZ2VzdGVkLCBvciBidWZmZXJibG9hdGVkIGJvdHRsZW5lY2s/IFRoZW4gdGhlIGhpZ2hlciBJ VyBhbmQgcGFjaW5nIHJhdGUgYXJlIHBvdXJpbmcgZ2Fzb2xpbmUgb24gYSBmaXJlLg0KDQpCVFcs IGlmIHlvdSBhcmUgY29uc2lkZXJpbmcgd3JpdGluZyBhbiBJbnRlcm5ldCBEcmFmdCBvbiDigJxQ YWNpbmcgaW4gVENQIiwgbWFrZSBzdXJlIHlvdSBpbmNsdWRlIHRoZSBMaW51eCBUQ1AgcGFjaW5n IHdvcmsgZG9uZSBieSBFcmljIER1bWF6ZXQsIHdoaWNoIGlzIHdpZGVseSBkZXBsb3llZCAoZS5n LiBvbiBnb29nbGUuY29tIGFuZA0KeW91dHViZS5jb20pOg0KDQogIGh0dHBzOi8vbHduLm5ldC9B cnRpY2xlcy81NjQ5NzgvDQogIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg4L3Ns aWRlcy9zbGlkZXMtODgtdGNwbS05LnBkZg0KDQpuZWFsDQo= From nobody Mon Nov 23 14:34:23 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357461ACE44 for ; Mon, 23 Nov 2015 14:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTHvmVl5RfeW for ; Mon, 23 Nov 2015 14:34:20 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888481ACE30 for ; Mon, 23 Nov 2015 14:34:20 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id tANMXt8v014871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Nov 2015 14:33:56 -0800 (PST) To: SALLANTIN Renaud , Neal Cardwell , BAUDOIN Cedric References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <26827.1448031032@lawyers.icir.org> From: Joe Touch Message-ID: <56539453.1020504@isi.edu> Date: Mon, 23 Nov 2015 14:33:55 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-MailScanner-ID: tANMXt8v014871 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Eric Dumazet , "tcpm@ietf.org" , "mallman@icir.org" , touch@isi.edu Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2015 22:34:22 -0000 On 11/23/2015 8:13 AM, SALLANTIN Renaud wrote: > I totally agree with the fact that enlarging the IW is dangerous in > the situation you described. But I don't see what could be the > repercussions of increasing the pacing rate? > > If the large RTT is due to the propagation delay, and not the > congestion, you will indeed add an unnecessary delay (depending on your > IW size and pacing rate). But, in the other case, you will probably > lower the consequences of the congestion on the segments you sent... If the large RTT is propagation delay, then increasing the IW is exactly the right answer, though you do want to pace the data out as well. 2140 TCB parameter reuse ought to fix the RTT issue, as well as pacing if pacing is implemented and part of the set of parameters reused across connections. Joe > > > PS: don't worry, we know and appreciate Eric's work on the pacing ;-) > > [@@ THALES ALENIA SPACE INTERNAL @@] > > > -----Message d'origine----- > De : Neal Cardwell [mailto:ncardwell@google.com] > Envoyé : lundi 23 novembre 2015 17:04 > À : BAUDOIN Cedric > Cc : mallman@icir.org; SALLANTIN Renaud; tcpm@ietf.org; Yuchung Cheng; Eric Dumazet > Objet : Re: [tcpm] How to improve TCP efficiency in a large RTT context? > > On Mon, Nov 23, 2015 at 5:19 AM, BAUDOIN Cedric wrote: >> Basically, we are not trying to reopen the IW debate :) We came to >> this question mostly because >> 1- for long RTT links, the current IW is clearly suboptimal >> 2- pacing techniques brings major improvement in term of burst impact >> , enabling more aggressive schemes Our need is to enable to better fill the satellite pipe especially for short TCP flows . > > What sorts of IW and pacing rate values are needed to achieve acceptable performance in the satellite systems you are concerned about? > >>From my perspective, one concern is that using a much bigger IW or default pacing rate value can create scenarios where either the server or client is vulnerable to DoS. Even if the larger IW or pacing rate are only enabled for high RTTs, eg > 500ms. For example, suppose a server sees a 500ms RTT and decides to use a larger IW or pacing rate... what if the 500ms was due not to a large propagation delay from a satellite link, but rather a low-bandwidth, congested, or bufferbloated bottleneck? Then the higher IW and pacing rate are pouring gasoline on a fire. > > BTW, if you are considering writing an Internet Draft on “Pacing in TCP", make sure you include the Linux TCP pacing work done by Eric Dumazet, which is widely deployed (e.g. on google.com and > youtube.com): > > https://lwn.net/Articles/564978/ > https://www.ietf.org/proceedings/88/slides/slides-88-tcpm-9.pdf > > neal > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Mon Nov 23 14:57:34 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AC01ACED3 for ; Mon, 23 Nov 2015 14:57:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj8YUvEJzmBR for ; Mon, 23 Nov 2015 14:57:31 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCEB41ACED2 for ; Mon, 23 Nov 2015 14:57:30 -0800 (PST) Received: by vkay187 with SMTP id y187so48919824vka.3 for ; Mon, 23 Nov 2015 14:57:30 -0800 (PST) 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:content-transfer-encoding; bh=vuUG61AA62Tn1VsoTOgM5RRwdvImyLQBzsamK1TL9uE=; b=ZTpr+5fD48uZEeP+lMcg2+qnRqXzSVrAYM01JSA5DetZGy6VSdbiunceBoKnopVgH6 HdraKuPFyqY5Vid2jMT5/ce2NB4T81g9uRn+FykOX4nowyguTupGQTP7Llb0tab4teoR AG/eJzqkzNbgy0BGreFTSb71JRj95aqSIBVrOGWTnYfvpjYb/ci6440/kq730Su7tbAG fWPjxyf56URUToSYlsqKluvo6LsNpJp+9u+uMaYcRSl/0OSO4MADjrWaye8/QZfgBuwO btDSIOBpPtYe7JehLszXbH/RhQpUmmA12SkmzgTLWdmnSrcAo1eRQImpdCHffrKx6gZg vwfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=vuUG61AA62Tn1VsoTOgM5RRwdvImyLQBzsamK1TL9uE=; b=SU/RKmEmkA1US743f0yJQBWmeCe6aJydvgdb5zdHoyczNk+XXhpgo1G0KIzS/fTraJ 8s49HCAArGYsbkMvxlvMV1lQcfONpZ3Ubbf2DMXLKVPJ0uJ9KUnVcARYxOWyTL2oFv0c zHLKap6QFfAalvuEf/ddN9421OhtormQCu3oH36F984+Ln1VpdUB0Iblte99/xT/17VW R1ExMTc7QSRXE5lYQRczHWcPImENXz4n0jqwLz7Z4OJ7TQ9wxV5I/i/ykrEfIh1225Fo NEFZJv8PYezbNqsfOzOkJqTqYCaWbWTsVoeoDsMzD1d//RhMCSfKGxibQWtByi6azLDS k4Jw== X-Gm-Message-State: ALoCoQk4sGT84T5VsdZlLCTFhqdell+Mv/6Jz/FrbeA6JWgci0HG6n1IEltKNOWp3AY8q9tspHUr X-Received: by 10.31.34.198 with SMTP id i189mr22011025vki.111.1448319449897; Mon, 23 Nov 2015 14:57:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.189.19 with HTTP; Mon, 23 Nov 2015 14:56:50 -0800 (PST) In-Reply-To: <56539453.1020504@isi.edu> References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <26827.1448031032@lawyers.icir.org> <56539453.1020504@isi.edu> From: Yuchung Cheng Date: Mon, 23 Nov 2015 14:56:50 -0800 Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tcpm@ietf.org" , "mallman@icir.org" , Eric Dumazet Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2015 22:57:33 -0000 On Mon, Nov 23, 2015 at 2:33 PM, Joe Touch wrote: > > > On 11/23/2015 8:13 AM, SALLANTIN Renaud wrote: >> I totally agree with the fact that enlarging the IW is dangerous in >> the situation you described. But I don't see what could be the >> repercussions of increasing the pacing rate? >> >> If the large RTT is due to the propagation delay, and not the >> congestion, you will indeed add an unnecessary delay (depending on your >> IW size and pacing rate). But, in the other case, you will probably >> lower the consequences of the congestion on the segments you sent... > > If the large RTT is propagation delay, then increasing the IW is exactly > the right answer, though you do want to pace the data out as well. right. the key issue is no easy way to reasonably verify if it's prop delay or cong or something else. > > 2140 TCB parameter reuse ought to fix the RTT issue, as well as pacing > if pacing is implemented and part of the set of parameters reused across > connections. > > Joe > > > > >> >> >> PS: don't worry, we know and appreciate Eric's work on the pacing ;-) >> >> [@@ THALES ALENIA SPACE INTERNAL @@] >> >> >> -----Message d'origine----- >> De : Neal Cardwell [mailto:ncardwell@google.com] >> Envoy=C3=A9 : lundi 23 novembre 2015 17:04 >> =C3=80 : BAUDOIN Cedric >> Cc : mallman@icir.org; SALLANTIN Renaud; tcpm@ietf.org; Yuchung Cheng; E= ric Dumazet >> Objet : Re: [tcpm] How to improve TCP efficiency in a large RTT context? >> >> On Mon, Nov 23, 2015 at 5:19 AM, BAUDOIN Cedric wrote: >>> Basically, we are not trying to reopen the IW debate :) We came to >>> this question mostly because >>> 1- for long RTT links, the current IW is clearly suboptimal >>> 2- pacing techniques brings major improvement in term of burst impact >>> , enabling more aggressive schemes Our need is to enable to better fil= l the satellite pipe especially for short TCP flows . >> >> What sorts of IW and pacing rate values are needed to achieve acceptable= performance in the satellite systems you are concerned about? >> >>>From my perspective, one concern is that using a much bigger IW or defau= lt pacing rate value can create scenarios where either the server or client= is vulnerable to DoS. Even if the larger IW or pacing rate are only enable= d for high RTTs, eg > 500ms. For example, suppose a server sees a 500ms RTT= and decides to use a larger IW or pacing rate... what if the 500ms was due= not to a large propagation delay from a satellite link, but rather a low-b= andwidth, congested, or bufferbloated bottleneck? Then the higher IW and pa= cing rate are pouring gasoline on a fire. >> >> BTW, if you are considering writing an Internet Draft on =E2=80=9CPacing= in TCP", make sure you include the Linux TCP pacing work done by Eric Duma= zet, which is widely deployed (e.g. on google.com and >> youtube.com): >> >> https://lwn.net/Articles/564978/ >> https://www.ietf.org/proceedings/88/slides/slides-88-tcpm-9.pdf >> >> neal >> _______________________________________________ >> 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 nobody Mon Nov 23 15:02:30 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3D41ACEF0 for ; Mon, 23 Nov 2015 15:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.485 X-Spam-Level: X-Spam-Status: No, score=-7.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC83QEWFmnCB for ; Mon, 23 Nov 2015 15:02:28 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31211ACEEB for ; Mon, 23 Nov 2015 15:02:28 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tANN1xoJ007496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 23 Nov 2015 15:02:00 -0800 (PST) To: Yuchung Cheng References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <26827.1448031032@lawyers.icir.org> <56539453.1020504@isi.edu> From: Joe Touch Message-ID: <56539AE7.4010008@isi.edu> Date: Mon, 23 Nov 2015 15:01:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "tcpm@ietf.org" , touch@isi.edu, "mallman@icir.org" , Eric Dumazet Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 23 Nov 2015 23:02:30 -0000 On 11/23/2015 2:56 PM, Yuchung Cheng wrote: > On Mon, Nov 23, 2015 at 2:33 PM, Joe Touch wrote: >> >> >> On 11/23/2015 8:13 AM, SALLANTIN Renaud wrote: >>> I totally agree with the fact that enlarging the IW is dangerous in >>> the situation you described. But I don't see what could be the >>> repercussions of increasing the pacing rate? >>> >>> If the large RTT is due to the propagation delay, and not the >>> congestion, you will indeed add an unnecessary delay (depending on your >>> IW size and pacing rate). But, in the other case, you will probably >>> lower the consequences of the congestion on the segments you sent... >> >> If the large RTT is propagation delay, then increasing the IW is exactly >> the right answer, though you do want to pace the data out as well. > > right. the key issue is no easy way to reasonably verify if it's prop > delay or cong or something else. We ought to be able to trust that congestion will result in loss. If it's just queuing delay and it's persistent, then it can be treated exactly the same as propagation delay. I.e., RED (or BLUE, or ALTQ, CODEL, etc.) ought to do the right thing here, but in the absence of other information, TCP ought to treat delay as delay. Joe From nobody Tue Nov 24 08:00:06 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7361A8A3B for ; Tue, 24 Nov 2015 08:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V1NgUNQUsIb for ; Tue, 24 Nov 2015 08:00:03 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731BD1A86F2 for ; Tue, 24 Nov 2015 08:00:03 -0800 (PST) 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 tAOG009E015440; Tue, 24 Nov 2015 08:00:01 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 3B2DA32DD7D7; Tue, 24 Nov 2015 11:00:00 -0500 (EST) To: SALLANTIN Renaud From: Mark Allman In-Reply-To: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Heavy Fuel X-URL-0: http://www.icir.org/mallman-files/Document87192.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 24 Nov 2015 11:00:00 -0500 Message-ID: <54296.1448380800@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 24 Nov 2015 16:00:05 -0000 --=-------459435943823349593450 Content-Type: text/plain I haven't been tracking things very closely... > Several major players already use IW=32 or higher (with and > without pacing), Is this well known? Could you point me to the results? (I am just interested.) allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZUiX0ACgkQWyrrWs4yIs6ipwCeOGIaB+vNkuHbLEMryCw8segh kPQAoJlIHNxwvLnWFoyuWt/8GbJUK7Em =SQc6 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Tue Nov 24 08:05:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4351A8ABD for ; Tue, 24 Nov 2015 08:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvSB7AQpjFs1 for ; Tue, 24 Nov 2015 08:05:37 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21E811A8ABF for ; Tue, 24 Nov 2015 08:05:37 -0800 (PST) Received: by ykfs79 with SMTP id s79so23874581ykf.1 for ; Tue, 24 Nov 2015 08:05:36 -0800 (PST) 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; bh=QTABzv4S3i3XZO7SgoqBgdiFfCRltvD/u3aznqjbyoU=; b=DTu/1AR2UoGnsrRsxF21f2NehD7JeGQR7oZBBNQHVCubae+PF1X6geVXjDoeNCVLwp Jpj+zVBnPHclFR4j6LygqS7TMeMhYigtisdPnd2PvkiBTiEyK1fqKrIRWXIlfj9WrhsJ Hyj6o2kedWy9sfBSpn6i/o6lSv8ctlEnusAsMjmhK3sN6+WiLtHwCkC427ItJ0wDst2K VXHiDhKdi/uORYPbBMxSQkYEr3mNii7kB2Ob7rzrrrCIshL2LIteWCaIR/N2EehbBw0x jvzMi7O+SQYyY2Zl+rGhs5aSNQI0gEyQXu87x2A+fPqF5SKXMn9QFEozj+3KH/X3EI3h ngDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QTABzv4S3i3XZO7SgoqBgdiFfCRltvD/u3aznqjbyoU=; b=Vpsh2XgU6XmE8RO7v2a+L1PXeDWDOEnMNLevGO8Utm+ODbpFhDQnHLmfzk/4rRo+3m eFzQ8+cJyw9FCEQTi3WNn4myUmNrzO/uZ2hMHi93JWD0lPIFpiofg8UePGLPYBssLdRf nsxPLWscqnBIJ57N/zHdfQjoRxLdY1psRkOFbAD2qe2LYxD1tPPa3Et2DUklnAhxuq8j DSqlA2dU36anVmOME+FlxJY/JSCfsOBOcmy6DFwLDf0X8+AQylygbUJ6E7lZ9hNTn+ZP 1J3BaSHtdwv8PcRT7pA97tsXTiZL0Igo0ReFVlERzKvISg9k8T7S0Xzq8tGinIwvGTwb WRpQ== X-Gm-Message-State: ALoCoQlL3GErfxQKW45ZXA+ZC7j7fOR35fX+jBeYgs1GfZHKDyvYjFySWAG9EWw9UZhuL4JmAQBJ MIME-Version: 1.0 X-Received: by 10.129.153.135 with SMTP id q129mr32301786ywg.15.1448381136281; Tue, 24 Nov 2015 08:05:36 -0800 (PST) Received: by 10.129.132.18 with HTTP; Tue, 24 Nov 2015 08:05:36 -0800 (PST) In-Reply-To: <54296.1448380800@lawyers.icir.org> References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <54296.1448380800@lawyers.icir.org> Date: Tue, 24 Nov 2015 11:05:36 -0500 Message-ID: From: Neal Cardwell To: Mark Allman Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2015 16:05:38 -0000 On Tue, Nov 24, 2015 at 11:00 AM, Mark Allman wrote: > > I haven't been tracking things very closely... > >> Several major players already use IW=32 or higher (with and >> without pacing), > > Is this well known? Could you point me to the results? (I am just > interested.) Here is one such study: http://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/ neal From nobody Tue Nov 24 08:10:25 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C391A8AC5 for ; Tue, 24 Nov 2015 08:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-HjhbJ_mZ0y for ; Tue, 24 Nov 2015 08:10:22 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B9D21A8A9D for ; Tue, 24 Nov 2015 08:10:21 -0800 (PST) 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 tAOGAJNK017052; Tue, 24 Nov 2015 08:10:19 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 1630A32DDC27; Tue, 24 Nov 2015 11:10:19 -0500 (EST) To: Neal Cardwell From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Heavy Fuel MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 24 Nov 2015 11:10:19 -0500 Message-ID: <56383.1448381419@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 24 Nov 2015 16:10:24 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Here is one such study: >=20 > http://www.cdnplanet.com/blog/initcwnd-settings-major-cdn-providers/ cool! thanks! --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZUi+oACgkQWyrrWs4yIs4zlQCeMsRXUBdDDiy7q79++7b2tN/r 570AoIv2Md0c3q8vcnzEpGsHcBzvUQzB =+zqt -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Tue Nov 24 08:14:07 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B111A1A88D2 for ; Tue, 24 Nov 2015 08:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QwVxdj6rQhp for ; Tue, 24 Nov 2015 08:14:03 -0800 (PST) Received: from thsbbfxrt02p.thalesgroup.com (thsbbfxrt02p.thalesgroup.com [192.93.158.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC6F1A889C for ; Tue, 24 Nov 2015 08:14:02 -0800 (PST) Received: from thsbbfxrt02p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3p4r552k9Fz1b6; Tue, 24 Nov 2015 17:14:01 +0100 (CET) X-Thales-IRT1: IRT11 From: SALLANTIN Renaud To: 'Neal Cardwell' , 'Mark Allman' Date: Tue, 24 Nov 2015 17:13:59 +0100 Thread-Topic: [tcpm] How to improve TCP efficiency in a large RTT context? Thread-Index: AdEm0fV1RjqOx1cSR2W8tOVsci+aPgAAP7EA Message-ID: References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <54296.1448380800@lawyers.icir.org> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-pmwin-version: 3.1.3.0, Antivirus-Engine: 3.60.0, Antivirus-Data: 5.21 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2015 16:14:04 -0000 SSBhbHNvIGJlbGlldmUgdGhhdCBHb29nbGUgaXMgdXNpbmcgSVczMiAoYW5kIFBhY2luZykgd2l0 aCBTUERZLi4uDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogTmVhbCBDYXJk d2VsbCBbbWFpbHRvOm5jYXJkd2VsbEBnb29nbGUuY29tXSANCkVudm95w6nCoDogbWFyZGkgMjQg bm92ZW1icmUgMjAxNSAxNzowNg0Kw4DCoDogTWFyayBBbGxtYW4NCkNjwqA6IFNBTExBTlRJTiBS ZW5hdWQ7IHRjcG1AaWV0Zi5vcmcNCk9iamV0wqA6IFJlOiBbdGNwbV0gSG93IHRvIGltcHJvdmUg VENQIGVmZmljaWVuY3kgaW4gYSBsYXJnZSBSVFQgY29udGV4dD8NCg0KT24gVHVlLCBOb3YgMjQs IDIwMTUgYXQgMTE6MDAgQU0sIE1hcmsgQWxsbWFuIDxtYWxsbWFuQGljaXIub3JnPiB3cm90ZToN Cj4NCj4gSSBoYXZlbid0IGJlZW4gdHJhY2tpbmcgdGhpbmdzIHZlcnkgY2xvc2VseS4uLg0KPg0K Pj4gU2V2ZXJhbCBtYWpvciBwbGF5ZXJzIGFscmVhZHkgdXNlIElXPTMyIG9yIGhpZ2hlciAod2l0 aCBhbmQgd2l0aG91dCANCj4+IHBhY2luZyksDQo+DQo+IElzIHRoaXMgd2VsbCBrbm93bj8gIENv dWxkIHlvdSBwb2ludCBtZSB0byB0aGUgcmVzdWx0cz8gIChJIGFtIGp1c3QNCj4gaW50ZXJlc3Rl ZC4pDQoNCkhlcmUgaXMgb25lIHN1Y2ggc3R1ZHk6DQoNCiAgaHR0cDovL3d3dy5jZG5wbGFuZXQu Y29tL2Jsb2cvaW5pdGN3bmQtc2V0dGluZ3MtbWFqb3ItY2RuLXByb3ZpZGVycy8NCg0KbmVhbA0K From nobody Tue Nov 24 08:40:44 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696741A9042 for ; Tue, 24 Nov 2015 08:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn7tLJv4O0Wb for ; Tue, 24 Nov 2015 08:40:41 -0800 (PST) Received: from thsbbfxrt02p.thalesgroup.com (thsbbfxrt02p.thalesgroup.com [192.93.158.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2211A9045 for ; Tue, 24 Nov 2015 08:40:41 -0800 (PST) Received: from thsbbfxrt02p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3p4rgq6RKgz1fg; Tue, 24 Nov 2015 17:40:39 +0100 (CET) X-Thales-IRT1: IRT11 From: SALLANTIN Renaud To: 'Joe Touch' , 'Neal Cardwell' , BAUDOIN Cedric Date: Tue, 24 Nov 2015 17:40:36 +0100 Thread-Topic: [tcpm] How to improve TCP efficiency in a large RTT context? Thread-Index: AdEmPx5XRWzXTZ1uQIqT9yue4P6fZQAluNxw Message-ID: <9079acd1-55df-4f87-a99f-1fa9e4ceb1c8@THSONEA01HUB05P.one.grp> References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <26827.1448031032@lawyers.icir.org> <56539453.1020504@isi.edu> In-Reply-To: <56539453.1020504@isi.edu> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-pmwin-version: 3.1.3.0, Antivirus-Engine: 3.60.0, Antivirus-Data: 5.21 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: 'Eric Dumazet' , "'tcpm@ietf.org'" , "'mallman@icir.org'" Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2015 16:40:42 -0000 DQo+SWYgdGhlIGxhcmdlIFJUVCBpcyBwcm9wYWdhdGlvbiBkZWxheSwgdGhlbiBpbmNyZWFzaW5n IHRoZSBJVyBpcyBleGFjdGx5IHRoZSByaWdodCBhbnN3ZXIsIHRob3VnaCB5b3UgZG8gd2FudCB0 byBwYWNlIHRoZSBkYXRhIG91dCBhcyB3ZWxsLg0KDQo+MjE0MCBUQ0IgcGFyYW1ldGVyIHJldXNl IG91Z2h0IHRvIGZpeCB0aGUgUlRUIGlzc3VlLCBhcyB3ZWxsIGFzIHBhY2luZyBpZiBwYWNpbmcg aXMgaW1wbGVtZW50ZWQgYW5kIHBhcnQgb2YgdGhlIHNldCBvZiBwYXJhbWV0ZXJzIHJldXNlZCBh Y3Jvc3MgY29ubmVjdGlvbnMuDQoNCkRvIHdlIGtub3cgdGhlIHBlcmNlbnRhZ2Ugb2YgY29ubmVj dGlvbiBlc3RhYmxpc2htZW50cyB0aGF0IGNhbiBiZW5lZml0IGZyb20gdGhlIFRDQiBpbmZvcm1h dGlvbj8gDQoNCiANCg== From nobody Tue Nov 24 09:01:35 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88ADB1B2D29 for ; Tue, 24 Nov 2015 09:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgetDRQgit1a for ; Tue, 24 Nov 2015 09:01:33 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9D31B2D27 for ; Tue, 24 Nov 2015 09:01:33 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id tAOH1AJg021341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Nov 2015 09:01:12 -0800 (PST) To: SALLANTIN Renaud , "'Neal Cardwell'" , BAUDOIN Cedric References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <26827.1448031032@lawyers.icir.org> <56539453.1020504@isi.edu> <9079acd1-55df-4f87-a99f-1fa9e4ceb1c8@THSONEA01HUB05P.one.grp> From: Joe Touch Message-ID: <565497D5.5010103@isi.edu> Date: Tue, 24 Nov 2015 09:01:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <9079acd1-55df-4f87-a99f-1fa9e4ceb1c8@THSONEA01HUB05P.one.grp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: tAOH1AJg021341 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: 'Eric Dumazet' , "'tcpm@ietf.org'" , "'mallman@icir.org'" , touch@isi.edu Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 24 Nov 2015 17:01:34 -0000 On 11/24/2015 8:40 AM, SALLANTIN Renaud wrote: > >> If the large RTT is propagation delay, then increasing the IW is exactly the right answer, though you do want to pace the data out as well. > >> 2140 TCB parameter reuse ought to fix the RTT issue, as well as pacing if pacing is implemented and part of the set of parameters reused across connections. > > Do we know the percentage of connection establishments that can benefit from the TCB information? It depends entirely on workload and what fraction of time a connection spends "learning" about a path. For connections that are very short, where TCP path properties aren't really used at all, or connections that are very long with persistent offered load, it won't matter at all. It's more work than it's worth for those very short connections. It doesn't hurt long connections. It's the medium-sized connections and long connections whose offered load or competing flows vary a lot that are the largest beneficiaries. Joe From nobody Tue Nov 24 09:43:12 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768FF1B304F for ; Tue, 24 Nov 2015 09:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLAg3o11P8WQ for ; Tue, 24 Nov 2015 09:43:10 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749261B304E for ; Tue, 24 Nov 2015 09:43:10 -0800 (PST) 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 tAOHh9iq026575 for ; Tue, 24 Nov 2015 09:43:09 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C346932E29D9 for ; Tue, 24 Nov 2015 12:43:08 -0500 (EST) To: tcpm@ietf.org From: Mark Allman Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Heavy Fuel X-URL-0: http://www.icir.org/mallman-files/Document28343.docx X-URL-1: http://www.icir.org/mallman-files/Document34461.xlsx MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 24 Nov 2015 12:43:08 -0500 Message-ID: <72616.1448386988@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Subject: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 24 Nov 2015 17:43:11 -0000 --=-------459435943823349593450 Content-Type: text/plain A proposal for allowing end hosts to set their initial cwnd to whatever they want ... in the canonical form that we use to propose such things ... draft-allman-tcpm-no-initwin-00.txt allman -- http://www.icir.org/mallman/ --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZUoawACgkQWyrrWs4yIs6aNwCcDS3siHq2kLxbbPdCANp0hboI 2S4Aniod+ZsGRtHHNsSx00qRcuqW/pEH =U040 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Tue Nov 24 16:07:51 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C4A1AC3BC for ; Tue, 24 Nov 2015 16:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.585, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LRXwciOWtCc for ; Tue, 24 Nov 2015 16:07:48 -0800 (PST) Received: from email5-west.aero.org (email5-west.aero.org [130.221.16.30]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02241AC3BA for ; Tue, 24 Nov 2015 16:07:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aero.org; i=@aero.org; q=dns/txt; s=mailhub; t=1448410069; x=1479946069; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hzMGrX98szOgDhIpTsYvCeVvSWHmIjddDkEnxeJ+chI=; b=dX7YJiwt9jYI8SrgZtNNsY0MdMes57QubAH6CFG6mUvJ+hFL5TCBtGQ+ qffAx4EUfrBGDOgaGj4DuKoPu9/guluUsjboMAx4Q8uCHjca5UDdRVVf2 dOeTzALX9/63URPKlpQg6CMm22zDLjduTWamSjT72Y9m2Ica46XNaK+NV g=; x-SBRS: 4.8 x-SenderGroup: Inbound_Office365 X-IronPort-AV: E=McAfee;i="5700,7163,7995"; a="1682018" X-IronPort-AV: E=Sophos;i="5.20,340,1444719600"; d="scan'208";a="1682018" X-IPAS-Result: A2FMAAD7+lRWlO+jLs9bAxkBAQEBDwEBAQEGAQEBAYRDBr48AQ2BZ4YPAhyBYBQBAQEBAQEBAw4BAQEBBwsLCR8whDUBAQECARIBEBFKCwIBCBoCJgICAjAVEAIEARIiiAQInyIBgSgBHGEFKAKKbwEBcJAmAQEBBwEBAQEBAQEcgQGFVIR9hFkYCyaCU4FEAQSSboNnjTKcWB8BAYJpgV1yAYQkAYEGAQEB Received: from mail-by2lp0239.outbound.protection.outlook.com (HELO na01-by2-obe.outbound.protection.outlook.com) ([207.46.163.239]) by email5-west.aero.org with ESMTP/TLS/AES256-SHA; 24 Nov 2015 16:07:46 -0800 Received: from DM2PR09MB0336.namprd09.prod.outlook.com (10.160.247.153) by DM2PR09MB0333.namprd09.prod.outlook.com (10.160.247.150) with Microsoft SMTP Server (TLS) id 15.1.325.17; Wed, 25 Nov 2015 00:07:43 +0000 Received: from DM2PR09MB0336.namprd09.prod.outlook.com ([10.160.247.153]) by DM2PR09MB0336.namprd09.prod.outlook.com ([10.160.247.153]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 00:07:43 +0000 From: Theodore V Faber To: "mallman@icir.org" , "tcpm@ietf.org" Thread-Topic: [tcpm] removing TCP's initial window Thread-Index: AQHRJt+ZKRGwEZIyQkCTOp3y4AvPP56rVr8A Date: Wed, 25 Nov 2015 00:07:43 +0000 Message-ID: References: <72616.1448386988@lawyers.icir.org> In-Reply-To: <72616.1448386988@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=theodore.v.faber@aero.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [130.221.224.7] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0333; 5:9MiM6L6q+fplKM5rMGpsikNud81ABYnQI8dDu1O9MOgtizRftA5/hH8ttE6zzG9f5pAxtQ/V/imva2w6reAotCBuwUNVg8LYrVuP8oqaxDr37OeK5e6SeSNUkwRmXjvjES+ZSEgdWQSwDywDGArbuQ==; 24:pKEEVWLrr2pnHTYLF3VxSChMmi0AstiqWLNAUHjH/ODRtYjnuO5MMQpc1/oqimch94lyRq1xgNr0tycoZTOJJPRfjbGNyn8Q34VnDmUBJ9o=; 20:jv2lGdOUGSDPnjfrMRuWFXOwIdZoVBi3xhu5z3Y7WDXSGyTJ2g9Wnu367cLq3gGmKQ7iGxfpBwvc/r7ENgB9Ag== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0333; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:DM2PR09MB0333; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0333; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(479174004)(24454002)(189002)(106356001)(92566002)(11100500001)(5001960100002)(5004730100002)(122556002)(76176999)(97736004)(2900100001)(86362001)(5002640100001)(19580405001)(101416001)(558084003)(2950100001)(81156007)(87936001)(189998001)(40100003)(5001770100001)(107886002)(50986999)(19580395003)(77096005)(6116002)(5007970100001)(5008740100001)(66066001)(2501003)(106116001)(102836003)(54356999)(586003)(10400500002)(99286002)(36756003)(105586002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR09MB0333; H:DM2PR09MB0336.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5DBC7E535FD6A4489384D15E96C3F391@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: aero.org X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 00:07:43.3899 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8294700-c5a4-4ca1-a876-1457d39899fd X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0333 Archived-At: Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 00:07:49 -0000 U2Vjb25kZWQuDQoNClJlcGxhY2Ug4oCcY29uZ2VzdGlvbuKAnSB3aXRoIOKAnGNvbmdlc3TigJ0g aW4gMihjKS4NCg0KUm9jayBvbi4NCg0KLS0gDQpUZWQgRmFiZXIgPHRoZW9kb3JlLnYuZmFiZXJA YWVyby5vcmc+DQpFbmdpbmVlcmluZyBTcGVjaWFsaXN0DQpDb21wdXRlciBTeXN0ZW1zIFJlc2Vh cmNoIERlcGFydG1lbnQNCjMxMC0zMzYtNzM3Mw0KDQoNCg0KDQoNCk9uIDExLzI0LzE1LCAwOTo0 MywgInRjcG0gb24gYmVoYWxmIG9mIE1hcmsgQWxsbWFuIiA8dGNwbS1ib3VuY2VzQGlldGYub3Jn DQpvbiBiZWhhbGYgb2YgbWFsbG1hbkBpY2lyLm9yZz4gd3JvdGU6DQoNCj4gIGRyYWZ0LWFsbG1h bi10Y3BtLW5vLWluaXR3aW4tMDAudHh0DQo+DQoNCg== From nobody Tue Nov 24 16:54:37 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EF51AC40C for ; Tue, 24 Nov 2015 16:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDCID3kXTiif for ; Tue, 24 Nov 2015 16:54:34 -0800 (PST) Received: from g4t3427.houston.hp.com (g4t3427.houston.hp.com [15.201.208.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA79B1AC40F for ; Tue, 24 Nov 2015 16:54:34 -0800 (PST) Received: from g9t2301.houston.hp.com (g9t2301.houston.hp.com [16.216.185.78]) by g4t3427.houston.hp.com (Postfix) with ESMTP id 1663E4C for ; Wed, 25 Nov 2015 00:54:34 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g9t2301.houston.hp.com (Postfix) with ESMTP id CDBC751 for ; Wed, 25 Nov 2015 00:54:33 +0000 (UTC) To: tcpm@ietf.org References: <72616.1448386988@lawyers.icir.org> From: Rick Jones Message-ID: <565506C9.6000808@hpe.com> Date: Tue, 24 Nov 2015 16:54:33 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <72616.1448386988@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 00:54:36 -0000 On 11/24/2015 09:43 AM, Mark Allman wrote: > > A proposal for allowing end hosts to set their initial cwnd to > whatever they want ... in the canonical form that we use to propose > such things ... > > draft-allman-tcpm-no-initwin-00.txt Admiral Farragut would be pleased :) In the vein of giving an inch and they will ask to take a mile, if such a paced, large IW is OK for the start of a connection, would it also be OK for "slow start after idle?" Or perhaps the lesser of that IW and cwnd when the connection went idle. rick jones From nobody Tue Nov 24 17:01:14 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86101AC429 for ; Tue, 24 Nov 2015 17:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.585, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIHfGd7i7hT2 for ; Tue, 24 Nov 2015 17:01:11 -0800 (PST) Received: from email5-west.aero.org (email5-west.aero.org [130.221.16.30]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06B51AC42B for ; Tue, 24 Nov 2015 17:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aero.org; i=@aero.org; q=dns/txt; s=mailhub; t=1448413271; x=1479949271; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9mCz0xu79owmzqGs2F7sTUWRQku/8fpRUL80s0SxnKk=; b=RbJnb0xSj8lJz8w/xyOokxvzjudmokW1qdG8AgojhOYNNaJPKQM5cNqu GP9gbctpl/XEbkCid7OMJWygvsr0mWdx64ZG2vfmxcLraJ2yFObC+Eqfe PY6zZtwH6+2/Kpcd5h1pGJsKjrbudG9lolfa28vDv/iJBF/ytTXt1Wxgt 4=; x-SBRS: 5.5 x-SenderGroup: Inbound_Office365 X-IronPort-AV: E=McAfee;i="5700,7163,7995"; a="1683040" X-IronPort-AV: E=Sophos;i="5.20,340,1444719600"; d="scan'208";a="1683040" X-IPAS-Result: A2FSAADyBlVWm/SjLs9bAxkBAQEBDwEBAQEGAQEBAYNUbwauIQGQGgENgWIFFwqFbgIcgWEUAQEBAQEBAQMOAQEBAQEGCwsJIS6CYhABAQEBAQFPAj4uAQEBAwEBAQ8BEBE6GwIBCBgCAiYCAgIlCxUQAgQBEiKIDA2fFgGBKAEcYQUoAopvAQFwkCkBAQEBBgEBAQEBAQEBARYEgQGFVIR9hFkYCyaCU4FEBZZVjTKcWB8BAYJTFgeBVnIBhCQBgQYBAQE Received: from mail-by2lp0244.outbound.protection.outlook.com (HELO na01-by2-obe.outbound.protection.outlook.com) ([207.46.163.244]) by email5-west.aero.org with ESMTP/TLS/AES256-SHA; 24 Nov 2015 17:01:10 -0800 Received: from DM2PR09MB0336.namprd09.prod.outlook.com (10.160.247.153) by DM2PR09MB0335.namprd09.prod.outlook.com (10.160.247.152) with Microsoft SMTP Server (TLS) id 15.1.331.20; Wed, 25 Nov 2015 01:01:08 +0000 Received: from DM2PR09MB0336.namprd09.prod.outlook.com ([10.160.247.153]) by DM2PR09MB0336.namprd09.prod.outlook.com ([10.160.247.153]) with mapi id 15.01.0331.023; Wed, 25 Nov 2015 01:01:08 +0000 From: Theodore V Faber To: Rick Jones , "tcpm@ietf.org" Thread-Topic: [tcpm] removing TCP's initial window Thread-Index: AQHRJt+ZKRGwEZIyQkCTOp3y4AvPP56r6fKA//97uQA= Date: Wed, 25 Nov 2015 01:01:07 +0000 Message-ID: References: <72616.1448386988@lawyers.icir.org> <565506C9.6000808@hpe.com> In-Reply-To: <565506C9.6000808@hpe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=theodore.v.faber@aero.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [130.221.224.7] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0335; 5:GxIuplny4o3qC2Wqr028iAnLEqSSj35ivWKZ26qynUTm/DZdk5fWUNC5MB0wHXeacaYcYS+ANM4F5Hu1lIKElEQEkuMuRG8zlG/z0jP6f0zab3yG+tMG3QI5Lef/e7bRmhU7QzfNM/cAaJttKwPTXw==; 24:A2aL+CpETeTh/hcAB8Zp42wTmlnxYb4XlXI5et1Xx9oTvaYDaJRCSuDWGcQYbppyVII7kvv9IXO1bWVnqzO0VOOdnG8ayd2X1CWJuF+OZk0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0335; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:DM2PR09MB0335; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0335; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(479174004)(24454002)(189002)(199003)(92566002)(6116002)(586003)(3846002)(102836003)(101416001)(122556002)(36756003)(86362001)(15975445007)(77096005)(561944003)(54356999)(2900100001)(2950100001)(2501003)(40100003)(5008740100001)(107886002)(81156007)(87936001)(5002640100001)(5004730100002)(5001770100001)(189998001)(66066001)(10400500002)(5007970100001)(106116001)(11100500001)(50986999)(106356001)(76176999)(5001960100002)(19580395003)(19580405001)(105586002)(99286002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR09MB0335; H:DM2PR09MB0336.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: aero.org X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2015 01:01:07.9005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8294700-c5a4-4ca1-a876-1457d39899fd X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0335 Archived-At: Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 01:01:12 -0000 V2VsbCBzYWlkLg0KLS0gDQpUZWQgRmFiZXIgPHRoZW9kb3JlLnYuZmFiZXJAYWVyby5vcmc+DQpF bmdpbmVlcmluZyBTcGVjaWFsaXN0DQpDb21wdXRlciBTeXN0ZW1zIFJlc2VhcmNoIERlcGFydG1l bnQNCjMxMC0zMzYtNzM3Mw0KDQoNCg0KDQoNCk9uIDExLzI0LzE1LCAxNjo1NCwgInRjcG0gb24g YmVoYWxmIG9mIFJpY2sgSm9uZXMiIDx0Y3BtLWJvdW5jZXNAaWV0Zi5vcmcNCm9uIGJlaGFsZiBv ZiByaWNrLmpvbmVzMkBocGUuY29tPiB3cm90ZToNCg0KPk9uIDExLzI0LzIwMTUgMDk6NDMgQU0s IE1hcmsgQWxsbWFuIHdyb3RlOg0KPj4NCj4+IEEgcHJvcG9zYWwgZm9yIGFsbG93aW5nIGVuZCBo b3N0cyB0byBzZXQgdGhlaXIgaW5pdGlhbCBjd25kIHRvDQo+PiB3aGF0ZXZlciB0aGV5IHdhbnQg Li4uIGluIHRoZSBjYW5vbmljYWwgZm9ybSB0aGF0IHdlIHVzZSB0byBwcm9wb3NlDQo+PiBzdWNo IHRoaW5ncyAuLi4NCj4+DQo+PiAgICBkcmFmdC1hbGxtYW4tdGNwbS1uby1pbml0d2luLTAwLnR4 dA0KPg0KPg0KPkFkbWlyYWwgRmFycmFndXQgd291bGQgYmUgcGxlYXNlZCA6KQ0KPg0KPkluIHRo ZSB2ZWluIG9mIGdpdmluZyBhbiBpbmNoIGFuZCB0aGV5IHdpbGwgYXNrIHRvIHRha2UgYSBtaWxl LCBpZiBzdWNoDQo+YSBwYWNlZCwgbGFyZ2UgSVcgaXMgT0sgZm9yIHRoZSBzdGFydCBvZiBhIGNv bm5lY3Rpb24sIHdvdWxkIGl0IGFsc28gYmUNCj5PSyBmb3IgInNsb3cgc3RhcnQgYWZ0ZXIgaWRs ZT8iICBPciBwZXJoYXBzIHRoZSBsZXNzZXIgb2YgdGhhdCBJVyBhbmQNCj5jd25kIHdoZW4gdGhl IGNvbm5lY3Rpb24gd2VudCBpZGxlLg0KPg0KPnJpY2sgam9uZXMNCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnRjcG0gbWFpbGluZyBsaXN0DQo+ dGNwbUBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGNw bQ0KDQo= From nobody Tue Nov 24 19:46:55 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A1E1ACEB4 for ; Tue, 24 Nov 2015 19:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-zj-84AYF1F for ; Tue, 24 Nov 2015 19:46:52 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3B81ACEB8 for ; Tue, 24 Nov 2015 19:46:51 -0800 (PST) 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 tAP3kZDg026568; Tue, 24 Nov 2015 19:46:36 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 6E5E4330750E; Tue, 24 Nov 2015 22:46:35 -0500 (EST) To: Rick Jones From: Mark Allman In-Reply-To: <565506C9.6000808@hpe.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Heavy Fuel MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 24 Nov 2015 22:46:35 -0500 Message-ID: <63311.1448423195@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 25 Nov 2015 03:46:53 -0000 --=-------459435943823349593450 Content-Type: text/plain > Admiral Farragut would be pleased :) Ha! > In the vein of giving an inch and they will ask to take a mile, if > such a paced, large IW is OK for the start of a connection, would it > also be OK for "slow start after idle?" Or perhaps the lesser of > that IW and cwnd when the connection went idle. Perhaps. The difference is that in this case the host has *some* notion of the path it is traversing. But, at some point that notion is so dated that indeed treating it like a brand new connection from a CC standpoint seems OK to me. But, there are probably more considerations here than at the start of a connection. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZVLxsACgkQWyrrWs4yIs4vPACfXmraNZ/nY9XJEwlIFEg21BPK AKsAnik/NTIXeS0kCyW6Wb2f5Vj5IrmO =WSq9 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Tue Nov 24 22:13:42 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236191B2A52 for ; Tue, 24 Nov 2015 22:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.939 X-Spam-Level: X-Spam-Status: No, score=0.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmnS0g2eGA41 for ; Tue, 24 Nov 2015 22:13:39 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85B421B2A44 for ; Tue, 24 Nov 2015 22:13:39 -0800 (PST) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5F549278310 for ; Wed, 25 Nov 2015 15:13:37 +0900 (JST) Received: by oies6 with SMTP id s6so23950010oie.1 for ; Tue, 24 Nov 2015 22:13:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.184.138 with SMTP id i132mr22860863oif.62.1448432015857; Tue, 24 Nov 2015 22:13:35 -0800 (PST) Received: by 10.202.190.6 with HTTP; Tue, 24 Nov 2015 22:13:35 -0800 (PST) In-Reply-To: <72616.1448386988@lawyers.icir.org> References: <72616.1448386988@lawyers.icir.org> Date: Tue, 24 Nov 2015 22:13:35 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Yoshifumi Nishida To: Mark Allman Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 06:13:41 -0000 Hmm. Is there any guidelines to apply this? We don't need TCB sharing for this? Also, why it's BCP? Thanks, -- Yoshi On Tue, Nov 24, 2015 at 9:43 AM, Mark Allman wrote: > > A proposal for allowing end hosts to set their initial cwnd to > whatever they want ... in the canonical form that we use to propose > such things ... > > draft-allman-tcpm-no-initwin-00.txt > > allman > > > -- > http://www.icir.org/mallman/ > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Nov 25 01:46:20 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB13F1A039E for ; Wed, 25 Nov 2015 01:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPJ4aO3x8P-O for ; Wed, 25 Nov 2015 01:46:12 -0800 (PST) Received: from thsbbfxrt01p.thalesgroup.com (thsbbfxrt01p.thalesgroup.com [192.54.144.131]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EFB1A0398 for ; Wed, 25 Nov 2015 01:46:12 -0800 (PST) Received: from thsbbfxrt01p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3p5HR64krCz1DK; Wed, 25 Nov 2015 10:46:10 +0100 (CET) X-Thales-IRT1: IRT11 From: SALLANTIN Renaud To: 'Yoshifumi Nishida' , 'Mark Allman' Date: Wed, 25 Nov 2015 10:46:06 +0100 Thread-Topic: [tcpm] removing TCP's initial window Thread-Index: AdEnSHJah3kTCh2LS9efrGOiaAAjzAAFSVAg Message-ID: References: <72616.1448386988@lawyers.icir.org> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-pmwin-version: 3.1.3.0, Antivirus-Engine: 3.60.0, Antivirus-Data: 5.21 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 09:46:18 -0000 In 1(C), I think that "pacing" needs to be defined. I am in favor of a lower and an upper limit for the pacing time between 2 s= egments transmission. If the number of segments you have to send across the RTT makes the pacing = time lower than a minimal value (TBD), then we'd better not pace.=20 Indeed, pacing adds an unnecessary complexity.=20 If the number of segments you have to send across the RTT makes the pacing = time higher than a maximal value (TBD), then we'd better use this upper lim= it as pacing time. Indeed, after a certain value, increasing again the pacing time between 2 s= egments transmission is useless and harmful: *it does not reduce the congestion impact on your segments transmission;=20 *but it adds an unnecessary (and long) delay in case of long RTT. For examp= le, pacing without upper limit an IW of 10 segments in satcom adds around 5= 00ms... I know that many points have to be discussed, and that's why we would be in= terested in a draft on the Pacing. [@@ THALES ALENIA SPACE INTERNAL @@] -----Message d'origine----- De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yoshifumi Nishida Envoy=E9=A0: mercredi 25 novembre 2015 07:14 =C0=A0: Mark Allman Cc=A0: tcpm@ietf.org Objet=A0: Re: [tcpm] removing TCP's initial window Hmm. Is there any guidelines to apply this? We don't need TCB sharing for t= his? Also, why it's BCP? Thanks, -- Yoshi On Tue, Nov 24, 2015 at 9:43 AM, Mark Allman wrote: > > A proposal for allowing end hosts to set their initial cwnd to=20 > whatever they want ... in the canonical form that we use to propose=20 > such things ... > > draft-allman-tcpm-no-initwin-00.txt > > allman > > > -- > http://www.icir.org/mallman/ > > > > > > _______________________________________________ > 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 nobody Wed Nov 25 02:19:47 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B289B1A1A3D for ; Wed, 25 Nov 2015 02:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0idgaY5dRAH for ; Wed, 25 Nov 2015 02:19:43 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871FA1A1A75 for ; Wed, 25 Nov 2015 02:19:39 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1a1XAk-0000lb-Cn; Wed, 25 Nov 2015 11:19:34 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1a1XAj-0007RV-VS; Wed, 25 Nov 2015 11:19:34 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: Date: Wed, 25 Nov 2015 11:19:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <72616.1448386988@lawyers.icir.org> To: Yoshifumi Nishida X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 16 msgs/h 4 sum rcpts/h 24 sum msgs/h 5 total rcpts 35676 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DEF567A709B42A5585FE9F0086F08E2B87D48EE7 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 8558 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "tcpm@ietf.org" , Mark Allman Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 10:19:45 -0000 I very much agree about TCB sharing. On the other hand, I also very much agree with the first sentiment = expressed in the "reasoning" list: *** (a) The author thinks that talking about the initial window for the better part of two decades is probably enough. And, definitely boring. *** So all in all, I appreciate this proposal a lot (and admittedly, I'm = also becoming a fan of Mark's combined sense of humor and system design = - I still think that tcpx2 was the best solution ever proposed to solve = header space issues). Cheers, Michael > On 25 Nov 2015, at 07:13, Yoshifumi Nishida = wrote: >=20 > Hmm. Is there any guidelines to apply this? We don't need TCB sharing = for this? > Also, why it's BCP? >=20 > Thanks, > -- > Yoshi >=20 > On Tue, Nov 24, 2015 at 9:43 AM, Mark Allman wrote: >>=20 >> A proposal for allowing end hosts to set their initial cwnd to >> whatever they want ... in the canonical form that we use to propose >> such things ... >>=20 >> draft-allman-tcpm-no-initwin-00.txt >>=20 >> allman >>=20 >>=20 >> -- >> http://www.icir.org/mallman/ >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>=20 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Nov 25 04:47:49 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10471B2C37 for ; Wed, 25 Nov 2015 04:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JMb4j6VR4Bl for ; Wed, 25 Nov 2015 04:47:46 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5C81B2C36 for ; Wed, 25 Nov 2015 04:47:46 -0800 (PST) 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 tAPCliON004649; Wed, 25 Nov 2015 04:47:44 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 21EB733091A4; Wed, 25 Nov 2015 07:47:45 -0500 (EST) To: Yoshifumi Nishida From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Play Guitar X-URL-0: http://www.icir.org/mallman-files/Document16406.doc X-URL-1: http://www.icir.org/mallman-files/Document59639.pdf X-URL-2: http://www.icir.org/mallman-files/Document62211.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 25 Nov 2015 07:47:45 -0500 Message-ID: <73918.1448455665@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 25 Nov 2015 12:47:47 -0000 --=-------459435943823349593450 Content-Type: text/plain > Hmm. Is there any guidelines to apply this? Not sure I follow. (I mean, clearly, it isn't fleshed out very well. It was just a sketch to see if there are any actual legs to it.) > We don't need TCB sharing for this? Nope. > Also, why it's BCP? Oh, sorry. That is because I quickly re-used the boilerplate from something else. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZVre4ACgkQWyrrWs4yIs7IJgCfRuJCW0Rpi0C7oqMNFjJWc+8M eZwAoJ+BdD1pd+Q4Nfb0mda/3212iwoD =qk13 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Nov 25 06:05:50 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81A91B2CE1 for ; Wed, 25 Nov 2015 06:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-juUspVYKxR for ; Wed, 25 Nov 2015 06:05:47 -0800 (PST) Received: from mta-us-west-01.viasat.com (mta-us-west-01.viasat.com [8.37.96.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5F41B2CD3 for ; Wed, 25 Nov 2015 06:05:47 -0800 (PST) Received: from pps.filterd (VCASPAM01.hq.corp.viasat.com [127.0.0.1]) by VCASPAM01.hq.corp.viasat.com (8.15.0.59/8.15.0.59) with SMTP id tAPE2j0N008160; Wed, 25 Nov 2015 14:05:46 GMT From: "Agarwal, Anil" To: "mallman@icir.org" , Yoshifumi Nishida Thread-Topic: [tcpm] removing TCP's initial window Thread-Index: AQHRJ397v9s3T5k930KFBsrg9zW6Y56su5vQ Date: Wed, 25 Nov 2015 14:05:43 +0000 Message-ID: <7A2801D5E40DD64A85E38DF22117852C881700E1@wdc1exchmbxp05.hq.corp.viasat.com> References: <73918.1448455665@lawyers.icir.org> In-Reply-To: <73918.1448455665@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7A2801D5E40DD64A85E38DF22117852C881700E1wdc1exchmbxp05h_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-11-25_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1511250244 Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 14:05:49 -0000 --_000_7A2801D5E40DD64A85E38DF22117852C881700E1wdc1exchmbxp05h_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Few thoughts - 1. Following statement is probably not true in many cases, e.g., cellular and satellite access networks. " (c) An overly aggressive IW is likely to congestion (sic) local networ= ks before burdening remote portions of the path" An overly aggressive IW will cause congestion at cellular/satellite head= -end. 2. Following rationale is a bit weak - " (g) Ultimately, being egregiously overly aggressive will not be in the sender's best interest---e.g., there will be a fight for local resources among the sender's own connections---and therefore there is an incentive to be reasonable." If being overly aggressive does not affect the sender's own local resour= ces, but affects remote resources instead, a sender might feel incentivized t= o be more aggressive than others, perhaps resulting in an IW-arms-race. 3. Rule (3) in section 1 describes actions after packet drops. We presume i= t applies to ECN marks as well. 4. It would seem logical that IW simply not be a one-size-fits-all value fo= r a given server. A server serves many clients with different time-varying path characteri= stics. Making IW a function of the client path characteristics, perhaps based o= n TCB sharing and/or cached historical information and/or configured parameters would = seem to be prudent. Anil -----Original Message----- From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Mark Allman Sent: Wednesday, November 25, 2015 7:48 AM To: Yoshifumi Nishida Cc: tcpm@ietf.org Subject: Re: [tcpm] removing TCP's initial window > Hmm. Is there any guidelines to apply this? Not sure I follow. (I mean, clearly, it isn't fleshed out very well. It was just a sketch to = see if there are any actual legs to it.) > We don't need TCB sharing for this? Nope. > Also, why it's BCP? Oh, sorry. That is because I quickly re-used the boilerplate from somethin= g else. allman --_000_7A2801D5E40DD64A85E38DF22117852C881700E1wdc1exchmbxp05h_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Few thoughts -

 

1. Following statement is prob= ably not true in many cases,

   e.g., cellular and satellite access networks.

   " (c) An overly aggressive IW is likely to congestion (sic) loc= al networks

        before burdening remote portions of the path"=

   An overly aggressive IW will cause congestion at cellular/satellite = head-end.

 

2. Following rationale is a bi= t weak -

   " (g) Ultimately, being egregiously overly aggressive will not = be in

    the sender's best interest---e.g., there = will be a fight for

    local resources among the sender's own connections---and<= /span>

    therefore there is an incentive to be reasonable."

 

   If being overly aggressive does not affect the sender's own local re= sources,

   but affects remote resources instead, a sender might feel incentiviz= ed to be

   more aggressive than others, perhaps resulting in an IW-arms-race.

 

3. Rule (3) in section 1 descr= ibes actions after packet drops. We presume it applies to=

   ECN marks as well.

 

4. It would seem logical that = IW simply not be a one-size-fits-all value for a given server.

   A server serves many clients with different time-varying path charac= teristics.

   Making IW a function of the client path characteristics, perhaps bas= ed on TCB sharing

   and/or cached historical information and/or configured parameters wo= uld seem to be prudent.

 

Anil

 

-----Original Message-----
From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of Mark Allman
Sent: Wednesday, November 25, 2015 7:48 AM
To: Yoshifumi Nishida
Cc: tcpm@ietf.org
Subject: Re: [tcpm] removing TCP's initial window

 

 

> Hmm. Is there any guidelines to apply this?<= o:p>

 

Not sure I follow.

 

(I mean, clearly, it isn't fleshed out very well.=   It was just a sketch to see if there are any actual legs to it.)

 

> We don't need TCB sharing for this?

 

Nope.

 

> Also, why it's BCP?

 

Oh, sorry. = That is because I quickly re-used the boilerplate from something el= se.

 

allman

 

 

 

--_000_7A2801D5E40DD64A85E38DF22117852C881700E1wdc1exchmbxp05h_-- From nobody Wed Nov 25 06:28:21 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E511B2D61 for ; Wed, 25 Nov 2015 06:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBfWyyEe6leU for ; Wed, 25 Nov 2015 06:28:13 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A93F1B2D59 for ; Wed, 25 Nov 2015 06:28:13 -0800 (PST) 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 tAPESBQ8011853; Wed, 25 Nov 2015 06:28:11 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 17BC2330A684; Wed, 25 Nov 2015 09:28:11 -0500 (EST) To: "Agarwal\, Anil" From: Mark Allman In-Reply-To: <7A2801D5E40DD64A85E38DF22117852C881700E1@wdc1exchmbxp05.hq.corp.viasat.com> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Play Guitar X-URL-0: http://www.icir.org/mallman-files/Document39432.html X-URL-1: http://www.icir.org/mallman-files/Document13763.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 25 Nov 2015 09:28:11 -0500 Message-ID: <92423.1448461691@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 25 Nov 2015 14:28:19 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > 2. Following rationale is a bit weak - >=20 > " (g) Ultimately, being egregiously overly aggressive will not be in=20 > the sender's best interest---e.g., there will be a fight for > local resources among the sender's own connections---and > therefore there is an incentive to be reasonable." >=20 > If being overly aggressive does not affect the sender's own local > resources, but affects remote resources instead, a sender might > feel incentivized to be more aggressive than others, perhaps > resulting in an IW-arms-race. Yeah- but the thing is that IW isn't the overall driver here. That is, I could try to dump as much as the advertised window would allow. But, if I see loss then I have to revert back. And, I have to repair that loss. And, so ultimately there is a check here. > 3. Rule (3) in section 1 describes actions after packet drops. We > presume it applies to >=20 > ECN marks as well. (Sure.) > 4. It would seem logical that IW simply not be a one-size-fits-all > value for a given server.=20=20 Right. There is no one-size-fits-all. And, so we---and I am clearly as much to blame as anyone---have chosen a one-size-fits-nobody approach. > A server serves many clients with different time-varying path > characteristics. Making IW a function of the client path > characteristics, Right. The ideal IW depends on the time-varying conditions. The problem is that when starting up we don't have much of an idea about this. > perhaps based on TCB sharing and/or cached historical information > and/or configured parameters would seem to be prudent. I don't disagree. Nothing in the draft precludes any of this. That is, the draft frees implementations to use whatever they deem as reasonable for the initial window. That could be a constant based on their own upstream. Or, some function based on the RTT during the 3WHS. Or, based on historical characteristics of the given remote IP / routed block. Or, whatever. There are lots of ideas in the air for arriving at something sensible. And, there is not one "sensible" for all situations. So, let's stop pretending there is some magic number that solves this and just let implementations / instantiations puzzle through it for themselves. allman =2D- http://www.icir.org/mallman/ @mallman_icsi --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZVxXoACgkQWyrrWs4yIs5lYQCbBYC0wCT4Z/TvQdgXpECJ8fPu TG4AnjWfzYOj6QiGraDnaxVMb07hveTC =xhjh -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Nov 25 08:36:46 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 810ED1A1B64 for ; Wed, 25 Nov 2015 08:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYorv6mUulvY for ; Wed, 25 Nov 2015 08:36:42 -0800 (PST) Received: from thsbbfxrt02p.thalesgroup.com (thsbbfxrt02p.thalesgroup.com [192.93.158.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7A71A1B57 for ; Wed, 25 Nov 2015 08:36:42 -0800 (PST) Received: from thsbbfxrt02p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3p5SXn0W3yz1tL; Wed, 25 Nov 2015 17:36:41 +0100 (CET) X-Thales-IRT1: IRT11 From: SALLANTIN Renaud To: SALLANTIN Renaud , 'Yoshifumi Nishida' , 'Mark Allman' Date: Wed, 25 Nov 2015 17:36:37 +0100 Thread-Topic: [tcpm] removing TCP's initial window Thread-Index: AdEnSHJah3kTCh2LS9efrGOiaAAjzAAFSVAgABBVKaA= Message-ID: <39c1c4aa-b49a-4625-8d6d-556d466de763@THSONEA01HUB02P.one.grp> References: <72616.1448386988@lawyers.icir.org> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-pmwin-version: 3.1.3.0, Antivirus-Engine: 3.60.0, Antivirus-Data: 5.21 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 16:36:44 -0000 Why not pace the IW of less than 10 segments?=20 [@@ THALES ALENIA SPACE INTERNAL @@] -----Message d'origine----- De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de SALLANTIN Renaud Envoy=E9=A0: mercredi 25 novembre 2015 10:46 =C0=A0: 'Yoshifumi Nishida'; 'Mark Allman' Cc=A0: 'tcpm@ietf.org' Objet=A0: Re: [tcpm] removing TCP's initial window In 1(C), I think that "pacing" needs to be defined. I am in favor of a lower and an upper limit for the pacing time between 2 s= egments transmission. If the number of segments you have to send across the RTT makes the pacing = time lower than a minimal value (TBD), then we'd better not pace.=20 Indeed, pacing adds an unnecessary complexity.=20 If the number of segments you have to send across the RTT makes the pacing = time higher than a maximal value (TBD), then we'd better use this upper lim= it as pacing time. Indeed, after a certain value, increasing again the pacing time between 2 s= egments transmission is useless and harmful: *it does not reduce the congestion impact on your segments transmission; *b= ut it adds an unnecessary (and long) delay in case of long RTT. For example= , pacing without upper limit an IW of 10 segments in satcom adds around 500= ms... I know that many points have to be discussed, and that's why we would be in= terested in a draft on the Pacing. [@@ THALES ALENIA SPACE INTERNAL @@] -----Message d'origine----- De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yoshifumi Nishida Envoy=E9=A0: mercredi 25 novembre 2015 07:14 =C0=A0: Mark Allman Cc=A0: tcpm@ietf.org Objet=A0: Re: [tcpm] removing TCP's initial window Hmm. Is there any guidelines to apply this? We don't need TCB sharing for t= his? Also, why it's BCP? Thanks, -- Yoshi On Tue, Nov 24, 2015 at 9:43 AM, Mark Allman wrote: > > A proposal for allowing end hosts to set their initial cwnd to=20 > whatever they want ... in the canonical form that we use to propose=20 > such things ... > > draft-allman-tcpm-no-initwin-00.txt > > allman > > > -- > http://www.icir.org/mallman/ > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Nov 25 08:56:35 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19B31A21A7 for ; Wed, 25 Nov 2015 08:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1s4Uoy9jgN_r for ; Wed, 25 Nov 2015 08:56:32 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1DE1A21A6 for ; Wed, 25 Nov 2015 08:56:32 -0800 (PST) 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 tAPGuU5o022295; Wed, 25 Nov 2015 08:56:30 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id B6172330BC38; Wed, 25 Nov 2015 11:56:29 -0500 (EST) To: SALLANTIN Renaud From: Mark Allman In-Reply-To: <39c1c4aa-b49a-4625-8d6d-556d466de763@THSONEA01HUB02P.one.grp> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Play Guitar X-URL-0: http://www.icir.org/mallman-files/Document93126.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 25 Nov 2015 11:56:29 -0500 Message-ID: <17838.1448470589@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "'tcpm@ietf.org'" Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 25 Nov 2015 16:56:33 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Why not pace the IW of less than 10 segments?=20 I didn't say not to. I said for IW > 10 you MUST. If you want to, great. But, we have already agreed on IW10 without pacing and so it seems like we don't need to add a requirement for pacing there. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZV6DsACgkQWyrrWs4yIs6KagCeNeKp65JpsesbvyjrKZPxFxGY o0kAn149IRiQeU+MS4LrPNCBKO7VqQRs =Ogk2 -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Nov 25 10:44:37 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8491A8AF3 for ; Wed, 25 Nov 2015 10:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.485 X-Spam-Level: X-Spam-Status: No, score=-7.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm22Dy5T2r-p for ; Wed, 25 Nov 2015 10:44:33 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1061A0015 for ; Wed, 25 Nov 2015 10:44:33 -0800 (PST) Received: from [128.9.184.98] ([128.9.184.98]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tAPIhsVP023779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Nov 2015 10:43:55 -0800 (PST) To: mallman@icir.org, tcpm@ietf.org References: <72616.1448386988@lawyers.icir.org> From: Joe Touch Message-ID: <5656016A.2080504@isi.edu> Date: Wed, 25 Nov 2015 10:43:54 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <72616.1448386988@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 18:44:36 -0000 I like the assumptions, esp. that AQM is widely deployed, but they're just that - assumptions. I'd like to see some evidence this approach is safe first, because pacing traffic out seems more likely to mask a "tragedy of the commons" issue than bursting would have, esp. when AQM isn't available. Joe On 11/24/2015 9:43 AM, Mark Allman wrote: > > A proposal for allowing end hosts to set their initial cwnd to > whatever they want ... in the canonical form that we use to propose > such things ... > > draft-allman-tcpm-no-initwin-00.txt > > allman > > > -- > http://www.icir.org/mallman/ > > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Wed Nov 25 10:56:27 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554391AC39E for ; Wed, 25 Nov 2015 10:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGnJJlUqitBe for ; Wed, 25 Nov 2015 10:56:24 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE30E1A8BB4 for ; Wed, 25 Nov 2015 10:56:24 -0800 (PST) Received: from [2a00:b900:109e:0:3e97:eff:feb2:e128] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_139-4deb125) id 1a1fEs-00019Q-Ny for tcpm@ietf.org (return-path ); Wed, 25 Nov 2015 18:56:22 +0000 To: tcpm@ietf.org References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> From: Jeremy Harris X-Enigmail-Draft-Status: N1110 Message-ID: <56560456.6070704@wizmail.org> Date: Wed, 25 Nov 2015 18:56:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:3e97:eff:feb2:e128] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 18:56:26 -0000 On 20/11/15 14:40, SALLANTIN Renaud wrote: > · Is there room to increase even more the Initial Window? Several major players already use IW=32 or higher (with and without pacing), that would really help for satellite communications. But the question here is how to mitigate the burst impact? In combination with larger IW, would there be benefit in packets being marked for "no roundtrip yet"? During startup of a flow, a bottleneck router could then fire a source-quench. This would at least help the case where the bottleneck is close to the source. -- Cheers, Jeremy From nobody Wed Nov 25 11:24:17 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDD31B2D04 for ; Wed, 25 Nov 2015 11:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GquvyENHCqjV for ; Wed, 25 Nov 2015 11:24:14 -0800 (PST) Received: from g1t5424.austin.hp.com (g1t5424.austin.hp.com [15.216.225.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E891B2CFB for ; Wed, 25 Nov 2015 11:24:14 -0800 (PST) Received: from g2t2360.austin.hp.com (g2t2360.austin.hp.com [16.197.8.247]) by g1t5424.austin.hp.com (Postfix) with ESMTP id 8443644; Wed, 25 Nov 2015 19:24:13 +0000 (UTC) Received: from [16.103.148.51] (tardy.usa.hp.com [16.103.148.51]) by g2t2360.austin.hp.com (Postfix) with ESMTP id 2D5873D; Wed, 25 Nov 2015 19:24:12 +0000 (UTC) To: Joe Touch , mallman@icir.org, tcpm@ietf.org References: <72616.1448386988@lawyers.icir.org> <5656016A.2080504@isi.edu> From: Rick Jones Message-ID: <56560ADC.2080208@hpe.com> Date: Wed, 25 Nov 2015 11:24:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5656016A.2080504@isi.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 19:24:16 -0000 On 11/25/2015 10:43 AM, Joe Touch wrote: > I like the assumptions, esp. that AQM is widely deployed, but they're > just that - assumptions. > > I'd like to see some evidence this approach is safe first, because > pacing traffic out seems more likely to mask a "tragedy of the commons" > issue than bursting would have, esp. when AQM isn't available. Much as I'd like to see bursting the IW (Damn the torpedoes and all that) because it would enable using TSO/GSO, why would pacing mask a tragedy of the AQM-less commons? If there is no AQM available at the bottleneck, it will either trigger a drop at the tail of the queue or not, and if it does not, all we have is a slight (one RTT?) delay before the sender "really" dumps a load on the bottleneck. Heck, if we are lucky (well, are we, ever?) that paced IW if it does get through without drops may complete the sending to be done anyway, and if it doesn't, it suggests there was going to be a queue fill/overflow if we started with a classic, smaller IW anyway. If not during the classic, smaller IW itself then during the subsequent RTTs. rick jones From nobody Wed Nov 25 11:32:36 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7EE1B2DF9 for ; Wed, 25 Nov 2015 11:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.485 X-Spam-Level: X-Spam-Status: No, score=-7.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6zTWvA63LOb for ; Wed, 25 Nov 2015 11:32:33 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495A31B2DEE for ; Wed, 25 Nov 2015 11:32:33 -0800 (PST) Received: from [128.9.184.98] ([128.9.184.98]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id tAPJWF0P022143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Nov 2015 11:32:16 -0800 (PST) To: Rick Jones , mallman@icir.org, tcpm@ietf.org References: <72616.1448386988@lawyers.icir.org> <5656016A.2080504@isi.edu> <56560ADC.2080208@hpe.com> From: Joe Touch X-Enigmail-Draft-Status: N1110 Message-ID: <56560CBF.8050006@isi.edu> Date: Wed, 25 Nov 2015 11:32:15 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56560ADC.2080208@hpe.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 19:32:35 -0000 On 11/25/2015 11:24 AM, Rick Jones wrote: > On 11/25/2015 10:43 AM, Joe Touch wrote: >> I like the assumptions, esp. that AQM is widely deployed, but they're >> just that - assumptions. >> >> I'd like to see some evidence this approach is safe first, because >> pacing traffic out seems more likely to mask a "tragedy of the commons" >> issue than bursting would have, esp. when AQM isn't available. > > Much as I'd like to see bursting the IW (Damn the torpedoes and all > that) because it would enable using TSO/GSO, why would pacing mask a > tragedy of the AQM-less commons? If there is no AQM available at the > bottleneck, it will either trigger a drop at the tail of the queue or > not, and if it does not, all we have is a slight (one RTT?) delay before > the sender "really" dumps a load on the bottleneck. Losses can occur all along a path, they don't have to occur only at one bottleneck. If you burst, you're more likely to see a drop in one of those locations than if you pace things out. In a sense, bursting is like a heavy-handed version of packet-pair in terms of measuring the drop behavior along the path - you're more likely to create a situation where you cause a drop of your own packets, because you're the dominant occupant of the queues at a given router. > Heck, if we are lucky (well, are we, ever?) that paced IW if it does get > through without drops may complete the sending to be done anyway, and if > it doesn't, it suggests there was going to be a queue fill/overflow if > we started with a classic, smaller IW anyway. If not during the > classic, smaller IW itself then during the subsequent RTTs. Except that if you run over several RTTs, you run a greater chance of experiencing a drop during one of those RTTs on the way to a larger window. Joe From nobody Wed Nov 25 11:59:15 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518DB1B2EF8 for ; Wed, 25 Nov 2015 11:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.136 X-Spam-Level: X-Spam-Status: No, score=-2.136 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H62UP8_Gk7YN for ; Wed, 25 Nov 2015 11:59:12 -0800 (PST) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034141B2BB0 for ; Wed, 25 Nov 2015 11:59:12 -0800 (PST) Received: from [192.168.1.103] (p508F0F20.dip0.t-ipconnect.de [80.143.15.32]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3B0D2200C00F5; Wed, 25 Nov 2015 20:59:09 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Tuexen In-Reply-To: <72616.1448386988@lawyers.icir.org> Date: Wed, 25 Nov 2015 20:59:08 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <72616.1448386988@lawyers.icir.org> To: mallman@icir.org X-Mailer: Apple Mail (2.2104) Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 19:59:14 -0000 > On 24 Nov 2015, at 18:43, Mark Allman wrote: > > > A proposal for allowing end hosts to set their initial cwnd to > whatever they want ... in the canonical form that we use to propose > such things ... Hi Marc, I really like and support this document. Wouldn't is make sense not to restrict this document to TCP, but also cover SCTP? Best regards Michael > > draft-allman-tcpm-no-initwin-00.txt > > allman > > > -- > http://www.icir.org/mallman/ > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Nov 25 12:06:25 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF941B2F2B for ; Wed, 25 Nov 2015 12:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAoHlj1cxIF6 for ; Wed, 25 Nov 2015 12:06:12 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC82F1B2F28 for ; Wed, 25 Nov 2015 12:06:12 -0800 (PST) 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 tAPK6BO1010262; Wed, 25 Nov 2015 12:06:11 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id AA87D33313A5; Wed, 25 Nov 2015 15:06:10 -0500 (EST) To: Michael Tuexen From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Play Guitar X-URL-0: http://www.icir.org/mallman-files/Document71424.xls MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 25 Nov 2015 15:06:10 -0500 Message-ID: <50225.1448481970@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Wed, 25 Nov 2015 20:06:16 -0000 --=-------459435943823349593450 Content-Type: text/plain > I really like and support this document. Wouldn't is make sense > not to restrict this document to TCP, but also cover SCTP? Absolutely. While I am kicking one beehive, I might as well kick two! :-) It is fun to know that I can still make enough noise to make people think. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZWFLIACgkQWyrrWs4yIs7/xwCfWtXWrcGZO+Gmk7N4QjLZC3Du xt8AoJ0mW/c9niW15aXzvAhsx61lyLaz =vi+x -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Wed Nov 25 13:30:34 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9FF1B30A2 for ; Wed, 25 Nov 2015 13:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.485 X-Spam-Level: X-Spam-Status: No, score=-7.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 699QL7CltS7X for ; Wed, 25 Nov 2015 13:30:32 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1631B30A1 for ; Wed, 25 Nov 2015 13:30:32 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tAPLU9wI018800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Nov 2015 13:30:12 -0800 (PST) To: mallman@icir.org, tcpm@ietf.org References: <72616.1448386988@lawyers.icir.org> <5656016A.2080504@isi.edu> From: Joe Touch Message-ID: <56562861.90503@isi.edu> Date: Wed, 25 Nov 2015 13:30:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5656016A.2080504@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 21:30:33 -0000 One other point to consider: If you're seeing loss, it also means you might be causing loss for others too. That's why we increase the window gently until we know better, and why getting one packet through might be permission to send another, but should not be interpreted as being safe to send a lot. Joe On 11/25/2015 10:43 AM, Joe Touch wrote: > I like the assumptions, esp. that AQM is widely deployed, but they're > just that - assumptions. > > I'd like to see some evidence this approach is safe first, because > pacing traffic out seems more likely to mask a "tragedy of the commons" > issue than bursting would have, esp. when AQM isn't available. > > Joe > > On 11/24/2015 9:43 AM, Mark Allman wrote: >> >> A proposal for allowing end hosts to set their initial cwnd to >> whatever they want ... in the canonical form that we use to propose >> such things ... >> >> draft-allman-tcpm-no-initwin-00.txt >> >> allman >> >> >> -- >> http://www.icir.org/mallman/ >> >> >> >> >> >> >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >> From nobody Wed Nov 25 13:34:32 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421E31B30B4 for ; Wed, 25 Nov 2015 13:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.485 X-Spam-Level: X-Spam-Status: No, score=-7.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me7uFpUeCwFL for ; Wed, 25 Nov 2015 13:34:29 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A20F1B30B9 for ; Wed, 25 Nov 2015 13:34:28 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tAPLXxNS019499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Nov 2015 13:34:00 -0800 (PST) To: Jeremy Harris , tcpm@ietf.org References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <56560456.6070704@wizmail.org> From: Joe Touch Message-ID: <56562947.8020803@isi.edu> Date: Wed, 25 Nov 2015 13:33:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56560456.6070704@wizmail.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 21:34:31 -0000 On 11/25/2015 10:56 AM, Jeremy Harris wrote: > On 20/11/15 14:40, SALLANTIN Renaud wrote: >> · Is there room to increase even more the Initial Window? Several major players already use IW=32 or higher (with and without pacing), that would really help for satellite communications. But the question here is how to mitigate the burst impact? > > In combination with larger IW, would there be benefit in packets > being marked for "no roundtrip yet"? During startup of a flow, > a bottleneck router could then fire a source-quench. See RF6633. Those messages are deprecated. > This would at least help the case where the bottleneck > is close to the source. The best we have is ECN marking, but that helps only for the return path ACKs, i.e., that'll take a round trip to react to. Joe From nobody Wed Nov 25 13:47:56 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4661B30E1 for ; Wed, 25 Nov 2015 13:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aMSYWztZzwo for ; Wed, 25 Nov 2015 13:47:53 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B451B30DF for ; Wed, 25 Nov 2015 13:47:53 -0800 (PST) Received: from [2a00:b900:109e:0:3e97:eff:feb2:e128] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_139-4deb125) id 1a1hup-0004fs-F1 (return-path ); Wed, 25 Nov 2015 21:47:51 +0000 To: Joe Touch , tcpm@ietf.org References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <56560456.6070704@wizmail.org> <56562947.8020803@isi.edu> From: Jeremy Harris Message-ID: <56562C86.4040406@wizmail.org> Date: Wed, 25 Nov 2015 21:47:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56562947.8020803@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:3e97:eff:feb2:e128] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 21:47:55 -0000 On 25/11/15 21:33, Joe Touch wrote: > > > On 11/25/2015 10:56 AM, Jeremy Harris wrote: >> On 20/11/15 14:40, SALLANTIN Renaud wrote: >>> · Is there room to increase even more the Initial Window? Several major players already use IW=32 or higher (with and without pacing), that would really help for satellite communications. But the question here is how to mitigate the burst impact? >> >> In combination with larger IW, would there be benefit in packets >> being marked for "no roundtrip yet"? During startup of a flow, >> a bottleneck router could then fire a source-quench. > > See RF6633. > > Those messages are deprecated. Large IW isn't permitted, either. We're discussing changes. -- Cheers, Jeremy From nobody Wed Nov 25 13:53:57 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936021A8AE4 for ; Wed, 25 Nov 2015 13:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.485 X-Spam-Level: X-Spam-Status: No, score=-7.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsIT62iv5f0w for ; Wed, 25 Nov 2015 13:53:55 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2181A8A48 for ; Wed, 25 Nov 2015 13:53:55 -0800 (PST) Received: from [128.9.184.98] ([128.9.184.98]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id tAPLrdYY004085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Nov 2015 13:53:39 -0800 (PST) To: Jeremy Harris , tcpm@ietf.org References: <9b39fe7d-76ff-4baa-be42-32d2e58833a8@THSONEA01HUB02P.one.grp> <56560456.6070704@wizmail.org> <56562947.8020803@isi.edu> <56562C86.4040406@wizmail.org> From: Joe Touch Message-ID: <56562DE2.4020107@isi.edu> Date: Wed, 25 Nov 2015 13:53:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56562C86.4040406@wizmail.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: touch@isi.edu Subject: Re: [tcpm] How to improve TCP efficiency in a large RTT context? X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 25 Nov 2015 21:53:56 -0000 On 11/25/2015 1:47 PM, Jeremy Harris wrote: > On 25/11/15 21:33, Joe Touch wrote: >> >> >> On 11/25/2015 10:56 AM, Jeremy Harris wrote: >>> On 20/11/15 14:40, SALLANTIN Renaud wrote: >>>> · Is there room to increase even more the Initial Window? Several major players already use IW=32 or higher (with and without pacing), that would really help for satellite communications. But the question here is how to mitigate the burst impact? >>> >>> In combination with larger IW, would there be benefit in packets >>> being marked for "no roundtrip yet"? During startup of a flow, >>> a bottleneck router could then fire a source-quench. >> >> See RF6633. >> >> Those messages are deprecated. > > Large IW isn't permitted, either. We're discussing changes. We don't typically "un-deprecate" things, though. Source quench is deprecated for a number of reasons, summarized in RFC 6633. It'd be useful to address those before assuming it can simply just start existing. Joe From nobody Thu Nov 26 02:30:14 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D6D1B3908 for ; Thu, 26 Nov 2015 02:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0fx7oInjhIn for ; Thu, 26 Nov 2015 02:30:11 -0800 (PST) Received: from thsbbfxrt02p.thalesgroup.com (thsbbfxrt02p.thalesgroup.com [192.93.158.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8921B3906 for ; Thu, 26 Nov 2015 02:30:11 -0800 (PST) Received: from thsbbfxrt02p.thalesgroup.com (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3p5wMP1FgYz299; Thu, 26 Nov 2015 11:30:09 +0100 (CET) X-Thales-IRT1: IRT11 From: SALLANTIN Renaud To: "mallman@icir.org" , "tcpm@ietf.org" Date: Thu, 26 Nov 2015 11:30:07 +0100 Thread-Topic: [tcpm] removing TCP's initial window Thread-Index: AdEm35oldRsVoownS6ahIQ3qPCDcFQBU5anw Message-ID: References: <72616.1448386988@lawyers.icir.org> In-Reply-To: <72616.1448386988@lawyers.icir.org> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR x-pmwin-version: 3.1.3.0, Antivirus-Engine: 3.60.0, Antivirus-Data: 5.21 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2015 10:30:13 -0000 Unlike for Jumpstart, you do not modify the TCP behavior after the IW trans= mission.=20 Don't you think that, in some cases, double the IW may trigger some congest= ion?=20 Would it be possible to refine the mechanism, and for example, determine wh= at should be used in the following RTTs (slow start or CC) in function of = the IW size?=20 [@@ THALES ALENIA SPACE INTERNAL @@] -----Message d'origine----- De=A0: tcpm [mailto:tcpm-bounces@ietf.org] De la part de Mark Allman Envoy=E9=A0: mardi 24 novembre 2015 18:43 =C0=A0: tcpm@ietf.org Objet=A0: [tcpm] removing TCP's initial window A proposal for allowing end hosts to set their initial cwnd to whatever the= y want ... in the canonical form that we use to propose such things ... draft-allman-tcpm-no-initwin-00.txt allman -- http://www.icir.org/mallman/ From nobody Thu Nov 26 11:28:00 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4581B2D25 for ; Thu, 26 Nov 2015 11:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5CUfqyoxRSZ for ; Thu, 26 Nov 2015 11:27:57 -0800 (PST) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.231]) by ietfa.amsl.com (Postfix) with ESMTP id CBE641B2D24 for ; Thu, 26 Nov 2015 11:27:56 -0800 (PST) Received: from t40700-la020.lan (80.223.92.46) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as saropa-1) id 5613C7B1017284F8; Thu, 26 Nov 2015 21:25:59 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Pasi Sarolahti In-Reply-To: <9826_1447836511_564C3B5E_9826_8_1_A4EDE80A-893B-423B-A1A7-317790857840@ifi.uio.no> Date: Thu, 26 Nov 2015 21:27:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7468519B-FFEE-4FDB-A34A-EFB5A2D736F6@iki.fi> <9826_1447836511_564C3B5E_9826_8_1_A4EDE80A-893B-423B-A1A7-317790857840@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "tcpm@ietf.org Extensions" Subject: Re: [tcpm] TCPM notes from IETF-94 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 26 Nov 2015 19:27:59 -0000 Hi Michael, Thanks for clarification. I will correct this part in the minutes, along = with the nit and couple of other updates, and will upload a new version = soon. - Pasi On 18 Nov 2015, at 10:48, Michael Welzl wrote: > Hi, >=20 > nit: s/what is write/what is right >=20 > Else: the transcription of what David Black said to Naeem Khademi on = the mic is misleading - it misses key bits that make it seem like a = different statement than it was: >=20 >=20 > The minutes say: > *** > David Black: RFC3168 says: don't do anything that breaks the Internet. = If there is a ECE, react to it the same way as with packet-loss. > *** >=20 > ... which makes it sound like this would be his advice and he would = opposed to experimental alternatives. However, what he really said is = (transcribed from Meetecho: > = http://recs.conf.meetecho.com/Playout/watch.jsp?recording=3DIETF94_TCPM&ch= apter=3Dchapter_1 at approx. 0:31): >=20 > *** > As one of the authors of RFC 3168: I agree that encouraging = Experimental for congestion control is a really good idea. > 3168 was written for the broad internet, hence contains some very = strict language that basically said don't do anything that would break = things. We had people react to congestion if you CE-mark as if you're = dropping a packet, we said: the only thing we know for certain is safe = right now - this was a long time ago - was: react to it as you would = react to a packet drop. I'm not opposed to interesting innovative things = being done under the guise of experimentation, I wanna provide some = history for why 3168 says what it does. > *** >=20 > The last sentence matters - it's really quite a different thing. >=20 > Cheers, > Michael >=20 >=20 >=20 >=20 >=20 >> On 16 Nov 2015, at 21:23, Pasi Sarolahti = wrote: >>=20 >> Hi, >>=20 >> The minutes of the Yokohama TCPM meeting are available at = https://www.ietf.org/proceedings/94/minutes/minutes-94-tcpm. Many thanks = to Christoph and David for compiling them! >>=20 >> If you have corrections to make, please send them to list, or = directly to chairs. >>=20 >> - Pasi >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Nov 30 06:30:39 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E315E1ACE10 for ; Mon, 30 Nov 2015 06:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwLJt2o9unSn for ; Mon, 30 Nov 2015 06:30:37 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D86D1ACE0E for ; Mon, 30 Nov 2015 06:30:37 -0800 (PST) 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 tAUEUZXS008333; Mon, 30 Nov 2015 06:30:35 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id C9394334ABF6; Mon, 30 Nov 2015 09:30:34 -0500 (EST) To: SALLANTIN Renaud From: Mark Allman In-Reply-To: Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Feel Like a Number X-URL-0: http://www.icir.org/mallman-files/Document22580.doc X-URL-1: http://www.icir.org/mallman-files/Document52583.html MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 30 Nov 2015 09:30:34 -0500 Message-ID: <81993.1448893834@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: "tcpm@ietf.org" Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 30 Nov 2015 14:30:38 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > Unlike for Jumpstart, you do not modify the TCP behavior after the > IW transmission. I am not sure if I follow. Regardless of what the IW is or how that is arrived at I think it is perfectly fine to send 2 * IW in the second RTT of data transmission if there was no loss in the first window of data. That is just traditional slow start. And, if an implementation wanted to somehow decide to transmit less than 2 * IW in the second RTT then that would also be fine with me. (I.e., you are always free to be more conservative than the spec allows.)=20 These two bits follow directly from the spec and would seem non-controversial to me. Does that answer the question? allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZcXYoACgkQWyrrWs4yIs7bAACbBoUemhkcqk5NnUOLUyc2uoqT 8WIAn1bWbIyvmYuwaB+N0+eR/0NHfjaI =6sGX -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Nov 30 08:02:40 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8761C1A01D7 for ; Mon, 30 Nov 2015 08:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HR8lPylYzSkC for ; Mon, 30 Nov 2015 08:02:37 -0800 (PST) Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3C41A01CB for ; Mon, 30 Nov 2015 08:02:36 -0800 (PST) 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 tAUG2XZ2016915; Mon, 30 Nov 2015 08:02:34 -0800 (PST) Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id E8EC3334EB96; Mon, 30 Nov 2015 11:02:31 -0500 (EST) To: Joe Touch From: Mark Allman In-Reply-To: <56562861.90503@isi.edu> Organization: International Computer Science Institute (ICSI) Song-of-the-Day: Feel Like a Number X-URL-0: http://www.icir.org/mallman-files/Document15242.doc X-URL-1: http://www.icir.org/mallman-files/Document94934.pdf MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-------459435943823349593450"; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 30 Nov 2015 11:02:31 -0500 Message-ID: <97817.1448899351@lawyers.icir.org> Sender: mallman@icir.org Archived-At: Cc: tcpm@ietf.org Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 30 Nov 2015 16:02:38 -0000 --=-------459435943823349593450 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > One other point to consider: >=20 > If you're seeing loss, it also means you might be causing > loss for others too. The dynamics are not that simple. E.g., if the other folks had started faster they might actually be out of the way when I start and not still sending. E.g., if I am seeing loss then that is bad for me. And, I don't have incentive to do bad things to myself. If the proposal would cause pain for others and not me then perhaps I'd buy this point more. But, I don't see that it will. So, in some sense my own self interest also serves to protect others. allman --=-------459435943823349593450 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlZccxUACgkQWyrrWs4yIs7Y+QCcDzUvDcqSSoOYDez2hkVbK2lZ j4YAoJsaavRV2q0LRXLBcNyM5TC3aqwz =bckl -----END PGP SIGNATURE----- --=-------459435943823349593450-- From nobody Mon Nov 30 10:07:53 2015 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78821B2ABB for ; Mon, 30 Nov 2015 10:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUb9tXdlCouB for ; Mon, 30 Nov 2015 10:07:51 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7D61B2AC0 for ; Mon, 30 Nov 2015 10:07:49 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-225-10.socal.res.rr.com [172.250.225.10]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id tAUI6vu2029250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 30 Nov 2015 10:07:07 -0800 (PST) To: mallman@icir.org References: <97817.1448899351@lawyers.icir.org> From: Joe Touch Message-ID: <565C9041.2000004@isi.edu> Date: Mon, 30 Nov 2015 10:06:57 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <97817.1448899351@lawyers.icir.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tcpm@ietf.org, touch@isi.edu Subject: Re: [tcpm] removing TCP's initial window X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.15 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, 30 Nov 2015 18:07:51 -0000 On 11/30/2015 8:02 AM, Mark Allman wrote: > >> One other point to consider: >> >> If you're seeing loss, it also means you might be causing >> loss for others too. > > The dynamics are not that simple. > > E.g., if the other folks had started faster they might actually be > out of the way when I start and not still sending. They might. They might not. I'll wager that my "might" is a "probably", though, because the chance that paced transmission is exactly the only thing dropped at a buffer is vanishingly small, given AQM. However, again this is a place where experiments would help, and the status-quo is the only viable position until we have evidence that cross-drops aren't the likely result. Joe