Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-19: (with COMMENT)

"Black, David" <David.Black@dell.com> Thu, 09 April 2020 13:47 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1512D3A0BBA; Thu, 9 Apr 2020 06:47:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_H2=-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=dell.com header.b=Kl2vEQxW; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=RaeXSM8R
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 tuSpJzwRM2s8; Thu, 9 Apr 2020 06:46:58 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 1C5D53A0B9E; Thu, 9 Apr 2020 06:46:57 -0700 (PDT)
Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 039DhKYM009385; Thu, 9 Apr 2020 09:46:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=XI9PLFHLPX5youo4qeA0d0YfugawRadAxOVFTHVhrgQ=; b=Kl2vEQxWdkJRNlK8lsOthWWRGFyUouCBoatBSK3wgbI6KgWcWNjJ4gZNHKmFcqdtwlw/ K2WdKBtJitQoxNjN2rXdNADJoC6UDaelzJm1kX08JvtaUa6E832qQ5sPCX3EBln/VFkk tyVpA9klTfANtAyOpoCc2bf3lbtAc8BxS49oCUoSsG91qhJDvoARxBGWEEZc/RPlW63E 24/pgIwnUyY4s9j52+w0j77dmKFO+ZxikbOtByDVPh0v8v0HPFRH1png+s/GBtswFfh6 b9gipq2PEevO3chdFGw0JIjRe3A141DNkqVmuxAPyjHd4k9RctvpxEeL0d4j1SOoxUUz cQ==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 3091pv9a3s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Apr 2020 09:46:56 -0400
Received: from pps.filterd (m0090351.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 039DhJkA029315; Thu, 9 Apr 2020 09:46:55 -0400
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2168.outbound.protection.outlook.com [104.47.56.168]) by mx0b-00154901.pphosted.com with ESMTP id 3091prbj9g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 09 Apr 2020 09:46:55 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MSkS8SOTAI3xPpgUiBcklyNoFrdfoVK+1M6wJdE6MBjcPPuJynjVop+g+C1UiN8XsRVJGVyoIvJKkExpQgGT8u0CZ5JXpbXV6HSblqESJlcn5IeGOz89fHe0dmzHDE6Jx6DEUAn+BHkf2wVkUzwe3iilADmNF5u4naERlJkvkh7ky31a3nCoY1If6EYu17Dv5vLi/JfNiKaiRXmRiZbTdeMP5xp0lgdE1X0i9hvslYdl2oo8CejMT7dOaPJ+PR1NYJWOM6Dbjm//yGOzk9IMS4W0rvXJzVIlRhTrb7DYKC5SvKTHe8I3pKVWtKXh8qf9gKCrrKp2XrS2m/r/IxRG9w==
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=XI9PLFHLPX5youo4qeA0d0YfugawRadAxOVFTHVhrgQ=; b=ZY+iMUk5n4aAHVUuSsb7cTnqUp8Aw864K+3bMrZREISndCrcQH9pYRXdutFXL26AGzBjp7ZH+8rB84UIqSOfigQpcocY+LuUrk2ERReCedHc+K4FHn1aPigDCMBSkd8H3PpjMqaIGcEupqNHWpV8dgoLrQ3NBUCGXlIhn0OT90mjc5ROsP87gSk8p4FjawVCsPtIKTtysmJEFAvz3c8gY94x3tg/UGLOUjU98ViyrdH2d2jMe/XNXX/UbsHz/sxyAMkEO3egNubQqV8w8tI6MX/UZ3Q92fz7U1UmmqpFY0UZrfrFUEfzmCB520MlnvnElwlq1lqOx5aPp7Ypp1GI6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XI9PLFHLPX5youo4qeA0d0YfugawRadAxOVFTHVhrgQ=; b=RaeXSM8R+661zqk1QdJE/4u9xY19/pbX4qYIoi3PeTu24Es5Pil2YmNkoMei/JfFZUG6+RUNCdEYam59jJFvBy4w10YVKMVHP6SzajKnvzJubo8VDPGpqxP0t73o6kD1K4eP3dkSGaxqx9KFNx0O90TWWZEMsocdbXnHD4JmqSU=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB2749.namprd19.prod.outlook.com (2603:10b6:208:f0::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Thu, 9 Apr 2020 13:46:53 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd%3]) with mapi id 15.20.2878.022; Thu, 9 Apr 2020 13:46:53 +0000
From: "Black, David" <David.Black@dell.com>
To: Robert Wilton <rwilton@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-tsvwg-datagram-plpmtud@ietf.org" <draft-ietf-tsvwg-datagram-plpmtud@ietf.org>, "tsvwg-chairs@ietf.org" <tsvwg-chairs@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Wesley Eddy <wes@mti-systems.com>, "Black, David" <David.Black@dell.com>
Thread-Topic: Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-19: (with COMMENT)
Thread-Index: AQHWDmJsJV2Nuop06U2RNge1Px4VcKhwzF4g
Date: Thu, 9 Apr 2020 13:46:53 +0000
Message-ID: <MN2PR19MB4045F4E4A42E265060ACDF5D83C10@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <158643188869.14599.10200280561577318227@ietfa.amsl.com>
In-Reply-To: <158643188869.14599.10200280561577318227@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-04-09T13:41:31.6955539Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 47d7a022-b352-43d3-42ef-08d7dc8c7662
x-ms-traffictypediagnostic: MN2PR19MB2749:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB2749D2A6F2D9A9DC0A404ACD83C10@MN2PR19MB2749.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0368E78B5B
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(376002)(346002)(396003)(5660300002)(54906003)(316002)(66476007)(6506007)(53546011)(110136005)(86362001)(66946007)(478600001)(966005)(786003)(186003)(64756008)(2906002)(76116006)(4326008)(52536014)(107886003)(66556008)(33656002)(9686003)(8936002)(7696005)(71200400001)(81166007)(26005)(8676002)(66446008)(81156014)(55016002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: qL79DCnmARDorIMd5/SCfhJG3HZBcX035QBGWDGpzn74RPC1na5UVOWcoFSUo8bUZ6i7icIJUSNhSA04fO/hnmao2BNzm9+fwVQPrQjdVZegox95GdBxnAjCioR03SDTjiXUak+35Pc0AJC05jb5Ca5He6RgKpt4YNfTeMmA8fGE4kmgy0s/oTKa9AD3RsT3XsmTmWpXFpFCE/ve8hmgdAvRJASydrBc555GnHsNp6+eIkfqJVKgoCyYwip3yeB0maGggMjSRgF2+ubxkjTXOmdD5n2/O+Pv1LSKxqXcLk43UBdUiVI3pSbrorHKJMmegdLVdA5mxLGq3+D8tj9hkDw1WMAYXwYuucsPZ/01VJdLrcXJZIzR4q4J3W+px+A+5Khz9hYJXFtQR0IqYQzrTWEmM40bD/KBwEYK4dxfgmshQ/kvGEkrvskJ5Sq4vzuAPktoGBnyg+T8CfiEHciZqOMC0dbcAqkvj+ZDA1kXO+aMF89exlDeEQYVVXj0Oi375xwLcGtw8ODc/2sntYD/Tg==
x-ms-exchange-antispam-messagedata: 2R30eN5EWrcXUwMhTzcj+H2Zrkw/6yf40aUkJ8mPCFGlRLLxTp/iVrssbHJoZpb7hqLUgutWLtFL2iKKQPVLWt8SX8wtJZuTVtbTbczf/oQNMWepQseZSFzMTuIZXhUsbbYH/heoY4PQTlxHAb/UaQ==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 47d7a022-b352-43d3-42ef-08d7dc8c7662
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2020 13:46:53.4503 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mMmw4W7aq4eQCtTrQpkdCB7i6ImCiKsQQw/ql61TXjbNu567qbHPYefK1m8i0zAlAQTKDPIiHZ+SkW3qB/ZXzg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB2749
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-09_04:2020-04-07, 2020-04-09 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 suspectscore=0 lowpriorityscore=0 impostorscore=0 adultscore=0 spamscore=0 mlxlogscore=707 malwarescore=0 bulkscore=0 phishscore=0 priorityscore=1501 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004090106
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 adultscore=0 clxscore=1015 mlxscore=0 phishscore=0 impostorscore=0 priorityscore=1501 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=830 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004090107
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/UiRTclx_3lYA4QDJIq5ifPRgakE>
Subject: Re: [tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-19: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 13:47:04 -0000

Hi Robert,

Commenting as an individual on this idea:

> Not the subject of this document, but it feels like life could be significantly
> simpler if somehow there was a mechanism to getting a set of agree a set of
> defined minimum PLPMTU that network may support.  E.g. perhaps 1280, 2000,
> 4000, 8000, 16000 octets.   My assumption here is that the underlying core link
> MTUs would be higher to cope with header overheads.

That would indeed be nice, but the plethora of tunnels and encapsulations in use suggests that boundary effects could result in the packet size settling to an MTU considerably smaller than possible.  For example, suppose that the underlying link is sized to support a 4000 byte MTU with some set of headers to which a tunnel that the link designers didn’t consider adds 64 bytes - having the MTU drop to 2000 bytes would not be a good result.

Thanks, --David (as an individual)

> -----Original Message-----
> From: Robert Wilton via Datatracker <noreply@ietf.org>
> Sent: Thursday, April 9, 2020 7:31 AM
> To: The IESG
> Cc: draft-ietf-tsvwg-datagram-plpmtud@ietf.org; tsvwg-chairs@ietf.org;
> tsvwg@ietf.org; Wesley Eddy; wes@mti-systems.com
> Subject: Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-
> 19: (with COMMENT)
> 
> 
> [EXTERNAL EMAIL]
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-tsvwg-datagram-plpmtud-19: 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-tsvwg-datagram-plpmtud/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Firstly I would like to say thank you for writing this document.
> 
> I have a general concern, not specifically with this document, but with the
> overall complexity of the solution.  I.e. the algorithm that is described has
> to contend with a lot of unreliable information (e.g. are packets dropped
> because of congestion or some other routing failure, hard to know whether PTB
> messages can be relied upon etc), there are also several different ways that
> the probes can be sent etc.
> 
> Not the subject of this document, but it feels like life could be significantly
> simpler if somehow there was a mechanism to getting a set of agree a set of
> defined minimum PLPMTU that network may support.  E.g. perhaps 1280, 2000,
> 4000, 8000, 16000 octets.   My assumption here is that the underlying core link
> MTUs would be higher to cope with header overheads.
> 
> A few comments on specific sections of the document:
> 
> 1) I would include PTB in the terminology section.
> 
> 3. Features Required to Provide Datagram PLPMTUD
> 
> Most of the the requirements in this section use RFC 2119 language, but a few
> don't:
> 
>    7.   Probing and congestion control: The decision about when to send
>         a probe packet does not need to be limited by the congestion
>         controller.  When not controlled by the congestion controller,
>         the interval between probe packets MUST be at least one RTT.  If
>         transmission of probe packets is limited by the congestion
>         controller, this could result in transmission of probe packets
>         being delayed or suspended during congestion.
> 
> Rather than "does not need to be limited", would this be better stated as
> "SHOULD NOT be limited" or "MAY not be limited"?
> 
>    11.  Probing and flow control: Flow control at the PL concerns the
>         end-to-end flow of data using the PL service.  This does not
>         apply to DPLPMTU when probe packets use a design that does not
>         carry user data to the remote application.
> 
> The second sentence could be stated something like:
> 
> "Flow control MUST NOT apply to DPLPMTU when probe packets use a design
> that
> does not carry user data to the remote application"
> 
> 5.1.2.  Constants
> 
>    MIN_PLPMTU:  The MIN_PLPMTU is the smallest allowed probe packet
>       size.  For IPv6, this value is 1280 bytes, as specified in
>       [RFC8200].  For IPv4, the minimum value is 68 bytes.
> 
> Does it really make sense to probe for a path MTU of 68 bytes.  Would it make
> sense for applications to be able to control the MIN_PLPMTU that they find
> acceptable?  E.g. if IPv6 has this at 1280 and QUIC has uses 1280, perhaps
> many
> applications/implementations would like to use 1280 as a reasonable lower
> bound
> rather than 68 bytes?
> 
>