From nobody Thu Jul 2 00:15:24 2020 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 C9DA33A0DA2; Thu, 2 Jul 2020 00:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S3LEMB8XcTi; Thu, 2 Jul 2020 00:15:21 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0B33A0844; Thu, 2 Jul 2020 00:15:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 46E4225A28; Thu, 2 Jul 2020 09:15:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1593674119; bh=0QwM1ciEdNssScNgwYvGtJlnF5HrUEbKvdVIITJxIeM=; h=From:To:CC:Subject:Date:From; b=VkeK7juAZDZP3Xim8uXyXJG899Q9a3ZPfnoLZHwb1kDCilw2n0PtjB2Tc47SNDUIx Zw5kz3I1M38QUjFatgYWz3BSZRi/AkwdbXAfF0nlniExtGayTGBaKhqDWrd7+qLmdu 6ovOlern4uYvl+ptIzKkuLo02fZqiWp+W7CGZWTs= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-vtIwFslfbs; Thu, 2 Jul 2020 09:15:18 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 2 Jul 2020 09:15:18 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Thu, 2 Jul 2020 09:15:17 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: tcpm-chairs Thread-Topic: Presentation slot requests for IETF 108 (online) Thread-Index: AdZQQCmoc741dfI0S+mziKOl37MyoQ== Date: Thu, 2 Jul 2020 07:15:17 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Presentation slot requests for IETF 108 (online) 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, 02 Jul 2020 07:15:23 -0000 Hi all, Given that we had a pretty packed agenda during the virtual interim meeting= , the chairs have asked for two slots during IETF 108. This basically impli= es that we have again the 2:30 hour slot that TCPM used to have for many ye= ars. According to the draft agenda for IETF 108, TCPM has been scheduled for Mon= day Session I (1:40) and Monday Session II (0:50). If you are interested in presenting, please let the chairs know until **Mon= day 2020-07-13**: * Draft name / presentation title * Presenter * Total duration (including Q&A) Thanks Michael (2x) and Yoshi From nobody Thu Jul 2 00:54:40 2020 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 24C483A0DEE; Thu, 2 Jul 2020 00:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTzCQ49ZNzd6; Thu, 2 Jul 2020 00:54:36 -0700 (PDT) Received: from mailout41.telekom.de (mailout41.telekom.de [194.25.225.151]) (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 AE50D3A0DE5; Thu, 2 Jul 2020 00:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1593676475; x=1625212475; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=jp2q9Rdju6XlKK9ZLKHryG3QYoap9DUVETy6GH65HrU=; b=CAQGrXyEHzFgXNsQOLkKXFAA6JPaIvlYKGAy1SAD2mbQW3Eae5WHhUud aTPQJ+ZtQFLwJjPiNC97Y+Y0OVZNWvOCf12vDM5NamilG9br9wtR7uwNW jNcfSKyH3RuxhjdPOh9Ldqbx6LcANWWqokH0+rqrNk934hp6VtcRq/cJo Pdd9sFH5kLjF0HoY9kWwI/oXlVwmnK4k8iRykC+hWEgZwUr0oyDP+wAg5 wsG90v7ZLNYW+DU4uyVvWRdF3YXYcZnEoR21sVEarBXu110mmtF1fMjio s3uX+S8tVAyIbcqkEFRX038uSEUe8Su//9XAmcO4KAFDk0mroTwDgJ/mM Q==; IronPort-SDR: NqsE7oD5ZpVg1AWfLXE1KyTw+Yafynl6hUdI70iJgDHVOYBjW+eLNnSbB6mG3m3Yn1SwXT+iIz sDE7iqx0ZVuw== Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT41.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2020 09:54:33 +0200 IronPort-SDR: uVsVmwSMf7H8PxOKtjF/qPDtAfg2qGdajkTSfKvuNT8fwQXSYLtbXspY/3DqrvXdTzUhzKCwBN VgZPZvJ+lBNXV0ZzdZEhPuXm12K3Y63UA= X-IronPort-AV: E=Sophos;i="5.75,303,1589234400"; d="scan'208";a="818997785" X-MGA-submission: =?us-ascii?q?MDFfDHg7mReV9DIsSkEGfhf2Q+MltF8YHbGwmd?= =?us-ascii?q?B3tZawPiddKO3yfG2eqKwAlA0H0joQ2JQsbIguE9Tn+j4zAooufRcoZX?= =?us-ascii?q?+6SVXOkQjKPWwfeh2ZFt0CpRSLH+H6utDRkeRH9Pjajf4QDJZilT4122?= =?us-ascii?q?q/r3kBDRp1rheO2bNgyOmKwg=3D=3D?= Received: from he105865.emea1.cds.t-internal.com ([10.169.119.42]) by QDE8PP.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 02 Jul 2020 09:54:33 +0200 Received: from HE199745.EMEA1.cds.t-internal.com (10.169.119.53) by HE105865.emea1.cds.t-internal.com (10.169.119.42) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Jul 2020 09:54:32 +0200 Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199745.EMEA1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 2 Jul 2020 09:54:32 +0200 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 2 Jul 2020 09:54:34 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kv/nHP+fsnKN44gfkyD29E+Kju8DBb4lFdpbwm5168Kk3ewQLDZ6/oi4tjOWJ9pzsqr8buZfpmIBcfEvAWzBiw/hk96ouEaDoxABJ9ZBpyBh9d0eepAd5O7WQ26dTnWRXa6QFk7Ph1Wg3kDNVOxI3iP2Eu5X0DgWCn4jARdErxopmx2gXAg2RGgF0vuNwH2FMZjFspaJ8r1KvGhsZXH+qLeRgnnE1FQQqH90gxOCSBHja5TrynablD9oDF50AZkkGk4IVcgaYRYGBHIHz2DdInodRMT8QSeV8ShVB8jcKsGtlSkpPSSi0mh7azTLqyXNwLoqLcU3j464IXLw2fyeOA== 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=jp2q9Rdju6XlKK9ZLKHryG3QYoap9DUVETy6GH65HrU=; b=aWkvVpbcnMQFiXyDbv44A3AEMFer5s9D6oUvtANtCnsCsUZ+xbvIRz4NMMH1PtYWR/mEhGg5AxZTotHw89AjzhSytqiJuShyMqRNn9pSh7GLKkRf/x55Xu6yWUNoRMSJgk0NQd2Jr2VPAO9d8t7UkErvSLd4U//+faYhEjECOQuB5oC9PBJ67MsdEqs034Ees2FXk3CW5itu9EjvDKd+3+jWMtCyZ7ali5ld5VVTB3D6NtdHSKb2cEH3egtWbPJ1unOMmLKRchBDZBbZogYXl5yucejTtc4sqDk7oUCnRKq8Pe8LCPvfToF/ci5F9yVTLL6eYIwwIfEz6uV61lDwLg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c012:a::11) by LEJPR01MB0571.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c012:8::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Thu, 2 Jul 2020 07:54:31 +0000 Received: from LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d595:7a33:8cac:79b0]) by LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d595:7a33:8cac:79b0%2]) with mapi id 15.20.3131.034; Thu, 2 Jul 2020 07:54:31 +0000 From: To: , CC: , Thread-Topic: Presentation slot requests for IETF 108 (online) Thread-Index: AdZQQCmoc741dfI0S+mziKOl37MyoQABBo5A Date: Thu, 2 Jul 2020 07:54:31 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hs-esslingen.de; dkim=none (message not signed) header.d=none; hs-esslingen.de; dmarc=none action=none header.from=telekom.de; x-originating-ip: [212.201.104.11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b8e0dbe4-8938-454d-6783-08d81e5d279c x-ms-traffictypediagnostic: LEJPR01MB0571: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0452022BE1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2S3723X2BenvJeaYL0rsKgIMicvRK6UvdWVzRAcIDujjWgQvwQ1Z3WYHa9podm2IiDvpqUjdjzO0PS8SS+BYNhO14Po4D8YHlB9XWTaWi3BGZOzSbqrEALhJLoGBCgUoe8F6qVZQBB8b3PScWsU4T+ztpgEwrVB5oZZBGMgtePFpuAi3YeRYm7TnYtfYYVJ7x0e5bEN9L8zds7eUy/pwbRzL44Cd75luGN0U6IDhg+stZIyCjIplrlPqdjjr4rhwS8jVPd78Ec//q+5qsaNGDjD04uMDO1Lj3bUai2rVB+NHoVnsYrjx41Vcsl4QcLBSA20AR+vx/NJT7qo2TFhp6nrF3U7rZVWXnW1v75ZecT0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE; PTR:; CAT:NONE; SFTY:; SFS:(376002)(396003)(346002)(366004)(39860400002)(136003)(66476007)(66946007)(66556008)(64756008)(66446008)(26005)(110136005)(54906003)(2906002)(55016002)(478600001)(8676002)(4326008)(53546011)(966005)(9686003)(76116006)(86362001)(71200400001)(33656002)(7696005)(83380400001)(8936002)(5660300002)(316002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: yENYfqE7O9grb2XFFteEMBaK0tC97nFH51PebQRxS1wID1BcEhFuxYsD0h88ulRKD9ALxt5SlN7FxOzS9B3dyv6wQ8sBqJZXPleqe9/eN2G/CAVhm7Tslm0Hreb1zOTrKKBUfcKNTp4Llr5gJkLChJqyXdbV3/rrxo+84Mp+mWS0QyiIVR4h6YGequB7fPNowFCrSUkSYHx5S430QPzpr76ci7iwHjXEhKKynj/L0hvD9CfW+/qyn6fepyTK4omlYi28FOZVYlAxVrLFCIORRtaqrTPdsE/U1hZhwHXjZNETD/v2C1qDKJZqn/VsXp2xof4/+hzfAHDnHC5kfWFMfKNqu5/uol74Q0wH3zGSmdv5EdXecXbNgjhWlXvt4/KQSiyrdzW9LetFjX6N2qBjNA4owzFRF4r75BJiLK9MKwVreyR9JZD9/xUQariD0QsZ/YmEw/0eqADD5klokaTzK1tCIsyAVywONddVBx5EsM1Yv6IvRjgAiZCrXtj3FG3H x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE X-MS-Exchange-CrossTenant-Network-Message-Id: b8e0dbe4-8938-454d-6783-08d81e5d279c X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2020 07:54:31.7818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: m94aN9AH7Mgv65G5JgZJwatmkU3KP4MLX9ZbjfmQ226m+c5chiJu+n/fKhdEgavvssoqCvqJmGlPf3nmoRDoJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0571 X-TM-SNTS-SMTP: F372C3580A0CE8FD721771261DD1C356FAC201A97578DF447A536E0A9A3A90DC2000:8 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) 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, 02 Jul 2020 07:54:38 -0000 Dear Michaels, Yoshi Since MPTCP WG is closed and TCPM takes care, Jiao and I would like to pres= ent implementation updates (probably also a new draft version -02) for * draft-amend-mptcp-robe / "Multipath TCP Robust Session Establishment" * Jiao Kang / Markus Amend * 20min Just in case we are not able to update the recent -01 to a -02, is it still= required to move the -01 to TCPM before #108? Br Markus -----Original Message----- From: tcpm On Behalf Of Scharf, Michael Sent: Donnerstag, 2. Juli 2020 09:15 To: tcpm@ietf.org Cc: tcpm-chairs Subject: [tcpm] Presentation slot requests for IETF 108 (online) Hi all, Given that we had a pretty packed agenda during the virtual interim meeting= , the chairs have asked for two slots during IETF 108. This basically impli= es that we have again the 2:30 hour slot that TCPM used to have for many ye= ars. According to the draft agenda for IETF 108, TCPM has been scheduled for Mon= day Session I (1:40) and Monday Session II (0:50). If you are interested in presenting, please let the chairs know until **Mon= day 2020-07-13**: * Draft name / presentation title * Presenter * Total duration (including Q&A) Thanks Michael (2x) and Yoshi _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jul 2 07:33:53 2020 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 802963A0936; Thu, 2 Jul 2020 07:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCHWiKoHKQmK; Thu, 2 Jul 2020 07:33:49 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5CE33A0924; Thu, 2 Jul 2020 07:33:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id EE9A225A1C; Thu, 2 Jul 2020 16:33:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1593700427; bh=SXVzlmVo9Q11OH02y20trbv0HhNfiiSelyjfU1JdNjc=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=qppVNCIkMiXI07C6sxbzwP9Zcpja/opcEz5lImVS3rqFUOb+GkpN4w99n99itfA/Z 5k2++nwUGHYaECI1S3CHcMDwVMvvRanXyMvzWKgf/ceyZDhTdx15oy9uhO8fzVcrjR CIoeihgVfjT5HgeVfcONwuzwHS01XbmrZUYaU1IE= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwwAM7s2JB11; Thu, 2 Jul 2020 16:33:45 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 2 Jul 2020 16:33:45 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Thu, 2 Jul 2020 16:33:45 +0200 From: "Scharf, Michael" To: "Markus.Amend@telekom.de" , "tcpm@ietf.org" CC: "tcpm-chairs@ietf.org" , "kangjiao@huawei.com" Thread-Topic: Presentation slot requests for IETF 108 (online) Thread-Index: AdZQQCmoc741dfI0S+mziKOl37MyoQABBo5AAA4+aKA= Date: Thu, 2 Jul 2020 14:33:44 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC85322@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) 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, 02 Jul 2020 14:33:52 -0000 Markus, Thanks for the request. It may make sense to resubmit the I-D as -tcpm- if it shall be presented in= TCPM. Then it shows up in datatracker in the right context. Michael > -----Original Message----- > From: Markus.Amend@telekom.de > Sent: Thursday, July 2, 2020 9:55 AM > To: Scharf, Michael ; tcpm@ietf.org > Cc: tcpm-chairs@ietf.org; kangjiao@huawei.com > Subject: RE: Presentation slot requests for IETF 108 (online) >=20 > Dear Michaels, Yoshi >=20 > Since MPTCP WG is closed and TCPM takes care, Jiao and I would like to > present implementation updates (probably also a new draft version -02) fo= r >=20 > * draft-amend-mptcp-robe / "Multipath TCP Robust Session Establishment" > * Jiao Kang / Markus Amend > * 20min >=20 > Just in case we are not able to update the recent -01 to a -02, is it sti= ll > required to move the -01 to TCPM before #108? >=20 > Br >=20 > Markus >=20 > -----Original Message----- > From: tcpm On Behalf Of Scharf, Michael > Sent: Donnerstag, 2. Juli 2020 09:15 > To: tcpm@ietf.org > Cc: tcpm-chairs > Subject: [tcpm] Presentation slot requests for IETF 108 (online) >=20 > Hi all, >=20 > Given that we had a pretty packed agenda during the virtual interim meeti= ng, > the chairs have asked for two slots during IETF 108. This basically impli= es that > we have again the 2:30 hour slot that TCPM used to have for many years. >=20 > According to the draft agenda for IETF 108, TCPM has been scheduled for > Monday Session I (1:40) and Monday Session II (0:50). >=20 > If you are interested in presenting, please let the chairs know until > **Monday 2020-07-13**: >=20 > * Draft name / presentation title > * Presenter > * Total duration (including Q&A) >=20 > Thanks >=20 > Michael (2x) and Yoshi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Thu Jul 2 11:21:05 2020 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 789723A0C6F; Thu, 2 Jul 2020 11:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 n54Qkxvw7xiK; Thu, 2 Jul 2020 11:20:59 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918A03A0C55; Thu, 2 Jul 2020 11:20:39 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 062IKXdJ062066; Thu, 2 Jul 2020 11:20:33 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net) Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 062IKW9I062065; Thu, 2 Jul 2020 11:20:32 -0700 (PDT) (envelope-from ietf) From: "Rodney W. Grimes" Message-Id: <202007021820.062IKW9I062065@gndrsh.dnsmgr.net> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DC85322@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" Date: Thu, 2 Jul 2020 11:20:32 -0700 (PDT) CC: "Markus.Amend@telekom.de" , "tcpm@ietf.org" , "tcpm-chairs@ietf.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) 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, 02 Jul 2020 18:21:03 -0000 Michael, Shouldnt the datatracker entry in its entierity be moved to tcpm since tcpm is now taking on the work of the closed mptcp wg? That way history of the document is preserved and can be easier to research. I am not sure this is even possible, but loosing the provadence of a document because it moved WG's seems problematic. Regards, Rod > Markus, > > Thanks for the request. > > It may make sense to resubmit the I-D as -tcpm- if it shall be presented in TCPM. Then it shows up in datatracker in the right context. > > Michael > > > -----Original Message----- > > From: Markus.Amend@telekom.de > > Sent: Thursday, July 2, 2020 9:55 AM > > To: Scharf, Michael ; tcpm@ietf.org > > Cc: tcpm-chairs@ietf.org; kangjiao@huawei.com > > Subject: RE: Presentation slot requests for IETF 108 (online) > > > > Dear Michaels, Yoshi > > > > Since MPTCP WG is closed and TCPM takes care, Jiao and I would like to > > present implementation updates (probably also a new draft version -02) for > > > > * draft-amend-mptcp-robe / "Multipath TCP Robust Session Establishment" > > * Jiao Kang / Markus Amend > > * 20min > > > > Just in case we are not able to update the recent -01 to a -02, is it still > > required to move the -01 to TCPM before #108? > > > > Br > > > > Markus > > > > -----Original Message----- > > From: tcpm On Behalf Of Scharf, Michael > > Sent: Donnerstag, 2. Juli 2020 09:15 > > To: tcpm@ietf.org > > Cc: tcpm-chairs > > Subject: [tcpm] Presentation slot requests for IETF 108 (online) > > > > Hi all, > > > > Given that we had a pretty packed agenda during the virtual interim meeting, > > the chairs have asked for two slots during IETF 108. This basically implies that > > we have again the 2:30 hour slot that TCPM used to have for many years. > > > > According to the draft agenda for IETF 108, TCPM has been scheduled for > > Monday Session I (1:40) and Monday Session II (0:50). > > > > If you are interested in presenting, please let the chairs know until > > **Monday 2020-07-13**: > > > > * Draft name / presentation title > > * Presenter > > * Total duration (including Q&A) > > > > Thanks > > > > Michael (2x) and Yoshi > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > -- Rod Grimes rgrimes@freebsd.org From nobody Thu Jul 2 12:25:38 2020 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 60C823A0774; Thu, 2 Jul 2020 12:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYsv3c6zouWs; Thu, 2 Jul 2020 12:25:34 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3F93A0486; Thu, 2 Jul 2020 12:25:34 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id k4so24599393oik.2; Thu, 02 Jul 2020 12:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9y3J5+rcNvUQSJ2xnPKH2fZM9auNIv6Ezxlkx9y/Qxo=; b=l7KD9UA+M1+jHHmFZupwEbTNGSdGsuBYQz/6SGW7HTL8k2PCJxO5rYvCo8a99gA/tj EE7NTmB/h09kMpE+purQF3P+4ZigOGSzdCYfMwKEcXdbUzMyuBALCGvu0COPPtoxEE3i fVo7TBma5MhI+e/7OE6rCrUvpIeO73gtCVYOWkmbgwsInwi1r7UMeGeLeyf2451osJxp phauuh09ohFYGRl5N5GDlaRzJsl79TvGvS7C84XR18xMPDE5llM+u7W+sq4rv2cz0X1M 7g1R3W7eI50ePfJzsLHSiQJawqZmvlq3ORR9lPtuiTa+Ks5qfa7/mWDpdiWKqG6HR6NU 3c3Q== 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=9y3J5+rcNvUQSJ2xnPKH2fZM9auNIv6Ezxlkx9y/Qxo=; b=WlotI1gr8aOLfLxGpdQmbvHkJgrZtiiasv9hYZGfXbXD4JDlkCSPBQZr8sqa4crK9/ txxmimakV1Hp6die9kqVsuiMwZ5lWU1cwdFnppJ6WJyB+c72LgPbOFZO8apBSs+LCJGQ w0DhkjG1lPBhvElX6Vac0XoiNYzWB+9/Ryksa55BVnzENSUEH0oLNsRQ+jbZ01BGV3nz BA8v9cErIXthKy4Ce8JYHHOAyIXqggQaR3euHuxusUHmEljurqKtLvgqkwUUFC5BDHbr suvpny1r/w3ywYhJvYnXoyPYR49yjGUkPOkRw0Ht0n05H28YS8TEzqK6H60c+LSkd429 7cLw== X-Gm-Message-State: AOAM5322u13QjCVuowvYcRSeO0fmD321CeziyZKAtGqQEoP8WurnVAte VrqN8m6oxX0l4DNoGH3UfYOLnckYyJTUVRVnYbM= X-Google-Smtp-Source: ABdhPJyWe/de+KE3VnLnvdCWZ6IUJ9BZ2SZU2N/g/3Wv0wBMCBdu8MgyHsaY/hbb+zkSw3KI3hwo4fAFTFq2hBUs9MU= X-Received: by 2002:a05:6808:2:: with SMTP id u2mr18891648oic.173.1593717933569; Thu, 02 Jul 2020 12:25:33 -0700 (PDT) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2DC85322@rznt8114.rznt.rzdir.fht-esslingen.de> <202007021820.062IKW9I062065@gndrsh.dnsmgr.net> In-Reply-To: <202007021820.062IKW9I062065@gndrsh.dnsmgr.net> From: Tim Wicinski Date: Thu, 2 Jul 2020 15:25:22 -0400 Message-ID: To: "Rodney W. Grimes" Cc: "Scharf, Michael" , "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004d797c05a97a5f00" Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) 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, 02 Jul 2020 19:25:36 -0000 --0000000000004d797c05a97a5f00 Content-Type: text/plain; charset="UTF-8" Rodney When the newer document is uploaded with the -tcpm- name, one can use the "Replaces" button in the Datatracker to create the breadcrumbs. For a current example in DNSOP, see: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ tim On Thu, Jul 2, 2020 at 2:21 PM Rodney W. Grimes wrote: > Michael, > Shouldnt the datatracker entry in its entierity be moved > to tcpm since tcpm is now taking on the work of the closed mptcp wg? > That way history of the document is preserved and can be easier > to research. > > I am not sure this is even possible, but loosing the > provadence of a document because it moved WG's seems problematic. > > Regards, > Rod > > > Markus, > > > > Thanks for the request. > > > > It may make sense to resubmit the I-D as -tcpm- if it shall be presented > in TCPM. Then it shows up in datatracker in the right context. > > > > Michael > > > > > -----Original Message----- > > > From: Markus.Amend@telekom.de > > > Sent: Thursday, July 2, 2020 9:55 AM > > > To: Scharf, Michael ; tcpm@ietf.org > > > Cc: tcpm-chairs@ietf.org; kangjiao@huawei.com > > > Subject: RE: Presentation slot requests for IETF 108 (online) > > > > > > Dear Michaels, Yoshi > > > > > > Since MPTCP WG is closed and TCPM takes care, Jiao and I would like to > > > present implementation updates (probably also a new draft version -02) > for > > > > > > * draft-amend-mptcp-robe / "Multipath TCP Robust Session Establishment" > > > * Jiao Kang / Markus Amend > > > * 20min > > > > > > Just in case we are not able to update the recent -01 to a -02, is it > still > > > required to move the -01 to TCPM before #108? > > > > > > Br > > > > > > Markus > > > > > > -----Original Message----- > > > From: tcpm On Behalf Of Scharf, Michael > > > Sent: Donnerstag, 2. Juli 2020 09:15 > > > To: tcpm@ietf.org > > > Cc: tcpm-chairs > > > Subject: [tcpm] Presentation slot requests for IETF 108 (online) > > > > > > Hi all, > > > > > > Given that we had a pretty packed agenda during the virtual interim > meeting, > > > the chairs have asked for two slots during IETF 108. This basically > implies that > > > we have again the 2:30 hour slot that TCPM used to have for many years. > > > > > > According to the draft agenda for IETF 108, TCPM has been scheduled for > > > Monday Session I (1:40) and Monday Session II (0:50). > > > > > > If you are interested in presenting, please let the chairs know until > > > **Monday 2020-07-13**: > > > > > > * Draft name / presentation title > > > * Presenter > > > * Total duration (including Q&A) > > > > > > Thanks > > > > > > Michael (2x) and Yoshi > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > Rod Grimes > rgrimes@freebsd.org > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --0000000000004d797c05a97a5f00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rodney

Whe= n the newer document is uploaded with the -tcpm- name, one can use the
"Replace= s" button in the Datatracker to create the breadcrumbs.

For a current example in DN= SOP, see:=C2=A0

https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

tim



On Thu, Jul 2,= 2020 at 2:21 PM Rodney W. Grimes <ietf@gndrsh.dnsmgr.net> wrote:
Michael,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Shouldnt the datatracker entry in its entierity= be moved
to tcpm since tcpm is now taking on the work of the closed mptcp wg?
That way history of the document is preserved and can be easier
to research.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I am not sure this is even possible, but loosin= g the
provadence of a document because it moved WG's seems problematic.

Regards,
Rod

> Markus,
>
> Thanks for the request.
>
> It may make sense to resubmit the I-D as -tcpm- if it shall be present= ed in TCPM. Then it shows up in datatracker in the right context.
>
> Michael
>
> > -----Original Message-----
> > From: Markus.Amend@telekom.de <Markus.Amend@telekom.de>
> > Sent: Thursday, July 2, 2020 9:55 AM
> > To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; tcpm@ietf.org
> > Cc: tcp= m-chairs@ietf.org; kangjiao@huawei.com
> > Subject: RE: Presentation slot requests for IETF 108 (online)
> >
> > Dear Michaels, Yoshi
> >
> > Since MPTCP WG is closed and TCPM takes care, Jiao and I would li= ke to
> > present implementation updates (probably also a new draft version= -02) for
> >
> > * draft-amend-mptcp-robe / "Multipath TCP Robust Session Est= ablishment"
> > * Jiao Kang / Markus Amend
> > * 20min
> >
> > Just in case we are not able to update the recent -01 to a -02, i= s it still
> > required to move the -01 to TCPM before #108?
> >
> > Br
> >
> > Markus
> >
> > -----Original Message-----
> > From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Scharf, Michael
> > Sent: Donnerstag, 2. Juli 2020 09:15
> > To: tcpm@ietf.= org
> > Cc: tcpm-chairs <tcpm-chairs@ietf.org>
> > Subject: [tcpm] Presentation slot requests for IETF 108 (online)<= br> > >
> > Hi all,
> >
> > Given that we had a pretty packed agenda during the virtual inter= im meeting,
> > the chairs have asked for two slots during IETF 108. This basical= ly implies that
> > we have again the 2:30 hour slot that TCPM used to have for many = years.
> >
> > According to the draft agenda for IETF 108, TCPM has been schedul= ed for
> > Monday Session I (1:40) and Monday Session II (0:50).
> >
> > If you are interested in presenting, please let the chairs know u= ntil
> > **Monday 2020-07-13**:
> >
> > * Draft name / presentation title
> > * Presenter
> > * Total duration (including Q&A)
> >
> > Thanks
> >
> > Michael (2x) and Yoshi
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/tcpm >
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm
>

--
Rod Grimes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rgrimes@freebsd.org

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--0000000000004d797c05a97a5f00-- From nobody Thu Jul 2 17:21:03 2020 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 D3C993A0942; Thu, 2 Jul 2020 17:20:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tcpm@ietf.org, martin.h.duke@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373562884.30173.18160492892753879725@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:28 -0700 Archived-At: Subject: [tcpm] tcpm - Requested sessions have been scheduled for IETF 108 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: Fri, 03 Jul 2020 00:20:29 -0000 Dear Michael Scharf, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tcpm Session 1 (1:40 requested) Monday, 27 July 2020, Session I 1100-1240 Room Name: Room 8 size: 8 --------------------------------------------- tcpm Session 2 (0:50 requested) Monday, 27 July 2020, Session II 1300-1350 Room Name: Room 8 size: 8 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/tcpm.ics Request Information: --------------------------------------------------------- Working Group Name: TCP Maintenance and Minor Extensions Area Name: Transport Area Session Requester: Michael Scharf Number of Sessions: 2 Length of Session(s): 100 Minutes, 50 Minutes Number of Attendees: 60 Conflicts to Avoid: Technology Overlap: tsvwg quic taps tsvarea iccrg panrg webtrans masque People who must be present: Yoshifumi Nishida Michael Tuexen Martin Duke Michael Scharf Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jul 2 23:22:48 2020 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 DC40A3A0D44 for ; Thu, 2 Jul 2020 23:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=eggert.org 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 vevSonLWu5KO for ; Thu, 2 Jul 2020 23:22:46 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 80DA03A0D43 for ; Thu, 2 Jul 2020 23:22:46 -0700 (PDT) Received: from [IPv6:2a00:ac00:0:35:d4c1:627c:7b6f:56d8] (unknown [IPv6:2a00:ac00:0:35:d4c1:627c:7b6f:56d8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 766986158CD for ; Fri, 3 Jul 2020 09:22:14 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1593757334; bh=e9BL3msbu06bzzVEgvfQRjiMQnEDxVnf/WjbJt9FQXk=; h=From:Subject:References:To:Date; b=wAVJL2Y8u3Ds2/gGMauMeMBkaarND8XSUVkju3cctFXVHPI+kmD1cUfmdQsN4sZxL ylQxNOxKtOZWpTJxsGI8TTSP3Rpkh5RzRQbAADk7/hRgHdFsUCO0BuyK9b/aGoADNg ahfFgz6/XWPnHECh3lrwF8ciqhrkNgV4H4ZzFsU0= From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_24532B70-FADB-4F94-B015-C2780A86B71B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: <457575FB-AFA4-49AD-AAFC-E2A774E24918@eggert.org> References: <9708D1EE-9E08-4C4C-B507-89E09B83191B@eggert.org> To: tcpm IETF list Date: Fri, 3 Jul 2020 09:22:13 +0300 X-MailScanner-ID: 766986158CD.A2440 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: [tcpm] Fwd: [Pearg] Geneva: Evolving Censorship Evasion X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 06:22:48 -0000 --Apple-Mail=_24532B70-FADB-4F94-B015-C2780A86B71B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi There are some pretty neat TCP tricks in this presentation, hence maybe = of interest to some on this list. Lars > Dave Levin just shared this presentation on the SIGCOMM slack. I = thought it might be interesting for this group: = https://youtu.be/ksojSRFLbBM >=20 >> Dave Levin 7:58 PM >> @here In case anyone is interested in seeing a talk about censorship = evasion, Kevin Bock from UMD will be presenting our work on Geneva, a = genetic algorithm that automatically discovers how to circumvent = nation-state censorship. Livestreaming starting in just a minute at = https://www.youtube.com/watch?v=3DksojSRFLbBM >> This is part of the Internet Measurement Village run by the great = folks at OONI. They=E2=80=99ve been extremely supportive in fostering a = community of researchers and activists to investigate and combat = censorship around the world. If you=E2=80=99re at all interested in = getting into that space, joining the OONI slack is a great first step. >=20 > Lars --Apple-Mail=_24532B70-FADB-4F94-B015-C2780A86B71B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAl7+zpUACgkQVLXDCb9w wVcTCg//Z9Zv2qC/1qqaFAgGArJxXVUVVfv9VOejjnfMnFtFDNo7UrAB4ocnZvDa PYXHI/888nMFLMV3z1xnBhLZN3t+732pP+PD+vZb+hY5HH6osTDkvFaTsGs4qhbB k8Moq7TZc4J+aFiPXsY0QQtI3ek1QJ50dEGjxhkDQedNUu7740pjc8Wfbhveo8XE PR3ZayzHIKseWQT/PWLblQpoJgg7zupz4uvErUy12ShhYrRpT6NS/CgtZb16gr7M iCPqBsEGg0qyNQ6SYHQp28ppmbEWXKveOJKYgXywRrqoa4wn0hWh64J+ECqGefDv 93ovvAYsWMYNZr1P+PMYXSWw4gKoRKWqBfBI5poAgH8vJRcN1HwHV5jDZCjzAd71 YfQv9FqJr8dxBXlGcrELdkDfmvWKzrwCURmfNnkicie5rEQF/WVeUhlIJARG8DD3 YXl2+MQ9QWejDwALEtOxLv5jHOUEdyxz+kHJvXBpskKZZgN/+CuyFf680nhBc1TJ cUEQWM87RXFFct1sTxqaxu68Nj+4Oet9ofHT1ELkdelD8rkYY8wZMo8d5ZdkvTDD xINA3k94gcu4m3CLJi84ZgF1sEbvt7Pi32sp8I0tLi+bVXNCWV2qIJTfeYk5krXY C3lPB+Y5e+7wwGKMZliCCj8Q7qZl1VDJnBp/maq9S1B8JnAZQlU= =XRJz -----END PGP SIGNATURE----- --Apple-Mail=_24532B70-FADB-4F94-B015-C2780A86B71B-- From nobody Fri Jul 3 00:36:24 2020 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 8E5A63A0DFC; Fri, 3 Jul 2020 00:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXp9mdclODUG; Fri, 3 Jul 2020 00:36:20 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFF63A0DED; Fri, 3 Jul 2020 00:36:19 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id E9BC125A17; Fri, 3 Jul 2020 09:36:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1593761777; bh=gpOZXiNI3CRxepQS3pskiQnXbHsHgr8kdKoJoMOSgns=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=PafYAR+X9Faax1o8GIVByKkVHlNPogHnqcn4fF6k5MSH+TuW0VKVlvxA/bUOVUQCr S290QdJ8lrP2INmop1m3MaDGvIAoEIFxJ/4EK4OomsZtQvDmngV5D86LoUguMgr2/n T53HooexzwigXxZPREcOGnx9sTl9t7dwQqq8/Bas= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cNu8NOGS7uoz; Fri, 3 Jul 2020 09:36:16 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 3 Jul 2020 09:36:16 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Fri, 3 Jul 2020 09:36:16 +0200 From: "Scharf, Michael" To: "Rodney W. Grimes" CC: "Markus.Amend@telekom.de" , "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Thread-Topic: [tcpm] Presentation slot requests for IETF 108 (online) Thread-Index: AdZQQCmoc741dfI0S+mziKOl37MyoQABBo5AAA4+aKAAA93uAAAfcSkg Date: Fri, 3 Jul 2020 07:36:15 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC87826@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2DC85322@rznt8114.rznt.rzdir.fht-esslingen.de> <202007021820.062IKW9I062065@gndrsh.dnsmgr.net> In-Reply-To: <202007021820.062IKW9I062065@gndrsh.dnsmgr.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 07:36:23 -0000 Rod, Tim Wicinski has already mentioned that "update" metadata can be used to ke= ep record of the history. Also, I believe it is quite common in the IETF to rename I-Ds if they move = between WGs. For individual submissions, this is probably not formally requ= ired, though. The advantage of -tcpm- is that it is then more apparent on which list the = discussion shall take place. Not all readers of I-Ds are familiar with all = IETF internals. Michael > -----Original Message----- > From: Rodney W. Grimes > Sent: Thursday, July 2, 2020 8:21 PM > To: Scharf, Michael > Cc: Markus.Amend@telekom.de; tcpm@ietf.org; tcpm-chairs@ietf.org > Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) >=20 > Michael, > Shouldnt the datatracker entry in its entierity be moved > to tcpm since tcpm is now taking on the work of the closed mptcp wg? > That way history of the document is preserved and can be easier > to research. >=20 > I am not sure this is even possible, but loosing the > provadence of a document because it moved WG's seems problematic. >=20 > Regards, > Rod >=20 > > Markus, > > > > Thanks for the request. > > > > It may make sense to resubmit the I-D as -tcpm- if it shall be presente= d in > TCPM. Then it shows up in datatracker in the right context. > > > > Michael > > > > > -----Original Message----- > > > From: Markus.Amend@telekom.de > > > Sent: Thursday, July 2, 2020 9:55 AM > > > To: Scharf, Michael ; tcpm@ietf.org > > > Cc: tcpm-chairs@ietf.org; kangjiao@huawei.com > > > Subject: RE: Presentation slot requests for IETF 108 (online) > > > > > > Dear Michaels, Yoshi > > > > > > Since MPTCP WG is closed and TCPM takes care, Jiao and I would like t= o > > > present implementation updates (probably also a new draft version -02= ) > for > > > > > > * draft-amend-mptcp-robe / "Multipath TCP Robust Session > Establishment" > > > * Jiao Kang / Markus Amend > > > * 20min > > > > > > Just in case we are not able to update the recent -01 to a -02, is it= still > > > required to move the -01 to TCPM before #108? > > > > > > Br > > > > > > Markus > > > > > > -----Original Message----- > > > From: tcpm On Behalf Of Scharf, Michael > > > Sent: Donnerstag, 2. Juli 2020 09:15 > > > To: tcpm@ietf.org > > > Cc: tcpm-chairs > > > Subject: [tcpm] Presentation slot requests for IETF 108 (online) > > > > > > Hi all, > > > > > > Given that we had a pretty packed agenda during the virtual interim > meeting, > > > the chairs have asked for two slots during IETF 108. This basically i= mplies > that > > > we have again the 2:30 hour slot that TCPM used to have for many year= s. > > > > > > According to the draft agenda for IETF 108, TCPM has been scheduled f= or > > > Monday Session I (1:40) and Monday Session II (0:50). > > > > > > If you are interested in presenting, please let the chairs know until > > > **Monday 2020-07-13**: > > > > > > * Draft name / presentation title > > > * Presenter > > > * Total duration (including Q&A) > > > > > > Thanks > > > > > > Michael (2x) and Yoshi > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > >=20 > -- > Rod Grimes rgrimes@freebs= d.org From nobody Fri Jul 3 02:19:24 2020 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 5C5D53A0B4A; Fri, 3 Jul 2020 02:19:23 -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 Vgq-OVep15hZ; Fri, 3 Jul 2020 02:19:21 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130103.outbound.protection.outlook.com [40.107.13.103]) (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 187153A0B48; Fri, 3 Jul 2020 02:19:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nGIo64IOupoN+7le4uCOz3qx2RS3rZJ7J6bosdTwLDrl5E+F7CrBiXabqN6wa1vnJgaKPtcdsoRl+YVuon+Lgm/I9V4fHBNvnUhexBjtFYiHZCjFWGI60RSw67qEY3xY0Y0JmGmwVCCf5uKOUHFONYBc284T4Ck85yv/MlGoIyQMrEQJ6QtpG4/rEu9textXJqPPWsbfBSF5g6KGyb1mwv1R/Cji/7KO0qc7UD6CtIUQeqv7O1A1AX6Xlfez4fOLo5fZJPyqPo9T7eMh9V1EqYCT/oP55gwtrvDs8c7WmGDb88tFBoE3ewWm7RTjBLcPqkl5Xafq/3JdrWQF2dJVqw== 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=uyGUA3iqR7w5JNDIauakeZpULCFAMqZUNtPAaAeCsDE=; b=ONtK+KcsBBKqqUMa0A2XuGWtjtPkr8AHvcuAlxMZvzZEIBTyaIGJixWGekEWRgINmkZYEYdD7M0R/J3C0NFr2ZCnLCrguxo3t6JGavsZkWRipN6yp9d8KOPQjrmQqRe3HvBycBi6QCiPtePujte2+iA8aKvwmzswBLdBfvc+qNwhcUCbVcO2WtwvE4HEJ0sM9ETSTsHF9EBpD+ztd7RIBmtlnj0FMVX71SHvWlqQCSZHLlLzMVQ17KCtH8FRYim6NRAtzsDx0PRrxV5+Ky4zW16Xk8UCH6psx8GnUEoO08L8lnSzCFRxo5ZgE1XCRnDVEpHT3E65MqNvaU2PLBa4hg== 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=uyGUA3iqR7w5JNDIauakeZpULCFAMqZUNtPAaAeCsDE=; b=O6WaCm78lpC5TDLNbFjo6ItwL7H+X2au713Qmtv/C/ooOJXwAik2Fkcb2WV2eRIOdy4jRrxt3gM2P9DHSC4tBTaSkpPzuzXCdu5E/x4XZFOfMoESseZgrzyKhP5sBR8AWGcm+OugCT+TbnQH78hqy4ov9c0uFbSdJ3HctaaV8qI= Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB7PR07MB5339.eurprd07.prod.outlook.com (2603:10a6:10:2f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.12; Fri, 3 Jul 2020 09:19:18 +0000 Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::f911:a06:2f4e:a103]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::f911:a06:2f4e:a103%4]) with mapi id 15.20.3153.028; Fri, 3 Jul 2020 09:19:17 +0000 From: tom petch To: "Scharf, Michael" , "Rodney W. Grimes" CC: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Thread-Topic: [tcpm] Presentation slot requests for IETF 108 (online) Thread-Index: AdZQQCmoc741dfI0S+mziKOl37MyoQABBo5AAA4+aKAACA7QAAAbykOAAANh8jY= Date: Fri, 3 Jul 2020 09:19:17 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2DC85322@rznt8114.rznt.rzdir.fht-esslingen.de> <202007021820.062IKW9I062065@gndrsh.dnsmgr.net>, <6EC6417807D9754DA64F3087E2E2E03E2DC87826@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DC87826@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hs-esslingen.de; dkim=none (message not signed) header.d=none;hs-esslingen.de; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 356cda25-53ca-4e26-2c9b-08d81f322996 x-ms-traffictypediagnostic: DB7PR07MB5339: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 045315E1EE x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cpVNXMTQcqNZ6X4A9FphjqZ1pbImxjg4kfaPYqPx5KX+YfxjcQANUTtw235SaD6kUqXvse/Ca34FWRwCEfGFDrl0JLuCFKNwBhjhBmA8jG9/sKXWBBnJ9aoxAhRaEPMMrmHeSkAIFT/IoeKQanZqHu8GheZt2wrCL1EDxeIVCiWvoVCjY8v15zDlvk1/OeaqFMQs5yiWc8MxvRKklirHTxzO5kvZwhZMc/pk//fqExMe+A9liulc+Ics9ErriE5exzmH1NA6euFkkdPHhO6ohD8jESIAqoWcZPd2N4Np5VhVzk/4KI5ZJdPysBpKy7eyMgJSSkonmIVLE1BnsXnP/b9T6jsd35b6+JkZEUQLjcEpZVogxqgJZbTH8IyeMf6nMbUpsPS2BTHkm3Hg01hYYg== 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:(346002)(396003)(366004)(136003)(39860400002)(376002)(53546011)(6506007)(8936002)(83380400001)(5660300002)(33656002)(76116006)(91956017)(66946007)(316002)(66476007)(64756008)(66446008)(54906003)(8676002)(110136005)(2906002)(66556008)(478600001)(966005)(7696005)(52536014)(71200400001)(55016002)(9686003)(186003)(26005)(86362001)(4326008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: qscpu6tgSRFE/4yC/6nS9CMpM3L4f4yXYA+ub7HOUld0zm6daBOoU/hXCJyNzf2M7W91yIFIRyS1iecwQ9ozPXEkhTm4+WtX8C35BHyn5qryuxNmmjZBllOVQZCAT1RhHmPTCpciRMxjR49rgt+ciW9NOA/5fOg3mNp/WXpS/B9syx/xBAM6LjyVEGshnEhjg/gSlVHVtkj9IcUdB8bR6iIpujbRxGxnoxIrp8Uv3JFPE/Se+4WRWDSY9BC3CSPZ1CaHON8TdM7Ra47/8b6WI1BdDd/TvJbSX3A6ovwS3emkQ0jLKVHzzwdYAqarCVFB2QXELaN09shGeyW6fDCdvHqEGszusThKl1sU4aMcysRIynrjCOcnfuuQ4ushiS4M97Jw+fXFY09tiHP3/3jmFNuanvEkGVaG+Oi3evZ1z7PjED5xOu4UsNBEsaLfpisziz0yVKqzrZX74a7h+zGStUfq1SsV7vqHufdu+jwNMzY= 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5340.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 356cda25-53ca-4e26-2c9b-08d81f322996 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2020 09:19:17.8159 (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: 1zWazRB7jXW7BoLrjRMSSpDqAWMy8sdby2ipcR98ohtj+ZfJQZTCCfKIzUnfzW4HhntiKifiKwdEtOZQ1sXTMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5339 Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 09:19:24 -0000 From: tcpm on behalf of Scharf, Michael =0A= Sent: 03 July 2020 08:36=0A= =0A= Rod,=0A= =0A= Tim Wicinski has already mentioned that "update" metadata can be used to ke= ep record of the history.=0A= =0A= Also, I believe it is quite common in the IETF to rename I-Ds if they move = between WGs. For individual submissions, this is probably not formally requ= ired, though.=0A= =0A= The advantage of -tcpm- is that it is then more apparent on which list the = discussion shall take place. Not all readers of I-Ds are familiar with all = IETF internals.=0A= =0A= =0A= which is why it is a bad idea to rename I-D IMHO when the WG changes since = it then requires a datatracker wonk to know where to go in the maze of IETF= related pages to find what it was in a previous life, something WG Chairs = do all the time but mere mortals may not. When OSPF became LSR, the I-D we= re NOT renamed and very sensible it was too:-)=0A= The only time a change of identifier is sensible is when an individual draf= t is adopted which happens to be another aspect of IETF internals that most= outside the IETF will not be familiar with!.=0A= Tom Petch=0A= Michael=0A= =0A= > -----Original Message-----=0A= > From: Rodney W. Grimes =0A= > Sent: Thursday, July 2, 2020 8:21 PM=0A= > To: Scharf, Michael =0A= > Cc: Markus.Amend@telekom.de; tcpm@ietf.org; tcpm-chairs@ietf.org=0A= > Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online)=0A= >=0A= > Michael,=0A= > Shouldnt the datatracker entry in its entierity be moved=0A= > to tcpm since tcpm is now taking on the work of the closed mptcp wg?=0A= > That way history of the document is preserved and can be easier=0A= > to research.=0A= >=0A= > I am not sure this is even possible, but loosing the=0A= > provadence of a document because it moved WG's seems problematic.=0A= >=0A= > Regards,=0A= > Rod=0A= >=0A= > > Markus,=0A= > >=0A= > > Thanks for the request.=0A= > >=0A= > > It may make sense to resubmit the I-D as -tcpm- if it shall be presente= d in=0A= > TCPM. Then it shows up in datatracker in the right context.=0A= > >=0A= > > Michael=0A= > >=0A= > > > -----Original Message-----=0A= > > > From: Markus.Amend@telekom.de =0A= > > > Sent: Thursday, July 2, 2020 9:55 AM=0A= > > > To: Scharf, Michael ; tcpm@ietf.org= =0A= > > > Cc: tcpm-chairs@ietf.org; kangjiao@huawei.com=0A= > > > Subject: RE: Presentation slot requests for IETF 108 (online)=0A= > > >=0A= > > > Dear Michaels, Yoshi=0A= > > >=0A= > > > Since MPTCP WG is closed and TCPM takes care, Jiao and I would like t= o=0A= > > > present implementation updates (probably also a new draft version -02= )=0A= > for=0A= > > >=0A= > > > * draft-amend-mptcp-robe / "Multipath TCP Robust Session=0A= > Establishment"=0A= > > > * Jiao Kang / Markus Amend=0A= > > > * 20min=0A= > > >=0A= > > > Just in case we are not able to update the recent -01 to a -02, is it= still=0A= > > > required to move the -01 to TCPM before #108?=0A= > > >=0A= > > > Br=0A= > > >=0A= > > > Markus=0A= > > >=0A= > > > -----Original Message-----=0A= > > > From: tcpm On Behalf Of Scharf, Michael=0A= > > > Sent: Donnerstag, 2. Juli 2020 09:15=0A= > > > To: tcpm@ietf.org=0A= > > > Cc: tcpm-chairs =0A= > > > Subject: [tcpm] Presentation slot requests for IETF 108 (online)=0A= > > >=0A= > > > Hi all,=0A= > > >=0A= > > > Given that we had a pretty packed agenda during the virtual interim= =0A= > meeting,=0A= > > > the chairs have asked for two slots during IETF 108. This basically i= mplies=0A= > that=0A= > > > we have again the 2:30 hour slot that TCPM used to have for many year= s.=0A= > > >=0A= > > > According to the draft agenda for IETF 108, TCPM has been scheduled f= or=0A= > > > Monday Session I (1:40) and Monday Session II (0:50).=0A= > > >=0A= > > > If you are interested in presenting, please let the chairs know until= =0A= > > > **Monday 2020-07-13**:=0A= > > >=0A= > > > * Draft name / presentation title=0A= > > > * Presenter=0A= > > > * Total duration (including Q&A)=0A= > > >=0A= > > > Thanks=0A= > > >=0A= > > > Michael (2x) and Yoshi=0A= > > >=0A= > > > _______________________________________________=0A= > > > tcpm mailing list=0A= > > > tcpm@ietf.org=0A= > > > https://www.ietf.org/mailman/listinfo/tcpm=0A= > >=0A= > > _______________________________________________=0A= > > tcpm mailing list=0A= > > tcpm@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/tcpm=0A= > >=0A= >=0A= > --=0A= > Rod Grimes rgrimes@freebs= d.org=0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From nobody Fri Jul 3 02:54:14 2020 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 229093A0BA3; Fri, 3 Jul 2020 02:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo4l_Hzs7954; Fri, 3 Jul 2020 02:54:11 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EF43A0B9F; Fri, 3 Jul 2020 02:54:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id E3F7525A17; Fri, 3 Jul 2020 11:54:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1593770048; bh=GzFh82oMu1T4QYoNQrFWrefBmXFAT8nBcldTJ+eJrWo=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JZKuxWnQgWzRa90W1NMdUFBeDOnKUNeoQARx2dU58gvce5ICvEOktGPBMlpG1857i sDB0F9LFzWJcMcfQob1qirgZtOTJTAlNjNYMWBvGrc7IXXysigliy95Eni0/wqC4fu 3uhmAYD4yfwERqLaYFyXH8uq9itmd/jO2u1bq/yU= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaKCDwB6mHIe; Fri, 3 Jul 2020 11:54:08 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 3 Jul 2020 11:54:08 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Fri, 3 Jul 2020 11:54:07 +0200 From: "Scharf, Michael" To: tom petch CC: "tcpm@ietf.org" , "tcpm-chairs@ietf.org" Thread-Topic: [tcpm] Presentation slot requests for IETF 108 (online) Thread-Index: AdZQQCmoc741dfI0S+mziKOl37MyoQABBo5AAA4+aKAAA93uAAAfcSkg////koD//93DsA== Date: Fri, 3 Jul 2020 09:54:07 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC87DE1@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2DC85322@rznt8114.rznt.rzdir.fht-esslingen.de> <202007021820.062IKW9I062065@gndrsh.dnsmgr.net>, <6EC6417807D9754DA64F3087E2E2E03E2DC87826@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 09:54:13 -0000 > Tim Wicinski has already mentioned that "update" metadata can be used to > keep record of the history. >=20 > Also, I believe it is quite common in the IETF to rename I-Ds if they mov= e > between WGs. For individual submissions, this is probably not formally > required, though. >=20 > The advantage of -tcpm- is that it is then more apparent on which list th= e > discussion shall take place. Not all readers of I-Ds are familiar with al= l IETF > internals. >=20 > > which is why it is a bad idea to rename I-D IMHO when the WG changes sinc= e > it then requires a datatracker wonk to know where to go in the maze of IE= TF > related pages to find what it was in a previous life, something WG Chairs= do > all the time but mere mortals may not. When OSPF became LSR, the I-D > were NOT renamed and very sensible it was too:-) Well, mere mortals may also not care much about the history of the document= , diffs between versions, and the like. As soon as they do, they sooner or = later run into datatracker, IMHO. Thus, with chair hat off, I disagree that using the name of a changed WG is= _always_ a "bad idea". But, well, my original statement was "it may make s= ense". And this includes the word MAY... > The only time a change of identifier is sensible is when an individual dr= aft is > adopted which happens to be another aspect of IETF internals that most > outside the IETF will not be familiar with!. To me, there are tradeoffs and there is no such one-fits-all rule. But the = last observation is probably correct. So, I really wonder if we discuss a r= elevant question here. And, well, the specific I-D discussed here is an (expired) -01 version of a= document that already has an "replaces" entry to an entirely different dra= ft name... I may miss something, but for this specific example I don't unde= rstand why renaming would be a real-world issue. Michael From nobody Fri Jul 3 06:29:36 2020 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 61A353A07C3; Fri, 3 Jul 2020 06:29:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant via Datatracker To: Cc: last-call@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org, rtg-ads@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159378297136.10528.6876563537109608281@ietfa.amsl.com> Reply-To: Stewart Bryant Date: Fri, 03 Jul 2020 06:29:31 -0700 Archived-At: Subject: [tcpm] Genart telechat review of draft-ietf-tcpm-rto-consider-16 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: Fri, 03 Jul 2020 13:29:32 -0000 Reviewer: Stewart Bryant Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-tcpm-rto-consider-16 Reviewer: Stewart Bryant Review Date: 2020-07-03 IETF LC End Date: 2020-06-01 IESG Telechat date: 2020-07-09 Summary: This is a well written document and is much improved over the previous version that I reviewed. I thank the author for their work in that regard. However I do have one concern that I think the Area Directors need to consider carefully. Major issues: Whilst the document has undoubtedly gained consensus in the transport area, it is not clear whether the other areas that will be impacted have properly considered the implications of the text and proactively given their consensus to the text. In particular the following text in a BCP may be a burden on future protocols, particularly in the routing and OAM spaces, with the potential for disagreements in the closing stages of specification approval. - The requirements in this document may not be appropriate in all cases and, therefore, inconsistent deviations and variants may be necessary (hence the "SHOULD" in the last bullet). However, inconsistencies MUST be (a) explained and (b) gather consensus. It is possible that I am over-reacting but experience tells me that this holds the seeds of future disagreements between areas, delays in publication, and possible re-engineering of what are in practice perfectly acceptable implementations. Minor issues: None Nits/editorial comments: There is a trivial nits issue in the abstract that the RFC editor will need to resolve. From nobody Sat Jul 4 15:42:35 2020 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 D3B4A3A1192; Sat, 4 Jul 2020 15:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eam9sj10u33Q; Sat, 4 Jul 2020 15:42:33 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848A63A118F; Sat, 4 Jul 2020 15:42:33 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id p3so16667558pgh.3; Sat, 04 Jul 2020 15:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0g6vjzjSw1QEFa2KJJaAB0mmEO8AnYZzj+/KVe/pqxg=; b=ioOWcOMhFP/9e5qucQ9nfkwCLk9Jknv1IGG1N18Bx+SfsbQvMSIeS29jSSTWXqA8Rw 1mXRTUH0oQEJo73s7o0P+/xGyefHsU9oeGvvyS8yZS8+f5XYoylGUXUZ4FXtASnt5eE8 vRW7kP2adSTeqy8tDKBiQkl1IRGbNEn3vcx9oax2hp07PKsEdgBN+6royJumvP7+KHUY TlhT7yXW2fR5fvk+PYUPHfg998g8EYX/Y7J8uubVxtJxsWwwReEsGnAOBuOqQgmLiKb0 WVbOg0wSWTkFuKMW2LYWDsBjKdLdaLFrlFAk4kLhWsdGQxOWSd7fecJ3dCqhezW8M+em rSdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0g6vjzjSw1QEFa2KJJaAB0mmEO8AnYZzj+/KVe/pqxg=; b=CRkhkUaxKo1HoEfY/OQZGGJzXHSt6Xijqpyn/z75zl8S0figHWj07w9LUpzqDZKYN9 6R0iFYGWvVAlh0l5miScZ3CQc5nSuT9r5aSObNuGvuQjjlxK/vxeI/60V++ragjA0chC vU9yl2Zjnb51F/MDuH9SXY3fYjNFT+18qYL1DrRSAS8YkAemwx5iH0JVvemsnE2q6Uep KIrlKzXxDochpPkNWTpC9RT8ZtMAa2umOKzInaC70CEzBQKL1bPrxxTYCRljS8e3t5gj PVpUK7rsgL3JMeb7VoNgVKw4jtqp1uFvPgr8hvOp2rqD3l37T1Nag0Nc6+2Yd4UNHt5V 7tNw== X-Gm-Message-State: AOAM531iBeoBx2YwzA0lZM+0lP2l3r73KyC5/g2bc9eD9sAlY77serNT shZm+/4DvDKy7ZuU0dyMwJLhdkX/ X-Google-Smtp-Source: ABdhPJx7LqXpaKAdYjtBoSzp8VxysFVQgOhWrd0f0Fx5dL5IdoSFwAWOti8/RWZTHrZniNZXnP7+aw== X-Received: by 2002:a62:c584:: with SMTP id j126mr14962998pfg.213.1593902552970; Sat, 04 Jul 2020 15:42:32 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:20b5:984b:4b61:48bb? ([2601:647:5600:5020:20b5:984b:4b61:48bb]) by smtp.gmail.com with ESMTPSA id b13sm14344684pjl.7.2020.07.04.15.42.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jul 2020 15:42:32 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <2C8AD99F-2FD6-47D4-99EB-8CE8F2382D48@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5F741960-B95B-4B87-9497-E9B573B5D1F1" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Sat, 4 Jul 2020 15:42:31 -0700 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> Cc: "tcpm@ietf.org" , tcpm-chairs To: Michael SCHARF References: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) 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, 04 Jul 2020 22:42:35 -0000 --Apple-Mail=_5F741960-B95B-4B87-9497-E9B573B5D1F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Michael, See the request embedded within the e-mail. > On Jul 2, 2020, at 12:15 AM, Scharf, Michael = wrote: >=20 > Hi all, >=20 > Given that we had a pretty packed agenda during the virtual interim = meeting, the chairs have asked for two slots during IETF 108. This = basically implies that we have again the 2:30 hour slot that TCPM used = to have for many years. >=20 > According to the draft agenda for IETF 108, TCPM has been scheduled = for Monday Session I (1:40) and Monday Session II (0:50). >=20 > If you are interested in presenting, please let the chairs know until = **Monday 2020-07-13**: >=20 > * Draft name / presentation title - draft-scharf-tcpm-yang-tcp/YANG = Model for Transmission Control Protocol (TCP) Configuration. > * Presenter: TBD > * Total duration (including Q&A): 10 min. >=20 > Thanks >=20 > Michael (2x) and Yoshi >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm Thanks. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_5F741960-B95B-4B87-9497-E9B573B5D1F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Michael,

See the = request embedded within the e-mail.

On Jul = 2, 2020, at 12:15 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:

Hi = all,

Given that we had a pretty packed = agenda during the virtual interim meeting, the chairs have asked for two = slots during IETF 108. This basically implies that we have again the = 2:30 hour slot that TCPM used to have for many years.

According to the draft agenda for IETF 108, TCPM has been = scheduled for Monday Session I (1:40) and Monday Session II (0:50).

If you are interested in presenting, please = let the chairs know until **Monday 2020-07-13**:

* Draft name / presentation title - draft-scharf-tcpm-yang-tcp/YANG Model for Transmission = Control Protocol (TCP) Configuration.
* Presenter: = TBD
* Total = duration (including Q&A): 10 = min.

Thanks

Michael (2x) and Yoshi

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

Thanks.


Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_5F741960-B95B-4B87-9497-E9B573B5D1F1-- From nobody Sat Jul 4 16:58:08 2020 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 4BF673A1208; Sat, 4 Jul 2020 16:58:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Yoshifumi Nishida X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <159390708628.10432.2317922664759962417@ietfa.amsl.com> Date: Sat, 04 Jul 2020 16:58:06 -0700 Archived-At: Subject: [tcpm] Murray Kucherawy's No Objection on draft-ietf-tcpm-rto-consider-16: (with COMMENT) 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: Sat, 04 Jul 2020 23:58:07 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-tcpm-rto-consider-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I note the shepherd and GenART review comments about the requirements language at the end of Section 2, and I don't find it to be problematic generally given this passed WGLC in multiple working groups (a wise move, by the way) and a proper IETF Last Call. These triple hyphens throughout the document are supposed to be em dashes, I presume? From nobody Mon Jul 6 04:13:18 2020 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 6B3B33A13A7; Mon, 6 Jul 2020 04:13:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Yoshifumi Nishida , nsd.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <159403399242.10185.16737724841858266155@ietfa.amsl.com> Date: Mon, 06 Jul 2020 04:13:12 -0700 Archived-At: Subject: [tcpm] Robert Wilton's No Objection on draft-ietf-tcpm-rto-consider-16: (with COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 11:13:13 -0000 Robert Wilton has entered the following ballot position for draft-ietf-tcpm-rto-consider-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for this document. I have no significant comments, just a few nits: 1 Introduction This document provides guidelines for developing an understanding of one path property: loss Recommend: "loss" -> "packet loss" (S.1) The requirements in this document apply only to the primary or last resort time-based loss detection. (S.2) The requirements for time-based loss detection mechanisms in this document are for the primary or "last resort" loss detection mechanism whether the mechanism is the sole loss repair strategy or works in concert with other mechanisms. I found the wording for these two requirements to be repetitive, possibly could be reworded and combined. 4 Requirements (1) As we note above, loss detection happens when a sender does not receive delivery confirmation within an some expected period of time. Nit: Delete "an" or "some" Often measuring the time required for delivery confirmation is is framed Nit: "is is" -> "is" Regards, Rob From nobody Mon Jul 6 12:49:33 2020 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 27F033A09E5; Mon, 6 Jul 2020 12:49:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Yoshifumi Nishida , nsd.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159406496706.24848.1574717471798101163@ietfa.amsl.com> Date: Mon, 06 Jul 2020 12:49:27 -0700 Archived-At: Subject: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 19:49:27 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-tcpm-rto-consider-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- If we are providing BCP-level requirements for time-based loss detection via absence of protocol-level acknowledgment, for new protocols, it seems appropriate to mandate that the acknowledgment signal is reliable, i.e., not spoofable by at least an off-path attacker, and ideally not spoofable by an on-path attacker either. I would love for this to be a cryptographically protected mechanism, but expect that I can't get away with mandating something that strong, and that something with "enough bits of entropy" will suffice. (I'd prefer "enough" to be 128 but could perhaps be persuaded that a lower value is appropriate as a minimum requirement.) Point S.3 in Section 3 indicates that "[t]he requirements in this document apply only to endpoint-to- endpoint unicast communication. Reliable multicast (e.g., [RFC5740]) protocols are explicitly outside the scope of this document." This limitation of scope should be reflected in the document's title, Abstract, and Introduction. I would also like to get an explicit confirmation that the various (non-)requirements on the details of exponential backoff and reduced weighting for old FT samples are as-intended (see COMMENT). Specifically, are there limitations on the base of the exponent for the exponential backoff, and is there a requirement to give more recent FT samples more precedence than older FT samples when computing an RTO estimate? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As a general note, the style of this document is somewhat divergent from what I understand to be "modern RFC style". While there's not a strict requirement to adhere to such a common style, and I do not have specific suggestions for changes, it did seem noteworthy. Abstract of congestion along a network path). While many mechanisms have been designed to detect loss, protocols ultimately can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection I'm not entirely convinced that the literal meaning of what these words say is universally true for all protocols (specifically "can only count on" and omitting a qualifier such as "many" or "most" protocols or "reliably count on"). Consider, for example, the DTN bundle protocol, which has some circumstances in which a given store-and-forward node will flat-out not attempt to forward a protocol onward to its final recipient, but can send back a status report to the sender noting the confirmed lack of delivery. I suggest adding some form of qualifier to admit the possibility of such unusual situations. Section 1 missing. However, despite our best intentions and most robust mechanisms we cannot place ultimate faith in receiving such acknowledgments, but can only truly depend on the passage of time. Therefore, our ultimate backstop to ensuring that we detect all loss is a timeout. [...] Despite the superficial similarity of tone, a strict reading of these words does not seem to share the issue I raised about the Abstract. (That said, this phrasing still seems a bit overblown and my personal preference would be to tone it down some.) Section 2 - This document does not update or obsolete any existing RFC. These previous specifications---while generally consistent with the requirements in this document---reflect community consensus and this document does not change that consensus. - The requirements in this document are meant to provide for network safety and, as such, SHOULD be used by all time-based loss detection mechanisms. I'm not sure that I understand how the combinations of these two statements apply to existing specifications. Is there some sense that existing specs might leave some flexibility and when there is such flexibility, implementations/deployments SHOULD use the flexibility to match this document as closely as possible? Or are existing deployments and implementations of existing RFCs also grandfathered out? If the intent of the second bullet is to only apply to new protocols, please say so explicitly. (Section 4 seems to imply the "only new protocols" case, but it's hard to be sure.) - The requirements in this document may not be appropriate in all cases and, therefore, inconsistent deviations and variants may be necessary (hence the "SHOULD" in the last bullet). However, inconsistencies MUST be (a) explained and (b) gather consensus. Similarly, is this statement only forward-looking? Presumably the first bullet ("does not update or obsolete any existing") trumps this one, but it's good to be clear. Additionally, I share the GenART reviewer's unease with this strong of a requirement and have low confidence that the IETF will reliably adhere to it in the future. nit(?): "inconsistent deviations" may be redundant? Section 3 (S.1) The requirements in this document apply only to the primary or last resort time-based loss detection. I'm not sure I understand what "primary or last resort [sic]" means. Are there time-based loss-detection mechanisms that are neither primary nor last resort? (nit: hyphenate "last-resort" as a compound adjective, and many other compound adjectives throughout.) (May also affect S.2.) I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary non-last-resort schemes, however, I think we should be more clear about what we mean when we introduce the term and why we exclude certain classes of time-based loss-detection mechanisms. detectors. However, these mechanisms do not obviate the need for a "retransmission timeout" or "RTO" because---as we discuss in Section 1---only the passage of time can ultimately be relied upon to detect loss. In cases such as these, the [This text is more like the Abstract's, implying that the passage of time is the only way to detect loss, universally] Section 4 In other words, the RTO should represent an empirically- derived reasonable amount of time that the sender should wait for delivery confirmation before deciding the given data is lost. Network paths are inherently dynamic and therefore it is crucial to incorporate multiple FT samples in the RTO to take into account the delay variation across time. It feels weird to say that the delay will vary over time here but say nothing about the corresponding need to discount very old FT samples. Point (b) talks about adding new samples in, but not about removing or discounting old samples. That the TCP example does exhibit this property does not excuse a lack of explicit mention as a property of note. (d) An RTO mechanism MUST NOT use ambiguous FT samples. Assume two copies of some segment X are transmitted at times t0 and t1 and then at time t2 the sender receives confirmation that X in fact arrived. In some cases, it is "segment" feels like use of TCP-specific terminology without disclaimer or generalization. There are cases where two copies of some data are transmitted in a way whereby the sender can tell which is being acknowledged by an incoming ACK. E.g., TCP's timestamp option [RFC7323] allows for segments to be uniquely identified and hence avoid the ambiguity. In such cases there is no ambiguity and the resulting samples can update the RTO. Perhaps note that QUIC was designed from the start to avoid the ambiguity about retransmitted segments? (3) Loss detected by the RTO mechanism MUST be taken as an indication of network congestion and the sending rate adapted using a standard mechanism (e.g., TCP collapses the congestion window to one segment [RFC5681]). [...] An exception to this rule is if an IETF standardized mechanism determines that a particular loss is due to a non-congestion event (e.g., packet corruption). In such a case a congestion If it's a MUST with an exception, doesn't that make it ... no longer a MUST? (4) Each time the RTO is used to detect a loss, the value of the RTO MUST be exponentially backed off such that the next firing requires a longer interval. [...] Do we expect this to be exponential backoff by doubling, or is it admissible to use an alternative base for the exponent? (Is there a minimum allowable value? E.g., 1.000001 does not seem like it would provide much protection for the network.) As with guideline (3), an exception to this rule exists if an IETF standardized mechanism determines that a particular loss is not due to congestion. (Same as above.) Section 5 Also, note, that in addition to the experiments discussed in [AP99], nit: s/note, that/note that,/ Further, a number of implementations use a steady-state minimum RTO that are less than the 1 second specified in [RFC6298] (which is different from the initial RTO we specify in Section 4, Requirement 1). While the implication of these deviations from the standard may Just to check: our requirement 1 is the same as RFC 6298, and the "less than 1 second" is what's different. Perhaps wording this akin to "and as such is in violation of the RTO specified in Requirement 1 from Section 4" would avoid the ambiguity about what is different from what. Finally, we note that while allowing implementations to be more aggressive could in fact increase the number of needless retransmissions the above requirements fail safe in that they insist nit: I suggest a comma after "needless retransmissions" Section 6 Noting that we incorporate the security considerations of RFC 6298 by reference, and quoting from there: In addition, even if the attacker can cause the sender's RTO to reach too small a value, it appears the attacker cannot leverage this into much of an attack (compared to the other damage they can do if they can spoof packets belonging to the connection), since the sending TCP will still back off its timer in the face of an incorrectly transmitted packet's loss due to actual congestion. Just to check my understanding: this "actual congestion" would need to be between the sender and the attacker, right? Since the attacker's spoofed ACKs would cause the sender to not detect loss due to congestion that occurs between the attacker and the intended recipient. References The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6298]") implies that it should be categorized as normative. Similarly for RFC 6298 itself. [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC 2134, June 2001. Fix the typo, please -- RFC 2134 is the articles of incorporation of ISOC. From nobody Mon Jul 6 13:33:40 2020 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 73EC23A0ACB; Mon, 6 Jul 2020 13:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCS7zR_ylAET; Mon, 6 Jul 2020 13:33:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 351853A0AC1; Mon, 6 Jul 2020 13:33:22 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 066KXDR0031822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Jul 2020 16:33:15 -0400 Date: Mon, 6 Jul 2020 13:33:12 -0700 From: Benjamin Kaduk To: Liang Xia Cc: secdir@ietf.org, last-call@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org Message-ID: <20200706203312.GR16335@kduck.mit.edu> References: <159045449615.13336.5105636835437605086@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <159045449615.13336.5105636835437605086@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [tcpm] [secdir] Secdir last call review of draft-ietf-tcpm-rto-consider-14 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, 06 Jul 2020 20:33:32 -0000 Hi Frank, Thanks for the review. I agree that what's presented in the document is pretty straightforward and without direct security issues, however, I chose to try to broaden the scope of the document slightly, balloting Discuss to suggest adding a requirement that (when writing new protocols) the ACKs used as input for RTO algorithms be unspoofable from off-path (i.e., have enough entropy to be unguessable). That kind of scope expansion is probably outside the scope (pun intended) of a typical secdir review, though :) Thanks, Ben On Mon, May 25, 2020 at 05:54:56PM -0700, Liang Xia via Datatracker wrote: > Reviewer: Liang Xia > Review result: Ready > > This document is good written, and no new security issues as it's a network > mechanism requirements BCP document. > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Mon Jul 6 17:52:00 2020 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 6BE743A07CB for ; Mon, 6 Jul 2020 17:51:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159408311942.25355.16137173131521428009@ietfa.amsl.com> Date: Mon, 06 Jul 2020 17:51:59 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG 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: Tue, 07 Jul 2020 00:51:59 -0000 Added milestone "Submit a document on modifying slow start to avoid large tail drops", due May 2021. URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Tue Jul 7 00:46:05 2020 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 BE8F63A09CC; Tue, 7 Jul 2020 00:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMaKlQakRqot; Tue, 7 Jul 2020 00:46:01 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A943A09C0; Tue, 7 Jul 2020 00:46:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 7E08225A1B; Tue, 7 Jul 2020 09:45:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1594107958; bh=yqRyYSX19A7Dd8doJVuk898s0mkhjn2ee3LvR0YiMcg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=iFwfw6NC6AYNV1zBySNJLEufDfUAGCbK/quXLzboiWlTOViLfD8+Iqsj7IEM6WDiy kQngqkzZ8bS8ENLwSSFpwEANKaHUxjjarjoX7GE5Y+b+KX1I30KpxyMhYTWNWaFeZD uhmjr3j9zuG8E99sICuaZusExLCDOMZ+XvZ8Uj5o= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyoxdJPVF066; Tue, 7 Jul 2020 09:45:56 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 7 Jul 2020 09:45:56 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Tue, 7 Jul 2020 09:45:56 +0200 From: "Scharf, Michael" To: Mahesh Jethanandani CC: "tcpm@ietf.org" , tcpm-chairs Thread-Topic: [tcpm] Presentation slot requests for IETF 108 (online) Thread-Index: AdZQQCmoc741dfI0S+mziKOl37MyoQCA3mmAAHukzUA= Date: Tue, 7 Jul 2020 07:45:56 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC9287C@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> <2C8AD99F-2FD6-47D4-99EB-8CE8F2382D48@gmail.com> In-Reply-To: <2C8AD99F-2FD6-47D4-99EB-8CE8F2382D48@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2DC9287Crznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) 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, 07 Jul 2020 07:46:04 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2DC9287Crznt8114rzntrzd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mahesh, Thanks. My co-chairs will decide on that slot request, as I am an author of= the I-D. But as we have a pretty long slot this time, I expect that we have enough t= ime for all presentation requests. I would probably plan rather with a 15min slot - under the assumption what = a discussion on the next steps (such as WG adoption in TCPM) is needed. Michael From: Mahesh Jethanandani Sent: Sunday, July 5, 2020 12:43 AM To: Scharf, Michael Cc: tcpm@ietf.org; tcpm-chairs Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) Hi Michael, See the request embedded within the e-mail. On Jul 2, 2020, at 12:15 AM, Scharf, Michael > wrote: Hi all, Given that we had a pretty packed agenda during the virtual interim meeting= , the chairs have asked for two slots during IETF 108. This basically impli= es that we have again the 2:30 hour slot that TCPM used to have for many ye= ars. According to the draft agenda for IETF 108, TCPM has been scheduled for Mon= day Session I (1:40) and Monday Session II (0:50). If you are interested in presenting, please let the chairs know until **Mon= day 2020-07-13**: * Draft name / presentation title - draft-scharf-tcpm-yang-tcp/YANG Model f= or Transmission Control Protocol (TCP) Configuration. * Presenter: TBD * Total duration (including Q&A): 10 min. Thanks Michael (2x) and Yoshi _______________________________________________ tcpm mailing list tcpm@ietf.org https://www.ietf.org/mailman/listinfo/tcpm Thanks. Mahesh Jethanandani mjethanandani@gmail.com --_000_6EC6417807D9754DA64F3087E2E2E03E2DC9287Crznt8114rzntrzd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mahesh,=

 = ;

Thanks. My co-chairs will decide on that slot request, as I am an auth= or of the I-D.

 

But as we have a pretty long slot this time, I expect that we have eno= ugh time for all presentation requests.

 

I would probably plan rather with a 15min slot - under the assumption = what a discussion on the next steps (such as WG adoption in TCPM) is needed.

 

Michael

 

From: Mahesh Jethanandani <mjetha= nandani@gmail.com>
Sent: Sunday, July 5, 2020 12:43 AM
To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
Cc: tcpm@ietf.org; tcpm-chairs <tcpm-chairs@ietf.org>
Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online)=

 

Hi Michael,

 

See the request embedded within the e-mail.



On Jul 2, 2020, at 12:15 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.= de> wrote:

 

Hi all,

Given that we had a pretty packed agenda during the virtual interim meeting= , the chairs have asked for two slots during IETF 108. This basically impli= es that we have again the 2:30 hour slot that TCPM used to have for many ye= ars.

According to the draft agenda for IETF 108, TCPM has been scheduled for Mon= day Session I (1:40) and Monday Session II (0:50).

If you are interested in presenting, please let the chairs know until **Mon= day 2020-07-13**:

* Draft name / presentation title - draft-sch= arf-tcpm-yang-tcp/YANG Model for Transmission Control Protocol (TCP) Config= uration.
* Presenter: TBD
* Total duration (including Q&A): 10 min.=

Thanks

Michael (2x) and Yoshi

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

 

Thanks.

 

Mahesh Jethanandani

 

 

 

--_000_6EC6417807D9754DA64F3087E2E2E03E2DC9287Crznt8114rzntrzd_-- From nobody Tue Jul 7 01:21:08 2020 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 E041E3A07A7; Tue, 7 Jul 2020 01:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ona0m6AC90Qi; Tue, 7 Jul 2020 01:21:03 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C553A07A3; Tue, 7 Jul 2020 01:21:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 2016225A26; Tue, 7 Jul 2020 10:21:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1594110061; bh=DKcZCw08JayAhDX1qKmcdzTeyn9vC16vxT8NGszAqhY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=GsEV91ER1oAw9zEhxzuKq5W+a4FYNXZpL7x3GTzvtctsiWCgKzho+Z9iDwSGLhGAV nU7mRQD2nP3fCz4LH17BC8n+mwi//WQgtVbih3OAgnYZs0+xfmJ4gUmXOkgWPT559u 2P4e29Sehfkxxe7xanBuDh+5p42mC+k7Ep9D8Atg= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlMjOTROERvz; Tue, 7 Jul 2020 10:20:59 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 7 Jul 2020 10:20:59 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Tue, 7 Jul 2020 10:20:59 +0200 From: "Scharf, Michael" To: Joseph Touch , Mirja Kuehlewind CC: "tcpm@ietf.org" , tcpm-chairs Thread-Topic: [tcpm] WGLC for draft-ietf-tcpm-2140bis Thread-Index: AQHWRmfqKbJ4UHStAUergHNr/f0rSajgI86AgBu6pSA= Date: Tue, 7 Jul 2020 08:20:59 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC92AA1@rznt8114.rznt.rzdir.fht-esslingen.de> References: <7840A9F4-48C7-4C41-8464-DB92A086F7A5@strayalpha.com> In-Reply-To: <7840A9F4-48C7-4C41-8464-DB92A086F7A5@strayalpha.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-2140bis 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, 07 Jul 2020 08:21:08 -0000 SGkgYWxsLA0KDQpJIGhhdmUgbm90IHNlZW4gZm9sbG93LXVwIGRpc2N1c3Npb25zLiANCg0KUmVn YXJkaW5nIDEpOiBBcyBmYXIgYXMgSSBjYW4gc2VlLCB0aGUgc2VjdXJpdHkgc2VjdGlvbiB3YXMg cmV3cml0dGVuIGluIC0wMiwgYnV0IGFzIGZhciBhcyBJIHJlY2FsbCB0aGUgaW50ZW50aW9uIHdh cyBtb3N0bHkgdG8gX2FkZF8gY29uc2lkZXJhdGlvbnMgKG9uIGZpbmdlcnByaW50aW5nKS4gV2hh dCB0ZXh0IHdvdWxkIGJlIG5lZWRlZCB0byBzb3J0IG91dCB0aGlzIGNvbW1lbnQ/DQoNClJlZ2Fy ZGluZyAyKTogVGhlIGFwcGVuZGl4IGlzIGluIHRoZXJlIGZvciBxdWl0ZSBzb21lIHRpbWUgYWxy ZWFkeSwgYnV0IG91dCBvZiBteSBoZWFkIHRoZXJlIHdhcyBub3QgbXVjaCByZWNlbnQgZGlzY3Vz c2lvbiBvbiBwYXJ0IG9mIHRoZSBkb2N1bWVudC4gV2VsbCwgaXQgaXMgYW4gYXBwZW5kaXggaW4g YW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudC4uLiBBcmUgdGhlcmUgb3RoZXIgdmlld3Mgb24gdGhl IGFwcGVuZGl4IGluIHRoZSBUQ1BNIGNvbW11bml0eT8NCg0KSSdkIGxpa2UgdG8gc29ydCB0aGlz IG91dCBpbiBvcmRlciB0byBjb25jbHVkZSB0aGUgV0dMQy4NCg0KVGhhbmtzDQoNCk1pY2hhZWwN CihhcyBzaGVwaGVyZCkNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBK b3NlcGggVG91Y2ggPHRvdWNoQHN0cmF5YWxwaGEuY29tPg0KPiBTZW50OiBGcmlkYXksIEp1bmUg MTksIDIwMjAgODo0MCBQTQ0KPiBUbzogTWlyamEgS3VlaGxld2luZCA8bWlyamEua3VlaGxld2lu ZD00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4NCj4gQ2M6IFNjaGFyZiwgTWljaGFlbCA8 TWljaGFlbC5TY2hhcmZAaHMtZXNzbGluZ2VuLmRlPjsgdGNwbUBpZXRmLm9yZzsNCj4gdGNwbS1j aGFpcnMgPHRjcG0tY2hhaXJzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3RjcG1dIFdHTEMg Zm9yIGRyYWZ0LWlldGYtdGNwbS0yMTQwYmlzDQo+IA0KPiBIaSwgTWlyamEsDQo+IA0KPiA+IE9u IEp1biAxOSwgMjAyMCwgYXQgMTE6MzEgQU0sIE1pcmphIEt1ZWhsZXdpbmQNCj4gPG1pcmphLmt1 ZWhsZXdpbmQ9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiA+DQo+ID4g SGkgTWljaGFlbCwgaGkgYWxsLA0KPiA+DQo+ID4gc29ycnkgZm9yIGJlaW5nIGxhdGUgaGVyZSBi dXQgdGltZXMgYXJlIGJ1c3kuLi4gc28gdGhhbmtzIGZvciB0aGUgZXh0ZW5zaW9uLg0KPiA+DQo+ ID4gVGhhbmtzIHRvIHRoZSBhdXRob3JzIGZvciBhbGwgdGhlIHdvcmsgb24gdGhpcyBiaXMgZG9j LiBJIG9ubHkgbWFuYWdlZCB0bw0KPiBoYXZlIGEgYnJpZWYgcmV2aWV3IG9mIHRoZSBkcmFmdCBi dXQgSSB0aGluayBpdCBhbiBpbnRlcmVzdGluZyByZWFkIHdpdGggYSBsb3Qgb2YNCj4gZ29vZCB1 cGRhdGVzLiBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1Ymxp Y2F0aW9uLA0KPiBob3dldmVyLCBJIGhhdmUgdHdvIGNvbW1lbnRzL3F1ZXN0aW9ucy4gdFRoZSBm aXJzdCBvbmUgaXMgbW9yZSBhDQo+IHN1Z2dlc3Rpb24gYnV0IHRoZSBzZWNvbmQgcG9pbnQgaXMg c29tZXRoaW5nIEkgdGhpbmsgd2Ugc2hvdWxkIGJlIHNob3VsZCB3ZQ0KPiBoYXZlIHN1cHBvcnQg Zm9yIGluIHRoZSBncm91cCBiZWZvcmUgd2UgbW92ZSBhaGVhZC4NCj4gPg0KPiA+IDEpIFRoZSBz ZWN1cml0eSBzZWN0aW9uIGNvdWxkIG1heWJlIGFsc28gZGlzY3VzcyBpZiB0aGVyZSBhcmUgYW55 DQo+IGltcGxpY2F0aW9ucyBmb3IgbGlrYWJpbGl0eSB3aGVuIGNhY2hpbmcgYW55IG9mIHRoZXNl IGluZm9ybWF0aW9uIGFuZCBob3cgdG8NCj4gaGFuZGxlIHRoYXQuIExvb2tpbmcgYXQgdGhlIGRp ZmYsIHRoZXJlIHdhcyBhIHNlY3Rpb24gaW4gdGhlIHNlY3VyaXR5DQo+IGNvbnNpZGVyYXRpb24g YWJvdXQgaW5mb3JtYXRpb24gc2hhcmluZyBvZiBhcHBsaWNhdGlvbi1zcGVjaWZpYyBzZXR0aW5n cy4gU28NCj4gd2h5IHdhcyB0aGF0IHJlbW92ZWQ/IEhvd2V2ZXIsIEkgdGhpbmsgdGhlIGRvY3Vt ZW50IGNvdWxkIGV2ZW4gc2F5DQo+IG1vcmUhDQo+ID4NCj4gPiAyKSBJIHdhcyBxdWl0ZSBzdXJw cmlzZWQgdG8gc2VlIGFwcGVuZGl4IEMgYW5kIHRoYXQgaXQgaXMgYSBGVUxMIGNvcHkgb2YgZHJh ZnQtDQo+IHRvdWNoLXRjcG0tYXV0b21hdGljLWl3LTAzLiBJJ20gb2theSB0byBkaXNjdXNzIG1v cmUgY29uc2lkZXJhdGlvbnMgb24gdGhlDQo+IElXIGUuZy4gb24gdGhlIGRlc2lnbiBwcmluY2lw bGUgbGV2ZWwgYW5kIG1vc3QgaW1wb3J0YW50bHkgbWF5YmUgdGhhdCBhIGxvc3MNCj4gd2l0aGlu IHRoZSBJVyBjYW4vc2hvdWxkIGltcGFjdGluZyB0aGUgY2FjaGVkIHZhbHVlLCBhbmQgdG8gZG8g c28gZXZlbiBpbg0KPiB0aGUgYm9keSBvZiB0aGUgZG9jLCBob3dldmVyLCBpZiBJIHJlbWVtYmVy IGNvcnJlY3RseSB0aGVyZSB3YXMgYSBsb3Qgb2YNCj4gZGlzY3Vzc2lvbiBhYm91dCB0aGUgYXV0 b21hdGVkIHNldHRpbmcgb2YgSVcgaW4gdGNwbSB3aGVuIHRoZSBJVzEwIFJGQw0KPiB3YXMgdW5k ZXIgZGlzY3Vzc2lvbiBhbmQgbm8gYWdyZWVtZW50IHJlYWNoZWQgaW4gdGhlIGdyb3VwLCBzbyB3 b3VsZA0KPiByYXRoZXIganVzdCBsaWtlIHRvIHNlZSBhIHJlZmVyZW5jZSB0byB0aGUgZXhwaXJl ZCBkcmFmdCB0aGFuIGNvcHkgYW5kIHBhc3RpbmcNCj4gdGhlIHdob2xlIGFsZ29yaXRobSBpbiB0 aGUgYXBwZW5kaXggb2YgdGhpcyBkcmFmdC4NCj4gDQo+IFRoZSBkaXNjdXNzaW9uIHdhcyBvbmx5 IHdoZXRoZXIgdGhlcmUgd2VyZSBzcGVjaWZpYyBzZXR0aW5ncyB0aGF0IGhhZCBiZWVuDQo+IGlt cGxlbWVudGVkLiBJZiB3ZSBjaXRlIGFuIGV4cGlyZWQgZHJhZnQsIHdlIG5lZWQgdG8gYmFzaWNh bGx5IGFkZCBzb21lIGluZm8NCj4gdG8gZXhwbGFpbiB3aGF04oCZcyBpbiB0aGUgb3RoZXIgZG9j ICh3aGljaCB3ZSBhcmUgc3VwcG9zZWQgdG8gdHJlYXQgYXMgbm9uLQ0KPiBleGlzdGVudCkuIEku ZS4sIGlmIHdl4oCZcmUgY2l0aW5nIGFuIG9sZCBkcmFmdCBmb3IgY3JlZGl0LCBpdOKAmXMganVz dCBhIGNpdGF0aW9uLCBidXQgaW4NCj4gdGhpcyBjYXNlIHdl4oCZcmUgc2F5aW5nIHRoYXQgdGhl IHRlY2huaXF1ZXMgaW4gdGhhdCBkcmFmdCAqYXJlKiBqdXN0IGEgdmFyaWFudCBvZg0KPiB3aGF0 IDIxNDAgYWxyZWFkeSBzdWdnZXN0cywgb25seSBvbiBhIGRpZmZlcmVudCB0aW1lc2NhbGUuDQo+ IA0KPiBJLmUuLCDigJxkaXNjdXNzaW5nIG1vcmUgY29uc2lkZXJhdGlvbnPigJ0gaXMgYmFzaWNh bGx5IHdoYXQgdGhhdCB0ZXh0IGFscmVhZHkgZG9lcy4NCj4gQWxsIHRoZSBpc3N1ZXMgdGhhdCBh cmUgaW4gdGhlIG9yaWdpbmFsIGRvYyB3ZXJlIHJlbGV2YW50IGZvciB0aGlzIG9uZeKAmXMNCj4g ZGlzY3Vzc2lvbiBvbiB0aGF0IGlzc3VlLg0KPiANCj4gSm9lDQo= From nobody Tue Jul 7 06:52:46 2020 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 6BE9E3A0D18 for ; Tue, 7 Jul 2020 06:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 asAa7nYSRViM for ; Tue, 7 Jul 2020 06:52:31 -0700 (PDT) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) (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 97E663A0D32 for ; Tue, 7 Jul 2020 06:52:29 -0700 (PDT) Received: by mail-ot1-f44.google.com with SMTP id 18so34319780otv.6 for ; Tue, 07 Jul 2020 06:52:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=lCdUDTiS4XZRQ+MC7Ao/xcEe4EuX9ZYhvEWKp5VPmgU=; b=pSxrqs9v7nw36u/L4aVN2LWO4Jx3b8XkmstGV3ZPNOcbNHDIVuM9SjUNa8IV/cKHpy i6zZMENnPrZgb4YGtnXRKcQ7tDCcgdGtLdh8DuFJZ5V//9UYysqIJZrSySPVYJ2e8GHF RbyuW9weiA2r2pJnXjHUa3Yfm+WtHvNB2w1ntl/AuLjALpS3h4MOZtXubpjR03p9BM1S Ios21x0JwcOrvsimvXpvDWYhxAvlA45qe+yWV8vxYM9TQMxwbsQGNcFi5G9XuiRsZpKj M0jTFAypk4lhltZmEaFUznAinw0ur1HdkU9cSf81d4PkH/7IM9yzeAwVnm9fOpOkAqPQ Xt0A== X-Gm-Message-State: AOAM533YNjGuFpLz/kHzvYq0y1WywLHMYqFqdUW4Ah0Kt0fQKwPIs0R+ H87qxgomZ0smnyaIHzG0AEJ3soJN56g3Zg== X-Google-Smtp-Source: ABdhPJxiAHZ8v1PkBJE5U7NtylZFA+qh1nuBZe6/zXczewusmzuDEfcBljhQB5V6rLY12CqATwtLyg== X-Received: by 2002:a9d:7c95:: with SMTP id q21mr23454785otn.65.1594129948427; Tue, 07 Jul 2020 06:52:28 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:5ca4:49cf:6dbb:2f5f]) by smtp.gmail.com with ESMTPSA id h10sm137030ooe.44.2020.07.07.06.52.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2020 06:52:27 -0700 (PDT) From: "Mark Allman" To: "Benjamin Kaduk" Cc: "The IESG" , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, "Yoshifumi Nishida" Date: Tue, 07 Jul 2020 09:52:26 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <77541F38-87A3-4E0B-929D-9F9BE5CFD00E@icir.org> In-Reply-To: <159406496706.24848.1574717471798101163@ietfa.amsl.com> References: <159406496706.24848.1574717471798101163@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_75324B94-38FC-4235-B93F-23AE99C39BDA_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT) 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, 07 Jul 2020 13:52:41 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_75324B94-38FC-4235-B93F-23AE99C39BDA_= Content-Type: text/plain [resend using better From to get past all the moderation stuff; sorry if this is a repeat] Hi Benjamin! > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > If we are providing BCP-level requirements for time-based loss > detection via absence of protocol-level acknowledgment, for new > protocols, it seems appropriate to mandate that the acknowledgment > signal is reliable, i.e., not spoofable by at least an off-path > attacker, and ideally not spoofable by an on-path attacker either. > I would love for this to be a cryptographically protected > mechanism, but expect that I can't get away with mandating > something that strong, and that something with "enough bits of > entropy" will suffice. (I'd prefer "enough" to be 128 but could > perhaps be persuaded that a lower value is appropriate as a > minimum requirement.) I have been thinking about this since yesterday and have a few thoughts ... - In some sense, I like the general thought. It would tighten things up. - That said, pragmatically, I think the risk from spoofed ACKs is pretty small. For instance, if you want to screw up the RTO you need to pretty continuously screw up the FT measurements for anything long running. So, it isn't enough to guess and inject correctly once, but you have to do so on an ongoing basis. And, with much less than 128 bits of entropy something like TCP is not particularly susceptible to this sort of thing. - And, so we can obviously make up a requirement for future protocols here, but I don't think that will be a "BCP" or even "CP". It would not be like the rest of the document where the aspects of loss detection are well understood. - And, we'd have to decide what we meant by "new protocol". Is that some wholly new thing or is that a new algorithm for SCTP or TCP or DNS? - Perhaps there is some non-normative note that could be added that folks are encouraged to think about making the feedback non-spoofable for FT measurements (among many other reasons, of course). I dunno ... > Point S.3 in Section 3 indicates that "[t]he requirements in this > document apply only to endpoint-to- endpoint unicast > communication. Reliable multicast (e.g., [RFC5740]) protocols are > explicitly outside the scope of this document." This limitation > of scope should be reflected in the document's title, Abstract, > and Introduction. (A note can be added.) > I would also like to get an explicit confirmation that the various > (non-)requirements on the details of exponential backoff and > reduced weighting for old FT samples are as-intended (see > COMMENT). Specifically, are there limitations on the base of the > exponent for the exponential backoff, and is there a requirement > to give more recent FT samples more precedence than older FT > samples when computing an RTO estimate? Yes- the intent is to not specify the details. The basic gist of the document is that we have learned that the details are not hugely important and so getting away from them is fine. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Abstract > > of congestion along a network path). While many mechanisms have > been designed to detect loss, protocols ultimately can only count on > the passage of time without delivery confirmation to declare a > packet "lost". Each implementation of a time-based loss detection > > I'm not entirely convinced that the literal meaning of what these > words say is universally true for all protocols (specifically "can > only count on" and omitting a qualifier such as "many" or "most" > protocols or "reliably count on"). Consider, for example, the DTN > bundle protocol, which has some circumstances in which a given > store-and-forward node will flat-out not attempt to forward a > protocol onward to its final recipient, but can send back a status > report to the sender noting the confirmed lack of delivery. I > suggest adding some form of qualifier to admit the possibility of > such unusual situations. > > Section 1 > > missing. However, despite our best intentions and most robust > mechanisms we cannot place ultimate faith in receiving such > acknowledgments, but can only truly depend on the passage of time. > Therefore, our ultimate backstop to ensuring that we detect all loss > is a timeout. [...] > > Despite the superficial similarity of tone, a strict reading of > these words does not seem to share the issue I raised about the > Abstract. (That said, this phrasing still seems a bit overblown > and my personal preference would be to tone it down some.) The point is objectively true and actually meant to be absolute. Yes, an explicit non-delivery notification can be sent. Such notifications may be useful and even quite important. But, ultimately, we cannot be rely upon such things to ensure reliable communications because they themselves may get lost, corrupted, delayed, etc. But, if time somehow stops marching forward then ... well, WGAS about the packets?! :) Too me this is a crucial protocol building touchstone. One has to think about what we can and cannot count on. And to what degree. > Section 2 > > - This document does not update or obsolete any existing RFC. > These previous specifications---while generally consistent with > the requirements in this document---reflect community consensus > and this document does not change that consensus. > > - The requirements in this document are meant to provide for > network safety and, as such, SHOULD be used by all time-based > loss detection mechanisms. > > I'm not sure that I understand how the combinations of these two > statements apply to existing specifications. Is there some sense that > existing specs might leave some flexibility and when there is such > flexibility, implementations/deployments SHOULD use the flexibility to > match this document as closely as possible? Or are existing deployments > and implementations of existing RFCs also grandfathered out? If the > intent of the second bullet is to only apply to new protocols, please > say so explicitly. (Section 4 seems to imply the "only new protocols" > case, but it's hard to be sure.) The first bullet is intended to be backwards looking and the second bullet is intended to be forward looking. A few extra words there to make the second bullet more clear would be (in hindsight!) useful. > - The requirements in this document may not be appropriate in all > cases and, therefore, inconsistent deviations and variants may > be necessary (hence the "SHOULD" in the last bullet). However, > inconsistencies MUST be (a) explained and (b) gather consensus. > > Similarly, is this statement only forward-looking? Presumably the first > bullet ("does not update or obsolete any existing") trumps this one, but > it's good to be clear. Yes- forward looking. Clarifying words to be added. > Additionally, I share the GenART reviewer's unease with this > strong of a requirement and have low confidence that the IETF will > reliably adhere to it in the future. In fairness to Stewart---even though I disagree with him---I think his point is broader than just non-adherence. (Stewart and I have iterated on his comments and in fact a number of his LC comments made the document better. But, on this point we just fundamentally disagreed.) I don't presume to speak for Stewart, but I believe he fears this will become a touchstone for area-on-area warfare whereby perfectly justifiable deviations won't be well understood as "perfectly justifiable" by folks not intimate with the given context. And, this will in turn hold things up. And, he seems especially concerned about cases where we want to update something that has been used forever and, yet, deviates from rto-consider. My take is three-fold ... - First, this statement in rto-consider really doesn't change anything, IMO. If we're not explaining why we're doing things and not getting consensus then we shouldn't be publishing it. - Second, this explicit statement was added to get WG consensus. Removing it or softening it would, I believe, run counter to the consensus the document has already gathered. - Third, IMO, saying a given mechanism has proven to be fine in a given context should really be enough justification. That is, yeah, I can see that some protocol lawyer could be pedantic. And, that might be annoying, I guess. But, I think reasonable people should be able to form a consensus that rebuts such things. > Section 3 > > (S.1) The requirements in this document apply only to the primary or > last resort time-based loss detection. > > I'm not sure I understand what "primary or last resort [sic]" means. > Are there time-based loss-detection mechanisms that are neither primary > nor last resort? (nit: hyphenate "last-resort" as a compound adjective, > and many other compound adjectives throughout.) > (May also affect S.2.) > I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary > non-last-resort schemes, however, I think we should be more clear about > what we mean when we introduce the term and why we exclude certain > classes of time-based loss-detection mechanisms. > > detectors. However, these mechanisms do not obviate the need > for a "retransmission timeout" or "RTO" because---as we > discuss in Section 1---only the passage of time can ultimately > be relied upon to detect loss. In cases such as these, the > > [This text is more like the Abstract's, implying that the passage of > time is the only way to detect loss, universally] I dunno. I would have to think about this a bit. As you say, we tried to sprinkle in references to non-last-resort timers. Perhaps there are some words we can add here to explain things better. You're the first one to trip on this. But, I'd be happy to go through this text and think about it again. > Section 4 > > In other words, the RTO should represent an empirically- > derived reasonable amount of time that the sender should > wait for delivery confirmation before deciding the given > data is lost. Network paths are inherently dynamic and > therefore it is crucial to incorporate multiple FT samples > in the RTO to take into account the delay variation across > time. > > It feels weird to say that the delay will vary over time here but say > nothing about the corresponding need to discount very old FT samples. > Point (b) talks about adding new samples in, but not about removing or > discounting old samples. That the TCP example does exhibit this > property does not excuse a lack of explicit mention as a property of > note. I think a note that says "it's fine to discount old samples" is OK and perfectly within the spirit of the guideline. I don't want to overly specify that one has to do this. > (d) An RTO mechanism MUST NOT use ambiguous FT samples. > > Assume two copies of some segment X are transmitted at times > t0 and t1 and then at time t2 the sender receives > confirmation that X in fact arrived. In some cases, it is > > "segment" feels like use of TCP-specific terminology without disclaimer > or generalization. (I can change this to 'packet'.) > (3) Loss detected by the RTO mechanism MUST be taken as an > indication of network congestion and the sending rate adapted > using a standard mechanism (e.g., TCP collapses the congestion > window to one segment [RFC5681]). > [...] > An exception to this rule is if an IETF standardized mechanism > determines that a particular loss is due to a non-congestion > event (e.g., packet corruption). In such a case a congestion > > If it's a MUST with an exception, doesn't that make it ... no longer a > MUST? I don't think so. But, you're no doubt a better protocol lawyer than I am. I believe this says you really have to do this, but there is a **very precise way** to get out of it. If we made this a SHOULD then it would be very much looser---i.e., you really ought to do this unless you have a good reason. Here we are telling you what the good reason has to look like. > (4) Each time the RTO is used to detect a loss, the value of the RTO > MUST be exponentially backed off such that the next firing > requires a longer interval. [...] > > Do we expect this to be exponential backoff by doubling, or is it > admissible to use an alternative base for the exponent? (Is there > a minimum allowable value? E.g., 1.000001 does not seem like it > would provide much protection for the network.) The document does not say to double the RTO. It means to not specify the constant. Again, the document is meant to get away from specifics where we can. I don't know how to set the minimal acceptable backoff. I think we'd all agree 1.000001 is not really going to cut it. But, would 1.8? How about 1.7? What about 1.3? I believe the consensus is that "exponential backoff" is enough. > Further, a number of implementations use a steady-state minimum RTO > that are less than the 1 second specified in [RFC6298] (which is > different from the initial RTO we specify in Section 4, Requirement > 1). While the implication of these deviations from the standard may > > Just to check: our requirement 1 is the same as RFC 6298, and the "less > than 1 second" is what's different. Perhaps wording this akin to "and > as such is in violation of the RTO specified in Requirement 1 from > Section 4" would avoid the ambiguity about what is different from what. Well. Um. I read it many times, but cannot understand what you wrote about the document's ambiguity! ;-) Maybe that is my lack of coffee, I dunno. But, let me try anyway ... RFC 6298 says the INITIAL RTO should be no less than 1sec. That agrees with rto-consider (requirement 1). RFC 6298 further says the MINIMUM RTO over the entire lifetime of a TCP connection should be no less than 1sec. There is no corresponding admonishment in rto-consider. Probably because these two things are both "1sec" in TCP a lot of people have gotten them mixed up in their minds during the development of this document. The parenthetical you quote was no doubt meant to clarify to someone. But, this discussion can be cleaned up, probably. > Section 6 > > Noting that we incorporate the security considerations of RFC 6298 > by reference, and quoting from there: > > In addition, even if the attacker can cause the sender's RTO to reach > too small a value, it appears the attacker cannot leverage this into > much of an attack (compared to the other damage they can do if they > can spoof packets belonging to the connection), since the sending TCP > will still back off its timer in the face of an incorrectly > transmitted packet's loss due to actual congestion. > > Just to check my understanding: this "actual congestion" would > need to be between the sender and the attacker, right? Since the > attacker's spoofed ACKs would cause the sender to not detect loss > due to congestion that occurs between the attacker and the > intended recipient. Oh boy. My brain is thrashing to try to page back in RFC6298. The above text isn't the most clear, so I assume I didn't write it. :) Hmm. I think the basic point is that if an attacker can spoof they can do much worse than impacting the computation of the RTO. And, if what they want to do is mess with a connection's performance and not the reliability of the connection---say because that'd be user-visible---then they cannot hide real losses. And, since they cannot hide real losses then from a network safety perspective this all fails safely because the endpoint will backoff when detecting those losses. > References > > The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6298]") > implies that it should be categorized as normative. Similarly for RFC > 6298 itself. I dunno. The entirety of the algorithm is given in rto-consider. So, the reference is really meant to give credit and point people at a place to read about it in more detail instead of as a pointer that must be understood to enact the guideline. Perhaps just a restructuring ... Therefore, in this situation an implementation MUST use Karn's algorithm and use neither version of the FT sample and hence not update the RTO (see [KP87,RFC6298] for a broader discussion of Karn's algorithm). Or, put them under "Normative". I really don't much care. > [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC > 2134, June 2001. > > Fix the typo, please -- RFC 2134 is the articles of incorporation of > ISOC. Well, I do not want to be anywhere near ISOC anything! Good catch, thanks! (And, what a weird typo ... all the digits are there, but in such a weird order ...) allman --=_MailMate_75324B94-38FC-4235-B93F-23AE99C39BDA_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXwR+GhEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizq6TAJ0fUhSi+r1+hqX2S727LkCt8OfeGQCfeXUy m2eEnl0lwbSwMQhrXQYIH4Q= =BhUY -----END PGP SIGNATURE----- --=_MailMate_75324B94-38FC-4235-B93F-23AE99C39BDA_=-- From nobody Tue Jul 7 07:43:55 2020 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 ED5153A0D5F; Tue, 7 Jul 2020 07:43:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Yoshifumi Nishida , nsd.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <159413302994.31598.19077014220035835@ietfa.amsl.com> Date: Tue, 07 Jul 2020 07:43:49 -0700 Archived-At: Subject: [tcpm] Roman Danyliw's No Objection on draft-ietf-tcpm-rto-consider-16: (with COMMENT) 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: Tue, 07 Jul 2020 14:43:50 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-tcpm-rto-consider-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ** What’s “network safety” in the context of this document? How do I know I have it? IMO, precision is needed since there is normative language around assuring it; and it likely has a different connotation when used in the security operations setting. ** References supporting the following claims/observations would be helpful: -- Section 1. Per “… we leverage the conservative notion that loss is an implicit indication of congestion .. it has historically served us well.” -- Section 1. Per “At this point, our experience leads to a recognition that often specific tweaks that deviate from standardized time-based loss detectors do not materially impact network safety with respect to congestion control.” ** Section 3. S.1 and S.2. The text would benefit from a more precise definition of primary and last resort timers as these are scoping the document ** Section 6. I might mention that one of the applications of loss measurements in the network is in DoS detection. From nobody Tue Jul 7 07:56:18 2020 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 A584B3A0DAD; Tue, 7 Jul 2020 07:56:15 -0700 (PDT) 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: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <159413377526.28047.15797027750212969283@ietfa.amsl.com> Date: Tue, 07 Jul 2020 07:56:15 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-17.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: Tue, 07 Jul 2020 14:56:16 -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-17.txt Pages : 106 Date : 2020-07-07 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-17 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 7 08:01:09 2020 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 8553E3A0CCE for ; Tue, 7 Jul 2020 06:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icsi-berkeley-edu.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 fpbdV3vNmhGB for ; Tue, 7 Jul 2020 06:49:10 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 2134B3A0CCC for ; Tue, 7 Jul 2020 06:49:10 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id h1so12167182otq.12 for ; Tue, 07 Jul 2020 06:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icsi-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=EX6bq//cay5hE/MWN8Jbm/Cmt4dGLrkPuHsdSLmW/o0=; b=tmp2Z3kLKIA/fkxK6wiocgqQJzOI0bnT60Z/5+3xX+Sc5CHH9Cc6mkcHAebcYkr2P5 LCMLUvCMUxV2DwEZFEqxjNRXjUuQ9tyex3V9SjPBZ6ePNuJVJmXYhqUjlaLKQck/Yhtr zJipPW6iADqBBp7/PKIm0cthPD8b9cQWVe+xSq7XsYHafKiZLTiBQmrO7nMGDjr/zIo3 uFxL6m/7KiTUNqDPv1dIKk6aPz4hfHNlYPOxarQc0rK6AtAeOWWs81l4oFNvTCv8ZPVx LzorOWmffDXKKB2V+KW87zESIcwtYTHQQEiOxfF+S4GyNmI/eDHViGvQ9iiWruH9TgvA G1Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=EX6bq//cay5hE/MWN8Jbm/Cmt4dGLrkPuHsdSLmW/o0=; b=MqNNCJCuDanDWsOzE2frtIiwd/Wx8AstaijZXV3C9wk0Nq24vhzf8QMWhdDKmOfHG1 B//0koPvFy7hCwcJ0FmwW+y+6Ykf0/QkZdTZdbMpmtwxMh/AmS1yThqYJmE9SZKz57CK BU75zBQiktGOD8UoWqx2ZEJf9OnZCOoeK6wjImPbjchsuE1pxuqRZc2r0Pnga2XMijC9 5lGSiAPJvyleET9VWu9kze+ngaAYSNomgYzVHFMWVi/HKUxXFeuhXS9AJb6s8Tgiy8w3 YHn/GNnKw0/5mFytEd4bA+B1fTFGM4WOGjiWR58dVycBlMBu3DtV2E81bh/Wdh0+7h97 CBYw== X-Gm-Message-State: AOAM531LEFjJLT84uVWAevpQ8IYrlSuxlGMhbp1rFlzWUHogkscsUQ3R jQj8XeC88tavEyb+T2rHbt/WBw== X-Google-Smtp-Source: ABdhPJxBfbyuhGqRB23IbEFJwAu/2E6mGuNEPw6U1pp1MAf+fHJllOEy+cEmo4aUL9ZcUOpKSneaFA== X-Received: by 2002:a9d:611d:: with SMTP id i29mr17913325otj.42.1594129748930; Tue, 07 Jul 2020 06:49:08 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:5ca4:49cf:6dbb:2f5f]) by smtp.gmail.com with ESMTPSA id i11sm144486oom.9.2020.07.07.06.49.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2020 06:49:08 -0700 (PDT) From: "Mark Allman" To: "Benjamin Kaduk" Cc: "The IESG" , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, "Yoshifumi Nishida" Date: Tue, 07 Jul 2020 09:49:06 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <97326820-187D-4A67-BBF0-CC58FAF18F0B@icsi.berkeley.edu> In-Reply-To: <159406496706.24848.1574717471798101163@ietfa.amsl.com> References: <159406496706.24848.1574717471798101163@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_D90801A7-890B-4E29-B915-5156ACFE2E06_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: X-Mailman-Approved-At: Tue, 07 Jul 2020 08:01:07 -0700 Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT) 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, 07 Jul 2020 13:49:14 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_D90801A7-890B-4E29-B915-5156ACFE2E06_= Content-Type: text/plain Hi Benjamin! > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > If we are providing BCP-level requirements for time-based loss > detection via absence of protocol-level acknowledgment, for new > protocols, it seems appropriate to mandate that the acknowledgment > signal is reliable, i.e., not spoofable by at least an off-path > attacker, and ideally not spoofable by an on-path attacker either. > I would love for this to be a cryptographically protected > mechanism, but expect that I can't get away with mandating > something that strong, and that something with "enough bits of > entropy" will suffice. (I'd prefer "enough" to be 128 but could > perhaps be persuaded that a lower value is appropriate as a > minimum requirement.) I have been thinking about this since yesterday and have a few thoughts ... - In some sense, I like the general thought. It would tighten things up. - That said, pragmatically, I think the risk from spoofed ACKs is pretty small. For instance, if you want to screw up the RTO you need to pretty continuously screw up the FT measurements for anything long running. So, it isn't enough to guess and inject correctly once, but you have to do so on an ongoing basis. And, with much less than 128 bits of entropy something like TCP is not particularly susceptible to this sort of thing. - And, so we can obviously make up a requirement for future protocols here, but I don't think that will be a "BCP" or even "CP". It would not be like the rest of the document where the aspects of loss detection are well understood. - And, we'd have to decide what we meant by "new protocol". Is that some wholly new thing or is that a new algorithm for SCTP or TCP or DNS? - Perhaps there is some non-normative note that could be added that folks are encouraged to think about making the feedback non-spoofable for FT measurements (among many other reasons, of course). I dunno ... > Point S.3 in Section 3 indicates that "[t]he requirements in this > document apply only to endpoint-to- endpoint unicast > communication. Reliable multicast (e.g., [RFC5740]) protocols are > explicitly outside the scope of this document." This limitation > of scope should be reflected in the document's title, Abstract, > and Introduction. (A note can be added.) > I would also like to get an explicit confirmation that the various > (non-)requirements on the details of exponential backoff and > reduced weighting for old FT samples are as-intended (see > COMMENT). Specifically, are there limitations on the base of the > exponent for the exponential backoff, and is there a requirement > to give more recent FT samples more precedence than older FT > samples when computing an RTO estimate? Yes- the intent is to not specify the details. The basic gist of the document is that we have learned that the details are not hugely important and so getting away from them is fine. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Abstract > > of congestion along a network path). While many mechanisms have > been designed to detect loss, protocols ultimately can only count on > the passage of time without delivery confirmation to declare a > packet "lost". Each implementation of a time-based loss detection > > I'm not entirely convinced that the literal meaning of what these > words say is universally true for all protocols (specifically "can > only count on" and omitting a qualifier such as "many" or "most" > protocols or "reliably count on"). Consider, for example, the DTN > bundle protocol, which has some circumstances in which a given > store-and-forward node will flat-out not attempt to forward a > protocol onward to its final recipient, but can send back a status > report to the sender noting the confirmed lack of delivery. I > suggest adding some form of qualifier to admit the possibility of > such unusual situations. > > Section 1 > > missing. However, despite our best intentions and most robust > mechanisms we cannot place ultimate faith in receiving such > acknowledgments, but can only truly depend on the passage of time. > Therefore, our ultimate backstop to ensuring that we detect all loss > is a timeout. [...] > > Despite the superficial similarity of tone, a strict reading of > these words does not seem to share the issue I raised about the > Abstract. (That said, this phrasing still seems a bit overblown > and my personal preference would be to tone it down some.) The point is objectively true and actually meant to be absolute. Yes, an explicit non-delivery notification can be sent. Such notifications may be useful and even quite important. But, ultimately, we cannot be rely upon such things to ensure reliable communications because they themselves may get lost, corrupted, delayed, etc. But, if time somehow stops marching forward then ... well, WGAS about the packets?! :) Too me this is a crucial protocol building touchstone. One has to think about what we can and cannot count on. And to what degree. > Section 2 > > - This document does not update or obsolete any existing RFC. > These previous specifications---while generally consistent with > the requirements in this document---reflect community consensus > and this document does not change that consensus. > > - The requirements in this document are meant to provide for > network safety and, as such, SHOULD be used by all time-based > loss detection mechanisms. > > I'm not sure that I understand how the combinations of these two > statements apply to existing specifications. Is there some sense that > existing specs might leave some flexibility and when there is such > flexibility, implementations/deployments SHOULD use the flexibility to > match this document as closely as possible? Or are existing deployments > and implementations of existing RFCs also grandfathered out? If the > intent of the second bullet is to only apply to new protocols, please > say so explicitly. (Section 4 seems to imply the "only new protocols" > case, but it's hard to be sure.) The first bullet is intended to be backwards looking and the second bullet is intended to be forward looking. A few extra words there to make the second bullet more clear would be (in hindsight!) useful. > - The requirements in this document may not be appropriate in all > cases and, therefore, inconsistent deviations and variants may > be necessary (hence the "SHOULD" in the last bullet). However, > inconsistencies MUST be (a) explained and (b) gather consensus. > > Similarly, is this statement only forward-looking? Presumably the first > bullet ("does not update or obsolete any existing") trumps this one, but > it's good to be clear. Yes- forward looking. Clarifying words to be added. > Additionally, I share the GenART reviewer's unease with this > strong of a requirement and have low confidence that the IETF will > reliably adhere to it in the future. In fairness to Stewart---even though I disagree with him---I think his point is broader than just non-adherence. (Stewart and I have iterated on his comments and in fact a number of his LC comments made the document better. But, on this point we just fundamentally disagreed.) I don't presume to speak for Stewart, but I believe he fears this will become a touchstone for area-on-area warfare whereby perfectly justifiable deviations won't be well understood as "perfectly justifiable" by folks not intimate with the given context. And, this will in turn hold things up. And, he seems especially concerned about cases where we want to update something that has been used forever and, yet, deviates from rto-consider. My take is three-fold ... - First, this statement in rto-consider really doesn't change anything, IMO. If we're not explaining why we're doing things and not getting consensus then we shouldn't be publishing it. - Second, this explicit statement was added to get WG consensus. Removing it or softening it would, I believe, run counter to the consensus the document has already gathered. - Third, IMO, saying a given mechanism has proven to be fine in a given context should really be enough justification. That is, yeah, I can see that some protocol lawyer could be pedantic. And, that might be annoying, I guess. But, I think reasonable people should be able to form a consensus that rebuts such things. > Section 3 > > (S.1) The requirements in this document apply only to the primary or > last resort time-based loss detection. > > I'm not sure I understand what "primary or last resort [sic]" means. > Are there time-based loss-detection mechanisms that are neither primary > nor last resort? (nit: hyphenate "last-resort" as a compound adjective, > and many other compound adjectives throughout.) > (May also affect S.2.) > I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary > non-last-resort schemes, however, I think we should be more clear about > what we mean when we introduce the term and why we exclude certain > classes of time-based loss-detection mechanisms. > > detectors. However, these mechanisms do not obviate the need > for a "retransmission timeout" or "RTO" because---as we > discuss in Section 1---only the passage of time can ultimately > be relied upon to detect loss. In cases such as these, the > > [This text is more like the Abstract's, implying that the passage of > time is the only way to detect loss, universally] I dunno. I would have to think about this a bit. As you say, we tried to sprinkle in references to non-last-resort timers. Perhaps there are some words we can add here to explain things better. You're the first one to trip on this. But, I'd be happy to go through this text and think about it again. > Section 4 > > In other words, the RTO should represent an empirically- > derived reasonable amount of time that the sender should > wait for delivery confirmation before deciding the given > data is lost. Network paths are inherently dynamic and > therefore it is crucial to incorporate multiple FT samples > in the RTO to take into account the delay variation across > time. > > It feels weird to say that the delay will vary over time here but say > nothing about the corresponding need to discount very old FT samples. > Point (b) talks about adding new samples in, but not about removing or > discounting old samples. That the TCP example does exhibit this > property does not excuse a lack of explicit mention as a property of > note. I think a note that says "it's fine to discount old samples" is OK and perfectly within the spirit of the guideline. I don't want to overly specify that one has to do this. > (d) An RTO mechanism MUST NOT use ambiguous FT samples. > > Assume two copies of some segment X are transmitted at times > t0 and t1 and then at time t2 the sender receives > confirmation that X in fact arrived. In some cases, it is > > "segment" feels like use of TCP-specific terminology without disclaimer > or generalization. (I can change this to 'packet'.) > (3) Loss detected by the RTO mechanism MUST be taken as an > indication of network congestion and the sending rate adapted > using a standard mechanism (e.g., TCP collapses the congestion > window to one segment [RFC5681]). > [...] > An exception to this rule is if an IETF standardized mechanism > determines that a particular loss is due to a non-congestion > event (e.g., packet corruption). In such a case a congestion > > If it's a MUST with an exception, doesn't that make it ... no longer a > MUST? I don't think so. But, you're no doubt a better protocol lawyer than I am. I believe this says you really have to do this, but there is a **very precise way** to get out of it. If we made this a SHOULD then it would be very much looser---i.e., you really ought to do this unless you have a good reason. Here we are telling you what the good reason has to look like. > (4) Each time the RTO is used to detect a loss, the value of the RTO > MUST be exponentially backed off such that the next firing > requires a longer interval. [...] > > Do we expect this to be exponential backoff by doubling, or is it > admissible to use an alternative base for the exponent? (Is there > a minimum allowable value? E.g., 1.000001 does not seem like it > would provide much protection for the network.) The document does not say to double the RTO. It means to not specify the constant. Again, the document is meant to get away from specifics where we can. I don't know how to set the minimal acceptable backoff. I think we'd all agree 1.000001 is not really going to cut it. But, would 1.8? How about 1.7? What about 1.3? I believe the consensus is that "exponential backoff" is enough. > Further, a number of implementations use a steady-state minimum RTO > that are less than the 1 second specified in [RFC6298] (which is > different from the initial RTO we specify in Section 4, Requirement > 1). While the implication of these deviations from the standard may > > Just to check: our requirement 1 is the same as RFC 6298, and the "less > than 1 second" is what's different. Perhaps wording this akin to "and > as such is in violation of the RTO specified in Requirement 1 from > Section 4" would avoid the ambiguity about what is different from what. Well. Um. I read it many times, but cannot understand what you wrote about the document's ambiguity! ;-) Maybe that is my lack of coffee, I dunno. But, let me try anyway ... RFC 6298 says the INITIAL RTO should be no less than 1sec. That agrees with rto-consider (requirement 1). RFC 6298 further says the MINIMUM RTO over the entire lifetime of a TCP connection should be no less than 1sec. There is no corresponding admonishment in rto-consider. Probably because these two things are both "1sec" in TCP a lot of people have gotten them mixed up in their minds during the development of this document. The parenthetical you quote was no doubt meant to clarify to someone. But, this discussion can be cleaned up, probably. > Section 6 > > Noting that we incorporate the security considerations of RFC 6298 > by reference, and quoting from there: > > In addition, even if the attacker can cause the sender's RTO to reach > too small a value, it appears the attacker cannot leverage this into > much of an attack (compared to the other damage they can do if they > can spoof packets belonging to the connection), since the sending TCP > will still back off its timer in the face of an incorrectly > transmitted packet's loss due to actual congestion. > > Just to check my understanding: this "actual congestion" would > need to be between the sender and the attacker, right? Since the > attacker's spoofed ACKs would cause the sender to not detect loss > due to congestion that occurs between the attacker and the > intended recipient. Oh boy. My brain is thrashing to try to page back in RFC6298. The above text isn't the most clear, so I assume I didn't write it. :) Hmm. I think the basic point is that if an attacker can spoof they can do much worse than impacting the computation of the RTO. And, if what they want to do is mess with a connection's performance and not the reliability of the connection---say because that'd be user-visible---then they cannot hide real losses. And, since they cannot hide real losses then from a network safety perspective this all fails safely because the endpoint will backoff when detecting those losses. > References > > The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6298]") > implies that it should be categorized as normative. Similarly for RFC > 6298 itself. I dunno. The entirety of the algorithm is given in rto-consider. So, the reference is really meant to give credit and point people at a place to read about it in more detail instead of as a pointer that must be understood to enact the guideline. Perhaps just a restructuring ... Therefore, in this situation an implementation MUST use Karn's algorithm and use neither version of the FT sample and hence not update the RTO (see [KP87,RFC6298] for a broader discussion of Karn's algorithm). Or, put them under "Normative". I really don't much care. > [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC > 2134, June 2001. > > Fix the typo, please -- RFC 2134 is the articles of incorporation of > ISOC. Well, I do not want to be anywhere near ISOC anything! Good catch, thanks! (And, what a weird typo ... all the digits are there, but in such a weird order ...) allman --=_MailMate_D90801A7-890B-4E29-B915-5156ACFE2E06_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHgEARECADgWIQR2wAGDYhexl/6SqCRbKutazjIizgUCXwR9UhocbWFsbG1hbkBp Y3NpLmJlcmtlbGV5LmVkdQAKCRBbKutazjIizkQkAJ48lbgWDUelAMeoxRdodWN/ lFTwxgCfTkbOnI9wW1E+oVl/V9nYsxaVZDA= =yxQl -----END PGP SIGNATURE----- --=_MailMate_D90801A7-890B-4E29-B915-5156ACFE2E06_=-- From nobody Tue Jul 7 08:21:38 2020 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 499DB3A0E18 for ; Tue, 7 Jul 2020 08:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fT6JKWMINVpX for ; Tue, 7 Jul 2020 08:21:32 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 47CC43A0E16 for ; Tue, 7 Jul 2020 08:21:31 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id x62so32009895qtd.3 for ; Tue, 07 Jul 2020 08:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=YgFOj0KTRE74C6Suh1FffiVl3nAosMiESijJiZ2ZPrI=; b=rhN4dWu/YtxlyzSySr+GkRjcKjtxJaS3vC/Teip3e2sk0fa8/Y7P9CDrnbLxtrQ8mW 7zc1Ai56c+OTHogtQnvW0h1N6M1a7mqO1Gvugq1pTczlbBXTg7MnxPbkNmQP2do9MCWE mw1bHlw1AJr9PkftyoBmvEAL7boQzLax9f8xAZ4BZ7QALwEdgvbyC3rzTqu9Ps2goygq 1vex+sHrj/MwpAV3s7n8TqrwuQD6QhnkXgg8UZ55pdenrQDUGegJuWnbVUkeMF3EpfMj aDS17TGvtAHktEoJ07u6NWAxDafm2odRvOn+pGq5ij+4cRC3Oohh6P8+DI1G/0NT2S7H ONqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=YgFOj0KTRE74C6Suh1FffiVl3nAosMiESijJiZ2ZPrI=; b=lMoFbJnO3jHNhrIQgw4RSpuK8CKG7Y8DBP4WW5fXvdz1W5XCHlX30fvL+eiy69RP68 /W2lD8okS2nGr/O+sS3OaXd+SJNi/uF84Wc+V/vW3Q1+dvwZx4U4I+gXoYKvwkd5mq/h dRS3h/TyZwN2FknuslQNzzdWwbXUKSFG/UcYqTK71wTZ4JqO1O1uSOOjOOQP2Pyp/icU ta1EU+u16YyK7B4hU7c0+UAlOpMjtFJEuAtxvJse4ejuFzfAtK0UEfh4Ic+LRwtag617 gwpQ6Yqe11+b1qtuPNSkbBG1Et0zvqOxmCflXX/Gg7Atgfl/RG283gq+nG4gzbPAiZtt 4PNQ== X-Gm-Message-State: AOAM532oWd/5M72omrMr34OR8nsFd0WocLXqp00ycLvkzcWQHq/Q9QxQ E4BH7If3v90k3THo2T+tohO8632o9Vq+Uw== X-Google-Smtp-Source: ABdhPJwQHEZXcFdYLYxJ/R2RP8JNAcWlSIaJaJfjRcXZFi/gRIp7NxDbJy44e9GKdo9kzJ0boBvnSQ== X-Received: by 2002:aed:21da:: with SMTP id m26mr36350404qtc.197.1594135289899; Tue, 07 Jul 2020 08:21:29 -0700 (PDT) Received: from [192.168.1.6] (user-12l31c7.cable.mindspring.com. [69.81.133.135]) by smtp.gmail.com with ESMTPSA id h41sm16633455qtk.68.2020.07.07.08.21.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Jul 2020 08:21:29 -0700 (PDT) To: tcpm@ietf.org References: <159413377526.28047.15797027750212969283@ietfa.amsl.com> From: Wesley Eddy Message-ID: Date: Tue, 7 Jul 2020 11:21:27 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <159413377526.28047.15797027750212969283@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-17.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 15:21:37 -0000 The changes in this revision are: - Updated header flags registry changes per prior list and meeting discussion. - Updated boilerplate for requirements language. - Changed word from "users" to "connections" regarding OPEN calls, per prior list discussion. - Made correction for errata 6222 that was marked "hold for document update". On 7/7/2020 10:56 AM, internet-drafts@ietf.org wrote: > 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-17.txt > Pages : 106 > Date : 2020-07-07 > > 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-17 > https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-17 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-17 > > > 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/ > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jul 7 10:56:14 2020 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 943CA3A0808 for ; Tue, 7 Jul 2020 10:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noDtoZRTExoi for ; Tue, 7 Jul 2020 10:56:11 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 4EC3C3A07F8 for ; Tue, 7 Jul 2020 10:56:11 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id 72so6473500ple.0 for ; Tue, 07 Jul 2020 10:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=3CmJKUMay53di3t+SfAWaOMtYJpSUX4KAw+cL7I4CVg=; b=a7Ytbmx38lEqbv43LCDtL22DlQ8vaj/8U67olywiHF4LQZf7xHmppzMQv7Xqotzzw7 h9D/Nyki5l+UWx3D48/KISnW6Xs3Mehslrmz8gqk5BHSGHBQO1M2ZPgP2HR8d2hR15kv 1m76XXxKTai/rdbKqWBruefKpl/0CEy//RG8cN5kE6C7V0pmFVfvujB+/dgRFhsh8Kd9 5MFUsS2lsRrEYu7woW/MGU/LUmZNuigorHWL4zfFev+mQlvS0jxpgA4LAygTswdKJ6IR u3bLoXbIxn3dqWBu7+r9sZHmMEhHpDUiug2Pv7jvT46QbrIvuve2Hu/lrtsQ6PHEfAV+ QnVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=3CmJKUMay53di3t+SfAWaOMtYJpSUX4KAw+cL7I4CVg=; b=kvDG3QP1KH1ghYlA2JorsfunaKKdRI+2wqK9b3XECVuNzSYm7Hzk5JT36xXCxZuVBA v4mgbdItnyU0bbS4QfgsgMkWApD6EtKBznaJs4s+Eyx4oTkX0Razq6x3GrejSx/ki/c4 fhC8H0/axb3DUUzyKoLd5QDrHjXL+fASKhW5TdbCjX6VNl+3QKyHWPF1ATKw/f6DvaKX /UVeywAq7f2nfolJMRdwkEEgiNze0/9dH4YMnuGKF739pOuSoI3E2jHXPYeLqkngQCcs apMjMcg6nUB9CBoTIbeCXcQyefPtu+JfsHmOOqFM40nDinXqt8HF5RFQnJqEUxwODp88 Z79w== X-Gm-Message-State: AOAM532Yqm5WZjBFeEK6rjzOg94VBQpS7+7anLsFDITYInswbEYtZe7l mNZR++tLeX9sn9y6QIXER17w/NRu X-Google-Smtp-Source: ABdhPJz+IXcNEwi3epfhuRCd450gF/qeJGf3685BG7JiE7aWhisZo9eCs4MYqdpDLpxU4+cEbeVe+Q== X-Received: by 2002:a17:902:ff13:: with SMTP id f19mr35740311plj.339.1594144570248; Tue, 07 Jul 2020 10:56:10 -0700 (PDT) Received: from ?IPv6:2601:647:5600:5020:2da1:1cb9:e3de:8e6d? ([2601:647:5600:5020:2da1:1cb9:e3de:8e6d]) by smtp.gmail.com with ESMTPSA id e16sm23132870pff.180.2020.07.07.10.56.09 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2020 10:56:09 -0700 (PDT) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) Date: Tue, 7 Jul 2020 10:56:08 -0700 References: <159414341389.5288.2538556311202282998@ietfa.amsl.com> To: tcpm@ietf.org In-Reply-To: <159414341389.5288.2538556311202282998@ietfa.amsl.com> Message-Id: <2C8E52DA-8F47-4FCF-B5F4-B24B97B43975@gmail.com> X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [tcpm] New Version Notification for draft-scharf-tcpm-yang-tcp-05.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2020 17:56:13 -0000 This version of the document tries to address the issues that were = brought up as part of WG adoption. The draft and the model has been = stripped down to what would be considered the bare minimum for the YANG = model to be useful, and in particular what would is needed by other = models that want to configure TCP parameters. We, the authors, plan to bring up the question of WG adoption in the = upcoming meeting. Thanks. > On Jul 7, 2020, at 10:36 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version of I-D, draft-scharf-tcpm-yang-tcp-05.txt > has been successfully submitted by Mahesh Jethanandani and posted to = the > IETF repository. >=20 > Name: draft-scharf-tcpm-yang-tcp > Revision: 05 > Title: YANG Model for Transmission Control Protocol = (TCP) Configuration > Document date: 2020-07-07 > Group: Individual Submission > Pages: 19 > URL: = https://www.ietf.org/internet-drafts/draft-scharf-tcpm-yang-tcp-05.txt > Status: = https://datatracker.ietf.org/doc/draft-scharf-tcpm-yang-tcp/ > Htmlized: = https://tools.ietf.org/html/draft-scharf-tcpm-yang-tcp-05 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-scharf-tcpm-yang-tcp > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-scharf-tcpm-yang-tcp-05 >=20 > Abstract: > This document specifies a YANG model for TCP on devices that are > configured by network management protocols. The YANG model defines = a > container for all TCP connections and groupings of some of the > parameters that can be imported and used in TCP implementations or = by > other models that need to configure TCP parameters. The model > includes definitions from YANG Groupings for TCP Client and TCP > Servers (I-D.ietf-netconf-tcp-client-server). The model is NMDA = (RFC > 8342) compliant. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com From nobody Wed Jul 8 08:36:41 2020 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 66DA13A0E33; Wed, 8 Jul 2020 08:36:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Yoshifumi Nishida , nsd.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <159422257236.6987.12408412094777683810@ietfa.amsl.com> Date: Wed, 08 Jul 2020 08:36:12 -0700 Archived-At: Subject: [tcpm] Alissa Cooper's No Objection on draft-ietf-tcpm-rto-consider-16: (with COMMENT) 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, 08 Jul 2020 15:36:13 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-tcpm-rto-consider-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Ben that the use of "we" and "our" is a little jarring and the document would be improved if those instances could be changed. From nobody Wed Jul 8 08:56:05 2020 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 E74DC3A0E75; Wed, 8 Jul 2020 08:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=FahdSKJT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iZd+xR1/ 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 dk6mwoJmO_gv; Wed, 8 Jul 2020 08:56:01 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D803D3A0E53; Wed, 8 Jul 2020 08:56:00 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0E76D5C0061; Wed, 8 Jul 2020 11:56:00 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 08 Jul 2020 11:56:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=q JIs5yJ/DO5VvSDUJMPhkevLdr8xD2Gka6a4h3AtaOU=; b=FahdSKJTnsv1BENEO Z1JBmGP9+Q9Fabvh6jzBi+oCCgZ7zLzAd/A5ftPKpLad0wpRKRnUVubxtvhAY2+J rhAm4f4BVwIA2My4gY7AiPycE2y8hUP8JyLkbgtvrHusXNHS3KunTJ4UI5GpyLle H07z2YqxDc10xWoPtH+GE6P6tsZzd/x2Bu/PvH8zQS9z4ZDTQQoe4MTaD983Y0tr MK683v5BZRPk/npZp+jWl/AhtWOC/daI0KDPAbBUgNKqaWe7A0fb1BFMWESIHRol vtoUmTCbVYhoNu6rwR8EJi2RzdD9Ar27w1OQoHATOyj78llh+vfDfNbAHTePW/7Q w0efA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=qJIs5yJ/DO5VvSDUJMPhkevLdr8xD2Gka6a4h3Ata OU=; b=iZd+xR1/KFD909N11fvNsWg8oCbzfnmNfhz20Yi7b9HTXqVIY7aUBKZkV Ht1tJ4Cy52lUTXsZDmkHzINZdbHqhba37nnGRLgUmifTHH8+ZGzgewdAo1FB3ktD DJsRg0t2SXGnEs1Kfvz0bx3ee6/s80Ho+iw1/BYfcM/XuIW0sZmq704k83V/35pz 2Uf6e672LzWF3x+EO+CwLYcKAOmbV2nevPY2XADMWHzaZIcPjfQ/h6VCkYmTJmrJ ChN27zHGrhJGpPYRrSeJOCsCHQ+T6uWd1tAfQa/4h83Zs293HJU2lqrbNpomrL7r MFYdv46/gjgz5AASJ7Yq+w1Vx80TA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnhepfeduhffgtefgtedvvdffiedutdekffegvdejjedtieehfefgleefuedtledv gffgnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrd ekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr lhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.84]) by mail.messagingengine.com (Postfix) with ESMTPA id 5541E3280060; Wed, 8 Jul 2020 11:55:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\)) From: Alissa Cooper In-Reply-To: <159378297136.10528.6876563537109608281@ietfa.amsl.com> Date: Wed, 8 Jul 2020 11:55:58 -0400 Cc: gen-art@ietf.org, rtg-ads@ietf.org, last-call@ietf.org, tcpm@ietf.org, draft-ietf-tcpm-rto-consider.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <047E9975-0F01-4388-9381-12702E888640@cooperw.in> References: <159378297136.10528.6876563537109608281@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3445.9.5) Archived-At: Subject: Re: [tcpm] [Gen-art] Genart telechat review of draft-ietf-tcpm-rto-consider-16 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, 08 Jul 2020 15:56:03 -0000 Stewart, thanks for your review. > On Jul 3, 2020, at 9:29 AM, Stewart Bryant via Datatracker = wrote: >=20 > Reviewer: Stewart Bryant > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-tcpm-rto-consider-16 > Reviewer: Stewart Bryant > Review Date: 2020-07-03 > IETF LC End Date: 2020-06-01 > IESG Telechat date: 2020-07-09 >=20 > Summary: This is a well written document and is much improved over the = previous > version that I reviewed. I thank the author for their work in that = regard. > However I do have one concern that I think the Area Directors need to = consider > carefully. >=20 > Major issues: > Whilst the document has undoubtedly gained consensus in the > transport area, it is not clear whether the other areas that will > be impacted have properly considered the implications > of the text and proactively given their consensus to the text. >=20 > In particular the following text in a BCP may be a burden on = future > protocols, particularly in the routing and OAM spaces, with the = potential > for disagreements in the closing stages of specification approval. >=20 > - The requirements in this document may not be appropriate in all > cases and, therefore, inconsistent deviations and variants may > be necessary (hence the "SHOULD" in the last bullet). However, > inconsistencies MUST be (a) explained and (b) gather consensus. >=20 > It is possible that I am over-reacting but experience tells me = that this > holds the seeds of future disagreements between areas, delays in > publication, and possible re-engineering of what are in practice = perfectly > acceptable implementations. I can see the concern, but given that the key requirement is a SHOULD I = expect there to be flexibility in interpretation. Alissa=20 >=20 > Minor issues: >=20 > None >=20 > Nits/editorial comments: > There is a trivial nits issue in the abstract that the RFC editor = will need > to resolve. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Jul 8 19:58:10 2020 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 D64D23A0D1B; Wed, 8 Jul 2020 19:58:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Yoshifumi Nishida , nsd.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <159426348285.30582.3195996735395117249@ietfa.amsl.com> Date: Wed, 08 Jul 2020 19:58:02 -0700 Archived-At: Subject: [tcpm] Barry Leiba's No Objection on draft-ietf-tcpm-rto-consider-16: (with COMMENT) 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: Thu, 09 Jul 2020 02:58:03 -0000 Barry Leiba has entered the following ballot position for draft-ietf-tcpm-rto-consider-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- — Section 1 — Given that packet loss is routine in best effort networks, loss detection is a crucial activity for many protocols and applications and is generally undertaken for two major reasons: The “given that” doesn’t seem the right introduction to the rest of the sentence. Do you mean, maybe, “Even though”? And “best-effort” should be hyphenated. and is overwhelming some portion of the network path. Data senders can therefore use loss to trigger transmission rate reductions. Or other congestion-avoidance mechanisms, no? For example, real-time applications such as media streaming might reduce the load by changing the tradeoff between quality and data size/bandwidth usage. Many protocols and applications use their own time-based loss detection mechanisms (e.g., TCP [RFC6298], SCTP [RFC4960], SIP [RFC3261]). Nit: this reads as if it’s saying that TCP, SCTP, and SIP are loss detection mechanisms. The examples should be more closely attached to what they’re examples of (protocols and applications). I suggest this: NEW Many protocols and applications, such as TCP [RFC6298], SCTP [RFC4960], and SIP [RFC3261], use their own time-based loss detection mechanisms. END — Section 2 — requirements document---because we had no idea how to write such a document! You might note the comment at the bottom of this page: https://en.m.wikipedia.org/wiki/Talk:Exclamation_mark#Multiple_exclamation_marks!!! — Section 4 — Often measuring the time required for delivery confirmation is is framed as assessing the "round-trip time (RTT)" of the network path as this is the minimum amount of time required to receive delivery confirmation and also often follows protocol behavior whereby acknowledgments are generated quickly after data arrives. This is an awkward sentence with at least two errors in it (a missing comma and a duplicate word). The awkwardness makes the antecedent to “this” in the following sentence unclear. I suggest rewording this sentence, perhaps as two sentences. I’ll also note that the antecedent to “this” two sentences down (“However, this is somewhat mis-leading”) is completely missing, so please have a fresh look at the whole paragraph. (a) If/when available, the RTO SHOULD be set based on multiple observations of the FT. If/when *what* is available? Do you mean, “Whenever possible”? Some protocols use non-data exchanges for various reasons---e.g., keepalives, heartbeats, control messages. Again, the examples are detached from what they’re examples of, so it looks as if they are examples of reasons, rather than of non-data exchanges. Please re-order the sentence. — Section 5 — mechanisms for many years seemingly without large scale problems Nit: hyphenate “large-scale”. Also in the last sentence of the same paragraph. Further, a number of implementations use a steady-state minimum RTO that are less than the 1 second specified Nit: make it “that is less” to match the singular subject. From nobody Thu Jul 9 02:57:28 2020 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 6AD363A00C0; Thu, 9 Jul 2020 02:57:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Yoshifumi Nishida , nsd.ietf@gmail.com, wes@mti-systems.com X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <159428864593.9289.6371515441778686606@ietfa.amsl.com> Date: Thu, 09 Jul 2020 02:57:26 -0700 Archived-At: Subject: [tcpm] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-tcpm-rto-consider-16=3A_=28with_COMMENT=29?= 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: Thu, 09 Jul 2020 09:57:27 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-tcpm-rto-consider-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please address the minor points of the IoT directorate review by Wesley Eddy (in cc): https://mailarchive.ietf.org/arch/msg/iot-directorate/KGPrkW0KJeW__Bf8gWaOXk0d4FY -éric From nobody Thu Jul 9 08:17:17 2020 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 4ADF63A0C7F; Thu, 9 Jul 2020 08:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe67uIJccFZI; Thu, 9 Jul 2020 08:17:07 -0700 (PDT) Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 E602A3A0C5C; Thu, 9 Jul 2020 08:17:06 -0700 (PDT) Received: by mail-il1-x143.google.com with SMTP id x9so2350897ila.3; Thu, 09 Jul 2020 08:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wHgcOFZp/0+hokMulVfI9GXx93w/3EIIYD2qDMFT2Bk=; b=qQ+Y5+TC5KYyt/VaMKGEfYUlFIQEpE9cPvUBvGFZPiQxuTATpjKWGEprm+UPaOUb1q Inb8K1wmLuvyYU3c0hOWjc73qkwjAodiWJeXk7liHH00XN9QGO0Y/hL89TLj0c5bMHE9 CZ1Gynya9kRnOfbZjFjwhgZJnqnQa+RDgimEZbchM+FhcjLHGaetofIbvOTflLxcVhjd Z7L82VB5jJfzrajngsdHd5vn06x+i7/xZmKN080WCe0QzUrcAdeb3Hd7bsSAjeavWJ6j kTJ+3pNnnWJJmUl3LD5R3CeVoKveRQYCUvV2KCV54VOKgp6BW4twZr6xES+RIQdq9hVo lDSw== 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=wHgcOFZp/0+hokMulVfI9GXx93w/3EIIYD2qDMFT2Bk=; b=ZR/VMFRYgwQuZhCroU6XfCch7FfShnQjyrRpYO7r4b/MCjPeypSFHmgct43Zgq202e iY1a9q1ETS5ZU/BIe32pbDAvcPBpXtzwYEUh2yxKKK3LlhZJVrGg7JHPvSicCYa8V2NZ 41YWao6jQvO2Yhlz9z/k+HivnWtKhgQXHcqEgSEAyuxTc/aW8QEo7fNHQ4AEGLAakSoy LTXOiN4UGdu4G0PPapWbDDVrbSV+PdaKp6TdXNWHEZCz+CD8GVT5CAnujeQwdnmTIonk g2GuUzO7lfSpzj9A/dDgVBFFns7LE5rvJuv32bjehb5IXYFRSo9MDdFNnacgj8K4Rclj pThQ== X-Gm-Message-State: AOAM533UUMwsGyR5sHeDa6p68F6U3L5J7SGavuxSrfjgvh54kvOasuXf iSEXXh4+G/pBY02COUKZimwtbEHgGHs80PrR2o0= X-Google-Smtp-Source: ABdhPJyBfQYrQhibQuULEeIPcGTPVQjIO34BQ0GF1w8LNPJXWVjOwylNVmiDzjrWd/sSs0fAZZeiTLaCTrSymCad3E8= X-Received: by 2002:a92:a196:: with SMTP id b22mr17239679ill.303.1594307826039; Thu, 09 Jul 2020 08:17:06 -0700 (PDT) MIME-Version: 1.0 References: <159406496706.24848.1574717471798101163@ietfa.amsl.com> <97326820-187D-4A67-BBF0-CC58FAF18F0B@icsi.berkeley.edu> In-Reply-To: <97326820-187D-4A67-BBF0-CC58FAF18F0B@icsi.berkeley.edu> From: Martin Duke Date: Thu, 9 Jul 2020 08:16:56 -0700 Message-ID: To: Mark Allman Cc: Benjamin Kaduk , "tcpm@ietf.org Extensions" , The IESG , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs Content-Type: multipart/alternative; boundary="000000000000a2424905aa03b787" Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT) 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, 09 Jul 2020 15:17:12 -0000 --000000000000a2424905aa03b787 Content-Type: text/plain; charset="UTF-8" Benjamin and I discussed this briefly in the telechat. I would summarize as follows: - We seem to have clear agreement on all but the first DISCUSS point - We should probably say something about the security implications of spoofed acks but not be too specific. The document doesn't really have a section (that I can find right now) that discusses the properties of ACKs, so perhaps the best place to put this is in security considerations. Something to the effect of "An attacker could spoof a sufficient number of receiver messages to either alter the feedback time calculation, or indicate the receipt of packets that did not actually arrive at the receiver. Endpoints SHOULD include measures to make it hard for off-path attackers to guess the fields of these packets to mitigate this attack" Together with the agreed fixes, this should be enough to move forward. Martin On Tue, Jul 7, 2020 at 8:01 AM Mark Allman wrote: > > Hi Benjamin! > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > If we are providing BCP-level requirements for time-based loss > > detection via absence of protocol-level acknowledgment, for new > > protocols, it seems appropriate to mandate that the acknowledgment > > signal is reliable, i.e., not spoofable by at least an off-path > > attacker, and ideally not spoofable by an on-path attacker either. > > I would love for this to be a cryptographically protected > > mechanism, but expect that I can't get away with mandating > > something that strong, and that something with "enough bits of > > entropy" will suffice. (I'd prefer "enough" to be 128 but could > > perhaps be persuaded that a lower value is appropriate as a > > minimum requirement.) > > I have been thinking about this since yesterday and have a few > thoughts ... > > - In some sense, I like the general thought. It would tighten > things up. > > - That said, pragmatically, I think the risk from spoofed ACKs is > pretty small. For instance, if you want to screw up the RTO you > need to pretty continuously screw up the FT measurements for > anything long running. So, it isn't enough to guess and inject > correctly once, but you have to do so on an ongoing basis. And, > with much less than 128 bits of entropy something like TCP is > not particularly susceptible to this sort of thing. > > - And, so we can obviously make up a requirement for future > protocols here, but I don't think that will be a "BCP" or even > "CP". It would not be like the rest of the document where the > aspects of loss detection are well understood. > > - And, we'd have to decide what we meant by "new protocol". Is > that some wholly new thing or is that a new algorithm for SCTP > or TCP or DNS? > > - Perhaps there is some non-normative note that could be added > that folks are encouraged to think about making the feedback > non-spoofable for FT measurements (among many other reasons, of > course). I dunno ... > > > Point S.3 in Section 3 indicates that "[t]he requirements in this > > document apply only to endpoint-to- endpoint unicast > > communication. Reliable multicast (e.g., [RFC5740]) protocols are > > explicitly outside the scope of this document." This limitation > > of scope should be reflected in the document's title, Abstract, > > and Introduction. > > (A note can be added.) > > > I would also like to get an explicit confirmation that the various > > (non-)requirements on the details of exponential backoff and > > reduced weighting for old FT samples are as-intended (see > > COMMENT). Specifically, are there limitations on the base of the > > exponent for the exponential backoff, and is there a requirement > > to give more recent FT samples more precedence than older FT > > samples when computing an RTO estimate? > > Yes- the intent is to not specify the details. The basic gist of > the document is that we have learned that the details are not hugely > important and so getting away from them is fine. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Abstract > > > > of congestion along a network path). While many mechanisms have > > been designed to detect loss, protocols ultimately can only count on > > the passage of time without delivery confirmation to declare a > > packet "lost". Each implementation of a time-based loss detection > > > > I'm not entirely convinced that the literal meaning of what these > > words say is universally true for all protocols (specifically "can > > only count on" and omitting a qualifier such as "many" or "most" > > protocols or "reliably count on"). Consider, for example, the DTN > > bundle protocol, which has some circumstances in which a given > > store-and-forward node will flat-out not attempt to forward a > > protocol onward to its final recipient, but can send back a status > > report to the sender noting the confirmed lack of delivery. I > > suggest adding some form of qualifier to admit the possibility of > > such unusual situations. > > > > Section 1 > > > > missing. However, despite our best intentions and most robust > > mechanisms we cannot place ultimate faith in receiving such > > acknowledgments, but can only truly depend on the passage of time. > > Therefore, our ultimate backstop to ensuring that we detect all loss > > is a timeout. [...] > > > > Despite the superficial similarity of tone, a strict reading of > > these words does not seem to share the issue I raised about the > > Abstract. (That said, this phrasing still seems a bit overblown > > and my personal preference would be to tone it down some.) > > The point is objectively true and actually meant to be absolute. > Yes, an explicit non-delivery notification can be sent. Such > notifications may be useful and even quite important. But, > ultimately, we cannot be rely upon such things to ensure reliable > communications because they themselves may get lost, corrupted, > delayed, etc. But, if time somehow stops marching forward then > .... well, WGAS about the packets?! :) > > Too me this is a crucial protocol building touchstone. One has to > think about what we can and cannot count on. And to what degree. > > > Section 2 > > > > - This document does not update or obsolete any existing RFC. > > These previous specifications---while generally consistent with > > the requirements in this document---reflect community consensus > > and this document does not change that consensus. > > > > - The requirements in this document are meant to provide for > > network safety and, as such, SHOULD be used by all time-based > > loss detection mechanisms. > > > > I'm not sure that I understand how the combinations of these two > > statements apply to existing specifications. Is there some sense that > > existing specs might leave some flexibility and when there is such > > flexibility, implementations/deployments SHOULD use the flexibility to > > match this document as closely as possible? Or are existing deployments > > and implementations of existing RFCs also grandfathered out? If the > > intent of the second bullet is to only apply to new protocols, please > > say so explicitly. (Section 4 seems to imply the "only new protocols" > > case, but it's hard to be sure.) > > The first bullet is intended to be backwards looking and the second > bullet is intended to be forward looking. A few extra words there > to make the second bullet more clear would be (in hindsight!) > useful. > > > - The requirements in this document may not be appropriate in all > > cases and, therefore, inconsistent deviations and variants may > > be necessary (hence the "SHOULD" in the last bullet). However, > > inconsistencies MUST be (a) explained and (b) gather consensus. > > > > Similarly, is this statement only forward-looking? Presumably the first > > bullet ("does not update or obsolete any existing") trumps this one, but > > it's good to be clear. > > Yes- forward looking. Clarifying words to be added. > > > Additionally, I share the GenART reviewer's unease with this > > strong of a requirement and have low confidence that the IETF will > > reliably adhere to it in the future. > > In fairness to Stewart---even though I disagree with him---I think > his point is broader than just non-adherence. (Stewart and I have > iterated on his comments and in fact a number of his LC comments > made the document better. But, on this point we just fundamentally > disagreed.) > > I don't presume to speak for Stewart, but I believe he fears this > will become a touchstone for area-on-area warfare whereby perfectly > justifiable deviations won't be well understood as "perfectly > justifiable" by folks not intimate with the given context. And, > this will in turn hold things up. And, he seems especially > concerned about cases where we want to update something that has > been used forever and, yet, deviates from rto-consider. > > My take is three-fold ... > > - First, this statement in rto-consider really doesn't change > anything, IMO. If we're not explaining why we're doing things > and not getting consensus then we shouldn't be publishing it. > > - Second, this explicit statement was added to get WG consensus. > Removing it or softening it would, I believe, run counter to the > consensus the document has already gathered. > > - Third, IMO, saying a given mechanism has proven to be fine in a > given context should really be enough justification. That is, > yeah, I can see that some protocol lawyer could be pedantic. > And, that might be annoying, I guess. But, I think reasonable > people should be able to form a consensus that rebuts such > things. > > > Section 3 > > > > (S.1) The requirements in this document apply only to the primary or > > last resort time-based loss detection. > > > > I'm not sure I understand what "primary or last resort [sic]" means. > > Are there time-based loss-detection mechanisms that are neither primary > > nor last resort? (nit: hyphenate "last-resort" as a compound adjective, > > and many other compound adjectives throughout.) > > (May also affect S.2.) > > I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary > > non-last-resort schemes, however, I think we should be more clear about > > what we mean when we introduce the term and why we exclude certain > > classes of time-based loss-detection mechanisms. > > > > detectors. However, these mechanisms do not obviate the need > > for a "retransmission timeout" or "RTO" because---as we > > discuss in Section 1---only the passage of time can ultimately > > be relied upon to detect loss. In cases such as these, the > > > > [This text is more like the Abstract's, implying that the passage of > > time is the only way to detect loss, universally] > > I dunno. I would have to think about this a bit. As you say, we > tried to sprinkle in references to non-last-resort timers. Perhaps > there are some words we can add here to explain things better. > You're the first one to trip on this. But, I'd be happy to go > through this text and think about it again. > > > Section 4 > > > > In other words, the RTO should represent an empirically- > > derived reasonable amount of time that the sender should > > wait for delivery confirmation before deciding the given > > data is lost. Network paths are inherently dynamic and > > therefore it is crucial to incorporate multiple FT samples > > in the RTO to take into account the delay variation across > > time. > > > > It feels weird to say that the delay will vary over time here but say > > nothing about the corresponding need to discount very old FT samples. > > Point (b) talks about adding new samples in, but not about removing or > > discounting old samples. That the TCP example does exhibit this > > property does not excuse a lack of explicit mention as a property of > > note. > > I think a note that says "it's fine to discount old samples" is OK > and perfectly within the spirit of the guideline. I don't want to > overly specify that one has to do this. > > > (d) An RTO mechanism MUST NOT use ambiguous FT samples. > > > > Assume two copies of some segment X are transmitted at times > > t0 and t1 and then at time t2 the sender receives > > confirmation that X in fact arrived. In some cases, it is > > > > "segment" feels like use of TCP-specific terminology without disclaimer > > or generalization. > > (I can change this to 'packet'.) > > > (3) Loss detected by the RTO mechanism MUST be taken as an > > indication of network congestion and the sending rate adapted > > using a standard mechanism (e.g., TCP collapses the congestion > > window to one segment [RFC5681]). > > [...] > > An exception to this rule is if an IETF standardized mechanism > > determines that a particular loss is due to a non-congestion > > event (e.g., packet corruption). In such a case a congestion > > > > If it's a MUST with an exception, doesn't that make it ... no longer a > > MUST? > > I don't think so. But, you're no doubt a better protocol lawyer > than I am. I believe this says you really have to do this, but > there is a **very precise way** to get out of it. If we made this a > SHOULD then it would be very much looser---i.e., you really ought to > do this unless you have a good reason. Here we are telling you what > the good reason has to look like. > > > (4) Each time the RTO is used to detect a loss, the value of the RTO > > MUST be exponentially backed off such that the next firing > > requires a longer interval. [...] > > > > Do we expect this to be exponential backoff by doubling, or is it > > admissible to use an alternative base for the exponent? (Is there > > a minimum allowable value? E.g., 1.000001 does not seem like it > > would provide much protection for the network.) > > The document does not say to double the RTO. It means to not > specify the constant. > > Again, the document is meant to get away from specifics where we > can. I don't know how to set the minimal acceptable backoff. I > think we'd all agree 1.000001 is not really going to cut it. But, > would 1.8? How about 1.7? What about 1.3? I believe the consensus > is that "exponential backoff" is enough. > > > Further, a number of implementations use a steady-state minimum RTO > > that are less than the 1 second specified in [RFC6298] (which is > > different from the initial RTO we specify in Section 4, Requirement > > 1). While the implication of these deviations from the standard may > > > > Just to check: our requirement 1 is the same as RFC 6298, and the "less > > than 1 second" is what's different. Perhaps wording this akin to "and > > as such is in violation of the RTO specified in Requirement 1 from > > Section 4" would avoid the ambiguity about what is different from what. > > Well. Um. I read it many times, but cannot understand what you > wrote about the document's ambiguity! ;-) Maybe that is my lack of > coffee, I dunno. But, let me try anyway ... > > RFC 6298 says the INITIAL RTO should be no less than 1sec. That > agrees with rto-consider (requirement 1). > > RFC 6298 further says the MINIMUM RTO over the entire lifetime of a > TCP connection should be no less than 1sec. There is no > corresponding admonishment in rto-consider. > > Probably because these two things are both "1sec" in TCP a lot of > people have gotten them mixed up in their minds during the > development of this document. The parenthetical you quote was no > doubt meant to clarify to someone. But, this discussion can be > cleaned up, probably. > > > Section 6 > > > > Noting that we incorporate the security considerations of RFC 6298 > > by reference, and quoting from there: > > > > In addition, even if the attacker can cause the sender's RTO to reach > > too small a value, it appears the attacker cannot leverage this into > > much of an attack (compared to the other damage they can do if they > > can spoof packets belonging to the connection), since the sending TCP > > will still back off its timer in the face of an incorrectly > > transmitted packet's loss due to actual congestion. > > > > Just to check my understanding: this "actual congestion" would > > need to be between the sender and the attacker, right? Since the > > attacker's spoofed ACKs would cause the sender to not detect loss > > due to congestion that occurs between the attacker and the > > intended recipient. > > Oh boy. My brain is thrashing to try to page back in RFC6298. > > The above text isn't the most clear, so I assume I didn't write > it. :) > > Hmm. > > I think the basic point is that if an attacker can spoof they can do > much worse than impacting the computation of the RTO. And, if what > they want to do is mess with a connection's performance and not the > reliability of the connection---say because that'd be > user-visible---then they cannot hide real losses. And, since they > cannot hide real losses then from a network safety perspective this > all fails safely because the endpoint will backoff when detecting > those losses. > > > References > > > > The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6298]") > > implies that it should be categorized as normative. Similarly for RFC > > 6298 itself. > > I dunno. The entirety of the algorithm is given in rto-consider. > So, the reference is really meant to give credit and point people at > a place to read about it in more detail instead of as a pointer that > must be understood to enact the guideline. Perhaps just a > restructuring ... > > Therefore, in this situation an implementation MUST use Karn's > algorithm and use neither version of the FT sample and hence not > update the RTO (see [KP87,RFC6298] for a broader discussion of > Karn's algorithm). > > Or, put them under "Normative". I really don't much care. > > > [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC > > 2134, June 2001. > > > > Fix the typo, please -- RFC 2134 is the articles of incorporation of > > ISOC. > > Well, I do not want to be anywhere near ISOC anything! Good catch, > thanks! (And, what a weird typo ... all the digits are there, but > in such a weird order ...) > > allman > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm > --000000000000a2424905aa03b787 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Benjamin and I discussed this briefly in the telechat. I w= ould summarize as follows:

- We seem to have clear agree= ment on all but the first DISCUSS point
- We should probably say = something about the security implications of spoofed acks but not be too sp= ecific. The document doesn't really have a section (that I can find rig= ht now) that discusses the properties of ACKs, so perhaps the best place to= put this is in security considerations. Something to the effect of=C2=A0

"An attacker could spoof a sufficient number o= f receiver messages to either alter the feedback time calculation, or indic= ate the receipt of packets that did not actually arrive at the receiver. En= dpoints SHOULD include measures to make it hard for off-path attackers to g= uess the fields of these packets to mitigate this attack"
Together with the agreed fixes, this should be enough to move = forward.

Martin

On Tue, Jul 7, 2020 at 8:01 A= M Mark Allman <mallman@icsi= .berkeley.edu> wrote:

Hi Benjamin!

> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> If we are providing BCP-level requirements for time-based loss
> detection via absence of protocol-level acknowledgment, for new
> protocols, it seems appropriate to mandate that the acknowledgment
> signal is reliable, i.e., not spoofable by at least an off-path
> attacker, and ideally not spoofable by an on-path attacker either.
> I would love for this to be a cryptographically protected
> mechanism, but expect that I can't get away with mandating
> something that strong, and that something with "enough bits of > entropy" will suffice.=C2=A0 (I'd prefer "enough" t= o be 128 but could
> perhaps be persuaded that a lower value is appropriate as a
> minimum requirement.)

I have been thinking about this since yesterday and have a few
thoughts ...

=C2=A0 - In some sense, I like the general thought.=C2=A0 It would tighten<= br> =C2=A0 =C2=A0 things up.

=C2=A0 - That said, pragmatically, I think the risk from spoofed ACKs is =C2=A0 =C2=A0 pretty small.=C2=A0 For instance, if you want to screw up the= RTO you
=C2=A0 =C2=A0 need to pretty continuously screw up the FT measurements for<= br> =C2=A0 =C2=A0 anything long running.=C2=A0 So, it isn't enough to guess= and inject
=C2=A0 =C2=A0 correctly once, but you have to do so on an ongoing basis.=C2= =A0 And,
=C2=A0 =C2=A0 with much less than 128 bits of entropy something like TCP is=
=C2=A0 =C2=A0 not particularly susceptible to this sort of thing.

=C2=A0 - And, so we can obviously make up a requirement for future
=C2=A0 =C2=A0 protocols here, but I don't think that will be a "BC= P" or even
=C2=A0 =C2=A0 "CP".=C2=A0 It would not be like the rest of the do= cument where the
=C2=A0 =C2=A0 aspects of loss detection are well understood.

=C2=A0 - And, we'd have to decide what we meant by "new protocol&q= uot;.=C2=A0 Is
=C2=A0 =C2=A0 that some wholly new thing or is that a new algorithm for SCT= P
=C2=A0 =C2=A0 or TCP or DNS?

=C2=A0 - Perhaps there is some non-normative note that could be added
=C2=A0 =C2=A0 that folks are encouraged to think about making the feedback<= br> =C2=A0 =C2=A0 non-spoofable for FT measurements (among many other reasons, = of
=C2=A0 =C2=A0 course).=C2=A0 I dunno ...

> Point S.3 in Section 3 indicates that "[t]he requirements in this=
> document apply only to endpoint-to- endpoint unicast
> communication.=C2=A0 Reliable multicast (e.g., [RFC5740]) protocols ar= e
> explicitly outside the scope of this document."=C2=A0 This limita= tion
> of scope should be reflected in the document's title, Abstract, > and Introduction.

(A note can be added.)

> I would also like to get an explicit confirmation that the various
> (non-)requirements on the details of exponential backoff and
> reduced weighting for old FT samples are as-intended (see
> COMMENT).=C2=A0 Specifically, are there limitations on the base of the=
> exponent for the exponential backoff, and is there a requirement
> to give more recent FT samples more precedence than older FT
> samples when computing an RTO estimate?

Yes- the intent is to not specify the details.=C2=A0 The basic gist of
the document is that we have learned that the details are not hugely
important and so getting away from them is fine.

> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Abstract
>
>=C2=A0 =C2=A0 =C2=A0of congestion along a network path).=C2=A0 While ma= ny mechanisms have
>=C2=A0 =C2=A0 =C2=A0been designed to detect loss, protocols ultimately = can only count on
>=C2=A0 =C2=A0 =C2=A0the passage of time without delivery confirmation t= o declare a
>=C2=A0 =C2=A0 =C2=A0packet "lost".=C2=A0 Each implementation = of a time-based loss detection
>
> I'm not entirely convinced that the literal meaning of what these<= br> > words say is universally true for all protocols (specifically "ca= n
> only count on" and omitting a qualifier such as "many" = or "most"
> protocols or "reliably count on").=C2=A0 Consider, for examp= le, the DTN
> bundle protocol, which has some circumstances in which a given
> store-and-forward node will flat-out not attempt to forward a
> protocol onward to its final recipient, but can send back a status
> report to the sender noting the confirmed lack of delivery.=C2=A0 I > suggest adding some form of qualifier to admit the possibility of
> such unusual situations.
>
> Section 1
>
>=C2=A0 =C2=A0 =C2=A0missing.=C2=A0 However, despite our best intentions= and most robust
>=C2=A0 =C2=A0 =C2=A0mechanisms we cannot place ultimate faith in receiv= ing such
>=C2=A0 =C2=A0 =C2=A0acknowledgments, but can only truly depend on the p= assage of time.
>=C2=A0 =C2=A0 =C2=A0Therefore, our ultimate backstop to ensuring that w= e detect all loss
>=C2=A0 =C2=A0 =C2=A0is a timeout.=C2=A0 [...]
>
> Despite the superficial similarity of tone, a strict reading of
> these words does not seem to share the issue I raised about the
> Abstract.=C2=A0 (That said, this phrasing still seems a bit overblown<= br> > and my personal preference would be to tone it down some.)

The point is objectively true and actually meant to be absolute.
Yes, an explicit non-delivery notification can be sent.=C2=A0 Such
notifications may be useful and even quite important.=C2=A0 But,
ultimately, we cannot be rely upon such things to ensure reliable
communications because they themselves may get lost, corrupted,
delayed, etc.=C2=A0 But, if time somehow stops marching forward then
.... well, WGAS about the packets?! :)

Too me this is a crucial protocol building touchstone.=C2=A0 One has to
think about what we can and cannot count on.=C2=A0 And to what degree.

> Section 2
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- This document does not update or obsolete = any existing RFC.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0These previous specifications---while= generally consistent with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the requirements in this document---r= eflect community consensus
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and this document does not change tha= t consensus.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- The requirements in this document are mean= t to provide for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0network safety and, as such, SHOULD b= e used by all time-based
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loss detection mechanisms.
>
> I'm not sure that I understand how the combinations of these two > statements apply to existing specifications.=C2=A0 Is there some sense= that
> existing specs might leave some flexibility and when there is such
> flexibility, implementations/deployments SHOULD use the flexibility to=
> match this document as closely as possible?=C2=A0 Or are existing depl= oyments
> and implementations of existing RFCs also grandfathered out?=C2=A0 If = the
> intent of the second bullet is to only apply to new protocols, please<= br> > say so explicitly.=C2=A0 (Section 4 seems to imply the "only new = protocols"
> case, but it's hard to be sure.)

The first bullet is intended to be backwards looking and the second
bullet is intended to be forward looking.=C2=A0 A few extra words there
to make the second bullet more clear would be (in hindsight!)
useful.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0- The requirements in this document may not = be appropriate in all
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cases and, therefore, inconsistent de= viations and variants may
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be necessary (hence the "SHOULD&= quot; in the last bullet).=C2=A0 However,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inconsistencies MUST be (a) explained= and (b) gather consensus.
>
> Similarly, is this statement only forward-looking?=C2=A0 Presumably th= e first
> bullet ("does not update or obsolete any existing") trumps t= his one, but
> it's good to be clear.

Yes- forward looking.=C2=A0 Clarifying words to be added.

> Additionally, I share the GenART reviewer's unease with this
> strong of a requirement and have low confidence that the IETF will
> reliably adhere to it in the future.

In fairness to Stewart---even though I disagree with him---I think
his point is broader than just non-adherence.=C2=A0 (Stewart and I have
iterated on his comments and in fact a number of his LC comments
made the document better.=C2=A0 But, on this point we just fundamentally disagreed.)

I don't presume to speak for Stewart, but I believe he fears this
will become a touchstone for area-on-area warfare whereby perfectly
justifiable deviations won't be well understood as "perfectly
justifiable" by folks not intimate with the given context.=C2=A0 And,<= br> this will in turn hold things up.=C2=A0 And, he seems especially
concerned about cases where we want to update something that has
been used forever and, yet, deviates from rto-consider.

My take is three-fold ...

=C2=A0 - First, this statement in rto-consider really doesn't change =C2=A0 =C2=A0 anything, IMO.=C2=A0 If we're not explaining why we'r= e doing things
=C2=A0 =C2=A0 and not getting consensus then we shouldn't be publishing= it.

=C2=A0 - Second, this explicit statement was added to get WG consensus.
=C2=A0 =C2=A0 Removing it or softening it would, I believe, run counter to = the
=C2=A0 =C2=A0 consensus the document has already gathered.

=C2=A0 - Third, IMO, saying a given mechanism has proven to be fine in a =C2=A0 =C2=A0 given context should really be enough justification.=C2=A0 Th= at is,
=C2=A0 =C2=A0 yeah, I can see that some protocol lawyer could be pedantic.<= br> =C2=A0 =C2=A0 And, that might be annoying, I guess.=C2=A0 But, I think reas= onable
=C2=A0 =C2=A0 people should be able to form a consensus that rebuts such =C2=A0 =C2=A0 things.

> Section 3
>
>=C2=A0 =C2=A0 =C2=A0(S.1) The requirements in this document apply only = to the primary or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0last resort time-based loss de= tection.
>
> I'm not sure I understand what "primary or last resort [sic]&= quot; means.
> Are there time-based loss-detection mechanisms that are neither primar= y
> nor last resort?=C2=A0 (nit: hyphenate "last-resort" as a co= mpound adjective,
> and many other compound adjectives throughout.)
> (May also affect S.2.)
> I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary
> non-last-resort schemes, however, I think we should be more clear abou= t
> what we mean when we introduce the term and why we exclude certain
> classes of time-based loss-detection mechanisms.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0detectors.=C2=A0 However, thes= e mechanisms do not obviate the need
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for a "retransmission tim= eout" or "RTO" because---as we
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discuss in Section 1---only th= e passage of time can ultimately
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be relied upon to detect loss.= =C2=A0 In cases such as these, the
>
> [This text is more like the Abstract's, implying that the passage = of
> time is the only way to detect loss, universally]

I dunno.=C2=A0 I would have to think about this a bit.=C2=A0 As you say, we=
tried to sprinkle in references to non-last-resort timers.=C2=A0 Perhaps there are some words we can add here to explain things better.
You're the first one to trip on this.=C2=A0 But, I'd be happy to go=
through this text and think about it again.

> Section 4
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In other words, the RTO= should represent an empirically-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0derived reasonable amou= nt of time that the sender should
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wait for delivery confi= rmation before deciding the given
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0data is lost.=C2=A0 Net= work paths are inherently dynamic and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0therefore it is crucial= to incorporate multiple FT samples
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the RTO to take into= account the delay variation across
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0time.
>
> It feels weird to say that the delay will vary over time here but say<= br> > nothing about the corresponding need to discount very old FT samples.<= br> > Point (b) talks about adding new samples in, but not about removing or=
> discounting old samples.=C2=A0 That the TCP example does exhibit this<= br> > property does not excuse a lack of explicit mention as a property of > note.

I think a note that says "it's fine to discount old samples" = is OK
and perfectly within the spirit of the guideline.=C2=A0 I don't want to=
overly specify that one has to do this.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(d) An RTO mechanism MUST NOT use amb= iguous FT samples.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Assume two copies of so= me segment X are transmitted at times
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t0 and t1 and then at t= ime t2 the sender receives
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0confirmation that X in = fact arrived.=C2=A0 In some cases, it is
>
> "segment" feels like use of TCP-specific terminology without= disclaimer
> or generalization.

(I can change this to 'packet'.)

>=C2=A0 =C2=A0 =C2=A0(3) Loss detected by the RTO mechanism MUST be take= n as an
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0indication of network congestion and = the sending rate adapted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using a standard mechanism (e.g., TCP= collapses the congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0window to one segment [RFC5681]).
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[...]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0An exception to this rule is if an IE= TF standardized mechanism
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0determines that a particular loss is = due to a non-congestion
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0event (e.g., packet corruption).=C2= =A0 In such a case a congestion
>
> If it's a MUST with an exception, doesn't that make it ... no = longer a
> MUST?

I don't think so.=C2=A0 But, you're no doubt a better protocol lawy= er
than I am.=C2=A0 I believe this says you really have to do this, but
there is a **very precise way** to get out of it.=C2=A0 If we made this a SHOULD then it would be very much looser---i.e., you really ought to
do this unless you have a good reason.=C2=A0 Here we are telling you what the good reason has to look like.

>=C2=A0 =C2=A0 =C2=A0(4) Each time the RTO is used to detect a loss, the= value of the RTO
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be exponentially backed off such= that the next firing
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requires a longer interval.=C2=A0 [..= .]
>
> Do we expect this to be exponential backoff by doubling, or is it
> admissible to use an alternative base for the exponent?=C2=A0 (Is ther= e
> a minimum allowable value?=C2=A0 E.g., 1.000001 does not seem like it<= br> > would provide much protection for the network.)

The document does not say to double the RTO.=C2=A0 It means to not
specify the constant.

Again, the document is meant to get away from specifics where we
can.=C2=A0 I don't know how to set the minimal acceptable backoff.=C2= =A0 I
think we'd all agree 1.000001 is not really going to cut it.=C2=A0 But,=
would 1.8?=C2=A0 How about 1.7?=C2=A0 What about 1.3?=C2=A0 I believe the c= onsensus
is that "exponential backoff" is enough.

>=C2=A0 =C2=A0 =C2=A0Further, a number of implementations use a steady-s= tate minimum RTO
>=C2=A0 =C2=A0 =C2=A0that are less than the 1 second specified in [RFC62= 98] (which is
>=C2=A0 =C2=A0 =C2=A0different from the initial RTO we specify in Sectio= n 4, Requirement
>=C2=A0 =C2=A0 =C2=A01).=C2=A0 While the implication of these deviations= from the standard may
>
> Just to check: our requirement 1 is the same as RFC 6298, and the &quo= t;less
> than 1 second" is what's different.=C2=A0 Perhaps wording thi= s akin to "and
> as such is in violation of the RTO specified in Requirement 1 from
> Section 4" would avoid the ambiguity about what is different from= what.

Well.=C2=A0 Um.=C2=A0 I read it many times, but cannot understand what you<= br> wrote about the document's ambiguity! ;-) Maybe that is my lack of
coffee, I dunno.=C2=A0 But, let me try anyway ...

RFC 6298 says the INITIAL RTO should be no less than 1sec.=C2=A0 That
agrees with rto-consider (requirement 1).

RFC 6298 further says the MINIMUM RTO over the entire lifetime of a
TCP connection should be no less than 1sec.=C2=A0 There is no
corresponding admonishment in rto-consider.

Probably because these two things are both "1sec" in TCP a lot of=
people have gotten them mixed up in their minds during the
development of this document.=C2=A0 The parenthetical you quote was no
doubt meant to clarify to someone.=C2=A0 But, this discussion can be
cleaned up, probably.

> Section 6
>
> Noting that we incorporate the security considerations of RFC 6298
> by reference, and quoting from there:
>
>=C2=A0 =C2=A0 In addition, even if the attacker can cause the sender= 9;s RTO to reach
>=C2=A0 =C2=A0 too small a value, it appears the attacker cannot leverag= e this into
>=C2=A0 =C2=A0 much of an attack (compared to the other damage they can = do if they
>=C2=A0 =C2=A0 can spoof packets belonging to the connection), since the= sending TCP
>=C2=A0 =C2=A0 will still back off its timer in the face of an incorrect= ly
>=C2=A0 =C2=A0 transmitted packet's loss due to actual congestion. >
> Just to check my understanding: this "actual congestion" wou= ld
> need to be between the sender and the attacker, right?=C2=A0 Since the=
> attacker's spoofed ACKs would cause the sender to not detect loss<= br> > due to congestion that occurs between the attacker and the
> intended recipient.

Oh boy.=C2=A0 My brain is thrashing to try to page back in RFC6298.

The above text isn't the most clear, so I assume I didn't write
it. :)

Hmm.

I think the basic point is that if an attacker can spoof they can do
much worse than impacting the computation of the RTO.=C2=A0 And, if what they want to do is mess with a connection's performance and not the
reliability of the connection---say because that'd be
user-visible---then they cannot hide real losses.=C2=A0 And, since they
cannot hide real losses then from a network safety perspective this
all fails safely because the endpoint will backoff when detecting
those losses.

> References
>
> The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6= 298]")
> implies that it should be categorized as normative.=C2=A0 Similarly fo= r RFC
> 6298 itself.

I dunno.=C2=A0 The entirety of the algorithm is given in rto-consider.
So, the reference is really meant to give credit and point people at
a place to read about it in more detail instead of as a pointer that
must be understood to enact the guideline.=C2=A0 Perhaps just a
restructuring ...

=C2=A0 Therefore, in this situation an implementation MUST use Karn's =C2=A0 algorithm and use neither version of the FT sample and hence not
=C2=A0 update the RTO (see [KP87,RFC6298] for a broader discussion of
=C2=A0 Karn's algorithm).

Or, put them under "Normative".=C2=A0 I really don't much car= e.

>=C2=A0 =C2=A0 =C2=A0[RFC3124] Balakrishnan, H., S. Seshan, "The Co= ngestion Manager", RFC
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02134, June 2001.
>
> Fix the typo, please -- RFC 2134 is the articles of incorporation of > ISOC.

Well, I do not want to be anywhere near ISOC anything!=C2=A0 Good catch, thanks!=C2=A0 (And, what a weird typo ... all the digits are there, but
in such a weird order ...)

allman
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm
--000000000000a2424905aa03b787-- From nobody Thu Jul 9 08:55:52 2020 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 17ED73A0EDE; Thu, 9 Jul 2020 08:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 zbm6umHsM3tp; Thu, 9 Jul 2020 08:55:39 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C993A0E3A; Thu, 9 Jul 2020 08:55:15 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 069FtAhQ091574; Thu, 9 Jul 2020 08:55:10 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net) Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 069Ft9fB091573; Thu, 9 Jul 2020 08:55:09 -0700 (PDT) (envelope-from ietf) From: "Rodney W. Grimes" Message-Id: <202007091555.069Ft9fB091573@gndrsh.dnsmgr.net> In-Reply-To: To: Martin Duke Date: Thu, 9 Jul 2020 08:55:09 -0700 (PDT) CC: Mark Allman , tcpm-chairs , "tcpm@ietf.org Extensions" , Benjamin Kaduk , draft-ietf-tcpm-rto-consider@ietf.org, The IESG X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT) 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, 09 Jul 2020 15:55:49 -0000 Martin, Benjamin, etc el: > Benjamin and I discussed this briefly in the telechat. I would summarize as > follows: > > - We seem to have clear agreement on all but the first DISCUSS point > - We should probably say something about the security implications of > spoofed acks but not be too specific. The document doesn't really have a > section (that I can find right now) that discusses the properties of ACKs, > so perhaps the best place to put this is in security considerations. Isn't it a mistake to discuss in "security considerations" a topic that is not in the main body of the document? > Something to the effect of > > "An attacker could spoof a sufficient number of receiver messages to either > alter the feedback time calculation, or indicate the receipt of packets > that did not actually arrive at the receiver. Endpoints SHOULD include > measures to make it hard for off-path attackers to guess the fields of > these packets to mitigate this attack" Such an ambigous statement added without discussion of how one might implment a "measure to make it hard" for an implementer would be a No-op as I have nothing to base what it is I SHOULD do from this document, nor any reference to another document. IMHO, trying to address off-path attacks in this draft is out of scope. The specification of those details should be in the transport protocol itself, not in a generized document such as this, as it is only in those documents that methods to mitigate attacks can reasonably be documented. Perhaps say that "transport protocols SHOULD document techniques for mitigation against attacks that could perturb the estimate of RTT"? But even that is, IMHO, beyond the scope of what this document should be covering as now it is saying what other documents should contain. I understand the desire to say something about the issues of an off path attack, but is this document really the right place to try and address that concern? Regards, Rodney W. Grimes > Together with the agreed fixes, this should be enough to move forward. > > Martin > > On Tue, Jul 7, 2020 at 8:01 AM Mark Allman > wrote: > > > > > Hi Benjamin! > > > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > If we are providing BCP-level requirements for time-based loss > > > detection via absence of protocol-level acknowledgment, for new > > > protocols, it seems appropriate to mandate that the acknowledgment > > > signal is reliable, i.e., not spoofable by at least an off-path > > > attacker, and ideally not spoofable by an on-path attacker either. > > > I would love for this to be a cryptographically protected > > > mechanism, but expect that I can't get away with mandating > > > something that strong, and that something with "enough bits of > > > entropy" will suffice. (I'd prefer "enough" to be 128 but could > > > perhaps be persuaded that a lower value is appropriate as a > > > minimum requirement.) > > > > I have been thinking about this since yesterday and have a few > > thoughts ... > > > > - In some sense, I like the general thought. It would tighten > > things up. > > > > - That said, pragmatically, I think the risk from spoofed ACKs is > > pretty small. For instance, if you want to screw up the RTO you > > need to pretty continuously screw up the FT measurements for > > anything long running. So, it isn't enough to guess and inject > > correctly once, but you have to do so on an ongoing basis. And, > > with much less than 128 bits of entropy something like TCP is > > not particularly susceptible to this sort of thing. > > > > - And, so we can obviously make up a requirement for future > > protocols here, but I don't think that will be a "BCP" or even > > "CP". It would not be like the rest of the document where the > > aspects of loss detection are well understood. > > > > - And, we'd have to decide what we meant by "new protocol". Is > > that some wholly new thing or is that a new algorithm for SCTP > > or TCP or DNS? > > > > - Perhaps there is some non-normative note that could be added > > that folks are encouraged to think about making the feedback > > non-spoofable for FT measurements (among many other reasons, of > > course). I dunno ... > > > > > Point S.3 in Section 3 indicates that "[t]he requirements in this > > > document apply only to endpoint-to- endpoint unicast > > > communication. Reliable multicast (e.g., [RFC5740]) protocols are > > > explicitly outside the scope of this document." This limitation > > > of scope should be reflected in the document's title, Abstract, > > > and Introduction. > > > > (A note can be added.) > > > > > I would also like to get an explicit confirmation that the various > > > (non-)requirements on the details of exponential backoff and > > > reduced weighting for old FT samples are as-intended (see > > > COMMENT). Specifically, are there limitations on the base of the > > > exponent for the exponential backoff, and is there a requirement > > > to give more recent FT samples more precedence than older FT > > > samples when computing an RTO estimate? > > > > Yes- the intent is to not specify the details. The basic gist of > > the document is that we have learned that the details are not hugely > > important and so getting away from them is fine. > > > > > ---------------------------------------------------------------------- > > > COMMENT: > > > ---------------------------------------------------------------------- > > > > > > Abstract > > > > > > of congestion along a network path). While many mechanisms have > > > been designed to detect loss, protocols ultimately can only count on > > > the passage of time without delivery confirmation to declare a > > > packet "lost". Each implementation of a time-based loss detection > > > > > > I'm not entirely convinced that the literal meaning of what these > > > words say is universally true for all protocols (specifically "can > > > only count on" and omitting a qualifier such as "many" or "most" > > > protocols or "reliably count on"). Consider, for example, the DTN > > > bundle protocol, which has some circumstances in which a given > > > store-and-forward node will flat-out not attempt to forward a > > > protocol onward to its final recipient, but can send back a status > > > report to the sender noting the confirmed lack of delivery. I > > > suggest adding some form of qualifier to admit the possibility of > > > such unusual situations. > > > > > > Section 1 > > > > > > missing. However, despite our best intentions and most robust > > > mechanisms we cannot place ultimate faith in receiving such > > > acknowledgments, but can only truly depend on the passage of time. > > > Therefore, our ultimate backstop to ensuring that we detect all loss > > > is a timeout. [...] > > > > > > Despite the superficial similarity of tone, a strict reading of > > > these words does not seem to share the issue I raised about the > > > Abstract. (That said, this phrasing still seems a bit overblown > > > and my personal preference would be to tone it down some.) > > > > The point is objectively true and actually meant to be absolute. > > Yes, an explicit non-delivery notification can be sent. Such > > notifications may be useful and even quite important. But, > > ultimately, we cannot be rely upon such things to ensure reliable > > communications because they themselves may get lost, corrupted, > > delayed, etc. But, if time somehow stops marching forward then > > .... well, WGAS about the packets?! :) > > > > Too me this is a crucial protocol building touchstone. One has to > > think about what we can and cannot count on. And to what degree. > > > > > Section 2 > > > > > > - This document does not update or obsolete any existing RFC. > > > These previous specifications---while generally consistent with > > > the requirements in this document---reflect community consensus > > > and this document does not change that consensus. > > > > > > - The requirements in this document are meant to provide for > > > network safety and, as such, SHOULD be used by all time-based > > > loss detection mechanisms. > > > > > > I'm not sure that I understand how the combinations of these two > > > statements apply to existing specifications. Is there some sense that > > > existing specs might leave some flexibility and when there is such > > > flexibility, implementations/deployments SHOULD use the flexibility to > > > match this document as closely as possible? Or are existing deployments > > > and implementations of existing RFCs also grandfathered out? If the > > > intent of the second bullet is to only apply to new protocols, please > > > say so explicitly. (Section 4 seems to imply the "only new protocols" > > > case, but it's hard to be sure.) > > > > The first bullet is intended to be backwards looking and the second > > bullet is intended to be forward looking. A few extra words there > > to make the second bullet more clear would be (in hindsight!) > > useful. > > > > > - The requirements in this document may not be appropriate in all > > > cases and, therefore, inconsistent deviations and variants may > > > be necessary (hence the "SHOULD" in the last bullet). However, > > > inconsistencies MUST be (a) explained and (b) gather consensus. > > > > > > Similarly, is this statement only forward-looking? Presumably the first > > > bullet ("does not update or obsolete any existing") trumps this one, but > > > it's good to be clear. > > > > Yes- forward looking. Clarifying words to be added. > > > > > Additionally, I share the GenART reviewer's unease with this > > > strong of a requirement and have low confidence that the IETF will > > > reliably adhere to it in the future. > > > > In fairness to Stewart---even though I disagree with him---I think > > his point is broader than just non-adherence. (Stewart and I have > > iterated on his comments and in fact a number of his LC comments > > made the document better. But, on this point we just fundamentally > > disagreed.) > > > > I don't presume to speak for Stewart, but I believe he fears this > > will become a touchstone for area-on-area warfare whereby perfectly > > justifiable deviations won't be well understood as "perfectly > > justifiable" by folks not intimate with the given context. And, > > this will in turn hold things up. And, he seems especially > > concerned about cases where we want to update something that has > > been used forever and, yet, deviates from rto-consider. > > > > My take is three-fold ... > > > > - First, this statement in rto-consider really doesn't change > > anything, IMO. If we're not explaining why we're doing things > > and not getting consensus then we shouldn't be publishing it. > > > > - Second, this explicit statement was added to get WG consensus. > > Removing it or softening it would, I believe, run counter to the > > consensus the document has already gathered. > > > > - Third, IMO, saying a given mechanism has proven to be fine in a > > given context should really be enough justification. That is, > > yeah, I can see that some protocol lawyer could be pedantic. > > And, that might be annoying, I guess. But, I think reasonable > > people should be able to form a consensus that rebuts such > > things. > > > > > Section 3 > > > > > > (S.1) The requirements in this document apply only to the primary or > > > last resort time-based loss detection. > > > > > > I'm not sure I understand what "primary or last resort [sic]" means. > > > Are there time-based loss-detection mechanisms that are neither primary > > > nor last resort? (nit: hyphenate "last-resort" as a compound adjective, > > > and many other compound adjectives throughout.) > > > (May also affect S.2.) > > > I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary > > > non-last-resort schemes, however, I think we should be more clear about > > > what we mean when we introduce the term and why we exclude certain > > > classes of time-based loss-detection mechanisms. > > > > > > detectors. However, these mechanisms do not obviate the need > > > for a "retransmission timeout" or "RTO" because---as we > > > discuss in Section 1---only the passage of time can ultimately > > > be relied upon to detect loss. In cases such as these, the > > > > > > [This text is more like the Abstract's, implying that the passage of > > > time is the only way to detect loss, universally] > > > > I dunno. I would have to think about this a bit. As you say, we > > tried to sprinkle in references to non-last-resort timers. Perhaps > > there are some words we can add here to explain things better. > > You're the first one to trip on this. But, I'd be happy to go > > through this text and think about it again. > > > > > Section 4 > > > > > > In other words, the RTO should represent an empirically- > > > derived reasonable amount of time that the sender should > > > wait for delivery confirmation before deciding the given > > > data is lost. Network paths are inherently dynamic and > > > therefore it is crucial to incorporate multiple FT samples > > > in the RTO to take into account the delay variation across > > > time. > > > > > > It feels weird to say that the delay will vary over time here but say > > > nothing about the corresponding need to discount very old FT samples. > > > Point (b) talks about adding new samples in, but not about removing or > > > discounting old samples. That the TCP example does exhibit this > > > property does not excuse a lack of explicit mention as a property of > > > note. > > > > I think a note that says "it's fine to discount old samples" is OK > > and perfectly within the spirit of the guideline. I don't want to > > overly specify that one has to do this. > > > > > (d) An RTO mechanism MUST NOT use ambiguous FT samples. > > > > > > Assume two copies of some segment X are transmitted at times > > > t0 and t1 and then at time t2 the sender receives > > > confirmation that X in fact arrived. In some cases, it is > > > > > > "segment" feels like use of TCP-specific terminology without disclaimer > > > or generalization. > > > > (I can change this to 'packet'.) > > > > > (3) Loss detected by the RTO mechanism MUST be taken as an > > > indication of network congestion and the sending rate adapted > > > using a standard mechanism (e.g., TCP collapses the congestion > > > window to one segment [RFC5681]). > > > [...] > > > An exception to this rule is if an IETF standardized mechanism > > > determines that a particular loss is due to a non-congestion > > > event (e.g., packet corruption). In such a case a congestion > > > > > > If it's a MUST with an exception, doesn't that make it ... no longer a > > > MUST? > > > > I don't think so. But, you're no doubt a better protocol lawyer > > than I am. I believe this says you really have to do this, but > > there is a **very precise way** to get out of it. If we made this a > > SHOULD then it would be very much looser---i.e., you really ought to > > do this unless you have a good reason. Here we are telling you what > > the good reason has to look like. > > > > > (4) Each time the RTO is used to detect a loss, the value of the RTO > > > MUST be exponentially backed off such that the next firing > > > requires a longer interval. [...] > > > > > > Do we expect this to be exponential backoff by doubling, or is it > > > admissible to use an alternative base for the exponent? (Is there > > > a minimum allowable value? E.g., 1.000001 does not seem like it > > > would provide much protection for the network.) > > > > The document does not say to double the RTO. It means to not > > specify the constant. > > > > Again, the document is meant to get away from specifics where we > > can. I don't know how to set the minimal acceptable backoff. I > > think we'd all agree 1.000001 is not really going to cut it. But, > > would 1.8? How about 1.7? What about 1.3? I believe the consensus > > is that "exponential backoff" is enough. > > > > > Further, a number of implementations use a steady-state minimum RTO > > > that are less than the 1 second specified in [RFC6298] (which is > > > different from the initial RTO we specify in Section 4, Requirement > > > 1). While the implication of these deviations from the standard may > > > > > > Just to check: our requirement 1 is the same as RFC 6298, and the "less > > > than 1 second" is what's different. Perhaps wording this akin to "and > > > as such is in violation of the RTO specified in Requirement 1 from > > > Section 4" would avoid the ambiguity about what is different from what. > > > > Well. Um. I read it many times, but cannot understand what you > > wrote about the document's ambiguity! ;-) Maybe that is my lack of > > coffee, I dunno. But, let me try anyway ... > > > > RFC 6298 says the INITIAL RTO should be no less than 1sec. That > > agrees with rto-consider (requirement 1). > > > > RFC 6298 further says the MINIMUM RTO over the entire lifetime of a > > TCP connection should be no less than 1sec. There is no > > corresponding admonishment in rto-consider. > > > > Probably because these two things are both "1sec" in TCP a lot of > > people have gotten them mixed up in their minds during the > > development of this document. The parenthetical you quote was no > > doubt meant to clarify to someone. But, this discussion can be > > cleaned up, probably. > > > > > Section 6 > > > > > > Noting that we incorporate the security considerations of RFC 6298 > > > by reference, and quoting from there: > > > > > > In addition, even if the attacker can cause the sender's RTO to reach > > > too small a value, it appears the attacker cannot leverage this into > > > much of an attack (compared to the other damage they can do if they > > > can spoof packets belonging to the connection), since the sending TCP > > > will still back off its timer in the face of an incorrectly > > > transmitted packet's loss due to actual congestion. > > > > > > Just to check my understanding: this "actual congestion" would > > > need to be between the sender and the attacker, right? Since the > > > attacker's spoofed ACKs would cause the sender to not detect loss > > > due to congestion that occurs between the attacker and the > > > intended recipient. > > > > Oh boy. My brain is thrashing to try to page back in RFC6298. > > > > The above text isn't the most clear, so I assume I didn't write > > it. :) > > > > Hmm. > > > > I think the basic point is that if an attacker can spoof they can do > > much worse than impacting the computation of the RTO. And, if what > > they want to do is mess with a connection's performance and not the > > reliability of the connection---say because that'd be > > user-visible---then they cannot hide real losses. And, since they > > cannot hide real losses then from a network safety perspective this > > all fails safely because the endpoint will backoff when detecting > > those losses. > > > > > References > > > > > > The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6298]") > > > implies that it should be categorized as normative. Similarly for RFC > > > 6298 itself. > > > > I dunno. The entirety of the algorithm is given in rto-consider. > > So, the reference is really meant to give credit and point people at > > a place to read about it in more detail instead of as a pointer that > > must be understood to enact the guideline. Perhaps just a > > restructuring ... > > > > Therefore, in this situation an implementation MUST use Karn's > > algorithm and use neither version of the FT sample and hence not > > update the RTO (see [KP87,RFC6298] for a broader discussion of > > Karn's algorithm). > > > > Or, put them under "Normative". I really don't much care. > > > > > [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC > > > 2134, June 2001. > > > > > > Fix the typo, please -- RFC 2134 is the articles of incorporation of > > > ISOC. > > > > Well, I do not want to be anywhere near ISOC anything! Good catch, > > thanks! (And, what a weird typo ... all the digits are there, but > > in such a weird order ...) > > > > allman > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm -- Rod Grimes rgrimes@freebsd.org From nobody Thu Jul 9 09:17:25 2020 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 265973A0CE4 for ; Thu, 9 Jul 2020 09:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.652 X-Spam-Level: X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 UaY-8cuFuLw7 for ; Thu, 9 Jul 2020 09:17:21 -0700 (PDT) Received: from mail-qk1-f172.google.com (mail-qk1-f172.google.com [209.85.222.172]) (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 9D0903A0CE2 for ; Thu, 9 Jul 2020 09:17:21 -0700 (PDT) Received: by mail-qk1-f172.google.com with SMTP id c139so2295420qkg.12 for ; Thu, 09 Jul 2020 09:17:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=UsyFN9x/YYd0Ymd9IV20Q9HidB6s1bUyyqSdLKMdM74=; b=cX+lDekPpY22o6pfqRSpQvCc2RgcPeqNJFu4vVwvCnsrnUPYmb+S5ogfC2m7/JbRmI 8AmXaCTzZqNogd5d4ED10t0WdWJ7JN1TiAYN5oeOZ0GqSPYx99cdSy0u2AC8DyVMzg4i pJlB+zoMO1w159q1JCobY67t3gxfFCLQuiDR2T8fBazcmbfkMBWhPyrniCs+WEPk1k2h /FreGLg+cXPuuLY986FBAcNmYZcXHiVSCTABWZg2w3hSIz+Aj5Rd1hWW5585EwQqbsKU m0RNPQNhe/wQII+Q1qNaM6prDV6C0eU057TV+c3lKh31DRlEjWdv2luJsMJrwaCx6vWj Et/w== X-Gm-Message-State: AOAM5329IueZ4db5woCQaQz+CQemOfGdPfb9LZgIEEzMuEYv82t0iUxM SYRItKllzdVSHP048PH+fFEn4g== X-Google-Smtp-Source: ABdhPJxbCHW0TNSE6jHQSnVQG5RnzYujIwXv5nLb+0QOJ8rXHr2tOGO9lhDgz5xU6eCvsK+8c7/h0A== X-Received: by 2002:a37:a605:: with SMTP id p5mr58294822qke.428.1594311440554; Thu, 09 Jul 2020 09:17:20 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:8035:789a:12fa:c941]) by smtp.gmail.com with ESMTPSA id p19sm4044037qkm.75.2020.07.09.09.17.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Jul 2020 09:17:19 -0700 (PDT) From: "Mark Allman" To: "Martin Duke" Cc: "Benjamin Kaduk" , Extensions , "The IESG" , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs Date: Thu, 09 Jul 2020 12:17:18 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <76EAC78C-C9BF-4185-92DF-62FC2D143BF2@icir.org> In-Reply-To: References: <159406496706.24848.1574717471798101163@ietfa.amsl.com> <97326820-187D-4A67-BBF0-CC58FAF18F0B@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_6D5C55A0-8A92-4595-8A73-EF325EC24150_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT) 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, 09 Jul 2020 16:17:23 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_6D5C55A0-8A92-4595-8A73-EF325EC24150_= Content-Type: text/plain Hello all! Thanks for all the comments from everyone. The comments that have come across except for the below seem small and reasonable for the most part. I am way booked until mid-next week, so I'll endeavor to do a rev then. > Benjamin and I discussed this briefly in the telechat. I would summarize as > follows: > > - We seem to have clear agreement on all but the first DISCUSS point > - We should probably say something about the security implications of > spoofed acks but not be too specific. The document doesn't really have a > section (that I can find right now) that discusses the properties of ACKs, > so perhaps the best place to put this is in security considerations. > Something to the effect of I'll take a stab at addressing this and we can iterate. As I mentioned previously, some non-normative encouraging seems fine. Going beyond that seems more thorny, I think. I'll take a crack at it and then we'll have something concrete to discuss / beat me with! allman --=_MailMate_6D5C55A0-8A92-4595-8A73-EF325EC24150_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXwdDDhEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIiziS9AJ43h6S66bp3PCLot3kT4cMfL3HMXwCcCNTL ffUX4rvQ90T5rkQmW7jtDrA= =mbIX -----END PGP SIGNATURE----- --=_MailMate_6D5C55A0-8A92-4595-8A73-EF325EC24150_=-- From nobody Fri Jul 10 00:17:18 2020 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 81C333A0EA0; Fri, 10 Jul 2020 00:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iMmitRpSgXf3; Fri, 10 Jul 2020 00:17:09 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C35C3A0E9D; Fri, 10 Jul 2020 00:17:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id AA7DF25A3B; Fri, 10 Jul 2020 09:17:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1594365427; bh=vX/Y64ODDtloQOt++R6oxJIzuJDONkbtCGjQSWDVyzU=; h=From:To:CC:Subject:Date:From; b=Lw36LhiZx2Y3Ls6SbPsjQKUUsNAv/O6utxpkWgFOG8rmx+V5nC2OJQfLWvYCIiSnm 3HuHLL65QWbqFHzizqxw08khid+EtMySxQFs1CziR8jjiUcfhIQ/9AGq97jCPqdeXm YSZrqSPa3UnaWVq37HLe/l3roW5Ml3MWcvaw4qwQ= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIMnj5QL7GPn; Fri, 10 Jul 2020 09:17:06 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 10 Jul 2020 09:17:06 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Fri, 10 Jul 2020 09:17:06 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: tcpm-chairs Thread-Topic: Presentation slot requests for IETF 108 (online) Thread-Index: AdZQQCmoc741dfI0S+mziKOl37MyoQGSdIbQ Date: Fri, 10 Jul 2020 07:17:06 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC9E2B0@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] FW: Presentation slot requests for IETF 108 (online) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 07:17:17 -0000 [Reminder] -----Original Message----- From: Scharf, Michael=20 Sent: Thursday, July 2, 2020 9:15 AM To: tcpm@ietf.org Cc: tcpm-chairs Subject: Presentation slot requests for IETF 108 (online) Hi all, Given that we had a pretty packed agenda during the virtual interim meeting= , the chairs have asked for two slots during IETF 108. This basically impli= es that we have again the 2:30 hour slot that TCPM used to have for many ye= ars. According to the draft agenda for IETF 108, TCPM has been scheduled for Mon= day Session I (1:40) and Monday Session II (0:50). If you are interested in presenting, please let the chairs know until **Mon= day 2020-07-13**: * Draft name / presentation title * Presenter * Total duration (including Q&A) Thanks Michael (2x) and Yoshi From nobody Fri Jul 10 00:51:18 2020 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 75F703A07D1 for ; Fri, 10 Jul 2020 00:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57mpQTgwvCCB for ; Fri, 10 Jul 2020 00:51:14 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6474B3A07C5 for ; Fri, 10 Jul 2020 00:51:14 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 81A4225A36; Fri, 10 Jul 2020 09:51:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1594367472; bh=74nZJTtip0wNz2Z9lD+oaiNd5rIwpskGUx/FVsjpjB8=; h=From:To:CC:Subject:Date:From; b=ubiimEN7V/j37PzFUVUnnU5G99ExSnUGIfyeokNPVhjkv8vqZDGHutTlV57aA2YFp fjx94Hf7j/8sEHjSSn8xs+4lUee25Vgjp+cQWtd9tNNKpviM2axD16YiYcKFuzQ+XB bUAPIGk/9CR4vJvIcerwzsmZldCGfBPEzZh36isA= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9-1wrAV5nyc; Fri, 10 Jul 2020 09:51:11 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 10 Jul 2020 09:51:11 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Fri, 10 Jul 2020 09:51:10 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" Thread-Topic: Heads-up: draft-ietf-netconf-tcp-client-server-07 Thread-Index: AdZWjKo44LjY7IBqQL2GoSu2bsGOCg== Date: Fri, 10 Jul 2020 07:51:10 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DC9E3E4@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Heads-up: draft-ietf-netconf-tcp-client-server-07 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 07:51:17 -0000 Hi all, This is a heads-up regarding the latest update of draft-ietf-netconf-tcp-cl= ient-server-07. This document is homed in the NETCONF working group. Yet, I believe that it= is important that TCPM is in the loop, too. Given that the YANG models state ... organization "IETF NETCONF (Network Configuration) Working Group and the IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; ... the authors plan to ask for a WGLC not only on the NETCONF list, but al= so on the TCPM list. Michael (as individual contributor to unusual cross-area documents) -----Original Message----- From: netconf On Behalf Of internet-drafts@ietf.= org Sent: Thursday, July 9, 2020 2:28 AM To: i-d-announce@ietf.org Cc: netconf@ietf.org Subject: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-07.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Configuration WG of the IETF. Title : YANG Groupings for TCP Clients and TCP Servers Authors : Kent Watsen Michael Scharf Filename : draft-ietf-netconf-tcp-client-server-07.txt Pages : 31 Date : 2020-07-08 Abstract: This document defines three YANG 1.1 [RFC7950] modules to support the configuration of TCP clients and TCP servers, either as standalone or in conjunction with a stack protocol layer specific configurations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-07 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-= 07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-tcp-client-server-07 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Jul 10 02:20:56 2020 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 6D9073A0F37 for ; Fri, 10 Jul 2020 02:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz9EfT5IJZMs for ; Fri, 10 Jul 2020 02:20:52 -0700 (PDT) Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 1CD473A0F36 for ; Fri, 10 Jul 2020 02:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1594372852; x=1625908852; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5dImczoeAHq0dOvAWRTA7PFe2SBdnN3oI+3IcGssJB8=; b=sRNSGQwyw3Z9+eKJAZ+9aeS8s41ZcCb7ZDA0h3cYleYVx3ncv+QEC9Ei uP5/4Rh0oEfpV09rNQTSvVKtQ+auRHiEbkZ/nauSxaAPuPK+a95Vbw1JO HotL4Ej7voXeTDAMNWjTCl+8A1ZS4ZgYqmAi5mchiclzor67f2QhrYEf6 RsDkOvEMsuqNGXJtv78vsT2PVZvBLeYGM6tPgHvg0TFJjM3IDJwoyoowj RMyQ9WC9bNbZ+Vl6CrETxQJvjo1r3JpPhZmBEj+ISYGdB9XFnxaLiQb3u jOpoQ6zx1hGRT7TOfjiSYtJBtcnWySLW+O+nF19ElKZwPPV6D9BHIiEmH Q==; IronPort-SDR: 69Snn5iNyU4yWIx57U5VgM3mn5ynXPxB5NJOyLqW7LlaYOVIy5TXFlywuwKno3F7PQmExm2hDB zmrCP8BThAkA== Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 10 Jul 2020 11:20:48 +0200 IronPort-SDR: EPeTU6UlPEFDTpKcSZ7uwKdiK7VuAMX+aJ5y4niwqVxdVT+B6Q0OPFWvZvEX0mDKOo9ZQg5m/C uoZhcGZwbhrilI9A5+doguqFz9iGbQ9nU= X-IronPort-AV: E=Sophos;i="5.75,335,1589234400"; d="scan'208";a="149555960" X-MGA-submission: =?us-ascii?q?MDEJDCFZV4bivfzLFAq2nw10VANVX4bdeKeRGI?= =?us-ascii?q?+eC//PvKcCMLqcg7H+bV/wjo4taWIMNtJrseQNDa5kt7eVEf1tsMBWvS?= =?us-ascii?q?eSC9pZphORCCeQQF8XoyCmqOv4wMNY487K94A3//FY0mtsWeUX3GzaRC?= =?us-ascii?q?xnphFiFVIxp0JE3VrWSpuE0Q=3D=3D?= Received: from he105716.emea1.cds.t-internal.com ([10.169.118.52]) by QDEC97.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 10 Jul 2020 11:20:49 +0200 Received: from HE105709.EMEA1.cds.t-internal.com (10.169.118.41) by HE105716.emea1.cds.t-internal.com (10.169.118.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jul 2020 11:20:48 +0200 Received: from HE104164.emea1.cds.t-internal.com (10.171.40.35) by HE105709.EMEA1.cds.t-internal.com (10.169.118.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 10 Jul 2020 11:20:48 +0200 Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.22) by O365mail06.telekom.de (172.30.0.233) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 10 Jul 2020 11:20:44 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LIVOIX0SZoWFXt0lm48cVeUXRRGFSmXVBfWm0nD52FEgYvSbWShDH2uSiK/MSAFFbwprbjUNBwG3MvArK9gJcOwGkRrE4gCBiCt8x8UcwGSqDORMpo/57dJG6qRUYOc5rxHRWyLyRdqtRNmzIZIMaPSsSox0YgTnOqIKmUYAkNZQNCUEDR0kCsheht/bWl5XLFdmrI33XEStGb8/1MeK7XjnuDq+GEl8hHOrLZDae4l7rMYJeLFQF1tpoLmCE81q7m7N+tucC92ZutP++wD2/N8JcXsbcOqapzD4vPsIM+0FimIBCJLQ9pqda3eTwknhkXJuT+sq6Mn9wB6NljZ60A== 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=5dImczoeAHq0dOvAWRTA7PFe2SBdnN3oI+3IcGssJB8=; b=UnzDbu+/2jrmSl0NtBdL84/8ime4KI3zjNooRDn4im+0XyY3ghFfFWCQLI5lXkjiA2H1taQh8qsWvAykbQ6VO327bWQIxEQfezyWwwkZDDAXfTQl519wu3FKaZY8k4gJv/dcgDzGWH/WvV1HtTl4ejm/ZkTMb8Z+pKm3jQ4CCeciEGxnWF3hW5jaLlARyHgCh6b3ynNV9xi3jVj6sz+IvQN3hhGi4p8skELuRyw6m0JSz1xqJueSgNH17sLfrXYsX9kU7tmTiIPkeYh45XLsUwL/Ctqc2RXsijah3b3UxK5kv4r/47HhcRUos06cMqOIS1j0acXM0xcu/wtxcnoWwA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c012:a::11) by LEJPR01MB0907.DEUPRD01.PROD.OUTLOOK.DE (2a01:4180:c012:4::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.9; Fri, 10 Jul 2020 09:20:47 +0000 Received: from LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d595:7a33:8cac:79b0]) by LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE ([fe80::d595:7a33:8cac:79b0%2]) with mapi id 15.20.3195.009; Fri, 10 Jul 2020 09:20:47 +0000 From: To: Thread-Topic: New Version Notification for draft-amend-tcpm-mptcp-robe-00.txt Thread-Index: AQHWVECQtCIf5ZKlm0yN65L1SwZGNqkAjNEQ Date: Fri, 10 Jul 2020 09:20:47 +0000 Message-ID: References: <159411392151.22613.17606192352426409719@ietfa.amsl.com> In-Reply-To: <159411392151.22613.17606192352426409719@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=telekom.de; x-originating-ip: [164.19.3.230] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eac804c2-ac75-4996-b094-08d824b287ea x-ms-traffictypediagnostic: LEJPR01MB0907: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PQIIMOAhTRFXvuniS9FH8E34+B/2n6MJV2ik1idqwBw9Ld3t4wljLj2X8tVi2PulLrUrjuUxtPdFpVFX4E15h99UDCwvWC/W6yLz8IACHg6XHpLy5TNcFClbGOKMbbRth81HaHeP85ER2YCvuTHJg11xIepBwbHBl5E3feEZYLy2FrRDlTzFqBEjwLaqzy3cwUvFZ8V5FQzrSJkTlvtluGGUpCFzfxEhwirfRuC7V+2E19zXDhYWQdDmeabUgaO8hjIF1rfJNspzM7kSEPz3OOjgyRI7BZ25oUP15z6AvxO9Dv3LRCOhFOFN+5FdRhTxqaXN9OuFGJpUnrJW2UmiW35GSPjvw891vJC+VUYvzOE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE; PTR:; CAT:NONE; SFTY:; SFS:(376002)(136003)(39860400002)(346002)(366004)(396003)(966005)(83380400001)(8676002)(66946007)(8936002)(76116006)(26005)(66476007)(66446008)(5660300002)(64756008)(66556008)(6916009)(71200400001)(33656002)(186003)(86362001)(66574015)(15650500001)(9686003)(7696005)(55016002)(316002)(53546011)(478600001)(2906002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xMg6rc5dbh9NFkh2UYT3jZEnpAcaS0aiHh/EC+Gc0gvODyoAv8T9f08f9nivxydEh6SMfGuCX6vg6RsSCJymgLV9hz+qSJ5jUwt0mMtMEbBg2v71vZBB5skoiCrxehWj1Uzmmi1m2OctFGWueXAVMjSnM11pgjqWMvtXcqgovsb48fbhmHc92DmrjYRJ9bPMBxPm4PGo3SzL+TIdUSBXW7xICyNi74xN8IgG53VzMdnz8/9mHxySm7IEWdL9m0p2QezUAd6zKxAaMHxO78qBSAqZihDjCYBSpDC6nFMZKyGXp3nT3cKSFPaNWVddDP87oudDKZbQp7gFO8/jRipMFI90obDjbF1AmptnnoAwvhyl6bKjxrkRZSE9Q7bhgrDOBY8lt/8wtmIypVSvhm1q/ocdm/iXzRmvf5jKVAB8A51lohLdeiNJrKAnNx+Pc7f0bjiskUwxdzA3sRkwzZrqPX16cRSzJNH2dJAGe4iPChI= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LEJPR01MB0490.DEUPRD01.PROD.OUTLOOK.DE X-MS-Exchange-CrossTenant-Network-Message-Id: eac804c2-ac75-4996-b094-08d824b287ea X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2020 09:20:47.5658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UANmOALMX97kywTEqZTxpGI18KoJmthLwtvw/5gutyxWTfjfjrcP6mrP1MFaLLSKbs+yUo+cTkvNUhPFE9ckmw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0907 X-TM-SNTS-SMTP: A8995254E90C50DC2EBA065D4D2E2D5AC9C90A57E4FC84911BEABDAC3EE12B102000:8 X-OriginatorOrg: telekom.de Archived-At: Subject: [tcpm] FW: New Version Notification for draft-amend-tcpm-mptcp-robe-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2020 09:20:54 -0000 RGVhciBhbGwsDQoNCmFmdGVyIHRoZSBNUFRDUCBXRyBoYXMgYmVlbiBjbG9zZWQsIHdlIG1pZ3Jh dGVkIHRoZSBNUFRDUCBSb2JFIHByb3Bvc2FsIG5vdyB0byBUQ1BNLiBFdmVuIGlmIGl0IGFwcGVh cnMgaGVyZSBhcyAtMDAgaXQncyB0aGUgdGhpcmQgaXRlcmF0aW9uLiBUaGUgaGlzdG9yeSBjYW4g YmUgY2hlY2tlZCB1bmRlciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1h bWVuZC10Y3BtLW1wdGNwLXJvYmUvLg0KDQpQcm9iYWJseSBKaWFvIGFuZCBJIHdpbGwgcHJlc2Vu dCB0aGUgcHJvZ3Jlc3MgYXQgdGhlIHVwY29taW5nIHZpcnR1YWwgSUVURjEwOCwgYSBzbG90IGlz IHJlcXVlc3RlZC4NCg0KQnINCg0KTWFya3VzDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4NCj4gU2VudDogRGllbnN0YWcsIDcuIEp1bGkgMjAyMCAxMToyNQ0KPiBUbzogQW1l bmQsIE1hcmt1cyA8TWFya3VzLkFtZW5kQHRlbGVrb20uZGU+OyBKaWFvIEthbmcNCj4gPGthbmdq aWFvQGh1YXdlaS5jb20+OyBBbWVuZCwgTWFya3VzIDxNYXJrdXMuQW1lbmRAdGVsZWtvbS5kZT4N Cj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbWVuZC10Y3Bt LW1wdGNwLXJvYmUtMDAudHh0DQo+IA0KPiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0 LWFtZW5kLXRjcG0tbXB0Y3Atcm9iZS0wMC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBNYXJrdXMgQW1lbmQgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0 b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWFtZW5kLXRjcG0tbXB0Y3Atcm9iZQ0KPiBSZXZpc2lv bjoJMDANCj4gVGl0bGU6CQlNdWx0aXBhdGggVENQIEV4dGVuc2lvbiBmb3IgUm9idXN0IFNlc3Np b24gRXN0YWJsaXNobWVudA0KPiBEb2N1bWVudCBkYXRlOgkyMDIwLTA3LTA3DQo+IEdyb3VwOgkJ SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJMjcNCj4gVVJMOiAgICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hbWVuZC10Y3BtLW1wdGNw LXJvYmUtDQo+IDAwLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtYW1lbmQtdGNwbS1tcHRjcC1yb2JlLw0KPiBIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFtZW5kLXRjcG0tbXB0Y3Atcm9i ZS0wMA0KPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1hbWVuZC10Y3BtLW1wdGNwLQ0KPiByb2JlDQo+IA0KPiANCj4gQWJzdHJhY3Q6 DQo+ICAgIE11bHRpcGF0aCBUQ1AgZXh0ZW5kcyB0aGUgcGxhaW4sIHNpbmdsZS1wYXRoIGxpbWl0 ZWQsIFRDUCB0b3dhcmRzIHRoZQ0KPiAgICBjYXBhYmlsaXR5IG9mIG11bHRpcGF0aCB0cmFuc21p c3Npb24uICBUaGlzIGdyZWF0bHkgaW1wcm92ZXMgdGhlDQo+ICAgIHJlbGlhYmlsaXR5IGFuZCBw ZXJmb3JtYW5jZSBvZiBUQ1AgY29tbXVuaWNhdGlvbi4gIEZvciBiYWNrd2FyZHMNCj4gICAgY29t cGF0aWJpbGl0eSByZWFzb25zIHRoZSBNdWx0aXBhdGggVENQIHdhcyBkZXNpZ25lZCB0byBzZXR1 cA0KPiAgICBzdWNjZXNzZnVsbHkgYW4gaW5pdGlhbCBwYXRoIGZpcnN0LCBhZnRlciB3aGljaCBz dWJzZXF1ZW50IHBhdGhzIGNhbg0KPiAgICBiZSBhZGRlZCBmb3IgbXVsdGlwYXRoIHRyYW5zbWlz c2lvbi4gIEZvciB0aGF0IHJlYXNvbiB0aGUgTXVsdGlwYXRoDQo+ICAgIFRDUCBoYXMgdGhlIHNh bWUgbGltaXRhdGlvbnMgYXMgdGhlIHBsYWluIFRDUCBkdXJpbmcgY29ubmVjdGlvbg0KPiAgICBz ZXR1cCwgaW4gY2FzZSB0aGUgc2VsZWN0ZWQgcGF0aCBpcyBub3QgZnVuY3Rpb25hbC4NCj4gDQo+ ICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBzZXQgb2YgaW1wbGVtZW50YXRpb25zIGFuZCBw b3NzaWJsZQ0KPiAgICBjb21iaW5hdGlvbnMgdGhlcmVvZiwgdGhhdCBwcm92aWRlIGEgbW9yZSBS b2J1c3QgRXN0YWJsaXNobWVudCAoUm9iRSkNCj4gICAgb2YgTVBUQ1Agc2Vzc2lvbnMuICBJdCBp bmNsdWRlcyBSb2JFX1RJTUVSLCBSb2JFX1NJTSwgUm9iRV9lU0lNIGFuZA0KPiAgICBSb2JFX0lQ Uy4NCj4gDQo+ICAgIFJvYkVfVElNRVIgaXMgZGVzaWduZWQgdG8gc3RheSBjbG9zZSB0byBNUFRD UCBpbiB0aGF0IHN0YW5kYXJkDQo+ICAgIGZ1bmN0aW9uYWxpdHkgaXMgdXNlZCB3aGVyZXZlciBw b3NzaWJsZS4gIFJlc2lsaWVuY3kgYWdhaW5zdCBuZXR3b3JrDQo+ICAgIG91dGFnZXMgaXMgYWNo aWV2ZWQgYnkgbW9kaWZ5aW5nIHRoZSBTWU4gcmV0cmFuc21pc3Npb24gdGltZXI6IElmIG9uZQ0K PiAgICBwYXRoIGlzIGRlZmVjdGl2ZSwgYW5vdGhlciBwYXRoIGlzIHVzZWQuDQo+IA0KPiAgICBS b2JFX1NJTSBhbmQgUm9iRV9lU0lNIHByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvIHNpbXVsdGFuZW91 c2x5IHVzZQ0KPiAgICBtdWx0aXBsZSBwYXRocyBmb3IgY29ubmVjdGlvbiBzZXR1cC4gIFRoZXkg ZW5zdXJlIGNvbm5lY3Rpdml0eSBpZiBhdA0KPiAgICBsZWFzdCBvbmUgZnVuY3Rpb25hbCBwYXRo IG91dCBvZiBhIGJ1bmNoIG9mIHBhdGhzIGlzIGdpdmVuIGFuZCBvZmZlcnMNCj4gICAgYmVzaWRl IHRoYXQgdGhlIG9wcG9ydHVuaXR5IHRvIHNpZ25pZmljYW50bHkgaW1wcm92ZSBsb2FkaW5nIHRp bWVzIG9mDQo+ICAgIEludGVybmV0IHNlcnZpY2VzLg0KPiANCj4gICAgUm9iRV9JUFMgcHJvdmlk ZXMgYSBoZXVyaXN0aWMgdG8gc2VsZWN0IHByb3Blcmx5IGFuIGluaXRpYWwgcGF0aCBmb3INCj4g ICAgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50IHdpdGggYSByZW1vdGUgaG9zdCBiYXNlZCBvbiBl bXBpcmljYWwgZGF0YQ0KPiAgICBkZXJpdmVkIGZyb20gcHJldmlvdXMgY29ubmVjdGlvbiBpbmZv cm1hdGlvbi4NCj4gDQo+ICAgIEluIHByYWN0aWNlLCB0aGVzZSBpbmRlcGVuZGVudCBzb2x1dGlv bnMgY2FuIGJlIGNvbXBsZW1lbnRhcnkgdXNlZC4NCj4gICAgVGhpcyBkb2N1bWVudCBhbHNvIHBy ZXNlbnRzIHRoZSBkZXNpZ24gYW5kIHByb3RvY29sIHByb2NlZHVyZSBmb3INCj4gICAgdGhvc2Ug Y29tYmluYXRpb25zIGluIGFkZGl0aW9uIHRvIHRoZSByZXNwZWN0aXZlIHN0YW5kLWFsb25lDQo+ ICAgIHNvbHV0aW9ucy4NCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0KDQo= From nobody Fri Jul 10 19:40:42 2020 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 3EA463A0CC1; Fri, 10 Jul 2020 19:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqA-B-CFKi_8; Fri, 10 Jul 2020 19:40:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 4C2BD3A0CC0; Fri, 10 Jul 2020 19:40:22 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06B2eFo0009520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jul 2020 22:40:17 -0400 Date: Fri, 10 Jul 2020 19:40:15 -0700 From: Benjamin Kaduk To: Mark Allman Cc: The IESG , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Yoshifumi Nishida Message-ID: <20200711024015.GL16335@kduck.mit.edu> References: <159406496706.24848.1574717471798101163@ietfa.amsl.com> <97326820-187D-4A67-BBF0-CC58FAF18F0B@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97326820-187D-4A67-BBF0-CC58FAF18F0B@icsi.berkeley.edu> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT) 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, 11 Jul 2020 02:40:26 -0000 On Tue, Jul 07, 2020 at 09:49:06AM -0400, Mark Allman wrote: > > Hi Benjamin! > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > If we are providing BCP-level requirements for time-based loss > > detection via absence of protocol-level acknowledgment, for new > > protocols, it seems appropriate to mandate that the acknowledgment > > signal is reliable, i.e., not spoofable by at least an off-path > > attacker, and ideally not spoofable by an on-path attacker either. > > I would love for this to be a cryptographically protected > > mechanism, but expect that I can't get away with mandating > > something that strong, and that something with "enough bits of > > entropy" will suffice. (I'd prefer "enough" to be 128 but could > > perhaps be persuaded that a lower value is appropriate as a > > minimum requirement.) > > I have been thinking about this since yesterday and have a few > thoughts ... > > - In some sense, I like the general thought. It would tighten > things up. > > - That said, pragmatically, I think the risk from spoofed ACKs is > pretty small. For instance, if you want to screw up the RTO you > need to pretty continuously screw up the FT measurements for > anything long running. So, it isn't enough to guess and inject > correctly once, but you have to do so on an ongoing basis. And, > with much less than 128 bits of entropy something like TCP is > not particularly susceptible to this sort of thing. > > - And, so we can obviously make up a requirement for future > protocols here, but I don't think that will be a "BCP" or even > "CP". It would not be like the rest of the document where the > aspects of loss detection are well understood. > > - And, we'd have to decide what we meant by "new protocol". Is > that some wholly new thing or is that a new algorithm for SCTP > or TCP or DNS? > > - Perhaps there is some non-normative note that could be added > that folks are encouraged to think about making the feedback > non-spoofable for FT measurements (among many other reasons, of > course). I dunno ... [I'll take this one in the ensuing thread] > > Point S.3 in Section 3 indicates that "[t]he requirements in this > > document apply only to endpoint-to- endpoint unicast > > communication. Reliable multicast (e.g., [RFC5740]) protocols are > > explicitly outside the scope of this document." This limitation > > of scope should be reflected in the document's title, Abstract, > > and Introduction. > > (A note can be added.) > > > I would also like to get an explicit confirmation that the various > > (non-)requirements on the details of exponential backoff and > > reduced weighting for old FT samples are as-intended (see > > COMMENT). Specifically, are there limitations on the base of the > > exponent for the exponential backoff, and is there a requirement > > to give more recent FT samples more precedence than older FT > > samples when computing an RTO estimate? > > Yes- the intent is to not specify the details. The basic gist of > the document is that we have learned that the details are not hugely > important and so getting away from them is fine. Thanks. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Abstract > > > > of congestion along a network path). While many mechanisms have > > been designed to detect loss, protocols ultimately can only count on > > the passage of time without delivery confirmation to declare a > > packet "lost". Each implementation of a time-based loss detection > > > > I'm not entirely convinced that the literal meaning of what these > > words say is universally true for all protocols (specifically "can > > only count on" and omitting a qualifier such as "many" or "most" > > protocols or "reliably count on"). Consider, for example, the DTN > > bundle protocol, which has some circumstances in which a given > > store-and-forward node will flat-out not attempt to forward a > > protocol onward to its final recipient, but can send back a status > > report to the sender noting the confirmed lack of delivery. I > > suggest adding some form of qualifier to admit the possibility of > > such unusual situations. > > > > Section 1 > > > > missing. However, despite our best intentions and most robust > > mechanisms we cannot place ultimate faith in receiving such > > acknowledgments, but can only truly depend on the passage of time. > > Therefore, our ultimate backstop to ensuring that we detect all loss > > is a timeout. [...] > > > > Despite the superficial similarity of tone, a strict reading of > > these words does not seem to share the issue I raised about the > > Abstract. (That said, this phrasing still seems a bit overblown > > and my personal preference would be to tone it down some.) > > The point is objectively true and actually meant to be absolute. > Yes, an explicit non-delivery notification can be sent. Such > notifications may be useful and even quite important. But, > ultimately, we cannot be rely upon such things to ensure reliable > communications because they themselves may get lost, corrupted, > delayed, etc. But, if time somehow stops marching forward then > ... well, WGAS about the packets?! :) > > Too me this is a crucial protocol building touchstone. One has to > think about what we can and cannot count on. And to what degree. That's why I tried to emphasize my point as being about "the literal meaning of what these words say". To say that the only thing that is 100% fully reliable is the timeout is one thing, but to say that the only thing we can "count on" has subtly different semantics. That is, we can rely on something without it being 100% reliable, and to say that the timeout is the only thing we can rely on is false. To say that the timeout is the only fully reliable signal that we have is (AFAIK) true. > > Section 2 > > > > - This document does not update or obsolete any existing RFC. > > These previous specifications---while generally consistent with > > the requirements in this document---reflect community consensus > > and this document does not change that consensus. > > > > - The requirements in this document are meant to provide for > > network safety and, as such, SHOULD be used by all time-based > > loss detection mechanisms. > > > > I'm not sure that I understand how the combinations of these two > > statements apply to existing specifications. Is there some sense that > > existing specs might leave some flexibility and when there is such > > flexibility, implementations/deployments SHOULD use the flexibility to > > match this document as closely as possible? Or are existing deployments > > and implementations of existing RFCs also grandfathered out? If the > > intent of the second bullet is to only apply to new protocols, please > > say so explicitly. (Section 4 seems to imply the "only new protocols" > > case, but it's hard to be sure.) > > The first bullet is intended to be backwards looking and the second > bullet is intended to be forward looking. A few extra words there > to make the second bullet more clear would be (in hindsight!) > useful. I look forward to it, thanks. > > - The requirements in this document may not be appropriate in all > > cases and, therefore, inconsistent deviations and variants may > > be necessary (hence the "SHOULD" in the last bullet). However, > > inconsistencies MUST be (a) explained and (b) gather consensus. > > > > Similarly, is this statement only forward-looking? Presumably the first > > bullet ("does not update or obsolete any existing") trumps this one, but > > it's good to be clear. > > Yes- forward looking. Clarifying words to be added. > > > Additionally, I share the GenART reviewer's unease with this > > strong of a requirement and have low confidence that the IETF will > > reliably adhere to it in the future. > > In fairness to Stewart---even though I disagree with him---I think > his point is broader than just non-adherence. (Stewart and I have > iterated on his comments and in fact a number of his LC comments > made the document better. But, on this point we just fundamentally > disagreed.) > > I don't presume to speak for Stewart, but I believe he fears this > will become a touchstone for area-on-area warfare whereby perfectly > justifiable deviations won't be well understood as "perfectly > justifiable" by folks not intimate with the given context. And, > this will in turn hold things up. And, he seems especially > concerned about cases where we want to update something that has > been used forever and, yet, deviates from rto-consider. I may have some small amount of experience with people wanting to update things that have been used forever and deviate from current best practices :) I think (at least from what I can see; maybe I'm off in a bubble) that the security area has learned to accomodate what cannot be changed without breaking "everything" as a side effect, but still insist on best practices where possible (i.e., for new things). So I'm optimistic that the IETF as a whole can do so as well. > My take is three-fold ... > > - First, this statement in rto-consider really doesn't change > anything, IMO. If we're not explaining why we're doing things > and not getting consensus then we shouldn't be publishing it. > > - Second, this explicit statement was added to get WG consensus. > Removing it or softening it would, I believe, run counter to the > consensus the document has already gathered. > > - Third, IMO, saying a given mechanism has proven to be fine in a > given context should really be enough justification. That is, > yeah, I can see that some protocol lawyer could be pedantic. > And, that might be annoying, I guess. But, I think reasonable > people should be able to form a consensus that rebuts such > things. > > > Section 3 > > > > (S.1) The requirements in this document apply only to the primary or > > last resort time-based loss detection. > > > > I'm not sure I understand what "primary or last resort [sic]" means. > > Are there time-based loss-detection mechanisms that are neither primary > > nor last resort? (nit: hyphenate "last-resort" as a compound adjective, > > and many other compound adjectives throughout.) > > (May also affect S.2.) > > I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary > > non-last-resort schemes, however, I think we should be more clear about > > what we mean when we introduce the term and why we exclude certain > > classes of time-based loss-detection mechanisms. > > > > detectors. However, these mechanisms do not obviate the need > > for a "retransmission timeout" or "RTO" because---as we > > discuss in Section 1---only the passage of time can ultimately > > be relied upon to detect loss. In cases such as these, the > > > > [This text is more like the Abstract's, implying that the passage of > > time is the only way to detect loss, universally] > > I dunno. I would have to think about this a bit. As you say, we > tried to sprinkle in references to non-last-resort timers. Perhaps > there are some words we can add here to explain things better. > You're the first one to trip on this. But, I'd be happy to go > through this text and think about it again. For this one, even "be relied upon ultimately" might be enough (albeit stilted language). In my parsing, at least, "can ultimately be relied upon" is more about "when it comes to the end, it's alwayw an option" than "is fundamentally reliable". Maybe something about "detect loss reliably" would be less stilted, as input for your further thoughts. > > Section 4 > > > > In other words, the RTO should represent an empirically- > > derived reasonable amount of time that the sender should > > wait for delivery confirmation before deciding the given > > data is lost. Network paths are inherently dynamic and > > therefore it is crucial to incorporate multiple FT samples > > in the RTO to take into account the delay variation across > > time. > > > > It feels weird to say that the delay will vary over time here but say > > nothing about the corresponding need to discount very old FT samples. > > Point (b) talks about adding new samples in, but not about removing or > > discounting old samples. That the TCP example does exhibit this > > property does not excuse a lack of explicit mention as a property of > > note. > > I think a note that says "it's fine to discount old samples" is OK > and perfectly within the spirit of the guideline. I don't want to > overly specify that one has to do this. Sure. > > (d) An RTO mechanism MUST NOT use ambiguous FT samples. > > > > Assume two copies of some segment X are transmitted at times > > t0 and t1 and then at time t2 the sender receives > > confirmation that X in fact arrived. In some cases, it is > > > > "segment" feels like use of TCP-specific terminology without disclaimer > > or generalization. > > (I can change this to 'packet'.) > > > (3) Loss detected by the RTO mechanism MUST be taken as an > > indication of network congestion and the sending rate adapted > > using a standard mechanism (e.g., TCP collapses the congestion > > window to one segment [RFC5681]). > > [...] > > An exception to this rule is if an IETF standardized mechanism > > determines that a particular loss is due to a non-congestion > > event (e.g., packet corruption). In such a case a congestion > > > > If it's a MUST with an exception, doesn't that make it ... no longer a > > MUST? > > I don't think so. But, you're no doubt a better protocol lawyer > than I am. I believe this says you really have to do this, but > there is a **very precise way** to get out of it. If we made this a > SHOULD then it would be very much looser---i.e., you really ought to > do this unless you have a good reason. Here we are telling you what > the good reason has to look like. One thing that people will do is say thing like "with one exception, you MUST do X. The exception is Y". Having the execption as a separate statement like the current text makes it veer into the territory of internal inconsistency, whereas the joined-up construction is a coherent thought. > > (4) Each time the RTO is used to detect a loss, the value of the RTO > > MUST be exponentially backed off such that the next firing > > requires a longer interval. [...] > > > > Do we expect this to be exponential backoff by doubling, or is it > > admissible to use an alternative base for the exponent? (Is there > > a minimum allowable value? E.g., 1.000001 does not seem like it > > would provide much protection for the network.) > > The document does not say to double the RTO. It means to not > specify the constant. > > Again, the document is meant to get away from specifics where we > can. I don't know how to set the minimal acceptable backoff. I > think we'd all agree 1.000001 is not really going to cut it. But, > would 1.8? How about 1.7? What about 1.3? I believe the consensus > is that "exponential backoff" is enough. Okay. Thanks for confirming. > > Further, a number of implementations use a steady-state minimum RTO > > that are less than the 1 second specified in [RFC6298] (which is > > different from the initial RTO we specify in Section 4, Requirement > > 1). While the implication of these deviations from the standard may > > > > Just to check: our requirement 1 is the same as RFC 6298, and the "less > > than 1 second" is what's different. Perhaps wording this akin to "and > > as such is in violation of the RTO specified in Requirement 1 from > > Section 4" would avoid the ambiguity about what is different from what. > > Well. Um. I read it many times, but cannot understand what you > wrote about the document's ambiguity! ;-) Maybe that is my lack of > coffee, I dunno. But, let me try anyway ... > > RFC 6298 says the INITIAL RTO should be no less than 1sec. That > agrees with rto-consider (requirement 1). > > RFC 6298 further says the MINIMUM RTO over the entire lifetime of a > TCP connection should be no less than 1sec. There is no > corresponding admonishment in rto-consider. > > Probably because these two things are both "1sec" in TCP a lot of > people have gotten them mixed up in their minds during the > development of this document. The parenthetical you quote was no > doubt meant to clarify to someone. But, this discussion can be > cleaned up, probably. Well, I think your discussion here has cleared one thing up for me, at least -- I totally missed the "steady-state" vs. "initial" distinction the first time around. Anyway, to be more clear about what I found ambiguous: the current text says, paraphrasing "some people do X. RFC 6298 says to do Y, and X is less than Y. This is different than what we say in section 4". The ambiguity is about the "this" in "this is different" -- is it X or Y? Hopefully that helps you clean things up. > > Section 6 > > > > Noting that we incorporate the security considerations of RFC 6298 > > by reference, and quoting from there: > > > > In addition, even if the attacker can cause the sender's RTO to reach > > too small a value, it appears the attacker cannot leverage this into > > much of an attack (compared to the other damage they can do if they > > can spoof packets belonging to the connection), since the sending TCP > > will still back off its timer in the face of an incorrectly > > transmitted packet's loss due to actual congestion. > > > > Just to check my understanding: this "actual congestion" would > > need to be between the sender and the attacker, right? Since the > > attacker's spoofed ACKs would cause the sender to not detect loss > > due to congestion that occurs between the attacker and the > > intended recipient. > > Oh boy. My brain is thrashing to try to page back in RFC6298. > > The above text isn't the most clear, so I assume I didn't write > it. :) > > Hmm. > > I think the basic point is that if an attacker can spoof they can do > much worse than impacting the computation of the RTO. And, if what > they want to do is mess with a connection's performance and not the > reliability of the connection---say because that'd be > user-visible---then they cannot hide real losses. And, since they > cannot hide real losses then from a network safety perspective this > all fails safely because the endpoint will backoff when detecting > those losses. Thanks for explaining it like that; I think I get it now. > > References > > > > The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6298]") > > implies that it should be categorized as normative. Similarly for RFC > > 6298 itself. > > I dunno. The entirety of the algorithm is given in rto-consider. Ah, I didn't work through it in enough detail to pick that up. > So, the reference is really meant to give credit and point people at > a place to read about it in more detail instead of as a pointer that > must be understood to enact the guideline. Perhaps just a > restructuring ... > > Therefore, in this situation an implementation MUST use Karn's > algorithm and use neither version of the FT sample and hence not > update the RTO (see [KP87,RFC6298] for a broader discussion of > Karn's algorithm). Sure, that looks fine. Thanks again, Ben > Or, put them under "Normative". I really don't much care. > > > [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC > > 2134, June 2001. > > > > Fix the typo, please -- RFC 2134 is the articles of incorporation of > > ISOC. > > Well, I do not want to be anywhere near ISOC anything! Good catch, > thanks! (And, what a weird typo ... all the digits are there, but > in such a weird order ...) > > allman From nobody Fri Jul 10 19:55:26 2020 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 51E833A0CE2; Fri, 10 Jul 2020 19:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmW-48otqmwz; Fri, 10 Jul 2020 19:55:21 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7B6663A0C45; Fri, 10 Jul 2020 19:55:20 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06B2t1ik013326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jul 2020 22:55:04 -0400 Date: Fri, 10 Jul 2020 19:55:01 -0700 From: Benjamin Kaduk To: "Rodney W. Grimes" Cc: Martin Duke , Mark Allman , tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rto-consider@ietf.org, The IESG Message-ID: <20200711025501.GM16335@kduck.mit.edu> References: <202007091555.069Ft9fB091573@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202007091555.069Ft9fB091573@gndrsh.dnsmgr.net> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT) 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, 11 Jul 2020 02:55:24 -0000 Hi Rod, On Thu, Jul 09, 2020 at 08:55:09AM -0700, Rodney W. Grimes wrote: > Martin, Benjamin, etc el: > > > Benjamin and I discussed this briefly in the telechat. I would summarize as > > follows: > > > > - We seem to have clear agreement on all but the first DISCUSS point > > - We should probably say something about the security implications of > > spoofed acks but not be too specific. The document doesn't really have a > > section (that I can find right now) that discusses the properties of ACKs, > > so perhaps the best place to put this is in security considerations. > > Isn't it a mistake to discuss in "security considerations" a > topic that is not in the main body of the document? Generally, yes. What is "the topic" you were thinking of? I see us talk about using acknowledgments to get RTT samples. I also see us talk about how the absence of an ACK is a signal for loss. However, in some cases, the inverse is not true: the presence of an ACK is not a reliable signal for completed delivery. In other words, best practices for detecing loss include both being confident there is loss and being confident there is not loss, and you have to worry about off-path attacks to use in-protocol ACKs to be confident there is not loss. Crypto is a great way to protect your ACKs from off-path attacks, but is not the only way to do so. I do note that I qualified my remark with quite a long predicate, and have not really seen anyone attempting to confirm or reject that predicate as being the goal of the document. > > Something to the effect of > > > > "An attacker could spoof a sufficient number of receiver messages to either > > alter the feedback time calculation, or indicate the receipt of packets > > that did not actually arrive at the receiver. Endpoints SHOULD include > > measures to make it hard for off-path attackers to guess the fields of > > these packets to mitigate this attack" > > Such an ambigous statement added without discussion of how one might > implment a "measure to make it hard" for an implementer would be > a No-op as I have nothing to base what it is I SHOULD do from this > document, nor any reference to another document. > > IMHO, trying to address off-path attacks in this draft is out of scope. Perhaps you could say what you think the scope is, then? > The specification of those details should be in the transport protocol > itself, not in a generized document such as this, as it is only in > those documents that methods to mitigate attacks can reasonably be > documented. Perhaps say that "transport protocols SHOULD document > techniques for mitigation against attacks that could perturb the > estimate of RTT"? But even that is, IMHO, beyond the scope of what > this document should be covering as now it is saying what other > documents should contain. > > I understand the desire to say something about the issues of > an off path attack, but is this document really the right place > to try and address that concern? If you want an accurate loss signal, you need an accurate non-loss signal. I think it's appropriate to make a note of that, along with some indication of what's needed to get an accurate non-loss signal, in the context of the BCP 72 threat model. Exactly what words we use to give that indication are not terribly important to me (and I note that anything we say in this document is subject to the "SHOULD be used by all time-based loss detection mechanisms" from Section 2, so even nominally MUST-level requirements still have an escape clause). -Ben > > Together with the agreed fixes, this should be enough to move forward. > > > > Martin > > > > On Tue, Jul 7, 2020 at 8:01 AM Mark Allman > > wrote: > > > > > > > > Hi Benjamin! > > > > > > > ---------------------------------------------------------------------- > > > > DISCUSS: > > > > ---------------------------------------------------------------------- > > > > > > > > If we are providing BCP-level requirements for time-based loss > > > > detection via absence of protocol-level acknowledgment, for new > > > > protocols, it seems appropriate to mandate that the acknowledgment > > > > signal is reliable, i.e., not spoofable by at least an off-path > > > > attacker, and ideally not spoofable by an on-path attacker either. > > > > I would love for this to be a cryptographically protected > > > > mechanism, but expect that I can't get away with mandating > > > > something that strong, and that something with "enough bits of > > > > entropy" will suffice. (I'd prefer "enough" to be 128 but could > > > > perhaps be persuaded that a lower value is appropriate as a > > > > minimum requirement.) > > > > > > I have been thinking about this since yesterday and have a few > > > thoughts ... > > > > > > - In some sense, I like the general thought. It would tighten > > > things up. > > > > > > - That said, pragmatically, I think the risk from spoofed ACKs is > > > pretty small. For instance, if you want to screw up the RTO you > > > need to pretty continuously screw up the FT measurements for > > > anything long running. So, it isn't enough to guess and inject > > > correctly once, but you have to do so on an ongoing basis. And, > > > with much less than 128 bits of entropy something like TCP is > > > not particularly susceptible to this sort of thing. > > > > > > - And, so we can obviously make up a requirement for future > > > protocols here, but I don't think that will be a "BCP" or even > > > "CP". It would not be like the rest of the document where the > > > aspects of loss detection are well understood. > > > > > > - And, we'd have to decide what we meant by "new protocol". Is > > > that some wholly new thing or is that a new algorithm for SCTP > > > or TCP or DNS? > > > > > > - Perhaps there is some non-normative note that could be added > > > that folks are encouraged to think about making the feedback > > > non-spoofable for FT measurements (among many other reasons, of > > > course). I dunno ... > > > > > > > Point S.3 in Section 3 indicates that "[t]he requirements in this > > > > document apply only to endpoint-to- endpoint unicast > > > > communication. Reliable multicast (e.g., [RFC5740]) protocols are > > > > explicitly outside the scope of this document." This limitation > > > > of scope should be reflected in the document's title, Abstract, > > > > and Introduction. > > > > > > (A note can be added.) > > > > > > > I would also like to get an explicit confirmation that the various > > > > (non-)requirements on the details of exponential backoff and > > > > reduced weighting for old FT samples are as-intended (see > > > > COMMENT). Specifically, are there limitations on the base of the > > > > exponent for the exponential backoff, and is there a requirement > > > > to give more recent FT samples more precedence than older FT > > > > samples when computing an RTO estimate? > > > > > > Yes- the intent is to not specify the details. The basic gist of > > > the document is that we have learned that the details are not hugely > > > important and so getting away from them is fine. > > > > > > > ---------------------------------------------------------------------- > > > > COMMENT: > > > > ---------------------------------------------------------------------- > > > > > > > > Abstract > > > > > > > > of congestion along a network path). While many mechanisms have > > > > been designed to detect loss, protocols ultimately can only count on > > > > the passage of time without delivery confirmation to declare a > > > > packet "lost". Each implementation of a time-based loss detection > > > > > > > > I'm not entirely convinced that the literal meaning of what these > > > > words say is universally true for all protocols (specifically "can > > > > only count on" and omitting a qualifier such as "many" or "most" > > > > protocols or "reliably count on"). Consider, for example, the DTN > > > > bundle protocol, which has some circumstances in which a given > > > > store-and-forward node will flat-out not attempt to forward a > > > > protocol onward to its final recipient, but can send back a status > > > > report to the sender noting the confirmed lack of delivery. I > > > > suggest adding some form of qualifier to admit the possibility of > > > > such unusual situations. > > > > > > > > Section 1 > > > > > > > > missing. However, despite our best intentions and most robust > > > > mechanisms we cannot place ultimate faith in receiving such > > > > acknowledgments, but can only truly depend on the passage of time. > > > > Therefore, our ultimate backstop to ensuring that we detect all loss > > > > is a timeout. [...] > > > > > > > > Despite the superficial similarity of tone, a strict reading of > > > > these words does not seem to share the issue I raised about the > > > > Abstract. (That said, this phrasing still seems a bit overblown > > > > and my personal preference would be to tone it down some.) > > > > > > The point is objectively true and actually meant to be absolute. > > > Yes, an explicit non-delivery notification can be sent. Such > > > notifications may be useful and even quite important. But, > > > ultimately, we cannot be rely upon such things to ensure reliable > > > communications because they themselves may get lost, corrupted, > > > delayed, etc. But, if time somehow stops marching forward then > > > .... well, WGAS about the packets?! :) > > > > > > Too me this is a crucial protocol building touchstone. One has to > > > think about what we can and cannot count on. And to what degree. > > > > > > > Section 2 > > > > > > > > - This document does not update or obsolete any existing RFC. > > > > These previous specifications---while generally consistent with > > > > the requirements in this document---reflect community consensus > > > > and this document does not change that consensus. > > > > > > > > - The requirements in this document are meant to provide for > > > > network safety and, as such, SHOULD be used by all time-based > > > > loss detection mechanisms. > > > > > > > > I'm not sure that I understand how the combinations of these two > > > > statements apply to existing specifications. Is there some sense that > > > > existing specs might leave some flexibility and when there is such > > > > flexibility, implementations/deployments SHOULD use the flexibility to > > > > match this document as closely as possible? Or are existing deployments > > > > and implementations of existing RFCs also grandfathered out? If the > > > > intent of the second bullet is to only apply to new protocols, please > > > > say so explicitly. (Section 4 seems to imply the "only new protocols" > > > > case, but it's hard to be sure.) > > > > > > The first bullet is intended to be backwards looking and the second > > > bullet is intended to be forward looking. A few extra words there > > > to make the second bullet more clear would be (in hindsight!) > > > useful. > > > > > > > - The requirements in this document may not be appropriate in all > > > > cases and, therefore, inconsistent deviations and variants may > > > > be necessary (hence the "SHOULD" in the last bullet). However, > > > > inconsistencies MUST be (a) explained and (b) gather consensus. > > > > > > > > Similarly, is this statement only forward-looking? Presumably the first > > > > bullet ("does not update or obsolete any existing") trumps this one, but > > > > it's good to be clear. > > > > > > Yes- forward looking. Clarifying words to be added. > > > > > > > Additionally, I share the GenART reviewer's unease with this > > > > strong of a requirement and have low confidence that the IETF will > > > > reliably adhere to it in the future. > > > > > > In fairness to Stewart---even though I disagree with him---I think > > > his point is broader than just non-adherence. (Stewart and I have > > > iterated on his comments and in fact a number of his LC comments > > > made the document better. But, on this point we just fundamentally > > > disagreed.) > > > > > > I don't presume to speak for Stewart, but I believe he fears this > > > will become a touchstone for area-on-area warfare whereby perfectly > > > justifiable deviations won't be well understood as "perfectly > > > justifiable" by folks not intimate with the given context. And, > > > this will in turn hold things up. And, he seems especially > > > concerned about cases where we want to update something that has > > > been used forever and, yet, deviates from rto-consider. > > > > > > My take is three-fold ... > > > > > > - First, this statement in rto-consider really doesn't change > > > anything, IMO. If we're not explaining why we're doing things > > > and not getting consensus then we shouldn't be publishing it. > > > > > > - Second, this explicit statement was added to get WG consensus. > > > Removing it or softening it would, I believe, run counter to the > > > consensus the document has already gathered. > > > > > > - Third, IMO, saying a given mechanism has proven to be fine in a > > > given context should really be enough justification. That is, > > > yeah, I can see that some protocol lawyer could be pedantic. > > > And, that might be annoying, I guess. But, I think reasonable > > > people should be able to form a consensus that rebuts such > > > things. > > > > > > > Section 3 > > > > > > > > (S.1) The requirements in this document apply only to the primary or > > > > last resort time-based loss detection. > > > > > > > > I'm not sure I understand what "primary or last resort [sic]" means. > > > > Are there time-based loss-detection mechanisms that are neither primary > > > > nor last resort? (nit: hyphenate "last-resort" as a compound adjective, > > > > and many other compound adjectives throughout.) > > > > (May also affect S.2.) > > > > I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary > > > > non-last-resort schemes, however, I think we should be more clear about > > > > what we mean when we introduce the term and why we exclude certain > > > > classes of time-based loss-detection mechanisms. > > > > > > > > detectors. However, these mechanisms do not obviate the need > > > > for a "retransmission timeout" or "RTO" because---as we > > > > discuss in Section 1---only the passage of time can ultimately > > > > be relied upon to detect loss. In cases such as these, the > > > > > > > > [This text is more like the Abstract's, implying that the passage of > > > > time is the only way to detect loss, universally] > > > > > > I dunno. I would have to think about this a bit. As you say, we > > > tried to sprinkle in references to non-last-resort timers. Perhaps > > > there are some words we can add here to explain things better. > > > You're the first one to trip on this. But, I'd be happy to go > > > through this text and think about it again. > > > > > > > Section 4 > > > > > > > > In other words, the RTO should represent an empirically- > > > > derived reasonable amount of time that the sender should > > > > wait for delivery confirmation before deciding the given > > > > data is lost. Network paths are inherently dynamic and > > > > therefore it is crucial to incorporate multiple FT samples > > > > in the RTO to take into account the delay variation across > > > > time. > > > > > > > > It feels weird to say that the delay will vary over time here but say > > > > nothing about the corresponding need to discount very old FT samples. > > > > Point (b) talks about adding new samples in, but not about removing or > > > > discounting old samples. That the TCP example does exhibit this > > > > property does not excuse a lack of explicit mention as a property of > > > > note. > > > > > > I think a note that says "it's fine to discount old samples" is OK > > > and perfectly within the spirit of the guideline. I don't want to > > > overly specify that one has to do this. > > > > > > > (d) An RTO mechanism MUST NOT use ambiguous FT samples. > > > > > > > > Assume two copies of some segment X are transmitted at times > > > > t0 and t1 and then at time t2 the sender receives > > > > confirmation that X in fact arrived. In some cases, it is > > > > > > > > "segment" feels like use of TCP-specific terminology without disclaimer > > > > or generalization. > > > > > > (I can change this to 'packet'.) > > > > > > > (3) Loss detected by the RTO mechanism MUST be taken as an > > > > indication of network congestion and the sending rate adapted > > > > using a standard mechanism (e.g., TCP collapses the congestion > > > > window to one segment [RFC5681]). > > > > [...] > > > > An exception to this rule is if an IETF standardized mechanism > > > > determines that a particular loss is due to a non-congestion > > > > event (e.g., packet corruption). In such a case a congestion > > > > > > > > If it's a MUST with an exception, doesn't that make it ... no longer a > > > > MUST? > > > > > > I don't think so. But, you're no doubt a better protocol lawyer > > > than I am. I believe this says you really have to do this, but > > > there is a **very precise way** to get out of it. If we made this a > > > SHOULD then it would be very much looser---i.e., you really ought to > > > do this unless you have a good reason. Here we are telling you what > > > the good reason has to look like. > > > > > > > (4) Each time the RTO is used to detect a loss, the value of the RTO > > > > MUST be exponentially backed off such that the next firing > > > > requires a longer interval. [...] > > > > > > > > Do we expect this to be exponential backoff by doubling, or is it > > > > admissible to use an alternative base for the exponent? (Is there > > > > a minimum allowable value? E.g., 1.000001 does not seem like it > > > > would provide much protection for the network.) > > > > > > The document does not say to double the RTO. It means to not > > > specify the constant. > > > > > > Again, the document is meant to get away from specifics where we > > > can. I don't know how to set the minimal acceptable backoff. I > > > think we'd all agree 1.000001 is not really going to cut it. But, > > > would 1.8? How about 1.7? What about 1.3? I believe the consensus > > > is that "exponential backoff" is enough. > > > > > > > Further, a number of implementations use a steady-state minimum RTO > > > > that are less than the 1 second specified in [RFC6298] (which is > > > > different from the initial RTO we specify in Section 4, Requirement > > > > 1). While the implication of these deviations from the standard may > > > > > > > > Just to check: our requirement 1 is the same as RFC 6298, and the "less > > > > than 1 second" is what's different. Perhaps wording this akin to "and > > > > as such is in violation of the RTO specified in Requirement 1 from > > > > Section 4" would avoid the ambiguity about what is different from what. > > > > > > Well. Um. I read it many times, but cannot understand what you > > > wrote about the document's ambiguity! ;-) Maybe that is my lack of > > > coffee, I dunno. But, let me try anyway ... > > > > > > RFC 6298 says the INITIAL RTO should be no less than 1sec. That > > > agrees with rto-consider (requirement 1). > > > > > > RFC 6298 further says the MINIMUM RTO over the entire lifetime of a > > > TCP connection should be no less than 1sec. There is no > > > corresponding admonishment in rto-consider. > > > > > > Probably because these two things are both "1sec" in TCP a lot of > > > people have gotten them mixed up in their minds during the > > > development of this document. The parenthetical you quote was no > > > doubt meant to clarify to someone. But, this discussion can be > > > cleaned up, probably. > > > > > > > Section 6 > > > > > > > > Noting that we incorporate the security considerations of RFC 6298 > > > > by reference, and quoting from there: > > > > > > > > In addition, even if the attacker can cause the sender's RTO to reach > > > > too small a value, it appears the attacker cannot leverage this into > > > > much of an attack (compared to the other damage they can do if they > > > > can spoof packets belonging to the connection), since the sending TCP > > > > will still back off its timer in the face of an incorrectly > > > > transmitted packet's loss due to actual congestion. > > > > > > > > Just to check my understanding: this "actual congestion" would > > > > need to be between the sender and the attacker, right? Since the > > > > attacker's spoofed ACKs would cause the sender to not detect loss > > > > due to congestion that occurs between the attacker and the > > > > intended recipient. > > > > > > Oh boy. My brain is thrashing to try to page back in RFC6298. > > > > > > The above text isn't the most clear, so I assume I didn't write > > > it. :) > > > > > > Hmm. > > > > > > I think the basic point is that if an attacker can spoof they can do > > > much worse than impacting the computation of the RTO. And, if what > > > they want to do is mess with a connection's performance and not the > > > reliability of the connection---say because that'd be > > > user-visible---then they cannot hide real losses. And, since they > > > cannot hide real losses then from a network safety perspective this > > > all fails safely because the endpoint will backoff when detecting > > > those losses. > > > > > > > References > > > > > > > > The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6298]") > > > > implies that it should be categorized as normative. Similarly for RFC > > > > 6298 itself. > > > > > > I dunno. The entirety of the algorithm is given in rto-consider. > > > So, the reference is really meant to give credit and point people at > > > a place to read about it in more detail instead of as a pointer that > > > must be understood to enact the guideline. Perhaps just a > > > restructuring ... > > > > > > Therefore, in this situation an implementation MUST use Karn's > > > algorithm and use neither version of the FT sample and hence not > > > update the RTO (see [KP87,RFC6298] for a broader discussion of > > > Karn's algorithm). > > > > > > Or, put them under "Normative". I really don't much care. > > > > > > > [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC > > > > 2134, June 2001. > > > > > > > > Fix the typo, please -- RFC 2134 is the articles of incorporation of > > > > ISOC. > > > > > > Well, I do not want to be anywhere near ISOC anything! Good catch, > > > thanks! (And, what a weird typo ... all the digits are there, but > > > in such a weird order ...) > > > > > > allman > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > -- > Rod Grimes rgrimes@freebsd.org From nobody Sat Jul 11 00:35:53 2020 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 ADBDD3A0407; Sat, 11 Jul 2020 00:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 JgRBo7IIqQoH; Sat, 11 Jul 2020 00:35:44 -0700 (PDT) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473F93A0403; Sat, 11 Jul 2020 00:35:44 -0700 (PDT) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 06B7ZaUo098663; Sat, 11 Jul 2020 00:35:36 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net) Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 06B7ZZn1098662; Sat, 11 Jul 2020 00:35:35 -0700 (PDT) (envelope-from ietf) From: "Rodney W. Grimes" Message-Id: <202007110735.06B7ZZn1098662@gndrsh.dnsmgr.net> In-Reply-To: <20200711025501.GM16335@kduck.mit.edu> To: Benjamin Kaduk Date: Sat, 11 Jul 2020 00:35:35 -0700 (PDT) CC: "Rodney W. Grimes" , Martin Duke , Mark Allman , tcpm-chairs , "tcpm@ietf.org Extensions" , draft-ietf-tcpm-rto-consider@ietf.org, The IESG X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT) 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, 11 Jul 2020 07:35:47 -0000 Hello Ben, > Hi Rod, > > On Thu, Jul 09, 2020 at 08:55:09AM -0700, Rodney W. Grimes wrote: > > Martin, Benjamin, etc el: > > > > > Benjamin and I discussed this briefly in the telechat. I would summarize as > > > follows: > > > > > > - We seem to have clear agreement on all but the first DISCUSS point > > > - We should probably say something about the security implications of > > > spoofed acks but not be too specific. The document doesn't really have a > > > section (that I can find right now) that discusses the properties of ACKs, > > > so perhaps the best place to put this is in security considerations. > > > > Isn't it a mistake to discuss in "security considerations" a > > topic that is not in the main body of the document? > > Generally, yes. What is "the topic" you were thinking of? spoofed acks, or a security precaution regarding acks. > > I see us talk about using acknowledgments to get RTT samples. I also see > us talk about how the absence of an ACK is a signal for loss. However, in > some cases, the inverse is not true: the presence of an ACK is not a > reliable signal for completed delivery. In other words, best practices for > detecing loss include both being confident there is loss and being confident > there is not loss, and you have to worry about off-path attacks to use > in-protocol ACKs to be confident there is not loss. Crypto is a great way > to protect your ACKs from off-path attacks, but is not the only way to do > so. The abstract of the document only says "detection of loss" it does not mention detecting "non loss" so I would consider non loss detection out of scope. Further nothing in section 3 mentions your "confident there is not loss." Perhaps the scope needs to have that? Further I see nothing in the section 3 "Scope" that speaks to protection of ACKs. It specifically state that this is a "protocol-agnostic" draft, I would consider an ACK to be protocol specific, in particular it is specific to several transport protocols that are connection oriented. Hence I assert speaking of security concerns for ACKs is out of scope, or additional scope needs added to section 3. > > I do note that I qualified my remark with quite a long predicate, and have > not really seen anyone attempting to confirm or reject that predicate as > being the goal of the document. I would need to go back to that email containing the long predicate to respond to this. > > > Something to the effect of > > > > > > "An attacker could spoof a sufficient number of receiver messages to either > > > alter the feedback time calculation, or indicate the receipt of packets > > > that did not actually arrive at the receiver. Endpoints SHOULD include > > > measures to make it hard for off-path attackers to guess the fields of > > > these packets to mitigate this attack" > > > > Such an ambigous statement added without discussion of how one might > > implment a "measure to make it hard" for an implementer would be > > a No-op as I have nothing to base what it is I SHOULD do from this > > document, nor any reference to another document. > > > > IMHO, trying to address off-path attacks in this draft is out of scope. > > Perhaps you could say what you think the scope is, then? See above, and section 3 of the document. > > > The specification of those details should be in the transport protocol > > itself, not in a generized document such as this, as it is only in > > those documents that methods to mitigate attacks can reasonably be > > documented. Perhaps say that "transport protocols SHOULD document > > techniques for mitigation against attacks that could perturb the > > estimate of RTT"? But even that is, IMHO, beyond the scope of what > > this document should be covering as now it is saying what other > > documents should contain. > > > > I understand the desire to say something about the issues of > > an off path attack, but is this document really the right place > > to try and address that concern? > > If you want an accurate loss signal, you need an accurate non-loss signal. Then the scope of this document needs amended to say that accurate non-loss signals are in scope and then go on to define exactly what an accurate non-loss signal is. > I think it's appropriate to make a note of that, along with some indication > of what's needed to get an accurate non-loss signal, in the context of the > BCP 72 threat model. Exactly what words we use to give that indication are > not terribly important to me (and I note that anything we say in this > document is subject to the "SHOULD be used by all time-based loss detection > mechanisms" from Section 2, so even nominally MUST-level requirements still > have an escape clause). > > -Ben > > > > Together with the agreed fixes, this should be enough to move forward. > > > > > > Martin > > > > > > On Tue, Jul 7, 2020 at 8:01 AM Mark Allman > > > wrote: > > > > > > > > > > > Hi Benjamin! > > > > > > > > > ---------------------------------------------------------------------- > > > > > DISCUSS: > > > > > ---------------------------------------------------------------------- > > > > > > > > > > If we are providing BCP-level requirements for time-based loss > > > > > detection via absence of protocol-level acknowledgment, for new > > > > > protocols, it seems appropriate to mandate that the acknowledgment > > > > > signal is reliable, i.e., not spoofable by at least an off-path > > > > > attacker, and ideally not spoofable by an on-path attacker either. > > > > > I would love for this to be a cryptographically protected > > > > > mechanism, but expect that I can't get away with mandating > > > > > something that strong, and that something with "enough bits of > > > > > entropy" will suffice. (I'd prefer "enough" to be 128 but could > > > > > perhaps be persuaded that a lower value is appropriate as a > > > > > minimum requirement.) > > > > > > > > I have been thinking about this since yesterday and have a few > > > > thoughts ... > > > > > > > > - In some sense, I like the general thought. It would tighten > > > > things up. > > > > > > > > - That said, pragmatically, I think the risk from spoofed ACKs is > > > > pretty small. For instance, if you want to screw up the RTO you > > > > need to pretty continuously screw up the FT measurements for > > > > anything long running. So, it isn't enough to guess and inject > > > > correctly once, but you have to do so on an ongoing basis. And, > > > > with much less than 128 bits of entropy something like TCP is > > > > not particularly susceptible to this sort of thing. > > > > > > > > - And, so we can obviously make up a requirement for future > > > > protocols here, but I don't think that will be a "BCP" or even > > > > "CP". It would not be like the rest of the document where the > > > > aspects of loss detection are well understood. > > > > > > > > - And, we'd have to decide what we meant by "new protocol". Is > > > > that some wholly new thing or is that a new algorithm for SCTP > > > > or TCP or DNS? > > > > > > > > - Perhaps there is some non-normative note that could be added > > > > that folks are encouraged to think about making the feedback > > > > non-spoofable for FT measurements (among many other reasons, of > > > > course). I dunno ... > > > > > > > > > Point S.3 in Section 3 indicates that "[t]he requirements in this > > > > > document apply only to endpoint-to- endpoint unicast > > > > > communication. Reliable multicast (e.g., [RFC5740]) protocols are > > > > > explicitly outside the scope of this document." This limitation > > > > > of scope should be reflected in the document's title, Abstract, > > > > > and Introduction. > > > > > > > > (A note can be added.) > > > > > > > > > I would also like to get an explicit confirmation that the various > > > > > (non-)requirements on the details of exponential backoff and > > > > > reduced weighting for old FT samples are as-intended (see > > > > > COMMENT). Specifically, are there limitations on the base of the > > > > > exponent for the exponential backoff, and is there a requirement > > > > > to give more recent FT samples more precedence than older FT > > > > > samples when computing an RTO estimate? > > > > > > > > Yes- the intent is to not specify the details. The basic gist of > > > > the document is that we have learned that the details are not hugely > > > > important and so getting away from them is fine. > > > > > > > > > ---------------------------------------------------------------------- > > > > > COMMENT: > > > > > ---------------------------------------------------------------------- > > > > > > > > > > Abstract > > > > > > > > > > of congestion along a network path). While many mechanisms have > > > > > been designed to detect loss, protocols ultimately can only count on > > > > > the passage of time without delivery confirmation to declare a > > > > > packet "lost". Each implementation of a time-based loss detection > > > > > > > > > > I'm not entirely convinced that the literal meaning of what these > > > > > words say is universally true for all protocols (specifically "can > > > > > only count on" and omitting a qualifier such as "many" or "most" > > > > > protocols or "reliably count on"). Consider, for example, the DTN > > > > > bundle protocol, which has some circumstances in which a given > > > > > store-and-forward node will flat-out not attempt to forward a > > > > > protocol onward to its final recipient, but can send back a status > > > > > report to the sender noting the confirmed lack of delivery. I > > > > > suggest adding some form of qualifier to admit the possibility of > > > > > such unusual situations. > > > > > > > > > > Section 1 > > > > > > > > > > missing. However, despite our best intentions and most robust > > > > > mechanisms we cannot place ultimate faith in receiving such > > > > > acknowledgments, but can only truly depend on the passage of time. > > > > > Therefore, our ultimate backstop to ensuring that we detect all loss > > > > > is a timeout. [...] > > > > > > > > > > Despite the superficial similarity of tone, a strict reading of > > > > > these words does not seem to share the issue I raised about the > > > > > Abstract. (That said, this phrasing still seems a bit overblown > > > > > and my personal preference would be to tone it down some.) > > > > > > > > The point is objectively true and actually meant to be absolute. > > > > Yes, an explicit non-delivery notification can be sent. Such > > > > notifications may be useful and even quite important. But, > > > > ultimately, we cannot be rely upon such things to ensure reliable > > > > communications because they themselves may get lost, corrupted, > > > > delayed, etc. But, if time somehow stops marching forward then > > > > .... well, WGAS about the packets?! :) > > > > > > > > Too me this is a crucial protocol building touchstone. One has to > > > > think about what we can and cannot count on. And to what degree. > > > > > > > > > Section 2 > > > > > > > > > > - This document does not update or obsolete any existing RFC. > > > > > These previous specifications---while generally consistent with > > > > > the requirements in this document---reflect community consensus > > > > > and this document does not change that consensus. > > > > > > > > > > - The requirements in this document are meant to provide for > > > > > network safety and, as such, SHOULD be used by all time-based > > > > > loss detection mechanisms. > > > > > > > > > > I'm not sure that I understand how the combinations of these two > > > > > statements apply to existing specifications. Is there some sense that > > > > > existing specs might leave some flexibility and when there is such > > > > > flexibility, implementations/deployments SHOULD use the flexibility to > > > > > match this document as closely as possible? Or are existing deployments > > > > > and implementations of existing RFCs also grandfathered out? If the > > > > > intent of the second bullet is to only apply to new protocols, please > > > > > say so explicitly. (Section 4 seems to imply the "only new protocols" > > > > > case, but it's hard to be sure.) > > > > > > > > The first bullet is intended to be backwards looking and the second > > > > bullet is intended to be forward looking. A few extra words there > > > > to make the second bullet more clear would be (in hindsight!) > > > > useful. > > > > > > > > > - The requirements in this document may not be appropriate in all > > > > > cases and, therefore, inconsistent deviations and variants may > > > > > be necessary (hence the "SHOULD" in the last bullet). However, > > > > > inconsistencies MUST be (a) explained and (b) gather consensus. > > > > > > > > > > Similarly, is this statement only forward-looking? Presumably the first > > > > > bullet ("does not update or obsolete any existing") trumps this one, but > > > > > it's good to be clear. > > > > > > > > Yes- forward looking. Clarifying words to be added. > > > > > > > > > Additionally, I share the GenART reviewer's unease with this > > > > > strong of a requirement and have low confidence that the IETF will > > > > > reliably adhere to it in the future. > > > > > > > > In fairness to Stewart---even though I disagree with him---I think > > > > his point is broader than just non-adherence. (Stewart and I have > > > > iterated on his comments and in fact a number of his LC comments > > > > made the document better. But, on this point we just fundamentally > > > > disagreed.) > > > > > > > > I don't presume to speak for Stewart, but I believe he fears this > > > > will become a touchstone for area-on-area warfare whereby perfectly > > > > justifiable deviations won't be well understood as "perfectly > > > > justifiable" by folks not intimate with the given context. And, > > > > this will in turn hold things up. And, he seems especially > > > > concerned about cases where we want to update something that has > > > > been used forever and, yet, deviates from rto-consider. > > > > > > > > My take is three-fold ... > > > > > > > > - First, this statement in rto-consider really doesn't change > > > > anything, IMO. If we're not explaining why we're doing things > > > > and not getting consensus then we shouldn't be publishing it. > > > > > > > > - Second, this explicit statement was added to get WG consensus. > > > > Removing it or softening it would, I believe, run counter to the > > > > consensus the document has already gathered. > > > > > > > > - Third, IMO, saying a given mechanism has proven to be fine in a > > > > given context should really be enough justification. That is, > > > > yeah, I can see that some protocol lawyer could be pedantic. > > > > And, that might be annoying, I guess. But, I think reasonable > > > > people should be able to form a consensus that rebuts such > > > > things. > > > > > > > > > Section 3 > > > > > > > > > > (S.1) The requirements in this document apply only to the primary or > > > > > last resort time-based loss detection. > > > > > > > > > > I'm not sure I understand what "primary or last resort [sic]" means. > > > > > Are there time-based loss-detection mechanisms that are neither primary > > > > > nor last resort? (nit: hyphenate "last-resort" as a compound adjective, > > > > > and many other compound adjectives throughout.) > > > > > (May also affect S.2.) > > > > > I see S.2 links to [DCCM13,CCDJ20,IS20] as examples of non-primary > > > > > non-last-resort schemes, however, I think we should be more clear about > > > > > what we mean when we introduce the term and why we exclude certain > > > > > classes of time-based loss-detection mechanisms. > > > > > > > > > > detectors. However, these mechanisms do not obviate the need > > > > > for a "retransmission timeout" or "RTO" because---as we > > > > > discuss in Section 1---only the passage of time can ultimately > > > > > be relied upon to detect loss. In cases such as these, the > > > > > > > > > > [This text is more like the Abstract's, implying that the passage of > > > > > time is the only way to detect loss, universally] > > > > > > > > I dunno. I would have to think about this a bit. As you say, we > > > > tried to sprinkle in references to non-last-resort timers. Perhaps > > > > there are some words we can add here to explain things better. > > > > You're the first one to trip on this. But, I'd be happy to go > > > > through this text and think about it again. > > > > > > > > > Section 4 > > > > > > > > > > In other words, the RTO should represent an empirically- > > > > > derived reasonable amount of time that the sender should > > > > > wait for delivery confirmation before deciding the given > > > > > data is lost. Network paths are inherently dynamic and > > > > > therefore it is crucial to incorporate multiple FT samples > > > > > in the RTO to take into account the delay variation across > > > > > time. > > > > > > > > > > It feels weird to say that the delay will vary over time here but say > > > > > nothing about the corresponding need to discount very old FT samples. > > > > > Point (b) talks about adding new samples in, but not about removing or > > > > > discounting old samples. That the TCP example does exhibit this > > > > > property does not excuse a lack of explicit mention as a property of > > > > > note. > > > > > > > > I think a note that says "it's fine to discount old samples" is OK > > > > and perfectly within the spirit of the guideline. I don't want to > > > > overly specify that one has to do this. > > > > > > > > > (d) An RTO mechanism MUST NOT use ambiguous FT samples. > > > > > > > > > > Assume two copies of some segment X are transmitted at times > > > > > t0 and t1 and then at time t2 the sender receives > > > > > confirmation that X in fact arrived. In some cases, it is > > > > > > > > > > "segment" feels like use of TCP-specific terminology without disclaimer > > > > > or generalization. > > > > > > > > (I can change this to 'packet'.) > > > > > > > > > (3) Loss detected by the RTO mechanism MUST be taken as an > > > > > indication of network congestion and the sending rate adapted > > > > > using a standard mechanism (e.g., TCP collapses the congestion > > > > > window to one segment [RFC5681]). > > > > > [...] > > > > > An exception to this rule is if an IETF standardized mechanism > > > > > determines that a particular loss is due to a non-congestion > > > > > event (e.g., packet corruption). In such a case a congestion > > > > > > > > > > If it's a MUST with an exception, doesn't that make it ... no longer a > > > > > MUST? > > > > > > > > I don't think so. But, you're no doubt a better protocol lawyer > > > > than I am. I believe this says you really have to do this, but > > > > there is a **very precise way** to get out of it. If we made this a > > > > SHOULD then it would be very much looser---i.e., you really ought to > > > > do this unless you have a good reason. Here we are telling you what > > > > the good reason has to look like. > > > > > > > > > (4) Each time the RTO is used to detect a loss, the value of the RTO > > > > > MUST be exponentially backed off such that the next firing > > > > > requires a longer interval. [...] > > > > > > > > > > Do we expect this to be exponential backoff by doubling, or is it > > > > > admissible to use an alternative base for the exponent? (Is there > > > > > a minimum allowable value? E.g., 1.000001 does not seem like it > > > > > would provide much protection for the network.) > > > > > > > > The document does not say to double the RTO. It means to not > > > > specify the constant. > > > > > > > > Again, the document is meant to get away from specifics where we > > > > can. I don't know how to set the minimal acceptable backoff. I > > > > think we'd all agree 1.000001 is not really going to cut it. But, > > > > would 1.8? How about 1.7? What about 1.3? I believe the consensus > > > > is that "exponential backoff" is enough. > > > > > > > > > Further, a number of implementations use a steady-state minimum RTO > > > > > that are less than the 1 second specified in [RFC6298] (which is > > > > > different from the initial RTO we specify in Section 4, Requirement > > > > > 1). While the implication of these deviations from the standard may > > > > > > > > > > Just to check: our requirement 1 is the same as RFC 6298, and the "less > > > > > than 1 second" is what's different. Perhaps wording this akin to "and > > > > > as such is in violation of the RTO specified in Requirement 1 from > > > > > Section 4" would avoid the ambiguity about what is different from what. > > > > > > > > Well. Um. I read it many times, but cannot understand what you > > > > wrote about the document's ambiguity! ;-) Maybe that is my lack of > > > > coffee, I dunno. But, let me try anyway ... > > > > > > > > RFC 6298 says the INITIAL RTO should be no less than 1sec. That > > > > agrees with rto-consider (requirement 1). > > > > > > > > RFC 6298 further says the MINIMUM RTO over the entire lifetime of a > > > > TCP connection should be no less than 1sec. There is no > > > > corresponding admonishment in rto-consider. > > > > > > > > Probably because these two things are both "1sec" in TCP a lot of > > > > people have gotten them mixed up in their minds during the > > > > development of this document. The parenthetical you quote was no > > > > doubt meant to clarify to someone. But, this discussion can be > > > > cleaned up, probably. > > > > > > > > > Section 6 > > > > > > > > > > Noting that we incorporate the security considerations of RFC 6298 > > > > > by reference, and quoting from there: > > > > > > > > > > In addition, even if the attacker can cause the sender's RTO to reach > > > > > too small a value, it appears the attacker cannot leverage this into > > > > > much of an attack (compared to the other damage they can do if they > > > > > can spoof packets belonging to the connection), since the sending TCP > > > > > will still back off its timer in the face of an incorrectly > > > > > transmitted packet's loss due to actual congestion. > > > > > > > > > > Just to check my understanding: this "actual congestion" would > > > > > need to be between the sender and the attacker, right? Since the > > > > > attacker's spoofed ACKs would cause the sender to not detect loss > > > > > due to congestion that occurs between the attacker and the > > > > > intended recipient. > > > > > > > > Oh boy. My brain is thrashing to try to page back in RFC6298. > > > > > > > > The above text isn't the most clear, so I assume I didn't write > > > > it. :) > > > > > > > > Hmm. > > > > > > > > I think the basic point is that if an attacker can spoof they can do > > > > much worse than impacting the computation of the RTO. And, if what > > > > they want to do is mess with a connection's performance and not the > > > > reliability of the connection---say because that'd be > > > > user-visible---then they cannot hide real losses. And, since they > > > > cannot hide real losses then from a network safety perspective this > > > > all fails safely because the endpoint will backoff when detecting > > > > those losses. > > > > > > > > > References > > > > > > > > > > The way we cite [KP87] ("MUST use Karn's algorithm [KP87,RFC6298]") > > > > > implies that it should be categorized as normative. Similarly for RFC > > > > > 6298 itself. > > > > > > > > I dunno. The entirety of the algorithm is given in rto-consider. > > > > So, the reference is really meant to give credit and point people at > > > > a place to read about it in more detail instead of as a pointer that > > > > must be understood to enact the guideline. Perhaps just a > > > > restructuring ... > > > > > > > > Therefore, in this situation an implementation MUST use Karn's > > > > algorithm and use neither version of the FT sample and hence not > > > > update the RTO (see [KP87,RFC6298] for a broader discussion of > > > > Karn's algorithm). > > > > > > > > Or, put them under "Normative". I really don't much care. > > > > > > > > > [RFC3124] Balakrishnan, H., S. Seshan, "The Congestion Manager", RFC > > > > > 2134, June 2001. > > > > > > > > > > Fix the typo, please -- RFC 2134 is the articles of incorporation of > > > > > ISOC. > > > > > > > > Well, I do not want to be anywhere near ISOC anything! Good catch, > > > > thanks! (And, what a weird typo ... all the digits are there, but > > > > in such a weird order ...) > > > > > > > > allman > > > > _______________________________________________ > > > > tcpm mailing list > > > > tcpm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > -- > > Rod Grimes rgrimes@freebsd.org > -- Rod Grimes rgrimes@freebsd.org From nobody Mon Jul 13 00:22:42 2020 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 4B0A33A0924; Mon, 13 Jul 2020 00:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.017 X-Spam-Level: X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 jCm_eGAY3Vn8; Mon, 13 Jul 2020 00:22:40 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20703A0922; Mon, 13 Jul 2020 00:22:39 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 06D7MYmk057829; Mon, 13 Jul 2020 09:22:34 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id E75B11D53C1; Mon, 13 Jul 2020 09:22:32 +0200 (CEST) Received: from 83.38.107.8 by webmail.entel.upc.edu with HTTP; Mon, 13 Jul 2020 09:22:33 +0200 Message-ID: In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Mon, 13 Jul 2020 09:22:33 +0200 From: "Carles Gomez Montenegro" To: "tcpm-chairs" Cc: Jon.Crowcroft@cl.cam.ac.uk, "tcpm@ietf.org" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at dash X-Virus-Status: Clean X-Greylist: ACL matched, not delayed by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Mon, 13 Jul 2020 09:22:34 +0200 (CEST) Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) 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, 13 Jul 2020 07:22:41 -0000 Dear chairs, We would like to request a presentation slot for IETF 108. Please find next the details of the request: * Draft name / presentation title: draft-gomez-tcpm-ack-rate-request-00 * Presenter: Carles Gomez * Total duration (including Q&A): 10 minutes Thanks, Carles > Hi all, > > Given that we had a pretty packed agenda during the virtual interim > meeting, the chairs have asked for two slots during IETF 108. This > basically implies that we have again the 2:30 hour slot that TCPM used to > have for many years. > > According to the draft agenda for IETF 108, TCPM has been scheduled for > Monday Session I (1:40) and Monday Session II (0:50). > > If you are interested in presenting, please let the chairs know until > **Monday 2020-07-13**: > > * Draft name / presentation title > * Presenter > * Total duration (including Q&A) > > Thanks > > Michael (2x) and Yoshi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Jul 13 00:31:49 2020 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 5188D3A0996 for ; Mon, 13 Jul 2020 00:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.017 X-Spam-Level: X-Spam-Status: No, score=-0.017 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 mQv3NaA4Qv_R for ; Mon, 13 Jul 2020 00:31:45 -0700 (PDT) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) (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 8451F3A098C for ; Mon, 13 Jul 2020 00:31:45 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id 06D7VdtG038780; Mon, 13 Jul 2020 09:31:39 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 8B5A81D53C1; Mon, 13 Jul 2020 09:31:39 +0200 (CEST) Received: from 83.38.107.8 by webmail.entel.upc.edu with HTTP; Mon, 13 Jul 2020 09:31:39 +0200 Message-ID: <9414a057dfeb5b49d8fa4839867737b7.squirrel@webmail.entel.upc.edu> Date: Mon, 13 Jul 2020 09:31:39 +0200 From: "Carles Gomez Montenegro" To: tcpm@ietf.org Cc: Jon.Crowcroft@cl.cam.ac.uk User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.3 at violet X-Virus-Status: Clean X-Greylist: Delayed for 00:09:05 by milter-greylist-4.3.9 (violet.upc.es [147.83.2.51]); Mon, 13 Jul 2020 09:31:39 +0200 (CEST) Archived-At: Subject: [tcpm] [Fwd: New Version Notification for draft-gomez-tcpm-ack-rate-request-00.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 07:31:47 -0000 Dear WG, First of all, thanks to everyone who contributed to the discussion on our earlier document, draft-gomez-tcpm-delack-suppr-reqs. With the aim of reflecting the outcome of that discussion, we just submitted a new Internet Draft entitled "TCP ACK Rate Request Option", as shown below. Comments will be appreciated. Thanks, Carles and Jon ---------------------------- Original Message ---------------------------- Subject: New Version Notification for draft-gomez-tcpm-ack-rate-request-00.txt From: internet-drafts@ietf.org Date: Mon, July 13, 2020 9:13 am To: "Carles Gomez" "Jon Crowcroft" -------------------------------------------------------------------------- A new version of I-D, draft-gomez-tcpm-ack-rate-request-00.txt has been successfully submitted by Carles Gomez and posted to the IETF repository. Name: draft-gomez-tcpm-ack-rate-request Revision: 00 Title: TCP ACK Rate Request Option Document date: 2020-07-13 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/internet-drafts/draft-gomez-tcpm-ack-rate-request-00.txt Status: https://datatracker.ietf.org/doc/draft-gomez-tcpm-ack-rate-request/ Htmlized: https://tools.ietf.org/html/draft-gomez-tcpm-ack-rate-request-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-gomez-tcpm-ack-rate-request Abstract: TCP Delayed Acknowledgments (ACKs) is a widely deployed mechanism that allows reducing protocol overhead in many scenarios. However, Delayed ACKs may also contribute to suboptimal performance. When a relatively large congestion window (cwnd) can be used, less frequent ACKs may be desirable. On the other hand, in relatively small cwnd scenarios, eliciting an immediate ACK may avoid unnecessary delays that may be incurred by the Delayed ACKs mechanism. This document specifies the TCP ACK Rate Request (TARR) option. This option allows a sender to indicate the ACK rate to be used by a receiver, and it also allows to request an immediate ACK from a receiver. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 13 02:36:53 2020 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 0E9B03A0CE8 for ; Mon, 13 Jul 2020 02:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[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 Pq4HT0a_GXZ7 for ; Mon, 13 Jul 2020 02:36:50 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2101.outbound.protection.outlook.com [40.107.21.101]) (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 1DDD33A0CDD for ; Mon, 13 Jul 2020 02:36:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WUKkQ+zeFYQpqIMVHi+/aIkzZ291q6LXUqCZX4se/QSbcNY6hj3irJdyVQL/Q3gJhc9MNrxvLm7XVsNaAq058xYdy/AIM5G1KXdP2nCzftPVtqb9MAQllAVjkUj1gG7D/iNQB0ZMi8vL14diKHl2gd/rnslErhjyx7Wsn6YTt0QcZ8Ah+v70aJNfpehYiGgtdexzaeCpTNU681UrIktXgYS5/WTc8T8zBe89L5nXNtC2aUmCtOjtDFQYfLMQ2EQ5Fy3UgPFYhll8qSD1WlBSDvsALpKS7tIXkwHeENp0MWK6I3AKLR/+XUs3ADb1vY/2KoYbXue4MuLj6K3MDPej1g== 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=BwIIraIxcNodJ79dw7Eo3YpakJJdEcrmbDDE6IlLXPk=; b=BizW8a3o5eD8+6JFd6jiQcgaD0AF9JXTq4DdE208fo/uLghPLU4wUmmEQgHmJPgFX5PyJTUkB3PoCuNhLHo5AsHKORNN9cA6wKvUlXZzorbhWvIvWQzuNwOcgvFBEkj5FhyZCK/LZmS0axQGE59HY84cM/B9hUuBheVQuWdOZP2yPkV2CgpBd7aDKUdNW0XBZfm8a9JHgeKf7hu0Wuk0w4NGKoqYiMW8JwINNfFXuVt+7ibF0XyaTmaIYn/4YqwiJ5BOjZqyUTDNOHvWKDfkTcxYIIQ0jzePZ40nEmfplN4dA18OA8yQDa2HKma4GPHy+LYyt2tTp+sSsRQDFrIuSQ== 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=BwIIraIxcNodJ79dw7Eo3YpakJJdEcrmbDDE6IlLXPk=; b=bJZfxlHrP0SxLpA1G1v1s7L6T8C9FL6AuVkto+Ro5j59bePwgUwVxeJ/1ABJ3SsmkPNwxuWMIamCvOXO9rGFdGUCrcbOGU3I7a1ezx8aptRY+Id8qT93yx8pDuMQxa9pY2NSviOl1Ztyjozlp56uMf+RPVx3MFSGxNDYxGr9mHI= Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB7PR07MB6057.eurprd07.prod.outlook.com (2603:10a6:10:8e::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.13; Mon, 13 Jul 2020 09:36:47 +0000 Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::f911:a06:2f4e:a103]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::f911:a06:2f4e:a103%4]) with mapi id 15.20.3195.009; Mon, 13 Jul 2020 09:36:47 +0000 From: tom petch To: "Scharf, Michael" , "tcpm@ietf.org" Thread-Topic: Heads-up: draft-ietf-netconf-tcp-client-server-07 Thread-Index: AdZWjKo44LjY7IBqQL2GoSu2bsGOCgCa4gTz Date: Mon, 13 Jul 2020 09:36:47 +0000 Message-ID: References: <6EC6417807D9754DA64F3087E2E2E03E2DC9E3E4@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DC9E3E4@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hs-esslingen.de; dkim=none (message not signed) header.d=none;hs-esslingen.de; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 760019a0-cf2e-4094-0276-08d82710435b x-ms-traffictypediagnostic: DB7PR07MB6057: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2vk3YL24/X0D5uZ/UK9OygGJYGVRDA5kNosQ68K9APeFyqTpxEa272QAdwF0/wytfa1Z+Dntnk3PEzLT2E8aZhy8YW3YacT3yHdl/utwyxD8wIyRbj66xIvshnm3PrAeqSvueRVfWPuL05adIkKIqNBmLxmvoWO6+Aee9bezCWoBDXRxgnXsqOIm5xXprUVRb0SaG3KBwUBnxY5I9tZyYUkQhDCy6l5ZSvtLSZ0zXhGnZgefa4PBIvgI/FxV90a8MbPkBBTL8EWJ74gKnwC3WOHQWNlyXqMIzYxs1VQd4dOR5ZWabS5rJ51G9hmZ+hYtQqj7uwq5CdFp9qYp0mU0LImaFFS+rx8wxHkKyHc4L3+hkCuBk79vcPCNt4CHLBgkkk4IOA/rPgGuaS7COXCklQ== 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:(346002)(136003)(396003)(39860400002)(376002)(366004)(478600001)(5660300002)(52536014)(316002)(71200400001)(110136005)(6506007)(8676002)(53546011)(26005)(8936002)(91956017)(76116006)(186003)(966005)(2906002)(33656002)(66946007)(9686003)(7696005)(64756008)(66446008)(55016002)(66476007)(66556008)(66574015)(83380400001)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: cjVWnaZewriDEKmXc0Spu83xEhckAoXnMJLGa5IfA9nqUllH7TA+ACkIjCE8brrtjlqEsYldSSm+8qRzEbjCcnzsVY3TRBciFPOLEacxItgNH+rFYlpoDKH1qR9X0I2lndI++zRj+zRkSkwDz4eRH6/bcn84ksvhyLZcRwlBhcOJIyJb/sS1X6Fca4dTNSWbIjLKTfErKSVx0sxH7+zyhtCXeLGDzU3NiJ3KbVfY8tJsKt4e1TqqTVlILQab4KGpT3MdxoNqsflvVVqoPQmMgCE/uEbxkPovoEaKO08ST5JT7x02LpRbrU0QV3S2j0PiMBuRDdPtbee7XvLCnxZnV9IkT6AVEfXyvtGZF+r2ig8CrOqKlssG2fQ7HAqN5G//GY8ClX1/YtBtg1JCiH65leYqaTnnfEJr2g9w1OAi9zCVNwyYJFU8MyLw6qc2ykWfC3/ivl6FrVf2JHCT0ey87Fdp+JVWknppZ+NEyBXmeFE= 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5340.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 760019a0-cf2e-4094-0276-08d82710435b X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2020 09:36:47.4933 (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: fPtGlEpuGd2QkNgb88JZMtxkv9alItvHr0qMt/t9uAGwq0V7W38iXi82U6i/2qrSRKYvsgbnwe52/5i+w/I1qw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB6057 Archived-At: Subject: Re: [tcpm] Heads-up: draft-ietf-netconf-tcp-client-server-07 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, 13 Jul 2020 09:36:52 -0000 From: tcpm on behalf of Scharf, Michael =0A= Sent: 10 July 2020 08:51=0A= =0A= Hi all,=0A= =0A= This is a heads-up regarding the latest update of draft-ietf-netconf-tcp-cl= ient-server-07.=0A= =0A= This document is homed in the NETCONF working group. Yet, I believe that it= is important that TCPM is in the loop, too.=0A= =0A= =0A= Michael=0A= =0A= I note that IANA only registers two URI not three and that the Security Con= siderations are not the usual ones (no TLS reference). More fundamentally,= and it is a comment I have made before on netconf I-D, I find it unclear w= ho the introductory text is intended for. It seems to be aimed at a YANG e= xpert who needs little or not introduction to the modules which they will r= everse engineer. This is something that those on the TCP list might see mo= re clearly than those on the Netconf list. This is not a problem that I h= ave with I-D from such as TEAS, CCAMP, RTGWG etc.=0A= =0A= Tom Petch=0A= =0A= Given that the YANG models state ...=0A= =0A= =0A= organization=0A= "IETF NETCONF (Network Configuration) Working Group and the=0A= IETF TCP Maintenance and Minor Extensions (TCPM) Working Group";=0A= =0A= =0A= .... the authors plan to ask for a WGLC not only on the NETCONF list, but a= lso on the TCPM list.=0A= =0A= Michael=0A= (as individual contributor to unusual cross-area documents)=0A= =0A= -----Original Message-----=0A= From: netconf On Behalf Of internet-drafts@ietf.= org=0A= Sent: Thursday, July 9, 2020 2:28 AM=0A= To: i-d-announce@ietf.org=0A= Cc: netconf@ietf.org=0A= Subject: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-07.txt= =0A= =0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= This draft is a work item of the Network Configuration WG of the IETF.=0A= =0A= Title : YANG Groupings for TCP Clients and TCP Servers=0A= Authors : Kent Watsen=0A= Michael Scharf=0A= Filename : draft-ietf-netconf-tcp-client-server-07.txt=0A= Pages : 31=0A= Date : 2020-07-08=0A= =0A= Abstract:=0A= This document defines three YANG 1.1 [RFC7950] modules to support the=0A= configuration of TCP clients and TCP servers, either as standalone or=0A= in conjunction with a stack protocol layer specific configurations.=0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/=0A= =0A= There are also htmlized versions available at:=0A= https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-07=0A= https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server-= 07=0A= =0A= A diff from the previous version is available at:=0A= https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-tcp-client-server-07= =0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n=0A= until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= =0A= _______________________________________________=0A= netconf mailing list=0A= netconf@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netconf=0A= =0A= _______________________________________________=0A= tcpm mailing list=0A= tcpm@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tcpm=0A= From nobody Mon Jul 13 12:44:26 2020 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 8FCEA3A0789; Mon, 13 Jul 2020 12:44:20 -0700 (PDT) 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: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <159466946056.23478.8788726849520982568@ietfa.amsl.com> Date: Mon, 13 Jul 2020 12:44:20 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-hystartplusplus-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 19:44:21 -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 : HyStart++: Modified Slow Start for TCP Authors : Praveen Balasubramanian Yi Huang Matt Olson Filename : draft-ietf-tcpm-hystartplusplus-00.txt Pages : 8 Date : 2020-07-13 Abstract: This doument describes HyStart++, a simple modification to the slow start phase of TCP congestion control algorithms. Traditional slow start can cause overshotting of the ideal send rate and cause large packet loss within a round-trip time which results in poor performance. HyStart++ combines the use of one variant of HyStart and Limited Slow Start (LSS) to prevent overshooting of the ideal sending rate, while also mitigating poor performance which can result from false positives when HyStart is used alone. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-hystartplusplus/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-hystartplusplus-00 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-hystartplusplus-00 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 Mon Jul 13 12:54:01 2020 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 E45423A0972; Mon, 13 Jul 2020 12:53:54 -0700 (PDT) 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: 7.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <159467003489.21738.2635214935249946687@ietfa.amsl.com> Date: Mon, 13 Jul 2020 12:53:54 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rack-09.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2020 19:53:58 -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 : RACK-TLP: a time-based efficient loss detection for TCP Authors : Yuchung Cheng Neal Cardwell Nandita Dukkipati Priyaranjan Jha Filename : draft-ietf-tcpm-rack-09.txt Pages : 31 Date : 2020-07-13 Abstract: This document presents the RACK-TLP loss detection algorithm for TCP. RACK-TLP uses per-segment transmit timestamp and selective acknowledgement (SACK) [RFC2018] and has two parts: RACK ("Recent ACKnowledgment") starts fast recovery quickly using time-based inferences derived from ACK feedback. TLP ("Tail Loss Probe") leverages RACK and sends a probe packet to trigger ACK feedback to avoid the retransmission timeout (RTO) events. Compared to the widely used DUPACK threshold approach, RACK-TLP detects losses more efficiently when there are application-limited flights of data, lost retransmissions, or data packet reordering events. It is intended to be an alternative to the DUPACK threshold approach in [RFC5681][RFC6675]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rack/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rack-09 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rack-09 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 Mon Jul 13 17:18:35 2020 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 BBEB43A0B8D for ; Mon, 13 Jul 2020 17:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LK7HCz9Fkc1b for ; Mon, 13 Jul 2020 17:18:30 -0700 (PDT) Received: from mail-ua1-x944.google.com (mail-ua1-x944.google.com [IPv6:2607:f8b0:4864:20::944]) (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 B693B3A0B6E for ; Mon, 13 Jul 2020 17:18:30 -0700 (PDT) Received: by mail-ua1-x944.google.com with SMTP id u33so2608782uad.9 for ; Mon, 13 Jul 2020 17:18:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=raIrvJotD2pREoClxhZ5gGouNQPLF8nClQ01XNYVfmE=; b=nwedkW76C9pdB77v5VsOixR3JEblc6PuJS8WviJvu36GT3WZ7ML0Q19xIm1WsLj2tY 0kdAhirBNGzwZQKndhmwS7ZIvT9/NiV05L1dE1/PqSKZZS7lBLKRmCeoYnnI/UPMPg0w M3Zky25i5hnLa4y5impvkjXyNp6qY8KkYfc3ceKmdSAE4U6KcEZNkG/0QXEOehc9mQkw 7d5AzJB7ZrR01QoAvOS1Nqh0ijgtPF40WeoFTs/1Weh5WxZv2G6X5Rl4IPXkuqwUpn1D GvTtMbTxMCvtcuPZiU+AwblkVGqmDimzaMPKytfDoebPjthW2bFgEqEoi4WCz4cVwkxr iB0w== 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=raIrvJotD2pREoClxhZ5gGouNQPLF8nClQ01XNYVfmE=; b=CR8gKaaIJEeUpJh5e6Gss2M7r1dHm7jotDSiH2kQpjjGHw1pLc5mF3PowjprbnfsiE p8+uGc2vK7w37Fv8Ne0pxKZjpojS+aEdZ3Mc6tOkeXHWqEWR2i37ZZRVUZ+E/JcKHDqB ybJ255AIXdjA9HpmaEPaKW9buF1XolUQ3Wm5lS3hBLpCHf0CKJO/xKWC8pWYtZBrH5TH uHTYh/Q1QgNbMsY1ofR1C88LoT56JGZLwVHtNxzUi8+AmcOPAHL07a3rObjte8/8XDE+ b7GyonK43lPAlsFyfA1qGHig7LVJgvXJ14rSpwcteFmeTXX9Jf6Na/HcQmuDVUFt3iCb /prg== X-Gm-Message-State: AOAM532oOmJUeF37NQf522bo14TQ2P9ilMJm3CRutR3hnfNXm7AkTJmz Jm33dkN/2gY1CPsjJt57RmVHSY8h5fOBuVVXOo4wGx+fcWQ= X-Google-Smtp-Source: ABdhPJzfbilT3eSRHOk1XEUaNxa00FHre4DKfv04dzX5ERER+W+QGfPcR1cjVFWUSmgJafcCNeRrT10WdpzVTU/xYME= X-Received: by 2002:ab0:5a4b:: with SMTP id m11mr1620086uad.112.1594685909192; Mon, 13 Jul 2020 17:18:29 -0700 (PDT) MIME-Version: 1.0 References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> In-Reply-To: From: Yuchung Cheng Date: Mon, 13 Jul 2020 17:17:53 -0700 Message-ID: To: Mirja Kuehlewind Cc: Michael Tuexen , tcpm IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-rack-08 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, 14 Jul 2020 00:18:34 -0000 On Mon, Apr 6, 2020 at 5:41 AM Mirja Kuehlewind wrote: > > Hi all, > > I reviewed this document and I think content-wise this is ready to move o= n (just some small questions below). Thank you for the review. Sorry it took so long to respond. We have made lots of changes based on your and other comments (nearly a rewrite). https://tools.ietf.org/html/draft-ietf-tcpm-rack-09 > > I would like to see another editorial pass on the document. There are mor= e detail comments below but I think the main points are a) provide a more d= etailed algorithm overview section (either in section 3 or beginning of sec= tion 7 to make it easier to understand the steps in the subsections in 7 an= d b) have an own main section for TLP and introduce parameters used for TLP= also in section 6 and mention TLP in the intro already. It's still obvious= that TLP was squeezed in later on.... > Thank you very much. We rewrote the first four sections so that RACK-TLP are an integrated design. We also add a protocol diagram to illustrate. > Further I think the security considerations could be more extensive: it c= ould a) mention again some of the reordering consideration in section 4 (or= maybe some of the text can be moved there entirely to not break the readin= g flow so much at the beginning of the doc) and b) say more about the impac= t of this algorithm on spurious retransmission (I guess it can both increas= e or decrease the number of spurious retransmissions in certain scenarios) = and c) mention again the impact on congestion control as described in secti= on 8.5 that a window reduction can happen both earlier or later in differen= t scenarios. We are not sure about the prospects of reordering consideration, congestion control, and spurious retransmission in the context of security. We do added this part " RACK-TLP algorithm behavior is based on information conveyed in SACK options, so it has security considerations similar to those described in the Security Considerations section of [RFC6675]. " > > Here are my technical questions/comments on section 7.2: > > For this sentence: > "If no reordering has been observed, RACK uses > RACK.reo_wnd of 0 during loss recovery, in order to retransmit > quickly, or when the number of DUPACKs exceeds the classic DUPACK > threshold." > > And the respective pseudo code here: > If RACK.reord is FALSE: > If in loss recovery: /* If in fast or timeout recovery */ > RACK.reo_wnd =3D 0 > Return > Else if RACK.pkts_sacked >=3D RACK.dupthresh: > RACK.reo_wnd =3D 0 > Return > > My understanding here is that the RACK-based time threshold should not be= used if in recovery or if no reordering is detected, right? Correct. Zero RACK reordering window essentially makes retransmit immediate w/o any further reordering accommodation. > > Why is that realized by setting the RACK.reo_wnd to zero rather than impl= ementing this logic in RACK_detect_loss()? I think the difference would be = that you don't reset RACK.reo_wnd but keep the previous state about adjustm= ents. But wouldn't that be good/better? > > My point it that the way it is described now confused me a bit and I'm lo= oking for a way to better describe that part... To reduce confusion we move the RACK.reo_wnd computation inside RACK_detect_loss. RACK.reo_wnd is adjusted every ACK. Does the new pseudocode help? > > Also why is RACK.dupthresh a separate parameter in the RACK name space in= stead of using the "existing" one (as you do with Packet. xmit_ts)? Further= this is actually not a parameter that is adjusted by the algorithm but a c= onfigured constant. It be helpful for the reader to indicate this in the na= ming, e.g. call it DUPTHRESH instead. In general I'm actually not sure that= using the RACK name space in this document is really helpful. We revised and replaced all RACK.dupthresh with RFC6657 =E2=80=98DupThresh= =E2=80=99 for clarity. > > And another unrelated question but on the same part of the algorithm: whe= re does the number 16 come from for the number of recovery cycles to keep a= ny adaptation? Good question. We added the rationale in the draft. If the reordering is temporary then a large adapted reordering window would slow the loss recovery after the reordering disappears. Therefore the inflated RACK.reo_wnd would persist for 16 loss recoveries and after which it resets to its starting value, min_RTT / 4. The downside of resetting the reordering window is false loss recovery if the reordering remains high. The rationale is to bound such false recoveries up to once every 16 recoveries (less than 7%). > > Then my more detailed (small and larger) editorial comments: > > 1) In the intro you use a couple of times "we" which is maybe less commo= n in RFCs as an RFC is a product of a wg not only of the author group. Mayb= e you can rephrase this. > Good idea. Replaced/remove all =E2=80=9Cwe=E2=80=9D words > 2) also in the intro: > "The goal of RACK is to solve all the problems..." > Maybe > "The goal of RACK is to address all the problems..." > > 3) Section 3 provides rather a high level overview. It would be nice to g= et more of an overview about the algorithm itself, e.g. explaining the diff= erent step described in section 7 on a high level. Or maybe you could add a= lternatively more text at the beginning of section 7 explaining how the dif= ferent subsections "fit together". Actually doing both would also not hurt = as some redundancy where you go step by step in more details is often reall= y helpful for the reader. Good idea. We added algorithm diagram in the new =E2=80=98RACK-TLP high-lev= el design=E2=80=99 section https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3.4 > > 4) Section 4 I first thought that some of this text could actually go int= o the security considerations, however, I guess there are also some require= ment here, so not sure if that could be splitted up somehow. I think the pr= oblem I have here is that is breaks quite a bit the reading flow between th= e overview section and the actual algorithm part. We rewrote section 4. Hopefully it=E2=80=99s more clear now. https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-4 > > 5) I find the naming of both RACK.reo_wnd and RACK.reo_wnd_incr a bit con= fusing, as RACK.reo_wnd is a time frame (and I would expect a packet windo= w based on the naming, given we have the congestion window or the received = window) and RACK.reo_wnd_incr is a multiplier (and I would expect some valu= e that would be added when "incr" is used) changed to RACK.reo_wnd_incr > > 6) 7.2: > " Sometimes the timestamps of RACK.Packet and Packet could carry the > same transmit timestamps due to clock granularity or segmentation > offloading (i.e. the two packets were handed to the NIC as a single > unit). In that case the sequence numbers of RACK.end_seq and > Packet.end_seq are compared to break the tie." > The textual description is not fully clear to me (pseudo code is fine). I= guess this text is in the context of update RACK.Packet itself, right? May= be that the missing part that should be spelled out. Sorry for the unclear text. We added a goal in the step and remove the offload text. The tie breaker is not necessarily due to segmentation offload. https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-6.2 > > 7) I would recommend to have section 7.3. to 7.6 in their own new main se= ction as it is an supplemental but separate algorithm. Further I would also= recommend to mention Tail Loss Probe also in the abstract and intro. Great suggestions. We have TLP in its whole section, and integrates them from the beginning (starting at abstract) https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3 > > 8) Section 7.5: At least SRTT was already used earlier on in the doc, so = maybe just add all these definitions to section 6.1? Added SRTT in the https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#secti= on-5 > > 9) Section 8.1: > " The examples above show that RACK is particularly useful when the > sender is limited by the application, which is common for > interactive, request/response traffic." > I think that is actually an important point to make in the introduction o= f the document. Agreed. Now mentioned in https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-2.2 > > 10) Also section 8.2: > " RACK can easily and optionally support the conventional approach in > [RFC6675][RFC5681] by resetting the reordering window to zero when > the threshold is met. Note that this approach differs slightly from > [RFC6675] which considers a packet lost when at least DupThresh > higher-sequence packets are SACKed. ..." > Also this information would be really helpful in the overview section alr= eady. We decided to have a dedicated section about reordering window value selection. It was scattered all over the document making readers hard to puzzle up the policy. Hopefully this section https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3.3.2 makes it clear how RACK reo_wnd can be used to support 3-dupack rule easily. > > 11) Also on both sections 8.1. and 8.2, I find the section titles not ver= y well suitable. I would maybe suggest to rearrange the content a bit and h= ave a section "Examples where RACK (and TLP) is beneficial" and another sec= tion on "Implementation considerations". At least for the examples section= I would recommend to use an own subsection. We now provide the two more examples early on in the Design section. > > 12) Maybe rename section 8.3 to "Reasoning for basic reordering window si= ze" (instead of " Adjusting the reordering window"...? > All reordering design rationale / policy is now in https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3.3 to avoid fragmented design reasonings. > 13) Section 8.4: > " Furthermore, RACK naturally works well with Tail Loss Probe [TLP]" > This reference should be removed as content was integrated into this docu= ment. Maybe the whole paragraph should be rephrased, removed entirely, or m= oved into the TLP section. agreed. removed > > 14) Section 8.5.1: > " Without RACK, the sender would time out, ..." > I suggest to say "Without RACK and TLP,..." as TLP is described as a sepa= rate optional algorithm but TLP is the important bit here. Also If you deci= de to have a separate example section, I would suggest to move this example= there as well. removed this as RACK-TLP is described as one united algorithm > > 15) Should section 9 stay in the final RFC? If so, I recommend to move it= into the appendix. However, it would also be nice to also provide results = on the number of retransmissions (have they increased with RACK and TLP?). = Alternatively I suggest removing this section and point to some paper maybe= ? > Agreed. removed. There wasn't a research paper for RACK-TLP but we probably should have published one :-) > 16) I think the security considerations could be more extensive, covering= impact on reordering, spurious retransmission, and congestion control, as = I said at the top of this mail. We are not sure if these are tied to security, or maybe there are specific issues we are missing? > > Thanks! > Mirja > > > > =EF=BB=BFOn 31.03.20, 00:28, "tcpm on behalf of Michael Tuexen" wrote: > > Dear all, > > just a quick reminder: > > We are currently running a WGLC for TCP RACK until Tuesday, April 7th= 2020. > > Please send any comments, including indications to support this docum= ent, > to the TCMP mailing list by then. > > The ID is available at > https://tools.ietf.org/html/draft-ietf-tcpm-rack-08 > > Best regards > Michael > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Mon Jul 13 18:05:12 2020 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 EE9553A0D51 for ; Mon, 13 Jul 2020 18:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 543Yw4L1nLBI for ; Mon, 13 Jul 2020 18:05:08 -0700 (PDT) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650134.outbound.protection.outlook.com [40.107.65.134]) (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 16D4D3A0D4C for ; Mon, 13 Jul 2020 18:05:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BvEjEvdmB7gfdqp7MMoAgLtSE7sk3UhvtJ44p8UMuBAGy6F3PqyZq+ULPUnwpZnWyrD6rTd8PpDqKTre1GwDiJccMzX89EN+FC7t8gCpZFTBdXVDsyituIA6HhbfkOQtFdI0RgHuOmOPmIUQTXYUTo6jmdW1bUqnWrVOiTiYC/QTXrylYEb2Vo/EYlwVH9fnaF9lL1a5MDzfb14gy4iVK1ZHsumc9vPqBjFOgGHihjLBHBjwFOFFAsu5pgzJ4uTOkkK7bX1SsM72eJzvgBXF0gz+bcmLdrGgMdK9VJIwXmvUuXr4GO6WxJwyDIFtwIWO7YR3Uw12BPhFXtv77bZmIQ== 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=7Ndpd9VRgOErawIa6mjDGLhqc6/Vu6xuy9+y+Z2Sos4=; b=Ky67calBEQthcbxp6caYM2tOSdKwORPenwdyqD6iXMvDdYyiXLDtIIlk6StHzINdoB3UyY/VgEDpSjDKXaDGDaSMqGHGq40lbDUn4UxUPEICUKvsjvsjq9bViOiCWp6xfaPC6fk+GiyNeEs2Su07jmqVdULMOSLSMr7Dio1IMTFnKXKMjLLt6rFCrjI/KMp1Wm3xcU8mUA2ICs/+4w3WJ9EYeGoxCdfZB02H0beszfdfCjD7BXetVkKC0xuEgXGRo5XiHUrIhio0Rg3z3V4a7W0Te6U6kTILrSBMhq3WVraIOgbJWOdgHoJwlFLQb9NU5Tp5BuwkyVltsQbV8MbyUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Ndpd9VRgOErawIa6mjDGLhqc6/Vu6xuy9+y+Z2Sos4=; b=hWIFGEFdC2XLT8KJnxN3ecgeIIxvqCT0GfAMCmE2OZYqk8avJOjR+2pQiTzy7LjOL14QuetPlbvIrp/bvBarh/R3jVa5zRS4LqFWToCltuGduk0HbQm6HMOnSUNFvYkba2v645JblAvKSVWLPtdsJzqpVCKjD9oD4Zv08KE67Wo= Received: from CH2PR00MB0726.namprd00.prod.outlook.com (2603:10b6:610:ad::12) by CH2PR00MB0827.namprd00.prod.outlook.com (2603:10b6:610:6f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3231.0; Tue, 14 Jul 2020 01:05:00 +0000 Received: from CH2PR00MB0726.namprd00.prod.outlook.com ([fe80::7562:9640:814e:c7f1]) by CH2PR00MB0726.namprd00.prod.outlook.com ([fe80::7562:9640:814e:c7f1%9]) with mapi id 15.20.3230.000; Tue, 14 Jul 2020 01:04:59 +0000 From: Praveen Balasubramanian To: Mark Allman , Extensions Thread-Topic: [EXTERNAL] [tcpm] hystart++ -03 review Thread-Index: AQHWKJdWK4LdZGIJG0SzVVnBYnn4ZaimmXwA Date: Tue, 14 Jul 2020 01:04:59 +0000 Message-ID: References: In-Reply-To: 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_SetDate=2020-07-14T01:04:58Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=555d31dd-7fff-48a5-b623-c99a437a2c48; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: icir.org; dkim=none (message not signed) header.d=none;icir.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:8:95d0:3f73:f682:d302] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3df4dbb4-dda4-47b5-fb3d-08d82791ee94 x-ms-traffictypediagnostic: CH2PR00MB0827: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Gx9EtUCLmrietDbq6j2h8WTEAhottA65jAa2OgU/pOfsEYxZ59J30OlwTqx9edajwWOY8t3D0RMf+wE9VbzM0C0lEKp+yvtDDFPK1m5aa8+ceOhXo0DKozJAsoYk95esR2FZhkjFFsRI91hxWkjjLiNaoEZvdihdZXBYZ5j1USvQUYy8Iu3FiJCJ9L5Cv4RotFgJ2yBs+dsLKZ3DLgUeeAlkUYjmPdo6J8b1xIRsq5Ds6/3UndUk9Z0cGBzdJHRccMcT5b5BbXQRQvF2nxfQ8LuAmHUJBe/58pqDk1sPoJug4RtmNZgQ92qdKaO8Jr7HV4jb5VeZLNzU4NQ3ZGelRglUwJuLjLeHC9Gx/AhaHMKrKWS5tDbjhGwQ5KaehGjnmlibBwFOWIDmSr55iL9b0Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0726.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(478600001)(71200400001)(5660300002)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(52536014)(10290500003)(8990500004)(86362001)(7696005)(110136005)(2906002)(316002)(9686003)(55016002)(966005)(8936002)(6506007)(53546011)(186003)(8676002)(33656002)(82950400001)(83380400001)(82960400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 7f1hYFHtTm9lscl9Oiw+kjoi97yLDvA2RN5/BoyI+RKV2AQhRPTYjdfP5Fc3vnPScN9BOTBwwMc8XPM7Jxl3XQF4N5TGXpfaXqT1pwPMYI2egkaT0HfuFFio6lJlIxIp4tdLL4+JX1QB0aKaN+v9/4NgQET2CfRiNWI2KUsQIJjWW3ZPlT0RVrhOQmTi9hX0lRXJ7SQWieJZgQJa2miAYIMgQHlx1EfKgIBDqg/AgvTH7bW6PH18sJBJ08VtOG8eOU3AayiV2NHfr+/iEwouWTMyyiqBOnI+mMmo3cNNyenaZyqxeT3AgTGSuDM2alqif6mZS/uQE66nfElMsIropvJRiBCde17Sjq0efuChv0lhSeUFxtpT6l9B74/YHPL9hbPb7gXcgLzZDIbw2qmwJosUWuUDu/xxKxpXiJaB1KjhZp/qeVGQuMAuEP+XzGJ/izYr6IyFGMPfYs+0lHqrKkphPTTNNiUikwrQYKWyxXpChn9pbBl/MEbARG9kiRTMC2eHKct89bzSK1bKx2aayEaBjTkN9HwA6kF8claYoX4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0726.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3df4dbb4-dda4-47b5-fb3d-08d82791ee94 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 01:04:59.7187 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WxXxFEeAIr3IopQ6xdWOWeaU3tPuMZg7igWGDaJJeyUNUpbrdCNEJrxjyK6+4+ekY42DflcJcRBFGjzBYFPTCgONGuJiun++55FWEGFTqZo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0827 Archived-At: Subject: Re: [tcpm] [EXTERNAL] hystart++ -03 review 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, 14 Jul 2020 01:05:10 -0000 Hi Mark, Sorry for the delayed response. Thanks for the review. Answers inline. Most= of the changes to the text have been incorporated in the WG version of the= document.=20 https://tools.ietf.org/html/draft-ietf-tcpm-hystartplusplus-00 Thanks -----Original Message----- From: tcpm On Behalf Of Mark Allman Sent: Tuesday, May 12, 2020 12:54 PM To: Extensions Subject: [EXTERNAL] [tcpm] hystart++ -03 review I read version -03 of the HyStart++ document and my view differs from many,= I guess. IMHO, this document is not ready for adoption. The draft is pretty anemic and I am not sure there is enough there to actua= lly judge whether it is or is not a good idea. It seems like perhaps the d= ocument could get there, but at this point I think the authors have some wo= rk to do. Review below. Section 1: - Nit: RFC 793 does not define slow start, remove ref. (Could add a ref to original Jacobson paper.) Good catch. Fixing to just refer to RFC 5681 instead of both RFC 793 and RF= C 5681.=20 - HyStart++ is "widely deployed", but is it widely used? Is it enabled or just there for the enabling? The document makes it sound like we have a lot of experience with this somehow, but none of that is shared (see below). Widely deployed was intended to imply widely used. Created a section "Deplo= yments and Performance Evaluations" so this text has been changed.=20 - Nit: Spell out "LSS" on first use. LSS is spelled out in the first use in the Abstract. Happy to repeat it in = the Introduction.=20 Section 3: - Nit: Totally fine to crib the definitions from RFC 5681, but it'd be good form to note that is where they came from. Sounds good. We now cite RFC 5681 in this section.=20 - Nit: Also, since you use rwnd in one of the definitions and you're copying things, you might as well copy that one, too. Done. Section 4: - There is so much unexplained magic in here. When setting RttThresh, what is magic about 1/8-th of the lastRoundMinRtt? Why clamp this between 4msec and 16msec? Would that really be reasonable for all networks? We need magic numbers sometimes and as long as they're resasonably chosen and motivated we have to live with having them around. But, the draft really needs to explain these choices, how they were made and how broadly applicable they might be. Further, the document suggests one MAY vary the constants, but it'd be great if it gave some sort of advice on how one might decide if different constants were OK or not OK. - The algorithm (series of equations) is here and clear. But, the document really needs to give us a flavor of the why. Talk us through what is happening and why in here, please. Added descriptions of what the implications are for tuning these constants = and what role they play in the heuristic in the new section "Tuning constan= ts".=20 General / meta: - The draft offers a little intuition on why this is a good idea (i.e., to prevent massive slow start over-shoot). But, there is no sketch of evidence that shows it is effective. I see this was previously mentioned on the mailing list and Praveen said: We presented lab measurement data at the last IETF. We are in the process of doing some A/B experiments at scale with real world workloads. We did fairness comparisons in our lab measurements between Hystart and non-Hystart and we didn't see any problems. The bar ought to be higher than "didn't see any problems". It is great that there is some testing done and planned. I'd like to see this all sketched in the document itself. I am not even close to convinced that this is a good idea. No, the bar is not we didn't see any problems :). That answer was specifica= lly scoped to a question around fairness. We did not observe any fairness i= ssues in the measurements.=20 The lab and prod data has been presented in multiple IETF meetings. Added d= ata to the "Deployments and Performance Evaluations" section.=20 - In some sense, this idea makes TCP more conservative (i.e., we stop exponential increase sooner than RFC5681 would suggest). So, the bar is likely not huge for saying this is "OK". But, I think we should have some notion that this helps *something* before agreeing to suggest it as somehow a reasonable thing to do in an RFC. Right now this document doesn't concretely show that HyStart++ is useful in any way. Correct more conservative. Added text in the draft to call out the improvem= ents.=20 From nobody Tue Jul 14 00:32:22 2020 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 9781D3A11D9 for ; Tue, 14 Jul 2020 00:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO-q8vU1nq3W for ; Tue, 14 Jul 2020 00:32:18 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0493A11CE for ; Tue, 14 Jul 2020 00:32:18 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 7851225A13; Tue, 14 Jul 2020 09:32:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1594711936; bh=/KtGlwl3JK/Emzln8LRpIiVKODq71paCciHQCiDF5RU=; h=From:To:Subject:Date:References:In-Reply-To:From; b=HnJg02yr78adb8MLeZyX/HFyBtufR5zhTPwokVzg83f27g3xgDRZhb0dJG+Sbu+3H cQdFpNe4+584Cmb9woNClLlesWgPD0AQjc9vmAkpyZe29hNi4vok5SXGXq4I3orpsl heqC31navlYZYMzFuZzlAhSBV6KAxOf61oRvD2eQ= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7CLnvcUN6dc; Tue, 14 Jul 2020 09:32:14 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 14 Jul 2020 09:32:14 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Tue, 14 Jul 2020 09:32:14 +0200 From: "Scharf, Michael" To: tom petch , "tcpm@ietf.org" Thread-Topic: Heads-up: draft-ietf-netconf-tcp-client-server-07 Thread-Index: AdZWjKo44LjY7IBqQL2GoSu2bsGOCgCa4gTzAC3hqqA= Date: Tue, 14 Jul 2020 07:32:13 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DCAFAFD@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2DC9E3E4@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Heads-up: draft-ietf-netconf-tcp-client-server-07 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, 14 Jul 2020 07:32:21 -0000 Tom, Thanks for the feedback. Some of this probably has to be sorted out consist= ently for the whole set of documents in the NETCONF WG. The TCP attributes in this specific document are actually described in quit= e some detail in Section 3.2, in order to address past TCPM feedback. So at= least for that part I don't think that a lot of "reverse-engineering" is n= eeded. Yet, I agree that the abstract and introduction could be expanded a bit. Michael > -----Original Message----- > From: tom petch > Sent: Monday, July 13, 2020 11:37 AM > To: Scharf, Michael ; tcpm@ietf.org > Subject: Re: Heads-up: draft-ietf-netconf-tcp-client-server-07 >=20 > From: tcpm on behalf of Scharf, Michael > > Sent: 10 July 2020 08:51 >=20 > Hi all, >=20 > This is a heads-up regarding the latest update of draft-ietf-netconf-tcp- > client-server-07. >=20 > This document is homed in the NETCONF working group. Yet, I believe that = it > is important that TCPM is in the loop, too. >=20 > > Michael >=20 > I note that IANA only registers two URI not three and that the Security > Considerations are not the usual ones (no TLS reference). More > fundamentally, and it is a comment I have made before on netconf I-D, I f= ind > it unclear who the introductory text is intended for. It seems to be aim= ed at > a YANG expert who needs little or not introduction to the modules which > they will reverse engineer. This is something that those on the TCP list= might > see more clearly than those on the Netconf list. This is not a problem = that I > have with I-D from such as TEAS, CCAMP, RTGWG etc. >=20 > Tom Petch >=20 > Given that the YANG models state ... >=20 > > organization > "IETF NETCONF (Network Configuration) Working Group and the > IETF TCP Maintenance and Minor Extensions (TCPM) Working Group"; > >=20 > .... the authors plan to ask for a WGLC not only on the NETCONF list, but= also > on the TCPM list. >=20 > Michael > (as individual contributor to unusual cross-area documents) >=20 > -----Original Message----- > From: netconf On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, July 9, 2020 2:28 AM > To: i-d-announce@ietf.org > Cc: netconf@ietf.org > Subject: [netconf] I-D Action: draft-ietf-netconf-tcp-client-server-07.tx= t >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Network Configuration WG of the IETF. >=20 > Title : YANG Groupings for TCP Clients and TCP Servers > Authors : Kent Watsen > Michael Scharf > Filename : draft-ietf-netconf-tcp-client-server-07.txt > Pages : 31 > Date : 2020-07-08 >=20 > Abstract: > This document defines three YANG 1.1 [RFC7950] modules to support the > configuration of TCP clients and TCP servers, either as standalone or > in conjunction with a stack protocol layer specific configurations. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-07 > https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-serve= r-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-tcp-client-server-= 07 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jul 14 03:07:03 2020 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 7043D3A08EC; Tue, 14 Jul 2020 03:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK4sX4BNzqTO; Tue, 14 Jul 2020 03:07:00 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94FDD3A08E9; Tue, 14 Jul 2020 03:06:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 83F4325A13; Tue, 14 Jul 2020 12:06:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1594721218; bh=/7WOT68J1ErYjyCTWDwlxs1UX0N/eG9dYnOlOVdaw9Q=; h=From:To:CC:Subject:Date:From; b=N7Q+1r4WjqfpJ/wshfZeCadE+MQpb/6qDWP55ip+O9lwNq0Y0QrEHQ+J7zuMPaZVk zwsUw6wTiKW5RyPJ64YxYFsqZYlGQAg5Zmn0BPZSrpZlLIAEUP/PUcffvRLj77A8LO r8LW1Mu7QyzbZ85k+GWntNPdrde1EO9OpmICByFo= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4LWxtZ58F32; Tue, 14 Jul 2020 12:06:57 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Tue, 14 Jul 2020 12:06:57 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Tue, 14 Jul 2020 12:06:56 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: tcpm-chairs Thread-Topic: IETF 108 agenda for TCPM - first draft Thread-Index: AdZZxn72GnT7GZsoSZSGmdm2AKKvcg== Date: Tue, 14 Jul 2020 10:06:56 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DCAFE90@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] IETF 108 agenda for TCPM - first draft 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, 14 Jul 2020 10:07:03 -0000 Hi all, I have uploaded a _first_ draft for the TCPM agenda that includes the reque= sts I am aware of: https://datatracker.ietf.org/meeting/108/materials/agenda-108-tcpm-00 A copy is also added below. Feel free to bash... Michael *** TCP Maintenance and Minor Extensions IETF 108 (online) Monday, July 27, 2020=20 # 11:00-12:40 (UTC) Monday Session I ## WG status * 11:00-11:15 WG status Chairs 15 min ## WG items * 11:15-11:25 draft-ietf-tcpm-rfc793bis Wesley Eddy 10 min * 11:25-11:45 draft-ietf-tcpm-rack Yuchung Cheng 20 min * 11:45-12:00 draft-ietf-tcpm-hystartplusplus Praveen Balasubramanian 15 min ## Non-WG items (TCP and MPTCP extensions) * 12:00-12:10 draft-gomez-tcpm-ack-rate-request Carles Gomez 10 min * 12:10-12:30 draft-amend-tcpm-mptcp-robe Jiao Kang / Markus Amend 20 min * 12:30-12:40 draft-kang-tcpm-accurate-data-scheduling-by-server-in-mptcp Jiao Kang 10 min # 13:00-13:50 (UTC) Monday Session II ## Items in other WGs (cross-area topics) * 13:00-13:15 draft-ietf-netconf-tcp-client-server Kent Watsen 15 min ## Non-WG items (cross-area topics) * 13:15-13:25 draft-scharf-tcpm-yang-tcp Michael Scharf 10 min From nobody Tue Jul 14 08:03:42 2020 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 917513A0888 for ; Mon, 13 Jul 2020 15:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.589 X-Spam-Level: X-Spam-Status: No, score=-17.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6KHHr-4JdYv for ; Mon, 13 Jul 2020 15:07:18 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 038F73A0D35 for ; Mon, 13 Jul 2020 15:07:00 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id u33so2446009uad.9 for ; Mon, 13 Jul 2020 15:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7q7lu0uAH5eozFtgmT9IAAaKvrjg8AlrbP0v/YaGSYo=; b=LTlAek5A3IPbhESPPYOwys8616ZoI74Az6kkHYa0kHd92xs5I8mm3Xm7+2EkxuPHTL 6d9gfHSvWnArsBYIw5hcQS5VDALArTMAmpWHfmv6YT3u32yIqso2E8zl779Fb7FqAViF hM/ZlrXT+ZpBqnoXxetNVV/8JjDkPN0ud6a+8T7HiajYeynPeERBw8aIBtr/rh6cElFj p/xNlEJTmK64IGh+U4mg36KeCpbDy1XYRXRtXJWpA98nFG+h+deiLnlVvscAht9MPdN6 /cAJHU5qKaj6EVnaVoJfI6VWpivzamoZAT6Rtl7BlYGYqIFLDdIUjzrU2tj4RnlrfsdO HZjQ== 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=7q7lu0uAH5eozFtgmT9IAAaKvrjg8AlrbP0v/YaGSYo=; b=ifwa8lfZV0SW7K4px+aNIeb5HSgBrtt4x45PvWA+xCCn4knjZ6Qb4cMfclQhzYeQS0 /U35FX5tLcGh9hjZb1CrrvsKumGEB6HeKjCkOzydALNCj866qctnkTzghk1KVNBFQlur i7FT5x+Pf6oZQHe73IqSA9J7U6NS/QCIlqt8SkcyGSd4GeCf54BenMgtbNdOCPfGx6mR Ud3C4gATef+eBnOlwZb2z6Mwmyburmhu8omx+qVoHrVJi6n2rzMxUurixy1y5uEywDTg y8jlsh9n4fpGvtsVhJy85pu25BnNPub0+RiEJe6125AHhTWWsxbvaPpZ95MIxPymcXUG ps0w== X-Gm-Message-State: AOAM530fOYccO0CQBfNoPpjl0NHSiRrdnRAVazhlttBAwzveDDQl52aT kKZX46nS++HSn6ihj/s4D26Xd+njThlj68QROXpBuYlF X-Google-Smtp-Source: ABdhPJyfyvkTiDZwNsQ/z05NPas82LP+2X263di6V4M1508OgD3rbNJPa4rNG9NX7KxjQcBtT0qp2F0XWSoVz/iD7ps= X-Received: by 2002:a9f:31b3:: with SMTP id v48mr1297962uad.87.1594678019254; Mon, 13 Jul 2020 15:06:59 -0700 (PDT) MIME-Version: 1.0 References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> <2c0558c37ec99da2b98f73eb5a79d8e6@tenghardt.net> In-Reply-To: <2c0558c37ec99da2b98f73eb5a79d8e6@tenghardt.net> From: Yuchung Cheng Date: Mon, 13 Jul 2020 15:06:21 -0700 Message-ID: To: Theresa Enghardt Cc: tcpm IETF list Content-Type: multipart/alternative; boundary="000000000000dee6db05aa59e896" Archived-At: X-Mailman-Approved-At: Tue, 14 Jul 2020 08:03:40 -0700 Subject: Re: [tcpm] Review (Re: WGLC for draft-ietf-tcpm-rack-08) 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, 13 Jul 2020 22:07:25 -0000 --000000000000dee6db05aa59e896 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 4, 2020 at 9:28 AM Theresa Enghardt wrote: > > Dear TCPM, > > I reviewed draft-ietf-tcpm-rack-08 focusing on whether it is clear and > easy to follow when seeking to understand how one would implement this > and/or how an existing implementation works. As a secondary concern, I > noted some editorial comments and suggestions of how one could make the > document more accessible. > > Overall, I think the document explains the scope and idea of the > algorithms really well and the algorithm details that are provided are > already quite useful. So thank you for this draft. > However, I did find a couple of points where some more clarification > would help, and a few consistency as well as editorial issues. I would > appreciate it if these were fixed before this document is published as a > Proposed Standard RFC. Thank you for such an excellent super detailed review. Sorry for taking such a long time to respond. We have made significant edits to our draft and published a newer version. https://tools.ietf.org/html/draft-ietf-tcpm-rack-09 detailed responses inline. > > Please find my review below: > > > Section 2, Introduction: > > =E2=80=9CIn recent years we have been observing several increasingly comm= on loss > and reordering patterns in the Internet: =E2=80=A6=E2=80=9D > As far as I can tell, this list actually combines the description of the > loss patterns with the limitations that existing loss recovery > mechanisms have, rather than describe limitations that are inherent to > the patterns or to TCP. So I think it makes sense to add something like > the following to this introductory sentence: =E2=80=9CGiven these pattern= s, > existing loss recovery mechanisms have the following limitations:=E2=80= =9D > Alternatively, you could move the paragraph starting with =E2=80=9CDespit= e TCP > stacks =E2=80=A6=E2=80=9D=E2=80=AFabove the list, so the list would alrea= dy be in the context of > limitations of existing loss recovery mechanisms. We like your suggestion and want to make further changes to clarify. We rewrote the first couple sections and split into existing mechanisms, their shortcoming in modern networks, and the design rationale of RACK-TLP. > > Please consider adding a half-sentence here explaining what a tail drop > is to make the document more accessible. We avoid that confusing word 'tail drop' altogether now b/c it may mean different things in different context (router queues vs application data frame). instead we describe the drop behavior directly "Packet drops at the end of an application data flight. " > > =E2=80=9CAlso, these algorithms, including RFCs, rarely address the inter= actions > with other algorithms.=E2=80=9D > I think it=E2=80=99s worth clarifying the scope of the problem:=E2=80=AFI= s this about > using multiple different algorithms at the same time on the same sender? > Or is this about interaction between different senders using different > algorithms? As other reviewers have also reflected this is unclear and not informational. We remove it. > > =E2=80=9CThe goal of RACK is to solve all the problems above =E2=80=A6=E2= =80=9D > Perhaps this paragraph should mention that RACK has limitations, too. > For example, this paragraph could already touch upon the problem of > reordering and spurious retransmissions, or it could briefly summarize > some of the disadvantages discussed in Section 8.2. Good suggestion. We now have a whole new subsection 'Reordering resilience with a time threshold' detailing the pros and cons of RACK design. > > The introduction, as well as the abstract, need to mention that this > document actually introduces two algorithms, RACK and TLP, and what > their relationship is. For example, while they can be implemented > separately, are there any dependencies between them? Why is it > beneficial to use them together? Other reviewers have expressed similar comments. We now mention them together in abstract and the high level design section together, along with their relationship in the Requirement section > Note that Section 8.5.1 has wording that suggests that using RACK > implies TLP and Section 9 implies that it=E2=80=99s possible to use TLP w= ithout > RACK. Please consider adding some of these points to the introduction > and make sure they=E2=80=99re consistent in the document. > Moreover, Section 8.4 discusses the relationship between RACK and TLP at > the very end. Please consider moving (some of) this discussion to > Section 2 or include a reference to the discussion here. This gets cleaned up now by removing section 9 entirely and rewriting the design section. Please take a look. > > Section 3, Overview: > > "RACK can be applied to both fast recovery and timeout recovery ..." > Timeout recovery refers to recovery after an RTO, correct? Does RACK > work the same way for both fast recovery and timeout recovery? This > reads a bit confusing to me, because the whole point of RACK seems to be > to avoid RTOs, and if an RTO happens, we already know that there has > been a packet loss. To help explain, we added a new subsection 'An Example of RACK-TLP in Action: RTO' in the design, along with a subsection 'Upon RTO expiration' in the RACK detailed algorithm section. Let us know if that helps. > > Section 4, Design Rationale for Reordering Tolerance: > > "TCP congestion control implicitly assumes the feedback from ACKs are > from the same bottleneck" > Please consider making the wording a bit clearer:=E2=80=AF=E2=80=9D... fe= edback from all > ACKs in a connection are from the same bottleneck=E2=80=9D -=E2=80=AFunle= ss I=E2=80=99m missing > something here. We removed this unclear sentence since it's really not critical to explain RACK reordering. We replace this with a new subsection of 'RACK reordering window adaptation' > > "How long the sender waits for such potential reordering events to > settle is determined by the current reordering window." > In this paragraph, it seems to me like the document jumps from general > considerations on the impact of RACK on packet reordering to specific > design considerations for RACK to mitigate these potential impacts. I > think it=E2=80=99s a good idea to make this transition clearer, e.g., by = adding > text like: "RACK deals with reordering by estimating a reordering > window. The way RACK deals with reordering disincentivizes excessive > reordering because of the following constraints on the reordering > window:=E2=80=AF..." > If the reordering window is a new concept that RACK introduces, or a > concept that was not widely known before, it might be worth explicitly > introducing it as a concept. Sorry for the messy text. We split RACK into the general design plus a specific section on reordering. We do not claim the reordering window is a new concept as many people have proposed similar idea. Rather we explain the new part is to combine the per-segment timestamping and reordering window to achieve better loss / reordering handling. This is detailed in the beginning of the new 'RACK-TLP high-level design' section > > =E2=80=9CIf no reordering has been observed, then RACK SHOULD honor the c= lassic > 3-DUPACK rule for initiating fast recovery. One simple way to implement > this is to temporarily override the reorder window to 0.=E2=80=9D > Just to make sure I understand correctly:=E2=80=AFHonoring the classic 3-= DUPACK > rule means detecting a packet lost after receiving 3 dup acks, in > addition to detecting packets lost based on timestamps, basically > whichever occurs first? It=E2=80=99s not obvious to me how this can be > implemented by overriding the reorder window to 0. So perhaps I=E2=80=99m > misunderstanding something here and some clarification would help. Agreed the text is confusing without reading the code. The new subsection 'RACK reordering window adaptation explicitly lists the rules of 3-dupacks and reordering window. When the reordering window is zero, RACK will mark the first unacked packet lost on the first DUPACK. The rule is to hold up until the third DUPACK (or 3 MSS worth of bytes been sacked). > > "...to adaptively estimate the duration of reordering events." > Perhaps it makes sense to add =E2=80=9Cand adjust the reordering window > accordingly=E2=80=9D=E2=80=AFto this sentence, as this part talks about m= andates on the > reordering window. > > "As a flow starts, either condition 1 or condition 2 or both would > trigger RACK to start the recovery process quickly." > Prior to this sentence, I assumed that the above points were mandates, > i.e., all of these criteria must be satisfied by the implementation. But > now the text says they are in fact conditions when to declare a packet > lost? Are 3 and 4 also conditions? We removed this sentence. What it meant originally was that at startup, RACK tends to error on the side of spurious retransmission with a lower initial reordering window. Since the majority of flows are short, the spurious rtx isn't a big concern if their paths have high reordering. But we realize the following sentences 'For short flows, the low initial ...' delivers that message already. > > =E2=80=9CIt also relaxes ordering constraints to allow sending flights of= TCP > packets on different paths dynamically for better load-balancing (e.g. > flowlets).=E2=80=9D > Please consider adding a reference for =E2=80=9Cflowlets=E2=80=9D. After reviewing it again, we realize it does not help as there are many ways to achieve load-balancing which is out of scope of this document. So we remove this sentence. > > As you discuss design rationale for the reordering window in this > section, perhaps it=E2=80=99s worth adding a reference to Section 8.3, wh= ich > contains more discussion of the reordering window and its default > values. Added > > Section 6.1, Definitions of variables: > > (Editorial)=E2=80=AFThis appears to be the only subsection of Section 6. = Can > this subsection be collapsed into Section 6? > > As you=E2=80=99re discussing packets and sequence numbers, I think it=E2= =80=99s worth > adding a few words on how to map TCP segments to packets, e.g., that an > implementation might want to store the first and last sequence number of > each TCP segment and consider this a packet. This might also be helpful > to make the connection between definitions that are based on sequence > numbers and others that are based on packets. > > Please add a definition of Packet.end_seq here, as this variable is used > in later sections, but not defined here. We replaced all references of a packet carrying sequence numbers to 'segment', as Gorry suggested. We added Segment.end_seq definition. Thanks for catching that > > For better overview, it might make sense to group variables, e.g., all > RTTs, all variables directly related to reordering, all sequence > numbers. > > =E2=80=9CThe RACK.xmit_ts, RACK.end_seq, RACK.rtt, RACK.reo_wnd, and > RACK.min_RTT variables are kept in the per-connection TCP control block. > RACK.packet and RACK.ack_ts are used as local variables in the > algorithm.=E2=80=9D > Aren=E2=80=99t RACK.packet and RACK.ack_ts also per-connection? If so, sh= ouldn=E2=80=99t > the choice of whether to put these in the per-connection TCP control > block or to use them as local variables up to the implementer? (Unless > I=E2=80=99m missing something here, in which case please clarify what the > difference is between these variables.) Sure we now split into per-connection variables and per segment variables and grouped related states together. > > Section 7.2, Upon receiving an ACK: > > Step 1: > > "Use the RTT measurements obtained via [RFC6298] or [RFC7323] to update > the estimated minimum RTT in RACK.min_RTT." > Does this document mandate how to collect individual RTT samples, in > which case maybe it=E2=80=99s worth highlighting this with a MUST or SHOU= LD? > Especially as one of the following sentences says "This document does > not specify an exact approach", but this might only refer to how to > derive the minimum RTT, not the individual RTT samples. Please clarify. We added a SHOULD: the sender SHOULD track a simple ... > > Do you perform Step 1 even for packets that you later find to be a > spurious retransmission, as this step occurs before the check for > spurious retransmissions? > Text in later sections reads as if RACK.min_RTT is not updated for > spurious retransmissions. In this case, it might be worth merging this > step with Step 2 and updating all stats after the check for spurious > retransmissions. For spuriously retransmitted packet, the ACK with TCP timestamp can still generate a valid RTT measurement, hence it should be incorporated in the min RTT update in Step 1. note that in Step 2, RACK.min_RTT is not updated as it is updated in Step 1. The RTT that's not updated is the RACK.rtt, which keeps the most recent RTT measurement. > > Step 2: > > The document first says to record the most recent Packet.xmit_ts if it > is ahead of RACK.xmit_ts. Again this is before the check for spurious > retransmissions, at least in the text. The pseudocode performs the check > first, which makes more sense to me. I think the text should be changed > to reflect the pseudocode, if this is indeed the intended order of > steps. Sure, we've reversed the text order to match the pseudo code better > > "... the sender would not be able to update its RACK.min_rtt using the > (ambiguous) RTT samples from retransmissions" > Possibly this whole example is intended as an exercise for the reader, > but just to be clear:=E2=80=AFHere the point is that the sender is unable= to > tell whether an ACK for M is from the original transmission or the > retransmission, right? And therefore it can=E2=80=99t update the RTT? Ple= ase > consider making this example a bit more explicit to make it easier to > understand. Sorry about the verbose confusing text. We replaced it with "Note that the second check is a heuristic when Timestamp option is either not available or when the round trip time is less than the timestamp clock granularity. > > Step 3: > > Maybe consider substituting =E2=80=9Cfalse retransmission=E2=80=9D=E2=80= =AFwith =E2=80=9Cspurious > retransmission=E2=80=9D, as these terms seem to refer to the same concept= . done. replaced all such words throughput > > Step 4: > > =E2=80=9CRACK starts initially with a conservative window of min_RTT/4" > This is RACK.min_RTT, right? Please use the variable name. > > What is the design rationale for increasing reo_wnd by min_RTT/4, and > not more or less, and for persisting for 16 loss recoveries, and not > more or less? > > SRTT refers to the connection's SRTT, defined similarly as in Section > 7.5 for TLP, right? Maybe it=E2=80=99s worth adding this as a definition = in > Section 6 already. SRTT is now referenced at the Definitions section > > "Note that extensions that require additional TCP features (e.g. DSACK) > would work if the feature functions simply return false." > I=E2=80=99m taking this to basically mean =E2=80=9CIf you don't implement= DSACK or if > you don't get DSACK, just return false from these functions and the > algorithm below still works=E2=80=9D, but I=E2=80=99m unsure if this is c= orrect. Does > =E2=80=9Cextensions that require additional TCP features=E2=80=9D refer t= o the > DSACK-based increases of the reordering window?=E2=80=AFBecause =E2=80=9C= extensions=E2=80=9D=E2=80=AFto > me sounds like something that would be defined in another section or > another RFC, and that would be explicitly marked as an extension. > If the meaning above is correct, please consider making this sentence > specific to the example of the DSACK-based increase in reordering > window. We now clarified that in the subsection of the design rationale section 'RACK reordering window adaptation' 'If the connection supports Duplicate Selective Acknowledgement (DSACK) information [RFC2883], the RACK reordering window SHOULD leverage that to adaptively estimate the duration of reordering events.' > > The pseudocode says that RACK.min_RTT is updated here -=E2=80=AFbut wasn'= t this > step 1 already? Or is RACK.min_RTT updated twice? Good catch. We removed the redundant pseudo code line. > > "If SND.UNA < RACK.rtt_seq: > RACK.dsack =3D false /* React to DSACK once per round trip */" > It seems like step 4 is the only part that uses RACK.rtt_seq, but the > definition in Section 6.1 says =E2=80=9CSND.NXT when RACK.rtt is updated.= =E2=80=9D Isn=E2=80=99t > RACK.rtt updated in Step 2 already? Is this definition (still) correct? > > Another question about the above pseudocode:=E2=80=AFWhy does this mean t= hat the > algorithm reacts once per round trip? What does the round trip have to > do with SND.UNA moving above RACK.rtt_seq? > > Why do you set RACK.reo_wnd_persist to -1 here, and not to 0? > > Step 5: > > "the sender MAY install a "reordering settling" timer set to fire at the > earliest moment at which it is safe to conclude that some packet is > lost" > This sounds like a really good idea, so why not make this a SHOULD? Changed to RECOMMENDED now. A few reviewers made the same comment too. "For timely loss detection, the sender is RECOMMENDED to install a reordering settling timer. This timer expires at the earliest moment when RACK would conclude that all the unacknowledged segments within the reordering window were lost." > > "To be more robust to reordering, RACK uses a more conservative RTT > value to decide if an unacknowledged packet should be considered lost, > RACK.rtt" > Is it a SHOULD or a MUST to be this conservative? Or are implementations > also free to use RACK.min_RTT? We removed this sentence entirely since it is now obsolete. The reordering window setting is now discussed in the new design rationale section. > > s/RACK.time_ts/RACK.xmit_ts/ Nice catch, revised. > > For the implementation optimization, maybe just briefly say explicitly > that the outcome of your optimization is that you only check packets > that have been sent after RACK.xmit_ts, so the advantage is immediately > obvious to the reader. Great idea. Added "checking only segments that have been sent after RACK.xmit_ts is more efficient than scanning the entire SACK scoreboard, especially when the inflight is large. " at the beginning of the paragraph now. > > Section 7.3, Tail Loss Probe > > (editorial) Should this be its own section? After all, it is its own > separate algorithm? We like that suggestion. So TLP is now a whole separate section > > Please consider substituting "Common causes of RTOs > include:"=E2=80=AFwith=E2=80=AF"Common causes of RTOs, which TLP is inten= ded to > mitigate, include:" to make the purpose of this section more clear. This section should be about TLP details. So we've integrated the RTO causes into the new Motivation subsection upfront. > > Section 7.4, Tail Loss Probe: An Example > > Please consider substituting "Following is an example of > TLP"=E2=80=AFwith=E2=80=AF"Following is an example of TLP used with RACK"= . We've changed and moved the example to a RACK-TLP at the "An Example of RACK-TLP in Action: Fast Recovery" subsection > > Section 7.5, Tail Loss Probe Algorithm Details > > TLPRxtOut, TLPHighRxt and WCDelAckT seem very different from the > variable names used otherwise the document, i.e., they are CamelCase, > while underscores are used in most other variables of the document. Also > these variable names are really hard to read and pronounce. Unless > there=E2=80=99s a good reason to call them exactly that (have they been d= efined > and used in other documents, in which case maybe it=E2=80=99s worth addin= g a > reference?), maybe consider making these variable names more similar. We renamed these variables to follow the styles of RACK variable names. > > (editorial) The PTO definition should go on a new line, otherwise it's > easy to overlook. Fixed > > Section 7.5.1, Phase 1: Scheduling a loss probe: > > (editorial)=E2=80=AFThere is a lot of nesting here, i.e., =E2=80=9Cphase = 1=E2=80=9D, =E2=80=9Cstep 1=E2=80=9D, > point 1., 2., 3.. Maybe consider restructuring this part, e.g., let > phases be different subsections, not subsubsections. > > (editorial) In the RACK algorithm, you put the description first and > then the pseudocode. Here, it's reversed. Maybe it's worth unifying your > approach? FWIW, I prefer putting the description first because it makes > the pseudocode easier to follow. > > "A sender should schedule a PTO only if all of the following conditions > are met" > Is this a =E2=80=9CSHOULD NOT schedule a PTO unless all of the following > conditions are met=E2=80=9D? yes > > "2. The connection has no SACKed sequences in the SACK scoreboard" > What is the reason for this constraint? > > "The RECOMMENDED value for WCDelAckT is 200ms." > Why this value and not another? Added an explanation. It=E2=80=99s a value used by Linux for many years, li= kely inherited from BSD (but not certain). > > s/If FlightSize =3D 1/If FlightSize =3D=3D=E2=80=AF1/ > > Section 7.5.2, Phase 2: Sending a loss probe: > > SMSS is used here, but not defined. Please expand and add a definition. Added > > Please clarify here already that while you allow only one TLP > retransmission to be in flight at a time, you allow multiple TLP new > data to be in flight. This is said later, but it is already relevant for > understanding this part. > > As you don't allow multiple TLP retransmits to be in flight: Does this > mean the PTO could fire but then you do not send any data, because there > is no new data available but there is already a TLP retransmit in > flight? Thanks for catching this -- we decided that there should be one outstanding TLP regardless of new or retransmission. This is safer from congestion control point of view. As a result we=E2=80=99ve modified this part of the algorithm. Therefore PTO can fire but not send any new (or old) data, by the guard of TLP.end_seq. > > "the sender MUST arm the RTO timer, not the PTO timer, at the end of > TLP_send_probe() if FlightSize is not zero." > Please add this to the pseudocode. The pseudo code TLP_send_probe has that (in the bottom) > > "Checking TLPRxtOut prior to sending the loss probe is also critical to > avoid TLP loops if an application writes periodically at an interval > less than PTO." > What is a TLP loop? And why would it occur if an application writes > periodically at an interval less than PTO? Please consider adding a > definition. This text is removed since TLP is now restricted to one outstanding probe at most. > > Section 7.5.3: Phase 3: ACK processing > > Isn=E2=80=99t this phase a special case of phase 1? =E2=80=9CPhase=E2=80= =9D=E2=80=AFimplies that these > occur one after the other. We removed all the phases words for clarity > > Section 7.6: TLP recovery detection > > Is this still part of the TLP algorithm? If so, why is it a new > subsection and not in the =E2=80=9CTLP algorithm details=E2=80=9D section= , and not > referenced from it? Or is this an optional addition/extension? > > To make the purpose of this algorithm clearer early on, please consider > briefly stating in the first paragraph that this introduces an algorithm > to detect whether a packet loss occurred or not, i.e., whether both the > original packet and the TLP arrived, or whether one of them got lost, > therefore, it's a loss, therefore, you have to reduce cwnd. It was. Now we have folded this part into the main TLP algorithm / Section. > > Section 7.6.3, Detecting recoveries accomplished by loss probes: > > What is the relationship between this Step 1, 2, 3, and Phase 1, 2, 3 > above? Consider rethinking your structure to make clear what happens > when. If =E2=80=9CStep=E2=80=9D=E2=80=AFand =E2=80=9CPhase=E2=80=9D refer= to the same concept, please consider > unifying your terminology. > > For condition 1: Why does this include "the segment contains no > data"=E2=80=AFand "the segment is not a window update"? (Why) Is it not p= ossible > to detect recovery if either of these is true? > > Condition 1 refers to a dup ack for the TLP retransmission, right? And > receiving this dup ack implies the TLP retransmission was spurious? (I=E2= =80=99m > just trying to make sure I understand correctly, but maybe it's worth > adding this to the draft to make it easier to follow.) > > Condition 2 uses DSACK, but you previously say "Since a significant > fraction of the hosts that support SACK do not support duplicate > selective acknowledgments (D-SACKs) [RFC2883] the TLP algorithm for > detecting such lost segments relies only on basic SACK support > [RFC2018]." > This seems to be at odds. Isn't it rather "with DSACK you can make this > detection more accurate, if you don't have it you have to rely on > condition 1 only"? Please consider rephrasing the sentence starting with > =E2=80=9CSince a significant fraction=E2=80=A6=E2=80=9D > > The last sentence of step 1 says:=E2=80=AF "... so the sender considers t= he TLP > episode to be done, and records that fact by setting TLPRxtOut to > false." > Isn't this already part of step 2, "Mark the end of a TLP retransmission > episode and detect losses"?=E2=80=AFShould this part be moved to step 2? Your comments suggest the TLP algorithm part is poorly written. We=E2=80=99= ve completely rewritten it so hopefully it=E2=80=99s easier to read. The part = that was confusing is the TLP recovery is focused on a special case when only one (last) packet was lost and repaired by TLP. This triggers particular type of ACKs depending on DSACK support or not. Let us know if the new section helps. > > "...it SHOULD invoke a congestion control response equivalent to fast > recovery." > Is this really a SHOULD or is this a MUST? Because the document also > says, "If the TLP sender does not receive such an indication before the > end of the TLP retransmission episode, then it MUST estimate that either > the original data segment or the TLP retransmission were lost, and > congestion control MUST react appropriately to that loss as it would any > other loss." We have revised and changed to SHOULD > > Section 8.1, Advantages: > > "Suppose the transmission of each packet is at least RACK.reo_wnd (1 > millisecond by default)" > Isn't the window RTT_min/4 by default? I think this is what it says > above. I am not seeing the 1 millisecond mentioned in any other part of > the document. 1msec was used in the older drafts that we've removed since. We've removed all mentions of it. > > "This example illustrates how RACK is able to repair certain drops at > the tail of a transaction without any timer." > What do you mean by =E2=80=9Cwithout any timer=E2=80=9D? RACK does potent= ially use > timers, doesn't it? Did you mean a specific timer here, like "without > PTO" or "without RTO"? again old text while RACK timer was not (yet) introduced. s/any timer/RTO recovery/ > > Section 8.3, Adjusting the reordering window: > > "... the Performance evaluation section ..." > Maybe consider adding a reference to this section. This subsection is now folded into the detailed RACK algorithm to give the rationale behind RACK.min_RTT/4 to avoid forward reference. > > Section 8.4, Relationships with other loss recovery algorithms > > At the very end, this section discusses the relationship between RACK > and TLP. As this document introduces both algorithms, consider moving > this discussion somewhere further up in the document. Alternatively, > please at least mention the existence of this discussion earlier in the > document and add a reference to the section of this discussion. We've moved this part and folded into the new 'High level design' section of RACK-TLP > > Section 8.5, Interaction with congestion control > > "RACK may detect losses faster or slower than the conventional duplicate > ACK threshold approach does. RACK can detect losses faster by not > requiring three DUPACKs, so congestion control may reduce the congestion > window earlier." > Does this text imply that RACK can be used without the three dup ack > threshold? This seems to be at odds with other parts of the document, > which clearly state that RACK implies reacting to three dup acks. > If RACK indeed implies using the three dup ack threshold, is this > paragraph still true? > > Similar to my comment on Section 2, please consider briefly clarifying > whether =E2=80=9Cinteraction=E2=80=9D means using two algorithms within t= he same sender, > or whether this is about coexistence of different senders. Sorry about the confusion. This text was written before we baked the 3-dupack rule into the RACK reordering window without a proper update here. We've revised to "If the packet losses happen after the reordering window has been increased by DSACK, RACK-TLP may take longer to detect losses than the pure DUPACK-counting approach. In this case TCP with pure loss-based congestion control may continue to increase the congestion window upon receiving ACKs during this time, making the sender more aggressive." To further clarify: RACK-TLP in theory does NOT need to respect the 3-DUPACK rule. The 3-DUPACK rule is added simply for better compatibility. > > Section 8.5.1, Example: interactions with congestion control > > "With RACK, a sender would send the TLP after 2*RTT" > This reads as if RACK does imply TLP? yes we make this clear in the Requirement section now. > > Section 8.7, RACK for other transport protocols > > "The algorithm can be simplified by skipping step 3 " > Please=E2=80=AFconsider just briefly clarifying if you mean step 3 of RAC= K, > "Detect packet reordering". In fact, why does it mean that? Even if you > have unique transmission or packet identifiers, reordering might still > occur, right? So don=E2=80=99t we still have to detect packet reordering? Sorry about the confusion. Again the step 3 was mis-cited from a very old version of the draft. We've cleaned this part up. > > Section 9, Experiments and Performance Evaluations > > =E2=80=9CWe plan to expand our experiments to regions with worse connecti= vity, > in particular on networks with strong traffic policing." > Just curious:=E2=80=AFHave these experiments actually taken place? We have expanded the experiment and eventually rolled out RACK-TLP to the entire Google (inside and Internet-facing) a few years ago. The results were fairly similar to the initial smaller-scale experiment. The values used in this draft is based on the result. > > Section 10, Security Considerations > > "An interesting scenario is ACK-splitting attacks" > Maybe start the paragraph with something saying "In fact, RACK lowers > the risk profile because it prevents the following attack"? But then it > does change the risk profile, which seems to be at odds with the first > sentence of this section. Good point. Revised. > > > This concludes my review. Again, thank you for this draft. We (all the authors) sincerely appreciate your superb thorough and detailed review! --000000000000dee6db05aa59e896 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sat, Apr 4, 2020 at 9:28 AM Theresa Enghardt <ietf@tenghardt.net> wro= te:

><= /p>

> Dear TCPM,<= /p>

>

> I reviewed draft-ietf-tcpm-= rack-08 focusing on whether it is clear and

> easy to follow when seeking to understand= how one would implement this

> and/or how an existing implementation works. As a second= ary concern, I

&= gt; noted some editorial comments and suggestions of how one could make the=

> document m= ore accessible.

= >

> Overal= l, I think the document explains the scope and idea of the

> algorithms really well and = the algorithm details that are provided are

> already quite useful. So thank you for th= is draft.

> H= owever, I did find a couple of points where some more clarification<= /p>

> would help, and a = few consistency as well as editorial issues. I would

> appreciate it if these were fixe= d before this document is published as a

> Proposed Standard RFC.

Tha= nk you for such an excellent super detailed review. Sorry for taking=

<= font color=3D"#000000" face=3D"Arial">such a long time to respond. We have made significant edits to our draft

and publis= hed a newer version.

https://tools.ietf.org/html/draft-ietf-tcpm-rack-= 09


detailed responses inline.




>

>= Please find my review below:

>

>

> Sec= tion 2, Introduction:

>

> = =E2=80=9CIn recent years we have been observing several increasingly common= loss

> and r= eordering patterns in the Internet: =E2=80=A6=E2=80=9D

> As far as I can tell, this list= actually combines the description of the

> loss patterns with the limitations that exis= ting loss recovery

> mechanisms have, rather than describe limitations that are inherent= to

> the pat= terns or to TCP. So I think it makes sense to add something like

=

= > the following to this= introductory sentence: =E2=80=9CGiven these patterns,

> existing loss recovery mechanis= ms have the following limitations:=E2=80=9D

> Alternatively, you could move the paragra= ph starting with =E2=80=9CDespite TCP

> stacks =E2=80=A6=E2=80=9D=E2=80=AFabove the list= , so the list would already be in the context of

> limitations of existing loss recovery= mechanisms.


We like your suggestion and want to make further changes to clarify. We re= wrote the first couple sections and split into existing mechanisms, their s= hortcoming in modern networks, and the design rationale of RACK-TLP.=



>

> Please consider addi= ng a half-sentence here explaining what a tail drop

> is to make the document more acc= essible.

We avoi= d that confusing word 'tail drop' altogether now b/c it may mean di= fferent things in different context (router queues vs application data fram= e). instead we describe the drop behavior directly "Packet drops at th= e end of an application data flight. "


>

> =E2=80=9CAlso, these algorithms, including RFCs, = rarely address the interactions

> with other algorithms.=E2=80=9D

> I think it=E2=80=99s worth clari= fying the scope of the problem:=E2=80=AFIs this about

> using multiple different algorit= hms at the same time on the same sender?

> Or is this about interaction between differen= t senders using different

> algorithms?

As other reviewers have also reflected this is unclear and not i= nformational. We remove it.


>

> =E2=80=9CThe goal of RACK is to solve all the problems above =E2= =80=A6=E2=80=9D

= > Perhaps this paragraph should mention that RACK has limitations, too.<= /span>

> For example= , this paragraph could already touch upon the problem of

> reordering and spurious ret= ransmissions, or it could briefly summarize

> some of the disadvantages discussed in Se= ction 8.2.

Good = suggestion. We now have a whole new subsection 'Reordering resilience w= ith a time threshold' detailing the pros and cons of RACK design.



>

> The introduction, a= s well as the abstract, need to mention that this

> document actually introduces two alg= orithms, RACK and TLP, and what

> their relationship is. For example, while they can be = implemented

>= separately, are there any dependencies between them? Why is it

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-variant-numeric:normal;font-variant-east-asian:norma= l;vertical-align:baseline;white-space:pre-wrap">> beneficial to use them= together?

Other= reviewers have expressed similar comments. We now mention them together in= abstract and the high level design section together, along with their rela= tionship in the Requirement section



> Note that Section 8.5.1 has wording that = suggests that using RACK

> implies TLP and Section 9 implies that it=E2=80=99s possible = to use TLP without

> RACK. Please consider adding some of these points to the introducti= on

> and make= sure they=E2=80=99re consistent in the document.

> Moreover, Section 8.4 discusses the = relationship between RACK and TLP at

> the very end. Please consider moving (some of) th= is discussion to

> Section 2 or include a reference to the discussion here.

This gets cleaned up now= by removing section 9 entirely and rewriting the design section. Please ta= ke a look.


&= gt;

> Section= 3, Overview:

&g= t;

> "RA= CK can be applied to both fast recovery and timeout recovery ..."

> Timeout recover= y refers to recovery after an RTO, correct? Does RACK

> work the same way for both fast = recovery and timeout recovery? This

> reads a bit confusing to me, because the whole poi= nt of RACK seems to be

> to avoid RTOs, and if an RTO happens, we already know that ther= e has

> been = a packet loss.


To help explain, we added a new subsection 'An Example of RACK-TLP i= n Action: RTO' in the design, along with a subsection 'Upon RTO exp= iration' in the RACK detailed algorithm section. Let us know if that he= lps.


>

> Section 4, De= sign Rationale for Reordering Tolerance:

>

> "TCP congestion control implicitly assumes the feed= back from ACKs are

> from the same bottleneck"

> Please consider making the wording a bit cleare= r:=E2=80=AF=E2=80=9D... feedback from all

> ACKs in a connection are from the same bottl= eneck=E2=80=9D -=E2=80=AFunless I=E2=80=99m missing

> something here.

We removed this unclear sentence= since it's really not critical to explain RACK reordering. We replace = this with a new subsection of 'RACK reordering window adaptation'


>

> "How long the = sender waits for such potential reordering events to

> settle is determined by the curr= ent reordering window."

> In this paragraph, it seems to me like the document jumps= from general

&g= t; considerations on the impact of RACK on packet reordering to specific

> design consid= erations for RACK to mitigate these potential impacts. I

> think it=E2=80=99s a good i= dea to make this transition clearer, e.g., by adding

> text like: "RACK deals with= reordering by estimating a reordering

> window. The way RACK deals with reordering disi= ncentivizes excessive

> reordering because of the following constraints on the reorderin= g

> window:= =E2=80=AF..."

> If the reordering window is a new concept that RACK introduces, or = a

> concept t= hat was not widely known before, it might be worth explicitly

> introducing it as a conc= ept.

Sorry for t= he messy text. We split RACK into the general design plus a specific sectio= n on reordering. We do not claim the reordering window is a new concept as = many people have proposed similar idea. Rather we explain the new part is t= o combine the per-segment timestamping and reordering window to achieve bet= ter loss / reordering handling. This is detailed in the beginning of the ne= w 'RACK-TLP high-level design' section



>

> =E2=80=9CIf no reordering has been observ= ed, then RACK SHOULD honor the classic

> 3-DUPACK rule for initiating fast recovery.=C2= =A0 One simple way to implement

> this is to temporarily override the reorder window to = 0.=E2=80=9D

>= Just to make sure I understand correctly:=E2=80=AFHonoring the classic 3-D= UPACK

> rule = means detecting a packet lost after receiving 3 dup acks, in

> addition to detecting pac= kets lost based on timestamps, basically

> whichever occurs first? It=E2=80=99s not obvi= ous to me how this can be

> implemented by overriding the reorder window to 0. So perhap= s I=E2=80=99m

&g= t; misunderstanding something here and some clarification would help.

Agreed the text is co= nfusing without reading the code. The new subsection 'RACK reordering w= indow adaptation explicitly lists the rules of 3-dupacks and reordering win= dow.


When th= e reordering window is zero, RACK will mark the first unacked packet lost o= n the first DUPACK. The rule is to hold up until the third DUPACK (or 3 MSS= worth of bytes been sacked).


>

> "...to adaptively estimate the duration of reordering even= ts."=E2=80=AF

> Perhaps it makes sense to add =E2=80=9Cand adjust the reordering wi= ndow

> accord= ingly=E2=80=9D=E2=80=AFto this sentence, as this part talks about mandates = on the

> reor= dering window.

&= gt;

> "A= s a flow starts, either condition 1 or condition 2 or both would

=

= > trigger RACK to start= the recovery process quickly."=E2=80=AF

> Prior to this sentence, I assumed that t= he above points were mandates,

> i.e., all of these criteria must be satisfied by the im= plementation. But

> now the text says they are in fact conditions when to declare a pack= et

> lost? Ar= e 3 and 4 also conditions?


We removed this sentence. What it meant originally was that = at startup, RACK tends to error on the side of spurious retransmission with= a lower initial reordering window. Since the majority of flows are short, = the spurious rtx isn't a big concern if their paths have high reorderin= g. But we realize the following sentences 'For short flows, the low ini= tial ...' delivers that message already.


>

> =E2=80=9CIt also relaxes ordering constraints to= allow sending flights of TCP

> packets on different paths dynamically for better load-b= alancing (e.g.

&= gt; flowlets).=E2=80=9D

> Please consider adding a reference for =E2=80=9Cflowlets=E2=80= =9D.


After r= eviewing it again, we realize it does not help as there are many ways to ac= hieve load-balancing which is out of scope of this document. So we remove t= his sentence.


>

> As y= ou discuss design rationale for the reordering window in this

> section, perhaps it=E2= =80=99s worth adding a reference to Section 8.3, which

> contains more discussion of the= reordering window and its default

> values.

Added


>

&= gt; Section 6.1, Definitions of variables:

>

> (Editorial)=E2=80=AFThis appears to be the only subs= ection of Section 6. Can

> this subsection be collapsed into Section 6?

>

> As you=E2=80=99re discussing packets a= nd sequence numbers, I think it=E2=80=99s worth

> adding a few words on how to map TCP s= egments to packets, e.g., that an

> implementation might want to store the first and las= t sequence number of

> each TCP segment and consider this a packet. This might also be h= elpful

> to m= ake the connection between definitions that are based on sequence

> numbers and others t= hat are based on packets.

>

&= gt; Please add a definition of Packet.end_seq here, as this variable is use= d

> in later = sections, but not defined here.

We replaced all references of a packet carrying sequence nu= mbers to 'segment', as Gorry suggested.

We added Segment.end_seq definition. Thanks= for catching that




>

> For better overview, it might make sense to group variables, e.g.,= all

> RTTs, = all variables directly related to reordering, all sequence

> numbers.

>

> =E2=80=9CThe RACK.xmit_ts, RACK.end_se= q, RACK.rtt, RACK.reo_wnd, and

> RACK.min_RTT variables are kept in the per-connection T= CP control block.

> RACK.packet and RACK.ack_ts are used as local variables in the

> algorithm.=E2=80= =9D

> Aren=E2= =80=99t RACK.packet and RACK.ack_ts also per-connection? If so, shouldn=E2= =80=99t

> the= choice of whether to put these in the per-connection TCP control

> block or to use them= as local variables up to the implementer? (Unless

> I=E2=80=99m missing something here,= in which case please clarify what the

> difference is between these variables.)<= /p>

Sure we now split i= nto per-connection variables and per segment variables and grouped related = states together.



>

&g= t; Section 7.2, Upon receiving an ACK:

>

> Step 1:=E2=80=AF

>

> "Use the RTT measurements obtained via [RFC6298] or [RFC73= 23] to update

&g= t; the estimated minimum RTT in RACK.min_RTT."

> Does this document mandate how t= o collect individual RTT samples, in

> which case maybe it=E2=80=99s worth highlighting = this with a MUST or SHOULD?

> Especially as one of the following sentences says "Th= is document does

> not specify an exact approach", but this might only refer to how= to

> derive = the minimum RTT, not the individual RTT samples. Please clarify.

=

= We added a SHOULD: the sen= der SHOULD track a simple ...


>

> Do you perform Step 1 even for packets that you later find to b= e a

> spuriou= s retransmission, as this step occurs before the check for

> spurious retransmissions?

> Text in late= r sections reads as if RACK.min_RTT is not updated for

> spurious retransmissions. In th= is case, it might be worth merging this

> step with Step 2 and updating all stats after = the check for spurious

> retransmissions.


For spuriously retransmitted packet, the ACK with TCP time= stamp can still generate a valid RTT measurement, hence it should be incorp= orated in the min RTT update in Step 1.


note that in Step 2, RACK.min_RTT is not updat= ed as it is updated in Step 1. The RTT that's not updated is the RACK.r= tt, which keeps the most recent RTT measurement.


>

> Step 2:

>

> The document first says to record the most recent Packe= t.xmit_ts if it

= > is ahead of RACK.xmit_ts. Again this is before the check for spurious<= /span>

> retransmiss= ions, at least in the text. The pseudocode performs the check

> first, which makes more = sense to me. I think the text should be changed

> to reflect the pseudocode, if this is = indeed the intended order of

> steps.


Sure, we've reversed the text order to match the pseudo co= de better



>

> &quo= t;... the sender would not be able to update its RACK.min_rtt using the

> (ambiguous) RT= T samples from retransmissions"

> Possibly this whole example is intended as an exe= rcise for the reader,

> but just to be clear:=E2=80=AFHere the point is that the sender = is unable to

>= ; tell whether an ACK for M is from the original transmission or the=

> retransmission, r= ight? And therefore it can=E2=80=99t update the RTT? Please

> consider making this examp= le a bit more explicit to make it easier to

> understand.

Sorry about the verbose confusing text. We re= placed it with "Note that the second check is a heuristic when Timesta= mp option is either not available or when the round trip time is less than = the timestamp clock granularity.


>

> Step 3:

>

>= Maybe consider substituting =E2=80=9Cfalse retransmission=E2=80=9D=E2=80= =AFwith =E2=80=9Cspurious

> retransmission=E2=80=9D, as these terms seem to refer to the= same concept.

d= one. replaced all such words throughput


>

> Step 4:

>

> =E2=80=9CRACK starts initially with a conservative window of min_R= TT/4"

> = This is RACK.min_RTT, right? Please use the variable name.

>

> What is the design rationale for incre= asing reo_wnd by min_RTT/4, and

> not more or less, and for persisting for 16 loss recov= eries, and not

&= gt; more or less?



>

&= gt; SRTT refers to the connection's SRTT, defined similarly as in Secti= on

> 7.5 for = TLP, right? Maybe it=E2=80=99s worth adding this as a definition in<= /p>

> Section 6 already.=

SRTT is now ref= erenced at the Definitions section


>

> "Note that extensions that require additional TCP fea= tures (e.g. DSACK)

> would work if the feature functions simply return false."

> I=E2=80=99m tak= ing this to basically mean =E2=80=9CIf you don't implement DSACK or if<= /span>

> you don'= ;t get DSACK, just return false from these functions and the

> algorithm below still wor= ks=E2=80=9D, but I=E2=80=99m unsure if this is correct. Does

> =E2=80=9Cextensions that = require additional TCP features=E2=80=9D refer to the

> DSACK-based increases of the reo= rdering window?=E2=80=AFBecause =E2=80=9Cextensions=E2=80=9D=E2=80=AFto

> me sounds like= something that would be defined in another section or

> another RFC, and that would be = explicitly marked as an extension.

> If the meaning above is correct, please consider ma= king this sentence

> specific to the example of the DSACK-based increase in reordering

> window.


We now clarified= that in the subsection of the design rationale section

'RACK reordering window adaptat= ion'


= 9;If the connection supports Duplicate Selective Acknowledgement (DSACK) in= formation [RFC2883], the RACK reordering window SHOULD leverage that to ada= ptively estimate the duration of reordering events.'


>

> The pseudocode says that RACK.min_RT= T is updated here -=E2=80=AFbut wasn't this

> step 1 already? Or is RACK.min_RTT upd= ated twice?


= Good catch. We removed the redundant pseudo code line.



>

> "If SND.UNA < RACK.rtt= _seq:

>=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RACK.dsack =3D false /* React to DSA= CK once per round trip */"

> It seems like step 4 is the only part that uses RACK.r= tt_seq, but the

= > definition in Section 6.1 says =E2=80=9CSND.NXT when RACK.rtt is updat= ed.=E2=80=9D Isn=E2=80=99t

> RACK.rtt updated in Step 2 already? Is this definition (sti= ll) correct?

>= ;

> Another q= uestion about the above pseudocode:=E2=80=AFWhy does this mean that the

> algorithm reac= ts once per round trip? What does the round trip have to

> do with SND.UNA moving abov= e RACK.rtt_seq?

= >

> Why do= you set RACK.reo_wnd_persist to -1 here, and not to 0?

>



> Step 5:

>

> "the sender MAY install a "reorderin= g settling" timer set to fire at the

> earliest moment at which it is safe to concl= ude that some packet is

> lost"

> This sounds like a really good idea, so why not make this a SH= OULD?


Change= d to RECOMMENDED now. A few reviewers made the same comment too.

=

= "For timely loss detection, the sen= der is RECOMMENDED to install a reordering settling timer. This timer expir= es at the earliest moment when RACK would conclude that all the unacknowled= ged segments within the reordering window were lost."


>

> "To be more robust to reo= rdering, RACK uses a more conservative RTT

> value to decide if an unacknowledged pack= et should be considered lost,

> RACK.rtt"

> Is it a SHOULD or a MUST to be this conservative? Or= are implementations

> also free to use RACK.min_RTT?


We removed this sentence entirely since it is = now obsolete. The reordering window setting is now discussed in the new des= ign rationale section.=C2=A0


>

> s/RACK.time_ts/RACK.xmit_ts/

Nice catch, revised.


>

> For the implementation optimization, maybe just = briefly say explicitly

> that the outcome of your optimization is that you only check pa= ckets

> that = have been sent after RACK.xmit_ts, so the advantage is immediately

> obvious to the read= er.


Great id= ea. Added "ch= ecking only segments that have been sent after RACK.xmit_ts is more efficie= nt than scanning the entire SACK scoreboard, especially when the inflight i= s large. " at the beginning of the paragraph now.


>

> Section 7.3, Tail Loss Probe

>

> (editorial) Should this be its = own section? After all, it is its own

> separate algorithm?

We like that suggestion. So TLP is now a who= le separate section


>

>= ; Please consider substituting=C2=A0 "Common causes of RTOs

=

= > include:"=E2=80= =AFwith=E2=80=AF"Common causes of RTOs, which TLP is intended to

> mitigate, includ= e:" to make the purpose of this section more clear.

This section should be about TLP= details. So we've integrated the RTO causes into the new Motivation su= bsection upfront.



>

&= gt; Section 7.4, Tail Loss Probe: An Example

>

> Please consider substituting "Following is an e= xample of

> T= LP"=E2=80=AFwith=E2=80=AF"Following is an example of TLP used wit= h RACK".

We= 've changed and moved the example to a RACK-TLP at the "An Exam= ple of RACK-TLP in Action: Fast Recovery" subsection


>

> Section 7.5, Tail Loss Probe Algori= thm Details

>=

> TLPRxtOut,= TLPHighRxt and WCDelAckT seem very different from the

> variable names used otherwise t= he document, i.e., they are CamelCase,

> while underscores are used in most other variab= les of the document. Also

> these variable names are really hard to read and pronounce. = Unless

> ther= e=E2=80=99s a good reason to call them exactly that (have they been defined=

> and used i= n other documents, in which case maybe it=E2=80=99s worth adding a

> reference?), maybe = consider making these variable names more similar.


We renamed these variables to foll= ow the styles of RACK variable names.



>

> (editorial) The PTO definition should go on a new l= ine, otherwise it's

> easy to overlook.


Fixed



>

> Section 7.5.1, Phase 1: Scheduling a loss probe:

>

> (editorial)=E2=80=AFThere is a lot of= nesting here, i.e., =E2=80=9Cphase 1=E2=80=9D, =E2=80=9Cstep 1=E2=80=9D,

> point 1., 2.= , 3.. Maybe consider restructuring this part, e.g., let

> phases be different subsection= s, not subsubsections.

>

>= (editorial) In the RACK algorithm, you put the description first and

> then the pseudoc= ode. Here, it's reversed. Maybe it's worth unifying your

=

= > approach? FWIW, I pre= fer putting the description first because it makes

> the pseudocode easier to follow.

>

> "A sender should sc= hedule a PTO only if all of the following conditions

> are met"

> Is this a =E2=80=9CSHOULD N= OT schedule a PTO unless all of the following

> conditions are met=E2=80=9D?

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-variant-numeric:normal;font-variant-east-asian:norma= l;vertical-align:baseline;white-space:pre-wrap">yes


>

> "2. The connection has no SACKed seq= uences in the SACK scoreboard"

> What is the reason for this constraint?

=

>

> "The RECOMMENDED va= lue for WCDelAckT is 200ms."

> Why this value and not another?

Added an explanation. It=E2=80=99s a= value used by Linux for many years, likely inherited from BSD (but not cer= tain).


><= /span>

> s/If Flight= Size =3D 1/If FlightSize =3D=3D=E2=80=AF1/

>

> Section 7.5.2, Phase 2: Sending a loss probe:=

>

> SMSS is used here, but not = defined. Please expand and add a definition.

Added

>

> Please clarify here already that while you allow only one TLP<= /span>

> retransmiss= ion to be in flight at a time, you allow multiple TLP new

> data to be in flight. This = is said later, but it is already relevant for

> understanding this part.

>

> As you don't allow multiple TLP r= etransmits to be in flight: Does this

> mean the PTO could fire but then you do not send= any data, because there

> is no new data available but there is already a TLP retransmi= t in

> flight= ?


Thanks for= catching this -- we decided that there should be one outstanding TLP regar= dless of new or retransmission. This is safer from congestion control point= of view. As a result we=E2=80=99ve modified this part of the algorithm. Th= erefore PTO can fire but not send any new (or old) data, by the guard of TL= P.end_seq.


&= gt;

> "t= he sender MUST arm the RTO timer, not the PTO timer, at the end of

> TLP_send_probe() if= FlightSize is not zero."

> Please add this to the pseudocode.

The pseudo code TLP_send_probe has that (in the bottom)=


>=

> "Checking TL= PRxtOut prior to sending the loss probe is also critical to

> avoid TLP loops if an appl= ication writes periodically at an interval

> less than PTO."

> What is a TLP loop? And why wou= ld it occur if an application writes

> periodically at an interval less than PTO? Please= consider adding a

> definition.

This text is removed since TLP is now restricted to one outstanding pro= be at most.


= >

> Sectio= n 7.5.3: Phase 3: ACK processing

>

> Isn=E2=80=99t this phase a special case of phase 1? =E2=80=9CPha= se=E2=80=9D=E2=80=AFimplies that these

> occur one after the other.

We removed all the phases words for = clarity


>=

> Section 7.= 6: TLP recovery detection

>

&= gt; Is this still part of the TLP algorithm? If so, why is it a new<= /p>

> subsection and not= in the =E2=80=9CTLP algorithm details=E2=80=9D section, and not

=

= > referenced from it? O= r is this an optional addition/extension?

>

> To make the purpose of this algorithm clearer early on,= please consider

> briefly stating in the first paragraph that this introduces an algori= thm

> to dete= ct whether a packet loss occurred or not, i.e., whether both the

=

= > original packet and t= he TLP arrived, or whether one of them got lost,

> therefore, it's a loss, therefore= , you have to reduce cwnd.

It was. Now we have folded this part into the main TLP algorithm= / Section.



>

> Se= ction 7.6.3, Detecting recoveries accomplished by loss probes:

>

> What is the relationship between= this Step 1, 2, 3, and Phase 1, 2, 3

> above? Consider rethinking your structure to mak= e clear what happens

> when. If =E2=80=9CStep=E2=80=9D=E2=80=AFand =E2=80=9CPhase=E2=80= =9D refer to the same concept, please consider

> unifying your terminology.

>

> For condition 1: Why does this i= nclude "the segment contains no

> data"=E2=80=AFand "the segment is not a= window update"? (Why) Is it not possible

> to detect recovery if either of these i= s true?

>

> Condition 1 re= fers to a dup ack for the TLP retransmission, right? And

> receiving this dup ack impl= ies the TLP retransmission was spurious? (I=E2=80=99m

> just trying to make sure I under= stand correctly, but maybe it's worth

> adding this to the draft to make it easier t= o follow.)

><= /span>

> Condition 2= uses DSACK, but you previously say "Since a significant

> fraction of the hosts th= at support SACK do not support duplicate

> selective acknowledgments (D-SACKs) [RFC2883]= the TLP algorithm for

> detecting such lost segments relies only on basic SACK support<= /span>

> [RFC2018].&= quot;

> This = seems to be at odds. Isn't it rather "with DSACK you can make this=

> detection = more accurate, if you don't have it you have to rely on

> condition 1 only"? Pl= ease consider rephrasing the sentence starting with

> =E2=80=9CSince a significant fra= ction=E2=80=A6=E2=80=9D

>

>= ; The last sentence of step 1 says:=E2=80=AF "... so the sender consid= ers the TLP

>= episode to be done, and records that fact by setting TLPRxtOut to

> false."=E2=80= =AF

> Isn'= ;t this already part of step 2, "Mark the end of a TLP retransmission<= /span>

> episode and= detect losses"?=E2=80=AFShould this part be moved to step 2?

Your comments suggest th= e TLP algorithm part is poorly written. We=E2=80=99ve completely rewritten = it so hopefully it=E2=80=99s easier to read. The part that was confusing is= the TLP recovery is focused on a special case when only one (last) packet = was lost and repaired by TLP. This triggers particular type of ACKs dependi= ng on DSACK support or not. Let us know if the new section helps.

>

> "...it SHOULD invo= ke a congestion control response equivalent to fast

> recovery."

> Is this really a SHOULD or = is this a MUST? Because the document also

> says, "If the TLP sender does not recei= ve such an indication before the

> end of the TLP retransmission episode, then it MUST e= stimate that either

> the original data segment or the TLP retransmission were lost, and=

> congestion= control MUST react appropriately to that loss as it would any

> other loss."


We have revised a= nd changed to SHOULD


>

&g= t; Section 8.1, Advantages:

>

> "Suppose the transmission of each packet is at least RACK.reo_wn= d (1

> millis= econd by default)"

> Isn't the window RTT_min/4 by default? I think this is wha= t it says

> a= bove. I am not seeing the 1 millisecond mentioned in any other part of

> the document.

1msec was used in= the older drafts that we've removed since. We've removed all menti= ons of it.


&= gt;

> "T= his example illustrates how RACK is able to repair certain drops at<= /p>

> the tail of a tran= saction without any timer."

> What do you mean by =E2=80=9Cwithout any timer=E2=80= =9D? RACK does potentially use

> timers, doesn't it? Did you mean a specific timer h= ere, like "without

> PTO" or "without RTO"?


again old text while RACK timer was = not (yet) introduced. s/any timer/RTO recovery/


>

> Section 8.3, Adjusting the reordering win= dow:

>=

> "... the Per= formance evaluation section ..."

> Maybe consider adding a reference to this sectio= n.

This subsecti= on is now folded into the detailed RACK algorithm to give the rationale beh= ind RACK.min_RTT/4 to avoid forward reference.


>

> Section 8.4, Relationships with other loss rec= overy algorithms

>

> At th= e very end, this section discusses the relationship between RACK

=

= > and TLP. As this docu= ment introduces both algorithms, consider moving

> this discussion somewhere further up = in the document. Alternatively,

> please at least mention the existence of this discussi= on earlier in the

> document and add a reference to the section of this discussion.

We've moved this= part and folded into the new 'High level design' section of RACK-T= LP


>

> Section 8.5, In= teraction with congestion control

>

> "RACK may detect losses faster or slower than the conventi= onal duplicate

&= gt; ACK threshold approach does.=C2=A0 RACK can detect losses faster by not=

> requiring = three DUPACKs, so congestion control may reduce the congestion

> window earlier."

> Does this te= xt imply that RACK can be used without the three dup ack

> threshold? This seems to be= at odds with other parts of the document,

> which clearly state that RACK implies rea= cting to three dup acks.

> If RACK indeed implies using the three dup ack threshold, is = this

> paragr= aph still true?

= >

> Simila= r to my comment on Section 2, please consider briefly clarifying

=

= > whether =E2=80=9Cinte= raction=E2=80=9D means using two algorithms within the same sender,<= /p>

> or whether this is= about coexistence of different senders.


Sorry about the confusion. This text was writt= en before we baked the 3-dupack rule into the RACK reordering window withou= t a proper update here. We've revised to

"If the packet losses happen after the reordering window ha= s been increased by DSACK, RACK-TLP may take longer to detect losses than t= he pure DUPACK-counting approach. In this case TCP with pure loss-based con= gestion control may continue to increase the congestion window upon receivi= ng ACKs during this time, making the sender more aggressive."

To further clarify:= RACK-TLP in theory does NOT need to respect the 3-DUPACK rule. The 3-DUPAC= K rule is added simply for better compatibility.


>

> Section 8.5.1, Example: interactions with= congestion control

>

> &q= uot;With RACK, a sender would send the TLP after 2*RTT"

> This reads as if RACK doe= s imply TLP?


yes we make this clear in the Requirement section now.


>

> Section 8.7, RACK for other transport= protocols

><= /span>

> "The a= lgorithm can be simplified by skipping step 3 "

> Please=E2=80=AFconsider just bri= efly clarifying if you mean step 3 of RACK,

> "Detect packet reordering". In = fact, why does it mean that? Even if you

> have unique transmission or packet identifier= s, reordering might still

> occur, right? So don=E2=80=99t we still have to detect packe= t reordering?

So= rry about the confusion. Again the step 3 was mis-cited from a very old ver= sion of the draft. We've cleaned this part up.


>

> Section 9, Experiments and Performance Ev= aluations

>

> =E2=80=9CWe = plan to expand our experiments to regions with worse connectivity,

> in particular on ne= tworks with strong traffic policing."=E2=80=AF

> Just curious:=E2=80=AFHave these= experiments actually taken place?


We have expanded the experiment and eventually rolle= d out RACK-TLP to the entire Google (inside and Internet-facing) a few year= s ago. The results were fairly similar to the initial smaller-scale experim= ent. The values used in this draft is based on the result.


>

> Section 10, Security Considerati= ons

><= /p>

> "An interesti= ng scenario is ACK-splitting attacks"

> Maybe start the paragraph with something = saying "In fact, RACK lowers

> the risk profile because it prevents the following a= ttack"? But then it

> does change the risk profile, which seems to be at odds with = the first

> s= entence of this section.


Good point. Revised.

>

>

>= This concludes my review. Again, thank you for this draft.


<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:10pt;font-family:Arial;color:rgb(0,0,0);background-= color:transparent;font-variant-numeric:normal;font-variant-east-asian:norma= l;vertical-align:baseline;white-space:pre-wrap">We (all the authors) sincer= ely appreciate your superb thorough and detailed review!

<= br>
--000000000000dee6db05aa59e896-- From nobody Tue Jul 14 10:25:48 2020 Return-Path: <010001734e5c6099-8c964e6d-6a0b-4f69-b913-9c544b9b7a95-000000@amazonses.watsen.net> 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 F0A193A0BF5 for ; Tue, 14 Jul 2020 10:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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_HELO_NONE=0.001, SPF_NONE=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=amazonses.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 KU-mMYQHgvif for ; Tue, 14 Jul 2020 10:25:45 -0700 (PDT) Received: from a48-93.smtp-out.amazonses.com (a48-93.smtp-out.amazonses.com [54.240.48.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B543A0BF0 for ; Tue, 14 Jul 2020 10:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1594747544; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:Feedback-ID; bh=AzS43E3rALrGxrEvr6HngkIX+c0EV81szr/uU0GwXbA=; b=hO7lAdVfbu7TB+hHB4+rLaj2bO2L+h9T5oWdPF9nut7NqAnYeRIGXEMjwt2kze0n Vj+VbhSqq47BSz5alap6EvnCXuqOz68Pl6AxrsryJcYwWh4W09OV0u0OQ5N//V6YYiJ iS5XrCMqscZvKGLGsHYFShyT04ZoyCQLocUy3Qmg= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Kent Watsen In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DCAFAFD@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Tue, 14 Jul 2020 17:25:43 +0000 Cc: tom petch , "tcpm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-ID: <010001734e5c6099-8c964e6d-6a0b-4f69-b913-9c544b9b7a95-000000@email.amazonses.com> References: <6EC6417807D9754DA64F3087E2E2E03E2DC9E3E4@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2DCAFAFD@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-SES-Outgoing: 2020.07.14-54.240.48.93 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [tcpm] Heads-up: draft-ietf-netconf-tcp-client-server-07 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, 14 Jul 2020 17:25:47 -0000 Hi Tom, 1) I fixed the missing IANA registration in my local copy (thanks!) 2) The Security Considerations section do follow the template, with = adjustments to make sense (the template is not one-size-fits-all) All, text suggestions are welcomed! Kent // co-author > On Jul 14, 2020, at 3:32 AM, Scharf, Michael = wrote: >=20 > Tom, >=20 > Thanks for the feedback. Some of this probably has to be sorted out = consistently for the whole set of documents in the NETCONF WG. >=20 > The TCP attributes in this specific document are actually described in = quite some detail in Section 3.2, in order to address past TCPM = feedback. So at least for that part I don't think that a lot of = "reverse-engineering" is needed. >=20 > Yet, I agree that the abstract and introduction could be expanded a = bit. >=20 > Michael >=20 >> -----Original Message----- >> From: tom petch >> Sent: Monday, July 13, 2020 11:37 AM >> To: Scharf, Michael ; tcpm@ietf.org >> Subject: Re: Heads-up: draft-ietf-netconf-tcp-client-server-07 >>=20 >> From: tcpm on behalf of Scharf, Michael >> >> Sent: 10 July 2020 08:51 >>=20 >> Hi all, >>=20 >> This is a heads-up regarding the latest update of = draft-ietf-netconf-tcp- >> client-server-07. >>=20 >> This document is homed in the NETCONF working group. Yet, I believe = that it >> is important that TCPM is in the loop, too. >>=20 >> >> Michael >>=20 >> I note that IANA only registers two URI not three and that the = Security >> Considerations are not the usual ones (no TLS reference). More >> fundamentally, and it is a comment I have made before on netconf I-D, = I find >> it unclear who the introductory text is intended for. It seems to be = aimed at >> a YANG expert who needs little or not introduction to the modules = which >> they will reverse engineer. This is something that those on the TCP = list might >> see more clearly than those on the Netconf list. This is not a = problem that I >> have with I-D from such as TEAS, CCAMP, RTGWG etc. >>=20 >> Tom Petch >>=20 >> Given that the YANG models state ... >>=20 >> >> organization >> "IETF NETCONF (Network Configuration) Working Group and the >> IETF TCP Maintenance and Minor Extensions (TCPM) Working = Group"; >> >>=20 >> .... the authors plan to ask for a WGLC not only on the NETCONF list, = but also >> on the TCPM list. >>=20 >> Michael >> (as individual contributor to unusual cross-area documents) >>=20 >> -----Original Message----- >> From: netconf On Behalf Of internet- >> drafts@ietf.org >> Sent: Thursday, July 9, 2020 2:28 AM >> To: i-d-announce@ietf.org >> Cc: netconf@ietf.org >> Subject: [netconf] I-D Action: = draft-ietf-netconf-tcp-client-server-07.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Network Configuration WG of the = IETF. >>=20 >> Title : YANG Groupings for TCP Clients and TCP = Servers >> Authors : Kent Watsen >> Michael Scharf >> Filename : draft-ietf-netconf-tcp-client-server-07.txt >> Pages : 31 >> Date : 2020-07-08 >>=20 >> Abstract: >> This document defines three YANG 1.1 [RFC7950] modules to support = the >> configuration of TCP clients and TCP servers, either as standalone = or >> in conjunction with a stack protocol layer specific configurations. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-netconf-tcp-client-server/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-07 >> = https://datatracker.ietf.org/doc/html/draft-ietf-netconf-tcp-client-server= -07 >>=20 >> A diff from the previous version is available at: >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-tcp-client-server-0= 7 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> netconf mailing list >> netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >>=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 Tue Jul 14 17:36:16 2020 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 E40543A0817 for ; Tue, 14 Jul 2020 17:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONSyMdRDgCzI for ; Tue, 14 Jul 2020 17:36:12 -0700 (PDT) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 4E8203A0544 for ; Tue, 14 Jul 2020 17:36:12 -0700 (PDT) Received: by mail-ua1-x92d.google.com with SMTP id b13so50255uav.3 for ; Tue, 14 Jul 2020 17:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Pm4I/hVf1AiYLZ4hELo1U5wYLjAjfHlo1v7R+xdohPo=; b=SNWWTgqkJIBc+6GPDgAbKXsmkf8VlBzTJ5/RAPCry+Y1QoHTtEblzgn+Bk22qNtaN2 f2rJJ1Ze+eOtSxMeKA5r8CI7OaAjWgNjjVQGMzduKJh5g1CdJNr0MVF8nWJi6q6dvRf2 4ajB6d6AXnS2iONIoYhEemHEmEr1ckzZk+dmZTUOxZmqpEOCOMTm2hu9wkoqzEsaGjzf kQoLzGJXFhxEJaOLjFF2r9bRQUL/150yZwVzmMlyd520DMdnuxOP+E4NYOTwW0QibXY/ RfkGOrYNZ6C7gdE9tXLrTqh26rFQGYIC06CLoAJuLctiXhx53xe6NuhtiloWZMqrvQsw 1Tmg== 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=Pm4I/hVf1AiYLZ4hELo1U5wYLjAjfHlo1v7R+xdohPo=; b=sjYq8nq9htOvjQg/ZTeUJWqESvzKe11GKRcD6WfpgRK/z8S7gTwPxsp9j56FzoSgkG T+TpyOLU+7ApS3jTLNyGvKksseQDHgdJJ0R+RHsTRuN7T9ogYNlCtBhr44Sbr6Fai8b/ FSpNVmQhCxpD8Gj9E67GD8i++FLv5bqXgyNj8JYSLiqpjXf6/cpQGOlHy+EAjRvgPO5l 2SwZ0s+fPpoC1yYluxJ6UVlg32W6OvgRRg9gmr/xrTA3iNdoSVl3BleqYdW5hOwYRL9E pQEJWQhHV9o5R4MAVx1QG3AWLSsEkA9s+AVmFzUPDgsLidtzJAT2IsFPev+AQYc+h2w5 LONw== X-Gm-Message-State: AOAM533gwAMo1JhChoBAkbjM47mK7aUrH7qjyk2a5tsGZ92hnvCmAFMK gFXIVh0bYn52crEPdL+dyZhL6eOQ9ObUsVEx/eZ+epSoZFg= X-Google-Smtp-Source: ABdhPJyZ1NrTP0AnqbHyeqc6Bh3KGMuRW+K/xNDD+uihJZiDGNgfcvM0yD8dMHxWqm7WusHSqrvK9EPy6Am+sfJj21w= X-Received: by 2002:ab0:15a4:: with SMTP id i33mr5523805uae.85.1594773370706; Tue, 14 Jul 2020 17:36:10 -0700 (PDT) MIME-Version: 1.0 References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> <7e9fb383-15d8-b613-2fcb-ea7de9c46ef2@erg.abdn.ac.uk> In-Reply-To: <7e9fb383-15d8-b613-2fcb-ea7de9c46ef2@erg.abdn.ac.uk> From: Yuchung Cheng Date: Tue, 14 Jul 2020 17:35:34 -0700 Message-ID: To: Gorry Fairhurst Cc: tcpm IETF list , Michael Tuexen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] WGLC for draft-ietf-tcpm-rack-08 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, 15 Jul 2020 00:36:15 -0000 On Mon, Apr 6, 2020 at 8:24 AM Gorry Fairhurst wrote= : > > I reviewed the latest version of RACK as a part of the TCPM WGLC. > > I do not think this is ready. I think the specification is important, > but the document has many editorial issues. > > These issues seem to be very important and I do not think the current > document is ready to proceed without a revision being prepared that can > be properly reviewed. Overall I am concerned that this draft provides > little evidence or justification for the proposed change to an existing > PS. I do not argue against the proposal, but I do suggest the > justification and trade-offs involved needs to be clear before the IETF > should publish such a specification. > > Some of the comments below could be fixed by editorial work, but as > currently written this makes many bold statements about IETF consensus > that I would not agree with. Many of these could be easily rephrased too > focus only on the topics being standardised, or by providing appropriate > evidence for the claims. Thanks for your review and comments. Sorry about the late response. We've revised the documents to remove all wordings about the frequency or population of issues we've observed, such as "prevalent reordering ...". https://tools.ietf.org/html/draft-ietf-tcpm-rack-09 Instead we put an explicit high-level design section to focus on the actual problems this draft aims to improve / fix, without claiming these problems are common or not, because they do vary across networks. > > Specific comments follow - some issues I will highlight in a separate mai= l. > > Gorry > > Section 2: > > =E2=80=94 > I do not see a reference that offers data for this: > In recent years we have been observing several increasingly common loss > and reordering patterns in the Internet. > - Can you explain who =E2=80=9Cwe=E2=80=9D are and where this has been pu= blished or > presented? I=E2=80=99d be quite comfortable if this said =E2=80=9Cin rece= nt tears there > is an increasing concern about the implications of loss or reordering=E2= =80=9D - > but the present set asserts this is common, so I ask for evidence please? We rewrote sections 1-3 to clarify the motivation, the design goals, and the rationale for these changes, plus a section to illustrate/overview the protocol. Mostly we removed =E2=80=9Cwe=E2=80=9D and other claims based on unpublishe= d data or anecdotal evidence. > =E2=80=94 > This is not explained: > =E2=80=9C Structured request-response traffic turns more losses into tail= drops.=E2=80=9D > - I don=E2=80=99t think the losses are turned into tail drops, maybe the = losses > are observed at the tails of transmission? We removed the confusing word "tail" drops. instead a new subsection to explain the problems more precisely https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-2.2 > =E2=80=94 > This is not justified: > =E2=80=9C Despite TCP stacks (e.g. Linux) that implement many of the sta= ndard > and proposed loss detection algorithms > [RFC4653][RFC5827][RFC5681][RFC6675][RFC7765][FACK][THIN-STREAM], we've > found that together they do not perform well. =E2=80=9C > - Can you explain who =E2=80=9Cwe=E2=80=9D are and where this has been pu= blished/presented? removed all wordings of "we", but it means the authors. This sentence is removed in the new revision entirely. > =E2=80=94 > This sentence doesn=E2=80=99t read well: =E2=80=9CThey can either detect = loss > quickly or accurately, but not both, especially when the sender is > application-limited or under reordering that is unpredictable. =E2=80= =9C > - /They/A sender/ =E2=80=A6. /or under reordering that is unpredictable/o= r when > the reordering is unpredictable/. > - What does unpredictable mean in this sentence? Is it about the pattern > or reordering, the variation in the pattern, the presence or not within > an RTT or something else? the pattern of reordering. we put down two specific cases to explain: https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3.3.1 > =E2=80=94 > This is not explained or justified: > =E2=80=9CAnd > under these conditions none of them can detect lost retransmissions > well.=E2=80=9D > - None of them can doe well? Can you explain this better, saying this is > not =E2=80=9Cwell=E2=80=9D seems a very poor justification for changing a= standard removed this sentence. instead we compared their pros & cons in the https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-8.1 https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-8.2 > =E2=80=94 > This is confusing: > =E2=80=9CAlso, these algorithms, including RFCs, rarely address the > interactions with other algorithms. =E2=80=9C > - Which? and why this this important? For all comments above. We agree this section was not clear and some statements lack data citations. As mentioned earlier we divided into a motivation section and a design section to avoid conflating the two. https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-2.2 > =E2=80=94 > Since section 2 seems mainly set out to provide the reason for the > change, would it not be more normal to precede the RFC2119 terminology > declaration? Sure we moved the terminology section to the beginning. > > This could also apply to section 3, which introduces the method, but > does not appear normative. > =E2=80=94=E2=80=94 > Section 3. > > =E2=80=9CThe main idea behind RACK is that if a packet has been delivered= out > of order, then the packets sent chronologically before that were > either lost or reordered.=E2=80=9D > - This is put forward as a TCP specification, and yet it describes > things in network-layer =E2=80=9Cpackets=E2=80=9D. If the IP layer were t= o fragment, > does this still work on IP packets? I think this should be in terms of > transport segments, or the relationship between packets and segments > explained. all packets are replaced with segments (if appropriate). > =E2=80=94 > =E2=80=9CUsing a threshold for counting duplicate acknowledgments (i.e., > DupThresh) alone is no longer reliable because of today's prevalent > reordering patterns. =E2=80=9C > - To me this is quite an annoying statement to make without reference to > a source of this consensus. Saying the method is robust to reodering > seems good, saying the current Internet has "prevalent reordering > patterns" makes me ask where? what evidence? how important? etc. I > suggest this document should not be making these claims. > =E2=80=94=E2=80=94 > =E2=80=9CA common type of reordering is that the last > "runt" packet of a window's worth of packet bursts gets delivered > first, then the rest arrive shortly after in order. =E2=80=9C > - Cite data please and explain the cases, or please do not claim this is > =E2=80=9Ccommon=E2=80=9D! > =E2=80=94 > =E2=80=9CToday's prevalent lost retransmissions also cause problems with > packet-counting approaches =E2=80=9C > - Cite data please, or please do not claim this is =E2=80=9Cprevalent=E2= =80=9D. re:annoying claims -- explained earlier. We try to be as thorough as possible to remove all the adjectives in the new revision. > =E2=80=94=E2=80=94 > =E2=80=9Care often unable to infer and quickly repair losses=E2=80=9D > - =E2=80=9Coften=E2=80=9D is being used here in a way that implies this i= s frequent? Is > this strictly necessary to define the algorithm. I think it would be > enough to explain these events can happen, and that the algorithm can > detect these cases and appropriately respond. I do not see the need to > make a statement of how common this is. > =E2=80=94 > This isn=E2=80=99t clear text, I had to read several times to be sure: > =E2=80=9COn each ACK, RACK marks any already-expired packets lost, > and for any packets that have not yet expired it waits until the > reordering window passes and then marks those lost as well=E2=80=9D > - I think this could be explained more simply. https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3.1 is this better? "... For each ACK received, the sender calculates the latest RTT measurement (if eligible) and adjusts the expiration time of every segment sent but not yet delivered. If a segment has expired, RACK marks it lost." > =E2=80=94 > =E2=80=9Churts=E2=80=9D performance. Could be better phrased. Section motivation tries to be more precise on the latency difference with / without RACK-TLP > =E2=80=94 > =E2=80=9CTCP congestion control implicitly assumes the > feedback from ACKs are from the same bottleneck. =E2=80=9C > - I don=E2=80=99t think this is true. There is no assumption. The design = was > based on a single bottleneck at any one time along the path. However > that does not imply that more than one bottleneck can not be present. Fair enough. We removed this since it's more or less out of scope of RACK-T= LP > =E2=80=94 > =E2=80=9CTherefore it > cannot handle well scenarios where packets are traversing largely > disjoint paths.=E2=80=9D > - I don=E2=80=99t know what =E2=80=9Chandle well=E2=80=9D means, not do I= understand =E2=80=9Clargely > disjoint=E2=80=9D really means in this context. Can this be explained? > =E2=80=94 > =E2=80=9CHaving an excessively large reordering window to > accommodate widely different latencies from different paths would > increase the latency of loss recovery.=E2=80=9D > - This needs better phrasing. Why does this have to be =E2=80=9Cexcessive= ly=E2=80=9D > large and why does a TCP transport care about =E2=80=9Cdifferent paths=E2= =80=9D > irrespective of being =E2=80=9Cwidely different=E2=80=9D - I could not un= derstand what > was intended at all. In order to be more clear about the reordering design of RACK-TLP, we made an explicit new section https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3.3.1 please let us know if that looks more clear > - =E2=80=94 > =E2=80=9CAn end-to-end transport protocol cannot tell immediately whether= a > hole is reordering or loss. =E2=80=9C > - Please explain hole before using. removed the colloquial word "hole". new text "Upon receiving an ACK indicating an out-of-order data delivery, a sender cannot tell immediately whether that out-of-order delivery was a result of reordering or loss. " > =E2=80=94 > =E2=80=9CHow long the sender waits for such > potential reordering events to settle is determined by the current > reordering window.=E2=80=9D > - NiT; except one is measured in packets, and =E2=80=9Chow long=E2=80=9D = is in units of > seconds. > =E2=80=94 > =E2=80=9CThe initial RACK reordering window SHOULD be set to a small > fraction of the round-trip time.=E2=80=9D > - Sounds good, is this after connection setup, or before? How does the > sender know the RTT? Nice catch. The sender is assumed to implement RFC6298 and estimate RTT. But in case the sender does not know (e.g. syn retransmits w/o TS), we advise to keep reo_wnd 0 w/o further better choice so it mimics old 3-du= pack https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3.3.2 "1. If the sender has observed some reordering since the connection was established, then the RACK reordering window SHOULD be set to a small fraction of the round-trip time, or zero if no round-trip time estimate is available." > =E2=80=94 > =E2=80=9C To accomplish this RACK places the > following mandates on the reordering window:=E2=80=9D > - The discussion =E2=80=98mandates=E2=80=99 appears to be different to th= e discussion of > requirements. I don=E2=80=99t see the difference explained. I wonder whet= her the > document should place all requirements in section 5, but if not, then > the purpose should be better explained. That's a good idea. We consolidated all reordering window requirements into https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3.3.2 > =E2=80=94 > =E2=80=9C RACK does not need any change on the receiver.=E2=80=9D > - OK. However, there is a requirement that the receiver reports loss > using SACK. added that to be clear > =E2=80=94 > =E2=80=9C RACK.dsack" indicates if a DSACK option .=E2=80=9D > - DSACK not mentioned until here. Should you cite DSACK [RFC3708] ? cited now in -09 > > --- > > =E2=80=9CThe RECOMMENDED value for WCDelAckT is 200ms.=E2=80=9D > -Why this value? is this linked to TCP Delayed ACK value? yes it's now named TLP.max_ack_delay to be explicit. 200ms originated from Linux which we believe (but not are not certain) came from old BSD. but this value is fairly inadequate in modern networking as some recent discussions reveal. so we changed to to Third, when FlightSize is one segment, the sender MAY inflate PTO by TLP.max_ack_delay to accommodate a potential delayed acknowledgment and reduce the risk of spurious retransmissions. The actual value of TLP.max_ack_delay is implementation-specific. to avoid hard-coding yet another number that'd become obsolete soon > =E2=80=94 > =E2=80=9CWe have evaluated using the smoothed RTT=E2=80=9D > =E2=80=A6. where is the data? Not published > =E2=80=94 > =E2=80=9CThey do not make any significant difference in terms of total re= covery > latency.=E2=80=9D > - Is this true of **ALL** cases? I strongly dislike such conclusions in > RFCs. The document can only make conclusions based on available data, > and claiming this for arbitrary paths is dangerous and unnecessary. > - > =E2=80=9CWhile RACK can be a supplemental loss > detection mechanism on top of these algorithms, this is not > necessary, because RACK implicitly subsumes most of them.=E2=80=9D > - what is not necessary RACK? or one of them? why does it say =E2=80=9Cmo= st=E2=80=9D, > please be specific. We removed this. In the abstract we make it clear what RACK is intended to be (an alternative to conventional DUPACK-counting approach). > - > I think sections 8 and 9 are both informative. Is this the case? I like > this information, but I would prefer the sections to explain that they > are informative, if that is the case I am not sure what to add to the section. "This is an informative section, = ..." > > --- > =E2=80=9C"Common causes of RTOs include:" > - This seems unnecessary, can=E2=80=99t you scope this to the ones that y= ou > think TLP will address, instead of making this very general statement. > The current text seems to need a reference, whereas saying this is what > TLP addresses would not. sure removed > =E2=80=94 > =E2=80=9C"A sender should schedule a PTO only if all of the following con= ditions > are met" > - what is the actual requirement here? I=E2=80=99m searching to understan= d what > is actually needed or recommended. The requirement is clear to me. but here is our newer text to hopefully make the reason clear to others: "After attempting to send a loss probe, regardless of whether a loss probe was sent, the sender MUST re-arm the RTO timer, not the PTO timer, if FlightSize is not zero. This ensures RTO recovery remains the last resort if TLP fails." > --- > > NiTs: > > =E2=80=9Ceg.=E2=80=9D should be =E2=80=9Ce.g.,=E2=80=9D fixed > > =E2=80=9Cis the easiest way to get a network to go faster.=E2=80=9D > - This needs to be explained better. This is over-simplified. so we remove this. > --- > =E2=80=9CTherefore their main > constraint on speed is reordering, and there is pressure to relax > that constraint. =E2=80=9C > - I object to this statement within a TCPM document. This is not related > to the TCPM Charter which is about maintaining transport protocols and > not changing network-layer forwarding behaviour. > I similarly think the following sentence is entirely inappropriate: > =E2=80=9CIf RACK becomes widely deployed, the underlying > networks may introduce more reordering for higher throughput. =E2=80= =9C > - albeit with a lower case =E2=80=9Cmay=E2=80=9D, this is still something= that tsvwg has > spent many meetings discussing and one that has significant pushback and > therefore a need for careful choice of words! Fine. the may is not intended to be the "MAY". We *do not* want to encourage reordering. Here is our revised text on excessive reordering: "However, the fact that the initial reordering window is low, and the reordering window's adaptive growth is bounded, means that there will continue to be a cost to reordering to disincentivize excessive network reordering over highly disjoint paths. For such networks there are good alternative solutions, such as MPTCP." https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3.3.2 > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 15 12:30:04 2020 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 84E323A0E91 for ; Wed, 15 Jul 2020 12:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXb_WLmzWtG0 for ; Wed, 15 Jul 2020 12:30:00 -0700 (PDT) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 7E6FC3A0C56 for ; Wed, 15 Jul 2020 12:30:00 -0700 (PDT) Received: by mail-vk1-xa2b.google.com with SMTP id c11so754636vkn.11 for ; Wed, 15 Jul 2020 12:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kxsv+3EmJamx/LQjFCLzTh5yGWFK0Hq750o5iq5MrWQ=; b=p+8b3w18z6CyaCOdPD6qZxQ24Rl+dJElpRVI0rak/r2De1V3kTRYEi06QOATxrAyEm XHdLLYmAzhyrDa9Isep3pO7RppcxQyEE2B1r+2I30I/nDgioE3okQxT2N/QwrKg9uf5E D7mgrx5zzCWs7dI4J2vvMDwBrh+Zi3CIgTA5xMkbhY+ky2eE0rMry1fCrlJ6RriEULPK 39FokYVDjvqW46RK5Vda825isi3+62R94zL43MIgwjoGUT51dRbXVmwG3jEeQ48xYpDY x/kdKLXprUTPO6zFz+dsGMxRYDZKD6D/B6RUVlF1Zvo9s0w3eSqw6RX71KU2Vt6fhv1x BGTQ== 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=kxsv+3EmJamx/LQjFCLzTh5yGWFK0Hq750o5iq5MrWQ=; b=ZpKUdo6SKEhbMOD8JwSgKGHXtxeRwW4ogFY9uuzh51jdHquYJtyU3Vyuq/ICvFzHM1 mASwCw964QgVxazt2Mku/QpXjC2YQi39esZFUZv3S69ielTIqVGP0JIKCnJSn9CPH9lx OJwLViDWvqHmo58R0lI01QLhyBv+PzNu/fyTPi49xzOJOvu5n3BOhHR7xrrRbMBZWnAB ivxj5PEi8UmxAEJuPAduUYmbOgP9XnABI3LvI2GgcY/FeLB6ftvIpyQqiJ2zmEjIop4o OpkdZsrTVX9IkN0MYktMqEN3HdVkUdVV4C+ZwklSI+0YGhDS20Pz6HiyA/2TCuYK7AsU IuEA== X-Gm-Message-State: AOAM532S5E+RkdYO4W0qb7BL80yNfkdDernpyVhTSEiCG54RHkWftBV3 cR1KuS9Cy8JVU5dkUjO6FxIdEZ48yHrUxfmGiZjWVg== X-Google-Smtp-Source: ABdhPJy8wzn1Ro1WN8t1QS1l7GRuxCKTipY1t+LoxiDxELt1w1fZ5E1+G5IglPyr1vIdzocanLt3bFRtC5XfvLRvI48= X-Received: by 2002:a1f:3d47:: with SMTP id k68mr589371vka.68.1594841399127; Wed, 15 Jul 2020 12:29:59 -0700 (PDT) MIME-Version: 1.0 References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> In-Reply-To: From: Yuchung Cheng Date: Wed, 15 Jul 2020 12:29:22 -0700 Message-ID: To: Praveen Balasubramanian Cc: Michael Tuexen , tcpm IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] [EXTERNAL] WGLC for draft-ietf-tcpm-rack-08 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, 15 Jul 2020 19:30:03 -0000 On Mon, Apr 6, 2020 at 3:54 PM Praveen Balasubramanian wrote: > > We reviewed the latest version of RACK as a part of the TCPM WGLC and thi= s is some feedback: > > Section 5 Requirements > >> For each packet sent, the sender MUST store its most recent transmiss= ion time > It is important to call out that in practice for sends that are batched t= ogether in time, an implementation may choose to keep per-send transmission= timestamps instead of per-packet. This improves memory efficiency. The way= the RFC requirement is worded it seems to exclude such an optimization. Good idea. We have added " 2. For each data segment sent, the sender MUST store its most recent transmission time with a timestamp whose granularity that is finer than 1/4 of the minimum RTT of the connection. At the time of writing, microsecond resolution is suitable for intra- datacenter traffic and millisecond granularity or finer is suitable for the Internet. Note that RACK-TLP can be implemented with TSO (TCP Segmentation Offload) support by having multiple segments in a TSO aggregate share the same timestamp." https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-4 > > Section 4 Design Rationale for Reordering Tolerance > >>If RACK becomes widely deployed, the underlying networks may introduce = more reordering for higher throughput. > A better word here would be universally deployed because otherwise networ= ks would be unfairly harming TCP stacks that have not deployed RACK. Plus a= s pointed out, reordering puts other strains on the network including ECMP,= RSS, hardware offloads etc. Consider removing any recommendations for netw= orks from this draft to prevent any unintentional relaxing of requirements = on networks. This section should ideally only focus on why RACK chooses to = relax reordering requirements as they pertain to loss detection and recover= y. yes the old text was being mis-intepreted as RACK encourages reordering so we tried our best to make that clear the opposite is true, toward the end of a new "reordering design" sub-section https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-3.3 > > >>temporarily override the reorder window > Nit: Let's consistently call this reordering window throughout the draft. great idea. we have now renamed all different names to "RACK reordering window, RACK.reo_wnd" to be specific throughout, instead of "reordering settle time", "reordering time window", etc > > > Section 7.2 Upon receiving an ACK Step 5. > >>For timely loss detection, the sender MAY install a "reordering settlin= g" timer set to fire at the earliest moment at which it is safe to conclude= that some packet is lost. > At least in lab tests this timer seems to make a big difference. Recommen= d changing this to a SHOULD instead of MAY. s.g. s/MAY/RECOMMENDED in step 5 of https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-6.2 For timely loss detection, the sender is RECOMMENDED to install a reordering timer. This timer expires at the earliest moment when RACK would conclude that all the unacknowledged segments within the reordering window were lost. > > >>This can be implemented by using a seperate doubly-linked list sorted i= n time order. > Typo separate. We shouldn't recommend a specific data structure. fixed typo and removed the RECOMMENDED > > Some questions that need more explanation: > 1. What about TLP and its relationship to Limited Transmit? Both of them = are techniques trying to solve the same problem. Its important to clarify w= hether Limited Transmit is left unchanged from RFC 6675. It is also unclear= whether Limited Transmit should be upgraded from a MAY to a SHOULD. The no= n-SACK case might benefit from Limited Transmit? TLP is 100% compatible with LT. We have some text on this now https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-7.2 7.2. Scheduling a loss probe The sender schedules a loss probe timeout (PTO) to transmit a segment during the normal transmission process. The sender SHOULD start or restart a loss probe PTO timer after transmitting new data (that was not itself a loss probe) or upon receiving an ACK that cumulatively acknowledges new data, unless it is already in fast recovery, RTO recovery, or the sender has segments delivered out-of-order (i.e. RACK.segs_sacked is not zero). These conditions are excluded because they are addressed by similar mechanisms, like Limited Transmit [RFC3042], the RACK reordering timer, and F-RTO [RFC5682]. > 2. Why does TLP require SACK? In the case SACK negotiation fails, or SACK= blocks are stripped in the network, TLP may still recover faster than an R= TO when FlightSize is 1. TLP requires RACK which requires SACK. TLP on non-sack is in theory possible but has very limited benefit. It can repair the single loss well, but consider this TLP w/ neither RACK & SACK: t0: send 10 packets (P1...P10, lost all except number 8) t1: dupack by P8 t2: send TLP of P10 t3: dupack by P10 --> ? still RTO given that only two dupacks are received. We decided early on it's no point to complicate TLP further to support non-sack, given sack is widely deployed. the non-sack deserves to stay unoptimized (their choice). > > > -----Original Message----- > From: tcpm On Behalf Of Michael Tuexen > Sent: Monday, March 30, 2020 3:28 PM > To: tcpm IETF list > Subject: [EXTERNAL] [tcpm] WGLC for draft-ietf-tcpm-rack-08 > > Dear all, > > just a quick reminder: > > We are currently running a WGLC for TCP RACK until Tuesday, April 7th 202= 0. > > Please send any comments, including indications to support this document,= to the TCMP mailing list by then. > > The ID is available at > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-ietf-tcpm-rack-08&data=3D02%7C01%7Cpravb%40mic= rosoft.com%7C0f4389073900466c89c408d7d4f9b460%7C72f988bf86f141af91ab2d7cd01= 1db47%7C1%7C0%7C637212041259507026&sdata=3DnQghPe61ph4EBThh4xRYp9LTmfis= Cp6LZAj96leSpOI%3D&reserved=3D0 > > Best regards > Michael > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Wed Jul 15 15:20:04 2020 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 1BE3D3A0E39 for ; Wed, 15 Jul 2020 15:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6Ruj-x2nBju for ; Wed, 15 Jul 2020 15:20:00 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 5C62B3A08FC for ; Wed, 15 Jul 2020 15:20:00 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id p25so1959760vsg.4 for ; Wed, 15 Jul 2020 15:20:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eQwPJkU5LA2BjvKrkBTp2zetI5FSwilBoHpiH1+R0b4=; b=PIUpoZIbd2LmC9FtCYX2g+FejmDrAc9hXWzuT+QGWb3zhUImPSpc0JmZ+oYXcGAUB/ 9mOXUxUnNp3cbZ1kUCXcmHVXx0XtnICVvhstorcQSK/XMQuh4cHEJkDBOSPAV+srybEx wEU5IAzZE+Y5wnrOeiUbEMFDxxqsgocFiQ7A4z60NhHmBdtkoZtNOR19qp3QsgPhAuRq vZRGcN0ykeoZDRxziZFBf2Ovd2ogMtnz/xTn2f781uECTi5UegD5k8anjUkdoOMPtQPS YViZrv9ays3n/1R2I35dz2JIcDvPVIdyTXEDTVPFDfQne088JSlW3P9peZA4S5FduO+2 RyTA== 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=eQwPJkU5LA2BjvKrkBTp2zetI5FSwilBoHpiH1+R0b4=; b=d6jRR/ELSzjPXSyhXfVnomPeRVSXo0KL8+318S5aHqF0PKfd2LZ1AsKERE2wbDy+mc Bz/1GA0/WQ1wvyCAHxlqIXQLpcdIWJ6L/BmxKiMfwKlLdsdA4yqmguY2dfPpeaYviVEe l0oeQP+UvC7EOZXOSHYDpFf/R10c38oi7H/qHzoMFrTk8Ti2WPJJvHzoxbH815YaNeT6 s3e5F/ZSVXekz5gKD77RM2BLiSOXfgVVoikdmwfHqNNbWgFamnPeWXRcCOky06Z7pN6s FqWrD8F5wUwrqyq7h9JxfGa6pU9n+95TlulKi452SQT2iJ8wcbnDQ0394ig0pcQwaE4N IhRw== X-Gm-Message-State: AOAM533yhesFbaqjIp9+JXofPNOR9fXseFs7Uayd1fvUuLazKgIEEPqt NG33HIzeJKp3Fu42uc9qACbMfrFwmCdQisdPN9GcLw== X-Google-Smtp-Source: ABdhPJy/l7kHETtESKWSSElaK+gXxnNHS6WGmCjNBHegnz9pidDzBZn2/udMkoSG0EHU8SDpvp9XIDL9bPbCsydpfTY= X-Received: by 2002:a67:bc1:: with SMTP id 184mr1054632vsl.104.1594851599082; Wed, 15 Jul 2020 15:19:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yuchung Cheng Date: Wed, 15 Jul 2020 15:19:22 -0700 Message-ID: To: Yi Huang Cc: "tcpm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Review of draft-ietf-tcpm-rack-08 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, 15 Jul 2020 22:20:02 -0000 On Tue, Apr 7, 2020 at 2:34 PM Yi Huang wrote: > > I reviewed the latest version of RACK and I have a few questions about th= e RACK timer. Thank you Yi for your review. Sorry it takes so long to respond. We've released a new revision > > > > In Section 7.2, Step 5: Detect losses, the draft states how/when the RACK= timer is armed. However, it=E2=80=99s not very clear that how/when it is c= anceled. I suppose when a cumulative ACK arrives and RACK_detect_loss() ret= urns with timeout =3D 0, it should be canceled? Are the RACK timer and the = RTO timer mutually exclusive? > Good catch. The timers are indeed mutually exclusive. We've revised to clarify these points in TLP, but forget to touch RACK. https://tools.ietf.org/html/draft-ietf-tcpm-rack-09#section-7.2 7.2. Scheduling a loss probe The sender schedules a loss probe timeout (PTO) to transmit a segment during the normal transmission process. ... Further, prior to scheduling a PTO the sender SHOULD cancel any pending PTO, RTO, RACK reordering timer, or zero window probe (ZWP) timer [RFC793]. We'll add another subsection on "Managing RACK TLP timers" to further clarify this. > > > When the RACK timer fires and calls RACK_detect_loss(), due to clock gran= ularity, the packets, for which the timer was scheduled for, might have not= expired yet. Thus, the RACK timer might be scheduled several times for the= same set of packets even when there is no new (S)ACK coming back. I think= it would be helpful to implementers if this is addressed/discussed in the = spec. > That's a good point. The draft specified RACK_detect_loss_and_arm_timer(): timeout =3D RACK_detect_loss() If timeout !=3D 0 Arm the RACK timer to call RACK_detect_loss_and_arm_timer() _after_ timeout so the RACK timer is supposed to expire 1 time unit after the maximum remaining time among unacked segments. Therefore these "expired" segments ideally would be marked lost. Our initial version puts a "timeout + 1_timer_tick" but it just needs more explanation to define a timer tick, etc. > > > Thanks, > > > > Yi > > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jul 17 23:49:40 2020 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 A38083A0C7D; Fri, 17 Jul 2020 23:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNNnJfLoffYM; Fri, 17 Jul 2020 23:49:36 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02AF93A0C77; Fri, 17 Jul 2020 23:49:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 9B65B25A15; Sat, 18 Jul 2020 08:49:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1595054973; bh=0H70oq0BO3WlQWOEBO0EPDYdTVYHMB7t4XQG/Vtu1Hg=; h=From:To:CC:Subject:Date:From; b=FaXgONJ3Ds6W+XCulpIugfUlBmI86aksNZ8omvdWFjwpo74Ouahda/oxy+8gRbiPY HM+xznpvRo/QLXo7HXS9sBX3DgHZ5TTcqaDXDGbiAnFQKZhgpBqpwxusIYNCozFdL+ b8Ka5HzAyCCECQeiq8++JBa/fIOPvgUm7fFEguAU= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQ2n5zTHMgYz; Sat, 18 Jul 2020 08:49:33 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sat, 18 Jul 2020 08:49:33 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Sat, 18 Jul 2020 08:49:32 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: tcpm-chairs Thread-Topic: IETF 108 - slides please Thread-Index: AdZcz4X2WhCag+aPTouawz6O5WtVYQ== Date: Sat, 18 Jul 2020 06:49:31 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DCB9B6B@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] IETF 108 - slides please 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, 18 Jul 2020 06:49:38 -0000 TCPM is scheduled on July 27 in the first two slots of IETF 108. Authors/presenters, please send a first version of your slides to the chair= s until Friday July 24 EOB. It is possible to provide updates afterwards if= needed. Thanks Michael From nobody Sun Jul 19 04:26:43 2020 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 96F2C3A08D8 for ; Sun, 19 Jul 2020 04:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Js2f_sikQG9E for ; Sun, 19 Jul 2020 04:26:40 -0700 (PDT) Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (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 6832C3A08D7 for ; Sun, 19 Jul 2020 04:26:40 -0700 (PDT) Received: by mail-vk1-xa2e.google.com with SMTP id b205so3080023vkb.8 for ; Sun, 19 Jul 2020 04:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=38UkJVLTnoObcNr71/vOpZ/6lFhhNvV6GnUbMClPuEk=; b=UN4+d47kRvgw/er3/sfEnYzqQrqlZk/q9QMflYI5Fvccs9ceO4RW7Wu59AVn6EpD9B Q5gogCoSBo8mOrRP/Hp4eMnM8s4pwcMZJV/qOWln3DuyrCwP+QOsOpYlUI89/YITIpDa 6cdJFpPpoFN6CMhN/JTkxhZrX9HBKhhxU8gIKtnvMc/yvslurx/cRlizLQzEouRj8XKy QQtzDEhm5oV4gYWGnCbBOn5eN1iBH6cMMD2TfCtp4kr6L1AYByc43SPLodSgr/5nxXMd ftIBZnPyJb4vUKHjHrnUp32ppA7uhzaFPq5AtCH+2LrywPK2UsBlax4N/gO5p/akA2Cg Umfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=38UkJVLTnoObcNr71/vOpZ/6lFhhNvV6GnUbMClPuEk=; b=M10+MrqElodbXpdiXFn+A+JyLa9eNQNZSG2TkbN43i/ABnY3ZJQSRHiAgiHJa4gqpl MD8GVvuVEisrFAJgWsuLAMkUeBBiQmUa7/x38owaWkncuUte24tJxE9nxJ1BWLVKhvox Re6x9Jb1wn/y/EuiDSRNbmxzl/7EvPg5geakLUEN1FyFuiibnwwiqC3R+8ORMQzrPhY8 CC1qJpccnw89Auk0BT4cYNF5YFMRKAbZ3WhU+GC7sUmfkhe0qB5aX6qT7LSk+uqcnynl pQUTAUzvfvPu/TEYYQhs9XTWIUdtMCxpi52yfLT2L75pyjvz+BxoyJFr+S22QTYRiZAY 14ww== X-Gm-Message-State: AOAM532wrOKUorUBbnDt3rVrNdSEv4/uQZJcABGsYbZ/7sfcu2T4On8U 8rzO+E+Oxqnezbf97xk5FNwpw63uVGFcK1hWMyPuiGsY X-Google-Smtp-Source: ABdhPJzkEabWOUiopRgq7qplYdFMfSYx3aCK6CRxNzCQ/byRmSPDSJHes+5zErcYmYEbWxxxQssAanq5Rq48xavoCnA= X-Received: by 2002:a1f:bf85:: with SMTP id p127mr12730288vkf.70.1595157999227; Sun, 19 Jul 2020 04:26:39 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Sun, 19 Jul 2020 04:26:28 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Content-Type: multipart/alternative; boundary="000000000000e79b3005aac9a971" Archived-At: Subject: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2020 11:26:42 -0000 --000000000000e79b3005aac9a971 Content-Type: text/plain; charset="UTF-8" Hi, I've read draft-kang-tcpm-accurate-data-scheduling-by-server-00. I think this is an interesting topic for mptcp, but I think it would be better to clarify the following points. 1: One thing I'm not very clear is why we cannot use MP_PRIO for the use cases described in the draft. I believe the draft should describe the cases where existing features cannot fulfill the requirements more specifically. 2: Clients also have their own constraints. (e.g. policy or routing) So, even though servers send a navigation request, they might not follow it. I think this point should be clarified. 3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1? Thanks, -- Yoshi --000000000000e79b3005aac9a971 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I've read=C2=A0draft-kang-tcpm-= accurate-data-scheduling-by-server-00.
I think this is an interes= ting=C2=A0topic for=C2=A0mptcp, but I think it would be better to clarify t= he following points.=C2=A0

1: One thing I'm no= t very clear is why we cannot use MP_PRIO for the use cases described in th= e draft. I believe the draft should describe the cases where existing=C2=A0= features cannot fulfill the requirements more specifically.=C2=A0

2: Clients also have their own constraints. (e.g. policy or= routing) So, even though servers send a navigation request, they might not= follow it. I think this point should be clarified.=C2=A0

3: What's the meaning of 'r', 'E', 'B' = flags in Section 4.1?

Thanks,
--
Yoshi
--000000000000e79b3005aac9a971-- From nobody Sun Jul 19 20:54:24 2020 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 6C5013A096D for ; Sun, 19 Jul 2020 20:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6cs9w5JvA6Y for ; Sun, 19 Jul 2020 20:54:21 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 0B0733A096A for ; Sun, 19 Jul 2020 20:54:21 -0700 (PDT) Received: from lhreml743-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BDF769B96A20F92998B8; Mon, 20 Jul 2020 04:54:18 +0100 (IST) Received: from lhreml741-chm.china.huawei.com (10.201.108.191) by lhreml743-chm.china.huawei.com (10.201.108.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Jul 2020 04:54:18 +0100 Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml741-chm.china.huawei.com (10.201.108.191) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 20 Jul 2020 04:54:18 +0100 Received: from DGGEMM534-MBS.china.huawei.com ([169.254.7.122]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0487.000; Mon, 20 Jul 2020 11:54:09 +0800 From: Kangjiao To: Yoshifumi Nishida , "tcpm@ietf.org Extensions" CC: Liangqiandeng Thread-Topic: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 Thread-Index: AQHWXb+HJHOpbU0oSkKL2jMMYvRPV6kP1fbA Date: Mon, 20 Jul 2020 03:54:09 +0000 Message-ID: <719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2C@dggemm534-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.102.89] Content-Type: multipart/alternative; boundary="_000_719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2Cdggemm534mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 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, 20 Jul 2020 03:54:23 -0000 --_000_719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2Cdggemm534mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9zaGksDQoNClRoYW5rcyBmb3IgeW91ciBzdWdnZXN0aW9ucy4gV2UgY2xhcmlmeSB0aGUg aXNzdWVzIGFzIGJlbG93Og0KDQoxOiBPbmUgdGhpbmcgSSdtIG5vdCB2ZXJ5IGNsZWFyIGlzIHdo eSB3ZSBjYW5ub3QgdXNlIE1QX1BSSU8gZm9yIHRoZSB1c2UgY2FzZXMgZGVzY3JpYmVkIGluIHRo ZSBkcmFmdC4gSSBiZWxpZXZlIHRoZSBkcmFmdCBzaG91bGQgZGVzY3JpYmUgdGhlIGNhc2VzIHdo ZXJlIGV4aXN0aW5nIGZlYXR1cmVzIGNhbm5vdCBmdWxmaWxsIHRoZSByZXF1aXJlbWVudHMgbW9y ZSBzcGVjaWZpY2FsbHkuDQoNCktKOiBUaGUgbmV3IE1QX05hdmlnYXRpb24gT3B0aW9uIGlzIHVz ZWQgZm9yIHRoZSBzZXJ2ZXIgdG8gaW5kaWNhdGUgZGVzdGluYXRpb24gbmV0d29yayBpbnRlcmZh Y2UgdG8gY2xpZW50IGZvciB3aGljaCBzZXJ2ZXIgd2FudHMgdG8gdXNlIGZvciB0cmFmZmljIHN3 aXRjaGluZy4gRm9yIG15IHVuZGVyc3RhbmRpbmcsIE1QX1BSSU8gaXMgdXNlZCB0byBzaWduYWwg YSBjaGFuZ2UgaW4gcHJpb3JpdHkgb2Ygc3ViZmxvd3MgdG8gdGhlIHBlZXIuIEluIGFwcGxpY2F0 aW9uLCBNUF9QUklPIGNhbiByZWR1Y2UgdGhlIGNoYW5jZSBvZiBkYXRhIHRyYW5zbWlzc2lvbiBv biBhIHNwZWNpZmljIHN1YmZsb3cgYnV0IGl0IGNhbm5vdCB0ZWxsIGl0cyBwZWVyIHdoaWNoIG5l dHdvcmsgaW50ZXJmYWNlIGlzIHRoZSBkZXN0aW5hdGlvbiBmcm9tIHNlcnZlciBzaWRlLiBGb3Ig ZXhhbXBsZSwgaWYgdGhlcmUgYXJlIG11bHRpcGxlIHN1YmZsb3dzIHdpdGggaGlnaCBwcmlvcml0 eSBmcm9tIGRpZmZlcmVuY2UgbmV0d29yayBpbnRlcmZhY2VzLCBjbGllbnQgcmVjZWl2aW5nIE1Q X1BSSU8gZG9lcyBub3Qga25vdyB3aGljaCBpcyB0aGUgdGFyZ2V0IG9uZS4NCg0KMjogQ2xpZW50 cyBhbHNvIGhhdmUgdGhlaXIgb3duIGNvbnN0cmFpbnRzLiAoZS5nLiBwb2xpY3kgb3Igcm91dGlu ZykgU28sIGV2ZW4gdGhvdWdoIHNlcnZlcnMgc2VuZCBhIG5hdmlnYXRpb24gcmVxdWVzdCwgdGhl eSBtaWdodCBub3QgZm9sbG93IGl0LiBJIHRoaW5rIHRoaXMgcG9pbnQgc2hvdWxkIGJlIGNsYXJp ZmllZC4NCg0KS0o6IElmIHRoZSBtZWNoYW5pc20gb2YgYWNjdXJhdGUtZGF0YS1zY2hlZHVsaW5n LWJ5LXNlcnZlciBpcyBkZXBsb3llZCwgdGhlIHByaW5jaXBsZSBpcyB0aGF0IHRoZSBzZXJ2ZXIg dGFrZXMgcHJlY2VkZW5jZS4NCg0KMzogV2hhdCdzIHRoZSBtZWFuaW5nIG9mICdyJywgJ0UnLCAn QicgZmxhZ3MgaW4gU2VjdGlvbiA0LjE/DQoNCktKOiAgRm9yIHRoZSBwcm90b2NvbCBkZXNpZ24s IHRoZSBkZWZpbml0aW9uIG9mIOKAmXLigJksIOKAmEXigJkgYW5kIOKAmULigJkgYXJlIGFzIGZv bGxvd2luZzoNCkZsYWcg4oCYcuKAmTogcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2FnZS4NCkZsYWcg 4oCYReKAmTogZXhpc3RzIHRvIHByb3ZpZGUgcmVsaWFiaWxpdHkgZm9yIHRoaXMgb3B0aW9uIChs aWtlIHRoYXQgaW4g4oCdQUREX0FERFLigJ0pLg0KRmxhZyDigJlC4oCZOiBpbmRpY2F0ZXMgd2hl dGhlciB0aGUgc3ViZmxvdyBvdmVyIHdoaWNoIHRoZSBvcHRpb24gaXMgcmVjZWl2ZWQgaXMgYSBi YWNrdXAgb25lICh0aGF0IGlzIGNvbXBhdGlhYmxlIHdpdGggdGhlIHZhbHVlIGJ5IE1QX1BSSU8p Lg0KDQpCdXQgd2UgYXJlIHRoaW5raW5nIHdoZXRoZXIgdGhlc2UgZmllbGRzIGFyZSBuZWNlc3Nh cnkgYW5kIHNob3VsZCBiZSBzZXQgYXMgbWFuZGF0b3J5Lg0KDQpTaW5jZXJlbHksDQpKaWFvDQpG cm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWW9z aGlmdW1pIE5pc2hpZGENClNlbnQ6IFN1bmRheSwgSnVseSAxOSwgMjAyMCA3OjI2IFBNDQpUbzog dGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zIDx0Y3BtQGlldGYub3JnPg0KU3ViamVjdDogW3RjcG1d IGNvbW1lbnRzIG9uIGRyYWZ0LWthbmctdGNwbS1hY2N1cmF0ZS1kYXRhLXNjaGVkdWxpbmctYnkt c2VydmVyLTAwDQoNCkhpLA0KSSd2ZSByZWFkIGRyYWZ0LWthbmctdGNwbS1hY2N1cmF0ZS1kYXRh LXNjaGVkdWxpbmctYnktc2VydmVyLTAwLg0KSSB0aGluayB0aGlzIGlzIGFuIGludGVyZXN0aW5n IHRvcGljIGZvciBtcHRjcCwgYnV0IEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGNsYXJp ZnkgdGhlIGZvbGxvd2luZyBwb2ludHMuDQoNCjE6IE9uZSB0aGluZyBJJ20gbm90IHZlcnkgY2xl YXIgaXMgd2h5IHdlIGNhbm5vdCB1c2UgTVBfUFJJTyBmb3IgdGhlIHVzZSBjYXNlcyBkZXNjcmli ZWQgaW4gdGhlIGRyYWZ0LiBJIGJlbGlldmUgdGhlIGRyYWZ0IHNob3VsZCBkZXNjcmliZSB0aGUg Y2FzZXMgd2hlcmUgZXhpc3RpbmcgZmVhdHVyZXMgY2Fubm90IGZ1bGZpbGwgdGhlIHJlcXVpcmVt ZW50cyBtb3JlIHNwZWNpZmljYWxseS4NCg0KMjogQ2xpZW50cyBhbHNvIGhhdmUgdGhlaXIgb3du IGNvbnN0cmFpbnRzLiAoZS5nLiBwb2xpY3kgb3Igcm91dGluZykgU28sIGV2ZW4gdGhvdWdoIHNl cnZlcnMgc2VuZCBhIG5hdmlnYXRpb24gcmVxdWVzdCwgdGhleSBtaWdodCBub3QgZm9sbG93IGl0 LiBJIHRoaW5rIHRoaXMgcG9pbnQgc2hvdWxkIGJlIGNsYXJpZmllZC4NCg0KMzogV2hhdCdzIHRo ZSBtZWFuaW5nIG9mICdyJywgJ0UnLCAnQicgZmxhZ3MgaW4gU2VjdGlvbiA0LjE/DQoNClRoYW5r cywNCi0tDQpZb3NoaQ0K --_000_719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2Cdggemm534mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1 NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3 MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIu MHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIFlvc2hpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyNC4wcHQ7bXNvLXBhcmEt bWFyZ2luLWxlZnQ6Mi4wZ2QiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+VGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb25zLiBXZSBjbGFyaWZ5IHRoZSBp c3N1ZXMgYXMgYmVsb3c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4xOiBPbmUgdGhpbmcgSSdtIG5vdCB2 ZXJ5IGNsZWFyIGlzIHdoeSB3ZSBjYW5ub3QgdXNlIE1QX1BSSU8gZm9yIHRoZSB1c2UgY2FzZXMg ZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4gSSBiZWxpZXZlIHRoZSBkcmFmdCBzaG91bGQgZGVzY3Jp YmUgdGhlIGNhc2VzIHdoZXJlIGV4aXN0aW5nJm5ic3A7ZmVhdHVyZXMgY2Fubm90IGZ1bGZpbGwg dGhlIHJlcXVpcmVtZW50cyBtb3JlIHNwZWNpZmljYWxseS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1MCUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtsaW5l LWhlaWdodDoxNTAlO2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPktK OiBUaGUgbmV3IE1QX05hdmlnYXRpb24gT3B0aW9uIGlzIHVzZWQgZm9yIHRoZSBzZXJ2ZXIgdG8g aW5kaWNhdGUgZGVzdGluYXRpb24gbmV0d29yayBpbnRlcmZhY2UgdG8gY2xpZW50IGZvciB3aGlj aCBzZXJ2ZXINCiB3YW50cyB0byB1c2UgZm9yIHRyYWZmaWMgc3dpdGNoaW5nLiBGb3IgbXkgdW5k ZXJzdGFuZGluZywgTVBfUFJJTyBpcyB1c2VkIHRvIHNpZ25hbCBhIGNoYW5nZSBpbiBwcmlvcml0 eSBvZiBzdWJmbG93cyB0byB0aGUgcGVlci4gSW4mbmJzcDthcHBsaWNhdGlvbiwgTVBfUFJJTyBj YW4gcmVkdWNlIHRoZSBjaGFuY2Ugb2YgZGF0YSB0cmFuc21pc3Npb24gb24gYSBzcGVjaWZpYyBz dWJmbG93IGJ1dCBpdCBjYW5ub3QgdGVsbCBpdHMgcGVlciB3aGljaCBuZXR3b3JrDQogaW50ZXJm YWNlIGlzIHRoZSBkZXN0aW5hdGlvbiBmcm9tIHNlcnZlciBzaWRlLiBGb3IgZXhhbXBsZSwgaWYg dGhlcmUgYXJlIG11bHRpcGxlIHN1YmZsb3dzIHdpdGggaGlnaCBwcmlvcml0eSBmcm9tIGRpZmZl cmVuY2UgbmV0d29yayBpbnRlcmZhY2VzLCBjbGllbnQgcmVjZWl2aW5nIE1QX1BSSU8gZG9lcyBu b3Qga25vdyB3aGljaCBpcyB0aGUgdGFyZ2V0IG9uZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Mjog Q2xpZW50cyBhbHNvIGhhdmUgdGhlaXIgb3duIGNvbnN0cmFpbnRzLiAoZS5nLiBwb2xpY3kgb3Ig cm91dGluZykgU28sIGV2ZW4gdGhvdWdoIHNlcnZlcnMgc2VuZCBhIG5hdmlnYXRpb24gcmVxdWVz dCwgdGhleSBtaWdodCBub3QgZm9sbG93IGl0LiBJIHRoaW5rIHRoaXMgcG9pbnQgc2hvdWxkIGJl IGNsYXJpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPktKOiBJZiB0aGUgbWVjaGFu aXNtIG9mIGFjY3VyYXRlLWRhdGEtc2NoZWR1bGluZy1ieS1zZXJ2ZXIgaXMgZGVwbG95ZWQsIHRo ZSBwcmluY2lwbGUgaXMgdGhhdCB0aGUgc2VydmVyIHRha2VzIHByZWNlZGVuY2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4zOiBXaGF0J3MgdGhlIG1lYW5pbmcgb2YgJ3InLCAnRScsICdCJyBmbGFncyBp biBTZWN0aW9uIDQuMT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+S0o6 Jm5ic3A7IEZvciB0aGUgcHJvdG9jb2wgZGVzaWduLCB0aGUgZGVmaW5pdGlvbiBvZiDigJly4oCZ LCDigJhF4oCZIGFuZCDigJlC4oCZIGFyZSBhcyBmb2xsb3dpbmc6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjI0LjBwdDttc28t cGFyYS1tYXJnaW4tbGVmdDoyLjBnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkZsYWcg 4oCYcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+4oCZPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj46DQogcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2FnZS4gPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjI0LjBw dDttc28tcGFyYS1tYXJnaW4tbGVmdDoyLjBnZCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PkZsYWcg4oCYRTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+4oCZPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj46DQogZXhpc3RzIHRvIHByb3ZpZGUgcmVsaWFiaWxpdHkgZm9y IHRoaXMgb3B0aW9uIChsaWtlIHRoYXQgaW4g4oCdQUREX0FERFLigJ0pLiA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjQuMHB0 O21zby1wYXJhLW1hcmdpbi1sZWZ0OjIuMGdkIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ RmxhZyDigJlCPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7igJk8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPjoNCiBpbmRpY2F0ZXMgd2hldGhlciB0aGUgc3ViZmxvdyBvdmVy IHdoaWNoIHRoZSBvcHRpb24gaXMgcmVjZWl2ZWQgaXMgYSBiYWNrdXAgb25lICh0aGF0IGlzIGNv bXBhdGlhYmxlIHdpdGggdGhlIHZhbHVlIGJ5IE1QX1BSSU8pLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1pbmRlbnQ6MTUuNzVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkJ1dCB3ZSBhcmUg dGhpbmtpbmcgd2hldGhlciB0aGVzZSBmaWVsZHMgYXJlIG5lY2Vzc2FyeSBhbmQgc2hvdWxkIGJl IHNldCBhcyBtYW5kYXRvcnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5T aW5jZXJlbHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkppYW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHRjcG0gW21haWx0bzp0Y3Bt LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPllvc2hpZnVtaSBOaXNoaWRh PGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSnVseSAxOSwgMjAyMCA3OjI2IFBNPGJyPg0KPGI+ VG86PC9iPiB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMgJmx0O3RjcG1AaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFt0Y3BtXSBjb21tZW50cyBvbiBkcmFmdC1rYW5nLXRjcG0tYWNj dXJhdGUtZGF0YS1zY2hlZHVsaW5nLWJ5LXNlcnZlci0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSd2ZSByZWFkJm5ic3A7ZHJhZnQt a2FuZy10Y3BtLWFjY3VyYXRlLWRhdGEtc2NoZWR1bGluZy1ieS1zZXJ2ZXItMDAuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkkgdGhpbmsgdGhpcyBpcyBhbiBpbnRlcmVzdGluZyZuYnNwO3RvcGljIGZv ciZuYnNwO21wdGNwLCBidXQgSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2xhcmlmeSB0 aGUgZm9sbG93aW5nIHBvaW50cy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjE6IE9uZSB0aGluZyBJJ20gbm90IHZlcnkgY2xlYXIgaXMgd2h5 IHdlIGNhbm5vdCB1c2UgTVBfUFJJTyBmb3IgdGhlIHVzZSBjYXNlcyBkZXNjcmliZWQgaW4gdGhl IGRyYWZ0LiBJIGJlbGlldmUgdGhlIGRyYWZ0IHNob3VsZCBkZXNjcmliZSB0aGUgY2FzZXMgd2hl cmUgZXhpc3RpbmcmbmJzcDtmZWF0dXJlcyBjYW5ub3QgZnVsZmlsbCB0aGUgcmVxdWlyZW1lbnRz IG1vcmUgc3BlY2lmaWNhbGx5LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+MjogQ2xpZW50cyBhbHNvIGhhdmUgdGhlaXIgb3duIGNvbnN0cmFp bnRzLiAoZS5nLiBwb2xpY3kgb3Igcm91dGluZykgU28sIGV2ZW4gdGhvdWdoIHNlcnZlcnMgc2Vu ZCBhIG5hdmlnYXRpb24gcmVxdWVzdCwgdGhleSBtaWdodCBub3QgZm9sbG93IGl0LiBJIHRoaW5r IHRoaXMgcG9pbnQgc2hvdWxkIGJlIGNsYXJpZmllZC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjM6IFdoYXQncyB0aGUgbWVhbmluZyBvZiAn cicsICdFJywgJ0InIGZsYWdzIGluIFNlY3Rpb24gNC4xPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4t LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3NoaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2Cdggemm534mbschi_-- From nobody Mon Jul 20 08:01:12 2020 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 668A43A0B81 for ; Mon, 20 Jul 2020 07:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dMUP0kA7eyOS for ; Mon, 20 Jul 2020 07:43:15 -0700 (PDT) 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 7A3AF3A0B80 for ; Mon, 20 Jul 2020 07:43:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4A497F40759; Mon, 20 Jul 2020 07:43:03 -0700 (PDT) To: mallman@icir.org, vern@icir.org, eblanton@cs.purdue.edu, martin.h.duke@gmail.com, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: cdeng@greatbeam.net, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200720144303.4A497F40759@rfc-editor.org> Date: Mon, 20 Jul 2020 07:43:03 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 20 Jul 2020 08:01:11 -0700 Subject: [tcpm] [Editorial Errata Reported] RFC5681 (6233) 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, 20 Jul 2020 14:43:17 -0000 The following errata report has been submitted for RFC5681, "TCP Congestion Control". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6233 -------------------------------------- Type: Editorial Reported by: Charles Deng Section: 4.3 Original Text ------------- Finally, after all loss in the given window of segments has been successfully retransmitted, cwnd MUST be set to no more than ssthresh and congestion avoidance MUST be used to further increase cwnd. Corrected Text -------------- Finally, after all loss in the given window of segments has been successfully retransmitted, cwnd MUST be set to no less than ssthresh and congestion avoidance MUST be used to further increase cwnd. Notes ----- if set cwnd no more than ssthresh, it will using slow start algorithm instead of congestion avoidance algorithm. so it should say "cwnd no less than ..." instead of "cwnd no more than ...". 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. -------------------------------------- RFC5681 (draft-ietf-tcpm-rfc2581bis-07) -------------------------------------- Title : TCP Congestion Control Publication Date : September 2009 Author(s) : M. Allman, V. Paxson, E. Blanton Category : DRAFT STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Tue Jul 21 07:05:23 2020 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 E52473A08CD; Tue, 21 Jul 2020 07:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z_0BS6dxAAOk; Tue, 21 Jul 2020 07:05:16 -0700 (PDT) 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 AF3EF3A08CC; Tue, 21 Jul 2020 07:05:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E1699F40727; Tue, 21 Jul 2020 07:05:00 -0700 (PDT) To: cdeng@greatbeam.net, mallman@icir.org, vern@icir.org, eblanton@cs.purdue.edu X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: martin.h.duke@gmail.com, iesg@ietf.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200721140500.E1699F40727@rfc-editor.org> Date: Tue, 21 Jul 2020 07:05:00 -0700 (PDT) Archived-At: Subject: [tcpm] [Errata Rejected] RFC5681 (6233) 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, 21 Jul 2020 14:05:18 -0000 The following errata report has been rejected for RFC5681, "TCP Congestion Control". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6233 -------------------------------------- Status: Rejected Type: Editorial Reported by: Charles Deng Date Reported: 2020-07-20 Rejected by: Martin Duke (IESG) Section: 4.3 Original Text ------------- Finally, after all loss in the given window of segments has been successfully retransmitted, cwnd MUST be set to no more than ssthresh and congestion avoidance MUST be used to further increase cwnd. Corrected Text -------------- Finally, after all loss in the given window of segments has been successfully retransmitted, cwnd MUST be set to no less than ssthresh and congestion avoidance MUST be used to further increase cwnd. Notes ----- if set cwnd no more than ssthresh, it will using slow start algorithm instead of congestion avoidance algorithm. so it should say "cwnd no less than ..." instead of "cwnd no more than ...". --VERIFIER NOTES-- This would be a significant design change in TCP. The original text is as intended by the community. -------------------------------------- RFC5681 (draft-ietf-tcpm-rfc2581bis-07) -------------------------------------- Title : TCP Congestion Control Publication Date : September 2009 Author(s) : M. Allman, V. Paxson, E. Blanton Category : DRAFT STANDARD Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Tue Jul 21 09:00:08 2020 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 0217E3A0B89 for ; Tue, 21 Jul 2020 09:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 3M_SqojqHYZw for ; Tue, 21 Jul 2020 09:00:01 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 6499E3A0B69 for ; Tue, 21 Jul 2020 09:00:01 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 06LFhNte062585; Tue, 21 Jul 2020 08:59:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : date : from : to : cc : subject : message-id : references : in-reply-to; s=20180706; bh=0eXhjLeE85ow7uhkTyTmQmdg8irQMWzHjN5PYjaVeFg=; b=tWBF3wq3cizs8YAQ5dQyDKnfAa2QpYQ6FwF+uh4OFiVN7ojZee0fL+B79MqWXXnG3eU/ cghTZuPvitfMXnQNcvUdemmgFRldwFkli0Wqa/Xs4Nrr4l1ZlzDKIhmY/t2W3V0bcBVP rqzgJBfj9eIpsoQHbSz6qnLYbqQ3K8vK3KOBBUD0Pxd0vIuqXLCKFKPb/bdXvbWPSb1D 805rm729eE0qnrDhO0ehVHc+gi5EZVqa87IeRtjRp59MDDt2tGr4VDGY94HhcIL5I5kJ Vx/4JS755av/4g1UYqSqFPHdOk6fIyoWWabDZJdxm+aTnJTOYrI27NfSoSk9pPfs4aQP JQ== Received: from rn-mailsvcp-mta-lapp01.rno.apple.com (rn-mailsvcp-mta-lapp01.rno.apple.com [10.225.203.149]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 32byr2a714-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 21 Jul 2020 08:59:48 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QDT00U37TRMBXO0@rn-mailsvcp-mta-lapp01.rno.apple.com>; Tue, 21 Jul 2020 08:59:46 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QDT00W00TONL600@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Tue, 21 Jul 2020 08:59:46 -0700 (PDT) X-Va-A: X-Va-T-CD: 3beaf764f461a8ab0294914a8b578f03 X-Va-E-CD: dbb4aa9d0c53e8100e25dcf92570366e X-Va-R-CD: 8e3f0004dc05f9a4784d4291b529a402 X-Va-CD: 0 X-Va-ID: 33b0dfa3-afe7-4380-a5b9-04f67dcb11bf X-V-A: X-V-T-CD: 3beaf764f461a8ab0294914a8b578f03 X-V-E-CD: dbb4aa9d0c53e8100e25dcf92570366e X-V-R-CD: 8e3f0004dc05f9a4784d4291b529a402 X-V-CD: 0 X-V-ID: c931e74f-7d89-4071-a89d-b0e9397aecfa X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-21_09:2020-07-21, 2020-07-21 signatures=0 MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from localhost ([17.235.54.194]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QDT00K9NTRL7200@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Tue, 21 Jul 2020 08:59:45 -0700 (PDT) Date: Tue, 21 Jul 2020 08:59:45 -0700 From: Christoph Paasch To: Kangjiao Cc: Yoshifumi Nishida , "tcpm@ietf.org Extensions" , Liangqiandeng Message-id: <20200721155945.GA93692@MacBook-Pro-64.local> References: <719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2C@dggemm534-mbs.china.huawei.com> In-reply-to: <719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2C@dggemm534-mbs.china.huawei.com> User-Agent: Mutt/1.12.2 (2019-09-21) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-21_09:2020-07-21, 2020-07-21 signatures=0 Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 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, 21 Jul 2020 16:00:07 -0000 Hello, as an overall comment, I agree that one of the difficulties around multipath is how the hosts can communicate to the peers the desired scheduling mechanisms. Currently there is no reliable way besides backup-bits which is a "hard" switch. However, often scheduling is much more fine-grained as shown in a number of the schedulers described in https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers-00. It's a bit similar to TCP which can't pick the peer's congestion-control and for example if one wants the peer to use a background-CC the host needs to resort to tuning the receive-window a la draft-bagnulo-iccrg-rledbat-00. So, having a way to communicate the scheduling "requirements" to the peer (and let the peer match these requirements with its local policies), would be good! One more comment inline: On 07/20/20 - 03:54, Kangjiao wrote: > Hi Yoshi, > > Thanks for your suggestions. We clarify the issues as below: > > 1: One thing I'm not very clear is why we cannot use MP_PRIO for the use > cases described in the draft. I believe the draft should describe the > cases where existing features cannot fulfill the requirements more > specifically. > > KJ: The new MP_Navigation Option is used for the server to indicate > destination network interface to client for which server wants to use for > traffic switching. For my understanding, MP_PRIO is used to signal a > change in priority of subflows to the peer. In application, MP_PRIO can > reduce the chance of data transmission on a specific subflow but it cannot > tell its peer which network interface is the destination from server side. > For example, if there are multiple subflows with high priority from > difference network interfaces, client receiving MP_PRIO does not know > which is the target one. For this particular scenario the server could send the MP_PRIO with backup-bit set on all subflows that the client should not use. Thus implicitly the high-priority network-interfaces can then be used by the client, right? Christoph > 2: Clients also have their own constraints. (e.g. policy or routing) So, > even though servers send a navigation request, they might not follow it. I > think this point should be clarified. > > KJ: If the mechanism of accurate-data-scheduling-by-server is deployed, > the principle is that the server takes precedence. > > 3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1? > > KJ: For the protocol design, the definition of ’r’, ‘E’ and ’B’ are as > following: Flag ‘r’: reserved for future usage. Flag ‘E’: exists to > provide reliability for this option (like that in ”ADD_ADDR”). Flag ’B’: > indicates whether the subflow over which the option is received is a > backup one (that is compatiable with the value by MP_PRIO). > > But we are thinking whether these fields are necessary and should be set > as mandatory. > > Sincerely, Jiao From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of > Yoshifumi Nishida Sent: Sunday, July 19, 2020 7:26 PM To: tcpm@ietf.org > Extensions Subject: [tcpm] comments on > draft-kang-tcpm-accurate-data-scheduling-by-server-00 > > Hi, I've read draft-kang-tcpm-accurate-data-scheduling-by-server-00. I > think this is an interesting topic for mptcp, but I think it would be > better to clarify the following points. > > 1: One thing I'm not very clear is why we cannot use MP_PRIO for the use > cases described in the draft. I believe the draft should describe the > cases where existing features cannot fulfill the requirements more > specifically. > > 2: Clients also have their own constraints. (e.g. policy or routing) So, > even though servers send a navigation request, they might not follow it. I > think this point should be clarified. > > 3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1? > > Thanks, -- Yoshi > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Tue Jul 21 09:04:21 2020 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 381D73A0C02 for ; Mon, 20 Jul 2020 08:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU0WgyRnfCkh for ; Mon, 20 Jul 2020 08:08:35 -0700 (PDT) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) (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 99AB63A0BFA for ; Mon, 20 Jul 2020 08:08:35 -0700 (PDT) Received: by mail-ot1-f42.google.com with SMTP id c25so12444817otf.7 for ; Mon, 20 Jul 2020 08:08:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=/Sa8+jReIFI4wtJWsGF7MO0BeAYeLLtjxs7eMWB6Nz4=; b=SsAg0xYG68dvnATipSghdk9ri6Al/tIJXjp1GbOgghd7FkcOiQvEnqF1P/xo/Bv2F0 DKmajNvjIDiUmlTuoFROcAn63Dnb3+AOrUxq2sPgnE0TB0MnfIZrpOthim1Q9HtJfGSA DuHsH8ZwHKWTkMhDklsi+cLvN0U8VuE+2djNZOFv5Ff7tq22B7hvH+lHea3PO6KcRWR7 nF8iWQzp1iiHu9GXFi1z5PomhMewBVgrIzOe6AwtHyHYgXEWMATTWzntSUNlQOWCqTCV 8WJz71B1YmJC+BvQb10imbTMu3ytTzv914s6eQEJ1QTM/B6TLFfwXnOO25Bd2c8k78iI vjPQ== X-Gm-Message-State: AOAM5302yajwH1JLgxvbQubS0m2UTG44r128uGWjSjuGhccMqCdFKIoT WdJ92knUXk6PQ9fiCf0moaIy+g== X-Google-Smtp-Source: ABdhPJzg5/8Xtfvt5ivuXvv7GUBt3ImtyO/A9egpu32BHBiFDZLK1KC5+hRRcyLmvwASo6oLU6tL5A== X-Received: by 2002:a9d:7352:: with SMTP id l18mr18550724otk.177.1595257714624; Mon, 20 Jul 2020 08:08:34 -0700 (PDT) Received: from [192.168.1.244] ([2600:1700:b380:3f00:4104:12d8:d7de:aa4f]) by smtp.gmail.com with ESMTPSA id t25sm3539610otc.80.2020.07.20.08.08.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2020 08:08:34 -0700 (PDT) From: "Mark Allman" To: "RFC Errata System" Cc: vern@icir.org, eblanton@cs.purdue.edu, martin.h.duke@gmail.com, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com, cdeng@greatbeam.net, tcpm@ietf.org, "Ethan Blanton" Date: Mon, 20 Jul 2020 11:08:32 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <4A9C6361-639D-459A-818B-7F2027CF5384@icir.org> In-Reply-To: <20200720144303.4A497F40759@rfc-editor.org> References: <20200720144303.4A497F40759@rfc-editor.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_FB88CBBA-2E09-4EB0-B24F-12B590B46862_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: X-Mailman-Approved-At: Tue, 21 Jul 2020 09:04:21 -0700 Subject: Re: [tcpm] [Editorial Errata Reported] RFC5681 (6233) 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, 20 Jul 2020 15:08:37 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_FB88CBBA-2E09-4EB0-B24F-12B590B46862_= Content-Type: text/plain > The following errata report has been submitted for RFC5681, > "TCP Congestion Control". > > -------------------------------------- > Type: Editorial > Reported by: Charles Deng This is not editorial as it would change the allowed operation of the algorithms. > Section: 4.3 > > Original Text > ------------- > Finally, after all loss in the given window of segments > has been successfully retransmitted, cwnd MUST be set to no more than > ssthresh and congestion avoidance MUST be used to further increase > cwnd. > > Corrected Text > -------------- > Finally, after all loss in the given window of segments > has been successfully retransmitted, cwnd MUST be set to no less than > ssthresh and congestion avoidance MUST be used to further increase > cwnd. > > Notes > ----- > if set cwnd no more than ssthresh, it will using slow start > algorithm instead of congestion avoidance algorithm. so it should > say "cwnd no less than ..." instead of "cwnd no more than ...". This is incorrect and the errata should be rejected. The wording isn't particularly great, but the idea is that at the end of the loss period we want cwnd to be half of the outstanding data when we first detected loss. And, in particular, we **certainly do not want** cwnd to be LARGER than half the outstanding data when loss occurred. And, by saying "cwnd MUST be no **LESS**" we are specifying that it must be larger-than-half. So, this language is a clearly both (a) a non-editorial algorithm change and (b) wrong. The wording leads to the confusion, however, I think. If one were to set cwnd to less than ssthresh (hence being more conservative) then we'd probably slow start to ssthresh before entering congestion avoidance, as the proposed errata notes. If I were to do anything here I think I'd strike "and congestion avoidance MUST be used to further increase cwnd" from the end of the sentence. I.e., just let what naturally happens happen. But, the current text is conservative. And, it may well be that we actually meant to use CA in this case even if cwnd < ssthresh for some reason I am mis-remembering. So, I'd want to page all that back in before agreeing with any errata. I am not sure it's really that big of a problem to worry about. allman --=_MailMate_FB88CBBA-2E09-4EB0-B24F-12B590B46862_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iG8EARECAC8WIQR2wAGDYhexl/6SqCRbKutazjIizgUCXxWzcBEcbWFsbG1hbkBp Y2lyLm9yZwAKCRBbKutazjIizuxZAJ9iuYHsmN1tZC4RtGgnDMMi3j/NnQCgjYrg TqlUssPTrSO7i5+8fg/680Y= =pj8c -----END PGP SIGNATURE----- --=_MailMate_FB88CBBA-2E09-4EB0-B24F-12B590B46862_=-- From vern@icsi.berkeley.edu Mon Jul 20 08:11:18 2020 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 71FB63A0C0C for ; Mon, 20 Jul 2020 08:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQX34AxMjr8z for ; Mon, 20 Jul 2020 08:11:15 -0700 (PDT) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (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 543BD3A0C0A for ; Mon, 20 Jul 2020 08:11:15 -0700 (PDT) Received: by mail-pg1-f170.google.com with SMTP id p3so10433838pgh.3 for ; Mon, 20 Jul 2020 08:11:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=EYRv8MOKrSCXePhyqXf9P1G5unWz2uPAf61WbE2J4uk=; b=TD7KMkcuMkksF0eFAEwvZc2fd2CiJx5rWWYdFErU9UPH/90sgNrFpHqojgUCP0eq7U nNUwbCchI9Nr5KBEK8CN24HFnQAjkQLTLodgldLLuoI9+SBC6FPOSqAORooOjBsLwff1 7aWk1Imkj5BCcGHvLjxPFrFsTdbcy/CYRVjZQ9MQGfot9PRhfyHncuLCiBSE4vlKX2+y Gg8ABu9znxrhiIB9SIT6is/41+2Q8FqhXAAkH0nLsn3PaB6gxWaORDFLg56Tg08f0Hr2 ih+cmwEsUaxHJiytdUzXgXPsT2YphHhPY/oJBh7sDTiotEOMPtKr5pp54FbqdtM6A9tD CUqQ== X-Gm-Message-State: AOAM533HEsefkRn6cT1SFs4e/MU8nMV2owPvo+Vs6xb9kvNNJ1vANxz+ KYPk/VquvF2ynVrzpQNzlodnjw== X-Google-Smtp-Source: ABdhPJyscbptLK7n7jrDTgx6TyK7NyNYLwJ0a3n+2gSuXl+WGeZW3WaDuDzpZqH/p7XT4XOEr9p2RQ== X-Received: by 2002:a62:7a07:: with SMTP id v7mr19532264pfc.76.1595257874766; Mon, 20 Jul 2020 08:11:14 -0700 (PDT) Received: from [192.168.8.5] (c-24-7-158-161.hsd1.ca.comcast.net. [24.7.158.161]) by smtp.gmail.com with ESMTPSA id 22sm16819490pfh.157.2020.07.20.08.11.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jul 2020 08:11:13 -0700 (PDT) From: "Vern Paxson" To: "Mark Allman" Cc: "RFC Errata System" , eblanton@cs.purdue.edu, martin.h.duke@gmail.com, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com, cdeng@greatbeam.net, tcpm@ietf.org, "Ethan Blanton" Date: Mon, 20 Jul 2020 08:11:12 -0700 X-Mailer: MailMate (1.13.1r5671) Message-ID: <2A8B0C39-38BF-4EBC-8A45-BB22A3F16011@icir.org> In-Reply-To: <4A9C6361-639D-459A-818B-7F2027CF5384@icir.org> References: <20200720144303.4A497F40759@rfc-editor.org> <4A9C6361-639D-459A-818B-7F2027CF5384@icir.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Tue, 21 Jul 2020 09:04:21 -0700 Subject: Re: [tcpm] [Editorial Errata Reported] RFC5681 (6233) 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, 20 Jul 2020 15:16:02 -0000 On 20 Jul 2020, at 8:08, Mark Allman wrote: > [stuff that all matches my read, too] -- Vern From nobody Tue Jul 21 09:04:29 2020 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 892C93A0C43 for ; Mon, 20 Jul 2020 08:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no 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 SzTV-wC3KOze for ; Mon, 20 Jul 2020 08:21:11 -0700 (PDT) Received: from cathode.kb8ojh.net (cathode.kb8ojh.net [162.243.72.198]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD0D3A0C41 for ; Mon, 20 Jul 2020 08:21:11 -0700 (PDT) Received: from anode.kb8ojh.net (cpe-74-77-94-120.buffalo.res.rr.com [74.77.94.120]) by cathode.kb8ojh.net (Postfix) with ESMTPSA id 6B7E440263; Mon, 20 Jul 2020 15:21:10 +0000 (UTC) Received: by anode.kb8ojh.net (Postfix, from userid 1000) id 91047400CA; Mon, 20 Jul 2020 11:21:09 -0400 (EDT) Date: Mon, 20 Jul 2020 11:21:09 -0400 From: Ethan Blanton To: Mark Allman Cc: RFC Errata System , vern@icir.org, martin.h.duke@gmail.com, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com, cdeng@greatbeam.net, tcpm@ietf.org Message-ID: <20200720152109.GA2853@mail.kb8ojh.net> Mail-Followup-To: Mark Allman , RFC Errata System , vern@icir.org, martin.h.duke@gmail.com, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com, cdeng@greatbeam.net, tcpm@ietf.org References: <20200720144303.4A497F40759@rfc-editor.org> <4A9C6361-639D-459A-818B-7F2027CF5384@icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9C6361-639D-459A-818B-7F2027CF5384@icir.org> X-GnuPG-Fingerprint: 2A9A 7752 8B91 6586 6289 FD3D 6CA9 2AC6 A1A8 AD0E User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: X-Mailman-Approved-At: Tue, 21 Jul 2020 09:04:21 -0700 Subject: Re: [tcpm] [Editorial Errata Reported] RFC5681 (6233) 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, 20 Jul 2020 15:21:13 -0000 Mark Allman wrote: > This is incorrect and the errata should be rejected. Agreed, for the reasons Mark mentioned. > If I were to do anything here I think I'd strike "and congestion > avoidance MUST be used to further increase cwnd" from the end of the > sentence. I.e., just let what naturally happens happen. But, the > current text is conservative. And, it may well be that we actually > meant to use CA in this case even if cwnd < ssthresh for some reason > I am mis-remembering. So, I'd want to page all that back in before > agreeing with any errata. I am not sure it's really that big of a > problem to worry about. I do not recall any reason that we must use CA instead of SS for the case of cwnd < ssthresh, but I also know that these things are very subtle and required a lot of discussion, so I am not too keen on trying to amend this errata or propose a new errata to handle that case. I believe that the current document is correct in this point, and that while it could possibly be clarified, a careful reading is still adequate to understand the intent. Ethan From nobody Wed Jul 22 00:21:42 2020 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 5C7973A0E9D for ; Wed, 22 Jul 2020 00:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXVzAD-gWgCL for ; Wed, 22 Jul 2020 00:21:39 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 CDB1D3A0E9C for ; Wed, 22 Jul 2020 00:21:38 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id d11so624557vsq.3 for ; Wed, 22 Jul 2020 00:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=umSxwOhnxJFGt/Y95BnTageorW/ylMYHaAEeKw6Agp8=; b=SBzWosuCNWS2PV1JdfCcn1yrajNoI0RwA3fv4VmzHko3q0zdBuQhhRF4Zgva+3hQ/O sweraTy6IyOjRHYjNlgDICkivy3Z2TeudTNv/x3hktNN9bKl3GBYvCWn+6HdgvesI26P 6x3EVF0yePX+X/Em5Z6LKH6O0KnIx2cb/DIsEL/0nVdnI4TRFISSu8klnY9IhFWPPhhY KoCfScGwXdMfO/dsfNrJ49NRnE8DXyCkcfFdEMb5LXnviJ/IVnpb3ozEMhk9blmZET4p He5bDF35kNIvykNNIen3aD/zpnFpVs1lIcMnJOhFQPVTmfIRc5rDEExOwP5KUQnXYFgJ KBSg== 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=umSxwOhnxJFGt/Y95BnTageorW/ylMYHaAEeKw6Agp8=; b=TC1E+QxMbq05/1vcQ5Dkm0NxrZimXKLwZmKmihw72xDn6udsWCDPayzTYYOhUpzuSV rja99opjSM5C9we+A2WQ77lDvIRtGPEJAudhsp8+VcDdp8OhxPiTLF/kLNFaQW3Ffhy+ mOZ7agcqdr3/Y1t54hGY26qOGmnWLTXrKGFADhAtcI4kNlm3Bpw6dcAupEdlduNYnpYB yeJuO3K6ivK8Htxw5gRMOxrEV+gLg3urpUHx05HTfnRkGj1vvnV4leMxNydDwwLYOVKS dJfpCOoejBGUUkUw8fKuXBsT7coQed7ZDmAFMiwcDQ3oCbHEX4eUSJp93BLh8K1HX+OU ywpQ== X-Gm-Message-State: AOAM530G9jFcGmZqGHl3LoYd7ryA4AQMqhlbG9NYJK8lreuXI3DbPDvd BIk0h12X1PDfAw1VKEX8WfC6SchndAwLV8vTen8= X-Google-Smtp-Source: ABdhPJzzIrpz/l8ovVjqcvIMWm056Jq+t4poTW4ppeftsJu4BgQzHyNFDNz040POK0xu74xRWA0TWZRbd9NgKlTAsA8= X-Received: by 2002:a67:f74a:: with SMTP id w10mr21353416vso.65.1595402496911; Wed, 22 Jul 2020 00:21:36 -0700 (PDT) MIME-Version: 1.0 References: <719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2C@dggemm534-mbs.china.huawei.com> In-Reply-To: <719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2C@dggemm534-mbs.china.huawei.com> From: Yoshifumi Nishida Date: Wed, 22 Jul 2020 00:21:25 -0700 Message-ID: To: Kangjiao Cc: "tcpm@ietf.org Extensions" , Liangqiandeng Content-Type: multipart/alternative; boundary="0000000000001a2b2005ab0297ee" Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 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, 22 Jul 2020 07:21:40 -0000 --0000000000001a2b2005ab0297ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kangjiao, Thanks for the response. I put my comments in lines. On Sun, Jul 19, 2020 at 8:54 PM Kangjiao wrote: > Hi Yoshi, > > > > Thanks for your suggestions. We clarify the issues as below: > > > > 1: One thing I'm not very clear is why we cannot use MP_PRIO for the use > cases described in the draft. I believe the draft should describe the cas= es > where existing features cannot fulfill the requirements more specifically= . > > > > KJ: The new MP_Navigation Option is used for the server to indicate > destination network interface to client for which server wants to use for > traffic switching. For my understanding, MP_PRIO is used to signal a chan= ge > in priority of subflows to the peer. In application, MP_PRIO can reduce t= he > chance of data transmission on a specific subflow but it cannot tell its > peer which network interface is the destination from server side. For > example, if there are multiple subflows with high priority from differenc= e > network interfaces, client receiving MP_PRIO does not know which is the > target one. > I think It would be better if you can show more concrete examples for the scenario in the draft. I would like to use the example in Section 3.2 of the draft for this. (BTW, I personally prefer to use IP_C1 or IP_S1 or C1, S1 rather than IP1, IP2 so that it will be easy to understand which address belongs to client or server) If the server sends MP_PRIO with B flag to the client by using and , I think the client will send traffic to IP4. Isn't this what the server wants? 2: Clients also have their own constraints. (e.g. policy or routing) So, > even though servers send a navigation request, they might not follow it. = I > think this point should be clarified. > > > > KJ: If the mechanism of accurate-data-scheduling-by-server is deployed, > the principle is that the server takes precedence. > Well, let's say the server wants to use 5G because it's beneficial for them, but the client doesn't want to use it because it's costly. The client still should follow the server's request? 3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1? > > > > KJ: For the protocol design, the definition of =E2=80=99r=E2=80=99, =E2= =80=98E=E2=80=99 and =E2=80=99B=E2=80=99 are as > following: > > Flag =E2=80=98r=E2=80=99: reserved for future usage. > > Flag =E2=80=98E=E2=80=99: exists to provide reliability for this option (= like that in > =E2=80=9DADD_ADDR=E2=80=9D). > > Flag =E2=80=99B=E2=80=99: indicates whether the subflow over which the op= tion is received > is a backup one (that is compatiable with the value by MP_PRIO). > > > > But we are thinking whether these fields are necessary and should be set > as mandatory. > Got it. Thanks for clarification. I think you'd better put these info into the draft later. Thanks, -- Yoshi > --0000000000001a2b2005ab0297ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Kangjiao,

Thanks for= the response.
I put my comments in lines.

On Sun, Jul 19, 2020 at 8:54 = PM Kangjiao <kangjiao@huawei.com<= /a>> wrote:

Hi Yoshi,

=C2=A0

Thanks for your suggestions. We clarify the issues= as below:

=C2=A0

1: One thing I'm not very c= lear is why we cannot use MP_PRIO for the use cases described in the draft.= I believe the draft should describe the cases where existing=C2=A0features= cannot fulfill the requirements more specifically.=C2=A0

=C2=A0

KJ: Th= e new MP_Navigation Option is used for the server to indicate destination n= etwork interface to client for which server wants to use for traffic switching. For my understanding, MP_PRIO is used = to signal a change in priority of subflows to the peer. In=C2=A0application= , MP_PRIO can reduce the chance of data transmission on a specific subflow = but it cannot tell its peer which network interface is the destination from server side. For example, if there are m= ultiple subflows with high priority from difference network interfaces, cli= ent receiving MP_PRIO does not know which is the target one.



2: Clients also have their own = constraints. (e.g. policy or routing) So, even though servers send a naviga= tion request, they might not follow it. I think this point should be clarif= ied.

=C2=A0

KJ: If the mechanism of accurate-data-scheduling-b= y-server is deployed, the principle is that the server takes precedence.



3: What's the meaning of &#= 39;r', 'E', 'B' flags in Section 4.1?

=C2=A0

KJ:=C2=A0 For the protocol design, the definition = of =E2=80=99r=E2=80=99, =E2=80=98E=E2=80=99 and =E2=80=99B=E2=80=99 are as = following:

Flag =E2=80=98r<= span style=3D"font-size:10.5pt;font-family:=E5=BE=AE=E8=BD=AF=E9=9B=85=E9= =BB=91,sans-serif">=E2=80=99: reserved for future usage.

Flag =E2=80=98E<= span style=3D"font-size:10.5pt;font-family:=E5=BE=AE=E8=BD=AF=E9=9B=85=E9= =BB=91,sans-serif">=E2=80=99: exists to provide reliability for this option (like that in =E2=80=9DADD_A= DDR=E2=80=9D).

Flag =E2=80=99B<= span style=3D"font-size:10.5pt;font-family:=E5=BE=AE=E8=BD=AF=E9=9B=85=E9= =BB=91,sans-serif">=E2=80=99: indicates whether the subflow over which the option is received is a backu= p one (that is compatiable with the value by MP_PRIO).=

=C2=A0

But we are thinking = whether these fields are necessary and should be set as mandatory.


Got it. Thanks for clarifica= tion. I think you'd better put these info into the draft later.

--0000000000001a2b2005ab0297ee-- From nobody Wed Jul 22 02:03:56 2020 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 CFC013A079E; Wed, 22 Jul 2020 02:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEnoeu4ibwxN; Wed, 22 Jul 2020 02:03:53 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 40DF83A079C; Wed, 22 Jul 2020 02:03:53 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id o8so1200047wmh.4; Wed, 22 Jul 2020 02:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t78R6O3eBcTrrnE9kl3iyHbtdo224yQuofy8VYP0CIU=; b=XD2FMSKVWRmWZKs9L7xXeq4GjTZVwhTycu/OWIk2JHx/gB1433oIZ7IBzS7Sva3Mz3 JaMM6DBQf/WPi6kq08Re/yJT1u0gMxcGjCBwaA/78jmUGJW1Bf6ccH60YlzevVVjMzir XtlTFPyaVEohDESKqrZTxTYlRQxWptgi2/sh8Q6vXK7AJkNzEc3Cqh9pVax0bnFIKT+7 TDeamU7xn4bEhjhu+esl0fesYT6wN7Cvp0/giu/K+4DIHZb3cyrg+2iAsS64+HtiZj15 KZT8mgg1aWSrdpfHEq7rHy8Ej3D7p4PoWb0zD1LUER46IH5pyiEPuCTlHyOFcG5xZ69S 7qzA== 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=t78R6O3eBcTrrnE9kl3iyHbtdo224yQuofy8VYP0CIU=; b=Sc2enJzO8Vr+2FLyjw6OZg9V6hwDOiYC5q6EGQF3pOxOB3/dzZnhv2ei5SZsIbXw2w np/MGyP0ftxbzM1no7dDt8JLUr5riArY1uedzQGyn+/KOxNr+8jd6EjChHuISK2TPy2c pPywx9ctccfs3DaoJQX2DaJEbFkLmyfexWtpyZf4VsD7JEhBxGmSG7BNFw9rL+OtRrYv mKgViIcB9viuyuy+w2Li/rERXkmyXNztUfPJUKKpy002QHItb/I0+1GSsJOVE+MBkE15 ooqsApxa3gR/Gl9KrvqR2otTIcoY51kteo4+ynhrkahhRmdMPK8Zh0QrgeKZQkBkQkfw 6rEg== X-Gm-Message-State: AOAM532Ul1EG1tU2Eg98rkw+FrDSHIgv01aDgg0ivH/loN0KJrh03Mgv cxXRkYj+D9/09lqMyhljfYEtuQH6MA3i9Ls9ZBWTb7on X-Google-Smtp-Source: ABdhPJxXR8bRiA3xqlwmNawbqhceAIJQxU9jnnHxFS7YKNvSVZkHotpSLSO4Q8muwtRYouMQ4hcwaYo4oHmoKm5mBWc= X-Received: by 2002:a1c:770f:: with SMTP id t15mr1032680wmi.22.1595408631096; Wed, 22 Jul 2020 02:03:51 -0700 (PDT) MIME-Version: 1.0 References: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: From: Juhamatti Kuusisaari Date: Wed, 22 Jul 2020 12:03:38 +0300 Message-ID: To: tcpm-chairs@ietf.org Cc: Joseph Touch , tcpm IETF list Content-Type: multipart/alternative; boundary="000000000000ba691205ab04043f" Archived-At: Subject: [tcpm] Presentation slot requests for IETF 108 (online) 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, 22 Jul 2020 09:03:55 -0000 --000000000000ba691205ab04043f Content-Type: text/plain; charset="UTF-8" Dear chairs, We would like to request a presentation slot for IETF 108. Please find next the details of the request: * Draft name / presentation title: draft-touch-tcpm-ao-test-vectors-00 * Presenter: Juhamatti Kuusisaari * Total duration (including Q&A): 15 minutes Thanks, Juhamatti > Hi all, > > Given that we had a pretty packed agenda during the virtual interim > meeting, the chairs have asked for two slots during IETF 108. This > basically implies that we have again the 2:30 hour slot that TCPM used to > have for many years. > > According to the draft agenda for IETF 108, TCPM has been scheduled for > Monday Session I (1:40) and Monday Session II (0:50). > > If you are interested in presenting, please let the chairs know until > **Monday 2020-07-13**: > > * Draft name / presentation title > * Presenter > * Total duration (including Q&A) > > Thanks > > Michael (2x) and Yoshi > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --000000000000ba691205ab04043f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear chairs,

We would like to request a presentation slot for IETF 108.

Please find next the details of the request:

* Draft name / presentation title: draft-touch-tcpm-ao-test-vectors-00
* Presenter:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Juhamatti Kuusisaari
* Total duration (including Q&A):=C2=A0 =C2=A015 minutes

Thanks,

Juhamatti


> Hi all,
>
> Given that we had a pretty packed agenda during the virtual interim > meeting, the chairs have asked for two slots during IETF 108. This
> basically implies that we have again the 2:30 hour slot that TCPM used= to
> have for many years.
>
> According to the draft agenda for IETF 108, TCPM has been scheduled fo= r
> Monday Session I (1:40) and Monday Session II (0:50).
>
> If you are interested in presenting, please let the chairs know until<= br> > **Monday 2020-07-13**:
>
> * Draft name / presentation title
> * Presenter
> * Total duration (including Q&A)
>
> Thanks
>
> Michael (2x) and Yoshi
>
> _______________________________________________
> tcpm mailing list
> = tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm=
--000000000000ba691205ab04043f-- From cdeng@greatbeam.net Tue Jul 21 03:35:51 2020 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 D47633A093C for ; Tue, 21 Jul 2020 03:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MSGID_FROM_MTA_HEADER=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1H1G0uZl-fP for ; Tue, 21 Jul 2020 03:35:48 -0700 (PDT) Received: from smtpbg501.qq.com (smtpbg501.qq.com [203.205.250.101]) (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 E91E73A0845 for ; Tue, 21 Jul 2020 03:35:47 -0700 (PDT) X-QQ-GoodBg: 0 X-QQ-SSF: 0010000000000020 X-QQ-FEAT: 7560NedJMvtze9AsuBIuek5yFrYVe907T2yGPjEyd41CF2/xJloRgvfbjHK2Z XGrwdxbB/h/BT2zcwDuWUiAom028iAOJgL0ZouupDJzit253KN2skxfmzux+Ax+VWGRA9/d e+yRkyxrz/Sm3F346GSSuRYYFGzbKIGIGhzanV9Mm3Gad8OnFQtboD3qafbzmTRo3JNXw4j OzyZHnMlQdpA5w9kMUhfp+TJ/9DGEw0zyMF8wGdKTNZ+hCGipiON8ZXvdxL0NrpgiXvWkBK 88xcE8XtF0lp3pTAlDtJmmNoiIAnqu88gpeg== X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 219.128.53.23 X-QQ-STYLE: X-QQ-mid: llogic42t1595327636t6544147 From: "=?utf-8?B?Q2hhcmxlcyBEZW5n?=" To: "=?utf-8?B?TWFyayBBbGxtYW4=?=" , "=?utf-8?B?UkZDIEVycmF0YSBTeXN0ZW0=?=" Cc: "=?utf-8?B?dmVybg==?=" , "=?utf-8?B?ZWJsYW50b24=?=" , "=?utf-8?B?bWFydGluLmguZHVrZQ==?=" , "=?utf-8?B?bWFnbnVzLndlc3Rlcmx1bmQ=?=" , "=?utf-8?B?bWljaGFlbC5zY2hhcmY=?=" , "=?utf-8?B?dHVleGVu?=" , "=?utf-8?B?bnNkLmlldGY=?=" , "=?utf-8?B?dGNwbQ==?=" , "=?utf-8?B?RXRoYW4gQmxhbnRvbg==?=" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_5F16C494_1633CD28_45C45F21" Content-Transfer-Encoding: 8Bit Date: Tue, 21 Jul 2020 18:33:56 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x References: <20200720144303.4A497F40759@rfc-editor.org> <4A9C6361-639D-459A-818B-7F2027CF5384@icir.org> In-Reply-To: <4A9C6361-639D-459A-818B-7F2027CF5384@icir.org> X-QQ-ReplyHash: 2241690902 X-QQ-SENDSIZE: 520 Received: from qq.com (unknown [127.0.0.1]) by smtp.qq.com (ESMTP) with SMTP id ; Tue, 21 Jul 2020 18:33:58 +0800 (CST) Feedback-ID: llogic:greatbeam.net:qybgweb:qybgweb11 Archived-At: X-Mailman-Approved-At: Wed, 22 Jul 2020 10:03:39 -0700 Subject: Re: [tcpm] [Editorial Errata Reported] RFC5681 (6233) 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, 22 Jul 2020 12:14:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_5F16C494_1633CD28_45C45F21 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyaywNCg0KDQombmJzcDsgJm5ic3A7VGhhbmtzIGZvciB5b3VyIGNsYXJpZmljYXRp b24uIEkgZ290IHVuZGVyc3RhbmQgdGhhdCB0aGUgY3duZCBzaG91bGQgYmUgc2V0IHRvIG5v IG1vcmUgdGhhbiBzc3RocmVzaC4NCg0KDQomZ3Q7Jmd0O0FuZCwgaXQgbWF5IHdlbGwgYmUg dGhhdCB3ZSBhY3R1YWxseSBtZWFudCB0byB1c2UgQ0EgaW4gdGhpcyBjYXNlIGV2ZW4gaWYg Y3duZCA8IHNzdGhyZXNoIGZvciBzb21lIHJlYXNvbiBJIGFtIG1pcy1yZW1lbWJlcmluZy4m bmJzcDsNCg0KDQombmJzcDsgJm5ic3A7YnV0IGNhbiB5b3Uga2luZGx5IGNsYXJpZnkgdGhh dCBhIHNjZW5hcmlvIFRDUCBuZWVkIGdldCBmb2xsb3dpbmcgQ0EgcnVsZXMgd2hlbiBjd25k IDwgc3N0aHJlc2ggPyZuYnNwOyBpZiB0aGVyZSBpcyBhIHN1Y2ggc2NlbmFyaW8sIGl0IG1l YW5zIFRDUCBjYW5ub3Qgb25seSBmb2xsb3dpbmcgcnVsZXMgb2YgQ0Egb3IgU1MgYWNjb3Jk aW5nIHRvIHZhbHVlcyBvZiBjd25kIGFuZCBzc3RocmVzaCBidXQgc3RhdGUgZmxhZ3Mgc29t ZXRoaW5nIGxpa2UgU1Mgc3RhdGUgYW5kIENBIHN0YXRlLg0KDQoNCkJlc3Qgd2lzaGVzDQpj aGFybGVzDQombmJzcDsNCi0tLS0tLS0tLS0tLS0tLS0tLSZuYnNwO09yaWdpbmFsJm5ic3A7 LS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAmbmJzcDsiTWFyayBBbGxtYW4iPG1hbGxtYW5A aWNpci5vcmcmZ3Q7Ow0KRGF0ZTogJm5ic3A7TW9uLCBKdWwgMjAsIDIwMjAgMTE6MDggUE0N ClRvOiAmbmJzcDsiUkZDIEVycmF0YSBTeXN0ZW0iPHJmYy1lZGl0b3JAcmZjLWVkaXRvci5v cmcmZ3Q7OyANCkNjOiAmbmJzcDsidmVybiI8dmVybkBpY2lyLm9yZyZndDs7ICJlYmxhbnRv biI8ZWJsYW50b25AY3MucHVyZHVlLmVkdSZndDs7ICJtYXJ0aW4uaC5kdWtlIjxtYXJ0aW4u aC5kdWtlQGdtYWlsLmNvbSZndDs7ICJtYWdudXMud2VzdGVybHVuZCI8bWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tJmd0OzsgIm1pY2hhZWwuc2NoYXJmIjxtaWNoYWVsLnNjaGFy ZkBocy1lc3NsaW5nZW4uZGUmZ3Q7OyAidHVleGVuIjx0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUm Z3Q7OyAibnNkLmlldGYiPG5zZC5pZXRmQGdtYWlsLmNvbSZndDs7ICJjZGVuZyI8Y2RlbmdA Z3JlYXRiZWFtLm5ldCZndDs7ICJ0Y3BtIjx0Y3BtQGlldGYub3JnJmd0OzsgIkV0aGFuIEJs YW50b24iPGVsYkBwc2cuY29tJmd0OzsgDQpTdWJqZWN0OiAmbmJzcDtSZTogW0VkaXRvcmlh bCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzU2ODEgKDYyMzMpDQoNCiZuYnNwOw0KDQoNCiZndDsg VGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZD NTY4MSwNCiZndDsgIlRDUCBDb25nZXN0aW9uIENvbnRyb2wiLg0KJmd0Ow0KJmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KJmd0OyBUeXBlOiBFZGl0b3Jp YWwNCiZndDsgUmVwb3J0ZWQgYnk6IENoYXJsZXMgRGVuZyA8Y2RlbmdAZ3JlYXRiZWFtLm5l dCZndDsNCg0KVGhpcyBpcyBub3QgZWRpdG9yaWFsIGFzIGl0IHdvdWxkIGNoYW5nZSB0aGUg YWxsb3dlZCBvcGVyYXRpb24gb2YNCnRoZSBhbGdvcml0aG1zLg0KDQomZ3Q7IFNlY3Rpb246 IDQuMw0KJmd0Ow0KJmd0OyBPcmlnaW5hbCBUZXh0DQomZ3Q7IC0tLS0tLS0tLS0tLS0NCiZn dDsgRmluYWxseSwgYWZ0ZXIgYWxsIGxvc3MgaW4gdGhlIGdpdmVuIHdpbmRvdyBvZiBzZWdt ZW50cw0KJmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgcmV0cmFuc21pdHRlZCwgY3duZCBN VVNUIGJlIHNldCB0byBubyBtb3JlIHRoYW4NCiZndDsgc3N0aHJlc2ggYW5kIGNvbmdlc3Rp b24gYXZvaWRhbmNlIE1VU1QgYmUgdXNlZCB0byBmdXJ0aGVyIGluY3JlYXNlDQomZ3Q7IGN3 bmQuDQomZ3Q7DQomZ3Q7IENvcnJlY3RlZCBUZXh0DQomZ3Q7IC0tLS0tLS0tLS0tLS0tDQom Z3Q7IEZpbmFsbHksIGFmdGVyIGFsbCBsb3NzIGluIHRoZSBnaXZlbiB3aW5kb3cgb2Ygc2Vn bWVudHMNCiZndDsgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHJldHJhbnNtaXR0ZWQsIGN3bmQg TVVTVCBiZSBzZXQgdG8gbm8gbGVzcyB0aGFuDQomZ3Q7IHNzdGhyZXNoIGFuZCBjb25nZXN0 aW9uIGF2b2lkYW5jZSBNVVNUIGJlIHVzZWQgdG8gZnVydGhlciBpbmNyZWFzZQ0KJmd0OyBj d25kLg0KJmd0Ow0KJmd0OyBOb3Rlcw0KJmd0OyAtLS0tLQ0KJmd0OyBpZiBzZXQgY3duZCBu byBtb3JlIHRoYW4gc3N0aHJlc2gsIGl0IHdpbGwgdXNpbmcgc2xvdyBzdGFydA0KJmd0OyBh bGdvcml0aG0gaW5zdGVhZCBvZiBjb25nZXN0aW9uIGF2b2lkYW5jZSBhbGdvcml0aG0uIHNv IGl0IHNob3VsZA0KJmd0OyBzYXkgImN3bmQgbm8gbGVzcyB0aGFuIC4uLiIgaW5zdGVhZCBv ZiAiY3duZCBubyBtb3JlIHRoYW4gLi4uIi4NCg0KVGhpcyBpcyBpbmNvcnJlY3QgYW5kIHRo ZSBlcnJhdGEgc2hvdWxkIGJlIHJlamVjdGVkLg0KDQpUaGUgd29yZGluZyBpc24ndCBwYXJ0 aWN1bGFybHkgZ3JlYXQsIGJ1dCB0aGUgaWRlYSBpcyB0aGF0IGF0IHRoZQ0KZW5kIG9mIHRo ZSBsb3NzIHBlcmlvZCB3ZSB3YW50IGN3bmQgdG8gYmUgaGFsZiBvZiB0aGUgb3V0c3RhbmRp bmcNCmRhdGEgd2hlbiB3ZSBmaXJzdCBkZXRlY3RlZCBsb3NzLiZuYnNwOyBBbmQsIGluIHBh cnRpY3VsYXIsIHdlDQoqKmNlcnRhaW5seSBkbyBub3Qgd2FudCoqIGN3bmQgdG8gYmUgTEFS R0VSIHRoYW4gaGFsZiB0aGUNCm91dHN0YW5kaW5nIGRhdGEgd2hlbiBsb3NzIG9jY3VycmVk LiZuYnNwOyBBbmQsIGJ5IHNheWluZyAiY3duZCBNVVNUIGJlDQpubyAqKkxFU1MqKiIgd2Ug YXJlIHNwZWNpZnlpbmcgdGhhdCBpdCBtdXN0IGJlIGxhcmdlci10aGFuLWhhbGYuDQpTbywg dGhpcyBsYW5ndWFnZSBpcyBhIGNsZWFybHkgYm90aCAoYSkgYSBub24tZWRpdG9yaWFsIGFs Z29yaXRobQ0KY2hhbmdlIGFuZCAoYikgd3JvbmcuDQoNClRoZSB3b3JkaW5nIGxlYWRzIHRv IHRoZSBjb25mdXNpb24sIGhvd2V2ZXIsIEkgdGhpbmsuJm5ic3A7IElmIG9uZSB3ZXJlDQp0 byBzZXQgY3duZCB0byBsZXNzIHRoYW4gc3N0aHJlc2ggKGhlbmNlIGJlaW5nIG1vcmUgY29u c2VydmF0aXZlKQ0KdGhlbiB3ZSdkIHByb2JhYmx5IHNsb3cgc3RhcnQgdG8gc3N0aHJlc2gg YmVmb3JlIGVudGVyaW5nIGNvbmdlc3Rpb24NCmF2b2lkYW5jZSwgYXMgdGhlIHByb3Bvc2Vk IGVycmF0YSBub3Rlcy4NCg0KSWYgSSB3ZXJlIHRvIGRvIGFueXRoaW5nIGhlcmUgSSB0aGlu ayBJJ2Qgc3RyaWtlICJhbmQgY29uZ2VzdGlvbg0KYXZvaWRhbmNlIE1VU1QgYmUgdXNlZCB0 byBmdXJ0aGVyIGluY3JlYXNlIGN3bmQiIGZyb20gdGhlIGVuZCBvZiB0aGUNCnNlbnRlbmNl LiZuYnNwOyBJLmUuLCBqdXN0IGxldCB3aGF0IG5hdHVyYWxseSBoYXBwZW5zIGhhcHBlbi4m bmJzcDsgQnV0LCB0aGUNCmN1cnJlbnQgdGV4dCBpcyBjb25zZXJ2YXRpdmUuJm5ic3A7IEFu ZCwgaXQgbWF5IHdlbGwgYmUgdGhhdCB3ZSBhY3R1YWxseQ0KbWVhbnQgdG8gdXNlIENBIGlu IHRoaXMgY2FzZSBldmVuIGlmIGN3bmQgPCBzc3RocmVzaCBmb3Igc29tZSByZWFzb24NCkkg YW0gbWlzLXJlbWVtYmVyaW5nLiZuYnNwOyBTbywgSSdkIHdhbnQgdG8gcGFnZSBhbGwgdGhh dCBiYWNrIGluIGJlZm9yZQ0KYWdyZWVpbmcgd2l0aCBhbnkgZXJyYXRhLiZuYnNwOyBJIGFt IG5vdCBzdXJlIGl0J3MgcmVhbGx5IHRoYXQgYmlnIG9mIGENCnByb2JsZW0gdG8gd29ycnkg YWJvdXQuDQoNCmFsbG1hbg== ------=_NextPart_5F16C494_1633CD28_45C45F21 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGRpdj48Zm9udD5IaSBNYXJrLDwvZm9udD48L2Rpdj48ZGl2Pjxmb250Pjxicj48L2ZvbnQ+ PC9kaXY+PGRpdj48Zm9udD4mbmJzcDsgJm5ic3A7VGhhbmtzIGZvciB5b3VyIGNsYXJpZmlj YXRpb24uIEkgZ290IHVuZGVyc3RhbmQgdGhhdCB0aGUgY3duZCBzaG91bGQgYmUgc2V0IHRv IG5vIG1vcmUgdGhhbiBzc3RocmVzaC48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udD48YnI+PC9m b250PjwvZGl2PjxkaXY+Jmd0OyZndDtBbmQsIGl0IG1heSB3ZWxsIGJlIHRoYXQgd2UgYWN0 dWFsbHkgbWVhbnQgdG8gdXNlIENBIGluIHRoaXMgY2FzZSBldmVuIGlmIGN3bmQgJmx0OyBz c3RocmVzaCBmb3Igc29tZSByZWFzb24gSSBhbSBtaXMtcmVtZW1iZXJpbmcuJm5ic3A7PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48Zm9udD4mbmJzcDsgJm5ic3A7YnV0IGNhbiB5b3Ug a2luZGx5IGNsYXJpZnkgdGhhdCBhIHNjZW5hcmlvIFRDUCBuZWVkIGdldCBmb2xsb3dpbmcg Q0EgcnVsZXMgd2hlbiBjd25kICZsdDsgc3N0aHJlc2ggPyZuYnNwOyBpZiB0aGVyZSBpcyBh IHN1Y2ggc2NlbmFyaW8sIGl0IG1lYW5zIFRDUCBjYW5ub3Qgb25seSBmb2xsb3dpbmcgcnVs ZXMgb2YgQ0Egb3IgU1MgPC9mb250PmFjY29yZGluZyB0byB2YWx1ZXMgb2YgY3duZCBhbmQg c3N0aHJlc2ggYnV0IHN0YXRlIGZsYWdzIHNvbWV0aGluZyBsaWtlIFNTIHN0YXRlIGFuZCBD QSBzdGF0ZS48L2Rpdj48ZGl2Pjxmb250Pjxicj48L2ZvbnQ+PC9kaXY+PGRpdj48Zm9udD5C ZXN0IHdpc2hlczwvZm9udD48L2Rpdj48ZGl2Pjxmb250PmNoYXJsZXM8L2ZvbnQ+PC9kaXY+ PGRpdj48aW5jbHVkZXRhaWw+PGRpdj4mbmJzcDs8L2Rpdj48ZGl2IHN0eWxlPSJmb250OlZl cmRhbmEgbm9ybWFsIDE0cHg7Y29sb3I6IzAwMDsiPjxkaXYgc3R5bGU9IkZPTlQtU0laRTog MTJweDtGT05ULUZBTUlMWTogQXJpYWwgTmFycm93O3BhZGRpbmc6MnB4IDAgMnB4IDA7Ij4t LS0tLS0tLS0tLS0tLS0tLS0mbmJzcDtPcmlnaW5hbCZuYnNwOy0tLS0tLS0tLS0tLS0tLS0t LTwvZGl2PjxkaXYgc3R5bGU9IkZPTlQtU0laRTogMTJweDtiYWNrZ3JvdW5kOiNlZmVmZWY7 cGFkZGluZzo4cHg7Ij48ZGl2IGlkPSJtZW51X3NlbmRlciI+PGI+RnJvbTogPC9iPiZuYnNw OyJNYXJrIEFsbG1hbiImbHQ7bWFsbG1hbkBpY2lyLm9yZyZndDs7PC9kaXY+PGRpdj48Yj5E YXRlOiA8L2I+Jm5ic3A7TW9uLCBKdWwgMjAsIDIwMjAgMTE6MDggUE08L2Rpdj48ZGl2Pjxi PlRvOiA8L2I+Jm5ic3A7IlJGQyBFcnJhdGEgU3lzdGVtIiZsdDtyZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnJmd0OzsgPHdicj48L2Rpdj48ZGl2PjxiPkNjOiA8L2I+Jm5ic3A7InZlcm4i Jmx0O3Zlcm5AaWNpci5vcmcmZ3Q7OyAiZWJsYW50b24iJmx0O2VibGFudG9uQGNzLnB1cmR1 ZS5lZHUmZ3Q7OyAibWFydGluLmguZHVrZSImbHQ7bWFydGluLmguZHVrZUBnbWFpbC5jb20m Z3Q7OyAibWFnbnVzLndlc3Rlcmx1bmQiJmx0O21hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29u LmNvbSZndDs7ICJtaWNoYWVsLnNjaGFyZiImbHQ7bWljaGFlbC5zY2hhcmZAaHMtZXNzbGlu Z2VuLmRlJmd0OzsgInR1ZXhlbiImbHQ7dHVleGVuQGZoLW11ZW5zdGVyLmRlJmd0OzsgIm5z ZC5pZXRmIiZsdDtuc2QuaWV0ZkBnbWFpbC5jb20mZ3Q7OyAiY2RlbmciJmx0O2NkZW5nQGdy ZWF0YmVhbS5uZXQmZ3Q7OyAidGNwbSImbHQ7dGNwbUBpZXRmLm9yZyZndDs7ICJFdGhhbiBC bGFudG9uIiZsdDtlbGJAcHNnLmNvbSZndDs7IDx3YnI+PC9kaXY+PGRpdj48Yj5TdWJqZWN0 OiA8L2I+Jm5ic3A7UmU6IFtFZGl0b3JpYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM1NjgxICg2 MjMzKTwvZGl2PjwvZGl2PjxkaXY+Jm5ic3A7PC9kaXY+PGRpdiBzdHlsZT0icG9zaXRpb246 cmVsYXRpdmU7Ij48ZGl2IGlkPSJ0bXBjb250ZW50X3JlcyI+PC9kaXY+PGJyPiZndDsgVGhl IGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDNTY4 MSw8YnI+Jmd0OyAiVENQIENvbmdlc3Rpb24gQ29udHJvbCIuPGJyPiZndDs8YnI+Jmd0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4mZ3Q7IFR5cGU6IEVk aXRvcmlhbDxicj4mZ3Q7IFJlcG9ydGVkIGJ5OiBDaGFybGVzIERlbmcgJmx0O2NkZW5nQGdy ZWF0YmVhbS5uZXQmZ3Q7PGJyPjxicj5UaGlzIGlzIG5vdCBlZGl0b3JpYWwgYXMgaXQgd291 bGQgY2hhbmdlIHRoZSBhbGxvd2VkIG9wZXJhdGlvbiBvZjxicj50aGUgYWxnb3JpdGhtcy48 YnI+PGJyPiZndDsgU2VjdGlvbjogNC4zPGJyPiZndDs8YnI+Jmd0OyBPcmlnaW5hbCBUZXh0 PGJyPiZndDsgLS0tLS0tLS0tLS0tLTxicj4mZ3Q7IEZpbmFsbHksIGFmdGVyIGFsbCBsb3Nz IGluIHRoZSBnaXZlbiB3aW5kb3cgb2Ygc2VnbWVudHM8YnI+Jmd0OyBoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgcmV0cmFuc21pdHRlZCwgY3duZCBNVVNUIGJlIHNldCB0byBubyBtb3JlIHRo YW48YnI+Jmd0OyBzc3RocmVzaCBhbmQgY29uZ2VzdGlvbiBhdm9pZGFuY2UgTVVTVCBiZSB1 c2VkIHRvIGZ1cnRoZXIgaW5jcmVhc2U8YnI+Jmd0OyBjd25kLjxicj4mZ3Q7PGJyPiZndDsg Q29ycmVjdGVkIFRleHQ8YnI+Jmd0OyAtLS0tLS0tLS0tLS0tLTxicj4mZ3Q7IEZpbmFsbHks IGFmdGVyIGFsbCBsb3NzIGluIHRoZSBnaXZlbiB3aW5kb3cgb2Ygc2VnbWVudHM8YnI+Jmd0 OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgcmV0cmFuc21pdHRlZCwgY3duZCBNVVNUIGJlIHNl dCB0byBubyBsZXNzIHRoYW48YnI+Jmd0OyBzc3RocmVzaCBhbmQgY29uZ2VzdGlvbiBhdm9p ZGFuY2UgTVVTVCBiZSB1c2VkIHRvIGZ1cnRoZXIgaW5jcmVhc2U8YnI+Jmd0OyBjd25kLjxi cj4mZ3Q7PGJyPiZndDsgTm90ZXM8YnI+Jmd0OyAtLS0tLTxicj4mZ3Q7IGlmIHNldCBjd25k IG5vIG1vcmUgdGhhbiBzc3RocmVzaCwgaXQgd2lsbCB1c2luZyBzbG93IHN0YXJ0PGJyPiZn dDsgYWxnb3JpdGhtIGluc3RlYWQgb2YgY29uZ2VzdGlvbiBhdm9pZGFuY2UgYWxnb3JpdGht LiBzbyBpdCBzaG91bGQ8YnI+Jmd0OyBzYXkgImN3bmQgbm8gbGVzcyB0aGFuIC4uLiIgaW5z dGVhZCBvZiAiY3duZCBubyBtb3JlIHRoYW4gLi4uIi48YnI+PGJyPlRoaXMgaXMgaW5jb3Jy ZWN0IGFuZCB0aGUgZXJyYXRhIHNob3VsZCBiZSByZWplY3RlZC48YnI+PGJyPlRoZSB3b3Jk aW5nIGlzbid0IHBhcnRpY3VsYXJseSBncmVhdCwgYnV0IHRoZSBpZGVhIGlzIHRoYXQgYXQg dGhlPGJyPmVuZCBvZiB0aGUgbG9zcyBwZXJpb2Qgd2Ugd2FudCBjd25kIHRvIGJlIGhhbGYg b2YgdGhlIG91dHN0YW5kaW5nPGJyPmRhdGEgd2hlbiB3ZSBmaXJzdCBkZXRlY3RlZCBsb3Nz LiZuYnNwOyBBbmQsIGluIHBhcnRpY3VsYXIsIHdlPGJyPioqY2VydGFpbmx5IGRvIG5vdCB3 YW50KiogY3duZCB0byBiZSBMQVJHRVIgdGhhbiBoYWxmIHRoZTxicj5vdXRzdGFuZGluZyBk YXRhIHdoZW4gbG9zcyBvY2N1cnJlZC4mbmJzcDsgQW5kLCBieSBzYXlpbmcgImN3bmQgTVVT VCBiZTxicj5ubyAqKkxFU1MqKiIgd2UgYXJlIHNwZWNpZnlpbmcgdGhhdCBpdCBtdXN0IGJl IGxhcmdlci10aGFuLWhhbGYuPGJyPlNvLCB0aGlzIGxhbmd1YWdlIGlzIGEgY2xlYXJseSBi b3RoIChhKSBhIG5vbi1lZGl0b3JpYWwgYWxnb3JpdGhtPGJyPmNoYW5nZSBhbmQgKGIpIHdy b25nLjxicj48YnI+VGhlIHdvcmRpbmcgbGVhZHMgdG8gdGhlIGNvbmZ1c2lvbiwgaG93ZXZl ciwgSSB0aGluay4mbmJzcDsgSWYgb25lIHdlcmU8YnI+dG8gc2V0IGN3bmQgdG8gbGVzcyB0 aGFuIHNzdGhyZXNoIChoZW5jZSBiZWluZyBtb3JlIGNvbnNlcnZhdGl2ZSk8YnI+dGhlbiB3 ZSdkIHByb2JhYmx5IHNsb3cgc3RhcnQgdG8gc3N0aHJlc2ggYmVmb3JlIGVudGVyaW5nIGNv bmdlc3Rpb248YnI+YXZvaWRhbmNlLCBhcyB0aGUgcHJvcG9zZWQgZXJyYXRhIG5vdGVzLjxi cj48YnI+SWYgSSB3ZXJlIHRvIGRvIGFueXRoaW5nIGhlcmUgSSB0aGluayBJJ2Qgc3RyaWtl ICJhbmQgY29uZ2VzdGlvbjxicj5hdm9pZGFuY2UgTVVTVCBiZSB1c2VkIHRvIGZ1cnRoZXIg aW5jcmVhc2UgY3duZCIgZnJvbSB0aGUgZW5kIG9mIHRoZTxicj5zZW50ZW5jZS4mbmJzcDsg SS5lLiwganVzdCBsZXQgd2hhdCBuYXR1cmFsbHkgaGFwcGVucyBoYXBwZW4uJm5ic3A7IEJ1 dCwgdGhlPGJyPmN1cnJlbnQgdGV4dCBpcyBjb25zZXJ2YXRpdmUuJm5ic3A7IEFuZCwgaXQg bWF5IHdlbGwgYmUgdGhhdCB3ZSBhY3R1YWxseTxicj5tZWFudCB0byB1c2UgQ0EgaW4gdGhp cyBjYXNlIGV2ZW4gaWYgY3duZCAmbHQ7IHNzdGhyZXNoIGZvciBzb21lIHJlYXNvbjxicj5J IGFtIG1pcy1yZW1lbWJlcmluZy4mbmJzcDsgU28sIEknZCB3YW50IHRvIHBhZ2UgYWxsIHRo YXQgYmFjayBpbiBiZWZvcmU8YnI+YWdyZWVpbmcgd2l0aCBhbnkgZXJyYXRhLiZuYnNwOyBJ IGFtIG5vdCBzdXJlIGl0J3MgcmVhbGx5IHRoYXQgYmlnIG9mIGE8YnI+cHJvYmxlbSB0byB3 b3JyeSBhYm91dC48YnI+PGJyPmFsbG1hbjxicj48YnI+PC9kaXY+PC9kaXY+PCEtLTwhW2Vu ZGlmXS0tPjwvaW5jbHVkZXRhaWw+PC9kaXY+ ------=_NextPart_5F16C494_1633CD28_45C45F21-- From nobody Wed Jul 22 15:21:26 2020 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 659363A083C; Wed, 22 Jul 2020 15:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz_8p7bO8DzB; Wed, 22 Jul 2020 15:21:23 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D71F3A083D; Wed, 22 Jul 2020 15:21:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 274EF25A14; Thu, 23 Jul 2020 00:21:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1595456482; bh=o/jMk0NhJu0GACeW0N0szg0Ao2h7Cjh/n02UJ7x1BQY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=lQGjcFPfxsVLn/uiIkzeyC3gKkm1gZGVIn2W8y64+V82U82p+JRC+qexSmh6mF4CQ V9lUI2re+n2SnDHNrzMy41DjPV3enlu7OAXOhBUh8FjrF5Zs51BT1tLDy3Z8biokT9 2YxV33ar/xgnfvpw7dNshtcKoRvstwgFgegimfVg= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npTkda0bPyAG; Thu, 23 Jul 2020 00:21:20 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 23 Jul 2020 00:21:20 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Thu, 23 Jul 2020 00:21:19 +0200 From: "Scharf, Michael" To: Juhamatti Kuusisaari , "tcpm-chairs@ietf.org" CC: Joseph Touch , tcpm IETF list Thread-Topic: [tcpm] Presentation slot requests for IETF 108 (online) Thread-Index: AdZQQCmoc741dfI0S+mziKOl37MyoQIlXLKAAcgnLwAAH/vS4A== Date: Wed, 22 Jul 2020 22:21:19 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DCC403E@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2DCC403Erznt8114rzntrzd_" MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) 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, 22 Jul 2020 22:21:25 -0000 --_000_6EC6417807D9754DA64F3087E2E2E03E2DCC403Erznt8114rzntrzd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSnVoYW1hdHRpLA0KDQpUaGlzIGlzIGEgbGF0ZSByZXF1ZXN0Lg0KDQpCdXQgYXMgd2UgbWF5 IGhhdmUgc29tZSB0aW1lIGxlZnQsIEnigJlsbCBwdXQgeW91IHRhbGsgYXQgdGhlIGVuZCBvZiB0 aGUgYWdlbmRhICjigJxpZiB0aW1lIHBlcm1pdHPigJ0pLg0KDQpNaWNoYWVsDQoNCkZyb206IEp1 aGFtYXR0aSBLdXVzaXNhYXJpIDxqdWhhbWF0a0BnbWFpbC5jb20+DQpTZW50OiBXZWRuZXNkYXks IEp1bHkgMjIsIDIwMjAgMTE6MDQgQU0NClRvOiB0Y3BtLWNoYWlyc0BpZXRmLm9yZw0KQ2M6IEpv c2VwaCBUb3VjaCA8dG91Y2hAc3RyYXlhbHBoYS5jb20+OyB0Y3BtIElFVEYgbGlzdCA8dGNwbUBp ZXRmLm9yZz4NClN1YmplY3Q6IFt0Y3BtXSBQcmVzZW50YXRpb24gc2xvdCByZXF1ZXN0cyBmb3Ig SUVURiAxMDggKG9ubGluZSkNCg0KDQpEZWFyIGNoYWlycywNCg0KV2Ugd291bGQgbGlrZSB0byBy ZXF1ZXN0IGEgcHJlc2VudGF0aW9uIHNsb3QgZm9yIElFVEYgMTA4Lg0KDQpQbGVhc2UgZmluZCBu ZXh0IHRoZSBkZXRhaWxzIG9mIHRoZSByZXF1ZXN0Og0KDQoqIERyYWZ0IG5hbWUgLyBwcmVzZW50 YXRpb24gdGl0bGU6IGRyYWZ0LXRvdWNoLXRjcG0tYW8tdGVzdC12ZWN0b3JzLTAwDQoqIFByZXNl bnRlcjogICAgICAgICAgICAgICAgICAgICAgICBKdWhhbWF0dGkgS3V1c2lzYWFyaQ0KKiBUb3Rh bCBkdXJhdGlvbiAoaW5jbHVkaW5nIFEmQSk6ICAgMTUgbWludXRlcw0KDQpUaGFua3MsDQoNCkp1 aGFtYXR0aQ0KDQoNCj4gSGkgYWxsLA0KPg0KPiBHaXZlbiB0aGF0IHdlIGhhZCBhIHByZXR0eSBw YWNrZWQgYWdlbmRhIGR1cmluZyB0aGUgdmlydHVhbCBpbnRlcmltDQo+IG1lZXRpbmcsIHRoZSBj aGFpcnMgaGF2ZSBhc2tlZCBmb3IgdHdvIHNsb3RzIGR1cmluZyBJRVRGIDEwOC4gVGhpcw0KPiBi YXNpY2FsbHkgaW1wbGllcyB0aGF0IHdlIGhhdmUgYWdhaW4gdGhlIDI6MzAgaG91ciBzbG90IHRo YXQgVENQTSB1c2VkIHRvDQo+IGhhdmUgZm9yIG1hbnkgeWVhcnMuDQo+DQo+IEFjY29yZGluZyB0 byB0aGUgZHJhZnQgYWdlbmRhIGZvciBJRVRGIDEwOCwgVENQTSBoYXMgYmVlbiBzY2hlZHVsZWQg Zm9yDQo+IE1vbmRheSBTZXNzaW9uIEkgKDE6NDApIGFuZCBNb25kYXkgU2Vzc2lvbiBJSSAoMDo1 MCkuDQo+DQo+IElmIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBwcmVzZW50aW5nLCBwbGVhc2UgbGV0 IHRoZSBjaGFpcnMga25vdyB1bnRpbA0KPiAqKk1vbmRheSAyMDIwLTA3LTEzKio6DQo+DQo+ICog RHJhZnQgbmFtZSAvIHByZXNlbnRhdGlvbiB0aXRsZQ0KPiAqIFByZXNlbnRlcg0KPiAqIFRvdGFs IGR1cmF0aW9uIChpbmNsdWRpbmcgUSZBKQ0KPg0KPiBUaGFua3MNCj4NCj4gTWljaGFlbCAoMngp IGFuZCBZb3NoaQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiB0Y3BtIG1haWxpbmcgbGlzdA0KPiB0Y3BtQGlldGYub3JnPG1haWx0bzp0Y3Bt QGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0N Cg== --_000_6EC6417807D9754DA64F3087E2E2E03E2DCC403Erznt8114rzntrzd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2 b3JsYWdlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAy LjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgPC9zcGFuPkp1aGFtYXR0aSw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgaXMgYSBsYXRlIHJl cXVlc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CdXQgYXMgd2UgbWF5IGhhdmUgc29tZSB0aW1lIGxl ZnQsIEnigJlsbCBwdXQgeW91IHRhbGsgYXQgdGhlIGVuZCBvZiB0aGUgYWdlbmRhICjigJxpZiB0 aW1lIHBlcm1pdHPigJ0pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWljaGFlbDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEp1aGFtYXR0aSBLdXVzaXNhYXJp ICZsdDtqdWhhbWF0a0BnbWFpbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEp1bHkgMjIsIDIwMjAgMTE6MDQgQU08YnI+DQo8Yj5Ubzo8L2I+IHRjcG0tY2hhaXJzQGlldGYu b3JnPGJyPg0KPGI+Q2M6PC9iPiBKb3NlcGggVG91Y2ggJmx0O3RvdWNoQHN0cmF5YWxwaGEuY29t Jmd0OzsgdGNwbSBJRVRGIGxpc3QgJmx0O3RjcG1AaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFt0Y3BtXSBQcmVzZW50YXRpb24gc2xvdCByZXF1ZXN0cyBmb3IgSUVURiAxMDggKG9u bGluZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5EZWFyIGNoYWlycyw8YnI+DQo8YnI+DQpXZSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgYSBw cmVzZW50YXRpb24gc2xvdCBmb3IgSUVURiAxMDguPGJyPg0KPGJyPg0KUGxlYXNlIGZpbmQgbmV4 dCB0aGUgZGV0YWlscyBvZiB0aGUgcmVxdWVzdDo8YnI+DQo8YnI+DQoqIERyYWZ0IG5hbWUgLyBw cmVzZW50YXRpb24gdGl0bGU6IGRyYWZ0LXRvdWNoLXRjcG0tYW8tdGVzdC12ZWN0b3JzLTAwPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIFByZXNl bnRlcjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBKdWhhbWF0dGkgS3V1c2lzYWFyaTxicj4N CiogVG90YWwgZHVyYXRpb24gKGluY2x1ZGluZyBRJmFtcDtBKTombmJzcDsgJm5ic3A7MTUgbWlu dXRlczxicj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpKdWhhbWF0dGk8YnI+DQo8YnI+DQo8 YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBHaXZlbiB0aGF0IHdlIGhhZCBh IHByZXR0eSBwYWNrZWQgYWdlbmRhIGR1cmluZyB0aGUgdmlydHVhbCBpbnRlcmltPGJyPg0KJmd0 OyBtZWV0aW5nLCB0aGUgY2hhaXJzIGhhdmUgYXNrZWQgZm9yIHR3byBzbG90cyBkdXJpbmcgSUVU RiAxMDguIFRoaXM8YnI+DQomZ3Q7IGJhc2ljYWxseSBpbXBsaWVzIHRoYXQgd2UgaGF2ZSBhZ2Fp biB0aGUgMjozMCBob3VyIHNsb3QgdGhhdCBUQ1BNIHVzZWQgdG88YnI+DQomZ3Q7IGhhdmUgZm9y IG1hbnkgeWVhcnMuPGJyPg0KJmd0Ozxicj4NCiZndDsgQWNjb3JkaW5nIHRvIHRoZSBkcmFmdCBh Z2VuZGEgZm9yIElFVEYgMTA4LCBUQ1BNIGhhcyBiZWVuIHNjaGVkdWxlZCBmb3I8YnI+DQomZ3Q7 IE1vbmRheSBTZXNzaW9uIEkgKDE6NDApIGFuZCBNb25kYXkgU2Vzc2lvbiBJSSAoMDo1MCkuPGJy Pg0KJmd0Ozxicj4NCiZndDsgSWYgeW91IGFyZSBpbnRlcmVzdGVkIGluIHByZXNlbnRpbmcsIHBs ZWFzZSBsZXQgdGhlIGNoYWlycyBrbm93IHVudGlsPGJyPg0KJmd0OyAqKk1vbmRheSAyMDIwLTA3 LTEzKio6PGJyPg0KJmd0Ozxicj4NCiZndDsgKiBEcmFmdCBuYW1lIC8gcHJlc2VudGF0aW9uIHRp dGxlPGJyPg0KJmd0OyAqIFByZXNlbnRlcjxicj4NCiZndDsgKiBUb3RhbCBkdXJhdGlvbiAoaW5j bHVkaW5nIFEmYW1wO0EpPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzPGJyPg0KJmd0Ozxicj4N CiZndDsgTWljaGFlbCAoMngpIGFuZCBZb3NoaTxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyB0Y3BtIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnRjcG1AaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj50Y3BtQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6EC6417807D9754DA64F3087E2E2E03E2DCC403Erznt8114rzntrzd_-- From nobody Wed Jul 22 19:00:58 2020 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 885E63A0B26 for ; Wed, 22 Jul 2020 19:00:57 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhKSOPUADSm2 for ; Wed, 22 Jul 2020 19:00:56 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 C1E453A0B23 for ; Wed, 22 Jul 2020 19:00:55 -0700 (PDT) Received: from lhreml732-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4FD19C581BA8D79C568B; Thu, 23 Jul 2020 03:00:54 +0100 (IST) Received: from lhreml732-chm.china.huawei.com (10.201.108.83) by lhreml732-chm.china.huawei.com (10.201.108.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 23 Jul 2020 03:00:54 +0100 Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml732-chm.china.huawei.com (10.201.108.83) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 23 Jul 2020 03:00:53 +0100 Received: from DGGEMM534-MBS.china.huawei.com ([169.254.7.122]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0487.000; Thu, 23 Jul 2020 10:00:41 +0800 From: Kangjiao To: Christoph Paasch , Yoshifumi Nishida , "tcpm@ietf.org Extensions" CC: Liangqiandeng Thread-Topic: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 Thread-Index: AQHWXb+HJHOpbU0oSkKL2jMMYvRPV6kP1fbAgAHYVoCAAryHoA== Date: Thu, 23 Jul 2020 02:00:41 +0000 Message-ID: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9A9BC@dggemm534-mbs.china.huawei.com> References: <719A2C1D4AC73847B6E1BF21DF1545EAE5C97D2C@dggemm534-mbs.china.huawei.com> <20200721155945.GA93692@MacBook-Pro-64.local> In-Reply-To: <20200721155945.GA93692@MacBook-Pro-64.local> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.102.89] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 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, 23 Jul 2020 02:00:58 -0000 SGkgQ2hyaXN0b3BoIGFuZCBZb3NoaSwNCg0KSWYgSSB1bmRlcnN0YW5kIHJpZ2h0LCB5b3UgYm90 aCBwb2ludCB0byB0aGUgc2FtZSBxdWVzdGlvbiB3aGV0aGVyIHJldXNpbmcgdGhlIE1QX1BSSU8g Y2FuIGZpbmlzaCBhY2N1cmF0ZSBkYXRhIHNjaGVkdWxpbmcgZm9yIHNlcnZlci4gSSB0aGluayBN UF9QUklPIG1heSBiZSBub3QgZW5vdWdoIGV2ZW4gaWYgc2V0dGluZyBhbGwgdGhlICJub24tdGFy Z2V0IiBzdWJmbG93cyB0byBiYWNrdXAgb25lcy4gSSBjYW4gZ2l2ZSBhIHNjZW5hcmlvOg0KDQpT aXggc3ViZmxvd3MgaGF2ZSBiZWVuIGVzdGFibGlzaGVkIGJldHdlZW4gY2xpZW50IGFuZCBzZXJ2 ZXIgdGhhdCBhcmUgPElQX0MxLCBJUF9TMT4sIDxJUF9DMiwgSVBfUzE+LCA8SVBfQzEsIElQX1My PiwgPElQX0MyLCBJUF9TMj4sIDxJUF9DMSwgSVBfUzM+IGFuZCA8SVBfQzIsIElQX1MzPi4gVGhl IGNsaWVudCBoYXMgSVBfQzEgYW5kIElQX0MyLiBUaGUgc2VydmVyIGhhcyBJUF9TMSwgSVBfUzIg YW5kIElQX1MzLg0KDQpTZXJ2ZXIgdG9vbCBkZXRlY3RzIHRoYXQgS1BJIG9mIElQX1MyIGlzIGJl dHRlciBub3cgc28gdGhlIHNlcnZlciB3YW50cyB0byBzd2l0Y2ggZGF0YSB0cmFmZmljIGZyb20g PElQX0MxLCBJUF9TMT4gdG8gdGhlIGRlc3RpbmF0aW9uIElQX1MyLiBJZiB3ZSBzZXQgPElQX0Mx LCBJUF9TMT4gYXMgImJhY2t1cCIsIGl0IGlzIG5vdCBndWFyYW50ZWVkIHRoYXQgYWxsIHRoZSBs b2FkIG92ZXIgPElQX0MxLCBJUF9TMT4gY2FuIGJlIGRpdmVydGVkIHRvIElQX1MyIGJlY2F1c2Ug b2YgdGhlIG9uZ29pbmcgc3VmbG93cyB0b3dhcmRzIElQX1MzLg0KDQpTbyBJIHRoaW5rIE1QX1BS SU8gY2FuIHJlZHVjZSB0aGUgY2hhbmNlIG9mIGRhdGEgdHJhbnNtaXNzaW9uIG9uIGEgc3BlY2lm aWMgc3ViZmxvdyBidXQgaXQgY2Fubm90IGNvbnZleSB0aGUgaW5mbyBvZiB0YXJnZXQgbmV0d29y ayBpbnRlcmZhY2UgZnJvbSBzZXJ2ZXIgdG8gY2xpZW50Lg0KDQpUaGFua3MNCkppYW8NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENocmlzdG9waCBQYWFzY2ggW21haWx0bzpj cGFhc2NoQGFwcGxlLmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjIsIDIwMjAgMTI6MDAg QU0NClRvOiBLYW5namlhbyA8a2FuZ2ppYW9AaHVhd2VpLmNvbT4NCkNjOiBZb3NoaWZ1bWkgTmlz aGlkYSA8bnNkLmlldGZAZ21haWwuY29tPjsgdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zIDx0Y3Bt QGlldGYub3JnPjsgTGlhbmdxaWFuZGVuZyA8bGlhbmdxaWFuZGVuZ0BodWF3ZWkuY29tPg0KU3Vi amVjdDogUmU6IFt0Y3BtXSBjb21tZW50cyBvbiBkcmFmdC1rYW5nLXRjcG0tYWNjdXJhdGUtZGF0 YS1zY2hlZHVsaW5nLWJ5LXNlcnZlci0wMA0KDQpIZWxsbywNCg0KYXMgYW4gb3ZlcmFsbCBjb21t ZW50LCBJIGFncmVlIHRoYXQgb25lIG9mIHRoZSBkaWZmaWN1bHRpZXMgYXJvdW5kIG11bHRpcGF0 aCBpcyBob3cgdGhlIGhvc3RzIGNhbiBjb21tdW5pY2F0ZSB0byB0aGUgcGVlcnMgdGhlIGRlc2ly ZWQgc2NoZWR1bGluZyBtZWNoYW5pc21zLiBDdXJyZW50bHkgdGhlcmUgaXMgbm8gcmVsaWFibGUg d2F5IGJlc2lkZXMgYmFja3VwLWJpdHMgd2hpY2ggaXMgYSAiaGFyZCIgc3dpdGNoLiBIb3dldmVy LCBvZnRlbiBzY2hlZHVsaW5nIGlzIG11Y2ggbW9yZSBmaW5lLWdyYWluZWQgYXMgc2hvd24gaW4g YSBudW1iZXIgb2YgdGhlIHNjaGVkdWxlcnMgZGVzY3JpYmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1ib25hdmVudHVyZS1pY2NyZy1zY2hlZHVsZXJzLTAwLg0KDQpJdCdz IGEgYml0IHNpbWlsYXIgdG8gVENQIHdoaWNoIGNhbid0IHBpY2sgdGhlIHBlZXIncyBjb25nZXN0 aW9uLWNvbnRyb2wgYW5kIGZvciBleGFtcGxlIGlmIG9uZSB3YW50cyB0aGUgcGVlciB0byB1c2Ug YSBiYWNrZ3JvdW5kLUNDIHRoZSBob3N0IG5lZWRzIHRvIHJlc29ydCB0byB0dW5pbmcgdGhlIHJl Y2VpdmUtd2luZG93IGEgbGEgZHJhZnQtYmFnbnVsby1pY2NyZy1ybGVkYmF0LTAwLg0KDQpTbywg aGF2aW5nIGEgd2F5IHRvIGNvbW11bmljYXRlIHRoZSBzY2hlZHVsaW5nICJyZXF1aXJlbWVudHMi IHRvIHRoZSBwZWVyIChhbmQgbGV0IHRoZSBwZWVyIG1hdGNoIHRoZXNlIHJlcXVpcmVtZW50cyB3 aXRoIGl0cyBsb2NhbCBwb2xpY2llcyksIHdvdWxkIGJlIGdvb2QhDQoNCg0KT25lIG1vcmUgY29t bWVudCBpbmxpbmU6DQoNCk9uIDA3LzIwLzIwIC0gMDM6NTQsIEthbmdqaWFvIHdyb3RlOg0KPiBI aSBZb3NoaSwNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBzdWdnZXN0aW9ucy4gV2UgY2xhcmlmeSB0 aGUgaXNzdWVzIGFzIGJlbG93Og0KPiANCj4gMTogT25lIHRoaW5nIEknbSBub3QgdmVyeSBjbGVh ciBpcyB3aHkgd2UgY2Fubm90IHVzZSBNUF9QUklPIGZvciB0aGUgDQo+IHVzZSBjYXNlcyBkZXNj cmliZWQgaW4gdGhlIGRyYWZ0LiBJIGJlbGlldmUgdGhlIGRyYWZ0IHNob3VsZCBkZXNjcmliZSAN Cj4gdGhlIGNhc2VzIHdoZXJlIGV4aXN0aW5nIGZlYXR1cmVzIGNhbm5vdCBmdWxmaWxsIHRoZSBy ZXF1aXJlbWVudHMgbW9yZSANCj4gc3BlY2lmaWNhbGx5Lg0KPiANCj4gS0o6IFRoZSBuZXcgTVBf TmF2aWdhdGlvbiBPcHRpb24gaXMgdXNlZCBmb3IgdGhlIHNlcnZlciB0byBpbmRpY2F0ZSANCj4g ZGVzdGluYXRpb24gbmV0d29yayBpbnRlcmZhY2UgdG8gY2xpZW50IGZvciB3aGljaCBzZXJ2ZXIg d2FudHMgdG8gdXNlIA0KPiBmb3IgdHJhZmZpYyBzd2l0Y2hpbmcuIEZvciBteSB1bmRlcnN0YW5k aW5nLCBNUF9QUklPIGlzIHVzZWQgdG8gc2lnbmFsIA0KPiBhIGNoYW5nZSBpbiBwcmlvcml0eSBv ZiBzdWJmbG93cyB0byB0aGUgcGVlci4gSW4gYXBwbGljYXRpb24sIE1QX1BSSU8gDQo+IGNhbiBy ZWR1Y2UgdGhlIGNoYW5jZSBvZiBkYXRhIHRyYW5zbWlzc2lvbiBvbiBhIHNwZWNpZmljIHN1YmZs b3cgYnV0IA0KPiBpdCBjYW5ub3QgdGVsbCBpdHMgcGVlciB3aGljaCBuZXR3b3JrIGludGVyZmFj ZSBpcyB0aGUgZGVzdGluYXRpb24gZnJvbSBzZXJ2ZXIgc2lkZS4NCj4gRm9yIGV4YW1wbGUsIGlm IHRoZXJlIGFyZSBtdWx0aXBsZSBzdWJmbG93cyB3aXRoIGhpZ2ggcHJpb3JpdHkgZnJvbSANCj4g ZGlmZmVyZW5jZSBuZXR3b3JrIGludGVyZmFjZXMsIGNsaWVudCByZWNlaXZpbmcgTVBfUFJJTyBk b2VzIG5vdCBrbm93IA0KPiB3aGljaCBpcyB0aGUgdGFyZ2V0IG9uZS4NCg0KRm9yIHRoaXMgcGFy dGljdWxhciBzY2VuYXJpbyB0aGUgc2VydmVyIGNvdWxkIHNlbmQgdGhlIE1QX1BSSU8gd2l0aCBi YWNrdXAtYml0IHNldCBvbiBhbGwgc3ViZmxvd3MgdGhhdCB0aGUgY2xpZW50IHNob3VsZCBub3Qg dXNlLiBUaHVzIGltcGxpY2l0bHkgdGhlIGhpZ2gtcHJpb3JpdHkgbmV0d29yay1pbnRlcmZhY2Vz IGNhbiB0aGVuIGJlIHVzZWQgYnkgdGhlIGNsaWVudCwgcmlnaHQ/DQoNCg0KQ2hyaXN0b3BoDQoN Cj4gMjogQ2xpZW50cyBhbHNvIGhhdmUgdGhlaXIgb3duIGNvbnN0cmFpbnRzLiAoZS5nLiBwb2xp Y3kgb3Igcm91dGluZykgDQo+IFNvLCBldmVuIHRob3VnaCBzZXJ2ZXJzIHNlbmQgYSBuYXZpZ2F0 aW9uIHJlcXVlc3QsIHRoZXkgbWlnaHQgbm90IA0KPiBmb2xsb3cgaXQuIEkgdGhpbmsgdGhpcyBw b2ludCBzaG91bGQgYmUgY2xhcmlmaWVkLg0KPiANCj4gS0o6IElmIHRoZSBtZWNoYW5pc20gb2Yg YWNjdXJhdGUtZGF0YS1zY2hlZHVsaW5nLWJ5LXNlcnZlciBpcyANCj4gZGVwbG95ZWQsIHRoZSBw cmluY2lwbGUgaXMgdGhhdCB0aGUgc2VydmVyIHRha2VzIHByZWNlZGVuY2UuDQo+IA0KPiAzOiBX aGF0J3MgdGhlIG1lYW5pbmcgb2YgJ3InLCAnRScsICdCJyBmbGFncyBpbiBTZWN0aW9uIDQuMT8N Cj4gDQo+IEtKOiAgRm9yIHRoZSBwcm90b2NvbCBkZXNpZ24sIHRoZSBkZWZpbml0aW9uIG9mIOKA mXLigJksIOKAmEXigJkgYW5kIOKAmULigJkgYXJlIA0KPiBhcw0KPiBmb2xsb3dpbmc6IEZsYWcg 4oCYcuKAmTogcmVzZXJ2ZWQgZm9yIGZ1dHVyZSB1c2FnZS4gIEZsYWcg4oCYReKAmTogZXhpc3Rz IHRvIA0KPiBwcm92aWRlIHJlbGlhYmlsaXR5IGZvciB0aGlzIG9wdGlvbiAobGlrZSB0aGF0IGlu IOKAnUFERF9BRERS4oCdKS4gIEZsYWcg4oCZQuKAmToNCj4gaW5kaWNhdGVzIHdoZXRoZXIgdGhl IHN1YmZsb3cgb3ZlciB3aGljaCB0aGUgb3B0aW9uIGlzIHJlY2VpdmVkIGlzIGEgDQo+IGJhY2t1 cCBvbmUgKHRoYXQgaXMgY29tcGF0aWFibGUgd2l0aCB0aGUgdmFsdWUgYnkgTVBfUFJJTykuDQo+ IA0KPiBCdXQgd2UgYXJlIHRoaW5raW5nIHdoZXRoZXIgdGhlc2UgZmllbGRzIGFyZSBuZWNlc3Nh cnkgYW5kIHNob3VsZCBiZSANCj4gc2V0IGFzIG1hbmRhdG9yeS4NCj4gDQo+IFNpbmNlcmVseSwg SmlhbyBGcm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgDQo+IFlvc2hpZnVtaSBOaXNoaWRhIFNlbnQ6IFN1bmRheSwgSnVseSAxOSwgMjAyMCA3OjI2 IFBNIFRvOiANCj4gdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zIDx0Y3BtQGlldGYub3JnPiBTdWJq ZWN0OiBbdGNwbV0gY29tbWVudHMgb24NCj4gZHJhZnQta2FuZy10Y3BtLWFjY3VyYXRlLWRhdGEt c2NoZWR1bGluZy1ieS1zZXJ2ZXItMDANCj4gDQo+IEhpLCBJJ3ZlIHJlYWQgZHJhZnQta2FuZy10 Y3BtLWFjY3VyYXRlLWRhdGEtc2NoZWR1bGluZy1ieS1zZXJ2ZXItMDAuICANCj4gSSB0aGluayB0 aGlzIGlzIGFuIGludGVyZXN0aW5nIHRvcGljIGZvciBtcHRjcCwgYnV0IEkgdGhpbmsgaXQgd291 bGQgDQo+IGJlIGJldHRlciB0byBjbGFyaWZ5IHRoZSBmb2xsb3dpbmcgcG9pbnRzLg0KPiANCj4g MTogT25lIHRoaW5nIEknbSBub3QgdmVyeSBjbGVhciBpcyB3aHkgd2UgY2Fubm90IHVzZSBNUF9Q UklPIGZvciB0aGUgDQo+IHVzZSBjYXNlcyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0LiBJIGJlbGll dmUgdGhlIGRyYWZ0IHNob3VsZCBkZXNjcmliZSANCj4gdGhlIGNhc2VzIHdoZXJlIGV4aXN0aW5n IGZlYXR1cmVzIGNhbm5vdCBmdWxmaWxsIHRoZSByZXF1aXJlbWVudHMgbW9yZSANCj4gc3BlY2lm aWNhbGx5Lg0KPiANCj4gMjogQ2xpZW50cyBhbHNvIGhhdmUgdGhlaXIgb3duIGNvbnN0cmFpbnRz LiAoZS5nLiBwb2xpY3kgb3Igcm91dGluZykgDQo+IFNvLCBldmVuIHRob3VnaCBzZXJ2ZXJzIHNl bmQgYSBuYXZpZ2F0aW9uIHJlcXVlc3QsIHRoZXkgbWlnaHQgbm90IA0KPiBmb2xsb3cgaXQuIEkg dGhpbmsgdGhpcyBwb2ludCBzaG91bGQgYmUgY2xhcmlmaWVkLg0KPiANCj4gMzogV2hhdCdzIHRo ZSBtZWFuaW5nIG9mICdyJywgJ0UnLCAnQicgZmxhZ3MgaW4gU2VjdGlvbiA0LjE/DQo+IA0KPiBU aGFua3MsIC0tIFlvc2hpDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gdGNwbSBtYWlsaW5nIGxpc3QNCj4gdGNwbUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RjcG0NCg0K From nobody Wed Jul 22 20:10:52 2020 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 C0DD63A0B9C for ; Wed, 22 Jul 2020 20:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 JVxUGpQI6hnk for ; Wed, 22 Jul 2020 20:10:50 -0700 (PDT) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 0829F3A0B8C for ; Wed, 22 Jul 2020 20:10:49 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 06N33UUU042993; Wed, 22 Jul 2020 20:10:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=kn34dKKJnOtkV22JoJyepsKrCbLGdVbktqkXv2GK6k4=; b=I7rqWsTYBAhGKhyxkPTbN3vsivmzIU/wsJK12gldXlG7KF04T1ld4+dXtKl4OUOrCloF GK25xdPY2nX6EMJi/h9daYZzw8MidXhnM+utN7HGZriG4E9eHRQwkaVvGOUhPVyJyCyM b+wUdJktmVrBul8/ffbgSfN7F/Deyv1XMpaa54JqRWq0eTTMeUgXKw/uGRGNVZjmPGHq 7NLzokBXno6aEeL/V5Q368d22oeB8aYOlGhFJSp38q7M6bapDunvxMKPQPFljHoIOfnY isMJ5BMAD5WCvLma3HhJrJZ93Iw04IIP+s2Nw47Faw2tUFh4S05tgnRRQ4gzkQpOP9uf Bg== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 32byr3f93f-14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 22 Jul 2020 20:10:44 -0700 Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QDW007QDJHVNKE0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 22 Jul 2020 20:10:43 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QDW00U00J09Y600@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Jul 2020 20:10:43 -0700 (PDT) X-Va-A: X-Va-T-CD: 3beaf764f461a8ab0294914a8b578f03 X-Va-E-CD: dbb4aa9d0c53e8100e25dcf92570366e X-Va-R-CD: 8e3f0004dc05f9a4784d4291b529a402 X-Va-CD: 0 X-Va-ID: 02e3ecc4-3272-4483-ba09-92e3a2111c78 X-V-A: X-V-T-CD: 3beaf764f461a8ab0294914a8b578f03 X-V-E-CD: dbb4aa9d0c53e8100e25dcf92570366e X-V-R-CD: 8e3f0004dc05f9a4784d4291b529a402 X-V-CD: 0 X-V-ID: e87e6098-1dbc-4d47-b31a-1a21d4c9dbde X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-22_17:2020-07-22, 2020-07-22 signatures=0 Received: from localhost (unknown [10.104.103.80]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QDW00XEYJHUU300@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Wed, 22 Jul 2020 20:10:43 -0700 (PDT) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable From: Christoph Paasch MIME-version: 1.0 (1.0) Date: Wed, 22 Jul 2020 20:10:41 -0700 Message-id: <213AD4B1-4F88-4389-93CE-242916C06DC8@apple.com> References: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9A9BC@dggemm534-mbs.china.huawei.com> Cc: Yoshifumi Nishida , "tcpm@ietf.org Extensions" , Liangqiandeng In-reply-to: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9A9BC@dggemm534-mbs.china.huawei.com> To: Kangjiao X-Mailer: iPhone Mail (18A336) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-22_17:2020-07-22, 2020-07-22 signatures=0 Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 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, 23 Jul 2020 03:10:52 -0000 Hello, > On Jul 22, 2020, at 7:01 PM, Kangjiao wrote: >=20 > =EF=BB=BFHi Christoph and Yoshi, >=20 > If I understand right, you both point to the same question whether reusing= the MP_PRIO can finish accurate data scheduling for server. I think MP_PRIO= may be not enough even if setting all the "non-target" subflows to backup o= nes. I can give a scenario: >=20 > Six subflows have been established between client and server that are , , , , a= nd . The client has IP_C1 and IP_C2. The server has IP_S1, IP_= S2 and IP_S3. >=20 > Server tool detects that KPI of IP_S2 is better now so the server wants to= switch data traffic from to the destination IP_S2. If we set= as "backup", it is not guaranteed that all the load over can be diverted to IP_S2 because of the ongoing suflows towards I= P_S3. But we could simply also set ans as backup as we= ll, no? Now, all the traffic will be steered towards S2. Christoph >=20 > So I think MP_PRIO can reduce the chance of data transmission on a specifi= c subflow but it cannot convey the info of target network interface from ser= ver to client. >=20 > Thanks > Jiao >=20 > -----Original Message----- > From: Christoph Paasch [mailto:cpaasch@apple.com]=20 > Sent: Wednesday, July 22, 2020 12:00 AM > To: Kangjiao > Cc: Yoshifumi Nishida ; tcpm@ietf.org Extensions ; Liangqiandeng > Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-b= y-server-00 >=20 > Hello, >=20 > as an overall comment, I agree that one of the difficulties around multipa= th is how the hosts can communicate to the peers the desired scheduling mech= anisms. Currently there is no reliable way besides backup-bits which is a "h= ard" switch. However, often scheduling is much more fine-grained as shown in= a number of the schedulers described in https://tools.ietf.org/html/draft-b= onaventure-iccrg-schedulers-00. >=20 > It's a bit similar to TCP which can't pick the peer's congestion-control a= nd for example if one wants the peer to use a background-CC the host needs t= o resort to tuning the receive-window a la draft-bagnulo-iccrg-rledbat-00. >=20 > So, having a way to communicate the scheduling "requirements" to the peer (= and let the peer match these requirements with its local policies), would be= good! >=20 >=20 > One more comment inline: >=20 >> On 07/20/20 - 03:54, Kangjiao wrote: >> Hi Yoshi, >>=20 >> Thanks for your suggestions. We clarify the issues as below: >>=20 >> 1: One thing I'm not very clear is why we cannot use MP_PRIO for the=20 >> use cases described in the draft. I believe the draft should describe=20 >> the cases where existing features cannot fulfill the requirements more=20= >> specifically. >>=20 >> KJ: The new MP_Navigation Option is used for the server to indicate=20 >> destination network interface to client for which server wants to use=20 >> for traffic switching. For my understanding, MP_PRIO is used to signal=20= >> a change in priority of subflows to the peer. In application, MP_PRIO=20 >> can reduce the chance of data transmission on a specific subflow but=20 >> it cannot tell its peer which network interface is the destination from s= erver side. >> For example, if there are multiple subflows with high priority from=20 >> difference network interfaces, client receiving MP_PRIO does not know=20 >> which is the target one. >=20 > For this particular scenario the server could send the MP_PRIO with backup= -bit set on all subflows that the client should not use. Thus implicitly the= high-priority network-interfaces can then be used by the client, right? >=20 >=20 > Christoph >=20 >> 2: Clients also have their own constraints. (e.g. policy or routing)=20 >> So, even though servers send a navigation request, they might not=20 >> follow it. I think this point should be clarified. >>=20 >> KJ: If the mechanism of accurate-data-scheduling-by-server is=20 >> deployed, the principle is that the server takes precedence. >>=20 >> 3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1? >>=20 >> KJ: For the protocol design, the definition of =E2=80=99r=E2=80=99, =E2=80= =98E=E2=80=99 and =E2=80=99B=E2=80=99 are=20 >> as >> following: Flag =E2=80=98r=E2=80=99: reserved for future usage. Flag =E2= =80=98E=E2=80=99: exists to=20 >> provide reliability for this option (like that in =E2=80=9DADD_ADDR=E2=80= =9D). Flag =E2=80=99B=E2=80=99: >> indicates whether the subflow over which the option is received is a=20 >> backup one (that is compatiable with the value by MP_PRIO). >>=20 >> But we are thinking whether these fields are necessary and should be=20 >> set as mandatory. >>=20 >> Sincerely, Jiao From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf Of=20= >> Yoshifumi Nishida Sent: Sunday, July 19, 2020 7:26 PM To:=20 >> tcpm@ietf.org Extensions Subject: [tcpm] comments on >> draft-kang-tcpm-accurate-data-scheduling-by-server-00 >>=20 >> Hi, I've read draft-kang-tcpm-accurate-data-scheduling-by-server-00. =20 >> I think this is an interesting topic for mptcp, but I think it would=20 >> be better to clarify the following points. >>=20 >> 1: One thing I'm not very clear is why we cannot use MP_PRIO for the=20 >> use cases described in the draft. I believe the draft should describe=20 >> the cases where existing features cannot fulfill the requirements more=20= >> specifically. >>=20 >> 2: Clients also have their own constraints. (e.g. policy or routing)=20 >> So, even though servers send a navigation request, they might not=20 >> follow it. I think this point should be clarified. >>=20 >> 3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1? >>=20 >> Thanks, -- Yoshi >=20 >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >=20 From nobody Wed Jul 22 21:38:48 2020 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 C7AD93A0C42 for ; Wed, 22 Jul 2020 21:38:46 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSA68UtyAjYe for ; Wed, 22 Jul 2020 21:38:45 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BF1903A0C40 for ; Wed, 22 Jul 2020 21:38:44 -0700 (PDT) Received: from lhreml724-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 45E913C16AF09A8FA54D; Thu, 23 Jul 2020 05:38:42 +0100 (IST) Received: from lhreml724-chm.china.huawei.com (10.201.108.75) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 23 Jul 2020 05:38:41 +0100 Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml724-chm.china.huawei.com (10.201.108.75) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 23 Jul 2020 05:38:41 +0100 Received: from DGGEMM534-MBS.china.huawei.com ([169.254.7.122]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0487.000; Thu, 23 Jul 2020 12:38:31 +0800 From: Kangjiao To: Christoph Paasch CC: Yoshifumi Nishida , "tcpm@ietf.org Extensions" , Liangqiandeng Thread-Topic: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 Thread-Index: AQHWXb+HJHOpbU0oSkKL2jMMYvRPV6kP1fbAgAHYVoCAAryHoP//kUKAgACdjyA= Date: Thu, 23 Jul 2020 04:38:31 +0000 Message-ID: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9AA60@dggemm534-mbs.china.huawei.com> References: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9A9BC@dggemm534-mbs.china.huawei.com> <213AD4B1-4F88-4389-93CE-242916C06DC8@apple.com> In-Reply-To: <213AD4B1-4F88-4389-93CE-242916C06DC8@apple.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.102.89] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 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, 23 Jul 2020 04:38:47 -0000 SGkgQ2hyaXN0b3BoLA0KDQpGcm9tIG15IHBlcnNwZWN0aXZlLCBJIHRoaW5rIGZvbGxvd2luZyBh cmUgdHdvIGRpZmZlcmVudCByZXF1aXJlbWVudHM6DQogDQoxLiBNYWtpbmcgYWxsIHRoZSB0cmFm ZmljIHRvd2FyZHMgUzIgKGZvciB0aGlzIGNhc2UsIE1QX1BSSU8gbWF5IGJlIGVub3VnaCkNCg0K Mi4gTWFraW5nIHRyYWZmaWMgb25seSBmcm9tIDxJUF9DMSwgSVBfUzE+IHRvIHRoZSBkZXN0aW5h dGlvbiBJUF9TMiwgd2hpY2ggbWVhbnMgZGl2ZXJ0aW5nIHRyYWZmaWMgdGhhdCBzaG91bGQgYmUg c2NoZWR1bGVkIHRvIDxJUF9DMSwgSVBfUzE+IHRvIG9uZSBzdWJmbG93IGJlbG9uZ2luZyB0byB0 aGUgdGFyZ2V0IG5ldHdvcmsgaW50ZXJmYWNlIChpdCBpcyAib24tZGVtYW5kIHNjaGVkdWxpbmci LCBmb3IgdGhpcyBjYXNlLCBNUF9QUklPIGlzIG5vdCBlbm91Z2gpDQoNCldoYXQgZG8geW91IHRo aW5rPw0KDQpTaW5jZXJlbHkNCkppYW8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IENocmlzdG9waCBQYWFzY2ggW21haWx0bzpjcGFhc2NoQGFwcGxlLmNvbV0gDQpTZW50OiBU aHVyc2RheSwgSnVseSAyMywgMjAyMCAxMToxMSBBTQ0KVG86IEthbmdqaWFvIDxrYW5namlhb0Bo dWF3ZWkuY29tPg0KQ2M6IFlvc2hpZnVtaSBOaXNoaWRhIDxuc2QuaWV0ZkBnbWFpbC5jb20+OyB0 Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMgPHRjcG1AaWV0Zi5vcmc+OyBMaWFuZ3FpYW5kZW5nIDxs aWFuZ3FpYW5kZW5nQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBSZTogW3RjcG1dIGNvbW1lbnRzIG9u IGRyYWZ0LWthbmctdGNwbS1hY2N1cmF0ZS1kYXRhLXNjaGVkdWxpbmctYnktc2VydmVyLTAwDQoN CkhlbGxvLA0KDQo+IE9uIEp1bCAyMiwgMjAyMCwgYXQgNzowMSBQTSwgS2FuZ2ppYW8gPGthbmdq aWFvQGh1YXdlaS5jb20+IHdyb3RlOg0KPiANCj4g77u/SGkgQ2hyaXN0b3BoIGFuZCBZb3NoaSwN Cj4gDQo+IElmIEkgdW5kZXJzdGFuZCByaWdodCwgeW91IGJvdGggcG9pbnQgdG8gdGhlIHNhbWUg cXVlc3Rpb24gd2hldGhlciByZXVzaW5nIHRoZSBNUF9QUklPIGNhbiBmaW5pc2ggYWNjdXJhdGUg ZGF0YSBzY2hlZHVsaW5nIGZvciBzZXJ2ZXIuIEkgdGhpbmsgTVBfUFJJTyBtYXkgYmUgbm90IGVu b3VnaCBldmVuIGlmIHNldHRpbmcgYWxsIHRoZSAibm9uLXRhcmdldCIgc3ViZmxvd3MgdG8gYmFj a3VwIG9uZXMuIEkgY2FuIGdpdmUgYSBzY2VuYXJpbzoNCj4gDQo+IFNpeCBzdWJmbG93cyBoYXZl IGJlZW4gZXN0YWJsaXNoZWQgYmV0d2VlbiBjbGllbnQgYW5kIHNlcnZlciB0aGF0IGFyZSA8SVBf QzEsIElQX1MxPiwgPElQX0MyLCBJUF9TMT4sIDxJUF9DMSwgSVBfUzI+LCA8SVBfQzIsIElQX1My PiwgPElQX0MxLCBJUF9TMz4gYW5kIDxJUF9DMiwgSVBfUzM+LiBUaGUgY2xpZW50IGhhcyBJUF9D MSBhbmQgSVBfQzIuIFRoZSBzZXJ2ZXIgaGFzIElQX1MxLCBJUF9TMiBhbmQgSVBfUzMuDQo+IA0K PiBTZXJ2ZXIgdG9vbCBkZXRlY3RzIHRoYXQgS1BJIG9mIElQX1MyIGlzIGJldHRlciBub3cgc28g dGhlIHNlcnZlciB3YW50cyB0byBzd2l0Y2ggZGF0YSB0cmFmZmljIGZyb20gPElQX0MxLCBJUF9T MT4gdG8gdGhlIGRlc3RpbmF0aW9uIElQX1MyLiBJZiB3ZSBzZXQgPElQX0MxLCBJUF9TMT4gYXMg ImJhY2t1cCIsIGl0IGlzIG5vdCBndWFyYW50ZWVkIHRoYXQgYWxsIHRoZSBsb2FkIG92ZXIgPElQ X0MxLCBJUF9TMT4gY2FuIGJlIGRpdmVydGVkIHRvIElQX1MyIGJlY2F1c2Ugb2YgdGhlIG9uZ29p bmcgc3VmbG93cyB0b3dhcmRzIElQX1MzLg0KDQpCdXQgd2UgY291bGQgc2ltcGx5IGFsc28gc2V0 IDxJUF9DMSxJUF9TMz4gYW5zIDxJUF9DMixJUF9TMz4gYXMgYmFja3VwIGFzIHdlbGwsIG5vPw0K DQpOb3csIGFsbCB0aGUgdHJhZmZpYyB3aWxsIGJlIHN0ZWVyZWQgdG93YXJkcyBTMi4NCg0KQ2hy aXN0b3BoDQoNCg0KPiANCj4gU28gSSB0aGluayBNUF9QUklPIGNhbiByZWR1Y2UgdGhlIGNoYW5j ZSBvZiBkYXRhIHRyYW5zbWlzc2lvbiBvbiBhIHNwZWNpZmljIHN1YmZsb3cgYnV0IGl0IGNhbm5v dCBjb252ZXkgdGhlIGluZm8gb2YgdGFyZ2V0IG5ldHdvcmsgaW50ZXJmYWNlIGZyb20gc2VydmVy IHRvIGNsaWVudC4NCj4gDQo+IFRoYW5rcw0KPiBKaWFvDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBDaHJpc3RvcGggUGFhc2NoIFttYWlsdG86Y3BhYXNjaEBhcHBs ZS5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAyMiwgMjAyMCAxMjowMCBBTQ0KPiBUbzog S2FuZ2ppYW8gPGthbmdqaWFvQGh1YXdlaS5jb20+DQo+IENjOiBZb3NoaWZ1bWkgTmlzaGlkYSA8 bnNkLmlldGZAZ21haWwuY29tPjsgdGNwbUBpZXRmLm9yZyBFeHRlbnNpb25zIA0KPiA8dGNwbUBp ZXRmLm9yZz47IExpYW5ncWlhbmRlbmcgPGxpYW5ncWlhbmRlbmdAaHVhd2VpLmNvbT4NCj4gU3Vi amVjdDogUmU6IFt0Y3BtXSBjb21tZW50cyBvbiANCj4gZHJhZnQta2FuZy10Y3BtLWFjY3VyYXRl LWRhdGEtc2NoZWR1bGluZy1ieS1zZXJ2ZXItMDANCj4gDQo+IEhlbGxvLA0KPiANCj4gYXMgYW4g b3ZlcmFsbCBjb21tZW50LCBJIGFncmVlIHRoYXQgb25lIG9mIHRoZSBkaWZmaWN1bHRpZXMgYXJv dW5kIG11bHRpcGF0aCBpcyBob3cgdGhlIGhvc3RzIGNhbiBjb21tdW5pY2F0ZSB0byB0aGUgcGVl cnMgdGhlIGRlc2lyZWQgc2NoZWR1bGluZyBtZWNoYW5pc21zLiBDdXJyZW50bHkgdGhlcmUgaXMg bm8gcmVsaWFibGUgd2F5IGJlc2lkZXMgYmFja3VwLWJpdHMgd2hpY2ggaXMgYSAiaGFyZCIgc3dp dGNoLiBIb3dldmVyLCBvZnRlbiBzY2hlZHVsaW5nIGlzIG11Y2ggbW9yZSBmaW5lLWdyYWluZWQg YXMgc2hvd24gaW4gYSBudW1iZXIgb2YgdGhlIHNjaGVkdWxlcnMgZGVzY3JpYmVkIGluIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib25hdmVudHVyZS1pY2NyZy1zY2hlZHVsZXJz LTAwLg0KPiANCj4gSXQncyBhIGJpdCBzaW1pbGFyIHRvIFRDUCB3aGljaCBjYW4ndCBwaWNrIHRo ZSBwZWVyJ3MgY29uZ2VzdGlvbi1jb250cm9sIGFuZCBmb3IgZXhhbXBsZSBpZiBvbmUgd2FudHMg dGhlIHBlZXIgdG8gdXNlIGEgYmFja2dyb3VuZC1DQyB0aGUgaG9zdCBuZWVkcyB0byByZXNvcnQg dG8gdHVuaW5nIHRoZSByZWNlaXZlLXdpbmRvdyBhIGxhIGRyYWZ0LWJhZ251bG8taWNjcmctcmxl ZGJhdC0wMC4NCj4gDQo+IFNvLCBoYXZpbmcgYSB3YXkgdG8gY29tbXVuaWNhdGUgdGhlIHNjaGVk dWxpbmcgInJlcXVpcmVtZW50cyIgdG8gdGhlIHBlZXIgKGFuZCBsZXQgdGhlIHBlZXIgbWF0Y2gg dGhlc2UgcmVxdWlyZW1lbnRzIHdpdGggaXRzIGxvY2FsIHBvbGljaWVzKSwgd291bGQgYmUgZ29v ZCENCj4gDQo+IA0KPiBPbmUgbW9yZSBjb21tZW50IGlubGluZToNCj4gDQo+PiBPbiAwNy8yMC8y MCAtIDAzOjU0LCBLYW5namlhbyB3cm90ZToNCj4+IEhpIFlvc2hpLA0KPj4gDQo+PiBUaGFua3Mg Zm9yIHlvdXIgc3VnZ2VzdGlvbnMuIFdlIGNsYXJpZnkgdGhlIGlzc3VlcyBhcyBiZWxvdzoNCj4+ IA0KPj4gMTogT25lIHRoaW5nIEknbSBub3QgdmVyeSBjbGVhciBpcyB3aHkgd2UgY2Fubm90IHVz ZSBNUF9QUklPIGZvciB0aGUgDQo+PiB1c2UgY2FzZXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4g SSBiZWxpZXZlIHRoZSBkcmFmdCBzaG91bGQgZGVzY3JpYmUgDQo+PiB0aGUgY2FzZXMgd2hlcmUg ZXhpc3RpbmcgZmVhdHVyZXMgY2Fubm90IGZ1bGZpbGwgdGhlIHJlcXVpcmVtZW50cyANCj4+IG1v cmUgc3BlY2lmaWNhbGx5Lg0KPj4gDQo+PiBLSjogVGhlIG5ldyBNUF9OYXZpZ2F0aW9uIE9wdGlv biBpcyB1c2VkIGZvciB0aGUgc2VydmVyIHRvIGluZGljYXRlIA0KPj4gZGVzdGluYXRpb24gbmV0 d29yayBpbnRlcmZhY2UgdG8gY2xpZW50IGZvciB3aGljaCBzZXJ2ZXIgd2FudHMgdG8gdXNlIA0K Pj4gZm9yIHRyYWZmaWMgc3dpdGNoaW5nLiBGb3IgbXkgdW5kZXJzdGFuZGluZywgTVBfUFJJTyBp cyB1c2VkIHRvIA0KPj4gc2lnbmFsIGEgY2hhbmdlIGluIHByaW9yaXR5IG9mIHN1YmZsb3dzIHRv IHRoZSBwZWVyLiBJbiBhcHBsaWNhdGlvbiwgDQo+PiBNUF9QUklPIGNhbiByZWR1Y2UgdGhlIGNo YW5jZSBvZiBkYXRhIHRyYW5zbWlzc2lvbiBvbiBhIHNwZWNpZmljIA0KPj4gc3ViZmxvdyBidXQg aXQgY2Fubm90IHRlbGwgaXRzIHBlZXIgd2hpY2ggbmV0d29yayBpbnRlcmZhY2UgaXMgdGhlIGRl c3RpbmF0aW9uIGZyb20gc2VydmVyIHNpZGUuDQo+PiBGb3IgZXhhbXBsZSwgaWYgdGhlcmUgYXJl IG11bHRpcGxlIHN1YmZsb3dzIHdpdGggaGlnaCBwcmlvcml0eSBmcm9tIA0KPj4gZGlmZmVyZW5j ZSBuZXR3b3JrIGludGVyZmFjZXMsIGNsaWVudCByZWNlaXZpbmcgTVBfUFJJTyBkb2VzIG5vdCBr bm93IA0KPj4gd2hpY2ggaXMgdGhlIHRhcmdldCBvbmUuDQo+IA0KPiBGb3IgdGhpcyBwYXJ0aWN1 bGFyIHNjZW5hcmlvIHRoZSBzZXJ2ZXIgY291bGQgc2VuZCB0aGUgTVBfUFJJTyB3aXRoIGJhY2t1 cC1iaXQgc2V0IG9uIGFsbCBzdWJmbG93cyB0aGF0IHRoZSBjbGllbnQgc2hvdWxkIG5vdCB1c2Uu IFRodXMgaW1wbGljaXRseSB0aGUgaGlnaC1wcmlvcml0eSBuZXR3b3JrLWludGVyZmFjZXMgY2Fu IHRoZW4gYmUgdXNlZCBieSB0aGUgY2xpZW50LCByaWdodD8NCj4gDQo+IA0KPiBDaHJpc3RvcGgN Cj4gDQo+PiAyOiBDbGllbnRzIGFsc28gaGF2ZSB0aGVpciBvd24gY29uc3RyYWludHMuIChlLmcu IHBvbGljeSBvciByb3V0aW5nKSANCj4+IFNvLCBldmVuIHRob3VnaCBzZXJ2ZXJzIHNlbmQgYSBu YXZpZ2F0aW9uIHJlcXVlc3QsIHRoZXkgbWlnaHQgbm90IA0KPj4gZm9sbG93IGl0LiBJIHRoaW5r IHRoaXMgcG9pbnQgc2hvdWxkIGJlIGNsYXJpZmllZC4NCj4+IA0KPj4gS0o6IElmIHRoZSBtZWNo YW5pc20gb2YgYWNjdXJhdGUtZGF0YS1zY2hlZHVsaW5nLWJ5LXNlcnZlciBpcyANCj4+IGRlcGxv eWVkLCB0aGUgcHJpbmNpcGxlIGlzIHRoYXQgdGhlIHNlcnZlciB0YWtlcyBwcmVjZWRlbmNlLg0K Pj4gDQo+PiAzOiBXaGF0J3MgdGhlIG1lYW5pbmcgb2YgJ3InLCAnRScsICdCJyBmbGFncyBpbiBT ZWN0aW9uIDQuMT8NCj4+IA0KPj4gS0o6ICBGb3IgdGhlIHByb3RvY29sIGRlc2lnbiwgdGhlIGRl ZmluaXRpb24gb2Yg4oCZcuKAmSwg4oCYReKAmSBhbmQg4oCZQuKAmSBhcmUgDQo+PiBhcw0KPj4g Zm9sbG93aW5nOiBGbGFnIOKAmHLigJk6IHJlc2VydmVkIGZvciBmdXR1cmUgdXNhZ2UuICBGbGFn IOKAmEXigJk6IGV4aXN0cyB0byANCj4+IHByb3ZpZGUgcmVsaWFiaWxpdHkgZm9yIHRoaXMgb3B0 aW9uIChsaWtlIHRoYXQgaW4g4oCdQUREX0FERFLigJ0pLiAgRmxhZyDigJlC4oCZOg0KPj4gaW5k aWNhdGVzIHdoZXRoZXIgdGhlIHN1YmZsb3cgb3ZlciB3aGljaCB0aGUgb3B0aW9uIGlzIHJlY2Vp dmVkIGlzIGEgDQo+PiBiYWNrdXAgb25lICh0aGF0IGlzIGNvbXBhdGlhYmxlIHdpdGggdGhlIHZh bHVlIGJ5IE1QX1BSSU8pLg0KPj4gDQo+PiBCdXQgd2UgYXJlIHRoaW5raW5nIHdoZXRoZXIgdGhl c2UgZmllbGRzIGFyZSBuZWNlc3NhcnkgYW5kIHNob3VsZCBiZSANCj4+IHNldCBhcyBtYW5kYXRv cnkuDQo+PiANCj4+IFNpbmNlcmVseSwgSmlhbyBGcm9tOiB0Y3BtIFttYWlsdG86dGNwbS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQo+PiBPZiBZb3NoaWZ1bWkgTmlzaGlkYSBTZW50OiBT dW5kYXksIEp1bHkgMTksIDIwMjAgNzoyNiBQTSBUbzoNCj4+IHRjcG1AaWV0Zi5vcmcgRXh0ZW5z aW9ucyA8dGNwbUBpZXRmLm9yZz4gU3ViamVjdDogW3RjcG1dIGNvbW1lbnRzIG9uDQo+PiBkcmFm dC1rYW5nLXRjcG0tYWNjdXJhdGUtZGF0YS1zY2hlZHVsaW5nLWJ5LXNlcnZlci0wMA0KPj4gDQo+ PiBIaSwgSSd2ZSByZWFkIGRyYWZ0LWthbmctdGNwbS1hY2N1cmF0ZS1kYXRhLXNjaGVkdWxpbmct Ynktc2VydmVyLTAwLiAgDQo+PiBJIHRoaW5rIHRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgdG9waWMg Zm9yIG1wdGNwLCBidXQgSSB0aGluayBpdCB3b3VsZCANCj4+IGJlIGJldHRlciB0byBjbGFyaWZ5 IHRoZSBmb2xsb3dpbmcgcG9pbnRzLg0KPj4gDQo+PiAxOiBPbmUgdGhpbmcgSSdtIG5vdCB2ZXJ5 IGNsZWFyIGlzIHdoeSB3ZSBjYW5ub3QgdXNlIE1QX1BSSU8gZm9yIHRoZSANCj4+IHVzZSBjYXNl cyBkZXNjcmliZWQgaW4gdGhlIGRyYWZ0LiBJIGJlbGlldmUgdGhlIGRyYWZ0IHNob3VsZCBkZXNj cmliZSANCj4+IHRoZSBjYXNlcyB3aGVyZSBleGlzdGluZyBmZWF0dXJlcyBjYW5ub3QgZnVsZmls bCB0aGUgcmVxdWlyZW1lbnRzIA0KPj4gbW9yZSBzcGVjaWZpY2FsbHkuDQo+PiANCj4+IDI6IENs aWVudHMgYWxzbyBoYXZlIHRoZWlyIG93biBjb25zdHJhaW50cy4gKGUuZy4gcG9saWN5IG9yIHJv dXRpbmcpIA0KPj4gU28sIGV2ZW4gdGhvdWdoIHNlcnZlcnMgc2VuZCBhIG5hdmlnYXRpb24gcmVx dWVzdCwgdGhleSBtaWdodCBub3QgDQo+PiBmb2xsb3cgaXQuIEkgdGhpbmsgdGhpcyBwb2ludCBz aG91bGQgYmUgY2xhcmlmaWVkLg0KPj4gDQo+PiAzOiBXaGF0J3MgdGhlIG1lYW5pbmcgb2YgJ3In LCAnRScsICdCJyBmbGFncyBpbiBTZWN0aW9uIDQuMT8NCj4+IA0KPj4gVGhhbmtzLCAtLSBZb3No aQ0KPiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiB0Y3BtIG1haWxpbmcgbGlzdA0KPj4gdGNwbUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90Y3BtDQo+IA0K From nobody Wed Jul 22 21:44:24 2020 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 BAAFB3A0C53; Wed, 22 Jul 2020 21:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 xQ7yS0bgZ2Me; Wed, 22 Jul 2020 21:44:21 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 529F83A0C41; Wed, 22 Jul 2020 21:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SAraM2su2yuVNUNAUVC7otyW8IAzvMv9oFQ5BqSS32E=; b=zjHz3J9ftFQC1Q8YFhiR1Pdrc gvOgi13GcDzb47NABbM0PpQu+AJnS0NcKtaqcETWLU9vSdgpU4ZbUA7E2hPbiN5lMLRdvpedeWO5Z TUk8+kd5vtk4yYVuMsODcf6o71gNAaf4I4SDdjJitgA6RpySkbNh4q5/bqCfe+7i6Aq84iltZ1pC7 UYLBzoM067dA4/exg0DD2iKwv8oAgJC8KNPtFdD7vqrFQ6A7kxMxjOSVPoh3WnDyYJ1tsbU909adS oHDew6KAP4M4hXa0O4NLC29muPJ+uP5I00GBPRDTU59ZQpM+fPVxIL3/WgV8oaENX/LHY/j8JzPVZ Q+VAuwriA==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61109 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jyT5c-0044hL-6j; Thu, 23 Jul 2020 00:44:20 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_2A09E40B-6DD0-4E3A-AACF-65405B6F9836" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DCC403E@rznt8114.rznt.rzdir.fht-esslingen.de> Date: Wed, 22 Jul 2020 21:44:15 -0700 Cc: Juhamatti Kuusisaari , "tcpm-chairs@ietf.org" , tcpm IETF list Message-Id: <9A6C3C44-12E3-4C93-8437-F8615FD7B0DB@strayalpha.com> References: <6EC6417807D9754DA64F3087E2E2E03E2DC848FF@rznt8114.rznt.rzdir.fht-esslingen.de> <6EC6417807D9754DA64F3087E2E2E03E2DCC403E@rznt8114.rznt.rzdir.fht-esslingen.de> To: "Scharf, Michael" X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [tcpm] Presentation slot requests for IETF 108 (online) 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, 23 Jul 2020 04:44:23 -0000 --Apple-Mail=_2A09E40B-6DD0-4E3A-AACF-65405B6F9836 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FWIW - this is largely my fault; I didn=E2=80=99t realize the timelines = and I=E2=80=99ve been helping lead this effort through the IETF process.=20= Even a brief slot would be appreciated and useful. It=E2=80=99s quite = simple as docs go. Joe > On Jul 22, 2020, at 3:21 PM, Scharf, Michael = wrote: >=20 > Hi Juhamatti, > =20 > This is a late request. > =20 > But as we may have some time left, I=E2=80=99ll put you talk at the = end of the agenda (=E2=80=9Cif time permits=E2=80=9D). > =20 > Michael > =20 > From: Juhamatti Kuusisaari >=20 > Sent: Wednesday, July 22, 2020 11:04 AM > To: tcpm-chairs@ietf.org > Cc: Joseph Touch >; = tcpm IETF list > > Subject: [tcpm] Presentation slot requests for IETF 108 (online) > =20 > =20 > Dear chairs, >=20 > We would like to request a presentation slot for IETF 108. >=20 > Please find next the details of the request: >=20 > * Draft name / presentation title: draft-touch-tcpm-ao-test-vectors-00 > * Presenter: Juhamatti Kuusisaari > * Total duration (including Q&A): 15 minutes >=20 > Thanks, >=20 > Juhamatti >=20 >=20 > > Hi all, > > > > Given that we had a pretty packed agenda during the virtual interim > > meeting, the chairs have asked for two slots during IETF 108. This > > basically implies that we have again the 2:30 hour slot that TCPM = used to > > have for many years. > > > > According to the draft agenda for IETF 108, TCPM has been scheduled = for > > Monday Session I (1:40) and Monday Session II (0:50). > > > > If you are interested in presenting, please let the chairs know = until > > **Monday 2020-07-13**: > > > > * Draft name / presentation title > > * Presenter > > * Total duration (including Q&A) > > > > Thanks > > > > Michael (2x) and Yoshi > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm = --Apple-Mail=_2A09E40B-6DD0-4E3A-AACF-65405B6F9836 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FWIW = - this is largely my fault; I didn=E2=80=99t realize the timelines and = I=E2=80=99ve been helping lead this effort through the IETF = process. 

Even = a brief slot would be appreciated and useful. It=E2=80=99s quite simple = as docs go.

Joe

On Jul 22, 2020, at 3:21 PM, Scharf, Michael = <Michael.Scharf@hs-esslingen.de> wrote:

Hi Juhamatti,
 
This is a late request.
 
But as = we may have some time left, I=E2=80=99ll put you talk at the end of the = agenda (=E2=80=9Cif time permits=E2=80=9D).
 
Michael
 
From: Juhamatti Kuusisaari = <juhamatk@gmail.com> 
Sent: Wednesday, July 22, 2020 = 11:04 AM
To: tcpm-chairs@ietf.org
Cc: Joseph Touch <touch@strayalpha.com>; = tcpm IETF list <tcpm@ietf.org>
Subject: [tcpm] Presentation slot = requests for IETF 108 (online)
 
 
Dear chairs,

We would like to = request a presentation slot for IETF 108.

Please find next the details of the request:

* Draft name / presentation title: = draft-touch-tcpm-ao-test-vectors-00
* Presenter:    =                     = Juhamatti Kuusisaari
* Total duration (including = Q&A):   15 minutes

Thanks,

Juhamatti


> Hi all,
>
> Given that = we had a pretty packed agenda during the virtual interim
> meeting, the chairs have asked for two slots during IETF = 108. This
> basically implies that we have again the = 2:30 hour slot that TCPM used to
> have for many = years.
>
> According to the draft = agenda for IETF 108, TCPM has been scheduled for
> = Monday Session I (1:40) and Monday Session II (0:50).
>
> If you are interested in presenting, = please let the chairs know until
> **Monday = 2020-07-13**:
>
> * Draft name / = presentation title
> * Presenter
> * = Total duration (including Q&A)
>
> = Thanks
>
> Michael (2x) and Yoshi
>
> = _______________________________________________
> tcpm = mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

= --Apple-Mail=_2A09E40B-6DD0-4E3A-AACF-65405B6F9836-- From nobody Thu Jul 23 07:02:11 2020 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 7442A3A045B; Thu, 23 Jul 2020 07:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5Uqdp15lDYr; Thu, 23 Jul 2020 07:02:08 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91EC3A044E; Thu, 23 Jul 2020 07:02:07 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id D648F25A12; Thu, 23 Jul 2020 16:02:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1595512925; bh=+tKDJ9L1vhf6Ky8fwyAEt2IWG8/WwcIoGaUkkdVYbSA=; h=From:To:CC:Subject:Date:From; b=tKVN0KUivKUyqtZgFJV5eV3WpnQdwxyLdAF6bh2xadu3CCXk0xiS3tHyOt0xKTEpR ANZ8BqDEX9yEKcg0J1jdsZ3XJn1vC1Smac+ByOLa505b8RlKoqLIKHtdLDUrpLPvvW tgjPdRYXkHes24xSORlArN1PYzc4aQEPoYUnTyuQ= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlktDJYqt-eD; Thu, 23 Jul 2020 16:02:04 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 23 Jul 2020 16:02:04 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Thu, 23 Jul 2020 16:02:04 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: tcpm-chairs Thread-Topic: IETF 108 agenda for TCPM - second draft Thread-Index: AdZg+c6IAxFvnmxCReiPcE3M26pvbA== Date: Thu, 23 Jul 2020 14:02:03 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DCC51F6@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] IETF 108 agenda for TCPM - second draft 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, 23 Jul 2020 14:02:10 -0000 I have added two further, short presentations: https://datatracker.ietf.org/doc/agenda-108-tcpm/ Michael From nobody Thu Jul 23 07:09:30 2020 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 3A7A53A0766; Thu, 23 Jul 2020 07:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.631 X-Spam-Level: X-Spam-Status: No, score=-1.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.267, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 7hk85WYVFvti; Thu, 23 Jul 2020 07:09:27 -0700 (PDT) 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 02A803A0747; Thu, 23 Jul 2020 07:09:26 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:ecd2:abd1:c73d:3fc7] (unknown [IPv6:2a02:8109:1140:c3d:ecd2:abd1:c73d:3fc7]) (Authenticated sender: macmic) by drew.franken.de (Postfix) with ESMTPSA id 85A737220F406; Thu, 23 Jul 2020 16:09:21 +0200 (CEST) From: Michael Tuexen Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7262B253-5950-4AD0-9A84-61C3D26A64C7"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 23 Jul 2020 16:09:20 +0200 In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2DCC51F6@rznt8114.rznt.rzdir.fht-esslingen.de> Cc: "tcpm@ietf.org" , tcpm-chairs To: "Scharf, Michael" References: <6EC6417807D9754DA64F3087E2E2E03E2DCC51F6@rznt8114.rznt.rzdir.fht-esslingen.de> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [tcpm] IETF 108 agenda for TCPM - second draft 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, 23 Jul 2020 14:09:29 -0000 --Apple-Mail=_7262B253-5950-4AD0-9A84-61C3D26A64C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 23. Jul 2020, at 16:02, Scharf, Michael = wrote: >=20 > I have added two further, short presentations: The first part is 5 minutes over time, exactly the rime where meetecho = will kill the session... Best regards Michael >=20 > https://datatracker.ietf.org/doc/agenda-108-tcpm/ >=20 > Michael --Apple-Mail=_7262B253-5950-4AD0-9A84-61C3D26A64C7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEKow ggUSMIID+qADAgECAgkA4wvV+K8l2YEwDQYJKoZIhvcNAQELBQAwgYIxCzAJBgNVBAYTAkRFMSsw KQYDVQQKDCJULVN5c3RlbXMgRW50ZXJwcmlzZSBTZXJ2aWNlcyBHbWJIMR8wHQYDVQQLDBZULVN5 c3RlbXMgVHJ1c3QgQ2VudGVyMSUwIwYDVQQDDBxULVRlbGVTZWMgR2xvYmFsUm9vdCBDbGFzcyAy MB4XDTE2MDIyMjEzMzgyMloXDTMxMDIyMjIzNTk1OVowgZUxCzAJBgNVBAYTAkRFMUUwQwYDVQQK EzxWZXJlaW4genVyIEZvZXJkZXJ1bmcgZWluZXMgRGV1dHNjaGVuIEZvcnNjaHVuZ3NuZXR6ZXMg ZS4gVi4xEDAOBgNVBAsTB0RGTi1QS0kxLTArBgNVBAMTJERGTi1WZXJlaW4gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMtg1/9moUHN0vqH l4pzq5lN6mc5WqFggEcVToyVsuXPztNXS43O+FZsFVV2B+pG/cgDRWM+cNSrVICxI5y+NyipCf8F XRgPxJiZN7Mg9mZ4F4fCnQ7MSjLnFp2uDo0peQcAIFTcFV9Kltd4tjTTwXS1nem/wHdN6r1ZB+Ba L2w8pQDcNb1lDY9/Mm3yWmpLYgHurDg0WUU2SQXaeMpqbVvAgWsRzNI8qIv4cRrKO+KA3Ra0Z3qL NupOkSk9s1FcragMvp0049ENF4N1xDkesJQLEvHVaY4l9Lg9K7/AjsMeO6W/VRCrKq4Xl14zzsjz 9AkH4wKGMUZrAcUQDBHHWekCAwEAAaOCAXQwggFwMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQU k+PYMiba1fFKpZFK4OpL4qIMz+EwHwYDVR0jBBgwFoAUv1kgNgB5oKAia4zV8mHSuCzLgkowEgYD VR0TAQH/BAgwBgEB/wIBAjAzBgNVHSAELDAqMA8GDSsGAQQBga0hgiwBAQQwDQYLKwYBBAGBrSGC LB4wCAYGZ4EMAQICMEwGA1UdHwRFMEMwQaA/oD2GO2h0dHA6Ly9wa2kwMzM2LnRlbGVzZWMuZGUv cmwvVGVsZVNlY19HbG9iYWxSb290X0NsYXNzXzIuY3JsMIGGBggrBgEFBQcBAQR6MHgwLAYIKwYB BQUHMAGGIGh0dHA6Ly9vY3NwMDMzNi50ZWxlc2VjLmRlL29jc3ByMEgGCCsGAQUFBzAChjxodHRw Oi8vcGtpMDMzNi50ZWxlc2VjLmRlL2NydC9UZWxlU2VjX0dsb2JhbFJvb3RfQ2xhc3NfMi5jZXIw DQYJKoZIhvcNAQELBQADggEBAIcL/z4Cm2XIVi3WO5qYi3FP2ropqiH5Ri71sqQPrhE4eTizDnS6 dl2e6BiClmLbTDPo3flq3zK9LExHYFV/53RrtCyD2HlrtrdNUAtmB7Xts5et6u5/MOaZ/SLick0+ hFvu+c+Z6n/XUjkurJgARH5pO7917tALOxrN5fcPImxHhPalR6D90Bo0fa3SPXez7vTXTf/D6OWS T1k+kEcQSrCFWMBvf/iu7QhCnh7U3xQuTY+8npTD5+32GPg8SecmqKc22CzeIs2LgtjZeOJVEqM7 h0S2EQvVDFKvaYwPBt/QolOLV5h7z/0HJPT8vcP9SpIClxvyt7bPZYoaorVyGTkwggWsMIIElKAD AgECAgcbY7rQHiw9MA0GCSqGSIb3DQEBCwUAMIGVMQswCQYDVQQGEwJERTFFMEMGA1UEChM8VmVy ZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYu MRAwDgYDVQQLEwdERk4tUEtJMS0wKwYDVQQDEyRERk4tVmVyZWluIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IDIwHhcNMTYwNTI0MTEzODQwWhcNMzEwMjIyMjM1OTU5WjCBjTELMAkGA1UEBhMCREUx RTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5lcyBEZXV0c2NoZW4gRm9yc2NodW5n c25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMGA1UEAwwcREZOLVZlcmVpbiBHbG9i YWwgSXNzdWluZyBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ07eRxH3h+Gy8Zp 1xCeOdfZojDbchwFfylfS2jxrRnWTOFrG7ELf6Gr4HuLi9gtzm6IOhDuV+UefwRRNuu6cG1joL6W LkDh0YNMZj0cZGnlm6Stcq5oOVGHecwX064vXWNxSzl660Knl5BpBb+Q/6RAcL0D57+eGIgfn5mI TQ5HjUhfZZkQ0tkqSe3BuS0dnxLLFdM/fx5ULzquk1enfnjK1UriGuXtQX1TX8izKvWKMKztFwUk P7agCwf9TRqaA1KgNpzeJIdl5Of6x5ZzJBTN0OgbaJ4YWa52fvfRCng8h0uwN89Tyjo4EPPLR22M ZD08WkVKusqAfLjz56dMTM0CAwEAAaOCAgUwggIBMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0P AQH/BAQDAgEGMCkGA1UdIAQiMCAwDQYLKwYBBAGBrSGCLB4wDwYNKwYBBAGBrSGCLAEBBDAdBgNV HQ4EFgQUazqYi/nyU4na4K2yMh4JH+iqO3QwHwYDVR0jBBgwFoAUk+PYMiba1fFKpZFK4OpL4qIM z+EwgY8GA1UdHwSBhzCBhDBAoD6gPIY6aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9v dC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDBAoD6gPIY6aHR0cDovL2NkcDIucGNhLmRmbi5kZS9n bG9iYWwtcm9vdC1nMi1jYS9wdWIvY3JsL2NhY3JsLmNybDCB3QYIKwYBBQUHAQEEgdAwgc0wMwYI KwYBBQUHMAGGJ2h0dHA6Ly9vY3NwLnBjYS5kZm4uZGUvT0NTUC1TZXJ2ZXIvT0NTUDBKBggrBgEF BQcwAoY+aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1nMi1jYS9wdWIvY2FjZXJ0 L2NhY2VydC5jcnQwSgYIKwYBBQUHMAKGPmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJv b3QtZzItY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQCBeEWkTqR/ DlXwCbFqPnjMaDWpHPOVnj/z+N9rOHeJLI21rT7H8pTNoAauusyosa0zCLYkhmI2THhuUPDVbmCN T1IxQ5dGdfBi5G5mUcFCMWdQ5UnnOR7Ln8qGSN4IFP8VSytmm6A4nwDO/afr0X9XLchMX9wQEZc+ lgQCXISoKTlslPwQkgZ7nu7YRrQbtQMMONncsKk/cQYLsgMHM8KNSGMlJTx6e1du94oFOO+4oK4v 9NsH1VuEGMGpuEvObJAaguS5Pfp38dIfMwK/U+d2+dwmJUFvL6Yb+qQTkPp8ftkLYF3sv8pBoGH7 EUkp2KgtdRXYShjqFu9VNCIaE40GMIIF4DCCBMigAwIBAgIMIRX9tDE2QqO3mVLXMA0GCSqGSIb3 DQEBCwUAMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1ciBGb2VyZGVydW5nIGVp bmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYDVQQLDAdERk4tUEtJMSUw IwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBMB4XDTE5MDYwNDE0MjkxMFoXDTIy MDYwMzE0MjkxMFowfDELMAkGA1UEBhMCREUxIDAeBgNVBAoMF0ZhY2hob2Noc2NodWxlIE11ZW5z dGVyMTIwMAYDVQQLDClGYWNoYmVyZWljaCBFbGVrdHJvdGVjaG5payB1bmQgSW5mb3JtYXRpazEX MBUGA1UEAwwOTWljaGFlbCBUdWV4ZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDM r8qQcPxLFCxzPtXvRyM9KeQaxyMA8gwUNc7IIiATs6mRQFe5ib/mvwT9nc0bAa+94go6HJDiD3FJ NkTo4u8aBsIcTt5pJtdBQLm88PLakbe3+fp/00//n7xxbTh7mAtFVCf25LxDCKkrdGk/+jglRq/R VdwhZZ3VpYCrx8YfI/hIzdRL3+4I4z/mnQ8K0X8d2MVVPG+9nBEngdnYGez5f/8wIVOgEYYBc21k yvMnVXLu2Ing+LwBd0gDG9Vasv87MNHCOZfJTNBlLhI2UDei/uNg9Zd4ynlMpPWZ7v0oiDWvmv8E OuD4oric8heyD0OYK2FL4qcVC4dn4pnyulfHAgMBAAGjggJOMIICSjA+BgNVHSAENzA1MA8GDSsG AQQBga0hgiwBAQQwEAYOKwYBBAGBrSGCLAEBBAQwEAYOKwYBBAGBrSGCLAIBBAQwCQYDVR0TBAIw ADAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBTxiodBVL/lA4p5iNesIsJRhhgd6zAfBgNVHSMEGDAWgBRrOpiL+fJTidrgrbIyHgkf6Ko7dDAg BgNVHREEGTAXgRV0dWV4ZW5AZmgtbXVlbnN0ZXIuZGUwgY0GA1UdHwSBhTCBgjA/oD2gO4Y5aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tY2EtZ2xvYmFsLWcyL3B1Yi9jcmwvY2FjcmwuY3JsMD+g PaA7hjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1jYS1nbG9iYWwtZzIvcHViL2NybC9jYWNy bC5jcmwwgdsGCCsGAQUFBwEBBIHOMIHLMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZu LmRlL09DU1AtU2VydmVyL09DU1AwSQYIKwYBBQUHMAKGPWh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUv ZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwSQYIKwYBBQUHMAKGPWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLWNhLWdsb2JhbC1nMi9wdWIvY2FjZXJ0L2NhY2VydC5jcnQw DQYJKoZIhvcNAQELBQADggEBABs3VlmIZ1VF3HkaQdjInZYmamRabbdgJ7cz6m6o/agKL7+Vhwx7 1BaaYs2gMa5Nu/GJ3YfdqIsUlYtKdl58Yhp/89E6xBfJkItS+rE8RFdf2XgklGlx7GmsvdA3tId5 b6K6r9a5wpVN0epxY6K8wwpzEib6fJLcHylybQXZ7JSOaLRLp6WU3QPoyTT7FpvAe/0b2MSCbPX4 fc53PCn2aGgXuRFVQeCn1SP1BF3QW1ppkFhcF6G+0JcUxYFAXE6r/71WZBvUHqoG/th2hAwQnS+Y KhUYh4SZQH3/ursXXJYXQ5vyIhkN1FZlmtWA8+ofdCnoqSTbiSX2Aa/kKbTapwgxggOdMIIDmQIB ATCBnjCBjTELMAkGA1UEBhMCREUxRTBDBgNVBAoMPFZlcmVpbiB6dXIgRm9lcmRlcnVuZyBlaW5l cyBEZXV0c2NoZW4gRm9yc2NodW5nc25ldHplcyBlLiBWLjEQMA4GA1UECwwHREZOLVBLSTElMCMG A1UEAwwcREZOLVZlcmVpbiBHbG9iYWwgSXNzdWluZyBDQQIMIRX9tDE2QqO3mVLXMA0GCWCGSAFl AwQCAQUAoIIBzzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3 MjMxNDA5MjBaMC8GCSqGSIb3DQEJBDEiBCB0CHzpVe9YOscos29UNudsr3ASzAAtF/LjJMmODflz IDCBrwYJKwYBBAGCNxAEMYGhMIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8VmVyZWluIHp1 ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUuIFYuMRAwDgYD VQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5nIENBAgwhFf20 MTZCo7eZUtcwgbEGCyqGSIb3DQEJEAILMYGhoIGeMIGNMQswCQYDVQQGEwJERTFFMEMGA1UECgw8 VmVyZWluIHp1ciBGb2VyZGVydW5nIGVpbmVzIERldXRzY2hlbiBGb3JzY2h1bmdzbmV0emVzIGUu IFYuMRAwDgYDVQQLDAdERk4tUEtJMSUwIwYDVQQDDBxERk4tVmVyZWluIEdsb2JhbCBJc3N1aW5n IENBAgwhFf20MTZCo7eZUtcwDQYJKoZIhvcNAQEBBQAEggEAHOXTjiXW64Tz4voIBLwCBWIv3Bpy NJn/zHMGdzk/+w1L8jZIEaKPtj8FO9pTmDaagJeI/iOcZ8BhdpAR1GTteZYECVuEHHk3lbf+Ijwi G8FpwmRp6zFeSQ7BxW49R5ar88DLkJw03D7rOYLZl2eHs4+DSLXDXDrZew8f/Rpqe0EFgoP043nc MG30Ju3Pu66+cIpWjIDJFTokCgQ/ShRaNSF+VokCeXLTMe5n5R/FYXVoeHGVhIsWtOdNDx7E3w2m XMguKa78HGU+ZGNviYPeFI1l1f8TVJId8hR9GmHemVl55w51MnYMStP3WAyJu+EcczE2CXJiAo7A dG2u51AIQAAAAAAAAA== --Apple-Mail=_7262B253-5950-4AD0-9A84-61C3D26A64C7-- From nobody Thu Jul 23 07:19:39 2020 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 DC7ED3A0789; Thu, 23 Jul 2020 07:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRKaiBfOYHUx; Thu, 23 Jul 2020 07:19:35 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F953A0833; Thu, 23 Jul 2020 07:19:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id A9AD125A12; Thu, 23 Jul 2020 16:19:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1595513973; bh=Pc9Mw7aSmk0x5xf91MA74UuWUBr1QIT6IAN5LouerD8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=Zk2MJQ2PPNGzm85opsaUMPlyx9eBbCo8cskKwe8Xvd3itbP2msknZqrBhJ9SC4Mf6 Us4nLh6jwbp9K0Eer7BKiuA6R9+BzyUuUwCDagpqG3bvEKOsk5OGgkr9zJFdwv0mrm 1Dq/WQ6zkMCRAiZbXaSt3DKovX2GU5Urpr8nIBV8= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxDLTBgOgudP; Thu, 23 Jul 2020 16:19:32 +0200 (CEST) Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 23 Jul 2020 16:19:32 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Thu, 23 Jul 2020 16:19:32 +0200 From: "Scharf, Michael" To: Michael Tuexen CC: "tcpm@ietf.org" , tcpm-chairs Thread-Topic: IETF 108 agenda for TCPM - second draft Thread-Index: AdZg+c6IAxFvnmxCReiPcE3M26pvbP//4JMA///cupA= Date: Thu, 23 Jul 2020 14:19:30 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DCC52BE@rznt8114.rznt.rzdir.fht-esslingen.de> References: <6EC6417807D9754DA64F3087E2E2E03E2DCC51F6@rznt8114.rznt.rzdir.fht-esslingen.de> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tcpm] IETF 108 agenda for TCPM - second draft 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, 23 Jul 2020 14:19:38 -0000 Ups. I somehow had in mind that the break was 10min. But, indeed, it is 20m= in. Simple bugfix: I'll present the chair deck faster... Usually we don't need = 15min for discussing the WG status. See the new version at the link. Michael > -----Original Message----- > From: Michael Tuexen > Sent: Thursday, July 23, 2020 4:09 PM > To: Scharf, Michael > Cc: tcpm@ietf.org; tcpm-chairs > Subject: Re: IETF 108 agenda for TCPM - second draft >=20 > > On 23. Jul 2020, at 16:02, Scharf, Michael esslingen.de> wrote: > > > > I have added two further, short presentations: > The first part is 5 minutes over time, exactly the rime where meetecho wi= ll > kill the session... >=20 > Best regards > Michael > > > > https://datatracker.ietf.org/doc/agenda-108-tcpm/ > > > > Michael From nobody Thu Jul 23 07:41:18 2020 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 E0F303A0863 for ; Thu, 23 Jul 2020 07:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 cADkhTaYIgoI for ; Thu, 23 Jul 2020 07:41:15 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 EE2863A085B for ; Thu, 23 Jul 2020 07:41:14 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 06NEXBaj036205; Thu, 23 Jul 2020 07:40:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : date : from : to : cc : subject : message-id : references : in-reply-to; s=20180706; bh=DRjXdz4T45L9Va1zZLivj9eegQFNOodJx2etofl2yFg=; b=GBIvjX6bKQY/s1e+rM2pTFvW2hGzkFgrNJi7bBsbVeG1I0C7RvQa61lS1Bv9ktLaPyP6 Vh0Zsr2PFo+CBlsSgCamDfJLfw+akvCXkyQ2D9BgMypb6QF6gnhzRYEZSYqRC7VtK1YO +0rF/27JJTe3fUFA23f7gTm7dqOKMcfwQ/7AzYE97hXr24VFaV3PRPN52mXzlKoXvdLY t7DqmU8sKgRwhDjE1jJk4nMrqTlXcHERYzkbrXhPK4lRezIsYC2hFxQqd0aQ6BqJD3RL yXw7M9jjt/kb+nn7TKmHnP1lpcmQ/5uk/fVel39eIcqvOUYKvEY+q4bwjlxrSbA8zKJ2 bg== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 32c02vyj21-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 23 Jul 2020 07:40:59 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QDX002O6FGBUOC0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 23 Jul 2020 07:40:59 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QDX00O00FEOCZ00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 23 Jul 2020 07:40:59 -0700 (PDT) X-Va-A: X-Va-T-CD: 3beaf764f461a8ab0294914a8b578f03 X-Va-E-CD: dbb4aa9d0c53e8100e25dcf92570366e X-Va-R-CD: 8e3f0004dc05f9a4784d4291b529a402 X-Va-CD: 0 X-Va-ID: 07fcbd36-228c-44c1-882d-314d4176bb76 X-V-A: X-V-T-CD: 3beaf764f461a8ab0294914a8b578f03 X-V-E-CD: dbb4aa9d0c53e8100e25dcf92570366e X-V-R-CD: 8e3f0004dc05f9a4784d4291b529a402 X-V-CD: 0 X-V-ID: fddcacef-de2b-425e-b82c-3fce2f6bd54a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-23_06:2020-07-23, 2020-07-23 signatures=0 MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from localhost ([17.232.165.97]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QDX002V8FGAMP30@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Thu, 23 Jul 2020 07:40:59 -0700 (PDT) Date: Thu, 23 Jul 2020 07:40:58 -0700 From: Christoph Paasch To: Kangjiao Cc: Yoshifumi Nishida , "tcpm@ietf.org Extensions" , Liangqiandeng Message-id: <20200723144058.GQ73500@MacBook-Pro-64.local> References: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9A9BC@dggemm534-mbs.china.huawei.com> <213AD4B1-4F88-4389-93CE-242916C06DC8@apple.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5C9AA60@dggemm534-mbs.china.huawei.com> In-reply-to: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9AA60@dggemm534-mbs.china.huawei.com> User-Agent: Mutt/1.12.2 (2019-09-21) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-23_06:2020-07-23, 2020-07-23 signatures=0 Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 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, 23 Jul 2020 14:41:17 -0000 On 07/23/20 - 04:38, Kangjiao wrote: > Hi Christoph, > > From my perspective, I think following are two different requirements: > > 1. Making all the traffic towards S2 (for this case, MP_PRIO may be enough) > > 2. Making traffic only from to the destination IP_S2, which means diverting traffic that should be scheduled to to one subflow belonging to the target network interface (it is "on-demand scheduling", for this case, MP_PRIO is not enough) What is the use-case for such a scheme? I don't see how a multipath scheduler could assign the traffic that "would" have been sent to to a different subflow. Because for that he would need to know what *would* have been sent on which he can only know once he actually sends traffic on that subflow as that will be driving the congestion-window which will allow to send more (or less) traffic on . Christoph > > What do you think? > > Sincerely > Jiao > > -----Original Message----- > From: Christoph Paasch [mailto:cpaasch@apple.com] > Sent: Thursday, July 23, 2020 11:11 AM > To: Kangjiao > Cc: Yoshifumi Nishida ; tcpm@ietf.org Extensions ; Liangqiandeng > Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 > > Hello, > > > On Jul 22, 2020, at 7:01 PM, Kangjiao wrote: > > > > Hi Christoph and Yoshi, > > > > If I understand right, you both point to the same question whether reusing the MP_PRIO can finish accurate data scheduling for server. I think MP_PRIO may be not enough even if setting all the "non-target" subflows to backup ones. I can give a scenario: > > > > Six subflows have been established between client and server that are , , , , and . The client has IP_C1 and IP_C2. The server has IP_S1, IP_S2 and IP_S3. > > > > Server tool detects that KPI of IP_S2 is better now so the server wants to switch data traffic from to the destination IP_S2. If we set as "backup", it is not guaranteed that all the load over can be diverted to IP_S2 because of the ongoing suflows towards IP_S3. > > But we could simply also set ans as backup as well, no? > > Now, all the traffic will be steered towards S2. > > Christoph > > > > > > So I think MP_PRIO can reduce the chance of data transmission on a specific subflow but it cannot convey the info of target network interface from server to client. > > > > Thanks > > Jiao > > > > -----Original Message----- > > From: Christoph Paasch [mailto:cpaasch@apple.com] > > Sent: Wednesday, July 22, 2020 12:00 AM > > To: Kangjiao > > Cc: Yoshifumi Nishida ; tcpm@ietf.org Extensions > > ; Liangqiandeng > > Subject: Re: [tcpm] comments on > > draft-kang-tcpm-accurate-data-scheduling-by-server-00 > > > > Hello, > > > > as an overall comment, I agree that one of the difficulties around multipath is how the hosts can communicate to the peers the desired scheduling mechanisms. Currently there is no reliable way besides backup-bits which is a "hard" switch. However, often scheduling is much more fine-grained as shown in a number of the schedulers described in https://tools.ietf.org/html/draft-bonaventure-iccrg-schedulers-00. > > > > It's a bit similar to TCP which can't pick the peer's congestion-control and for example if one wants the peer to use a background-CC the host needs to resort to tuning the receive-window a la draft-bagnulo-iccrg-rledbat-00. > > > > So, having a way to communicate the scheduling "requirements" to the peer (and let the peer match these requirements with its local policies), would be good! > > > > > > One more comment inline: > > > >> On 07/20/20 - 03:54, Kangjiao wrote: > >> Hi Yoshi, > >> > >> Thanks for your suggestions. We clarify the issues as below: > >> > >> 1: One thing I'm not very clear is why we cannot use MP_PRIO for the > >> use cases described in the draft. I believe the draft should describe > >> the cases where existing features cannot fulfill the requirements > >> more specifically. > >> > >> KJ: The new MP_Navigation Option is used for the server to indicate > >> destination network interface to client for which server wants to use > >> for traffic switching. For my understanding, MP_PRIO is used to > >> signal a change in priority of subflows to the peer. In application, > >> MP_PRIO can reduce the chance of data transmission on a specific > >> subflow but it cannot tell its peer which network interface is the destination from server side. > >> For example, if there are multiple subflows with high priority from > >> difference network interfaces, client receiving MP_PRIO does not know > >> which is the target one. > > > > For this particular scenario the server could send the MP_PRIO with backup-bit set on all subflows that the client should not use. Thus implicitly the high-priority network-interfaces can then be used by the client, right? > > > > > > Christoph > > > >> 2: Clients also have their own constraints. (e.g. policy or routing) > >> So, even though servers send a navigation request, they might not > >> follow it. I think this point should be clarified. > >> > >> KJ: If the mechanism of accurate-data-scheduling-by-server is > >> deployed, the principle is that the server takes precedence. > >> > >> 3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1? > >> > >> KJ: For the protocol design, the definition of ’r’, ‘E’ and ’B’ are > >> as > >> following: Flag ‘r’: reserved for future usage. Flag ‘E’: exists to > >> provide reliability for this option (like that in ”ADD_ADDR”). Flag ’B’: > >> indicates whether the subflow over which the option is received is a > >> backup one (that is compatiable with the value by MP_PRIO). > >> > >> But we are thinking whether these fields are necessary and should be > >> set as mandatory. > >> > >> Sincerely, Jiao From: tcpm [mailto:tcpm-bounces@ietf.org] On Behalf > >> Of Yoshifumi Nishida Sent: Sunday, July 19, 2020 7:26 PM To: > >> tcpm@ietf.org Extensions Subject: [tcpm] comments on > >> draft-kang-tcpm-accurate-data-scheduling-by-server-00 > >> > >> Hi, I've read draft-kang-tcpm-accurate-data-scheduling-by-server-00. > >> I think this is an interesting topic for mptcp, but I think it would > >> be better to clarify the following points. > >> > >> 1: One thing I'm not very clear is why we cannot use MP_PRIO for the > >> use cases described in the draft. I believe the draft should describe > >> the cases where existing features cannot fulfill the requirements > >> more specifically. > >> > >> 2: Clients also have their own constraints. (e.g. policy or routing) > >> So, even though servers send a navigation request, they might not > >> follow it. I think this point should be clarified. > >> > >> 3: What's the meaning of 'r', 'E', 'B' flags in Section 4.1? > >> > >> Thanks, -- Yoshi > > > >> _______________________________________________ > >> tcpm mailing list > >> tcpm@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcpm > > From nobody Fri Jul 24 07:17:19 2020 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 006703A094B for ; Fri, 24 Jul 2020 07:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.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 U4DCON6twNS2 for ; Fri, 24 Jul 2020 07:17:14 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEC23A095D for ; Fri, 24 Jul 2020 07:17:10 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id j11so10138768ljo.7 for ; Fri, 24 Jul 2020 07:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=My7eRWEQkkNYhVcU0HFKs/GxEbJ4qNj3dtCdcGaL1OE=; b=vQXBfojOmXcEeyncT/hhssyyVhYHBV5PqbvoG2ZYLwyzo8MgZwV4TlXPqgcWkvQjHg IzcUyJYzgOc9Huh5sbyKCUsbzfn5JdPTYuyqaYq7ZVBJFoyNwoe2xAXyoYk+LGyymKx7 idA1SFNjWVXjo9lqDyIBwsTB03pmdIRaxqb1c9hagULZmhJuJLmA/Icy/gCt8BYyi02Q ol0AcfBnHl8gIsV/hVWxSzFqgcNpqyA+S3v3kUKPGnXdt6dcaeJ5J758W1hnmHykujWc 4TkYKu03RSjt+sejzQHSwLbNXGQWHV9I4ttk1gOnJ1lgrs6ckT1ytCcg9+U1TPdEuqp9 U4MA== 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=My7eRWEQkkNYhVcU0HFKs/GxEbJ4qNj3dtCdcGaL1OE=; b=QqTyfs1MuK+KjVhTL2E6RVDaYgQpBBFcmrUa51j2Ye8bYB7Y+Hh9gqQMC3J/Yp9g1E dT5s+kcGCDuS4rY/05YCnlgRVy4UxSYqpUcHThMol3I8joI0gBCfLLZAmqSvJTPhO0kU I/U7mTLGPxaoT9LWfV+RKQ3bQorHCkb/F93RwfWUrmQ3IZwhpRkJyZFQKWy/7zJjc9k6 LXp+WbXbtWLc9+oB0coAyO0TcuDT8FdgthfXNHvTdIFlfU79daGkofnqv6eI4XHuBn+m RpOyNOIX4QxDVhWHs4pv8L8yV2STDp1LhKtbX6PpC7rSFPnyR82J+b3Qwe1kBOwgEVuT BPuQ== X-Gm-Message-State: AOAM530gohHL4cEnK0KkHittDLVNLTJVuSC8KXrSvko+ZTo0jirdUkmC 1+rTj8WhZ453IHl4zPmxW2sLeaQqzbq2nFyC9CFyKkgTSyuDTGqH9AHcYy1WBIIs29CfPAgMCAe 7OUbI8rxgUQxt X-Google-Smtp-Source: ABdhPJxNWH9Ot7B4B6Itf28sHgsmx3iOGBVoeGxCQduI4InQB67OU+DPS30oLwOVqHZ63U/71iTJyaMjC+US9Zj06Vg= X-Received: by 2002:a2e:9591:: with SMTP id w17mr4627274ljh.390.1595600228726; Fri, 24 Jul 2020 07:17:08 -0700 (PDT) MIME-Version: 1.0 References: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9A9BC@dggemm534-mbs.china.huawei.com> <213AD4B1-4F88-4389-93CE-242916C06DC8@apple.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5C9AA60@dggemm534-mbs.china.huawei.com> <20200723144058.GQ73500@MacBook-Pro-64.local> In-Reply-To: <20200723144058.GQ73500@MacBook-Pro-64.local> From: Olivier Bonaventure Date: Fri, 24 Jul 2020 16:16:42 +0200 Message-ID: To: Christoph Paasch Cc: Kangjiao , "tcpm@ietf.org Extensions" , Liangqiandeng Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 14:17:17 -0000 Hello, > > > > From my perspective, I think following are two different requirements: > > > > 1. Making all the traffic towards S2 (for this case, MP_PRIO may be eno= ugh) > > > > 2. Making traffic only from to the destination IP_S2, wh= ich means diverting traffic that should be scheduled to to o= ne subflow belonging to the target network interface (it is "on-demand sche= duling", for this case, MP_PRIO is not enough) > > What is the use-case for such a scheme? Understanding the requirements from the applications would really help in this discussion. This could also serve as input for Multipath QUIC where the middlebox problems that are mentioned in the draft do not exist. > I don't see how a multipath scheduler could assign the traffic that "woul= d" > have been sent to to a different subflow. Because for that he wou= ld > need to know what *would* have been sent on which he can only kno= w > once he actually sends traffic on that subflow as that will be driving th= e > congestion-window which will allow to send more (or less) traffic on . Another point that needs to be taken into account is that when client moves, the network conditions change dynamically and the server view might differ from the wireless conditions on the client. In this case, it is difficult for the server to precisely decide where it wants to receive data. See http://multipath-tcp.org/multimob/ Olivier --=20 Disclaimer: https://www.tessares.net/mail-disclaimer/=20 From nobody Fri Jul 24 13:16:10 2020 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 616923A0B24 for ; Fri, 24 Jul 2020 13:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tenghardt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKT2m_NmiYRo for ; Fri, 24 Jul 2020 13:16:07 -0700 (PDT) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (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 7CB5B3A0B23 for ; Fri, 24 Jul 2020 13:16:07 -0700 (PDT) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 7C7BBAA; Fri, 24 Jul 2020 22:16:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1595621765; bh=pfxcmo4GBx43oXCzpK3PnSb36C9MCdLAKzl6HSneoKo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=bxM7BIePfqlE2ZgeGUGhArIPk2Vp8JwFG0XvWig4716w7g6rfi4AQ3RNVegwO6U3E 021Vy94sYLwJvd+oYKryLVxeODNLX8da2zCw9uEsNgKb17/a2VS2Ja7n6oaW1tyeH3 ZOVl6URFjfwpKdSw7RafZTZg2paBRH1ziHITEtXKvYCSXqb1ST3/n260/GTgl75Syl L3xPW/FE2bQOt4KMARt9GvndcqRZKz77+LQWhNuI6H4lCP30ye34gGDqDENnDjZFlD ctQ3YGKxXUOKvngfsAjTxtuWJ5QF4vkUlmosDpMlQHxYKjrEhJTqKn8Jhe7w2UDo9V WR9LuZvC9qbNQ== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 24 Jul 2020 13:16:05 -0700 From: Theresa Enghardt To: Yuchung Cheng Cc: tcpm IETF list In-Reply-To: References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> <2c0558c37ec99da2b98f73eb5a79d8e6@tenghardt.net> Message-ID: X-Sender: ietf@tenghardt.net User-Agent: Roundcube Webmail/1.3.14 Archived-At: Subject: Re: [tcpm] Review (Re: WGLC for draft-ietf-tcpm-rack-08) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 20:16:09 -0000 Dear Yuchung, Thank you for the reply and for posting a new draft. I read the current version -09 and find that it has greatly improved clarity and readability. This resolves most of my comments. Just one reply and a few additional minor comments: On 2020-07-13 15:06, Yuchung Cheng wrote: > […] The new > subsection 'RACK reordering window adaptation explicitly lists the > rules of 3-dupacks and reordering window. > When the reordering window is zero, RACK will mark the first unacked > packet lost on the first DUPACK. The rule is to hold up until the > third DUPACK (or 3 MSS worth of bytes been sacked). This helps, thanks. Reading the new Section 3.3.2, I'm wondering about the following though: "If the sender has not observed any reordering since the connection was established, then the RACK reordering window SHOULD be zero in either of the following cases: […] 1. After learning that three segments have been delivered out of order (e.g. receiving 3 DUPACKs per [RFC5681]); in turn, this will cause the RACK loss detection logic to trigger fast recovery. 2. During fast recovery or RTO recovery." Does this SHOULD mean that the implementation should set the reordering window to 0 under either of the listed conditions? Because I fail to see how the two listed conditions mean that that "the sender has not observed any reordering". Or SHOULD the sender set the reordering window to 0 if either it hasn't observed any reordering, or one of the listed conditions are true. An alternative (and probably false) way of reading this would be that the SHOULD just means that the sender should expect the reordering window to be 0. But it doesn't seem logical to me to use SHOULD in this way. (This is probably clarified later in the detailed algorithm, but it would be nice to have this phrased clearly in this Section as well.) In Section 3.3.2, I fail to understand or parse the following sentence: The RACK reordering window SHOULD leverage that to adaptively estimate the duration of reordering events, if the receiver uses Duplicate Selective Acknowledgement (DSACK) [RFC2883]. The RACK reordering window SHOULD leverage what? (If "that" refers to the sentence before, SRTT, then the connection to DSACK is not obvious to me. So I think it's good to substitute "that" here.) Nits / Editorial comments: In Section 2.2 and Section 3.3.2., the numbered list goes "1.", "1.", "2.", but should be "1.", "2.", "3.". In Section 4, list item 2. might have an unnecessary "that": "[…] timestamp whose granularity that is finer than 1/4 of the minimum RTT of the connection." Best, Theresa From nobody Fri Jul 24 16:46:34 2020 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 53FCC3A082F for ; Fri, 24 Jul 2020 16:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qhk1YsEMNnaG for ; Fri, 24 Jul 2020 16:46:31 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 D32643A082C for ; Fri, 24 Jul 2020 16:46:30 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id b26so1219313vsa.13 for ; Fri, 24 Jul 2020 16:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ythRF765DPqf60ZnCDs4XvgRxzAjuezDLkyDzdpP5Lk=; b=VxS5Oug0FEL6yHyqC/RVgBL2Q6hN5pOAOZ7904abtqCD9AaXHK1gXhSvL+6G/jd69J /TtVOA415RSD54nYizDcenZilF+GXteU5a19UQNyocI6+dNGu5BYIEEiqh4U4jwItu5C 2HBW/ntamC0SCzYXLuch1BCZpbK7zJ/YwJlLGDdiLzFG5VKGlMine/XNEzgkQvZIU5f0 ukZKtHBXwoKzhWl3sCHQlVX8IYNiMwh/kNhZpk4vypW6TMMSOl+tSCd2glDhs114f2Q+ dVw5byPleLev2DuFOVwD4aXLEEzPlKg0MZyBARlBA+/X2B7NZZZD6oiNFTeuueJQZ3l6 ON0g== 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=ythRF765DPqf60ZnCDs4XvgRxzAjuezDLkyDzdpP5Lk=; b=gV+cpabj8Rl/lscLtDfWgHDrwD7EnsHD0//PFWbMPDu8ln9lfGbuwUGncSJXA7K0C+ cgdLR1nTwYWC/BkT8phjjvleXFxRdxE6C8v1VTH62TfUtMAaIdEZtuSdF0Z7qEqg66Dd fa5cIwo0BkMZT8zi7bsMW32A/XxJV6RnmOggoSCx2yrNzWr8RclfL4wNnPr7QqKhIrGb EDhGcqtQeCz5b6NHJ880nQckd3kvJBFVLkCtce7z1o4lYYjf6BXXZhYP4Mn0Cknxp30n /cY8TZy6MNYMEnK0w9G/oDv9X+MF6H1axSyt9CVLM4npwFEMWptkjTqx9p/VK0qFeXwv oQdg== X-Gm-Message-State: AOAM533G1Xj4tb3TiKjMwn+ac4FeEF2SCXNcQAHoyzlrlu8WjKhbr9Y3 4ffyt9Z7IBgDBVabNhoPaKPbLlHDm8pYNh82vlLGL0VN X-Google-Smtp-Source: ABdhPJwF5T4JOOI73q8MrnEvJnyXrIegtRasSSuhfUTEW4Am+XrO5HgvxViI2Ut7A4uVD9eQFbplNoCLNae0FjggItU= X-Received: by 2002:a67:f87:: with SMTP id 129mr9822104vsp.134.1595634389511; Fri, 24 Jul 2020 16:46:29 -0700 (PDT) MIME-Version: 1.0 References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> <2c0558c37ec99da2b98f73eb5a79d8e6@tenghardt.net> In-Reply-To: From: Yuchung Cheng Date: Fri, 24 Jul 2020 16:45:53 -0700 Message-ID: To: Theresa Enghardt Cc: tcpm IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Review (Re: WGLC for draft-ietf-tcpm-rack-08) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2020 23:46:32 -0000 On Fri, Jul 24, 2020 at 1:16 PM Theresa Enghardt wrote= : > > Dear Yuchung, > > Thank you for the reply and for posting a new draft. > > I read the current version -09 and find that it has greatly improved > clarity and readability. thanks for taking another look! > > This resolves most of my comments. > > Just one reply and a few additional minor comments: > > On 2020-07-13 15:06, Yuchung Cheng wrote: > > > [=E2=80=A6] The new > > subsection 'RACK reordering window adaptation explicitly lists the > > rules of 3-dupacks and reordering window. > > When the reordering window is zero, RACK will mark the first unacked > > packet lost on the first DUPACK. The rule is to hold up until the > > third DUPACK (or 3 MSS worth of bytes been sacked). > > This helps, thanks. > > Reading the new Section 3.3.2, I'm wondering about the following though: > > "If the sender has not observed any reordering since the > connection was established, then the RACK reordering window > SHOULD be zero in either of the following cases: [=E2=80=A6] > > 1. After learning that three segments have been delivered out of > order (e.g. receiving 3 DUPACKs per [RFC5681]); in turn, this > will cause the RACK loss detection logic to trigger fast > recovery. > > 2. During fast recovery or RTO recovery." > > Does this SHOULD mean that the implementation should set the reordering > window to 0 under either of the listed conditions? yes > Because I fail to see how the two listed conditions mean that that "the > sender has not observed any reordering". > Or SHOULD the sender set the reordering window to 0 if either it hasn't > observed any reordering, or one of the listed conditions are true. agree this can be better clarified. do you think the following is more clea= r: 1. The reordering window SHOULD be zero if no reordering has been observed on the connection so far, plus either (a) three segments have been delivered out of order since the last recovery or (b) the sender is already in fast or RTO recovery. Otherwise the reordering window SHOULD start from a small fraction of th= e round trip time, or zero if no round trip time estimate is available. 2. The RACK reordering window SHOULD adaptively increase if the sender receives the Duplicate Selective Acknowledgement (DSACK) [RFC28= 83], suggesting the window is too small which causes spurious retransmissio= n. 3. The RACK reordering window MUST be bounded and this bound SHOULD be SRTT. (The text after this needs to be adjusted for the new bullet numbers). > > An alternative (and probably false) way of reading this would be that > the SHOULD just means that the sender should expect the reordering > window to be 0. > But it doesn't seem logical to me to use SHOULD in this way. > > (This is probably clarified later in the detailed algorithm, but it > would be nice to have this phrased clearly in this Section as well.) > > > In Section 3.3.2, I fail to understand or parse the following sentence: > The RACK reordering window SHOULD leverage that to > adaptively > estimate the duration of reordering events, if the receiver > uses > Duplicate Selective Acknowledgement (DSACK) [RFC2883]. > > The RACK reordering window SHOULD leverage what? (If "that" refers to > the sentence before, SRTT, then the connection to DSACK is not obvious > to me. So I think it's good to substitute "that" here.) sorry that=3DDSACK. sentence got cut out accidentally. Does the proposed new text in my earlier comment look better? > > Nits / Editorial comments: > > In Section 2.2 and Section 3.3.2., the numbered list goes "1.", "1.", > "2.", but should be "1.", "2.", "3.". will fix > > In Section 4, list item 2. might have an unnecessary "that": > "[=E2=80=A6] timestamp whose granularity that is finer than 1/4 of the mi= nimum > RTT of the connection." will fix. > > > Best, > Theresa From nobody Fri Jul 24 17:10:09 2020 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 570FD3A0C9F for ; Fri, 24 Jul 2020 17:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tenghardt.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaGO26UwfZR5 for ; Fri, 24 Jul 2020 17:10:05 -0700 (PDT) Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (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 B77683A0878 for ; Fri, 24 Jul 2020 17:10:05 -0700 (PDT) Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 0F963AA; Sat, 25 Jul 2020 02:10:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1595635804; bh=pf+itzR30J3D6KarsIbxIJYFsKK16HmoQjqRLA3S8/o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BbSoYLHjsQBAdes1MaWn48i1ZgFsuZi1hknOQLwmpxNL5NQ5mJ6i/D7Fx5ZUra1nk kIw+0lEtf/8Y3G9WTxjqdgSW6S/1Hhqn6b7qgFLoo0DWzm8WaaSYS/bKhZ/dBP3EI3 4q4lP6QVEN3toqR2XnPGUm1UqfuZTsCUFSRpDgaDPYwrTgAdnceTXu8bj0Pg7/U9BI G9qLoBrLQGF4pdEyNKUQ9836nxabm0Ra72M0RbkkjqwVK4U+tSD8/w8MVlgoCjV7h/ mcXFQk5Vk2s+GDBMIMftgo8l9OdkIRnWjX9yLd5tDvmgDlu3QTbZUs8svpm9rXUZ9L MOtIQ4z1gcidw== MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Fri, 24 Jul 2020 17:10:04 -0700 From: Theresa Enghardt To: Yuchung Cheng Cc: tcpm IETF list In-Reply-To: References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> <2c0558c37ec99da2b98f73eb5a79d8e6@tenghardt.net> Message-ID: <34f124c361b7c3e6c20f543b604f67c3@tenghardt.net> X-Sender: ietf@tenghardt.net User-Agent: Roundcube Webmail/1.3.14 Archived-At: Subject: Re: [tcpm] Review (Re: WGLC for draft-ietf-tcpm-rack-08) 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, 25 Jul 2020 00:10:07 -0000 Hi Yuchung, See inline: On 2020-07-24 16:45, Yuchung Cheng wrote: >> On 2020-07-13 15:06, Yuchung Cheng wrote: >> […] >> Reading the new Section 3.3.2, I'm wondering about the following >> though: >> >> "If the sender has not observed any reordering since the >> connection was established, then the RACK reordering window >> SHOULD be zero in either of the following cases: […] >> >> 1. After learning that three segments have been delivered out of >> order (e.g. receiving 3 DUPACKs per [RFC5681]); in turn, this >> will cause the RACK loss detection logic to trigger fast >> recovery. >> >> 2. During fast recovery or RTO recovery." >> >> Does this SHOULD mean that the implementation should set the >> reordering >> window to 0 under either of the listed conditions? > yes > >> Because I fail to see how the two listed conditions mean that that >> "the >> sender has not observed any reordering". >> Or SHOULD the sender set the reordering window to 0 if either it >> hasn't >> observed any reordering, or one of the listed conditions are true. > > agree this can be better clarified. do you think the following is more > clear: > > 1. The reordering window SHOULD be zero if no reordering has been > observed on the connection so far, plus either (a) > three segments have been delivered out of order since the last > recovery or (b) the sender is already in fast or RTO recovery. > Otherwise the reordering window SHOULD start from a small fraction of > the > round trip time, or zero if no round trip time estimate is available. > > 2. The RACK reordering window SHOULD adaptively increase if the > sender receives the Duplicate Selective Acknowledgement (DSACK) > [RFC2883], > suggesting the window is too small which causes spurious > retransmission. > > 3. The RACK reordering window MUST be bounded and this bound SHOULD > be SRTT. > > (The text after this needs to be adjusted for the new bullet numbers). This is much clearer, thanks! Additionally, I suggest to change "The reordering window SHOULD be zero" to "The reordering window SHOULD be set to zero", or to prefix the entire list with a sentence like "More specifically, the sender sets the reordering window as follows:". >> In Section 3.3.2, I fail to understand or parse the following >> sentence: >> The RACK reordering window SHOULD leverage that to >> adaptively >> estimate the duration of reordering events, if the receiver >> uses >> Duplicate Selective Acknowledgement (DSACK) [RFC2883]. >> >> The RACK reordering window SHOULD leverage what? (If "that" refers to >> the sentence before, SRTT, then the connection to DSACK is not obvious >> to me. So I think it's good to substitute "that" here.) > sorry that=DSACK. sentence got cut out accidentally. Does the proposed > new text in my earlier comment look better? Yes, this is clearer to me now. I would suggest the following slight changes to this sentence though: OLD: "The RACK reordering window SHOULD adaptively increase if the sender receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], suggesting the window is too small which causes spurious retransmission." NEW: "The RACK reordering window SHOULD adaptively increase if the sender receives a Duplicate Selective Acknowledgement (DSACK) [RFC2883], suggesting the window is too small, which causes spurious retransmission." Best, Theresa From nobody Sat Jul 25 08:18:46 2020 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 880FC3A0AA0 for ; Sat, 25 Jul 2020 08:18:44 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ph6w97z7wdqo for ; Sat, 25 Jul 2020 08:18:42 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A921F3A0A83 for ; Sat, 25 Jul 2020 08:18:42 -0700 (PDT) Received: from lhreml720-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A6CB7E14F3A01276F11D for ; Sat, 25 Jul 2020 16:18:39 +0100 (IST) Received: from lhreml720-chm.china.huawei.com (10.201.108.71) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Sat, 25 Jul 2020 16:18:39 +0100 Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by lhreml720-chm.china.huawei.com (10.201.108.71) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Sat, 25 Jul 2020 16:18:39 +0100 Received: from DGGEMM534-MBS.china.huawei.com ([169.254.7.122]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0487.000; Sat, 25 Jul 2020 23:18:29 +0800 From: Kangjiao To: Olivier Bonaventure , Christoph Paasch CC: "tcpm@ietf.org Extensions" , Liangqiandeng Thread-Topic: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 Thread-Index: AQHWXb+HJHOpbU0oSkKL2jMMYvRPV6kP1fbAgAHYVoCAAryHoP//kUKAgACdjyCAACNOAIABi44AgAImzSA= Date: Sat, 25 Jul 2020 15:18:28 +0000 Message-ID: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9DC89@dggemm534-mbs.china.huawei.com> References: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9A9BC@dggemm534-mbs.china.huawei.com> <213AD4B1-4F88-4389-93CE-242916C06DC8@apple.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5C9AA60@dggemm534-mbs.china.huawei.com> <20200723144058.GQ73500@MacBook-Pro-64.local> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.122.183] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 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, 25 Jul 2020 15:18:45 -0000 SGksDQoNClRoZSBzY2VuYXJpb3MgaW4gdGhpcyBkcmFmdCBhcmUgbm90IGZvciB0cmFmZmljIGhh bmRvdmVyIHdoZW4gZW5jb3VudGVyaW5nIG5ldHdvcmsgZmFpbHVyZS4gSXQgaXMgYXBwbGllZCB3 aGVuIG9uZSBwZWVyIGhhcyBhbiBleHBsaWNpdCBwbGFuIG9uIHRyYWZmaWMgc3dpdGNoaW5nLiBG b3IgZXhhbXBsZSwgZm9yIG5ldHdvcmsgbWlncmF0aW9uIG9yIGV4cGFuc2lvbiBvbiBzZXJ2ZXIs IG9wZXJhdG9yIHdhbnRzIHRvIGFkanVzdCB0aGUgdHJhZmZpYyBvbiB0aGVzZSBuZXR3b3JrcyBp biBhZHZhbmNlLiBUaGlzIGlzIGFuIGFjdHVhbCBjYXNlLg0KDQpXZSB0aGluayBwYWNrZXQgc2No ZWR1bGVyIGtub3dzIG9uIHdoaWNoIHN1YmZsb3cgdGhlIG5leHQgcGFja2V0IHdpbGwgYmUgc2Vu dC4gU28gaXQgbWF5IGJlIGEgZ29vZCBjaG9pY2UgdG8gZGVwbG95IHRoZSBsb2dpYyBvZiBhY2N1 cmF0ZSB0cmFmZmljIHN3aXRjaGluZyBvbiB0aGlzIGNvbXBvbmVudC4NCg0KU2luY2VyZWx5LA0K Smlhbw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT2xpdmllciBCb25hdmVu dHVyZSBbbWFpbHRvOm9saXZpZXIuYm9uYXZlbnR1cmVAdGVzc2FyZXMubmV0XSANClNlbnQ6IEZy aWRheSwgSnVseSAyNCwgMjAyMCAxMDoxNyBQTQ0KVG86IENocmlzdG9waCBQYWFzY2ggPGNwYWFz Y2g9NDBhcHBsZS5jb21AZG1hcmMuaWV0Zi5vcmc+DQpDYzogS2FuZ2ppYW8gPGthbmdqaWFvQGh1 YXdlaS5jb20+OyB0Y3BtQGlldGYub3JnIEV4dGVuc2lvbnMgPHRjcG1AaWV0Zi5vcmc+OyBMaWFu Z3FpYW5kZW5nIDxsaWFuZ3FpYW5kZW5nQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBSZTogW3RjcG1d IGNvbW1lbnRzIG9uIGRyYWZ0LWthbmctdGNwbS1hY2N1cmF0ZS1kYXRhLXNjaGVkdWxpbmctYnkt c2VydmVyLTAwDQoNCkhlbGxvLA0KDQoNCj4gPg0KPiA+IEZyb20gbXkgcGVyc3BlY3RpdmUsIEkg dGhpbmsgZm9sbG93aW5nIGFyZSB0d28gZGlmZmVyZW50IHJlcXVpcmVtZW50czoNCj4gPg0KPiA+ IDEuIE1ha2luZyBhbGwgdGhlIHRyYWZmaWMgdG93YXJkcyBTMiAoZm9yIHRoaXMgY2FzZSwgTVBf UFJJTyBtYXkgYmUgDQo+ID4gZW5vdWdoKQ0KPiA+DQo+ID4gMi4gTWFraW5nIHRyYWZmaWMgb25s eSBmcm9tIDxJUF9DMSwgSVBfUzE+IHRvIHRoZSBkZXN0aW5hdGlvbiBJUF9TMiwgDQo+ID4gd2hp Y2ggbWVhbnMgZGl2ZXJ0aW5nIHRyYWZmaWMgdGhhdCBzaG91bGQgYmUgc2NoZWR1bGVkIHRvIDxJ UF9DMSwgDQo+ID4gSVBfUzE+IHRvIG9uZSBzdWJmbG93IGJlbG9uZ2luZyB0byB0aGUgdGFyZ2V0 IG5ldHdvcmsgaW50ZXJmYWNlIChpdCANCj4gPiBpcyAib24tZGVtYW5kIHNjaGVkdWxpbmciLCBm b3IgdGhpcyBjYXNlLCBNUF9QUklPIGlzIG5vdCBlbm91Z2gpDQo+DQo+IFdoYXQgaXMgdGhlIHVz ZS1jYXNlIGZvciBzdWNoIGEgc2NoZW1lPw0KDQpVbmRlcnN0YW5kaW5nIHRoZSByZXF1aXJlbWVu dHMgZnJvbSB0aGUgYXBwbGljYXRpb25zIHdvdWxkIHJlYWxseSBoZWxwIGluIHRoaXMgZGlzY3Vz c2lvbi4gVGhpcyBjb3VsZCBhbHNvIHNlcnZlIGFzIGlucHV0IGZvciBNdWx0aXBhdGggUVVJQyB3 aGVyZSB0aGUgbWlkZGxlYm94IHByb2JsZW1zIHRoYXQgYXJlIG1lbnRpb25lZCBpbiB0aGUgZHJh ZnQgZG8gbm90IGV4aXN0Lg0KDQo+IEkgZG9uJ3Qgc2VlIGhvdyBhIG11bHRpcGF0aCBzY2hlZHVs ZXIgY291bGQgYXNzaWduIHRoZSB0cmFmZmljIHRoYXQgIndvdWxkIg0KPiBoYXZlIGJlZW4gc2Vu dCB0byA8QzEsUzE+IHRvIGEgZGlmZmVyZW50IHN1YmZsb3cuIEJlY2F1c2UgZm9yIHRoYXQgaGUg DQo+IHdvdWxkIG5lZWQgdG8ga25vdyB3aGF0ICp3b3VsZCogaGF2ZSBiZWVuIHNlbnQgb24gPEMx LFMxPiB3aGljaCBoZSBjYW4gDQo+IG9ubHkga25vdyBvbmNlIGhlIGFjdHVhbGx5IHNlbmRzIHRy YWZmaWMgb24gdGhhdCBzdWJmbG93IGFzIHRoYXQgd2lsbCANCj4gYmUgZHJpdmluZyB0aGUgY29u Z2VzdGlvbi13aW5kb3cgd2hpY2ggd2lsbCBhbGxvdyB0byBzZW5kIG1vcmUgKG9yIGxlc3MpIHRy YWZmaWMgb24gPEMxLFMxPi4NCg0KQW5vdGhlciBwb2ludCB0aGF0IG5lZWRzIHRvIGJlIHRha2Vu IGludG8gYWNjb3VudCBpcyB0aGF0IHdoZW4gY2xpZW50IG1vdmVzLCB0aGUgbmV0d29yayBjb25k aXRpb25zIGNoYW5nZSBkeW5hbWljYWxseSBhbmQgdGhlIHNlcnZlciB2aWV3IG1pZ2h0IGRpZmZl ciBmcm9tIHRoZSB3aXJlbGVzcyBjb25kaXRpb25zIG9uIHRoZSBjbGllbnQuIEluIHRoaXMgY2Fz ZSwgaXQgaXMgZGlmZmljdWx0IGZvciB0aGUgc2VydmVyIHRvIHByZWNpc2VseSBkZWNpZGUgd2hl cmUgaXQgd2FudHMgdG8gcmVjZWl2ZSBkYXRhLiBTZWUgaHR0cDovL211bHRpcGF0aC10Y3Aub3Jn L211bHRpbW9iLw0KDQpPbGl2aWVyDQoNCi0tIA0KDQoNCkRpc2NsYWltZXI6IGh0dHBzOi8vd3d3 LnRlc3NhcmVzLm5ldC9tYWlsLWRpc2NsYWltZXIvDQo8aHR0cHM6Ly93d3cudGVzc2FyZXMubmV0 L21haWwtZGlzY2xhaW1lci8+DQoNCg0K From nobody Sun Jul 26 02:34:06 2020 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 5EDDD3A0CF9; Sun, 26 Jul 2020 02:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O14Vf5DFGTtP; Sun, 26 Jul 2020 02:34:02 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7533A0CF8; Sun, 26 Jul 2020 02:34:02 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 80AA425A13; Sun, 26 Jul 2020 11:34:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1595756040; bh=7lLEyeXQguN9fuCCKAyfGLw8Y1oAkV/dXFKQfDHM8po=; h=From:To:CC:Subject:Date:From; b=GWzTnzKbpSL4Wt3aHZa+jNJuF/jkQ/NECAsAoQFXVA8ydKFN2t6SSS8hcALGMvdLQ jHAbY1vSVzEM27h0vni/RbCXEuGjDxDda/TZJvDCYQIXsrpmvJVcm4JX+mcRv+eg/Y 7a+Egl3UMgZap1UkzcZRtqskumFYBg1Fxm1RTGIU= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYjH39j12dRm; Sun, 26 Jul 2020 11:33:59 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Sun, 26 Jul 2020 11:33:59 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sun, 26 Jul 2020 11:33:59 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: tcpm-chairs Thread-Topic: Notetaker Thread-Index: AdZjL7p1B91SVlCVSSeeE38ZPaJtTA== Date: Sun, 26 Jul 2020 09:33:58 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DCCF044@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Notetaker X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 09:34:05 -0000 As usually, we need a notetaker and (possibly) a Jabber scribe for the meet= ing tomorrow. Does somebody volunteer? Thanks Michael From nobody Sun Jul 26 10:12:34 2020 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 9BF963A1013 for ; Sun, 26 Jul 2020 10:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cScxEIXg_gQ5 for ; Sun, 26 Jul 2020 10:12:31 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (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 37E453A1012 for ; Sun, 26 Jul 2020 10:12:31 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id 66so3262569vka.13 for ; Sun, 26 Jul 2020 10:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ICpmwbB95YON5v3axq6jaY4Ramh520ECl17RUrchUdI=; b=ZfEZ1Y3Qa1rkyBlCxVAscSkDCfpTNkawmlrrfc5FiKfddeNVWqFd3cVwR6W94MqWgx lgqmDyEW8FcSY9GSoXPz0qCokDnRV3dEm0DfeL2YDeTSMVJJyw4+9vplkijoRVA0uOFv YdR/PvYQWI4JVnAmHhR9WiojaNqVMvdnwCIpPlwLWFZHc++meSLoSTDL27HYRUalRShz BjZNar18QTNF9TkpIGEBgb/juHEpIpaO+M9HQ1HqYsO3mrGkgarUlfcDZyX73MZr4zSr pvsxg9gvIDCahlTuRf6JGsKLZQEN1PfeTbm3sOJgVymrN1frMtLDISdYkJo2Lx6sTKaE +u/g== 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=ICpmwbB95YON5v3axq6jaY4Ramh520ECl17RUrchUdI=; b=h7N9AzzYSwBam7oyblGO8Nd50aGBySrbBYhlFeWkvFNz17tzUz6xVRUoRXuhge2lha b7bINivCn5c6XSOfpUhvoyot4QEfykltNTs5DnclnrountPLuldCO8r77azweyksQaht Gb/P2pi0bZ679TkxwkjxPL5NGDtZJkKm4agAllL42QuUhObGSmT8NwokC6CozQi3zhl/ ePzLnxA6n5gMVQSrnuF3z+LJ+jkg2AARWbXN5TA9TuIoeErY6fGvhxbfaIsfQ5Vg+ICK zxIUmUdOljGy9RSfJ5TCYjSsi1P3KqD8XxjZRcFck8Bk+ZT2J3YEXw4n1GYMNVDLE7px HwCg== X-Gm-Message-State: AOAM532uuLiZEJP5u78Miprnj0Z8gic4M+C1yZJ5N+5sr5QXE5bNX0AB inCTwXJnRVZtX3mQkaWKAhQPmgDMSSnLYOqaw6A9lW2p X-Google-Smtp-Source: ABdhPJxBmCmPUtLKbLxBwBrkdAcAZccfgkaWORg1+fTNIAkuVa2H/wBYI2NNpTePQ+zezkCtut8X9KsGZ6QgAnRrhVA= X-Received: by 2002:a1f:3d47:: with SMTP id k68mr14220847vka.68.1595783549984; Sun, 26 Jul 2020 10:12:29 -0700 (PDT) MIME-Version: 1.0 References: <3D4D034B-7A72-4313-8FB6-CB689A167E91@fh-muenster.de> <2c0558c37ec99da2b98f73eb5a79d8e6@tenghardt.net> <34f124c361b7c3e6c20f543b604f67c3@tenghardt.net> In-Reply-To: <34f124c361b7c3e6c20f543b604f67c3@tenghardt.net> From: Yuchung Cheng Date: Sun, 26 Jul 2020 10:11:53 -0700 Message-ID: To: Theresa Enghardt Cc: tcpm IETF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Review (Re: WGLC for draft-ietf-tcpm-rack-08) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2020 17:12:33 -0000 On Fri, Jul 24, 2020 at 5:10 PM Theresa Enghardt wrote= : > > Hi Yuchung, > > See inline: > > On 2020-07-24 16:45, Yuchung Cheng wrote: > > >> On 2020-07-13 15:06, Yuchung Cheng wrote: > >> [=E2=80=A6] > >> Reading the new Section 3.3.2, I'm wondering about the following > >> though: > >> > >> "If the sender has not observed any reordering since the > >> connection was established, then the RACK reordering window > >> SHOULD be zero in either of the following cases: [=E2=80=A6] > >> > >> 1. After learning that three segments have been delivered out of > >> order (e.g. receiving 3 DUPACKs per [RFC5681]); in turn, this > >> will cause the RACK loss detection logic to trigger fast > >> recovery. > >> > >> 2. During fast recovery or RTO recovery." > >> > >> Does this SHOULD mean that the implementation should set the > >> reordering > >> window to 0 under either of the listed conditions? > > yes > > > >> Because I fail to see how the two listed conditions mean that that > >> "the > >> sender has not observed any reordering". > >> Or SHOULD the sender set the reordering window to 0 if either it > >> hasn't > >> observed any reordering, or one of the listed conditions are true. > > > > agree this can be better clarified. do you think the following is more > > clear: > > > > 1. The reordering window SHOULD be zero if no reordering has been > > observed on the connection so far, plus either (a) > > three segments have been delivered out of order since the last > > recovery or (b) the sender is already in fast or RTO recovery. > > Otherwise the reordering window SHOULD start from a small fraction of > > the > > round trip time, or zero if no round trip time estimate is available. > > > > 2. The RACK reordering window SHOULD adaptively increase if the > > sender receives the Duplicate Selective Acknowledgement (DSACK) > > [RFC2883], > > suggesting the window is too small which causes spurious > > retransmission. > > > > 3. The RACK reordering window MUST be bounded and this bound SHOULD > > be SRTT. > > > > (The text after this needs to be adjusted for the new bullet numbers). > > This is much clearer, thanks! > > Additionally, I suggest to change "The reordering window SHOULD be zero" > to "The reordering window SHOULD be set to zero", or to prefix the > entire list with a sentence like "More specifically, the sender sets the > reordering window as follows:". > > > >> In Section 3.3.2, I fail to understand or parse the following > >> sentence: > >> The RACK reordering window SHOULD leverage that to > >> adaptively > >> estimate the duration of reordering events, if the receiver > >> uses > >> Duplicate Selective Acknowledgement (DSACK) [RFC2883]. > >> > >> The RACK reordering window SHOULD leverage what? (If "that" refers to > >> the sentence before, SRTT, then the connection to DSACK is not obvious > >> to me. So I think it's good to substitute "that" here.) > > sorry that=3DDSACK. sentence got cut out accidentally. Does the propose= d > > new text in my earlier comment look better? > > Yes, this is clearer to me now. > > I would suggest the following slight changes to this sentence though: > > OLD: > "The RACK reordering window SHOULD adaptively increase if the sender > receives the Duplicate Selective Acknowledgement (DSACK) [RFC2883], > suggesting the window is too small which causes spurious > retransmission." > > NEW: > "The RACK reordering window SHOULD adaptively increase if the sender > receives a Duplicate Selective Acknowledgement (DSACK) [RFC2883], > suggesting the window is too small, which causes spurious > retransmission." Sure we'll revise accordingly. > > Best, > Theresa From nobody Mon Jul 27 05:55:58 2020 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 1DF9C3A1A45; Mon, 27 Jul 2020 05:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcQ7fjOENO5K; Mon, 27 Jul 2020 05:55:53 -0700 (PDT) Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3376A3A198D; Mon, 27 Jul 2020 05:55:40 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id A7EE925A12; Mon, 27 Jul 2020 14:55:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1595854538; bh=sdtQ1Ms4I5vpkRdZR4Elcc7T+eqUJcmuCMcSmXl8H7c=; h=From:To:CC:Subject:Date:From; b=JSAZwB6l8elZla3H+AuBrjBH/0KN8hSgu6i7jaEUvAV2I5ZaJq0Lk8iigc709YoPa 1xaj1Xs5n2uX//Z0+T8IiP750Zi+o7AxeNhUbCthpez2KvnnHqUr0kxunFPardeWcf sHjqTiCfqlc/xs7Gzh1iRBEzbhcR4/yEy01IhbCE= X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyJwfMZxhSsY; Mon, 27 Jul 2020 14:55:37 +0200 (CEST) Received: from rznt8101.rznt.rzdir.fht-esslingen.de (rznt8101.rznt.rzdir.fht-esslingen.de [134.108.29.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Mon, 27 Jul 2020 14:55:37 +0200 (CEST) Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.171]) by rznt8101.rznt.rzdir.fht-esslingen.de ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Mon, 27 Jul 2020 14:55:37 +0200 From: "Scharf, Michael" To: "tcpm@ietf.org" CC: tcpm-chairs Thread-Topic: Aprupt meeting end Thread-Index: AdZkFK2IBpcn5KdfSASiYCk9rerFJA== Date: Mon, 27 Jul 2020 12:55:37 +0000 Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2DCD4E2A@rznt8114.rznt.rzdir.fht-esslingen.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.108.48.165] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tcpm] Aprupt meeting end 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, 27 Jul 2020 12:55:57 -0000 Sorry, I was surprised that the meeting ends without any prior warning... As already mentioned, my proposal is to reshuffle the agenda for slot II as= follows: # 13:00-13:50 (UTC) Monday Session II ## Items in other WGs (cross-area topics) * 13:00-13:15 draft-ietf-netconf-tcp-client-server Kent Watsen 15 min ## Non-WG items (cross-area topics) * 13:15-13:25 draft-scharf-tcpm-yang-tcp Michael Scharf 10 min ## Non-WG items (MPTCP part two) * Next steps for draft-amend-tcpm-mptcp-robe * 13:25-12:35 draft-kang-tcpm-accurate-data-scheduling-by-server-in-mptcp Jiao Kang 10 min ## If time permits * 13:35-13:50 draft-touch-tcpm-ao-test-vectors Juhamatti Kuusisaari 15 min Michael From nobody Mon Jul 27 08:06:50 2020 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 F06063A19F6; Mon, 27 Jul 2020 08:06:47 -0700 (PDT) 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: 7.10.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tcpm@ietf.org Message-ID: <159586240790.9390.501511321431622321@ietfa.amsl.com> Date: Mon, 27 Jul 2020 08:06:47 -0700 Archived-At: Subject: [tcpm] I-D Action: draft-ietf-tcpm-rto-consider-17.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2020 15:06:48 -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 : Requirements for Time-Based Loss Detection Author : Mark Allman Filename : draft-ietf-tcpm-rto-consider-17.txt Pages : 12 Date : 2020-07-27 Abstract: Many protocols must detect packet loss for various reasons (e.g., to ensure reliability using retransmissions or to understand the level of congestion along a network path). While many mechanisms have been designed to detect loss, ultimately, protocols can only count on the passage of time without delivery confirmation to declare a packet "lost". Each implementation of a time-based loss detection mechanism represents a balance between correctness and timeliness and therefore no implementation suits all situations. This document provides high-level requirements for time-based loss detectors appropriate for general use in unicast communication across the Internet. Within the requirements, implementations have latitude to define particulars that best address each situation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-17 https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rto-consider-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rto-consider-17 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 Mon Jul 27 08:08:21 2020 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 F1AE53A160C for ; Sun, 26 Jul 2020 19:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0F34wXLNvVVC for ; Sun, 26 Jul 2020 19:27:53 -0700 (PDT) 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 BE8563A160A for ; Sun, 26 Jul 2020 19:27:53 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2A4DFF40744; Sun, 26 Jul 2020 19:27:31 -0700 (PDT) To: ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com, martin.h.duke@gmail.com, magnus.westerlund@ericsson.com, michael.scharf@hs-esslingen.de, tuexen@fh-muenster.de, nsd.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: simon.omni.acc@gmail.com, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200727022731.2A4DFF40744@rfc-editor.org> Date: Sun, 26 Jul 2020 19:27:31 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 27 Jul 2020 08:08:19 -0700 Subject: [tcpm] [Technical Errata Reported] RFC7413 (6239) 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, 27 Jul 2020 02:27:55 -0000 The following errata report has been submitted for RFC7413, "TCP Fast Open". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6239 -------------------------------------- Type: Technical Reported by: Simon khng ren hao Section: 5.2 Original Text ------------- produces responses earlier before the handshake completes Corrected Text -------------- produces responses after the handshake completes Notes ----- Located on last paragraph last line of section on page 16. First line states 'not to respond with data until the handshake finishes' which contradicts the last line. 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. -------------------------------------- RFC7413 (draft-ietf-tcpm-fastopen-10) -------------------------------------- Title : TCP Fast Open Publication Date : December 2014 Author(s) : Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain Category : EXPERIMENTAL Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Jul 27 09:58:32 2020 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 7D5653A0FC4 for ; Mon, 27 Jul 2020 09:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 5VZNfYTX_jVu for ; Mon, 27 Jul 2020 09:58:29 -0700 (PDT) Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (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 00CC33A0FC1 for ; Mon, 27 Jul 2020 09:58:28 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.43/8.16.0.42) with SMTP id 06RGkStE010779; Mon, 27 Jul 2020 09:58:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=20180706; bh=VFQCy5LfS3JzefcAGIKcrX+jQmObuPRNpQ1YDmBuBTk=; b=Vn+BPnAbjGjjr6WeJLm5AjS2wgfm5zqUjHWWzrnZgSyNiH0aO4FAIg0PeYf0altqwJNO 4gzb7KwrxR+c1xyZGgP6uWe5YHSts6kbmEiNSP0aBacEfltOwR6IwBZC6ZkQ7nrtkjZJ QQdfC6FOoDZFZniZbMvT8FYljodA190OrQHJ9QHUxgNuJvrF7QH2Svjy1nSgyGWkEFj7 CXU36EULpX5HhYKVUvVZJIa6uZ2fr++GWy/5E8rbyIjqCyveT+D2+8ZT2UD3eoEDDfsi OngoQ7AmMQMIKL4Wi8qJbSQafVhtA9gmH4V7zI7LI8MPzkIPU7zmtehe4hYGHcaRfHNi MA== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by nwk-aaemail-lapp02.apple.com with ESMTP id 32ghafs5y9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 27 Jul 2020 09:58:23 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPS id <0QE500GO10HBBZO0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 27 Jul 2020 09:58:23 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) id <0QE400S00ZV58L00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 27 Jul 2020 09:58:23 -0700 (PDT) X-Va-A: X-Va-T-CD: 3beaf764f461a8ab0294914a8b578f03 X-Va-E-CD: dbb4aa9d0c53e8100e25dcf92570366e X-Va-R-CD: 8e3f0004dc05f9a4784d4291b529a402 X-Va-CD: 0 X-Va-ID: 52430b5f-7394-432e-aed4-4ebf231df13f X-V-A: X-V-T-CD: 3beaf764f461a8ab0294914a8b578f03 X-V-E-CD: dbb4aa9d0c53e8100e25dcf92570366e X-V-R-CD: 8e3f0004dc05f9a4784d4291b529a402 X-V-CD: 0 X-V-ID: 86d2dd34-ca59-4662-b012-56755105f583 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_12:2020-07-27, 2020-07-27 signatures=0 Received: from localhost ([17.234.118.104]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.5.20200312 64bit (built Mar 12 2020)) with ESMTPSA id <0QE500XFT0HAXO00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 27 Jul 2020 09:58:22 -0700 (PDT) Date: Mon, 27 Jul 2020 09:58:22 -0700 From: Christoph Paasch To: Kangjiao Cc: Olivier Bonaventure , "tcpm@ietf.org Extensions" , Liangqiandeng Message-id: <20200727165822.GB73500@MacBook-Pro-64.local> References: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9A9BC@dggemm534-mbs.china.huawei.com> <213AD4B1-4F88-4389-93CE-242916C06DC8@apple.com> <719A2C1D4AC73847B6E1BF21DF1545EAE5C9AA60@dggemm534-mbs.china.huawei.com> <20200723144058.GQ73500@MacBook-Pro-64.local> <719A2C1D4AC73847B6E1BF21DF1545EAE5C9DC89@dggemm534-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <719A2C1D4AC73847B6E1BF21DF1545EAE5C9DC89@dggemm534-mbs.china.huawei.com> User-Agent: Mutt/1.12.2 (2019-09-21) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_12:2020-07-27, 2020-07-27 signatures=0 Archived-At: Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 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, 27 Jul 2020 16:58:31 -0000 On 07/25/20 - 15:18, Kangjiao wrote: > The scenarios in this draft are not for traffic handover when encountering > network failure. It is applied when one peer has an explicit plan on > traffic switching. For example, for network migration or expansion on > server, operator wants to adjust the traffic on these networks in advance. > This is an actual case. > > We think packet scheduler knows on which subflow the next packet will be > sent. > So it may be a good choice to deploy the logic of accurate traffic > switching on this component. I would love to understand more on how one would implement such kind of a logic. Do you have a pseudo-code example? I have a hard time imagining how the scheduling estimates the amount of traffic it would have sent on subflow A and rather sends it on subflow B, because to drive this decision-making it needs an estimate of RTT, congestion-window,... of subflow A which it only can get by actually scheduling traffic on A. While at a macro-level an operator can do its traffic-engineering and decide what proportion of traffic should be sent on one vs the other path, I don't see how this translates into the same method at the micro-level where scheduling happens on a packet-by-packet basis and is hugely driven by congestion-control and RTT. Thus, to achieve such traffic-engineering for the operator it looks to me like it translates rather to adjusting the weights and preferences on the subflows. Thanks, Christoph > > Sincerely, > Jiao > > -----Original Message----- > From: Olivier Bonaventure [mailto:olivier.bonaventure@tessares.net] > Sent: Friday, July 24, 2020 10:17 PM > To: Christoph Paasch > Cc: Kangjiao ; tcpm@ietf.org Extensions ; Liangqiandeng > Subject: Re: [tcpm] comments on draft-kang-tcpm-accurate-data-scheduling-by-server-00 > > Hello, > > > > > > > > From my perspective, I think following are two different requirements: > > > > > > 1. Making all the traffic towards S2 (for this case, MP_PRIO may be > > > enough) > > > > > > 2. Making traffic only from to the destination IP_S2, > > > which means diverting traffic that should be scheduled to > > IP_S1> to one subflow belonging to the target network interface (it > > > is "on-demand scheduling", for this case, MP_PRIO is not enough) > > > > What is the use-case for such a scheme? > > Understanding the requirements from the applications would really help in this discussion. This could also serve as input for Multipath QUIC where the middlebox problems that are mentioned in the draft do not exist. > > > I don't see how a multipath scheduler could assign the traffic that "would" > > have been sent to to a different subflow. Because for that he > > would need to know what *would* have been sent on which he can > > only know once he actually sends traffic on that subflow as that will > > be driving the congestion-window which will allow to send more (or less) traffic on . > > Another point that needs to be taken into account is that when client moves, the network conditions change dynamically and the server view might differ from the wireless conditions on the client. In this case, it is difficult for the server to precisely decide where it wants to receive data. See http://multipath-tcp.org/multimob/ > > Olivier > > -- > > > Disclaimer: https://www.tessares.net/mail-disclaimer/ > > > From nobody Mon Jul 27 15:17:38 2020 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 C71ED3A08D7; Mon, 27 Jul 2020 15:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3Pz9CcmA4S9i; Mon, 27 Jul 2020 15:17:28 -0700 (PDT) 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 6EE9D3A08E4; Mon, 27 Jul 2020 15:17:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5D6C5F4074C; Mon, 27 Jul 2020 15:17:04 -0700 (PDT) To: simon.omni.acc@gmail.com, ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: martin.h.duke@gmail.com, iesg@ietf.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200727221704.5D6C5F4074C@rfc-editor.org> Date: Mon, 27 Jul 2020 15:17:04 -0700 (PDT) Archived-At: Subject: [tcpm] [Errata Rejected] RFC7413 (6239) 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, 27 Jul 2020 22:17:30 -0000 The following errata report has been rejected for RFC7413, "TCP Fast Open". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6239 -------------------------------------- Status: Rejected Type: Technical Reported by: Simon khng ren hao Date Reported: 2020-07-27 Rejected by: Martin Duke (IESG) Section: 5.2 Original Text ------------- produces responses earlier before the handshake completes Corrected Text -------------- produces responses after the handshake completes Notes ----- Located on last paragraph last line of section on page 16. First line states 'not to respond with data until the handshake finishes' which contradicts the last line. --VERIFIER NOTES-- This erratum does not correctly interpret the paragraph. The sentence is: "But the potential latency saving from TFO may diminish if the server application produces responses earlier before the handshake completes." The text refers to when the server response is available, not when it is sent. If the server data isn't yet available, then there is no message to withhold and therefore no performance penalty in waiting for the handshake to complete. -------------------------------------- RFC7413 (draft-ietf-tcpm-fastopen-10) -------------------------------------- Title : TCP Fast Open Publication Date : December 2014 Author(s) : Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain Category : EXPERIMENTAL Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Tue Jul 28 08:36:59 2020 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 76F673A0F15 for ; Mon, 27 Jul 2020 08:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icsi-berkeley-edu.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 a30sq5pXgvqy for ; Mon, 27 Jul 2020 08:21:40 -0700 (PDT) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (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 0459B3A183C for ; Mon, 27 Jul 2020 08:21:25 -0700 (PDT) Received: by mail-qv1-xf2f.google.com with SMTP id x6so1791744qvr.8 for ; Mon, 27 Jul 2020 08:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icsi-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=2GCOTwbypuhtsxEepSC0wmFUv9lD7Qsf/PKbaQ/WyTc=; b=ZH1aGMEI7sNe2vxHxFOKg8g5W+1uCXSEhBxOg5YWmrP1tU0htVpW9oUR5pDgm0b3c0 koxZh8mJWl2im0E0ielqsYLpBosIJ7wpcZtYe73E3MUhn1lRo9y1i9kjAaSCy+h3cZYp kX+l/neLMU+PBfo+01ujT2T6XTaYM0I0K+W/m4/1vuRSS8QkTfDF3CdwHlGmvP0smIFE 36J3n5yv6dN70Hdn7JPYZeMw1ijkMGBI1/hfcuySrEZEoXtTt3NtVn2pWzEOlZ6JLWzJ T/VHtudf9SsucO0p2g9HkFsyTNlr3MnEv+nE3hr1qPb4Nn+Dp20Ibktx5b9/szhHzDaf +w+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=2GCOTwbypuhtsxEepSC0wmFUv9lD7Qsf/PKbaQ/WyTc=; b=tyooQxGyapM4IkvOa5TPzn1zHk6HfC35R5t6tmx7WUNItBfrZZ4bCgeEalwvcND4MZ xt2CvNvxV/rgL+8ci1Qdg0d0+FzeGnAszP8ak+s7s4Ncz4LFqBrxmpd3KDUtQBSWkfUD oRPtolURtDAsN82RoKEeOTV8t6PgL/HdQyt8PnOJjFvpTFmAYvvpo6/I9DiPZz2iT+V9 +pprLSPAhgezdLI/v3S1Fd6P2Ha244mZbtuMwOvOTA4/+es+JTz6h/Fs6kdrQ53BeylW mnnlew5sP205ikLu1Qt5xvhOalWG6zSwsjkEPLl0irWLq1t1ug/+iV6f0SJIRRslfqXP 6q+g== X-Gm-Message-State: AOAM532AeCXJMSCXUHrgTrnwVTOgMsFSPiOpcWGrvsBBoUZZ8KH0QKtw mmYwgmr69U0s8vp1zb8SWczcgA== X-Google-Smtp-Source: ABdhPJxwX02Y20NDU4qA6LYPblHvVnuQB0uTO6p8gZuR6TR/XJGNoxMfxOyaRL09qwdgreynegkNXg== X-Received: by 2002:ad4:4a27:: with SMTP id n7mr16011132qvz.184.1595863284899; Mon, 27 Jul 2020 08:21:24 -0700 (PDT) Received: from [192.168.1.244] (162-203-32-211.lightspeed.bcvloh.sbcglobal.net. [162.203.32.211]) by smtp.gmail.com with ESMTPSA id m63sm14698536qte.32.2020.07.27.08.21.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Jul 2020 08:21:23 -0700 (PDT) From: "Mark Allman" To: "Martin Duke" Cc: "Benjamin Kaduk" , Extensions , "The IESG" , draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs Date: Mon, 27 Jul 2020 11:21:22 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: References: <159406496706.24848.1574717471798101163@ietfa.amsl.com> <97326820-187D-4A67-BBF0-CC58FAF18F0B@icsi.berkeley.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_6CE2EBF0-E068-4BD2-B9ED-09A19BDA74D7_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: X-Mailman-Approved-At: Tue, 28 Jul 2020 08:36:58 -0700 Subject: Re: [tcpm] Benjamin Kaduk's Discuss on draft-ietf-tcpm-rto-consider-16: (with DISCUSS and COMMENT) 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, 27 Jul 2020 15:21:42 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_6CE2EBF0-E068-4BD2-B9ED-09A19BDA74D7_= Content-Type: text/plain > Benjamin and I discussed this briefly in the telechat. I would summarize as > follows: > > - We seem to have clear agreement on all but the first DISCUSS point > - We should probably say something about the security implications of > spoofed acks but not be too specific. The document doesn't really have a > section (that I can find right now) that discusses the properties of ACKs, > so perhaps the best place to put this is in security considerations. > Something to the effect of Thanks for all the comments, folks. I just posted -17. Several things ... - First, on the main point of Ben's DISCUSS, I added some non-normative words to requirement 2a in section 4 to encourage the use of ACKs that cannot be readily spoofed. I ran the text by Martin & Ben last week and while I don't want to speak for them, both seemed satisfied. (Ben- The words submitted are further honed based on your note.) - I take the COMMENTS as suggestions. The typos and small errors were all fixed. For the larger comments I tried to clarify where these indicated that was needed. But, I didn't change something for every comment. And, I especially didn't try to figure out / address the more nebulous comments. - I can enumerate the changes based on the COMMENTS, if that's useful. However, my understanding of COMMENTS is that they're suggestions and as such I'd much rather just refer you to the diffs if you are interested in some specific comment. Please yell if I missed something. Thanks, allman --=_MailMate_6CE2EBF0-E068-4BD2-B9ED-09A19BDA74D7_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHgEARECADgWIQR2wAGDYhexl/6SqCRbKutazjIizgUCXx7w8hocbWFsbG1hbkBp Y3NpLmJlcmtlbGV5LmVkdQAKCRBbKutazjIizjLZAJ0QRosYh2KUYRjC/Ed+IkaH k9XbWwCgmDPOiJl9XnsPkn8H97bIJOdY4BE= =uROT -----END PGP SIGNATURE----- --=_MailMate_6CE2EBF0-E068-4BD2-B9ED-09A19BDA74D7_=-- From nobody Tue Jul 28 08:37:05 2020 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 5C4463A0B8A for ; Mon, 27 Jul 2020 13:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANudsz_aDKhh for ; Mon, 27 Jul 2020 13:00:37 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 EA8C03A0B88 for ; Mon, 27 Jul 2020 13:00:36 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id o184so8981549vsc.0 for ; Mon, 27 Jul 2020 13:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=whhNflrfN1LdgubPJKOAY+zHG3Tw4BtwJUhXC4prqd0=; b=dev07rIs2AaiQTqBvA022hzuy1RpAfLW5qJa6uZHX3m73oPZ2a7YeavaGiqONezXWU pX1KxuFI7MIx0NTA/6rqZITao6flLo4I7LcT3eT/rT5dbACKUwl8Rwx+SK+9NCPwNPvm aAfaIivbUtP/8ZS/ACRDvpnoyK++8VUZ9qDwqKh8imPfD94308p8LS+kjRgAChJj0smp 0vEutLzSqqSo0HTolYdLNkfC9tt3OMgkkT5rFmky2hERbZx8KPh96yooRWToRFC32qap bbPvw449915/qYpiMfH/U8Df31kgSX77mNit7ciJEtOBftfIYYKNtAb80lc7D+chjl59 tb+w== 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=whhNflrfN1LdgubPJKOAY+zHG3Tw4BtwJUhXC4prqd0=; b=VKjvN/SwQCkQ7Jdns3Hae4vKmasREImwOf9v7ySpZ1/oHTlOT8ChdoUTVh5ziypEkb EQsIKQ1vU/6Jg6Ipysect+U5h97VFo6wfYT/zKM9kQr5B/ELG4AV6fBZuMXKQlfhYhI2 WnuVG6Yke77eNsXCXM+7y6FghUKvUT6NadGRyLaMAdxsS1b+hMj5r78xHOn0su88nAbK A4wp06dCyRZaP/V0oW638uV9wsQIgaN40f2Uao791dnzPVpZ7OXpUSC/KjjmziiwPU0r gK2vphfpvTleurfGcaSmdY2I7xaIOrsFcmZkTgEZp4QH/fjAD+OHKNLf2O2O8pZMnFnc 7FUg== X-Gm-Message-State: AOAM533/MDRZ0ylYk8ktwfB/DN3U1l2oQI9pwv6w8xhO5VyPSSAKmzAN 7IHzJQtWKCf+Q/dlJ8TLdJ0X279Kdw9cBer/6NduMQ== X-Google-Smtp-Source: ABdhPJwUcfyBoPCKLpQ5znm/WO+4RfxdGyqqiN5IttBe3cfipKsazPH+BNxPYYqkOpWD3h5sAgwayg4I6LjHXclzIuY= X-Received: by 2002:a67:f856:: with SMTP id b22mr17043861vsp.123.1595880035626; Mon, 27 Jul 2020 13:00:35 -0700 (PDT) MIME-Version: 1.0 References: <20200727022731.2A4DFF40744@rfc-editor.org> In-Reply-To: <20200727022731.2A4DFF40744@rfc-editor.org> From: Yuchung Cheng Date: Mon, 27 Jul 2020 13:00:00 -0700 Message-ID: To: RFC Errata System Cc: Jerry Chu , Sivasankar Radhakrishnan , Arvind Jain , Martin Duke , magnus.westerlund@ericsson.com, "Scharf, Michael" , Michael Tuexen , Yoshifumi Nishida , simon.omni.acc@gmail.com, "tcpm@ietf.org Extensions" Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Tue, 28 Jul 2020 08:36:58 -0700 Subject: Re: [tcpm] [Technical Errata Reported] RFC7413 (6239) 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, 27 Jul 2020 20:00:38 -0000 On Sun, Jul 26, 2020 at 7:27 PM RFC Errata System wrote: > > The following errata report has been submitted for RFC7413, > "TCP Fast Open". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6239 > > -------------------------------------- > Type: Technical > Reported by: Simon khng ren hao > > Section: 5.2 > > Original Text > ------------- > produces responses earlier before the handshake completes > > Corrected Text > -------------- > produces responses after the handshake completes I don't think the errata is valid. what the text meant to say is "if the server produces data (ready to sent) before the handshake completes, then the server not to send the data until the handshake finishes is at a disadvantage.". the text is to discuss pros & cons of a design decision, not describing the protocol itself. > > Notes > ----- > Located on last paragraph last line of section on page 16. First line states 'not to respond with data until the handshake finishes' which contradicts the last line. > > 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. > > -------------------------------------- > RFC7413 (draft-ietf-tcpm-fastopen-10) > -------------------------------------- > Title : TCP Fast Open > Publication Date : December 2014 > Author(s) : Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain > Category : EXPERIMENTAL > Source : TCP Maintenance and Minor Extensions > Area : Transport > Stream : IETF > Verifying Party : IESG From nobody Tue Jul 28 16:22:11 2020 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 D2F013A0AAC; Tue, 28 Jul 2020 16:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 FZm1JH7CFvp4; Tue, 28 Jul 2020 16:22:03 -0700 (PDT) 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 57F3E3A0A9A; Tue, 28 Jul 2020 16:22:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BB4F7F4073D; Tue, 28 Jul 2020 16:21:37 -0700 (PDT) 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: <20200728232137.BB4F7F4073D@rfc-editor.org> Date: Tue, 28 Jul 2020 16:21:37 -0700 (PDT) Archived-At: Subject: [tcpm] =?utf-8?q?RFC_8803_on_0-RTT_TCP_Convert_Protocol?= 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, 28 Jul 2020 23:22:05 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8803 Title: 0-RTT TCP Convert Protocol Author: O. Bonaventure, Ed., M. Boucadair, Ed., S. Gundavelli, S. Seo, B. Hesmans Status: Experimental Stream: IETF Date: July 2020 Mailbox: Olivier.Bonaventure@tessares.net, mohamed.boucadair@orange.com, sgundave@cisco.com, sh.seo@kt.com, Benjamin.Hesmans@tessares.net Pages: 47 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpm-converters-19.txt URL: https://www.rfc-editor.org/info/rfc8803 DOI: 10.17487/RFC8803 This document specifies an application proxy, called Transport Converter, to assist the deployment of TCP extensions such as Multipath TCP. A Transport Converter may provide conversion service for one or more TCP extensions. The conversion service is provided by means of the 0-RTT TCP Convert Protocol (Convert). This protocol provides 0-RTT (Zero Round-Trip Time) conversion service since no extra delay is induced by the protocol compared to connections that are not proxied. Also, the Convert Protocol does not require any encapsulation (no tunnels whatsoever). This specification assumes an explicit model, where the Transport Converter is explicitly configured on hosts. As a sample applicability use case, this document specifies how the Convert Protocol applies for Multipath TCP. 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 Wed Jul 29 11:54:58 2020 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 B014F3A0EDF for ; Wed, 29 Jul 2020 11:54:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159604888069.26352.10528529553542770015@ietfa.amsl.com> Date: Wed, 29 Jul 2020 11:54:40 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG 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, 29 Jul 2020 18:54:43 -0000 Changed milestone "Submit specification of more accurate ECN feedback in TCP to the IESG for publication as an Experimental RFC", set description to "Submit specification of more accurate ECN feedback in TCP to the IESG for publication as a Proposed Standard RFC". Changed milestone "Submit a document on modifying slow start to avoid large tail drops", set description to "Submit a document on modifying slow start to avoid large tail drops as a Proposed Standard RFC". URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Jul 29 11:55:03 2020 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 B00623A0EDD for ; Wed, 29 Jul 2020 11:54:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159604888070.26517.201892983805015434@ietfa.amsl.com> Date: Wed, 29 Jul 2020 11:54:40 -0700 From: IETF Secretariat Archived-At: Subject: [tcpm] Milestones changed for tcpm WG 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, 29 Jul 2020 18:54:43 -0000 Changed milestone "Submit a document on modifying slow start to avoid large tail drops", set description to "Submit a document on modifying slow start to avoid large tail drops as a Proposed Standard RFC". URL: https://datatracker.ietf.org/wg/tcpm/about/ From nobody Wed Jul 29 23:49:10 2020 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 85BE43A0EF3; Wed, 29 Jul 2020 23:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owAxNQWgiEwz; Wed, 29 Jul 2020 23:48:59 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 09A773A0EDA; Wed, 29 Jul 2020 23:48:58 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id d190so4697778wmd.4; Wed, 29 Jul 2020 23:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=U81AnJ0MWLtRkQ0NZb1uBnODlG77J1IeQRyZOsZkkTg=; b=ht1K9gb2sA+1TwhbKjTMzZ0/4zmqDZr3+1SXM/wZFybgJ+xzfskjyP5T+oHzTxhzt9 Z5BSqbZtgZxxMxL8baUcs2JSA2Q4UgXKmKuXxWq99eAiqhlf/OoVanRETE7sc8Pon1Yp L1tZeLCOViRKhK6jouRhbeB+3GeKj/uS0Bl0VwZ7oz4KA1XKGZz8MXrUSZd+5MYdnv2n Z79jV6CR+HEedJ1Q+Wl4V3gXCmVqUB1s0jaQsvzm8kh0vEsH3udRIpNhGEobB15acYe/ k6ECAlM4cyTAJfkIQFnxx+daM7jRMp0l74dHvyDkrA2mO7C3sBcVm1QMJ5EM3uHGAp5T Td9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=U81AnJ0MWLtRkQ0NZb1uBnODlG77J1IeQRyZOsZkkTg=; b=I5z9vowdTrBB415f5AkpL/TM9LWr0YnJFd3MSCDlQYAkHtVf+y2zrtVlLwB7QKGWLi 970hISxF2AOYTod1WQtniCs95edkSY8stb7yl6n4PzZHum5xAkq1AstU6jHgrypWGBVQ uMzIUJgJc7ET5WCFTWeiWnQKDaH9Mvfa78VWZUGSAy4bv/amkSWIN8GrUR7upqUINIGo nj7tz7KPFUPqdxKA8UuvkWtaz4YLzNgvRbqVPRZAM1GQeFOa5AFBFV9sTvTnzckdp9tS MlDnuXwG+Wm1p19G35jVAqIbiVQz0244804BXul21jB1Y8s6YHLU7LIJFPu2Ie9YdSBW 3BPg== X-Gm-Message-State: AOAM531yNt+olC7jkzM2UveOqBgcHrUql32vFSTUoNRIw3nafpeFGq/8 cfl5WZhxTX1dzdeN5YlXCNWY9zqkZAuuvS0ufV5I4DKp X-Google-Smtp-Source: ABdhPJy5IgmrW8CyjNQ9yIvP86dKLxFIrmmEwqapNdd+Zo7U54POEoNyulK2bsXXnRXg8Lz33uy115abujWOYmLx7nQ= X-Received: by 2002:a1c:2ec4:: with SMTP id u187mr11620762wmu.188.1596091737238; Wed, 29 Jul 2020 23:48:57 -0700 (PDT) MIME-Version: 1.0 From: Yoshifumi Nishida Date: Wed, 29 Jul 2020 23:48:46 -0700 Message-ID: To: "tcpm@ietf.org Extensions" Cc: tcpm-chairs Content-Type: multipart/alternative; boundary="00000000000006f0c805aba31124" Archived-At: Subject: [tcpm] draft minute for 108th meeting 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, 30 Jul 2020 06:49:02 -0000 --00000000000006f0c805aba31124 Content-Type: text/plain; charset="UTF-8" Hi, I've uploaded a draft minute on the following URL. https://www.ietf.org/proceedings/108/minutes/minutes-108-tcpm-00.md Please let us know if you have corrections or questions, etc. Thanks! -- tcpm co-chairs --00000000000006f0c805aba31124 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
I've uploaded a draft minute on the= following URL.

https= ://www.ietf.org/proceedings/108/minutes/minutes-108-tcpm-00.md

Please let us know if you have corrections= or questions, etc.
Thanks!
--
tcpm co-chairs=
--00000000000006f0c805aba31124-- From nobody Fri Jul 31 10:38:58 2020 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 9ECBE3A0BD9; Fri, 31 Jul 2020 10:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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=ericsson.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 J9iRQfGZHDkD; Fri, 31 Jul 2020 10:38:52 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10067.outbound.protection.outlook.com [40.107.1.67]) (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 7FEF83A0BD7; Fri, 31 Jul 2020 10:38:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dUJyDEN2u0IOfZ0w+avG6bfKzuVLMAMmmYA/TuGsDcPPI+5wOqicRQSuZnmKPZK+Cu8xLQdlsCDdssD0EMWm6AJB58CgaVyJRQmV9VeCyqMkhZp1ifqstJ4c6y5T5gvd2ykQuxDpiaEqkpcYDPSaVCzWigr4UqpW5/ZbcmhhzwGqQWqYubZr+3ylQioFna0Jz4pejvga3GWhK2m3LN0afjVKG/C5M2pYUvDyMVZOFI4lUi8uvYz0dRQKuB5i2KJDIJpniyO36e6ujjmy7eo1pzDj+hNDeAk+O3pglOSiza4F/BKY9SSrS5Agbkaaw9+JnMC8YeLgy8XsmrW2RJ1+SQ== 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=YI+vMwHPz3OyxZ6OVkNkMsx/7v255FHeUmcl0sJVnZ8=; b=k1GF6dV+/3EogOvH0canWuuKX0g0Tavpkmjl/WDpZ7zur+bbCotxvA4xaN5nT5IlK0OpnU9oOfh2CkobOl5Xf2Wqe8NgDRXHmxkJKw2EfMgnm4kKcjN2R65OUeLqVf24sIY9MfUQoZ9cRT1D9NB0VQZKtEANVnXKcRMBKjwThkVWfiug+5oRrWsouECA5MAl5hAjJQ1336H2RDIJ8VGS9RtwFHqsYEhFwYshfOy4MdJ4EL59DO7l+ElrcG0IymzLr7oqiiZ1ITjnhrD8QrXFOwU7GDI3xRfokibO/FD6yu5rAGtI86bIpvQluexzmtV/4/9Fpcf3NiQJq07W2P0hGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YI+vMwHPz3OyxZ6OVkNkMsx/7v255FHeUmcl0sJVnZ8=; b=FeWLQrVoohWSoF1wTF/ccOTQuY/hlX4IsQYHkc8zrtsWRiRbAsDJ3daAbrjVvJqWvuShm5+2MXM1VMkedWhlJHnt875PK7r2WtAbVrBRTO29NqhqRMlISuQXVrl3sPo9/EqYCL3DY58Hvc804vnI4PJw/qrakKVdR77iI1RRNRE= Received: from AM0PR0702MB3713.eurprd07.prod.outlook.com (2603:10a6:208:19::10) by AM0PR07MB4723.eurprd07.prod.outlook.com (2603:10a6:208:6a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.15; Fri, 31 Jul 2020 17:38:48 +0000 Received: from AM0PR0702MB3713.eurprd07.prod.outlook.com ([fe80::d1f1:397c:7240:92f1]) by AM0PR0702MB3713.eurprd07.prod.outlook.com ([fe80::d1f1:397c:7240:92f1%7]) with mapi id 15.20.3195.030; Fri, 31 Jul 2020 17:38:48 +0000 From: Mirja Kuehlewind To: "tsv-area@ietf.org" , "tcpm@ietf.org" Thread-Topic: Joint RIPE MATWG / IRTF MAPRG session next Wednesday, Aug 5, 13:00 UTC Thread-Index: AQHWZ2FywNVghJxAX0SjQXUc4A+Ciw== Date: Fri, 31 Jul 2020 17:38:48 +0000 Message-ID: <088CD7AA-F107-4D90-A68A-8DE72E8D2D5D@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2003:de:e700:7a00:58fb:54b9:2185:2a13] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 86e9ba97-9eb4-427b-2062-08d835789502 x-ms-traffictypediagnostic: AM0PR07MB4723: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4ju89xMq5nKiBZWj2kyYpXJLEfcNS6aB5LBBneooX2nOGbimAb5usCQ7Css61kvr5HVLecJteJt0tEvuJLizBRfFUwRu8kliTPWX5h/MmKtoIzgO4OndMv0inybocpCjyU8N9WHNsCAbEPMNYx3KvYCgDri8vm1wycEDTm/TjSsBr3nRXfHJihPw2/wPLomUtMMwzXCDVUTd7/6qLSaiJvYMXW1SyfWMxoJiR6ThyBtLH4dNRTrc8W8iQapLMawcWntvdlwu/jy3m/MsUnALwJTsasnhsT3v4jQV+yrBbQSBVaNeb8vS3K/euLCJ0vgOb2jZYBrFDjde3PvI0FYIHOOS7NLIAQE59p0iOnfR4/mz0AtuG4U3DauBqoouXGrNfWzlJFeBdtqqgI54qM/1dw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3713.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(366004)(39860400002)(396003)(76116006)(6486002)(66446008)(66476007)(2906002)(5660300002)(16799955002)(64756008)(66556008)(33656002)(66946007)(86362001)(6506007)(450100002)(36756003)(4744005)(186003)(110136005)(2616005)(966005)(66574015)(44832011)(316002)(8936002)(8676002)(6512007)(478600001)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: dlYyp/8piSTJ/NyPeuT288bpaleX/TPwvTteNigz+K2aOjJt3xitGOqRaGCOFYvcwqDcLmQZ7U3zVA5oHAeC/jiUXdCOqab3PaR+WuWRAfAEZ7FlzQ/1N0M1wZ0zdLOoHv9aohLFmXSWEOhXPTAJkqsifjubnGK3XZJg+FDZZO0R2+9yUgMvwlmJcdzHG3+MlVH6oAlIYA8ImZfFHTzSVeDdS6S6JGNFF7cNP8/FQo3yMOq9URiNWukLF25N5yiyUkNYKXMRHgw9dbP7bkzxgViSsqKmF8rnq356TzLyYPYoXBwuzNL6ZNH56lByfJgIkfcNWuZZUnvchs6aNx9eliHCAA5k0q/MEcdplgtkq4HBvUmNfxed5oRwDe6fKsomkG04h8WtGTUjtnwvnM72gux6PiP8q1t9jE/lG0OlgZWfYqLwMAf+E9jnukJK5DI9m4mtbLn2TCMlfDdRoQbLO6I0Xu/QKaqva1VMKlfc/imozdOaRxZic3wxd3FuTcXjRf5/XtFx1BNminJ7MTm5Beby6KL4VlAPzCEinmLMvJNi3ribaQVd+06NJQ3AK/hyjGm2JsdxgRQ1G94nvsv98dwmKdsRB3xk2NMy/hXJLc1o4vU0pBIyuyM1ti+lDNDiIAu46Ifne+hDgOOELTDEO/fq7L6nzcIYINlNQRDFG6mlf8/TxXihgjcA3NKvFfkCUQKNj1oPVI+XK1kRWYi94Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <4CF96DABC966364380205AC928C8AF64@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3713.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 86e9ba97-9eb4-427b-2062-08d835789502 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2020 17:38:48.3658 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pghgfI60NNsRnVCHdLeGEi7in4XIXK5gozNr3ON1TU/chCgYUa1LGSYHgp13OpZNlaR2DoidnACSN9GIkF2k9vqazECuXje/jFlcPpoIsT0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4723 Archived-At: Subject: [tcpm] Joint RIPE MATWG / IRTF MAPRG session next Wednesday, Aug 5, 13:00 UTC X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2020 17:38:55 -0000 SGkgYWxsLA0KDQpob3BlIHlvdSBoYWQgYSBnb29kIElFVEYgd2VlayBidXQgaXQncyBub3Qgb3Zl ciB5ZXQuLi4gd2Ugd2lsbCBoYXZlIGEgam9pbnQgUklQRSBNQVRXRyAvIElSVEYgTUFQUkcgc2Vz c2lvbiBuZXh0IFdlZG5lc2RheSwgQXVnIDUsIDEzOjAwIFVUQywgb24gV2ViZXguDQoNClRoZXJl IGFyZSBhIGNvdXBsZSBvZiB0YWxrcyBvbiB0aGUgYWdlbmRhIHRoYXQgY291bGQgYmUgaW50ZXJl c3RpbmcgZm9yIHRoaXMgZ3JvdXAsIGUuZy46DQoNCi0gSW50ZXJuZXQgTWVhc3VyZW1lbnRzIG9m IHRoZSBDT1ZJRC0xOSBwYW5kZW1pYyAtIEVtaWxlIEFiZW4sIFZlc25hIE1hbm9qbG9pdmljLCBM YWkgWWkgT2hsc2VuDQoNCi0gTGF0ZW5jeSAmIEFRTSBPYnNlcnZhdGlvbnMgb24gdGhlIEludGVy bmV0IC0gSmFrZSBIb2xsYW5kDQoNCi0gUGFja2V0IExhdGVuY2llcyBpbiBNb2JpbGUgTmV0d29y ayAtIFBoaWxpcHAgQnJ1aG4NCg0KLSBNVVNULCBTSE9VTEQsIERPTidUIENBUkU6IFRDUCBjb25m b3JtYW5jZSBpbiB0aGUgd2lsZA0KDQpIZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBmdWxsIGFnZW5k YToNCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS0yMDIwLW1hcHJn LTAxL2FnZW5kYS9hZ2VuZGEtaW50ZXJpbS0yMDIwLW1hcHJnLTAxLXNlc3NhLTAwDQoNCkhlcmUg aXMgYWxzbyB0aGUgV2VibGluayBsaW5rOg0KDQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYv ai5waHA/TVRJRD1tODUwNmY5MWQ1M2ZjNzY5ZjJhZmFhYTgxYzkxN2MwZWYNCg0KSG9wZSB0byBz ZWUgeW91IGFsbCBuZXh0IHdlZWshDQoNCk1pcmphDQoNCg0KDQo= From nobody Fri Jul 31 16:23:48 2020 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 8B2993A0D2D; Fri, 31 Jul 2020 16:23:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-tcpm-rto-consider@ietf.org, tcpm-chairs@ietf.org, tcpm@ietf.org, Yoshifumi Nishida , nsd.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <159623782505.2762.7104582032416395434@ietfa.amsl.com> Date: Fri, 31 Jul 2020 16:23:45 -0700 Archived-At: Subject: [tcpm] Benjamin Kaduk's No Objection on draft-ietf-tcpm-rto-consider-17: (with COMMENT) 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: Fri, 31 Jul 2020 23:23:47 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-tcpm-rto-consider-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tcpm-rto-consider/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the updates; they seem to address the core topics I raised and found the appropriate places to do so (even when I did not) -- I may have to reference this document when giving authors an example of the degree of interpretation available to them when responding to IESG (or, really, any) comments. Having said that, "a healthy amount of randomness" is perhaps not very clear guidance in terms of how much is "healthy", but I recognize the goal of not being overly prescriptive, and am reluctant to suggest additional changes.