From nobody Mon Dec 3 00:34:52 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3599126C01 for ; Mon, 3 Dec 2018 00:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86ZqMSE2n0Vs for ; Mon, 3 Dec 2018 00:34:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 013B612777C for ; Mon, 3 Dec 2018 00:34:49 -0800 (PST) Received: from [0.0.0.0] ([213.143.121.76]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LgYuT-1hF9rS2wr7-00o2XD; Mon, 03 Dec 2018 09:34:36 +0100 To: =?UTF-8?Q?Ilpo_J=c3=a4rvinen?= Cc: Neal Cardwell , Felix Weinrank , "tcpm@ietf.org" References: <8d43389c-93c1-899d-37ab-808c471eed47@fh-muenster.de> <632bc671-4294-5eb3-ff8a-8c7dd492beb1@fh-muenster.de> <5f27394f-5f88-457d-5a2a-8ce4fcd80202@gmx.at> From: "Scheffenegger, Richard" Message-ID: <5e86631c-98f2-4945-c70e-ab00d1beb348@gmx.at> Date: Mon, 3 Dec 2018 09:34:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:5GNbNYSr3P8JkXWfB63h3Gr1QTY40KEev/8C0aJz208s9SZ0W87 cF/1ru2JG+N+wJBYO7AoJQXaMlAKkrZWsT29dQBzAgK6lRBVUOUfwG2GUZNWiriu+4iZs6Q oDcL/SXHuShPUrZfAr07Tpe+FvpHVKhdX3UYfdS/EXH2a368LEAHUehCkSP7x2aNpOwWuDr PyOyjqaLetmk8eV7uCGmA== X-UI-Out-Filterresults: notjunk:1;V03:K0:AMtDJCl4ldI=:cRy4tOB460Erfc4yjt3Nf9 U7YIYZ27sXs1oqPhI0vv6CxbQd1xUL3CvSfOKxG+vXbdIB+Y/0pqx3VkxKJq1UspRSvCIhSZP QckHGsdjd8/ckqhdVsUnzH7ZvQX9lChD9g682rSdYZXu10S0j4syMtZIn2tGdkUgTDxblkBw5 OAJDfSI7R4YYuzaKl9VyborniB6/PJ2bI8X9z2vNlskedm20V/40JhLFfRy0VRDDxnhAfKD3m S7r06D4duWBs7bTid+Qg/DiNtDbRi5KfTv1Gmmwnxie8oZBzPXHzpM44aCP9A11ah8J6ZBQrn b7W1knOF+gFdsl3ycXW+HENaWwPGE0GFuqE+r1TIuADH1vxsvh8cqf0rPUG0UN2b1XLCxPMXM 5JzIJ0pGz6p7bVd7gs2Mg6i/iEhFUqs/bEPUp+CfPtuMb+erfJU58XcRbZTC64PIyGt5jSlzH b7fkV/G3T1+LOzaAqlr/2yxI6xkk9KzxqmeufhYK4c3uIriKji0SmM23EQDGTMT5n1skJ6eQr Pg1zHE9h+MEpDCb0c8uCF26azVrYsqJGeELBA2E5+2F36IJ+hhyA6F1D7s+v0QttG3aMJ2Bzb 47uJOiTkXgkXvS9NQsiTvNESabjIQqJIEzPoFky+60kAbLilil6tK3Te+nolYILYIgG6M9Rg1 ZXs0GMgOiV9qi0N8J8YmmQC2MunT53pkuCmJV59P1adXhuGI5urI9e2c9D9G8TLuxg5iQN5ER CaQUIKAYvmb5IDFkSKJKN/yrCYUO/oDaxA0Or5BbsghDG87OtqvVhxpInXz0y3QnygQvYDD8R dnnVYlrR8hJ306EOP2O+HdqsTRLzs82AUmUUGkWf1nFUFYP0Yap4h6K/ENgPJNYrZLRGJravI Hednu5Vh9j5c63qbrmuze6QV3f/YTPVujKhHT+pBF7oKUX9gUphvR6mmK9uqfK Archived-At: Subject: Re: [tcpm] RACK - variable explanation X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 08:34:52 -0000 Am 28.11.2018 um 16:56 schrieb Ilpo Järvinen: > On Wed, 28 Nov 2018, Richard Scheffenegger wrote: >> Am 22.11.2018 um 17:16 schrieb Neal Cardwell: >>> On Thu, Nov 22, 2018 at 10:28 AM Felix Weinrank >>> wrote: >>>> >>>> I don't completely understand the following check: >>>> >>>> If RACK.reordering_seen is FALSE: >>>> If in loss recovery: /* If in fast or timeout recovery */ >>>> RACK.reo_wnd = 0 >>>> Return >>>> Else if RACK.pkts_sacked >= RACK.dupthresh: >>>> RACK.reo_wnd = 0 >>>> return >>>> >>>> The Draft says: >>>> "RACK.pkts_sacked" returns the total number of packets selectively >>>> acknowledged in the SACK scoreboard. >>>> >>>> Whats the purpose of this check: RACK.pkts_sacked >= RACK.dupthresh >>> >>> This is the traditional TCP Fast Retransmit heuristic, described in >>> https://tools.ietf.org/html/rfc5681 in section 3.2, and >>> https://tools.ietf.org/html/rfc6675 in section 5, and the older >>> https://tools.ietf.org/html/rfc2001 in section 3. >> >> To be pedandic, only RFC3517 and RFC6675 would be applicable directly, as RACK >> requires SACK support. >> >> Also, RFC6675 explicitly shortened the trigger condition from receiving 3 >> DupACKs down to FACK > (dupthresh - 1)*SMSS. > > Where does that "FACK" part come from? Not from RFC6675 for sure. The > condition given in RFC6675 requires at least that many bytes to be > acknowledged by SACK blocks to trigger recovery, not just sequence > distance like FACK does. : : > > RFC6675 algorithm requires a positive proof that at least 3 MSS sized > packets were delirered. The algorithm just doesn't use dup ACK as a proxy > for that but bases the decision on scoreboard details only. Maybe you're > misreading the RFC6675 somehow? Indeed, sorry for my confusion. So to sum up, entering LR with RACK has the same trigger condition as RFC6675 SACK. I did misread the IsLost(SeqNum) description there. From nobody Wed Dec 5 06:30:14 2018 Return-Path: X-Original-To: tcpm@ietf.org Delivered-To: tcpm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDC3126C01; Wed, 5 Dec 2018 06:30:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tcpm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <154402020786.31968.1103572371946773419@ietfa.amsl.com> Date: Wed, 05 Dec 2018 06:30:07 -0800 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-12.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 14:30:08 -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 WG of the IETF. Title : Transmission Control Protocol Specification Author : Wesley M. Eddy Filename : draft-ietf-tcpm-rfc793bis-12.txt Pages : 104 Date : 2018-12-05 Abstract: This document specifies the Internet's Transmission Control Protocol (TCP). TCP is an important transport layer protocol in the Internet stack, and has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFC 1122, and should be considered as a replacement for the portions of that document dealing with TCP requirements. It updates RFC 5961 due to a small clarification in reset handling while in the SYN-RECEIVED state. RFC EDITOR NOTE: If approved for publication as an RFC, this should be marked additionally as "STD: 7" and replace RFC 793 in that role. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-12 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-12 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 Wed Dec 5 06:48:08 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56866126C01 for ; Wed, 5 Dec 2018 06:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg0wSOPSfB0k for ; Wed, 5 Dec 2018 06:48:03 -0800 (PST) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 F1C0D124BF6 for ; Wed, 5 Dec 2018 06:48:02 -0800 (PST) Received: by mail-qk1-x734.google.com with SMTP id q1so11955403qkf.13 for ; Wed, 05 Dec 2018 06:48:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=dtibRQrLbJKojaVWS1s123/GILLlJRxQ6RRarGgSKg4=; b=DryzALpmT0G+3MoUHtQrOvihinQ87CrfrYvIcHel4lUzsqs2lHVjaLCXtJxPIkguR0 ZYpzMYHlqKQRdrJ2yKy9rhLwu48SQeJX6h9tN903DWJTGXFVLiD256F8rKGxtHNl321/ k+4l9UCWaW19Spzpzlx5DmKlQCTGg/QhvtRQv7gDrYzHxf89hti9JXRr+rdCtg8Z8qiH QyM+cHCsVRc4+i6hvpjwR70dDpl6HdFtRmAsI4WFGNKTrS9Pk0RL13V3BG8AWQoBbTqe AxMFRUTuyqs09CE82tfLYEnmwViEjg1oUzzXCMTbGr/hagwbTuPimqsx5z5gCndr/0j1 shjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=dtibRQrLbJKojaVWS1s123/GILLlJRxQ6RRarGgSKg4=; b=L/O/taKW48M8Ns8Yckzxe5i2mbKlJ61mIZNECHiK8YYsTa3koQsDt/MScHldekzLEW 49omJh1B7E1AeU+m7a1o+bWtEiIkRp4pMyQk9x34LfwJUqKth08pgUOM4pM0peSOpK4J iTngO+C4depAWw8z0lnRdWeOtnF09DPJ7wyECyotLyrut51pLBM+zfVNu/aZ2i53xn+3 y0WeFSItbcXYx/xlYOzlNJEMrY6X3/XQ+LLgMq9b8ZrNtxdy99BVepOaW0vwcZLy9AOh DIE68QwGZdT0FIksuwPCO1LakZDvpdXWccPyKOm1drf5vk9eCY9gK35mpnYm9E1U7lQv EpnQ== X-Gm-Message-State: AA+aEWbPVnmEJi5mY76i14hbGRGRXK1JrtXCZB9fX1BfYzfyW6hLReuM mb4mApt/AUqd+uYklVWeYBlQcbr6Lmo= X-Google-Smtp-Source: AFSGD/WvhucKST1j1LepOVyuE7/js/1PjqNG+p4OpRyo2fVJTU7zaDsLsSBD7LKUkA3BXYHHlmW9UA== X-Received: by 2002:a37:3409:: with SMTP id b9mr22636446qka.337.1544021281905; Wed, 05 Dec 2018 06:48:01 -0800 (PST) Received: from [192.168.1.105] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id z23sm17725938qkg.50.2018.12.05.06.48.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Dec 2018 06:48:01 -0800 (PST) To: tcpm@ietf.org From: Wesley Eddy Message-ID: <7ca44c90-3ef9-b177-2f29-db39045322c7@mti-systems.com> Date: Wed, 5 Dec 2018 09:47:59 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------96017791130FFAE005CDA892" Content-Language: en-US Archived-At: Subject: [tcpm] 793bis update X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 14:48:06 -0000 This is a multi-part message in MIME format. --------------96017791130FFAE005CDA892 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello, I've posted an update to the 793bis draft, with diffs available at: https://tools.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-12.txt Some changes worth commenting on and raising awareness of are: 1) There was some content missing on the proper PUSH behavior. It turned out that I hadn't previously brought this in correctly from RFC 1122. 2) I found an inconsistency between the description of "Asynchronous Reports" (from RFC 1122) and the description of error notifications to the application for incoming ICMP messages and excessive retransmissions.  In the specific sections that describe those, there are SHOULD statements about providing notification, but the Asynchronous Reports sections says "MUST". I think the MUST should be changed to a SHOULD in this section on page 54.  Your thoughts would be very helpful. 3) In section 3.9.2.3 I think there was a "must" that needed to become a "MUST".  The sentence in question is: An incoming SYN with an invalid source address MUST be ignored either by TCP or by the IP layer (MUST-63) (see Section 3.2.1.3 of [14]). 4) Similarly, in 3.10 I think there was a "should" that needs to be a "SHOULD": Segments with higher beginning sequence numbers SHOULD be held for later processing (SHLD-31). 5) In the RFC 1122 table of requirements, I think there was 1 spurious one that does not seem to relate to any actual sentence/requirement and seems to be a "MUST NOT" that would have been just a rephrasing of the MUST in MUST-37.  The item in the list just says: "Sender timeout OK conn with zero wind" with a checkmark in the "MUST NOT" column.  I believe this is the same as what we already have in MUST-37: As long as the receiving TCP continues to send acknowledgments in response to the probe segments, the sending TCP MUST allow the connection to stay open (MUST-37). Again, your thoughts on this would be helpful. I think altogether, the document is getting into pretty decent shape, so it would be good to hear some thoughts from the working group about it. (Note on page 7 there is an XML2RFC reference I'm trying to correct to not resolve to "Paragraph 5", so please don't beat me up on that for now). --------------96017791130FFAE005CDA892 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hello, I've posted an update to the 793bis draft, with diffs available at:

https://tools.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-12.txt


Some changes worth commenting on and raising awareness of are:

1) There was some content missing on the proper PUSH behavior.  It turned out that I hadn't previously brought this in correctly from RFC 1122.

2) I found an inconsistency between the description of "Asynchronous Reports" (from RFC 1122) and the description of error notifications to the application for incoming ICMP messages and excessive retransmissions.  In the specific sections that describe those, there are SHOULD statements about providing notification, but the Asynchronous Reports sections says "MUST".  I think the MUST should be changed to a SHOULD in this section on page 54.  Your thoughts would be very helpful.

3) In section 3.9.2.3 I think there was a "must" that needed to become a "MUST".  The sentence in question is:

      An incoming SYN with an invalid source address MUST be ignored
      either by TCP or by the IP layer (MUST-63) (see Section 3.2.1.3 of
      [14]).

4) Similarly, in 3.10 I think there was a "should" that needs to be a "SHOULD":

      Segments with higher beginning sequence numbers SHOULD be held for later
      processing (SHLD-31).

5) In the RFC 1122 table of requirements, I think there was 1 spurious one that does not seem to relate to any actual sentence/requirement and seems to be a "MUST NOT" that would have been just a rephrasing of the MUST in MUST-37.  The item in the list just says: "Sender timeout OK conn with zero wind" with a checkmark in the "MUST NOT" column.  I believe this is the same as what we already have in MUST-37:

   As long as the receiving TCP continues to send acknowledgments
   in response to the probe segments, the sending TCP MUST allow the
   connection to stay open (MUST-37).

Again, your thoughts on this would be helpful.

I think altogether, the document is getting into pretty decent shape, so it would be good to hear some thoughts from the working group about it.

(Note on page 7 there is an XML2RFC reference I'm trying to correct to not resolve to "Paragraph 5", so please don't beat me up on that for now).

