Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice
tom petch <ietfa@btconnect.com> Fri, 12 June 2020 09:47 UTC
Return-Path: <ietfa@btconnect.com>
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 633043A0ED0; Fri, 12 Jun 2020 02:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QKvVJqNsVqO; Fri, 12 Jun 2020 02:47:52 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80102.outbound.protection.outlook.com [40.107.8.102]) (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 C6D373A0A9D; Fri, 12 Jun 2020 02:47:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CEvZ4O91Oc/ybg2ADQ5AsVeM7ZziNiId41BiDjaz4suwApP54SGwo518VrT7Tbv6ObTzEFHpVaE2HySGT1e7/5nic8Z1xHz+VQunbSy4xFCBM+J9fkRnhDttAZmD5sSTO9lHdGfV0P5KA0grNICDySBR6DDkmyAsuilVIMa0Qfb+7Y8V8KJ/G0kKfVBxKr1GTdgKLNLcTlUKo8DMgM68McaEeaEpzamRSiAYgOAZX5ZFsg/919qRPNrZp9GFJqMI9CLhyjPfQrj7Zf1TJFsuahJF0Yl3/bFYynGav8exVsI8APFfx8pq08/1oWtfb7f07Pc0Kp4RcM9wYbHiSzS83A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hgCFBLiiPOUxNsn5gHnHRgHOc3y2ESYcL0L70xsvEZ0=; b=Yx724NkTxqXimIlxDgPaielmfDKKbUcFjQJ3phPAO+3N8XOEKFSf2MkLVbIPWMD3ozvfpvN4taycPpnKZnkP0QeJt9YOzLmtXIRfbAafOw2fzzo4gOl4QJ5+iubyb9SnJn/u7M1WPwKmfebRKi6bvmr4jVWFwmOsD/uYtLwitmBD1rqfdeKRkulrPqTaP3oyCB9FV9hNRYJCq9t2OwMOf2X/i6L+hXY6MqzBYq4XyB1KAJG4fz5k7qH17lFpDjdLFrG3ORLpmlp7abBCWAwY6AKF3RS+stR8hpZBxIN4k4McGkQgvC+Q6vTw+dE45mMZeNYt4WJL5o0T0hcDyQXelg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hgCFBLiiPOUxNsn5gHnHRgHOc3y2ESYcL0L70xsvEZ0=; b=wFJhM5pIzurVFd6f3LQ6D9roag4tR2DpMD8tknTqcVSQrvdPznSeZhqSqq/wLAnT3t1JM11dkUb0x1uSdWo59R+C4JKSEV6+4kzKukZx55Ofxuzs17xSAawonwLssaUYJV57HkBnwGah6xWOT0pWvnYKle1EaZir3WSdSu0qg5s=
Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB7PR07MB4537.eurprd07.prod.outlook.com (2603:10a6:5:2c::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.7; Fri, 12 Jun 2020 09:47:48 +0000
Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::6d73:b879:b380:bed4]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::6d73:b879:b380:bed4%7]) with mapi id 15.20.3088.019; Fri, 12 Jun 2020 09:47:48 +0000
From: tom petch <ietfa@btconnect.com>
To: Martin Duke <martin.h.duke@gmail.com>
CC: Mark Allman <mallman@icir.org>, Last Call <last-call@ietf.org>, tcpm <tcpm@ietf.org>, "draft-ietf-tcpm-rto-consider@ietf.org" <draft-ietf-tcpm-rto-consider@ietf.org>, "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
Thread-Topic: [tcpm] [Last-Call] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice
Thread-Index: AQHWNQ2m9gFeETvyo0Wr/I+Dg676t6i+70PggAAUpICAAX7IgIAJg2SAgAAyuICAAAaRgIAEMVRigAWHOACAANi/hA==
Date: Fri, 12 Jun 2020 09:47:48 +0000
Message-ID: <DB7PR07MB53401B7092F57A088CED3552A2810@DB7PR07MB5340.eurprd07.prod.outlook.com>
References: <158981133458.2481.15195759097492819350@ietfa.amsl.com> <DB7PR07MB53406A74483D8123C75ADD70A28E0@DB7PR07MB5340.eurprd07.prod.outlook.com> <5ECFE791.3050400@btconnect.com> <055C1A6F-3EA9-4695-869F-BDE0A4943BE5@icsi.berkeley.edu> <5ED0F22E.1070402@btconnect.com> <7CD0EF44-D26A-4F85-AA6A-91D3C55B44AC@icir.org> <5ED244F7.7030307@btconnect.com> <9AF1F719-7F29-4080-99E8-C0AB83DF1FF9@icir.org> <1UWAyt4aeg.1UCdKrbr8wj@pc8xp> <7534662C-6B13-4788-BD1F-F89B404C1088@icir.org> <DB7PR07MB5340CD431F596B63A812A360A2850@DB7PR07MB5340.eurprd07.prod.outlook.com>, <CAM4esxR_2x-kfwx3Ko_B+BKKEzMRBLTVBosvFpdyv2ZuVh1XNA@mail.gmail.com>
In-Reply-To: <CAM4esxR_2x-kfwx3Ko_B+BKKEzMRBLTVBosvFpdyv2ZuVh1XNA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com;
x-originating-ip: [86.139.211.47]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5decd967-5d08-455d-737c-08d80eb5aa80
x-ms-traffictypediagnostic: DB7PR07MB4537:
x-microsoft-antispam-prvs: <DB7PR07MB453789F7EF0D00619DD0F490A2810@DB7PR07MB4537.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0432A04947
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ICQqosQiS4QTrDCp2aCd12VbDbXgY6QTokyzP1PBjzCgFkfrOC0TmmTJ42BL+4OQ9WDqVtqw4TDD2Go7iXd+nRCuGHjMryzZbjqhtX5QaQV4Ng6oAnhE3FV+HSsa8Lah+WQRf0yXB1PDi8mgE4IfvG77xRSFO2wBwBRFcw+nIwub61xeK6BSP2MT9tX4u6w7nAynQELORCyGp3qa1nqUN88ie4LEx9d97OWN+CQjz3ckXhHxI1R1ASsS2vP30bfuj51u+DrSK1+JCcJUbg5i7NcpaxeJ1bb5P3ruv8Kg7QxzuD4e/TdT3upiHUGWENj3VlyiX9b2W8GVVS22lYlVTaRZKS0GyJ5xQ0/B6rkZQw9p6WciGmQLhmVOehwr73467gE4GGxS+nHwXQGx52Qmsg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5340.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(39860400002)(376002)(366004)(396003)(346002)(136003)(8676002)(6916009)(66476007)(66556008)(66446008)(86362001)(64756008)(71200400001)(26005)(55016002)(966005)(83380400001)(53546011)(478600001)(66574014)(91956017)(4326008)(8936002)(6506007)(76116006)(186003)(66946007)(33656002)(2906002)(52536014)(5660300002)(316002)(54906003)(9686003)(7696005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: OExnP2+1HfiQAtvjJpnwjz0xUyvqmwI5zTeSHIP7M969r1SBD90T6DjFJ1ksB+sTCrpGGXJEfwmmeYpsXdsLKr+I4HSaLhwf/TB1kY8ma4P9te7dG8u1G1XfsH5W8J3doZDYFdOqZajT8p0lHQKT1MtGXATJFADPABS1rS2pFKYYIGBD/fjb4hNY7naewVpfEfMAsh+oR74OHAeMzOcOspeqopF9Gu3bjA07YJQaRs5ut/TbjCe8kqiqmJFnFlU7NpqbozIAiVmLbKSjZSQv2DG6rpbVn8k9DLJOcFAnZrK3d7wKcW4vWZRe7ueYrG+1ZZYewGJePn1UHpcXDnwGbUlZsGU9sQnH6pvO4Qd1yL5aJQp3xer7K9Sefj/z19BX0HMuK5+bFkvcMpARddb/F+d6vy6pYwKWaOf0ZxX7AcSnLkr4sVsSh3VWc4v0yFYDi7FP7PTXRGqM+SMX3qQyVVLTnhB9dddu9FXa2SkO2/o=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5decd967-5d08-455d-737c-08d80eb5aa80
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 09:47:48.2789 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: U9RC5T7ihYp+nJwtuD64LPjozVnvOBjO3e8JHteTDobUvndzs/4GViBdLD+xGostI+AfX7gWW8iQ7vjZUUUGmg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4537
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/jZV420RB7RiuqQDhaqji9uY96tQ>
Subject: Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcpm-rto-consider-14.txt> (Requirements for Time-Based Loss Detection) to Best Current Practice
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2020 09:47:57 -0000
From: Martin Duke <martin.h.duke@gmail.com> Sent: 11 June 2020 21:43 Tom, does draft-15 address your concerns? <tp> Martin yes it does. The new first paragraph makes a world of difference to me. I omitted to mention some editorial issues before. Terminology the boiler plate is out of date s,2 This document is different from from ... Requirements would be easier to refer to if they were R1, R2a or some such a reference for DNS recursive resolver would be good EWMA needs expanding on first use Tom Petch https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tcpm-rto-consider-15.txt On Mon, Jun 8, 2020 at 1:28 AM tom petch <ietfa@btconnect.com<mailto:ietfa@btconnect.com>> wrote: From: tcpm <tcpm-bounces@ietf.org<mailto:tcpm-bounces@ietf.org>> on behalf of Mark Allman <mallman@icir.org<mailto:mallman@icir.org>> Sent: 05 June 2020 17:16 > Mark, that is what I am questioning, well ... > that by default loss implies congestion. Historically true for > the IETF but I think that there are a growing number of cases > where it is not true as in a post I saw on another WG list this > week where a document was saying that loss MUST NOT be taken as an > indication of congestion so the MUST in this I-D I find too > strong. OK. So, I am not sure what to do here. I will say several things ... <tp> Mark, what I would like to see is a statement up front, Introduction or just after, along the lines that the document (mostly?) assumes that loss is due to congestion which has historically been the case in the Internet and is likely still largely the case in the Internet and the recommendations here are designed to reduce that congestion . but that there will be networks where loss is not due to congestion in which case the recommendations here MAY adversely affect the performance of the network. I would not give an example but if one is needed, then it would be loss caused by a burst of interference where backing off simply slows down the rate unnecessarily. Tom Petch (1) I believe that as a general, default the document is quite right in specifying a congestion response and exponential backoff. (2) I believe consensus of the WGs has been the same as my notion in (1) for some time now. So, even setting aside (1), I am not sure I feel like I have carte blanche to change this. (3) I do not believe loss always means congestion and I do not believe assuming such is always correct or should always be done. I don't think I know anyone who thinks that. So, the document explicitly says that is fine, just go get consensus that some other approach is fine. (And, that should be happening regardless of this document, so I am not sure what the big deal is here.) So, basically, I am not sure what to do here. Maybe one of the ADs can help. Or, maybe we can set this aside and I can do the things I told you I'd do and a little extra framing will make this better. I am all ears for advice here. (BTW, I have a half response to Stewart, as well. I am not ignoring his review. I am just behind.) allman _______________________________________________ tcpm mailing list tcpm@ietf.org<mailto:tcpm@ietf.org> https://www.ietf.org/mailman/listinfo/tcpm
- [tcpm] Last Call: <draft-ietf-tcpm-rto-consider-1… The IESG
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] Last Call: <draft-ietf-tcpm-rto-consid… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Benjamin Kaduk
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Stewart Bryant
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Martin Duke
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… tom petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… t petch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Carsten Bormann
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Mark Allman
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Joseph Touch
- Re: [tcpm] [Last-Call] Last Call: <draft-ietf-tcp… Wesley Eddy