Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt

"Felipe Garrido (fegarrid)" <fegarrid@cisco.com> Mon, 14 September 2020 14:28 UTC

Return-Path: <fegarrid@cisco.com>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF66B3A0A69 for <tram@ietfa.amsl.com>; Mon, 14 Sep 2020 07:28:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JQ1u7Tsb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=P0mlhGfp
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 SuXNrr-HoU7F for <tram@ietfa.amsl.com>; Mon, 14 Sep 2020 07:27:59 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7693A0A66 for <tram@ietf.org>; Mon, 14 Sep 2020 07:27:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40051; q=dns/txt; s=iport; t=1600093678; x=1601303278; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xzDzoa4JPkWD6DVpT6s8ANRUYXmNzPbx2mBKoh6j3GM=; b=JQ1u7TsbrDkpehnN0v+WVKYQmCEuGUwMdBk9oPuw9ZLDeJXiViTrro0Q SGDAG6EhInS3Xce/tIUYHE0aea7H/sB7R8J44KnMyb0QWnpn6+tGPT4xo TGgoaqC3hd4ilcY/3+MtJL/40BcGZBR72Y9EcV7J45bVEpb/8ZhrZBAlA 4=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ah+6lMBR31W5bkWe/wFhVHKe0Sdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJ5uhLzePcv6amUGdG/JXS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh4CQdXB?= =?us-ascii?q?z1OQwzL++zB42Bx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAADffF9f/4YNJK1gDg0BAQEBAQE?= =?us-ascii?q?BAQUBAQESAQEBAwMBAQGBewYBAQELAYEiL1EHcFkvLAqEL4NGA4RZiRWYcoE?= =?us-ascii?q?ugSUDVQsBAQENAQEYAQoKAgQBAYRLAheCEAIkNAkOAgMBAQsBAQUBAQECAQY?= =?us-ascii?q?EbYVcDIVyAQEBAQMBARARHQEBLAsBDwIBCBEDAQIhBwMCAgIlCxQJCAIEAQ0?= =?us-ascii?q?FCRmDBAGBfk0DLgEOqkkCgTmIYXaBMoMBAQEFgTMBAwIOQUOCYBiCEAmBOAG?= =?us-ascii?q?CcINphAeCSxuBQT+BESccgk0+glELAQEBAQEBFYFdCQ0JCIJZM4Itj2ISgzO?= =?us-ascii?q?GcItykQEKgmWIbpFPAx5XgjKBJ4hOhTeON5JegXGIZYYEjwkCBAIEBQIOAQE?= =?us-ascii?q?FgVQ6KoEXDwdwFRohKgGCPglHFwINjh8MF4NOhRSFBD50AjUCBgEJAQEDCXy?= =?us-ascii?q?NEC2BBgGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.76,426,1592870400"; d="scan'208,217";a="813528104"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Sep 2020 14:27:56 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 08EERuHs001673 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Sep 2020 14:27:56 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Sep 2020 09:27:55 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 14 Sep 2020 09:27:55 -0500
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 14 Sep 2020 09:27:55 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DWhv37Io/C7GFI+dd8bNcqV/JR76hAqTqqUGiSBCQiEddrig9CIvDPP5OAkBfD1OPXlkpm73sVZpvzBpa3jg5ReZntceUhET+l/VEqAJVRq0No0xhG2/cJWui6FA7fgoG9YKaH19drKePHoo9VPhbgQ9jXuS5q8lKjQLuGPk3sM9aEO76+sv2NOX5T6NBGvV+AE3CT5yNSJA4QuVfaREbi1CfvvSqWtvsMO350lEZOAm3K6q3OSyXiGM75nT9adNN2NnsqMiABsiMZjEIBFNR++LojWJNfuJ8pz9/xv9K0XmzQV4KRHeTkX1lK1SSGKgn+bLAiwduw2TYEEFusWt4g==
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=xzDzoa4JPkWD6DVpT6s8ANRUYXmNzPbx2mBKoh6j3GM=; b=futNNw0Mkm/MrGx+Lqwzhiuy26aNKJB7GR3IW66lfxEIJiB3ffxWwG6Y5uohgJLGqutIWfwi6DazBKN1Op7LyKnI/9CneORzfr+sD6uQc3ZyBnF6bF5sXEKvbxf5xszekYp1mGvAQ3s/Zn6X723sZ+Eo/3XfJLIM1s92jMm32D6KDrGCjBsIjzzcjBKYJ21kSbrYOd90lo1CI8+cX6ENKxH9/wLVimgYVPg6vZM/1TT6tryFrMgZ0aj1kgf2zUm/Nr2/64Fk+xCBcIueqdaGy2uIuU1T3sxgofxz+uZy4cDPghgiWpUBW7DRKDfrJZ1vPnhqydAC5DOYexby2wSiFQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xzDzoa4JPkWD6DVpT6s8ANRUYXmNzPbx2mBKoh6j3GM=; b=P0mlhGfpmV8keOkpB+Qf61WzvknWYcthiMrQUSjaR2I2dnw8xBtyWhZs4wRusnJrQ7BDBbTJkiJi5LeoYkcE2I/xNc1y+sRrAZhtxCIVv8jEif3px9RTndhJLPbl3KWBkHHB6uQqLYaJNkkuO+/gjlIqknZmOiqEGVc63Eu/TW4=
Received: from BN7PR11MB2850.namprd11.prod.outlook.com (2603:10b6:406:b3::31) by BN6PR1101MB2147.namprd11.prod.outlook.com (2603:10b6:405:57::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3370.16; Mon, 14 Sep 2020 14:27:54 +0000
Received: from BN7PR11MB2850.namprd11.prod.outlook.com ([fe80::5cc5:d39d:2bf3:43cd]) by BN7PR11MB2850.namprd11.prod.outlook.com ([fe80::5cc5:d39d:2bf3:43cd%5]) with mapi id 15.20.3370.019; Mon, 14 Sep 2020 14:27:54 +0000
From: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tram@ietf.org" <tram@ietf.org>
CC: "gorry@abdn.ac.uk" <gorry@abdn.ac.uk>
Thread-Topic: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
Thread-Index: AQHWWeIlRauY1NbH+kWmz7M1LUhM7KkmQDOAgAGIp4CAF7oBgIAozMiA
Date: Mon, 14 Sep 2020 14:27:54 +0000
Message-ID: <41CA9214-D8C3-4A40-BAB7-43BD40F40A63@cisco.com>
References: <7c201e29-1a63-39ed-cdd9-3b8b9ac383e6@erg.abdn.ac.uk> <860e8240-ce51-5407-4187-92478262f87c@erg.abdn.ac.uk> <179FB260-1FAC-419B-B5F4-86F850177C97@cisco.com> <04b71d3e-1c79-cdc1-5b20-906732ffa768@erg.abdn.ac.uk> <025EEF1A-A751-4A45-A36F-70CCC043255C@cisco.com>
In-Reply-To: <025EEF1A-A751-4A45-A36F-70CCC043255C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.40.20081000
authentication-results: erg.abdn.ac.uk; dkim=none (message not signed) header.d=none;erg.abdn.ac.uk; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [173.38.117.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c0550906-519e-43b6-f717-08d858ba5e57
x-ms-traffictypediagnostic: BN6PR1101MB2147:
x-microsoft-antispam-prvs: <BN6PR1101MB2147981702D2409068FA0851C8230@BN6PR1101MB2147.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1nAuGyzhOO97/iy3DJbgOWsK409Vg/ISuGbtmx6TXalHqno9nxuiQCBlDymIuDokOwgBWE923ZaWdo00cGzy59ylOpSXAmivCTzQv0F59hBVqZmktHNqQHdh5TukeKFtlhiBMsfKtO1SK/u/DeG6qUlqgj7kUV/FuyZ/e682pdE0AM/tQ/BzqMajYCdApgwkrsmdsxyqhUDkJCkegNgSpLIE9//slwqIJthJHBZytJmOQYDGNUZ47rzcAJWhTCNF8Wkn1bIs7kwbEVzidE/6N3R812Wv4UMBgr30mNcOpIp8yUoD6Q8V9WeF1r3KggdF9UwofAFkpsuxQQw5eDcnPD/cr5LC3zIsbda8FCjljuzF7zI/M1/ygxnmg2ckW64wbCibZcuQg4zxiUXvMP3zfQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2850.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(346002)(136003)(396003)(39860400002)(5660300002)(110136005)(6512007)(316002)(296002)(6486002)(71200400001)(2616005)(66574015)(66476007)(478600001)(8936002)(66556008)(2906002)(53546011)(64756008)(66446008)(36756003)(6506007)(26005)(8676002)(66946007)(83380400001)(33656002)(9326002)(76116006)(91956017)(86362001)(21615005)(186003)(966005)(166002)(4326008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: x0JbGaLLV34giTuA0DmQdlzeHClLyZRrTTzesscqEU6McPtIG2Dx+T8PwKokQogBi/74Vh7AiGh+NkPUcfuTIHjNvq28b4mj1oacawS5ma7Lw0w6sK/BrM7I8Ay+Q78iBPV/9KnBTTVaCYxx/fatKCCxf6rnNN50iGGGOuir2Q2ZtYLhn54Lqp/XrVnxDUAGQAh3EBZHN852TzJGC20NaX7q0UKKxcPcgqteEeovaF/VAaM2OnzO3+6VJpR5XbegZaFRosjMZCwb6noDbvXE/HFHCk6kYqWUN09/B5tsjipCmG7JzIAMS+vaYuQ1MsOhFXVJjwfeGGpzAJVbjM+COTAmbEFzsI6+foTrGfnqPvSeSbMe578xXq8RzlC6s+ArONbF6sgIfgKrC5fnlEyTjjf3lh2wk2HP2fnlWBHW5WkraVGqJEc7tRbVq8hneWyx8Iv5mR3alLzJp0GZUOoPhyowgRj7kgGH/HG4f+NXCnO8t+CdGyy6/0089nghyUHj3DtESO00A1jU69gY8b6eVELwpSfgbiUAviyM6WSISbfo88ox5CM947yVih09hFEYQ13r4ks7CmPhf9Hu2bKUd8omYPRKT+NlZhpOM2L2Mn8OQF69gg/ePqGqSULMIwA0FRf+QW2WiVi/y0CeP4zdgg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_41CA9214D8C34A40BAB743BD40F40A63ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2850.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c0550906-519e-43b6-f717-08d858ba5e57
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2020 14:27:54.1400 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +LUjBqOAixNMxdsCvw5zvKXpbMqyibC81qNrkIh/hjhwosu0p2SgPoNPfaoPBJh9gupbcEZt7bkAdPuyvx/a/g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2147
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/cTJBbAu0S7vYAtcj4ity89d5rM8>
Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2020 14:28:02 -0000

Hi Gorry,

Have you had a chance to review the latest draft?

Thanks,
-Felipe

From: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>
Date: Wednesday, August 19, 2020 at 11:24 AM
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>uk>, "tram@ietf.org" <tram@ietf.org>
Cc: "gorry@abdn.ac.uk" <gorry@abdn.ac.uk>
Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt

Hi Gorry,

Version 18 has been published with the changes mentioned below.  To make sure readers are aware, can you add an informative reference to stun-pmtud in the tsvwg-datagram-plpmtud draft?

Thanks,
-Felipe

From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Date: Tuesday, August 4, 2020 at 5:05 AM
To: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>om>, "tram@ietf.org" <tram@ietf.org>
Cc: "gorry@abdn.ac.uk" <gorry@abdn.ac.uk>
Subject: Re: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt



On 03/08/2020 14:39, Felipe Garrido (fegarrid) wrote:
Hi Gorry,

Thank you for the comments. Responses are in-line.

Thanks,
-Felipe

From: tram <tram-bounces@ietf.org><mailto:tram-bounces@ietf.org> on behalf of Gorry Fairhurst <gorry@erg.abdn.ac.uk><mailto:gorry@erg.abdn.ac.uk>
Date: Tuesday, July 14, 2020 at 9:24 AM
To: "tram@ietf.org"<mailto:tram@ietf.org> <tram@ietf.org><mailto:tram@ietf.org>
Cc: "gorry@abdn.ac.uk"<mailto:gorry@abdn.ac.uk> <gorry@abdn.ac.uk><mailto:gorry@abdn.ac.uk>
Subject: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt


I had a look at draft-ietf-tram-stun-pmtud-17 with respect to the last comments, and saw some changes and I have a few comments. These comments are sent to the TRAM mailing list,

Gorry

---

Section 2 does not discuss the frequency of the probe. This is a congestion control case, and the method needs to assert some guidance/requirements on the probing. Do probe packets count against cwnd when using this method?

In section 4.1.
I think this is misleading, and not a feature of the simple method:
“   Note: Routers can be configured to clear the DF bit or ignore the DF
   bit which can be difficult or impossible to detect if reassembly
   occurs prior to receiving the packet, rendering PLPMTUD inaccurate.
“
- I wouldn’t call this inaccurate? If the path contains a link-layer (or tunnel or anything) that fragments and reassembles - then the path MTU is whatever size that assembly is performed to. It has always been this way, if links fragment and reassemble, IP uses the reassembled size.




--
Updated the Note as follows.

“   Note: Routers can be configured to clear the DF bit or ignore the DF
   bit which can be difficult or impossible to detect if reassembly
   occurs prior to receiving the packet.”


Sure. I'd actually suggest /might be configured/ to /can be configured/... I'm not sure any RFC should do this according to the spec.



In section 4.2.2.  Receiving an ICMP Packet
This ID currently recommends “ Validation SHOULD be performed on the ICMP
   packet as specified in [RFC8085].”
- Since this is a method above UDP, I think this implicitly also checks the UDP port information, hence this recommendation actually is an unavoidable consequence when using a normal stack - if you have one that forwards ICMP to the socket.

This becomes a requirement (or is always true) in dplpmtud:
- “Any received PTB message MUST be validated before it is used to update the PLPMTU discovery information”.
- Should this be a requirement in this spec, to avoid off-path attack?

--
I agree. Updating to,

“ Validation MUST be performed on the ICMP  packet as specified in [RFC8085].”
OK, or refer to the DPLPMTUD Spec - where the details are explain?




In section 4.2.5
“It could have been possible to use the checksum generated in the UDP
   checksum for this, but this value is generally not accessible to
   applications.  Also, sometimes the checksum is not calculated or is
   off-loaded to network hardware.“
- I do not agree this could be used (even if the checksum was returned to user space), and think it suggests something that isn’t possible. The UDP checksum includes the pseudo header information, including the ports. Wouldn’t this make the method very fragile in the face of NAPT?

--
Removing this paragraph in its entirety.
Thanks



In section 5:
I don’t yet see changes in this version to section 5.
“The PMTUD mechanism described in this document is intended to be used
   by any UDP-based protocols that do not have built-in PMTUD
   capabilities, irrespective of whether those UDP-based protocols are
   STUN-based or not.  So the manner in which a specific protocol
   discovers that it is safe to send PMTUD probes is largely dependent
   on the details of that specific protocol, with the exception of the
   Implicit Mechanism described below, which applies to any protocol."

- Please see comments made in the previous last call.

--
Can you be more specific on what comments were not addressed?

In section 7:

This has added a section that is a cross-reference of which sections contain information that relates to DPLPMTUD.

I see a mapping of requirements in section 7.1 to refer to the described method  with STUN. This seems like a useful addition (and appropriate). Currently this doesn’t really have enough detail to clearly see how the two sets of text relate, one might have to read both to figure out the details, and if that’s the case, maybe it should be explained up front. That could be helpful.

--
agreed. Can you provide the additional text that would satisfy your comment?

However, this does not resolve the last call questions raised about the method, and it seems to require someone to read both documents, which really  isn't that easy.

--
The addition of Section 7 does require that both drafts be read. As such, we’re moving I-D.ietf-tsvwg-datagram-plpmtud to a normative reference.



That sounds good.



Section 7.1.  Probe loss recovery -  I think understand that the probes themselves do not need to be recovered, but the text in section 7.1 does not quite say this.
--
Agreed. Updating to the following
Probe loss recovery: This requirement is fulfilled by requiring that the PADDING bits MUST be set to zero as discussed in Section 4.1.1 and Section 4.2.1 of this document. No retransmission is required as there is no user data being transmitted in the probe.


/being/is being/



Section 7.1. Section 7 doesn’t describe the implications of probing on flow control control. I’m not sure the current text is enough:
- Do probe packets count as credit to an upper layer protocol using this method?

---
Can you provide additional clarification on the request?
DPLPMTUD contains guidance on flow control and congestion control (added during the WGLC),see (10) in section 3.



---

I hope this helps,

Gorry
On 06/07/2020 15:02, Magnus Westerlund wrote:

Hi,



Gorry did have feedback on this document, and they have done some attempt

to define a DPLPMTUD mapping for their mechanism. I looked at it briefly and

think it is horrible terse with just requirements to combine sections. Which

unfortunately requires one to sit and cross reference the two documents.



I would appreciate any feedback from any of you have and if there appear some

glaring  failures or problems with things they declare out of scope etc.

Privately or publicly to the TRAM mailing list (tram@ietf.org<mailto:tram@ietf.org>).



Cheers



Magnus



On Mon, 2020-07-06 at 06:04 -0700, internet-drafts@ietf.org<mailto: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 TURN Revised and Modernized WG of the IETF.



        Title           : Packetization Layer Path MTU Discovery (PLMTUD) For

UDP Transports Using Session Traversal Utilities for NAT (STUN)

        Authors         : Marc Petit-Huguenin

                          Gonzalo Salgueiro

                          Felipe Garrido

   Filename        : draft-ietf-tram-stun-pmtud-17.txt

   Pages           : 23

   Date            : 2020-07-06



Abstract:

   The datagram exchanged between two Internet endpoints have to go

   through a series of physical and virtual links that may have

   different limits on the upper size of the datagram they can transmit

   without fragmentation.  Because fragmentation is considered harmful,

   most transports and protocols are designed with a mechanism that

   permits dynamic measurement of the maximum size of a datagram.  This

   mechanism is called Packetization Layer Path MTU Discovery (PLPMTUD).

   But the UDP transport and some of the protocols that use UDP were

   designed without that feature.  The Session Traversal Utilities for

   NAT (STUN) Usage described in this document permits retrofitting an

   existing UDP-based protocol with such a feature.  Similarly, a new

   UDP-based protocol could simply reuse the mechanism described in this

   document.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-17

https://datatracker.ietf.org/doc/html/draft-ietf-tram-stun-pmtud-17



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-pmtud-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/





_______________________________________________

I-D-Announce mailing list

I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>

https://www.ietf.org/mailman/listinfo/i-d-announce

Internet-Draft directories: http://www.ietf.org/shadow.html

or ftp://ftp.ietf.org/ietf/1shadow-sites.txt