--------------96017791130FFAE005CDA892-- From maolson@microsoft.com Tue Dec 4 15:26:20 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EABC130DC9 for ; Tue, 4 Dec 2018 15:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NMKJFOr5w8o for ; Tue, 4 Dec 2018 15:26:17 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740115.outbound.protection.outlook.com [40.107.74.115]) (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 B29EA124BE5 for ; Tue, 4 Dec 2018 15:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y709jT9RPgOnxde3EnxjYgU3eBwEca0evAoqoscspB8=; b=WAo9ai58nqCRyAraHuXchVEHn5M5dWQK/rOROicyq+NKzOWRcc/J6f9c1YFVa3WsFEswXOdzh0xp6ajD8G87B+udebTAf1Az0pixDayEuLmCXUeLfd82TF8p0fgSI8+1J2ZFXdq6yC/9mjhSYwxi1A5vQyI5aHnVcBwjnkxWf9A= Received: from CY4PR21MB0118.namprd21.prod.outlook.com (10.173.189.12) by CY4PR21MB0168.namprd21.prod.outlook.com (10.173.192.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.1; Tue, 4 Dec 2018 23:26:14 +0000 Received: from CY4PR21MB0118.namprd21.prod.outlook.com ([fe80::9c54:66df:6820:8006]) by CY4PR21MB0118.namprd21.prod.outlook.com ([fe80::9c54:66df:6820:8006%2]) with mapi id 15.20.1425.006; Tue, 4 Dec 2018 23:26:14 +0000 From: Matt Olson To: "tcpm@ietf.org" Thread-Topic: RFC 6675 SACK tracking Thread-Index: AdSMJigjQ8FMajp0TMaA29dkbqDV7Q== Date: Tue, 4 Dec 2018 23:26:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:b:687b:bb18:5d5a:5b1b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0168; 6:QFPF8PweK+tjr5iksWZ9uem6BoFNE70pmd8q34ysBXD5Tg5yra//pMD2iRmJ/niMi54/WynhIhLxe8gqF6TR+Tu8ZGgKtKAEPVOS7y1rmyGvBznzUV7/Kn517OifchssMyOG85oSPTz/SwJE46l4/j9pyd3SdammAyFyhNZhtTpxpoeJXue47r4qsfn6zkPtolJOSsK6WcDLbPL95A9jqKszJliWauO5gc1uukzofeIH1Vjwudql0F2uRpFlA8mV0+MFJqGMJ+4//Uqpdzx6OxQEGGmR3g3IOir9CXzdf0KGg1BERcFjthkbFHg0N1aJOj6nVtAwH6IjhIYmPoERa+1TbqwWRb3H1ANDv3VvpEHGqs07IPg+1mmlzVsJBE7e+dMKccr+2NXIJTkcc+XBru3uQa47rAlDjxv9landfzSM4+kq7KSBbK+swXFFfU4Y9kXo4Y0x3sbUEWERVrvmNg==; 5:0wRmHQFYFQu4ukFWDIuwR35jz3UzP6VwzAOhSB9+c9sh9UWl473ZEkeX/4Y4Bxk3rh0yryJHspQT+MLOHib8DRA2/MvHLiT9HhBN0mOiMlywRlVwHg82KfDQNFKTU1xf5g/Hh2i/YCuNoahqn4A7Gst1lsLvIRQMIore2F8NW0w=; 7:POAFPJUdu1cHSP06intWEb1COxfiVmmyWDY1LCPmkOyBHO9d6MzDqdDP5E0aG5jyW223+9aTxMpV3sWJrzVAGjWBbcAcR0pNqgKixC63aTgrPNC/3v9Qqe3jZjiUMruAXcD66jqr8/df44ORp3wQOg== x-ms-office365-filtering-correlation-id: 4726781f-9595-42fa-8b06-08d65a3fe274 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CY4PR21MB0168; x-ms-traffictypediagnostic: CY4PR21MB0168: x-ms-exchange-purlcount: 1 authentication-results: spf=none (sender IP is ) smtp.mailfrom=maolson@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(8220035)(2401047)(5005006)(8121501046)(10201501046)(3231455)(999002)(944501516)(2018427008)(93006095)(93001095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:CY4PR21MB0168; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0168; x-forefront-prvs: 0876988AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(376002)(346002)(366004)(396003)(199004)(189003)(8990500004)(316002)(74316002)(7736002)(966005)(478600001)(305945005)(99286004)(97736004)(102836004)(22452003)(53936002)(68736007)(7696005)(54906003)(86612001)(6506007)(10090500001)(86362001)(9686003)(46003)(6306002)(55016002)(6916009)(4326008)(107886003)(2501003)(486006)(476003)(81166006)(8676002)(5640700003)(8936002)(33656002)(81156014)(1730700003)(6436002)(25786009)(256004)(14444005)(71190400001)(71200400001)(10290500003)(105586002)(186003)(2906002)(14454004)(6116002)(7116003)(5660300001)(2351001)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0168; H:CY4PR21MB0118.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: J/2go4uHawmi8ir/vE9gPiUfw/KX7TQFIE7zC1a8IjxD7AcmqstXGdfooSZPvaqr9zthqY+chSkyoQFjv2mzvEjZfRuq2HsTIGs07ViZOBYsdWzo40sT4phm22j8lKghcqecNjEmptE8Vu58Pr0OChl4oVLYRyh+kOdHNNsJSRAGvQeogLTgqpFB9injYrYvILI1MGNb+1rLIvYi+JSpiQi7b0AhgRny2r9BUh1UbvlSy6bOaw8IkMzSEGjXY1LDi+VkCkYCHszoYt8K9MOPbnI/tJnYLtF106UgA0/rPT/pNsi9L5N56nyXSF+30Nlaun9aTCxuNLWQ0BImFt6Bo6AeNWzy/ub6PJO+cDoq3YQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4726781f-9595-42fa-8b06-08d65a3fe274 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2018 23:26:14.6290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0168 Archived-At: X-Mailman-Approved-At: Wed, 05 Dec 2018 08:01:46 -0800 Subject: [tcpm] RFC 6675 SACK tracking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 23:31:32 -0000 Hi, I have a question about the RFC 6675 conditions for determining bytes l= ost. Below I've pasted two relevant parts of the RFC. The conditions for ma= rking a byte lost are "2MSS or 3 discontiguous SACKed regions come after th= e byte." The paragraph below from Section 9 provides some rationale for the= "2MSS" part, which changed from RFC3517 (which had it as 3MSS): we want to= detect loss even when three sub-MSS packets after the byte made it to the = peer. In particular it says "this retains the requirement that at least thr= ee segments following the sequence number in question have been SACKed." Bu= t, this doesn't seem to add up: a single received SACK block covering 2MSS = might only represent two packets. Besides this inconsistency in the RFC, I wonder: why do we care about "disc= ontiguous SACKed regions" anyway? If we receive three ACKs, each with a SAC= K block that is a proper superset of the previous one, can't we conclude th= at three packets arrived at the peer and (following the spirit, if not the = letter, of RFC 6675) conclude that any bytes previous to the union of those= SACKs were lost? Even if together they SACK less than 2MSS bytes? Thanks! https://tools.ietf.org/html/rfc6675 >From section 4: IsLost (SeqNum): This routine returns whether the given sequence number is considered to be lost. The routine returns true when either DupThresh discontiguous SACKed sequences have arrived above 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence numbers greater than 'SeqNum' have been SACKed. Otherwise, the routine returns false. >From section 9: The function IsLost () has been modified to require that more than (DupThresh - 1) * SMSS octets have been SACKed above a given sequence number as indication that it is lost, which is changed from the minimum requirement of (DupThresh * SMSS) described in [RFC3517]. This retains the requirement that at least three segments following the sequence number in question have been SACKed, while improving detection in the event that the sender has outstanding segments which are smaller than SMSS. From nobody Wed Dec 5 08:32:01 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E327712D4F0 for ; Wed, 5 Dec 2018 08:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.96 X-Spam-Level: X-Spam-Status: No, score=-18.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r173KxIUQs8v for ; Wed, 5 Dec 2018 08:31:57 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 896EE1277BB for ; Wed, 5 Dec 2018 08:31:57 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id m19so17185168ioh.3 for ; Wed, 05 Dec 2018 08:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=E6f3wPlpvTNqnEOLvVYRDgBvAIZ7OUPqOkKgwlnwa2U=; b=ReHyUjvbo/P2NkiA+MczYpbzXwWNfba5kONb7hmPMiPqr4Tyyxj2Cs1qWFCLla+RwN i8agwPtkzsrorx/4ji4RWuOXohmd6cAkOjmfqSWBMCIZ2POp47ahiietznMnYq+ezE4G Bz1BoiOyRgSciMG7uVIOh6COX9YYiT74yjdFHg6Pdc7sih3GT6Yl4XSSlbj/VNuUjtzL ddiEebVd9yJLwuU6zOEIf2Km94lTCuE2zaICeHb07hMMlpu+rtBThCUMhxni1/OrpyRf mgvbNRwb5/WDAPAMkevJa9IvSPt00WK8Mrl1dsfSm9HJub/W+Hz8+aBv0HFrYhszVi1B VBdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=E6f3wPlpvTNqnEOLvVYRDgBvAIZ7OUPqOkKgwlnwa2U=; b=k9DEf1vToqIpUHHDcXhLS8YF+OhpYGN6ZKyCxDNklo4jcAg21CpH8PzrHoxWFqP1MU 28qaycKD/Iny0L4vyNvgnWeHsD/GbMVwIHmbcSCt+b60dYkAs124ftMO8rjDhawr7EOk v35zcUgZWMED1bYAkffH5zYQmxDZ6IRoKoujOyLOjYrNazvjELWl+LuTbLJpFzBPjwkA tcbSvvux7PPINbJc+RwlEtzucPNRCcV3878YGOMk2BekRFvJHpquPWarjIeIIEXckTSN mQ2ZaE/5fq1AnIyEi2qp9QQjfu+JPClsD0vxkCttQfzyvthE4k+cDi1T6dlkKMNq1VMo edWQ== X-Gm-Message-State: AA+aEWbfqmIXvrjmPeld7wFixZ80FjHNVfqi+E/kxhCP+RWm4JzApuLL uK4tEkqHjyvTzvKRd1cc27AanzNm4xTI7pyufk+7T0VkyEUj9g== X-Google-Smtp-Source: AFSGD/Vz059DbZ+gEg11t7neEH9u3EEzKmppHerZFwIO9pumZjqX/vvt3eiBcnIFZ1zY63mdBbBvP+zZrAeWbIn/sLg= X-Received: by 2002:a6b:9089:: with SMTP id s131mr23852140iod.242.1544027516479; Wed, 05 Dec 2018 08:31:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Wed, 5 Dec 2018 08:31:20 -0800 Message-ID: To: maolson=40microsoft.com@dmarc.ietf.org Cc: "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] RFC 6675 SACK tracking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 16:32:00 -0000 On Wed, Dec 5, 2018 at 8:02 AM Matt Olson wrote: > > Hi, I have a question about the RFC 6675 conditions for determining bytes= lost. Below I've pasted two relevant parts of the RFC. The conditions for = marking a byte lost are "2MSS or 3 discontiguous SACKed regions come after = the byte." The paragraph below from Section 9 provides some rationale for t= he "2MSS" part, which changed from RFC3517 (which had it as 3MSS): we want = to detect loss even when three sub-MSS packets after the byte made it to th= e peer. In particular it says "this retains the requirement that at least t= hree segments following the sequence number in question have been SACKed." = But, this doesn't seem to add up: a single received SACK block covering 2MS= S might only represent two packets. > > Besides this inconsistency in the RFC, I wonder: why do we care about "di= scontiguous SACKed regions" anyway? If we receive three ACKs, each with a S= ACK block that is a proper superset of the previous one, can't we conclude = that three packets arrived at the peer and (following the spirit, if not th= e letter, of RFC 6675) conclude that any bytes previous to the union of tho= se SACKs were lost? Even if together they SACK less than 2MSS bytes? In my opinion we should not care about the continuity of SACK, or even counting SACKs. I've proposed a new way to detect losses (implemented by Linux & NetFlix.BSD) https://tools.ietf.org/html/draft-ietf-tcpm-rack-04 > > Thanks! > > > > https://tools.ietf.org/html/rfc6675 > > >From section 4: > IsLost (SeqNum): > This routine returns whether the given sequence number is > considered to be lost. The routine returns true when either > DupThresh discontiguous SACKed sequences have arrived above > 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence > numbers greater than 'SeqNum' have been SACKed. Otherwise, the > routine returns false. > > >From section 9: > The function IsLost () has been modified to require that more than > (DupThresh - 1) * SMSS octets have been SACKed above a given sequence > number as indication that it is lost, which is changed from the > minimum requirement of (DupThresh * SMSS) described in [RFC3517]. > This retains the requirement that at least three segments following > the sequence number in question have been SACKed, while improving > detection in the event that the sender has outstanding segments which > are smaller than SMSS. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Dec 5 09:45:34 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4C130E8B for ; Wed, 5 Dec 2018 09:45:31 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR9Tfdul_juI for ; Wed, 5 Dec 2018 09:45:28 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CF4A12D4EB for ; Wed, 5 Dec 2018 09:45:28 -0800 (PST) Received: from mb.fritz.box (pD9F971F2.dip0.t-ipconnect.de [217.249.113.242]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id F369E721E2822; Wed, 5 Dec 2018 18:45:23 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Michael Tuexen In-Reply-To: Date: Wed, 5 Dec 2018 18:45:23 +0100 Cc: maolson=40microsoft.com@dmarc.ietf.org, "tcpm@ietf.org Extensions" Content-Transfer-Encoding: quoted-printable Message-Id: <84DE752E-C61A-4D70-9CD8-BD49F742836E@lurchi.franken.de> References: To: Yuchung Cheng X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [tcpm] RFC 6675 SACK tracking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 17:45:32 -0000 > On 5. Dec 2018, at 17:31, Yuchung Cheng = wrote: >=20 > On Wed, Dec 5, 2018 at 8:02 AM Matt Olson > wrote: >>=20 >> Hi, I have a question about the RFC 6675 conditions for determining = bytes lost. Below I've pasted two relevant parts of the RFC. The = conditions for marking a byte lost are "2MSS or 3 discontiguous SACKed = regions come after the byte." The paragraph below from Section 9 = provides some rationale for the "2MSS" part, which changed from RFC3517 = (which had it as 3MSS): we want to detect loss even when three sub-MSS = packets after the byte made it to the peer. In particular it says "this = retains the requirement that at least three segments following the = sequence number in question have been SACKed." But, this doesn't seem to = add up: a single received SACK block covering 2MSS might only represent = two packets. >>=20 >> Besides this inconsistency in the RFC, I wonder: why do we care about = "discontiguous SACKed regions" anyway? If we receive three ACKs, each = with a SACK block that is a proper superset of the previous one, can't = we conclude that three packets arrived at the peer and (following the = spirit, if not the letter, of RFC 6675) conclude that any bytes previous = to the union of those SACKs were lost? Even if together they SACK less = than 2MSS bytes? > In my opinion we should not care about the continuity of SACK, or even > counting SACKs. I've proposed a new way to detect losses (implemented > by Linux & NetFlix.BSD) It is in the FreeBSD code base and will be included in the upcoming = release 12.0. The code was contributed by Netflix. Best regards Michael >=20 > https://tools.ietf.org/html/draft-ietf-tcpm-rack-04 >=20 >>=20 >> Thanks! >>=20 >>=20 >>=20 >> https://tools.ietf.org/html/rfc6675 >>=20 >>> =46rom section 4: >> IsLost (SeqNum): >> This routine returns whether the given sequence number is >> considered to be lost. The routine returns true when either >> DupThresh discontiguous SACKed sequences have arrived above >> 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence >> numbers greater than 'SeqNum' have been SACKed. Otherwise, the >> routine returns false. >>=20 >>> =46rom section 9: >> The function IsLost () has been modified to require that more than >> (DupThresh - 1) * SMSS octets have been SACKed above a given = sequence >> number as indication that it is lost, which is changed from the >> minimum requirement of (DupThresh * SMSS) described in [RFC3517]. >> This retains the requirement that at least three segments following >> the sequence number in question have been SACKed, while improving >> detection in the event that the sender has outstanding segments = which >> are smaller than SMSS. >>=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 Wed Dec 5 10:57:26 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18E7130E95 for ; Wed, 5 Dec 2018 10:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiHhvcpexWIc for ; Wed, 5 Dec 2018 10:57:17 -0800 (PST) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-dm3nam05on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe51::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AF3130EE6 for ; Wed, 5 Dec 2018 10:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bScf1eRfX9G3UOKBVqUglpTAjVGZNeHEfF79zK4T/50=; b=kwRAwAkfLrI4EIqXE10Hctb2vONxWOE11wGoZ1FeV9vOx6bjs5LmKg8IwS2emjgDfxcIV9rzcYYb6+DEHSyOiDgfvt/bBknMdd0F7yvEl8STx+y7vTA7KciLSK5qxHX7vRqaWCdlauliQtn9R7Qns0a9IMnRFiRwqsfGABi+tbA= Received: from MW2PR2101MB1049.namprd21.prod.outlook.com (52.132.149.13) by MW2PR2101MB0890.namprd21.prod.outlook.com (52.132.152.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.4; Wed, 5 Dec 2018 18:57:12 +0000 Received: from MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a]) by MW2PR2101MB1049.namprd21.prod.outlook.com ([fe80::89e4:5371:41cc:d24a%4]) with mapi id 15.20.1425.006; Wed, 5 Dec 2018 18:57:12 +0000 From: Praveen Balasubramanian To: Michael Tuexen , Yuchung Cheng CC: "maolson=40microsoft.com@dmarc.ietf.org" , "tcpm@ietf.org Extensions" Thread-Topic: [tcpm] RFC 6675 SACK tracking Thread-Index: AdSMJigjQ8FMajp0TMaA29dkbqDV7QAkcvIAAAKWD4AAAlGp4A== Date: Wed, 5 Dec 2018 18:57:12 +0000 Message-ID: References: <84DE752E-C61A-4D70-9CD8-BD49F742836E@lurchi.franken.de> In-Reply-To: <84DE752E-C61A-4D70-9CD8-BD49F742836E@lurchi.franken.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:b:4d9:f2bf:b4c5:f950] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MW2PR2101MB0890; 6:2V4pv1bFRkTGNEt09E/E1EC2goTO9MFrnbzzYgeeqegaEl6RN51Zy2fRm8H/T5GLyIUOJEW1DMAxQNVEl00L901tCmiHeK1FJKeGA4I27/TwI9SZ9SmVObgDA2TayG17DFDd4GHBRdtoxNVV1oelFs0wLmemCEo98tEwO7ZWVf7EglD22nakwvqoUUgydI0TX19q/0TDZFFX5fFWDN8iLA/2NVW89AK5+8h+ZZ3S6iuzvG/11HkkYfYKWti42Gs006ziZc5Am6Opco04KVwYXgC8GEoZBrEtpbAa5GytGnBMOSPUJbzXn8eUILiKl8WyPL8/aXJydY3PESBMpbe9phjpolwtsyM5G8S8eoNFBgX/doiuLOdRnHtbpGbHNhW00eKFkRyYFv/edgJqgWEZosx/qCP/PCiWv0WxE/bqAaIr8GfPltGjhHCDmgGqYWodHf8I8RCyHR1FdDaGAcdN3A==; 5:SoYu5/0OaCZurkPQAw963M7cwF6Tm/x/vB5+GpwByTJEfwwoBEMaSbl9beyckA3S2m8XELyd1fZdZxN4DqpiS+WeBCUn0LiXU3Gxrnxf8VNegfSy//+VpVUSmaX5nnMC5cbwZXfV7ycExeDeW1KYBoR0KJpJbvrdL5e/65TvsBY=; 7:FvHIxsZiBUgot3PzMImz2XclBeRIM0Fe0Zdb7BtX2lC7GJj6S6TD8+X2mfTjW+/BQSe/jvjBX+gn8sfx9XvcfRD/qDHxDo+Vl6ukbXAK5b9pc9U9rLtIbag4kS/v/WbyC3Uq6VoVo2REjYcGOslA8Q== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 59406b78-92ee-4ba9-3f79-08d65ae3774d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:MW2PR2101MB0890; x-ms-traffictypediagnostic: MW2PR2101MB0890: x-ms-exchange-purlcount: 5 authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230008)(999002)(6040522)(8220035)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231463)(944501520)(2018427008)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:MW2PR2101MB0890; BCL:0; PCL:0; RULEID:; SRVR:MW2PR2101MB0890; x-forefront-prvs: 08770259B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(136003)(396003)(366004)(189003)(199004)(13464003)(33656002)(8990500004)(105586002)(10090500001)(74316002)(7736002)(5660300001)(305945005)(106356001)(81166006)(10290500003)(97736004)(6436002)(2906002)(25786009)(229853002)(6116002)(256004)(14444005)(14454004)(966005)(8936002)(81156014)(8676002)(68736007)(446003)(476003)(486006)(11346002)(99286004)(76176011)(7696005)(53936002)(316002)(478600001)(4326008)(71190400001)(71200400001)(6246003)(54906003)(110136005)(6306002)(9686003)(55016002)(46003)(575784001)(86612001)(53546011)(102836004)(6506007)(186003)(86362001)(22452003); DIR:OUT; SFP:1102; SCL:1; SRVR:MW2PR2101MB0890; H:MW2PR2101MB1049.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: b/xWxOWyhnYDbsdAoxLV4jfHcOoTReUvVvgRW6Q6fAQqd9o70/b/mHpiBUE4d0J+D92jB3fckgANLdcjpZZtU5gB29WRyVcd7bVle6WIHdUoZyzBeJTyKwEwBzdtRSJvNWiVUjDW50aAnG2rvEC66wXL1qR6FK6NZJhMiECsouF40CmQnJRuw5qTihGb6au3PyMSO/yNZ5RHQRx+wVVayJ1kBwwajpr3V4Vx241d40oTQJza5q0XI+4aIBwGdgdqvoVPZumd2gseZbctimCa1D8IncAMuZroGrl9s91RCUcO/W7lh7by8NJbUVO7FJkzI7t7mdKG/2E81GRWSFODjTDoGTshMtqI5dS1laxaIck= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59406b78-92ee-4ba9-3f79-08d65ae3774d X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2018 18:57:12.4030 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB0890 Archived-At: Subject: Re: [tcpm] RFC 6675 SACK tracking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 18:57:23 -0000 It is understood that RACK loss detection doesn't have any ambiguity and mo= st of it is implemented in Windows as an addendum to 6675. But RFC 6675 is = Standards Track and is implemented in several OS versions that are deployed= . Can someone with historical context please chime in on what the intent wa= s so we can resolve the inconsistency and also clarify the requirement arou= nd continuity?=20 -----Original Message----- From: tcpm On Behalf Of Michael Tuexen Sent: Wednesday, December 5, 2018 9:45 AM To: Yuchung Cheng Cc: maolson=3D40microsoft.com@dmarc.ietf.org; tcpm@ietf.org Extensions Subject: Re: [tcpm] RFC 6675 SACK tracking > On 5. Dec 2018, at 17:31, Yuchung Cheng wrote: >=20 > On Wed, Dec 5, 2018 at 8:02 AM Matt Olson=20 > wrote: >>=20 >> Hi, I have a question about the RFC 6675 conditions for determining byte= s lost. Below I've pasted two relevant parts of the RFC. The conditions for= marking a byte lost are "2MSS or 3 discontiguous SACKed regions come after= the byte." The paragraph below from Section 9 provides some rationale for = the "2MSS" part, which changed from RFC3517 (which had it as 3MSS): we want= to detect loss even when three sub-MSS packets after the byte made it to t= he peer. In particular it says "this retains the requirement that at least = three segments following the sequence number in question have been SACKed."= But, this doesn't seem to add up: a single received SACK block covering 2M= SS might only represent two packets. >>=20 >> Besides this inconsistency in the RFC, I wonder: why do we care about "d= iscontiguous SACKed regions" anyway? If we receive three ACKs, each with a = SACK block that is a proper superset of the previous one, can't we conclude= that three packets arrived at the peer and (following the spirit, if not t= he letter, of RFC 6675) conclude that any bytes previous to the union of th= ose SACKs were lost? Even if together they SACK less than 2MSS bytes? > In my opinion we should not care about the continuity of SACK, or even=20 > counting SACKs. I've proposed a new way to detect losses (implemented=20 > by Linux & NetFlix.BSD) It is in the FreeBSD code base and will be included in the upcoming release= 12.0. The code was contributed by Netflix. Best regards Michael >=20 > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools > .ietf.org%2Fhtml%2Fdraft-ietf-tcpm-rack-04&data=3D02%7C01%7Cpravb%40 > microsoft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91a > b2d7cd011db47%7C1%7C0%7C636796287446259136&sdata=3Dx14zcF4RSsfSPb3lw > 9zkfpcLZPYpWJZXllTcWOJZwhA%3D&reserved=3D0 >=20 >>=20 >> Thanks! >>=20 >>=20 >>=20 >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftool >> s.ietf.org%2Fhtml%2Frfc6675&data=3D02%7C01%7Cpravb%40microsoft.com% >> 7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7cd011db47 >> %7C1%7C0%7C636796287446259136&sdata=3Dlc8lSSoypNl7PjuqVu2KYxjq3o971 >> oCMy4idlXDRWnk%3D&reserved=3D0 >>=20 >>> From section 4: >> IsLost (SeqNum): >> This routine returns whether the given sequence number is >> considered to be lost. The routine returns true when either >> DupThresh discontiguous SACKed sequences have arrived above >> 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence >> numbers greater than 'SeqNum' have been SACKed. Otherwise, the >> routine returns false. >>=20 >>> From section 9: >> The function IsLost () has been modified to require that more than >> (DupThresh - 1) * SMSS octets have been SACKed above a given sequence >> number as indication that it is lost, which is changed from the >> minimum requirement of (DupThresh * SMSS) described in [RFC3517]. >> This retains the requirement that at least three segments following >> the sequence number in question have been SACKed, while improving >> detection in the event that the sender has outstanding segments which >> are smaller than SMSS. >>=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micro >> soft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7 >> cd011db47%7C1%7C0%7C636796287446259136&sdata=3DIqnoUOScKKei3PwnYM%2 >> B0HmbrY1EScWdIZoYlGvhAiUU%3D&reserved=3D0 >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i > etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microso > ft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7cd0 > 11db47%7C1%7C0%7C636796287446259136&sdata=3DIqnoUOScKKei3PwnYM%2B0Hm > brY1EScWdIZoYlGvhAiUU%3D&reserved=3D0 _______________________________________________ tcpm mailing list tcpm@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf= .org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.com= %7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7cd011db47%7C1%= 7C0%7C636796287446259136&sdata=3DIqnoUOScKKei3PwnYM%2B0HmbrY1EScWdIZoYl= GvhAiUU%3D&reserved=3D0 From nobody Wed Dec 5 11:12:12 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22E96130F09 for ; Wed, 5 Dec 2018 11:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.959 X-Spam-Level: X-Spam-Status: No, score=-18.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrhdNa_WGzN0 for ; Wed, 5 Dec 2018 11:11:59 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::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 35BF0130F0A for ; Wed, 5 Dec 2018 11:11:57 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id y23so18550674oia.4 for ; Wed, 05 Dec 2018 11:11:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OYFgfQHbpk+OKjGmUKniJO43wXYIKDNEqg0p0o1WgHE=; b=VDRdI35cmPCtU0f5ad6bfrPB6AgzeSYfVDeKry6fx/twUucTDgfic5vuPZMZ6zsDx+ +v7Zmt9kQHKqmgiGoXjKXp/DXk+0myhds4zJsN5N0uk6nCUfyw+d3AZ7QLtHYNx5AIZS gAwhoFOizI5SGo0VWocbBK/jWfHJxdprBnIDF9dsbyuyo9TXAB2MprxsNhwat4LB4VGW 0pHIdPqPZ8kYO6csVZdslfCvycdRvMSAep/U9SbHuZnTTV5tqRGe7UZjY+eVNUdr0d/R d6Ou0VfD5Wg5GUWrkqngB9eoWyoAzwbavUMvXexOzmVpR4GK9dmzd75bk+akqduGiE/t 1SAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OYFgfQHbpk+OKjGmUKniJO43wXYIKDNEqg0p0o1WgHE=; b=s/gmp6pIuJlYPN4vfFGIrPfXaBZ/5KjEKshH5EupLWgr8tQ5Ru2np5fddok4mUjwpa d9qzQsIgGEbBTperGwmsSYAfkVQPlDeehY1NYHkhqv6U0hvXMWYA9C6ZVmTEc8JHReBk i5RPD5OsUoiklzNwraVfIZ/MyFV92J+GMNXNGtnZQbzW2OfEYuw+7XuBjaiDkv/7tP9X 2BYNwttt39Y4g0cbULPrtjpLjRjlaaummaKAqEr+CVTzpUWEFtfGFfCH7khHH0u/GTtS rgjl+CssjtnRcx7dio8mTH+r4Hlu2V9WomocMs+Jbs3qo9EP2Cz1GG9ojfRiPiECfOVP 552A== X-Gm-Message-State: AA+aEWby3tdtokSH9c7vu1iJ7ZVV9EaWtC+ladQebml6nqZsmyhFGvfE r7Px/xenYodaV7T+tiWgTILy+mNspn9NDGQWvsf1fw== X-Google-Smtp-Source: AFSGD/UzKPTyI4Dug5cP4GamdwI2lF53aDX6T/Ojm1uLAVb8KexVcJRsJjf+CC4wWkDqHu2K+Mtmr38Bh2fBtzXWrfg= X-Received: by 2002:aca:1e08:: with SMTP id m8mr15064260oic.347.1544037115999; Wed, 05 Dec 2018 11:11:55 -0800 (PST) MIME-Version: 1.0 References: <84DE752E-C61A-4D70-9CD8-BD49F742836E@lurchi.franken.de> In-Reply-To: From: Neal Cardwell Date: Wed, 5 Dec 2018 14:11:39 -0500 Message-ID: To: pravb=40microsoft.com@dmarc.ietf.org Cc: Michael Tuexen , ycheng=40google.com@dmarc.ietf.org, maolson=40microsoft.com@dmarc.ietf.org, "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d22776057c4b2791" Archived-At: Subject: Re: [tcpm] RFC 6675 SACK tracking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 19:12:09 -0000 --000000000000d22776057c4b2791 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If we take RFC 6675 literally, I don't think there is an inconsistency. Importantly, I don't think it quite says: "2MSS or 3 discontiguous SACKed regions come after the byte." In section 4 (IsLost) and Section 9 (Changes Relative to RFC 3517), it says "more than (DupThresh - 1) * SMSS" bytes have been SACKed. DupThresh is 3, so that means "more than 2*SMSS". To get more than 2*SMSS requires at least 3 segments. So that requirement seems to mean essentially 3 or more segments, where one of those segments may not be full sized. So I think that is consistent with the statement: This retains the requirement that at least three segments following the sequence number in question have been SACKed Does that sound plausible? neal On Wed, Dec 5, 2018 at 1:57 PM Praveen Balasubramanian wrote: > It is understood that RACK loss detection doesn't have any ambiguity and > most of it is implemented in Windows as an addendum to 6675. But RFC 6675 > is Standards Track and is implemented in several OS versions that are > deployed. Can someone with historical context please chime in on what the > intent was so we can resolve the inconsistency and also clarify the > requirement around continuity? > > -----Original Message----- > From: tcpm On Behalf Of Michael Tuexen > Sent: Wednesday, December 5, 2018 9:45 AM > To: Yuchung Cheng > Cc: maolson=3D40microsoft.com@dmarc.ietf.org; tcpm@ietf.org Extensions < > tcpm@ietf.org> > Subject: Re: [tcpm] RFC 6675 SACK tracking > > > On 5. Dec 2018, at 17:31, Yuchung Cheng 40google.com@dmarc.ietf.org> wrote: > > > > On Wed, Dec 5, 2018 at 8:02 AM Matt Olson > > wrote: > >> > >> Hi, I have a question about the RFC 6675 conditions for determining > bytes lost. Below I've pasted two relevant parts of the RFC. The conditio= ns > for marking a byte lost are "2MSS or 3 discontiguous SACKed regions come > after the byte." The paragraph below from Section 9 provides some rationa= le > for the "2MSS" part, which changed from RFC3517 (which had it as 3MSS): w= e > want to detect loss even when three sub-MSS packets after the byte made i= t > to the peer. In particular it says "this retains the requirement that at > least three segments following the sequence number in question have been > SACKed." But, this doesn't seem to add up: a single received SACK block > covering 2MSS might only represent two packets. > >> > >> Besides this inconsistency in the RFC, I wonder: why do we care about > "discontiguous SACKed regions" anyway? If we receive three ACKs, each wit= h > a SACK block that is a proper superset of the previous one, can't we > conclude that three packets arrived at the peer and (following the spirit= , > if not the letter, of RFC 6675) conclude that any bytes previous to the > union of those SACKs were lost? Even if together they SACK less than 2MSS > bytes? > > In my opinion we should not care about the continuity of SACK, or even > > counting SACKs. I've proposed a new way to detect losses (implemented > > by Linux & NetFlix.BSD) > It is in the FreeBSD code base and will be included in the upcoming > release 12.0. > The code was contributed by Netflix. > > Best regards > Michael > > > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftool= s > > .ietf.org%2Fhtml%2Fdraft-ietf-tcpm-rack-04&data=3D02%7C01%7Cpravb%4= 0 > > microsoft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91a > > b2d7cd011db47%7C1%7C0%7C636796287446259136&sdata=3Dx14zcF4RSsfSPb3l= w > > 9zkfpcLZPYpWJZXllTcWOJZwhA%3D&reserved=3D0 > > > >> > >> Thanks! > >> > >> > >> > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftoo= l > >> s.ietf.org%2Fhtml%2Frfc6675&data=3D02%7C01%7Cpravb%40microsoft.com= % > >> 7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7cd011db47 > >> %7C1%7C0%7C636796287446259136&sdata=3Dlc8lSSoypNl7PjuqVu2KYxjq3o97= 1 > >> oCMy4idlXDRWnk%3D&reserved=3D0 > >> > >>> From section 4: > >> IsLost (SeqNum): > >> This routine returns whether the given sequence number is > >> considered to be lost. The routine returns true when either > >> DupThresh discontiguous SACKed sequences have arrived above > >> 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence > >> numbers greater than 'SeqNum' have been SACKed. Otherwise, the > >> routine returns false. > >> > >>> From section 9: > >> The function IsLost () has been modified to require that more than > >> (DupThresh - 1) * SMSS octets have been SACKed above a given sequenc= e > >> number as indication that it is lost, which is changed from the > >> minimum requirement of (DupThresh * SMSS) described in [RFC3517]. > >> This retains the requirement that at least three segments following > >> the sequence number in question have been SACKed, while improving > >> detection in the event that the sender has outstanding segments whic= h > >> are smaller than SMSS. > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > >> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micr= o > >> soft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7 > >> cd011db47%7C1%7C0%7C636796287446259136&sdata=3DIqnoUOScKKei3PwnYM%= 2 > >> B0HmbrY1EScWdIZoYlGvhAiUU%3D&reserved=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= i > > etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40micros= o > > ft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7cd0 > > 11db47%7C1%7C0%7C636796287446259136&sdata=3DIqnoUOScKKei3PwnYM%2B0H= m > > brY1EScWdIZoYlGvhAiUU%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microsoft.c= om%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C636796287446259136&sdata=3DIqnoUOScKKei3PwnYM%2B0HmbrY1EScWdIZo= YlGvhAiUU%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000d22776057c4b2791 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If we t= ake RFC 6675 literally, I don't think there is an inconsistency. Import= antly, I don't think it quite says: "2MSS or 3 discontiguous SACKe= d regions come after the byte."=C2=A0

= In section 4 (IsLost) and Section 9 (Changes Relative to RFC 3517), it says= "more than (DupThresh - 1) * SMSS" bytes have been SACKed.=C2=A0= DupThresh is 3, so that means "more than 2*SMSS". To get more th= an 2*SMSS requires at least 3 segments. So that requirement seems to mean e= ssentially 3 or more segments, where one of those segments may not be full = sized.

So I think that is = consistent with the statement:

=C2=A0 This retains the requirement that at least three segments follo= wing
=C2=A0 =C2=A0the sequence number in qu= estion have been SACKed

Does that sound plau= sible?

neal

=
On Wed, Dec 5, 2018 at 1:57= PM Praveen Balasubramanian <pravb=3D40microsoft.com@dmarc.ietf.org> wrote:
It is understood that RACK loss detection doesn&#= 39;t have any ambiguity and most of it is implemented in Windows as an adde= ndum to 6675. But RFC 6675 is Standards Track and is implemented in several= OS versions that are deployed. Can someone with historical context please = chime in on what the intent was so we can resolve the inconsistency and als= o clarify the requirement around continuity?

-----Original Message-----
From: tcpm <t= cpm-bounces@ietf.org> On Behalf Of Michael Tuexen
Sent: Wednesday, December 5, 2018 9:45 AM
To: Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org>
Cc: maolson=3D40microsoft.com@dmarc.ietf.org; tcpm@ietf.org Extensions <tcpm@ietf.org>
Subject: Re: [tcpm] RFC 6675 SACK tracking

> On 5. Dec 2018, at 17:31, Yuchung Cheng <ycheng=3D40google.com@dmarc.ietf.org= > wrote:
>
> On Wed, Dec 5, 2018 at 8:02 AM Matt Olson
> <maolson=3D40microsoft.com@dmarc.ietf.org> wrote:
>>
>> Hi, I have a question about the RFC 6675 conditions for determinin= g bytes lost. Below I've pasted two relevant parts of the RFC. The cond= itions for marking a byte lost are "2MSS or 3 discontiguous SACKed reg= ions come after the byte." The paragraph below from Section 9 provides= some rationale for the "2MSS" part, which changed from RFC3517 (= which had it as 3MSS): we want to detect loss even when three sub-MSS packe= ts after the byte made it to the peer. In particular it says "this ret= ains the requirement that at least three segments following the sequence nu= mber in question have been SACKed." But, this doesn't seem to add = up: a single received SACK block covering 2MSS might only represent two pac= kets.
>>
>> Besides this inconsistency in the RFC, I wonder: why do we care ab= out "discontiguous SACKed regions" anyway? If we receive three AC= Ks, each with a SACK block that is a proper superset of the previous one, c= an't we conclude that three packets arrived at the peer and (following = the spirit, if not the letter, of RFC 6675) conclude that any bytes previou= s to the union of those SACKs were lost? Even if together they SACK less th= an 2MSS bytes?
> In my opinion we should not care about the continuity of SACK, or even=
> counting SACKs. I've proposed a new way to detect losses (implemen= ted
> by Linux & NetFlix.BSD)
It is in the FreeBSD code base and will be included in the upcoming release= 12.0.
The code was contributed by Netflix.

Best regards
Michael
>
> https://na01.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools
> .ietf= .org%2Fhtml%2Fdraft-ietf-tcpm-rack-04&amp;data=3D02%7C01%7Cpravb%40=
> = microsoft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91a<= br> > b2d7cd011db47%7C1%7C0%7C636796287446259136&amp;sdata=3Dx14zcF4RSsf= SPb3lw
> 9zkfpcLZPYpWJZXllTcWOJZwhA%3D&amp;reserved=3D0
>
>>
>> Thanks!
>>
>>
>>
>> https://na01.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftool
>> s.ietf.org%2Fhtml%2Frfc6675&amp;data=3D02%7C01%7Cpravb%40microsoft.co= m%
>> 7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7cd011d= b47
>> %7C1%7C0%7C636796287446259136&amp;sdata=3Dlc8lSSoypNl7PjuqVu2K= Yxjq3o971
>> oCMy4idlXDRWnk%3D&amp;reserved=3D0
>>
>>> From section 4:
>> IsLost (SeqNum):
>>=C2=A0 =C2=A0 =C2=A0 This routine returns whether the given sequenc= e number is
>>=C2=A0 =C2=A0 =C2=A0 considered to be lost.=C2=A0 The routine retur= ns true when either
>>=C2=A0 =C2=A0 =C2=A0 DupThresh discontiguous SACKed sequences have = arrived above
>>=C2=A0 =C2=A0 =C2=A0 'SeqNum' or more than (DupThresh - 1) = * SMSS bytes with sequence
>>=C2=A0 =C2=A0 =C2=A0 numbers greater than 'SeqNum' have bee= n SACKed.=C2=A0 Otherwise, the
>>=C2=A0 =C2=A0 =C2=A0 routine returns false.
>>
>>> From section 9:
>>=C2=A0 =C2=A0The function IsLost () has been modified to require th= at more than
>>=C2=A0 =C2=A0(DupThresh - 1) * SMSS octets have been SACKed above a= given sequence
>>=C2=A0 =C2=A0number as indication that it is lost, which is changed= from the
>>=C2=A0 =C2=A0minimum requirement of (DupThresh * SMSS) described in= [RFC3517].
>>=C2=A0 =C2=A0This retains the requirement that at least three segme= nts following
>>=C2=A0 =C2=A0the sequence number in question have been SACKed, whil= e improving
>>=C2=A0 =C2=A0detection in the event that the sender has outstanding= segments which
>>=C2=A0 =C2=A0are smaller than SMSS.
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.
>> i= etf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40mi= cro
>> s= oft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7 >> cd011db47%7C1%7C0%7C636796287446259136&amp;sdata=3DIqnoUOScKKe= i3PwnYM%2
>> B0HmbrY1EScWdIZoYlGvhAiUU%3D&amp;reserved=3D0
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://na01.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i
> etf.or= g%2Fmailman%2Flistinfo%2Ftcpm&amp;data=3D02%7C01%7Cpravb%40microso<= br> > ft.com<= /a>%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7cd0
> 11db47%7C1%7C0%7C636796287446259136&amp;sdata=3DIqnoUOScKKei3PwnYM= %2B0Hm
> brY1EScWdIZoYlGvhAiUU%3D&amp;reserved=3D0

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

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000d22776057c4b2791-- From nobody Wed Dec 5 11:29:07 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB419130EDA for ; Wed, 5 Dec 2018 11:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 qh-Y5aj_oYO0 for ; Wed, 5 Dec 2018 11:29:02 -0800 (PST) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D47130E13 for ; Wed, 5 Dec 2018 11:29:01 -0800 (PST) X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 mail.cs.helsinki.fi Wed, 05 Dec 2018 21:28:54 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type; s=dkim20130528; bh=StHJyLAwW6QX9I/wq f773bTR9x+Uz4/5BwN6NhvlveM=; b=SAH5Ub/inRyDjmWIcPgCXMLOB+I0XRJuF GFmyiaHslmpRK3JhL14nO8qu4m7MboNJ5CLwuiXPLzAeaoV/S8db8Y5ENOlDiO5U 8bc9wjUvXqzYwCb7iJCVC5loY6MZyNXdIySKIYHDKbsvXb8Rt6gsgUQQOo4bDzh9 ss1u+0S4N4= Received: from dx6-cs-02.pc.helsinki.fi (dx6-cs-02.pc.helsinki.fi [193.167.160.58]) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by mail.cs.helsinki.fi with ESMTPSA; Wed, 05 Dec 2018 21:28:54 +0200 id 00000000005A014E.000000005C0826F6.000077FD Date: Wed, 5 Dec 2018 21:28:54 +0200 (EET) From: Markku Kojo X-X-Sender: kojo@dx6-cs-02.pc.helsinki.fi To: Neal Cardwell cc: pravb=40microsoft.com@dmarc.ietf.org, maolson=40microsoft.com@dmarc.ietf.org, Michael Tuexen , ycheng=40google.com@dmarc.ietf.org, "tcpm@ietf.org" In-Reply-To: Message-ID: References: <84DE752E-C61A-4D70-9CD8-BD49F742836E@lurchi.franken.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_script-30741-1544038134-0001-2" Archived-At: Subject: Re: [tcpm] RFC 6675 SACK tracking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 19:29:06 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_script-30741-1544038134-0001-2 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable This is exactly the correct interpretation, so no inconsistency. And the other rule ("DupThresh discontiguous SACKed sequences")=20 should be obvious: DupThresh discontiguous SACKed sequences is an=20 alternative way to guarantee that at least DupThresh segments following the sequence number in question have been SACKed, regardless of the size=20 of the segments. /Markku On Wed, 5 Dec 2018, Neal Cardwell wrote: > If we take RFC 6675 literally, I don't think there is an inconsistency. = Importantly, I don't think it quite says: "2MSS or 3 discontiguous SACKed > regions come after the byte."=C2=A0 >=20 > In section 4 (IsLost) and Section 9 (Changes Relative to RFC 3517), it = says "more than (DupThresh - 1) * SMSS" bytes have been SACKed.=C2=A0 Dup= Thresh is > 3, so that means "more than 2*SMSS". To get more than 2*SMSS requires a= t least 3 segments. So that requirement seems to mean essentially 3 or mo= re > segments, where one of those segments may not be full sized. >=20 > So I think that is consistent with the statement: >=20 > =C2=A0 This retains the requirement that at least three segments follow= ing > =C2=A0 =C2=A0the sequence number in question have been SACKed >=20 > Does that sound plausible? > > neal >=20 >=20 > On Wed, Dec 5, 2018 at 1:57 PM Praveen Balasubramanian wrote: > It is understood that RACK loss detection doesn't have any ambigu= ity and most of it is implemented in Windows as an addendum to 6675. But > RFC 6675 is Standards Track and is implemented in several OS vers= ions that are deployed. Can someone with historical context please chime > in on what the intent was so we can resolve the inconsistency and = also clarify the requirement around continuity? > > -----Original Message----- > From: tcpm On Behalf Of Michael Tuexen > Sent: Wednesday, December 5, 2018 9:45 AM > To: Yuchung Cheng > Cc: maolson=3D40microsoft.com@dmarc.ietf.org; tcpm@ietf.org Exten= sions > Subject: Re: [tcpm] RFC 6675 SACK tracking > > > On 5. Dec 2018, at 17:31, Yuchung Cheng wrote: > > > > On Wed, Dec 5, 2018 at 8:02 AM Matt Olson > > wrote: > >> > >> Hi, I have a question about the RFC 6675 conditions for determ= ining bytes lost. Below I've pasted two relevant parts of the RFC. The > conditions for marking a byte lost are "2MSS or 3 discontiguous S= ACKed regions come after the byte." The paragraph below from Section 9 > provides some rationale for the "2MSS" part, which changed from R= FC3517 (which had it as 3MSS): we want to detect loss even when three > sub-MSS packets after the byte made it to the peer. In particular = it says "this retains the requirement that at least three segments > following the sequence number in question have been SACKed." But, = this doesn't seem to add up: a single received SACK block covering 2MSS > might only represent two packets. > >> > >> Besides this inconsistency in the RFC, I wonder: why do we car= e about "discontiguous SACKed regions" anyway? If we receive three ACKs, > each with a SACK block that is a proper superset of the previous = one, can't we conclude that three packets arrived at the peer and > (following the spirit, if not the letter, of RFC 6675) conclude t= hat any bytes previous to the union of those SACKs were lost? Even if > together they SACK less than 2MSS bytes? > > In my opinion we should not care about the continuity of SACK, = or even > > counting SACKs. I've proposed a new way to detect losses (imple= mented > > by Linux & NetFlix.BSD) > It is in the FreeBSD code base and will be included in the upcomi= ng release 12.0. > The code was contributed by Netflix. > > Best regards > Michael > > > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Ftools > > .ietf..org%2Fhtml%2Fdraft-ietf-tcpm-rack-04&data=3D02%7C01%= 7Cpravb%40 > > microsoft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f1= 41af91a > > b2d7cd011db47%7C1%7C0%7C636796287446259136&sdata=3Dx14zcF4R= SsfSPb3lw > > 9zkfpcLZPYpWJZXllTcWOJZwhA%3D&reserved=3D0 > > > >> > >> Thanks! > >> > >> > >> > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Ftool > >> s.ietf.org%2Fhtml%2Frfc6675&data=3D02%7C01%7Cpravb%40micro= soft.com% > >> 7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7cd= 011db47 > >> %7C1%7C0%7C636796287446259136&sdata=3Dlc8lSSoypNl7PjuqVu2K= Yxjq3o971 > >> oCMy4idlXDRWnk%3D&reserved=3D0 > >> > >>> From section 4: > >> IsLost (SeqNum): > >>=C2=A0 =C2=A0 =C2=A0 This routine returns whether the given seq= uence number is > >>=C2=A0 =C2=A0 =C2=A0 considered to be lost.=C2=A0 The routine r= eturns true when either > >>=C2=A0 =C2=A0 =C2=A0 DupThresh discontiguous SACKed sequences h= ave arrived above > >>=C2=A0 =C2=A0 =C2=A0 'SeqNum' or more than (DupThresh - 1) * SM= SS bytes with sequence > >>=C2=A0 =C2=A0 =C2=A0 numbers greater than 'SeqNum' have been SA= CKed.=C2=A0 Otherwise, the > >>=C2=A0 =C2=A0 =C2=A0 routine returns false. > >> > >>> From section 9: > >>=C2=A0 =C2=A0The function IsLost () has been modified to requir= e that more than > >>=C2=A0 =C2=A0(DupThresh - 1) * SMSS octets have been SACKed abo= ve a given sequence > >>=C2=A0 =C2=A0number as indication that it is lost, which is cha= nged from the > >>=C2=A0 =C2=A0minimum requirement of (DupThresh * SMSS) describe= d in [RFC3517]. > >>=C2=A0 =C2=A0This retains the requirement that at least three s= egments following > >>=C2=A0 =C2=A0the sequence number in question have been SACKed, = while improving > >>=C2=A0 =C2=A0detection in the event that the sender has outstan= ding segments which > >>=C2=A0 =C2=A0are smaller than SMSS. > >> > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww. > >> ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cprav= b%40micro > >> soft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af= 91ab2d7 > >> cd011db47%7C1%7C0%7C636796287446259136&sdata=3DIqnoUOScKKe= i3PwnYM%2 > >> B0HmbrY1EScWdIZoYlGvhAiUU%3D&reserved=3D0 > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Fwww.i > > etf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%= 40microso > > ft.com%7C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91a= b2d7cd0 > > 11db47%7C1%7C0%7C636796287446259136&sdata=3DIqnoUOScKKei3Pw= nYM%2B0Hm > > brY1EScWdIZoYlGvhAiUU%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=3D02%7C01%7Cpravb%40microso= ft.com%7 > C3e30aef4f4f74719c27e08d65ad97ab3%7C72f988bf86f141af91ab2d7cd011db47%7C= 1%7C0%7C636796287446259136&sdata=3DIqnoUOScKKei3PwnYM%2B0HmbrY1EScWdI= ZoYlGv > hAiUU%3D&reserved=3D0 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >=20 >=20 > --=_script-30741-1544038134-0001-2-- From nobody Wed Dec 5 11:43:56 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAC512D4EB for ; Wed, 5 Dec 2018 11:43:55 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNHy7BX3xDbX for ; Wed, 5 Dec 2018 11:43:54 -0800 (PST) Received: from smtp-rs2-vallila1.fe.helsinki.fi (smtp-rs2-vallila1.fe.helsinki.fi [128.214.173.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08A2A1276D0 for ; Wed, 5 Dec 2018 11:43:53 -0800 (PST) Received: from whs-18.cs.helsinki.fi (whs-18.cs.helsinki.fi [128.214.166.46]) by smtp-rs2.it.helsinki.fi (8.14.7/8.14.7) with ESMTP id wB5JhkPL009283; Wed, 5 Dec 2018 21:43:47 +0200 Received: by whs-18.cs.helsinki.fi (Postfix, from userid 1070048) id D3BAA3600D1; Wed, 5 Dec 2018 21:43:46 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by whs-18.cs.helsinki.fi (Postfix) with ESMTP id D2484360098; Wed, 5 Dec 2018 21:43:46 +0200 (EET) Date: Wed, 5 Dec 2018 21:43:46 +0200 (EET) From: =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= X-X-Sender: ijjarvin@whs-18.cs.helsinki.fi To: Matt Olson cc: "tcpm@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] RFC 6675 SACK tracking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 19:43:56 -0000 On Tue, 4 Dec 2018, Matt Olson wrote: > Hi, I have a question about the RFC 6675 conditions for determining > bytes lost. Below I've pasted two relevant parts of the RFC. The > conditions for marking a byte lost are "2MSS or 3 discontiguous SACKed > regions come after the byte." The paragraph below from Section 9 > provides some rationale for the "2MSS" part, which changed from RFC3517 > (which had it as 3MSS): we want to detect loss even when three sub-MSS > packets after the byte made it to the peer. In particular it says "this > retains the requirement that at least three segments following the > sequence number in question have been SACKed." But, this doesn't seem to > add up: a single received SACK block covering 2MSS might only represent > two packets. It has > 2MSS not >= 2MSS ("more than 2MSS"). With Nagle, only one Besides this inconsistency in the RFC, I wonder: why do we care about > "discontiguous SACKed regions" anyway? If we receive three ACKs, each > with a SACK block that is a proper superset of the previous one, can't > we conclude that three packets arrived at the peer and (following the > spirit, if not the letter, of RFC 6675) conclude that any bytes previous > to the union of those SACKs were lost? Even if together they SACK less > than 2MSS bytes? You'd need to add variables for tracking those developments of supersets (in fact, a variable per seqno given how the IsLost function is specified in RFC6675). But yes, in general, new SACK information in each ACK is even better condition (and if possible, matching against segment boundaries that were used for sending them out to protect also against any kind of SACK splitting would also be nice to have) but tracking that has its own implementation efficiency challenges even if the implementation would not be locked in how the scoreboard details are arranged in RFC6675 algorithm (this comes from a guy who has implemented significant portion of the scoreboard handling in one OS). -- i. > https://tools.ietf.org/html/rfc6675 > > >From section 4: > IsLost (SeqNum): > This routine returns whether the given sequence number is > considered to be lost. The routine returns true when either > DupThresh discontiguous SACKed sequences have arrived above > 'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence > numbers greater than 'SeqNum' have been SACKed. Otherwise, the > routine returns false. > > >From section 9: > The function IsLost () has been modified to require that more than > (DupThresh - 1) * SMSS octets have been SACKed above a given sequence > number as indication that it is lost, which is changed from the > minimum requirement of (DupThresh * SMSS) described in [RFC3517]. > This retains the requirement that at least three segments following > the sequence number in question have been SACKed, while improving > detection in the event that the sender has outstanding segments which > are smaller than SMSS. > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > From nobody Thu Dec 6 08:03:48 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E996130EFC for ; Wed, 5 Dec 2018 11:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_HEX=1.122, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icJdBuFmL5ND for ; Wed, 5 Dec 2018 11:20:03 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770105.outbound.protection.outlook.com [40.107.77.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87AC7130EC6 for ; Wed, 5 Dec 2018 11:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XVeA+gqnCGKurSKQNLW6EPjsmzzAVQIY74JlywlCAog=; b=gnzEumyLgDJLw3QbbYM4/nggNj8oyIk0YDI8R2PWk3oKd3GMEXYE1hkbNAtkXOZiDofzAen590h45Wp32RC53QLYkoCq1oF0etxUhkVAlsEqt2Ti2J7dsqBvZv4c/SUnNxz2zdYYk+PCyWN9QGHPonMnwxc5H+Ybn6vN8SD+Blw= Received: from CY4PR21MB0118.namprd21.prod.outlook.com (10.173.189.12) by CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.2; Wed, 5 Dec 2018 19:20:01 +0000 Received: from CY4PR21MB0118.namprd21.prod.outlook.com ([fe80::9c54:66df:6820:8006]) by CY4PR21MB0118.namprd21.prod.outlook.com ([fe80::9c54:66df:6820:8006%2]) with mapi id 15.20.1425.006; Wed, 5 Dec 2018 19:20:01 +0000 From: Matt Olson To: Neal Cardwell , Praveen Balasubramanian CC: Michael Tuexen , "ycheng@google.com" , "tcpm@ietf.org" Thread-Topic: [tcpm] RFC 6675 SACK tracking Thread-Index: AdSMJigjQ8FMajp0TMaA29dkbqDV7QAkcvIAAAKWD4AAAlGp4AAAsaCAAAAqAdA= Date: Wed, 5 Dec 2018 19:20:00 +0000 Message-ID: References: <84DE752E-C61A-4D70-9CD8-BD49F742836E@lurchi.franken.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:b:687b:bb18:5d5a:5b1b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0774; 6:QbFwb2VGumi8S9flx+nRVaZkxhcBCsNLDUjApyUhhPTBvNidgOZN0c5XKyUL2UPHxNUpZ1ptgg05sMe2XXWz2brJN1gEJ7R6FKFYoJ3yoAFZkeF4P+qAtZKEHh2s5ZwetE/++06GjY+m+wsrodtfYyRaoLk0ntsaP/4C2vhI0CTFSJA0SCn1tf5/b5XQW6EIr7XvyV8sNwrqbGEWwLsmgB7lQBrqSFrphibFgjpOMjDQkRfNWK0n/kGmO5cc7zMswso8zfMj+z29FOB88qCxW85dj9xfX1821UYrBNAps4wC302vMFubR4ShFTnzsvLf3YbW1W5bsFaxDlj1f87j5vPdKEpiMUo7iVjkZwe079r+3L3xyB9Yb9fS/5wnN9wjBxW7tBtMx2yRgbyhtMUVJIZVrS99z2DYjR4DqwdLza6IeVYLdxScaZH533j58BCWhw8yQFjGv3r8jF3nt0JLqA==; 5:8wiEQDbE5Yp1L68jOSeFtGou4prvOivyKH3huQmjewOqn34tuegr4IwgnvP8tOkpj8UFlqHnjOsRFn9Axv+L7YWGrwagWVrBQa4sYVmL7ZiRH4ONRmL++W0ESeVB+H9gy9TbWwHhPZSM7OLDgvuHQvbDEnjwnf2mtgygZSvRXiY=; 7:u9+zaNDcG8oF2wRcL8GQ4uJZNFifmSIJgwqZt/y33BoM0z/87H+D4PCQ16ETMIoEsKpP8WilAjkSh9mSkvRiqkNvc1iEu+kvALs3ZLtGnQMpjwhetJHJ9nP9WogdiZukpnCnoxEa06HPny/bkFY3KA== x-ms-office365-filtering-correlation-id: 98cecca4-1621-4abb-1db1-08d65ae6a715 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CY4PR21MB0774; x-ms-traffictypediagnostic: CY4PR21MB0774: x-ms-exchange-purlcount: 22 authentication-results: spf=none (sender IP is ) smtp.mailfrom=maolson@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230008)(999002)(6040522)(8220035)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231463)(944501520)(2018427008)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:CY4PR21MB0774; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0774; x-forefront-prvs: 08770259B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(346002)(376002)(396003)(366004)(13464003)(199004)(189003)(51444003)(102836004)(53936002)(966005)(478600001)(14454004)(7696005)(606006)(6246003)(53546011)(1511001)(33656002)(6506007)(229853002)(76176011)(10090500001)(68736007)(6636002)(2906002)(8990500004)(8676002)(11346002)(4326008)(446003)(81156014)(81166006)(25786009)(10290500003)(476003)(486006)(186003)(790700001)(6116002)(106356001)(105586002)(55016002)(46003)(22452003)(99286004)(316002)(236005)(71190400001)(256004)(71200400001)(97736004)(14444005)(110136005)(6306002)(54906003)(6436002)(7736002)(9686003)(74316002)(8936002)(575784001)(93886005)(54896002)(86362001)(5660300001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0774; H:CY4PR21MB0118.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: FfRzSaUUrS6GDn4sN3uQ1XyLg2Q4xQ8Kck+ng/3ofYNYs+ih0WO1j3qySk1/rGTSFMpt09G8RiYbxbCYBqtHF9HyiZcqlPejUYw+UFPUVnm9H59sklOqa/Tosg21Ijjc/G+4VcFRf7iP6ISu0bSodNFwwy03DnAtZvL73fSZG2Z4o2zzMzD1rxsNn3ExlWLXH7UjEp/6YC5+Pquhh9t4uepoVzesPbXQkTsliFT9vLhOJJpnTfnrWHm7LSXBhXR7Ol4lqW0dzbAH/PQ4goFNdxPes7HXAtJyWIF60yH9v5llx4JcAENy4w2ppfsISEAEScPv3688RCPJJzsbKir8bfn3sl1h+y63cmBHJ4i2Ysw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0118A14A241CDF2529762CBBBCA80CY4PR21MB0118namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 98cecca4-1621-4abb-1db1-08d65ae6a715 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2018 19:20:01.0079 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0774 Archived-At: X-Mailman-Approved-At: Thu, 06 Dec 2018 08:03:45 -0800 Subject: Re: [tcpm] RFC 6675 SACK tracking X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 19:20:11 -0000 --_000_CY4PR21MB0118A14A241CDF2529762CBBBCA80CY4PR21MB0118namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlYXQgY2F0Y2guIEkgbWlzcmVhZCBpdCBhcyDigJw+PSAyTVNT4oCdIHJhdGhlciB0aGFuIOKA nD4gMk1TU+KAnS4gV2l0aCDigJw+IDJNU1PigJ0sIGl0IG1ha2VzIHNlbnNlLiBUaGFua3MsIE5l YWwhDQoNClRoZSBxdWVzdGlvbiBhYm91dCB3aHkg4oCcZGlzY29udGlndWl0eeKAnSBmdW5kYW1l bnRhbGx5IG1hdHRlcnMgc3RpbGwgc3RhbmRzLCB0aG91Z2guDQoNCkZyb206IE5lYWwgQ2FyZHdl bGwgPG5jYXJkd2VsbD00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNk YXksIERlY2VtYmVyIDUsIDIwMTggMTE6MTIgQU0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh biA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCkNjOiBNaWNoYWVsIFR1ZXhlbiA8TWljaGFlbC5UdWV4 ZW5AbHVyY2hpLmZyYW5rZW4uZGU+OyB5Y2hlbmdAZ29vZ2xlLmNvbTsgTWF0dCBPbHNvbiA8bWFv bHNvbkBtaWNyb3NvZnQuY29tPjsgdGNwbUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt0Y3BtXSBS RkMgNjY3NSBTQUNLIHRyYWNraW5nDQoNCklmIHdlIHRha2UgUkZDIDY2NzUgbGl0ZXJhbGx5LCBJ IGRvbid0IHRoaW5rIHRoZXJlIGlzIGFuIGluY29uc2lzdGVuY3kuIEltcG9ydGFudGx5LCBJIGRv bid0IHRoaW5rIGl0IHF1aXRlIHNheXM6ICIyTVNTIG9yIDMgZGlzY29udGlndW91cyBTQUNLZWQg cmVnaW9ucyBjb21lIGFmdGVyIHRoZSBieXRlLiINCg0KSW4gc2VjdGlvbiA0IChJc0xvc3QpIGFu ZCBTZWN0aW9uIDkgKENoYW5nZXMgUmVsYXRpdmUgdG8gUkZDIDM1MTcpLCBpdCBzYXlzICJtb3Jl IHRoYW4gKER1cFRocmVzaCAtIDEpICogU01TUyIgYnl0ZXMgaGF2ZSBiZWVuIFNBQ0tlZC4gIER1 cFRocmVzaCBpcyAzLCBzbyB0aGF0IG1lYW5zICJtb3JlIHRoYW4gMipTTVNTIi4gVG8gZ2V0IG1v cmUgdGhhbiAyKlNNU1MgcmVxdWlyZXMgYXQgbGVhc3QgMyBzZWdtZW50cy4gU28gdGhhdCByZXF1 aXJlbWVudCBzZWVtcyB0byBtZWFuIGVzc2VudGlhbGx5IDMgb3IgbW9yZSBzZWdtZW50cywgd2hl cmUgb25lIG9mIHRob3NlIHNlZ21lbnRzIG1heSBub3QgYmUgZnVsbCBzaXplZC4NCg0KU28gSSB0 aGluayB0aGF0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgc3RhdGVtZW50Og0KDQogIFRoaXMgcmV0 YWlucyB0aGUgcmVxdWlyZW1lbnQgdGhhdCBhdCBsZWFzdCB0aHJlZSBzZWdtZW50cyBmb2xsb3dp bmcNCiAgIHRoZSBzZXF1ZW5jZSBudW1iZXIgaW4gcXVlc3Rpb24gaGF2ZSBiZWVuIFNBQ0tlZA0K DQpEb2VzIHRoYXQgc291bmQgcGxhdXNpYmxlPw0KDQpuZWFsDQoNCg0KT24gV2VkLCBEZWMgNSwg MjAxOCBhdCAxOjU3IFBNIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2Yj00MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y Zz4+IHdyb3RlOg0KSXQgaXMgdW5kZXJzdG9vZCB0aGF0IFJBQ0sgbG9zcyBkZXRlY3Rpb24gZG9l c24ndCBoYXZlIGFueSBhbWJpZ3VpdHkgYW5kIG1vc3Qgb2YgaXQgaXMgaW1wbGVtZW50ZWQgaW4g V2luZG93cyBhcyBhbiBhZGRlbmR1bSB0byA2Njc1LiBCdXQgUkZDIDY2NzUgaXMgU3RhbmRhcmRz IFRyYWNrIGFuZCBpcyBpbXBsZW1lbnRlZCBpbiBzZXZlcmFsIE9TIHZlcnNpb25zIHRoYXQgYXJl IGRlcGxveWVkLiBDYW4gc29tZW9uZSB3aXRoIGhpc3RvcmljYWwgY29udGV4dCBwbGVhc2UgY2hp bWUgaW4gb24gd2hhdCB0aGUgaW50ZW50IHdhcyBzbyB3ZSBjYW4gcmVzb2x2ZSB0aGUgaW5jb25z aXN0ZW5jeSBhbmQgYWxzbyBjbGFyaWZ5IHRoZSByZXF1aXJlbWVudCBhcm91bmQgY29udGludWl0 eT8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRjcG0gPHRjcG0tYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIE1p Y2hhZWwgVHVleGVuDQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDUsIDIwMTggOTo0NSBBTQ0K VG86IFl1Y2h1bmcgQ2hlbmcgPHljaGVuZz00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4+DQpDYzogbWFvbHNvbj00MG1pY3Jvc29m dC5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9y Zz47IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+IEV4dGVuc2lvbnMgPHRjcG1A aWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFt0Y3BtXSBSRkMg NjY3NSBTQUNLIHRyYWNraW5nDQoNCj4gT24gNS4gRGVjIDIwMTgsIGF0IDE3OjMxLCBZdWNodW5n IENoZW5nIDx5Y2hlbmc9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGdvb2ds ZS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCj4NCj4gT24gV2VkLCBEZWMgNSwgMjAxOCBh dCA4OjAyIEFNIE1hdHQgT2xzb24NCj4gPG1hb2xzb249NDBtaWNyb3NvZnQuY29tQGRtYXJjLmll dGYub3JnPG1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCj4+ DQo+PiBIaSwgSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgdGhlIFJGQyA2Njc1IGNvbmRpdGlvbnMg Zm9yIGRldGVybWluaW5nIGJ5dGVzIGxvc3QuIEJlbG93IEkndmUgcGFzdGVkIHR3byByZWxldmFu dCBwYXJ0cyBvZiB0aGUgUkZDLiBUaGUgY29uZGl0aW9ucyBmb3IgbWFya2luZyBhIGJ5dGUgbG9z dCBhcmUgIjJNU1Mgb3IgMyBkaXNjb250aWd1b3VzIFNBQ0tlZCByZWdpb25zIGNvbWUgYWZ0ZXIg dGhlIGJ5dGUuIiBUaGUgcGFyYWdyYXBoIGJlbG93IGZyb20gU2VjdGlvbiA5IHByb3ZpZGVzIHNv bWUgcmF0aW9uYWxlIGZvciB0aGUgIjJNU1MiIHBhcnQsIHdoaWNoIGNoYW5nZWQgZnJvbSBSRkMz NTE3ICh3aGljaCBoYWQgaXQgYXMgM01TUyk6IHdlIHdhbnQgdG8gZGV0ZWN0IGxvc3MgZXZlbiB3 aGVuIHRocmVlIHN1Yi1NU1MgcGFja2V0cyBhZnRlciB0aGUgYnl0ZSBtYWRlIGl0IHRvIHRoZSBw ZWVyLiBJbiBwYXJ0aWN1bGFyIGl0IHNheXMgInRoaXMgcmV0YWlucyB0aGUgcmVxdWlyZW1lbnQg dGhhdCBhdCBsZWFzdCB0aHJlZSBzZWdtZW50cyBmb2xsb3dpbmcgdGhlIHNlcXVlbmNlIG51bWJl ciBpbiBxdWVzdGlvbiBoYXZlIGJlZW4gU0FDS2VkLiIgQnV0LCB0aGlzIGRvZXNuJ3Qgc2VlbSB0 byBhZGQgdXA6IGEgc2luZ2xlIHJlY2VpdmVkIFNBQ0sgYmxvY2sgY292ZXJpbmcgMk1TUyBtaWdo dCBvbmx5IHJlcHJlc2VudCB0d28gcGFja2V0cy4NCj4+DQo+PiBCZXNpZGVzIHRoaXMgaW5jb25z aXN0ZW5jeSBpbiB0aGUgUkZDLCBJIHdvbmRlcjogd2h5IGRvIHdlIGNhcmUgYWJvdXQgImRpc2Nv bnRpZ3VvdXMgU0FDS2VkIHJlZ2lvbnMiIGFueXdheT8gSWYgd2UgcmVjZWl2ZSB0aHJlZSBBQ0tz LCBlYWNoIHdpdGggYSBTQUNLIGJsb2NrIHRoYXQgaXMgYSBwcm9wZXIgc3VwZXJzZXQgb2YgdGhl IHByZXZpb3VzIG9uZSwgY2FuJ3Qgd2UgY29uY2x1ZGUgdGhhdCB0aHJlZSBwYWNrZXRzIGFycml2 ZWQgYXQgdGhlIHBlZXIgYW5kIChmb2xsb3dpbmcgdGhlIHNwaXJpdCwgaWYgbm90IHRoZSBsZXR0 ZXIsIG9mIFJGQyA2Njc1KSBjb25jbHVkZSB0aGF0IGFueSBieXRlcyBwcmV2aW91cyB0byB0aGUg dW5pb24gb2YgdGhvc2UgU0FDS3Mgd2VyZSBsb3N0PyBFdmVuIGlmIHRvZ2V0aGVyIHRoZXkgU0FD SyBsZXNzIHRoYW4gMk1TUyBieXRlcz8NCj4gSW4gbXkgb3BpbmlvbiB3ZSBzaG91bGQgbm90IGNh cmUgYWJvdXQgdGhlIGNvbnRpbnVpdHkgb2YgU0FDSywgb3IgZXZlbg0KPiBjb3VudGluZyBTQUNL cy4gSSd2ZSBwcm9wb3NlZCBhIG5ldyB3YXkgdG8gZGV0ZWN0IGxvc3NlcyAoaW1wbGVtZW50ZWQN Cj4gYnkgTGludXggJiBOZXRGbGl4LkJTRCkNCkl0IGlzIGluIHRoZSBGcmVlQlNEIGNvZGUgYmFz ZSBhbmQgd2lsbCBiZSBpbmNsdWRlZCBpbiB0aGUgdXBjb21pbmcgcmVsZWFzZSAxMi4wLg0KVGhl IGNvZGUgd2FzIGNvbnRyaWJ1dGVkIGJ5IE5ldGZsaXguDQoNCkJlc3QgcmVnYXJkcw0KTWljaGFl bA0KPg0KPiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnRvb2xzDQo+IC5pZXRmLi5vcmc8aHR0cHM6Ly9uYW0wNi5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZpZXRmLm9yZyZkYXRh PTAyJTdDMDElN0NtYW9sc29uJTQwbWljcm9zb2Z0LmNvbSU3QzJhZmMzOWNhNjVlNzQ1NWU1ZGE5 MDhkNjVhZTU5MThkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNjc5NjMzOTM4NDczMTM0OCZzZGF0YT1laHNQNTlKdWFSN2VWRWQlMkJ1QWI2dzhCRTl0VTlw dGZmVERpemx3cFBHZzQlM0QmcmVzZXJ2ZWQ9MD4lMkZodG1sJTJGZHJhZnQtaWV0Zi10Y3BtLXJh Y2stMDQmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwDQo+IG1pY3Jvc29mdC5jb208aHR0cHM6 Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYl MkZtaWNyb3NvZnQuY29tJmRhdGE9MDIlN0MwMSU3Q21hb2xzb24lNDBtaWNyb3NvZnQuY29tJTdD MmFmYzM5Y2E2NWU3NDU1ZTVkYTkwOGQ2NWFlNTkxOGQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Nzk2MzM5Mzg0NzMxMzQ4JnNkYXRhPUptMzJCdzZsS1A0 VlBFQkFpJTJGeXVBTjAxWFlBVUNXbWtrUVQwNm5HdkhIYyUzRCZyZXNlcnZlZD0wPiU3QzNlMzBh ZWY0ZjRmNzQ3MTljMjdlMDhkNjVhZDk3YWIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYQ0KPiBiMmQ3 Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3OTYyODc0NDYyNTkxMzYmYW1wO3NkYXRhPXgxNHpjRjRS U3NmU1BiM2x3DQo+IDl6a2ZwY0xaUFlwV0paWGxsVGNXT0pad2hBJTNEJmFtcDtyZXNlcnZlZD0w DQo+DQo+Pg0KPj4gVGhhbmtzIQ0KPj4NCj4+DQo+Pg0KPj4gaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29sDQo+PiBzLmll dGYub3JnPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwJTNBJTJGJTJGcy5pZXRmLm9yZyZkYXRhPTAyJTdDMDElN0NtYW9sc29uJTQwbWljcm9z b2Z0LmNvbSU3QzJhZmMzOWNhNjVlNzQ1NWU1ZGE5MDhkNjVhZTU5MThkJTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc5NjMzOTM4NDc0MTM1NiZzZGF0YT1L TkhmJTJGY2E1bmE3bSUyQlljVEQxZmpaMW94QVhaR1lnMURVdDZUMUgzMCUyRmVnJTNEJnJlc2Vy dmVkPTA+JTJGaHRtbCUyRnJmYzY2NzUmYW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9z b2Z0LmNvbTxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cCUzQSUyRiUyRjQwbWljcm9zb2Z0LmNvbSZkYXRhPTAyJTdDMDElN0NtYW9sc29uJTQw bWljcm9zb2Z0LmNvbSU3QzJhZmMzOWNhNjVlNzQ1NWU1ZGE5MDhkNjVhZTU5MThkJTdDNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc5NjMzOTM4NDc1MTM2NSZz ZGF0YT1oRHNSMzR3OFR4bEFxJTJCc09xWGElMkZGdHd3bW9xcjMyVnB5JTJGUWxqd1hDcVdvJTNE JnJlc2VydmVkPTA+JQ0KPj4gN0MzZTMwYWVmNGY0Zjc0NzE5YzI3ZTA4ZDY1YWQ5N2FiMyU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3DQo+PiAlN0MxJTdDMCU3QzYzNjc5NjI4NzQ0 NjI1OTEzNiZhbXA7c2RhdGE9bGM4bFNTb3lwTmw3UGp1cVZ1MktZeGpxM285NzENCj4+IG9DTXk0 aWRsWERSV25rJTNEJmFtcDtyZXNlcnZlZD0wDQo+Pg0KPj4+IEZyb20gc2VjdGlvbiA0Og0KPj4g SXNMb3N0IChTZXFOdW0pOg0KPj4gICAgICBUaGlzIHJvdXRpbmUgcmV0dXJucyB3aGV0aGVyIHRo ZSBnaXZlbiBzZXF1ZW5jZSBudW1iZXIgaXMNCj4+ICAgICAgY29uc2lkZXJlZCB0byBiZSBsb3N0 LiAgVGhlIHJvdXRpbmUgcmV0dXJucyB0cnVlIHdoZW4gZWl0aGVyDQo+PiAgICAgIER1cFRocmVz aCBkaXNjb250aWd1b3VzIFNBQ0tlZCBzZXF1ZW5jZXMgaGF2ZSBhcnJpdmVkIGFib3ZlDQo+PiAg ICAgICdTZXFOdW0nIG9yIG1vcmUgdGhhbiAoRHVwVGhyZXNoIC0gMSkgKiBTTVNTIGJ5dGVzIHdp dGggc2VxdWVuY2UNCj4+ICAgICAgbnVtYmVycyBncmVhdGVyIHRoYW4gJ1NlcU51bScgaGF2ZSBi ZWVuIFNBQ0tlZC4gIE90aGVyd2lzZSwgdGhlDQo+PiAgICAgIHJvdXRpbmUgcmV0dXJucyBmYWxz ZS4NCj4+DQo+Pj4gRnJvbSBzZWN0aW9uIDk6DQo+PiAgIFRoZSBmdW5jdGlvbiBJc0xvc3QgKCkg aGFzIGJlZW4gbW9kaWZpZWQgdG8gcmVxdWlyZSB0aGF0IG1vcmUgdGhhbg0KPj4gICAoRHVwVGhy ZXNoIC0gMSkgKiBTTVNTIG9jdGV0cyBoYXZlIGJlZW4gU0FDS2VkIGFib3ZlIGEgZ2l2ZW4gc2Vx dWVuY2UNCj4+ICAgbnVtYmVyIGFzIGluZGljYXRpb24gdGhhdCBpdCBpcyBsb3N0LCB3aGljaCBp cyBjaGFuZ2VkIGZyb20gdGhlDQo+PiAgIG1pbmltdW0gcmVxdWlyZW1lbnQgb2YgKER1cFRocmVz aCAqIFNNU1MpIGRlc2NyaWJlZCBpbiBbUkZDMzUxN10uDQo+PiAgIFRoaXMgcmV0YWlucyB0aGUg cmVxdWlyZW1lbnQgdGhhdCBhdCBsZWFzdCB0aHJlZSBzZWdtZW50cyBmb2xsb3dpbmcNCj4+ICAg dGhlIHNlcXVlbmNlIG51bWJlciBpbiBxdWVzdGlvbiBoYXZlIGJlZW4gU0FDS2VkLCB3aGlsZSBp bXByb3ZpbmcNCj4+ICAgZGV0ZWN0aW9uIGluIHRoZSBldmVudCB0aGF0IHRoZSBzZW5kZXIgaGFz IG91dHN0YW5kaW5nIHNlZ21lbnRzIHdoaWNoDQo+PiAgIGFyZSBzbWFsbGVyIHRoYW4gU01TUy4N Cj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4+IHRjcG1AaWV0Zi5vcmc8bWFpbHRvOnRjcG1AaWV0Zi5v cmc+DQo+PiBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy4NCj4+IGlldGYub3JnPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGaWV0Zi5vcmcmZGF0YT0w MiU3QzAxJTdDbWFvbHNvbiU0MG1pY3Jvc29mdC5jb20lN0MyYWZjMzljYTY1ZTc0NTVlNWRhOTA4 ZDY1YWU1OTE4ZCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzY3OTYzMzkzODQ3NTEzNjUmc2RhdGE9b3BYQTRWMnJHNW0wRWNqWVgyWTdYTmRRNTJWTDVSUmx5 ZiUyQmNmOUVSZDZBJTNEJnJlc2VydmVkPTA+JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZh bXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNybw0KPj4gc29mdC5jb208aHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZzb2Z0 LmNvbSZkYXRhPTAyJTdDMDElN0NtYW9sc29uJTQwbWljcm9zb2Z0LmNvbSU3QzJhZmMzOWNhNjVl NzQ1NWU1ZGE5MDhkNjVhZTU5MThkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjc5NjMzOTM4NDc2MTM3MyZzZGF0YT1tU1Raa3E0UG8wZ0ZXTGtnRFp0ajlW RHl1eWRwWVU2Y3RoU2phdiUyRnNsYzAlM0QmcmVzZXJ2ZWQ9MD4lN0MzZTMwYWVmNGY0Zjc0NzE5 YzI3ZTA4ZDY1YWQ5N2FiMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3DQo+PiBjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjc5NjI4NzQ0NjI1OTEzNiZhbXA7c2RhdGE9SXFub1VPU2NLS2VpM1B3bllN JTINCj4+IEIwSG1iclkxRVNjV2RJWm9ZbEd2aEFpVVUlM0QmYW1wO3Jlc2VydmVkPTANCj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdGNwbSBt YWlsaW5nIGxpc3QNCj4gdGNwbUBpZXRmLm9yZzxtYWlsdG86dGNwbUBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ3d3cuaQ0KPiBldGYub3JnPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGZXRmLm9yZyZkYXRhPTAyJTdDMDElN0NtYW9s c29uJTQwbWljcm9zb2Z0LmNvbSU3QzJhZmMzOWNhNjVlNzQ1NWU1ZGE5MDhkNjVhZTU5MThkJTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc5NjMzOTM4NDc2 MTM3MyZzZGF0YT1pSzkydmVVUnBZZ2hqSHpTRDRRbmNUWjlXJTJCRnNkeDdFVmU1aGprallvdEUl M0QmcmVzZXJ2ZWQ9MD4lMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTAyJTdD MDElN0NwcmF2YiU0MG1pY3Jvc28NCj4gZnQuY29tPGh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGZnQuY29tJmRhdGE9MDIlN0Mw MSU3Q21hb2xzb24lNDBtaWNyb3NvZnQuY29tJTdDMmFmYzM5Y2E2NWU3NDU1ZTVkYTkwOGQ2NWFl NTkxOGQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Nzk2 MzM5Mzg0NzcxMzgxJnNkYXRhPVNFZGhLYWREQkp2QmRqJTJCWUtwaHN2RjRnTkZSdXp3Y1JLdEVG OVdGdFhzSSUzRCZyZXNlcnZlZD0wPiU3QzNlMzBhZWY0ZjRmNzQ3MTljMjdlMDhkNjVhZDk3YWIz JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDANCj4gMTFkYjQ3JTdDMSU3QzAlN0M2MzY3OTYy ODc0NDYyNTkxMzYmYW1wO3NkYXRhPUlxbm9VT1NjS0tlaTNQd25ZTSUyQjBIbQ0KPiBiclkxRVNj V2RJWm9ZbEd2aEFpVVUlM0QmYW1wO3Jlc2VydmVkPTANCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnRjcG0gbWFpbGluZyBsaXN0DQp0Y3BtQGlldGYu b3JnPG1haWx0bzp0Y3BtQGlldGYub3JnPg0KaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5j b20lN0MzZTMwYWVmNGY0Zjc0NzE5YzI3ZTA4ZDY1YWQ5N2FiMyU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3OTYyODc0NDYyNTkxMzYmYW1wO3NkYXRhPUlx bm9VT1NjS0tlaTNQd25ZTSUyQjBIbWJyWTFFU2NXZElab1lsR3ZoQWlVVSUzRCZhbXA7cmVzZXJ2 ZWQ9MDxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmRh dGE9MDIlN0MwMSU3Q21hb2xzb24lNDBtaWNyb3NvZnQuY29tJTdDMmFmYzM5Y2E2NWU3NDU1ZTVk YTkwOGQ2NWFlNTkxOGQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM2Nzk2MzM5Mzg0NzgxMzkwJnNkYXRhPXZXejIzZnZJTGJvMlI2bXM4ZkFLSEhzMmhvRm1S a3p4anpZN0piVWElMkJTUSUzRCZyZXNlcnZlZD0wPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KdGNwbSBtYWlsaW5nIGxpc3QNCnRjcG1AaWV0Zi5v cmc8bWFpbHRvOnRjcG1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RjcG08aHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJG dGNwbSZkYXRhPTAyJTdDMDElN0NtYW9sc29uJTQwbWljcm9zb2Z0LmNvbSU3QzJhZmMzOWNhNjVl NzQ1NWU1ZGE5MDhkNjVhZTU5MThkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N0MxJTdDMCU3QzYzNjc5NjMzOTM4NDc4MTM5MCZzZGF0YT12V3oyM2Z2SUxibzJSNm1zOGZBS0hI czJob0ZtUmt6eGp6WTdKYlVhJTJCU1ElM0QmcmVzZXJ2ZWQ9MD4NCg== --_000_CY4PR21MB0118A14A241CDF2529762CBBBCA80CY4PR21MB0118namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3JlYXQgY2F0Y2guIEkgbWlzcmVh ZCBpdCBhcyDigJwmZ3Q7PSAyTVNT4oCdIHJhdGhlciB0aGFuIOKAnCZndDsgMk1TU+KAnS4gV2l0 aCDigJwmZ3Q7IDJNU1PigJ0sIGl0IG1ha2VzIHNlbnNlLiBUaGFua3MsIE5lYWwhPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBxdWVzdGlvbiBhYm91dCB3aHkg4oCcZGlzY29udGlndWl0eeKA nSBmdW5kYW1lbnRhbGx5IG1hdHRlcnMgc3RpbGwgc3RhbmRzLCB0aG91Z2guPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBOZWFsIENhcmR3ZWxsICZsdDtuY2FyZHdlbGw9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgRGVjZW1iZXIgNSwgMjAxOCAxMToxMiBBTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxh c3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBN aWNoYWVsIFR1ZXhlbiAmbHQ7TWljaGFlbC5UdWV4ZW5AbHVyY2hpLmZyYW5rZW4uZGUmZ3Q7OyB5 Y2hlbmdAZ29vZ2xlLmNvbTsgTWF0dCBPbHNvbiAmbHQ7bWFvbHNvbkBtaWNyb3NvZnQuY29tJmd0 OzsgdGNwbUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RjcG1dIFJGQyA2Njc1 IFNBQ0sgdHJhY2tpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklmIHdlIHRha2UgUkZDIDY2NzUgbGl0ZXJhbGx5LCBJIGRvbid0IHRoaW5rIHRo ZXJlIGlzIGFuIGluY29uc2lzdGVuY3kuIEltcG9ydGFudGx5LCBJIGRvbid0IHRoaW5rIGl0IHF1 aXRlIHNheXM6ICZxdW90OzJNU1Mgb3IgMyBkaXNjb250aWd1b3VzIFNBQ0tlZCByZWdpb25zIGNv bWUgYWZ0ZXIgdGhlIGJ5dGUuJnF1b3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gc2VjdGlvbiA0IChJc0xvc3QpIGFuZCBTZWN0aW9uIDkg KENoYW5nZXMgUmVsYXRpdmUgdG8gUkZDIDM1MTcpLCBpdCBzYXlzICZxdW90O21vcmUgdGhhbiAo RHVwVGhyZXNoIC0gMSkgKiBTTVNTJnF1b3Q7IGJ5dGVzIGhhdmUgYmVlbiBTQUNLZWQuJm5ic3A7 IER1cFRocmVzaCBpcyAzLCBzbyB0aGF0IG1lYW5zICZxdW90O21vcmUgdGhhbiAyKlNNU1MmcXVv dDsuIFRvIGdldCBtb3JlIHRoYW4gMipTTVNTIHJlcXVpcmVzIGF0IGxlYXN0IDMgc2VnbWVudHMu DQogU28gdGhhdCByZXF1aXJlbWVudCBzZWVtcyB0byBtZWFuIGVzc2VudGlhbGx5IDMgb3IgbW9y ZSBzZWdtZW50cywgd2hlcmUgb25lIG9mIHRob3NlIHNlZ21lbnRzIG1heSBub3QgYmUgZnVsbCBz aXplZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U28gSSB0aGluayB0aGF0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgc3RhdGVtZW50OjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg VGhpcyByZXRhaW5zIHRoZSByZXF1aXJlbWVudCB0aGF0IGF0IGxlYXN0IHRocmVlIHNlZ21lbnRz IGZvbGxvd2luZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dGhlIHNlcXVlbmNlIG51bWJlciBpbiBx dWVzdGlvbiBoYXZlIGJlZW4gU0FDS2VkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9lcyB0aGF0IHNvdW5kIHBsYXVzaWJsZT88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bmVh bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyA1LCAyMDE4IGF0IDE6NTcgUE0gUHJhdmVlbiBC YWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21A ZG1hcmMuaWV0Zi5vcmciPjQwbWljcm9zb2Z0LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SXQgaXMgdW5kZXJzdG9vZCB0aGF0IFJBQ0sgbG9zcyBkZXRlY3Rpb24gZG9lc24ndCBo YXZlIGFueSBhbWJpZ3VpdHkgYW5kIG1vc3Qgb2YgaXQgaXMgaW1wbGVtZW50ZWQgaW4gV2luZG93 cyBhcyBhbiBhZGRlbmR1bSB0byA2Njc1LiBCdXQgUkZDIDY2NzUgaXMgU3RhbmRhcmRzIFRyYWNr IGFuZCBpcyBpbXBsZW1lbnRlZCBpbiBzZXZlcmFsIE9TIHZlcnNpb25zIHRoYXQgYXJlIGRlcGxv eWVkLiBDYW4gc29tZW9uZQ0KIHdpdGggaGlzdG9yaWNhbCBjb250ZXh0IHBsZWFzZSBjaGltZSBp biBvbiB3aGF0IHRoZSBpbnRlbnQgd2FzIHNvIHdlIGNhbiByZXNvbHZlIHRoZSBpbmNvbnNpc3Rl bmN5IGFuZCBhbHNvIGNsYXJpZnkgdGhlIHJlcXVpcmVtZW50IGFyb3VuZCBjb250aW51aXR5Pw0K PGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiB0Y3BtICZs dDs8YSBocmVmPSJtYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ dGNwbS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgT24gQmVoYWxmIE9mIE1pY2hhZWwgVHVleGVu PGJyPg0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciA1LCAyMDE4IDk6NDUgQU08YnI+DQpUbzog WXVjaHVuZyBDaGVuZyAmbHQ7eWNoZW5nPTxhIGhyZWY9Im1haWx0bzo0MGdvb2dsZS5jb21AZG1h cmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCkNjOiBtYW9sc29uPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21A ZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0 Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij50Y3BtQGlldGYub3JnPC9hPiBFeHRlbnNpb25zICZsdDs8YSBocmVmPSJtYWlsdG86dGNwbUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRjcG1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1Ympl Y3Q6IFJlOiBbdGNwbV0gUkZDIDY2NzUgU0FDSyB0cmFja2luZzxicj4NCjxicj4NCiZndDsgT24g NS4gRGVjIDIwMTgsIGF0IDE3OjMxLCBZdWNodW5nIENoZW5nICZsdDt5Y2hlbmc9PGEgaHJlZj0i bWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwZ29v Z2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0 OyBPbiBXZWQsIERlYyA1LCAyMDE4IGF0IDg6MDIgQU0gTWF0dCBPbHNvbiA8YnI+DQomZ3Q7ICZs dDttYW9sc29uPTxhIGhyZWY9Im1haWx0bzo0MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj40MG1pY3Jvc29mdC5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBIaSwgSSBoYXZlIGEgcXVlc3Rpb24g YWJvdXQgdGhlIFJGQyA2Njc1IGNvbmRpdGlvbnMgZm9yIGRldGVybWluaW5nIGJ5dGVzIGxvc3Qu IEJlbG93IEkndmUgcGFzdGVkIHR3byByZWxldmFudCBwYXJ0cyBvZiB0aGUgUkZDLiBUaGUgY29u ZGl0aW9ucyBmb3IgbWFya2luZyBhIGJ5dGUgbG9zdCBhcmUgJnF1b3Q7Mk1TUyBvciAzIGRpc2Nv bnRpZ3VvdXMgU0FDS2VkIHJlZ2lvbnMgY29tZSBhZnRlciB0aGUgYnl0ZS4mcXVvdDsgVGhlIHBh cmFncmFwaCBiZWxvdw0KIGZyb20gU2VjdGlvbiA5IHByb3ZpZGVzIHNvbWUgcmF0aW9uYWxlIGZv ciB0aGUgJnF1b3Q7Mk1TUyZxdW90OyBwYXJ0LCB3aGljaCBjaGFuZ2VkIGZyb20gUkZDMzUxNyAo d2hpY2ggaGFkIGl0IGFzIDNNU1MpOiB3ZSB3YW50IHRvIGRldGVjdCBsb3NzIGV2ZW4gd2hlbiB0 aHJlZSBzdWItTVNTIHBhY2tldHMgYWZ0ZXIgdGhlIGJ5dGUgbWFkZSBpdCB0byB0aGUgcGVlci4g SW4gcGFydGljdWxhciBpdCBzYXlzICZxdW90O3RoaXMgcmV0YWlucyB0aGUgcmVxdWlyZW1lbnQg dGhhdA0KIGF0IGxlYXN0IHRocmVlIHNlZ21lbnRzIGZvbGxvd2luZyB0aGUgc2VxdWVuY2UgbnVt YmVyIGluIHF1ZXN0aW9uIGhhdmUgYmVlbiBTQUNLZWQuJnF1b3Q7IEJ1dCwgdGhpcyBkb2Vzbid0 IHNlZW0gdG8gYWRkIHVwOiBhIHNpbmdsZSByZWNlaXZlZCBTQUNLIGJsb2NrIGNvdmVyaW5nIDJN U1MgbWlnaHQgb25seSByZXByZXNlbnQgdHdvIHBhY2tldHMuPGJyPg0KJmd0OyZndDsgPGJyPg0K Jmd0OyZndDsgQmVzaWRlcyB0aGlzIGluY29uc2lzdGVuY3kgaW4gdGhlIFJGQywgSSB3b25kZXI6 IHdoeSBkbyB3ZSBjYXJlIGFib3V0ICZxdW90O2Rpc2NvbnRpZ3VvdXMgU0FDS2VkIHJlZ2lvbnMm cXVvdDsgYW55d2F5PyBJZiB3ZSByZWNlaXZlIHRocmVlIEFDS3MsIGVhY2ggd2l0aCBhIFNBQ0sg YmxvY2sgdGhhdCBpcyBhIHByb3BlciBzdXBlcnNldCBvZiB0aGUgcHJldmlvdXMgb25lLCBjYW4n dCB3ZSBjb25jbHVkZSB0aGF0IHRocmVlIHBhY2tldHMgYXJyaXZlZCBhdCB0aGUNCiBwZWVyIGFu ZCAoZm9sbG93aW5nIHRoZSBzcGlyaXQsIGlmIG5vdCB0aGUgbGV0dGVyLCBvZiBSRkMgNjY3NSkg Y29uY2x1ZGUgdGhhdCBhbnkgYnl0ZXMgcHJldmlvdXMgdG8gdGhlIHVuaW9uIG9mIHRob3NlIFNB Q0tzIHdlcmUgbG9zdD8gRXZlbiBpZiB0b2dldGhlciB0aGV5IFNBQ0sgbGVzcyB0aGFuIDJNU1Mg Ynl0ZXM/PGJyPg0KJmd0OyBJbiBteSBvcGluaW9uIHdlIHNob3VsZCBub3QgY2FyZSBhYm91dCB0 aGUgY29udGludWl0eSBvZiBTQUNLLCBvciBldmVuIDxicj4NCiZndDsgY291bnRpbmcgU0FDS3Mu IEkndmUgcHJvcG9zZWQgYSBuZXcgd2F5IHRvIGRldGVjdCBsb3NzZXMgKGltcGxlbWVudGVkIDxi cj4NCiZndDsgYnkgTGludXggJmFtcDsgTmV0RmxpeC5CU0QpPGJyPg0KSXQgaXMgaW4gdGhlIEZy ZWVCU0QgY29kZSBiYXNlIGFuZCB3aWxsIGJlIGluY2x1ZGVkIGluIHRoZSB1cGNvbWluZyByZWxl YXNlIDEyLjAuPGJyPg0KVGhlIGNvZGUgd2FzIGNvbnRyaWJ1dGVkIGJ5IE5ldGZsaXguPGJyPg0K PGJyPg0KQmVzdCByZWdhcmRzPGJyPg0KTWljaGFlbDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YSBo cmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRnRvb2xzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzPC9hPjxi cj4NCiZndDsgLjxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGaWV0Zi5vcmcmYW1wO2RhdGE9MDIlN0MwMSU3Q21h b2xzb24lNDBtaWNyb3NvZnQuY29tJTdDMmFmYzM5Y2E2NWU3NDU1ZTVkYTkwOGQ2NWFlNTkxOGQl N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Nzk2MzM5Mzg0 NzMxMzQ4JmFtcDtzZGF0YT1laHNQNTlKdWFSN2VWRWQlMkJ1QWI2dzhCRTl0VTlwdGZmVERpemx3 cFBHZzQlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5pZXRmLi5vcmc8L2E+JTJG aHRtbCUyRmRyYWZ0LWlldGYtdGNwbS1yYWNrLTA0JmFtcDthbXA7ZGF0YT0wMiU3QzAxJTdDcHJh dmIlNDA8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJGJTJGbWljcm9zb2Z0LmNvbSZhbXA7ZGF0YT0w MiU3QzAxJTdDbWFvbHNvbiU0MG1pY3Jvc29mdC5jb20lN0MyYWZjMzljYTY1ZTc0NTVlNWRhOTA4 ZDY1YWU1OTE4ZCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzY3OTYzMzkzODQ3MzEzNDgmYW1wO3NkYXRhPUptMzJCdzZsS1A0VlBFQkFpJTJGeXVBTjAxWFlB VUNXbWtrUVQwNm5HdkhIYyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KbWlj cm9zb2Z0LmNvbTwvYT4lN0MzZTMwYWVmNGY0Zjc0NzE5YzI3ZTA4ZDY1YWQ5N2FiMyU3QzcyZjk4 OGJmODZmMTQxYWY5MWE8YnI+DQomZ3Q7IGIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc5NjI4 NzQ0NjI1OTEzNiZhbXA7YW1wO3NkYXRhPXgxNHpjRjRSU3NmU1BiM2x3PGJyPg0KJmd0OyA5emtm cGNMWlBZcFdKWlhsbFRjV09KWndoQSUzRCZhbXA7YW1wO3Jlc2VydmVkPTA8YnI+DQomZ3Q7IDxi cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFRoYW5rcyE8YnI+DQomZ3Q7Jmd0OyA8YnI+DQom Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRv b2wiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9vbDwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBo cmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cCUzQSUyRiUyRnMuaWV0Zi5vcmcmYW1wO2RhdGE9MDIlN0MwMSU3Q21hb2xzb24lNDBtaWNy b3NvZnQuY29tJTdDMmFmYzM5Y2E2NWU3NDU1ZTVkYTkwOGQ2NWFlNTkxOGQlN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Nzk2MzM5Mzg0NzQxMzU2JmFtcDtz ZGF0YT1LTkhmJTJGY2E1bmE3bSUyQlljVEQxZmpaMW94QVhaR1lnMURVdDZUMUgzMCUyRmVnJTNE JmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpzLmlldGYub3JnPC9hPiUyRmh0bWwl MkZyZmM2Njc1JmFtcDthbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlPGEgaHJlZj0iaHR0cHM6Ly9u YW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkY0 MG1pY3Jvc29mdC5jb20mYW1wO2RhdGE9MDIlN0MwMSU3Q21hb2xzb24lNDBtaWNyb3NvZnQuY29t JTdDMmFmYzM5Y2E2NWU3NDU1ZTVkYTkwOGQ2NWFlNTkxOGQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Nzk2MzM5Mzg0NzUxMzY1JmFtcDtzZGF0YT1oRHNS MzR3OFR4bEFxJTJCc09xWGElMkZGdHd3bW9xcjMyVnB5JTJGUWxqd1hDcVdvJTNEJmFtcDtyZXNl cnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+NDBtaWNyb3NvZnQuY29tPC9hPiU8YnI+DQomZ3Q7Jmd0 OyA3QzNlMzBhZWY0ZjRmNzQ3MTljMjdlMDhkNjVhZDk3YWIzJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDc8YnI+DQomZ3Q7Jmd0OyAlN0MxJTdDMCU3QzYzNjc5NjI4NzQ0NjI1OTEz NiZhbXA7YW1wO3NkYXRhPWxjOGxTU295cE5sN1BqdXFWdTJLWXhqcTNvOTcxPGJyPg0KJmd0OyZn dDsgb0NNeTRpZGxYRFJXbmslM0QmYW1wO2FtcDtyZXNlcnZlZD0wPGJyPg0KJmd0OyZndDsgPGJy Pg0KJmd0OyZndDsmZ3Q7IEZyb20gc2VjdGlvbiA0Ojxicj4NCiZndDsmZ3Q7IElzTG9zdCAoU2Vx TnVtKTo8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoaXMgcm91dGluZSByZXR1 cm5zIHdoZXRoZXIgdGhlIGdpdmVuIHNlcXVlbmNlIG51bWJlciBpczxicj4NCiZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgY29uc2lkZXJlZCB0byBiZSBsb3N0LiZuYnNwOyBUaGUgcm91dGlu ZSByZXR1cm5zIHRydWUgd2hlbiBlaXRoZXI8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7IER1cFRocmVzaCBkaXNjb250aWd1b3VzIFNBQ0tlZCBzZXF1ZW5jZXMgaGF2ZSBhcnJpdmVk IGFib3ZlPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAnU2VxTnVtJyBvciBtb3Jl IHRoYW4gKER1cFRocmVzaCAtIDEpICogU01TUyBieXRlcyB3aXRoIHNlcXVlbmNlPGJyPg0KJmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBudW1iZXJzIGdyZWF0ZXIgdGhhbiAnU2VxTnVtJyBo YXZlIGJlZW4gU0FDS2VkLiZuYnNwOyBPdGhlcndpc2UsIHRoZTxicj4NCiZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgcm91dGluZSByZXR1cm5zIGZhbHNlLjxicj4NCiZndDsmZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyBGcm9tIHNlY3Rpb24gOTo8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDtU aGUgZnVuY3Rpb24gSXNMb3N0ICgpIGhhcyBiZWVuIG1vZGlmaWVkIHRvIHJlcXVpcmUgdGhhdCBt b3JlIHRoYW48YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsoRHVwVGhyZXNoIC0gMSkgKiBTTVNT IG9jdGV0cyBoYXZlIGJlZW4gU0FDS2VkIGFib3ZlIGEgZ2l2ZW4gc2VxdWVuY2U8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDtudW1iZXIgYXMgaW5kaWNhdGlvbiB0aGF0IGl0IGlzIGxvc3QsIHdo aWNoIGlzIGNoYW5nZWQgZnJvbSB0aGU8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDttaW5pbXVt IHJlcXVpcmVtZW50IG9mIChEdXBUaHJlc2ggKiBTTVNTKSBkZXNjcmliZWQgaW4gW1JGQzM1MTdd Ljxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO1RoaXMgcmV0YWlucyB0aGUgcmVxdWlyZW1lbnQg dGhhdCBhdCBsZWFzdCB0aHJlZSBzZWdtZW50cyBmb2xsb3dpbmc8YnI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDt0aGUgc2VxdWVuY2UgbnVtYmVyIGluIHF1ZXN0aW9uIGhhdmUgYmVlbiBTQUNLZWQs IHdoaWxlIGltcHJvdmluZzxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO2RldGVjdGlvbiBpbiB0 aGUgZXZlbnQgdGhhdCB0aGUgc2VuZGVyIGhhcyBvdXRzdGFuZGluZyBzZWdtZW50cyB3aGljaDxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwO2FyZSBzbWFsbGVyIHRoYW4gU01TUy48YnI+DQomZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsmZ3Q7IHRjcG0gbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsg PGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50Y3BtQGlldGYu b3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3IiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRnd3dzwvYT4uPGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9uYW0w Ni5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM0ElMkYlMkZpZXRm Lm9yZyZhbXA7ZGF0YT0wMiU3QzAxJTdDbWFvbHNvbiU0MG1pY3Jvc29mdC5jb20lN0MyYWZjMzlj YTY1ZTc0NTVlNWRhOTA4ZDY1YWU1OTE4ZCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzY3OTYzMzkzODQ3NTEzNjUmYW1wO3NkYXRhPW9wWEE0VjJyRzVtMEVj allYMlk3WE5kUTUyVkw1UlJseWYlMkJjZjlFUmQ2QSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0 PSJfYmxhbmsiPg0KaWV0Zi5vcmc8L2E+JTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGNwbSZhbXA7 YW1wO2RhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm88YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUz QSUyRiUyRnNvZnQuY29tJmFtcDtkYXRhPTAyJTdDMDElN0NtYW9sc29uJTQwbWljcm9zb2Z0LmNv bSU3QzJhZmMzOWNhNjVlNzQ1NWU1ZGE5MDhkNjVhZTU5MThkJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjc5NjMzOTM4NDc2MTM3MyZhbXA7c2RhdGE9bVNU WmtxNFBvMGdGV0xrZ0RadGo5VkR5dXlkcFlVNmN0aFNqYXYlMkZzbGMwJTNEJmFtcDtyZXNlcnZl ZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpzb2Z0LmNvbTwvYT4lN0MzZTMwYWVmNGY0Zjc0NzE5YzI3 ZTA4ZDY1YWQ5N2FiMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3PGJyPg0KJmd0OyZndDsgY2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzY3OTYyODc0NDYyNTkxMzYmYW1wO2FtcDtzZGF0YT1JcW5vVU9T Y0tLZWkzUHduWU0lMjxicj4NCiZndDsmZ3Q7IEIwSG1iclkxRVNjV2RJWm9ZbEd2aEFpVVUlM0Qm YW1wO2FtcDtyZXNlcnZlZD0wPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyB0Y3BtIG1haWxpbmcgbGlz dDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij50Y3BtQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaSIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaTwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJG JTJGZXRmLm9yZyZhbXA7ZGF0YT0wMiU3QzAxJTdDbWFvbHNvbiU0MG1pY3Jvc29mdC5jb20lN0My YWZjMzljYTY1ZTc0NTVlNWRhOTA4ZDY1YWU1OTE4ZCU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3OTYzMzkzODQ3NjEzNzMmYW1wO3NkYXRhPWlLOTJ2ZVVS cFlnaGpIelNENFFuY1RaOVclMkJGc2R4N0VWZTVoamtqWW90RSUzRCZhbXA7cmVzZXJ2ZWQ9MCIg dGFyZ2V0PSJfYmxhbmsiPg0KZXRmLm9yZzwvYT4lMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3Bt JmFtcDthbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvPGJyPg0KJmd0OyA8YSBocmVm PSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cCUzQSUyRiUyRmZ0LmNvbSZhbXA7ZGF0YT0wMiU3QzAxJTdDbWFvbHNvbiU0MG1pY3Jvc29mdC5j b20lN0MyYWZjMzljYTY1ZTc0NTVlNWRhOTA4ZDY1YWU1OTE4ZCU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY3OTYzMzkzODQ3NzEzODEmYW1wO3NkYXRhPVNF ZGhLYWREQkp2QmRqJTJCWUtwaHN2RjRnTkZSdXp3Y1JLdEVGOVdGdFhzSSUzRCZhbXA7cmVzZXJ2 ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0KZnQuY29tPC9hPiU3QzNlMzBhZWY0ZjRmNzQ3MTljMjdl MDhkNjVhZDk3YWIzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDA8YnI+DQomZ3Q7IDExZGI0 NyU3QzElN0MwJTdDNjM2Nzk2Mjg3NDQ2MjU5MTM2JmFtcDthbXA7c2RhdGE9SXFub1VPU2NLS2Vp M1B3bllNJTJCMEhtPGJyPg0KJmd0OyBiclkxRVNjV2RJWm9ZbEd2aEFpVVUlM0QmYW1wO2FtcDty ZXNlcnZlZD0wPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQp0Y3BtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0 Y3BtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGNwbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFt cDtkYXRhPTAyJTdDMDElN0NtYW9sc29uJTQwbWljcm9zb2Z0LmNvbSU3QzJhZmMzOWNhNjVlNzQ1 NWU1ZGE5MDhkNjVhZTU5MThkJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjc5NjMzOTM4NDc4MTM5MCZhbXA7c2RhdGE9dld6MjNmdklMYm8yUjZtczhmQUtI SHMyaG9GbVJrenhqelk3SmJVYSUyQlNRJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0Y3BtJmFtcDth bXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDM2UzMGFlZjRmNGY3NDcx OWMyN2UwOGQ2NWFkOTdhYjMlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM2Nzk2Mjg3NDQ2MjU5MTM2JmFtcDthbXA7c2RhdGE9SXFub1VPU2NLS2VpM1B3bllN JTJCMEhtYnJZMUVTY1dkSVpvWWxHdmhBaVVVJTNEJmFtcDthbXA7cmVzZXJ2ZWQ9MDwvYT48YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCnRjcG0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj50Y3BtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v bmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy Rnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRjcG0mYW1wO2RhdGE9MDIlN0Mw MSU3Q21hb2xzb24lNDBtaWNyb3NvZnQuY29tJTdDMmFmYzM5Y2E2NWU3NDU1ZTVkYTkwOGQ2NWFl NTkxOGQlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Nzk2 MzM5Mzg0NzgxMzkwJmFtcDtzZGF0YT12V3oyM2Z2SUxibzJSNm1zOGZBS0hIczJob0ZtUmt6eGp6 WTdKYlVhJTJCU1ElM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG08L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB0118A14A241CDF2529762CBBBCA80CY4PR21MB0118namp_-- From nobody Fri Dec 14 16:22:10 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B45130EB3 for ; Fri, 14 Dec 2018 16:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW5u31I5I43x for ; Fri, 14 Dec 2018 16:22:05 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-co1nam04on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe4d::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17AC127B4C for ; Fri, 14 Dec 2018 16:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BhmhndDUVLV7lW3QTR4nPH48bldRbVJBbDw1jHWittA=; b=J3RXQQwDl4w6DwENWKAaizAagztLhiKqIm+sTpJ6ymkTysa6w8uhcEWxokGzCHVNMHzl9+r/ZJm+a7/1I2Ii94sr4jsWwg8p+SmrwfknQNhpqu6gcgHP/FdHWTncxQ2OXQszy5r+nNe98ULg9aSHIcu6tuL4VtnSiarAYvtkGTc= Received: from SN6PR2101MB0909.namprd21.prod.outlook.com (52.132.117.10) by SN6PR2101MB1071.namprd21.prod.outlook.com (52.132.115.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.5; Sat, 15 Dec 2018 00:22:03 +0000 Received: from SN6PR2101MB0909.namprd21.prod.outlook.com ([fe80::8c0d:9d4d:7dc0:51ac]) by SN6PR2101MB0909.namprd21.prod.outlook.com ([fe80::8c0d:9d4d:7dc0:51ac%2]) with mapi id 15.20.1446.006; Sat, 15 Dec 2018 00:22:03 +0000 From: Yi Huang To: "tcpm@ietf.org" CC: Praveen Balasubramanian , Matt Olson Thread-Topic: review of draft-ietf-tcpm-rack-04 Thread-Index: AdSUC7G8XsAiniw3RrSyMOXGtuTizQ== Date: Sat, 15 Dec 2018 00:22:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=huanyi@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-12-15T00:22:02.3329640Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:0:8174:c742:70c:c51a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1071; 6:CMeHYqx+/NAhV6g82VPi494iDiXGNKXwWtX/RRCOv8HB1q8djdnRg14tr3eHkuejtg6i4bYg7Xmhz/q+W04Ju8o/n9G5un+7AMgnHE8jwnhQDV0yWn9lCkt8L2PtkkheRPM98CSB2Ti8/8b8YqS7CEcqL0QjKrgwpCqfP5HGR/ZEAd9XlrOzYoi0rA29gwpXDsOIxuBWLARrSqkWwL3Jeo8MqTm3IfbBejkRMSB9k8Nu4+m2FfgB0CMhxbAgWSHtCnlqiRt8BRvP9Ex2/qzANDJFXN7vPDPjtfjTddCBb6t6SkN44r+ll3eRrVyT61OZZr0kTvD4J7HkQr65rJ9d5gf+U91E8BsQ/yOouW3txQWEemHafVOhLI4BT6MKpWHFLiIkTCk1kfDm73PgRgjbepukFBDaezHIk2lZeCnjj/woRUV/dBkFAJNYWIWMYQE51lhjLJuek1tkaMXzcqwNdQ==; 5:ZZk/tkIH2nnEEyP+r4XTCgE6bDFIhkABPqEdnjDKqi60pO/jc4MaUBRAOActFF+f0A1KygECKRShHIiFTxWEEcNxldZpBzjg0azbDRsvx8QT16zJoWFTOyVXOTwdivzwXpu8icYiCzzB7isP9sWlbpvhb5dIBK6sXqIwnPEIQ94=; 7:XAfBTrc8afixwisP7WUI1YlP3pOznE6NnuUntozC5QieXcDJIINZvsXGyHeP0oXU+PR3js1X48ABGlHIpMdtliZYwwvhJwjoww0cviOw2f36eBXHijn2q5urVFHkSyJD134MEYyoYQVUD3Oh65bJvQ== x-ms-office365-filtering-correlation-id: 7f024b31-d36d-480c-36f6-08d6622356c4 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SN6PR2101MB1071; x-ms-traffictypediagnostic: SN6PR2101MB1071: x-ms-exchange-purlcount: 2 authentication-results: spf=none (sender IP is ) smtp.mailfrom=huanyi@microsoft.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(5005014)(6040522)(8220035)(2401047)(8121501046)(93006095)(93001095)(3002001)(3231475)(944501520)(2018427008)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:SN6PR2101MB1071; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB1071; x-forefront-prvs: 088751B4D4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(39860400002)(136003)(376002)(396003)(199004)(189003)(107886003)(53936002)(316002)(22452003)(2501003)(256004)(6916009)(71200400001)(99286004)(14444005)(6116002)(2351001)(790700001)(71190400001)(6436002)(55016002)(5640700003)(54896002)(6306002)(9686003)(54906003)(33656002)(105586002)(86612001)(86362001)(476003)(486006)(68736007)(186003)(25786009)(106356001)(74316002)(7736002)(6506007)(8990500004)(478600001)(10290500003)(102836004)(46003)(9326002)(81166006)(2906002)(14454004)(4326008)(81156014)(8676002)(10090500001)(7696005)(1730700003)(8936002)(5660300001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1071; H:SN6PR2101MB0909.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: OUjlf9tRtTRumd9LAVrFXa9hTfyP8hiyJPjzfJ/n5Go2GWHD2EK4cVXE2zK7jdDZjyjrBtsjYD6n5IB8pVoPWJEiYc0CiOi7OgU4iabDXvrV8rvLWGPRSUcc0Qpy103GeFxEixXPc3kunMLt3unVdejOhHW2Evr0IH+USAcg+4D8nJrB9g+ZgCk4Tk8BAD/AI3jdGwMeTvez2k2/IXJmW+Thf+1oCviF7r+xCnEEMnj0sOvbJAU2oKKDTGEmvK6A2W1/HXzSigl9H/CLK0vd5JVjty0OwTsGAAaFX1OwfiDC7NTQrSGKxQfLw3ZjLQLf spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR2101MB090982053327B242581F079CC3A20SN6PR2101MB0909_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f024b31-d36d-480c-36f6-08d6622356c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2018 00:22:03.6959 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1071 Archived-At: Subject: [tcpm] review of draft-ietf-tcpm-rack-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 00:22:09 -0000 --_000_SN6PR2101MB090982053327B242581F079CC3A20SN6PR2101MB0909_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQpJIGhhdmUgcmVhZCBkcmFmdC1pZXRmLXRjcG0tcmFjay0wNCBhbmQgaGF2ZSBz b21lIHRob3VnaHRzIHRvIHNoYXJlIHdpdGggdGNwbS4NCg0KDQoNCjEuIFBhZ2UuIDEzLCBpdCBz ZWVtcyB0aGVyZSBpcyBhIGJ1ZyBpbiB0aGUgcHNldWRvY29kZSBvZiBSQUNLX2RldGVjdF9sb3Nz KCkgKExpbmUgNSkuDQoNCkZvciBlYWNoIHBhY2tldCwgUGFja2V0LCBub3QgYWNrbm93bGVkZ2Vk IHlldDoNCg0KICAgICAgICBJZiBQYWNrZXQubG9zdCBpcyBUUlVFIG9yIFBhY2tldC5yZXRyYW5z bWl0dGVkIGlzIEZBTFNFOiAvLyDigJxvcuKAnSBzaG91bGQgYmUgY2hhbmdlZCB0byDigJxhbmTi gJ0NCg0KICAgICAgICAgICAgQ29udGludWUgLyogTG9zdCBwYWNrZXQgbm90IHJldHJhbnNtaXR0 ZWQgeWV0ICovDQoNCg0KDQpUaGUgY3VycmVudCBsb2dpYyB3b3VsZCBza2lwIGFueSBwYWNrZXRz IHRoYXQgbmVlZCB0byBiZSByZXRyYW5zbWl0dGVkIGluIHNjb3JlYm9hcmQuIEFsc28sIHRoZSBj b21tZW50IGFmdGVyIOKAnENvbnRpbnVl4oCdIGFsc28gc2F5cyDigJxMb3N0IHBhY2tldCBub3Qg cmV0cmFuc21pdHRlZCB5ZXTigJ0gd2hpY2ggaW1wbGljaXRseSBpcyBhbiBBTkQuDQoNCg0KDQoy LiBJbiBQYWdlIDE5LCB0aGUgZm9sbG93aW5nIHN0YXRlbWVudHMgYXJlIGNvbnRyYWRpY3Rvcnku DQoNCg0KDQphLiBBIHNlbmRlciBjb25zaWRlcnMgYm90aCB0aGUgb3JpZ2luYWwgc2VnbWVudCBh bmQgVExQIHByb2JlIHJldHJhbnNtaXNzaW9uIHNlZ21lbnQgYXMgYWNrbm93bGVkZ2VkIGlmIGVp dGhlciAxIG9yIDIgYXJlIHRydWU6DQoNCmIuIElmIG5laXRoZXIgY29uZGl0aW9ucyBhcmUgbWV0 LCB0aGVuIHRoZSBzZW5kZXIgZXN0aW1hdGVzIHRoYXQgdGhlIHJlY2VpdmVyIHJlY2VpdmVkIGJv dGggdGhlIG9yaWdpbmFsIGRhdGEgc2VnbWVudCBhbmQgdGhlIFRMUCBwcm9iZSByZXRyYW5zbWlz c2lvbiwgYW5kIHNvIHRoZSBzZW5kZXIgY29uc2lkZXJzIHRoZSBUTFAgZXBpc29kZSB0byBiZSBk b25lLCBhbmQgcmVjb3JkcyB0aGF0IGZhY3QgYnkgc2V0dGluZyBUTFBSeHRPdXQgdG8gZmFsc2Uu DQoNCg0KDQpJIHRoaW5rLCBpbiBiLCDigJxuZWl0aGVy4oCdIHNob3VsZCBiZSBjaGFuZ2VkIHRv IOKAnGVpdGhlcuKAnSBzaW5jZSB0aGUg4oCcdGhlbuKAnSBwYXJ0IGlzIHRoZSBzYW1lIGZvciBh IGFuZCBiLCB3aGljaCBzYXlzIGJvdGggdGhlIG9yaWdpbmFsIHNlZ21lbnQgYW5kIHByb2JlIGFy ZSBhY2tlZC4NCg0KDQoNCjMuIFBhZ2UgNywgZnJvbSAiUkFDSy5yZW9fd25kX3BlcnNpc3QiIHRv IHRoZSBlbmQgb2YgdGhpcyBwYXJhZ3JhcGgsIHB1bmN0dWF0aW9ucyBtaWdodCBiZSBuZWVkZWQg c2luY2Ugc2V2ZXJhbCB2YXJpYWJsZSBkZWZpbml0aW9ucyBzdGljayB0b2dldGhlci4NCg0KDQpU aGFua3MsDQoNCllpDQo= --_000_SN6PR2101MB090982053327B242581F079CC3A20SN6PR2101MB0909_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAueG1zb25vcm1hbCwg bGkueG1zb25vcm1hbCwgZGl2Lnhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6eF9tc29ub3Jt YWw7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMw NTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0ieG1zb25vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+SSBoYXZlIHJl YWQgZHJhZnQtaWV0Zi10Y3BtLXJhY2stMDQgYW5kIGhhdmUgc29tZSB0aG91Z2h0cyB0byBzaGFy ZSB3aXRoIHRjcG0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+MS4gUGFnZS4gMTMsIGl0IHNl ZW1zIHRoZXJlIGlzIGEgYnVnIGluIHRoZSBwc2V1ZG9jb2RlIG9mIFJBQ0tfZGV0ZWN0X2xvc3Mo KSAoTGluZSA1KS4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Inhtc29ub3JtYWwiPkZvciBlYWNoIHBhY2tldCwgUGFja2V0LCBub3QgYWNrbm93bGVkZ2Vk IHlldDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgUGFja2V0Lmxvc3QgaXMgVFJVRSBvciBQ YWNrZXQucmV0cmFuc21pdHRlZCBpcyBGQUxTRTogLy8g4oCcb3LigJ0gc2hvdWxkIGJlIGNoYW5n ZWQgdG8g4oCcYW5k4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IENvbnRpbnVlIC8qIExvc3QgcGFja2V0IG5vdCByZXRyYW5zbWl0dGVkIHlldCAqLzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPlRoZSBjdXJyZW50IGxvZ2ljIHdvdWxkIHNraXAgYW55 IHBhY2tldHMgdGhhdCBuZWVkIHRvIGJlIHJldHJhbnNtaXR0ZWQgaW4gc2NvcmVib2FyZC4gQWxz bywgdGhlIGNvbW1lbnQgYWZ0ZXIg4oCcQ29udGludWXigJ0gYWxzbyBzYXlzIOKAnExvc3QgcGFj a2V0IG5vdCByZXRyYW5zbWl0dGVkIHlldOKAnSB3aGljaCBpbXBsaWNpdGx5IGlzIGFuIEFORC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj4yLiBJbiBQYWdlIDE5LCB0aGUgZm9sbG93aW5nIHN0 YXRlbWVudHMgYXJlIGNvbnRyYWRpY3RvcnkuIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0i eG1zb25vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Inhtc29ub3JtYWwiPmEuIEEgc2VuZGVyIGNvbnNpZGVycyBib3RoIHRoZSBvcmlnaW5hbCBz ZWdtZW50IGFuZCBUTFAgcHJvYmUgcmV0cmFuc21pc3Npb24gc2VnbWVudCBhcyBhY2tub3dsZWRn ZWQgaWYgZWl0aGVyIDEgb3IgMiBhcmUgdHJ1ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4 bXNvbm9ybWFsIj5iLiBJZiBuZWl0aGVyIGNvbmRpdGlvbnMgYXJlIG1ldCwgdGhlbiB0aGUgc2Vu ZGVyIGVzdGltYXRlcyB0aGF0IHRoZSByZWNlaXZlciByZWNlaXZlZCBib3RoIHRoZSBvcmlnaW5h bCBkYXRhIHNlZ21lbnQgYW5kIHRoZSBUTFAgcHJvYmUgcmV0cmFuc21pc3Npb24sIGFuZCBzbyB0 aGUgc2VuZGVyIGNvbnNpZGVycyB0aGUgVExQIGVwaXNvZGUgdG8gYmUgZG9uZSwgYW5kIHJlY29y ZHMgdGhhdCBmYWN0IGJ5IHNldHRpbmcNCiBUTFBSeHRPdXQgdG8gZmFsc2UuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPkkgdGhpbmssIGluIGIsIOKAnG5laXRoZXLi gJ0gc2hvdWxkIGJlIGNoYW5nZWQgdG8g4oCcZWl0aGVy4oCdIHNpbmNlIHRoZSDigJx0aGVu4oCd IHBhcnQgaXMgdGhlIHNhbWUgZm9yIGEgYW5kIGIsIHdoaWNoIHNheXMgYm90aCB0aGUgb3JpZ2lu YWwgc2VnbWVudCBhbmQgcHJvYmUgYXJlIGFja2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Inhtc29ub3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inhtc29ub3JtYWwi PjMuIFBhZ2UgNywgZnJvbSAmcXVvdDtSQUNLLnJlb193bmRfcGVyc2lzdCZxdW90OyB0byB0aGUg ZW5kIG9mIHRoaXMgcGFyYWdyYXBoLCBwdW5jdHVhdGlvbnMgbWlnaHQgYmUgbmVlZGVkIHNpbmNl IHNldmVyYWwgdmFyaWFibGUgZGVmaW5pdGlvbnMgc3RpY2sgdG9nZXRoZXIuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllpPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN6PR2101MB090982053327B242581F079CC3A20SN6PR2101MB0909_-- From nobody Sun Dec 16 19:19:20 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCC7130E43 for ; Sun, 16 Dec 2018 19:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.96 X-Spam-Level: X-Spam-Status: No, score=-18.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSv1_djopMHw for ; Sun, 16 Dec 2018 19:19:17 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 27208130E29 for ; Sun, 16 Dec 2018 19:19:17 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id a6so17895855itl.4 for ; Sun, 16 Dec 2018 19:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=yvS8lUrmtTovOnDd+qHCk0K5cWKJjZhD4Mu/2j7kX6Q=; b=ZnShbdZImo5H0UIBlLNJ5mDjrRXUB3uyRwb91DF3rObKLytvpCJB52V5xlYham2UeQ rgy6l+9OlPJdslsy02pH3c05TgYl0DXXTngg9DyY4e8Sxl+UfhKWavj676nA6kyuYbPK FBmg7biS8DVCO8xLM3wfj3t8AJNYQ/lDTZiE1gM9tQzHrpQW6yE74BqfU3p6HkMDvrF5 +HS4TrnaCCXUTrkbYWa1+VbruN8etO9LGYsMyWjQhy9IZSO3TxBp8FzJvLvAQtkMG/iE +UYCL3xD40MhISAQXoQXc27SpSZQPpsowk34ZY7ypD2qVkpjApI4StzQz4SmO9ACsV7l b2FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=yvS8lUrmtTovOnDd+qHCk0K5cWKJjZhD4Mu/2j7kX6Q=; b=MM3yVvRgoTwxpjYKUxVPh6lTK4gOQl4sUS1Dtp4oSWlmMGSwWJcbUanvAFt2Z/Vmb5 B4A9aRpSLyWAMyV44d1cSpumA2o/SjAHXGnhAvAQljPc0YNFp+LiarSx0TeTVi5f4Tbw 1OGZwbbEdILguCRyZLI6RviIwq7vw056Ycgxl6ZfLY5DuMtCR/d/5484buBBgG9ULtNu CWhGorsYoPp6W6pGWENpW7/nZIGH2W/bD1JOtvLmToAqOAI6ActHAHiNFCFXIj4ircVY srwp1VmT4rLrd7IWxtRsvDu30S+JrLyB0HWHgUbMKQRy59UA0FMuHUfIHT7kuv2YZ5Yg 0SqQ== X-Gm-Message-State: AA+aEWY8AGLdc/NQOIce2GW3qZr6OaL5soVbvVXZQqSgUWwXA+vXZ63C vhRzHw+1G/3GMb7O7g4r1NTmqJFHV0+VkpZu6tsPXQ== X-Google-Smtp-Source: AFSGD/WVkDzrEmnSkIHMFTj0lkDNg2Q4zT6LtdA/eqUfvE9oLNnvMFXYh3anPWggvTyAj0qQIDeUNKNw1uC47pkU9DA= X-Received: by 2002:a24:55cf:: with SMTP id e198mr10408419itb.110.1545016756128; Sun, 16 Dec 2018 19:19:16 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Sun, 16 Dec 2018 19:18:39 -0800 Message-ID: To: Yi Huang Cc: "tcpm@ietf.org" , Matt Olson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] review of draft-ietf-tcpm-rack-04 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 03:19:19 -0000 Thanks for the good catches. Ack and will revise the three issues in the next draft. On Fri, Dec 14, 2018 at 4:22 PM Yi Huang wrote: > > Hi, > > > > I have read draft-ietf-tcpm-rack-04 and have some thoughts to share with = tcpm. > > > > 1. Page. 13, it seems there is a bug in the pseudocode of RACK_detect_los= s() (Line 5). > > For each packet, Packet, not acknowledged yet: > > If Packet.lost is TRUE or Packet.retransmitted is FALSE: // =E2= =80=9Cor=E2=80=9D should be changed to =E2=80=9Cand=E2=80=9D > > Continue /* Lost packet not retransmitted yet */ > > > > The current logic would skip any packets that need to be retransmitted in= scoreboard. Also, the comment after =E2=80=9CContinue=E2=80=9D also says = =E2=80=9CLost packet not retransmitted yet=E2=80=9D which implicitly is an = AND. > > > > 2. In Page 19, the following statements are contradictory. > > > > a. A sender considers both the original segment and TLP probe retransmiss= ion segment as acknowledged if either 1 or 2 are true: > > b. If neither conditions are met, then the sender estimates that the rece= iver received both the original data segment and the TLP probe retransmissi= on, and so the sender considers the TLP episode to be done, and records tha= t fact by setting TLPRxtOut to false. > > > > I think, in b, =E2=80=9Cneither=E2=80=9D should be changed to =E2=80=9Cei= ther=E2=80=9D since the =E2=80=9Cthen=E2=80=9D part is the same for a and b= , which says both the original segment and probe are acked. > > > > 3. Page 7, from "RACK.reo_wnd_persist" to the end of this paragraph, punc= tuations might be needed since several variable definitions stick together. > > > > Thanks, > > > > Yi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Dec 18 13:48:29 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BA71312A8; Tue, 18 Dec 2018 13:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fErFxgTbhHCC; Tue, 18 Dec 2018 13:48:16 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E56A1312A1; Tue, 18 Dec 2018 13:48:15 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4CED7B80C36; Tue, 18 Dec 2018 13:47:52 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, tcpm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20181218214752.4CED7B80C36@rfc-editor.org> Date: Tue, 18 Dec 2018 13:47:52 -0800 (PST) Archived-At: Subject: [tcpm] =?utf-8?q?RFC_8511_on_TCP_Alternative_Backoff_with_ECN_?= =?utf-8?b?KEFCRSk=?= X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 21:48:22 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8511 Title: TCP Alternative Backoff with ECN (ABE) Author: N. Khademi, M. Welzl, G. Armitage, G. Fairhurst Status: Experimental Stream: IETF Date: December 2018 Mailbox: naeemk@ifi.uio.no, michawe@ifi.uio.no, garmitage@netflix.com, gorry@erg.abdn.ac.uk Pages: 12 Characters: 27408 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-alternativebackoff-ecn-12.txt URL: https://www.rfc-editor.org/info/rfc8511 DOI: 10.17487/RFC8511 Active Queue Management (AQM) mechanisms allow for burst tolerance while enforcing short queues to minimise the time that packets spend enqueued at a bottleneck. This can cause noticeable performance degradation for TCP connections traversing such a bottleneck, especially if there are only a few flows or their bandwidth-delay product (BDP) is large. The reception of a Congestion Experienced (CE) Explicit Congestion Notification (ECN) mark indicates that an AQM mechanism is used at the bottleneck, and the bottleneck network queue is therefore likely to be short. Feedback of this signal allows the TCP sender-side ECN reaction in congestion avoidance to reduce the Congestion Window (cwnd) by a smaller amount than the congestion control algorithm's reaction to inferred packet loss. Therefore, this specification defines an experimental change to the TCP reaction specified in RFC 3168, as permitted by RFC 8311. This document is a product of the TCP Maintenance and Minor Extensions Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Dec 28 08:01:32 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77550130E6A for ; Thu, 27 Dec 2018 11:30:48 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Q6bKHIJikdd for ; Thu, 27 Dec 2018 11:30:46 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A11130E5F for ; Thu, 27 Dec 2018 11:30:46 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 2BD5EB81008; Thu, 27 Dec 2018 11:30:42 -0800 (PST) To: david.borman@quantum.com, braden@isi.edu, vanj@google.com, rs@netapp.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nishida@sfc.wide.ad.jp X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: marco.caspers@t-mobilethuis.nl, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181227193042.2BD5EB81008@rfc-editor.org> Date: Thu, 27 Dec 2018 11:30:42 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 28 Dec 2018 08:01:30 -0800 Subject: [tcpm] [Technical Errata Reported] RFC7323 (5585) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 19:30:48 -0000 The following errata report has been submitted for RFC7323, "TCP Extensions for High Performance". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5585 -------------------------------------- Type: Technical Reported by: Marco Caspers Section: 2.2 Original Text ------------- 2.2. Window Scale Option The three-byte Window Scale option MAY be sent in a segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to both send and receive window scaling, and (2) communicate the exponent of a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows SHOULD send the option, even if its own scale factor is 1 and the exponent 0. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations. The maximum scale exponent is limited to 14 for a maximum permissible receive window size of 1 GiB (2^(14+16)). Corrected Text -------------- 2.2. Window Scale Option The three-byte Window Scale option MAY be sent in a segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to both send and receive window scaling, and (2) communicate the exponent of a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows SHOULD send the option, even if its own scale factor is 1 and the exponent 0. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations. The maximum scale exponent is limited to 14 for a maximum permissible receive window size of approximately 1 GiB ((2^30-1) - (2^14-1)). Notes ----- Left shift inserts zero's on the right hand side so the maximum window size is actually approximately 16KiB shy of 1 GiB and not exactly 1Gib as stated. The calculation given 2^(16+14) is mathematically incorrect. Stating invalid calculations will lead to invalid implementations. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7323 (draft-ietf-tcpm-1323bis-21) -------------------------------------- Title : TCP Extensions for High Performance Publication Date : September 2014 Author(s) : D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed. Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Fri Dec 28 08:01:40 2018 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9C6130E89 for ; Thu, 27 Dec 2018 11:47:38 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NVZB1Uw_ngv for ; Thu, 27 Dec 2018 11:47:36 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658D2130E84 for ; Thu, 27 Dec 2018 11:47:36 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E2F33B81159; Thu, 27 Dec 2018 11:47:31 -0800 (PST) To: david.borman@quantum.com, braden@isi.edu, vanj@google.com, rs@netapp.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nishida@sfc.wide.ad.jp X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: marco.caspers@t-mobilethuis.nl, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20181227194731.E2F33B81159@rfc-editor.org> Date: Thu, 27 Dec 2018 11:47:31 -0800 (PST) Archived-At: X-Mailman-Approved-At: Fri, 28 Dec 2018 08:01:30 -0800 Subject: [tcpm] [Technical Errata Reported] RFC7323 (5586) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 19:47:39 -0000 The following errata report has been submitted for RFC7323, "TCP Extensions for High Performance". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5586 -------------------------------------- Type: Technical Reported by: Marco Caspers Section: 2.3 Original Text ------------- Since the max window is 2^S (where S is the scaling shift count) times at most 2^16 - 1 (the maximum unscaled window), the maximum window is guaranteed to be < 2^30 if S <= 14. Thus, the shift count MUST be limited to 14 (which allows windows of 2^30 = 1 GiB). If a Window Scale option is received with a shift.cnt value larger than 14, the TCP SHOULD log the error but MUST use 14 instead of the specified value. This is safe as a sender can always choose to only partially use any signaled receive window. If the receiver is scaling by a factor larger than 14 and the sender is only scaling by 14, then the receive window used by the sender will appear smaller than it is in reality. Corrected Text -------------- Since the max window is 2^S (where S is the scaling shift count) times at most 2^16 - 1 (the maximum unscaled window), the maximum window is guaranteed to be < 2^30-2^14 if S <= 14. Thus, the shift count MUST be limited to 14 (which allows windows of 2^30-2^14 ~ 1 GiB). If a Window Scale option is received with a shift.cnt value larger than 14, the TCP SHOULD log the error but MUST use 14 instead of the specified value. This is safe as a sender can always choose to only partially use any signaled receive window. If the receiver is scaling by a factor larger than 14 and the sender is only scaling by 14, then the receive window used by the sender will appear smaller than it is in reality. Notes ----- Shifting is inserting zeroes on the right hand side. Thus for S = 14 the 14 right most bits are zero and thus the calculation 2^30 is invalid for the guaranteed maximum window size. Correct calculation formulae is (2^30 - 1) - (2^14 -1). Which can be simplified to 2^30 - 2^14. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7323 (draft-ietf-tcpm-1323bis-21) -------------------------------------- Title : TCP Extensions for High Performance Publication Date : September 2014 Author(s) : D. Borman, B. Braden, V. Jacobson, R. Scheffenegger, Ed. Category : PROPOSED STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG