From nobody Thu Jan 4 07:15:33 2018 Return-Path: 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 EEEBA126B72 for ; Thu, 4 Jan 2018 07:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 9f8_Arwev7n8 for ; Thu, 4 Jan 2018 07:15:29 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 C51BC1267BB for ; Thu, 4 Jan 2018 07:15:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.45,507,1508796000"; d="scan'208,217";a="250094270" Received: from demeter.inrialpes.fr ([194.199.28.3]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jan 2018 16:15:26 +0100 From: Vincent Roca Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AD777166-588E-41DF-9F40-C1FF52624C64" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 4 Jan 2018 16:15:25 +0100 In-Reply-To: Cc: Vincent Roca , "tsvwg@ietf.org" To: "Black, David" References: X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 15:15:31 -0000 --Apple-Mail=_AD777166-588E-41DF-9F40-C1FF52624C64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello everybody, > * Please send an email to this list if you would like to see this work = adopted in TSVWG, or you have comments on the suitability for adoption. > =20 > * Please indicate if you are willing to REVIEW such a document during = its development. As I said during IETF100 meeting, I support this I-D adoption and agree = to review it. Cheers, Vincent= --Apple-Mail=_AD777166-588E-41DF-9F40-C1FF52624C64 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello= everybody,

* Please send an email to this list if you would like = to see this work adopted in TSVWG, or you have comments on the = suitability for adoption.

 

* Please indicate = if you are willing to REVIEW such a document during its = development.


As= I said during IETF100 meeting, I support this I-D adoption and agree to = review it.

Cheers,

  Vincent
= --Apple-Mail=_AD777166-588E-41DF-9F40-C1FF52624C64-- From nobody Fri Jan 5 12:59:36 2018 Return-Path: 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 E90B112D87D for ; Fri, 5 Jan 2018 12:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 (1024-bit key) header.d=dell.com header.b=sGBvP9m6; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=Wdqf6gyI 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 0z-9_8ntv6Sy for ; Fri, 5 Jan 2018 12:59:32 -0800 (PST) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (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 C1E571241F5 for ; Fri, 5 Jan 2018 12:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1515185795; x=1546721795; h=from:cc:to:subject:date:message-id:mime-version; bh=hopPJXcyPMU/ro6vFJ9pmY2Jb816nVLogBxAl2efei0=; b=sGBvP9m6RDqVrR933eWtNu0KyWFZLH9GJ1lQ6wcVNSpq6zNmtuBOcqDt rqRF3k+twX+8rOkw9cB1qFFYX/uAZB/z9OB+7rXFpyFTzzdPNAZASfEGN sLqaAzn8ZZ5k27iF7rCiFUDbJoyeyHUwRGlyjHk8SLTCkOw1cgNGgfXTt 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AS6KmURJwMw8M4wagMNmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgeL/3xwZ3uMQTl6Ol3ixeRBMOHs6sC07KempujcFRI2YyGvnEGfc4EfD4+ou?= =?us-ascii?q?JSoTYdBtWYA1bwNv/gYn9yNs1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgpp?= =?us-ascii?q?POT1HZPZg9iq2+yo9JDffxhEiCChbb9uMR67sRjfus4KjIV4N60/0AHJonxGe+?= =?us-ascii?q?RXwWNnO1eelAvi68mz4ZBu7T1et+ou+MBcX6r6eb84TaFDAzQ9L281/szrugLd?= =?us-ascii?q?QgaJ+3ART38ZkhtMAwjC8RH6QpL8uTb0u+ZhxCWXO9D9QLYpUjqg8qhrUgflhi?= =?us-ascii?q?cZOTAk7GHZhM9+jKNHrx2uvBFw2ZLYbYWPOfZiYq/RY9UXTndBUMZLUCxBB5ux?= =?us-ascii?q?Y4USAuoFJ+lXs4r9q0MTphWwHwasGuLvxSJGinTr2qA03f4uER/H3AM9Bd4DrX?= =?us-ascii?q?DUo8/pO6cRSu260bfHzTHHb/9MxTj9743IfwknrPqRU7xwds/RxlMuFwPDlliQ?= =?us-ascii?q?qJLqPy+b1ugXtGib9eVgWOSygGAkswF8ujmiy8Q2hoXXiI8Z1ErI+Th5zYs7P9?= =?us-ascii?q?G0VlJ3bcO8HJdNqy2WLZV6T80hTm1ytys3xacKtYO1cSUJ0JgnyQDQZv+bf4WN?= =?us-ascii?q?5x/uV+mcLDN2hH9geL+wmgy9/Valx+HhS8W7y1NHoyVLn9TPtn0A0QHY5NKdRf?= =?us-ascii?q?tn5Eih3C6C1wXU6u5ZP085jbHbK5s9wr4okZoTrFjDEjf2mEroiK+WcV0p9faz?= =?us-ascii?q?6+v9f7nqvIKTOJFwigH6K6gundG/AfgjPQgJQmib//mz2KP58U34WLVKjvg2k6?= =?us-ascii?q?bDvJ/GIsQbo7a1Aw5T0ok99xayFzar3dcCkXUZIl9JZgiLg5XpNlzAOvz0E+uz?= =?us-ascii?q?j0m0nDdu3f/GP7nhApvXLnjElbfsZbhz5FRCyAoy0N9T/Y9ZCrUbL/3vWU/8r8?= =?us-ascii?q?HXAQE9Mwyw2eroFNJ91oYGVWKVHqCZKL/SsUOP5u83P+mMf5EVuTjyK/U+5v7h?= =?us-ascii?q?k2M5mVEHcamux5sXZyPwIvMzaVmCf2XjqtYMDWlMuRAxBqS+lEacTjF7ZnuuUe?= =?us-ascii?q?Q7/D5tW6y8CoKWDKqpibeCmG+XF4NXaioOXnyFD3bkMa+AUvwPQC6fJssnmTsB?= =?us-ascii?q?A+vyA7Q93A2j4Vepg4FsKfDZr3UV?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FZAAD/5k9ah8mZ6ERdHQEBBQELAYJKI?= =?us-ascii?q?iOBBRB0JweOLo5qhB6VDhSBPkMKI4UYAoQxPxgBAQEBAQEBAQEBAhABAQEIDQk?= =?us-ascii?q?IKCQLgjgiEUshBgYBAQEBAQEmAQEBAQEBAQEBAQEBAQEBAQEBFwI9ARIBARwwE?= =?us-ascii?q?x8aAREBGhBWFw8BBBuJQ2QBD7MVgxGHMgEBAQEBBQEBAQEcAwWEFIE2X4FXgWi?= =?us-ascii?q?CIIJXgWYBgTsBEQIBICuCLQxigjSKUIlLhViJaAYCgXuHJoJYi1iGGItXil+MB?= =?us-ascii?q?wIEAgQFAhqBPB+BGnBvUoIqgmQlgU54AYchK4EJgRcBAQE?= X-IPAS-Result: =?us-ascii?q?A2FZAAD/5k9ah8mZ6ERdHQEBBQELAYJKIiOBBRB0JweOLo5?= =?us-ascii?q?qhB6VDhSBPkMKI4UYAoQxPxgBAQEBAQEBAQEBAhABAQEIDQkIKCQLgjgiEUshB?= =?us-ascii?q?gYBAQEBAQEmAQEBAQEBAQEBAQEBAQEBAQEBFwI9ARIBARwwEx8aAREBGhBWFw8?= =?us-ascii?q?BBBuJQ2QBD7MVgxGHMgEBAQEBBQEBAQEcAwWEFIE2X4FXgWiCIIJXgWYBgTsBE?= =?us-ascii?q?QIBICuCLQxigjSKUIlLhViJaAYCgXuHJoJYi1iGGItXil+MBwIEAgQFAhqBPB+?= =?us-ascii?q?BGnBvUoIqgmQlgU54AYchK4EJgRcBAQE?= Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jan 2018 14:56:35 -0600 From: "Black, David" Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jan 2018 02:52:28 +0600 Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w05KxTnM006958 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 5 Jan 2018 15:59:30 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com w05KxTnM006958 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1515185971; bh=rdM4RRxAlR/kIYlO9kcwWJUvtsQ=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Wdqf6gyIbMtU+1zwRv62/U/uy5z2+LRayDNh8gjUoVUyk9b1pvbZ9UgAuKNkKw88M EZH5+N1yEwQU4dmcjpcYM8i02yGX8LZ1SuhKQL71qSRfplp9gGr8bpmoCO1c+s3RlO Xsn1kpLejW7skarQIvFr/sm3Z9BSdcM7XeyJQom8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com w05KxTnM006958 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd01.lss.emc.com (RSA Interceptor) for ; Fri, 5 Jan 2018 15:59:19 -0500 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w05KxJTs020384 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Fri, 5 Jan 2018 15:59:19 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0352.000; Fri, 5 Jan 2018 15:59:19 -0500 To: "tsvwg@ietf.org" Thread-Topic: Adoption call: draft-fairhurst-tsvwg-iana-dscp-registry-02 to end 22nd January 2018 Thread-Index: AdOGZTW3fzNwxL6cSgK8G+kecVQ37A== Date: Fri, 5 Jan 2018 20:59:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FF3299BMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] Adoption call: draft-fairhurst-tsvwg-iana-dscp-registry-02 to end 22nd January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 20:59:35 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FF3299BMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have another WG draft adoption call as follows: The TSVWG chairs are considering WG adoption of the draft "IANA Assignment = of DSCP Pool 3 (xxxx01) Values to require Publication of a Standards Track = or Best Current Practice RFC". This is an enabling draft that will allow the WG to assign DSCP (Diffserv C= odepoint) 1 (000001) or 5 (000101) from DSCP Pool 3 (xxxx01 values) as the = default DSCP for the Lower Effort (LE) PHB (Per Hop Behavior). As discuss= ed in the Singapore TSVWG meeting in November, the intent is to use one of = these codepoints to avoid possible problems caused by deployed network equi= pment remarking DSCPs for better than best effort PHBs/traffic to DSCP 2 (0= 00010). The need for this enabling draft in order to advance the LE PHB d= raft (draft-ietf-tsvwg-le-phb) was identified in Singapore, and Gorry volun= teered to write it. The LE PHB draft has temporarily expired due to delays= in working through this default DSCP assignment issue; an updated version = of the LE PHB draft is expected to be submitted in the near future. The chairs are now looking for input from the working group to help inform = whether TSVWG should adopt this DSCP registry draft (draft-fairhurst-tsvwg-= iana-dscp-registry-02). * Please send an email to this list if you would like to see this work adop= ted in TSVWG, or you have comments on the suitability for adoption. * Please indicate if you are willing to REVIEW such a document during its d= evelopment. Please send all notes of support/comments to the TSVWG list or the WG chair= s by the date above. Best wishes, David and Wes. (TSVWG Co-Chairs) [Gorry is recused from this adoption decision, as he is t= he author of this draft.] Abstract The Differentiated Services (Diffserv) architecture specifies use of the DSField in the IPv4 and IPv6 packet header to carry the Diffserv Codepoint (DSCP). The Internet Assigned Numbers Authority (IANA) maintains a registry of assigned DSCP values. This update to RFC2474 changes the IANA assignment method for Pool 3 of the registry (i.e., DSCPs of the form xxxx01) to Standards Action, i.e., values are assigned through a Standards Track or Best Current Practice RFC. The update also removes permission for experimental and Local Use of the codepoints that form Pool 3 of the DSCP registry; Pool 1 codepoints (i.e., DSCPs of the form xxxx11) remain available for these purposes. Reminder: There is also an outstanding WG draft adoption call on draft-fair= hurst-tsvwg-datagram-plpmtud-02 (Packetization Layer Path MTU Discovery for= Datagram Transports) that runs through next Wednesday, 10th January 2018 (= https://www.ietf.org/mail-archive/web/tsvwg/current/msg15562.html). Please= also respond to that adoption call if you are interested in WG adoption of= that draft. --_000_CE03DB3D7B45C245BCA0D243277949362FF3299BMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have another WG draft adoption call as follows:

 

The TSVWG chairs are considering WG adoption of t= he draft "IANA Assignment of DSCP Pool 3 (xxxx01) Values to require Pu= blication of a Standards Track or Best Current Practice RFC".

 

This is an enabling draft that will allow the WG = to assign DSCP (Diffserv Codepoint) 1 (000001) or 5 (000101) from DSCP Pool= 3 (xxxx01 values) as the default DSCP for the Lower Effort (LE) PHB (Per H= op Behavior).   As discussed in the Singapore TSVWG meeting in November, the intent is to use one of these cod= epoints to avoid possible problems caused by deployed network equipment rem= arking DSCPs for better than best effort PHBs/traffic to DSCP 2 (000010).&n= bsp;  The need for this enabling draft in order to advance the LE PHB draft (draft-ietf-tsvwg-le-phb) was identif= ied in Singapore, and Gorry volunteered to write it.  The LE PHB draft= has temporarily expired due to delays in working through this default DSCP= assignment issue; an updated version of the LE PHB draft is expected to be submitted in the near future.

 

The chairs are now looking for input from the wor= king group to help inform whether TSVWG should adopt this DSCP registry dra= ft (draft-fairhurst-tsvwg-iana-dscp-registry-02).

 

* Please send an email to this list if you would = like to see this work adopted in TSVWG, or you have comments on the suitabi= lity for adoption.

 

* Please indicate if you are willing to REVIEW su= ch a document during its development.

 

Please send all notes of support/comments to the = TSVWG list or the WG chairs by the date above.

 

Best wishes,

 

David and Wes.

(TSVWG Co-Chairs) [Gorry is recused from this ado= ption decision, as he is the author of this draft.]

 

Abstract

 

   The Differentiated Services (Diffser= v) architecture specifies use of

   the DSField in the IPv4 and IPv6 pac= ket header to carry the Diffserv

   Codepoint (DSCP). The Internet Assig= ned Numbers Authority (IANA)

   maintains a registry of assigned DSC= P values.

 

   This update to RFC2474 changes the I= ANA assignment method for Pool 3

   of the registry (i.e., DSCPs of the = form xxxx01) to Standards Action,

   i.e., values are assigned through a = Standards Track or Best Current

   Practice RFC. The update also remove= s permission for experimental and

   Local Use of the codepoints that for= m Pool 3 of the DSCP registry;

   Pool 1 codepoints (i.e., DSCPs of th= e form xxxx11) remain available

   for these purposes.

 

Reminder: There is also an outstanding WG draft adop= tion call on draft-fairhurst-tsvwg-datagram-plpmtud-02 (Packetization Layer= Path MTU Discovery for Datagram Transports) that runs through next Wednesd= ay, 10th January 2018 (https://www.ietf.org/mail-archive/web/tsvwg/curre= nt/msg15562.html).  Please also respond to that adoption call if you are interested in WG adop= tion of that draft.

--_000_CE03DB3D7B45C245BCA0D243277949362FF3299BMX307CL04corpem_-- From nobody Fri Jan 5 15:58:37 2018 Return-Path: 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 033F312D967 for ; Fri, 5 Jan 2018 15:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7LkVT8M2dHx4 for ; Fri, 5 Jan 2018 15:58:34 -0800 (PST) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (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 831DB1242F7 for ; Fri, 5 Jan 2018 15:58:34 -0800 (PST) Received: by mail-pl0-x233.google.com with SMTP id d21so3992611pll.1 for ; Fri, 05 Jan 2018 15:58:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=73RNBKcXWSlXITxw/LrT9ztQXaVEGwqLKGd31+m+x8s=; b=NCSs0lA75f045iZ7DENtV9i7nSzudEleTKJVaZBbC8+DlF0sWKYMYDb/FbYPaI/Mgg ysoswj3vIful6eAZesDnxxVIkFeCw6nu8sGE+t++fjlhNTtZeinORt/DVI+QyZEaia5s Ss/PqrhEVIDy9mFEvxax644xlhqDBQj63w3d7STGND78l0C3ner+KaeJusa2n8yAX3HQ Ond4U7lRPis2jQM3SkMVoqgzVja8Jq+dsnAJjdvT2JVrhe9777cZOHww9Mp0ql/PNohU FB8YrEB677kTophpDf1hEEnPX6ueWspp/+Ww6coMZkT+RQh9vFpdZrdYOumZUSMTFXcF mlmg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=73RNBKcXWSlXITxw/LrT9ztQXaVEGwqLKGd31+m+x8s=; b=YHV+GFNovZ6ZTD8242mg2tPL4k5uYqx8GqvB/sbg4+42jw8zALgWWm/ClyJxT9LacP 4q2khWbPESlKX5KiWLs+cCRNsBqRV2jeLbn6v9HePWqYnhffNEvP4B3bOc5WD0HRQz/k Fad4U3VGv8uHoX6wAjMCRNqdmVWqby3RwJRGbO9ygGyIJQKtFx+rzTnfYLFFEx2W6Wrr iBlvro70oPDcWrsQ6yMG11ioliZgWYE14tmD2MdKFwZ4aY/ui+EwiohagLYY41lrhyLb 9EyBupqxirW2N3aYT62ywYWlDflW3fTkn7CXrV81xin0antyUGZp0CMEx+FDWFCHIskN G+fg== X-Gm-Message-State: AKGB3mKB3irQu10d4PJd3EKZaZsh8XzDRu4wyusuGKU/78SWnoV5ZQx7 NOjL4XvlFxwNqieQE8GHQrTg2A== X-Google-Smtp-Source: ACJfBosKG6t9uRQ8E7ilw1ZUsKtNyy6YdSxXB5Wa852P1p0e6FRcin64fcwdzyuQTp5Bsa0NRl5Sbw== X-Received: by 10.159.241.152 with SMTP id s24mr4784205plr.229.1515196713470; Fri, 05 Jan 2018 15:58:33 -0800 (PST) Received: from ?IPv6:2406:e007:6f17:1:28cc:dc4c:9703:6781? ([2406:e007:6f17:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m13sm7620689pgs.77.2018.01.05.15.58.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jan 2018 15:58:32 -0800 (PST) To: "Black, David" , "tsvwg@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Sat, 6 Jan 2018 12:58:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-iana-dscp-registry-02 to end 22nd January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jan 2018 23:58:36 -0000 ...> * Please send an email to this list if you would like to see this work adopted in TSVWG, or you have comments on the suitability for adoption. I think this is a necessary next step, so yes to adoption. > * Please indicate if you are willing to REVIEW such a document during its development. I will. Regards Brian From nobody Mon Jan 8 05:02:54 2018 Return-Path: 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 73C7012785F for ; Mon, 8 Jan 2018 05:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 MfrqGxiwM-Zp for ; Mon, 8 Jan 2018 05:02:48 -0800 (PST) Received: from mail.mera.ru (mail.mera.ru [188.130.168.162]) (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 A9A221242F5 for ; Mon, 8 Jan 2018 05:02:48 -0800 (PST) Received: from mbx03.merann.ru ([192.168.50.73]) by mail.mera.ru with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) (Exim 4.89) (envelope-from ) id 1eYX5h-0003mD-RB; Mon, 08 Jan 2018 16:03:49 +0300 Received: from e16srv03.merann.ru (192.168.50.33) by mbx03.merann.ru (192.168.50.73) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 8 Jan 2018 16:02:43 +0300 Received: from e16srv03.merann.ru (2001:67c:2344:50::33) by e16srv03.merann.ru (2001:67c:2344:50::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Mon, 8 Jan 2018 16:02:43 +0300 Received: from e16srv03.merann.ru ([fe80::4855:646a:d15e:75f3]) by e16srv03.merann.ru ([fe80::4855:646a:d15e:75f3%12]) with mapi id 15.01.0845.039; Mon, 8 Jan 2018 16:02:43 +0300 From: "Proshin, Maksim" To: "David.Black@dell.com" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 Thread-Index: AQHTiIBCsyjl2mE4nkaio0Ly1dyIEKNp76Sc Date: Mon, 8 Jan 2018 13:02:43 +0000 Message-ID: <650fb7bc27884328b9bfcc9016fa8b73@mera.ru> References: , In-Reply-To: Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [176.213.4.1] x-inside-org: True Content-Type: multipart/alternative; boundary="_000_650fb7bc27884328b9bfcc9016fa8b73meraru_" MIME-Version: 1.0 X-Source-IF-Name: mail.mera.ru Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 13:02:51 -0000 --_000_650fb7bc27884328b9bfcc9016fa8b73meraru_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As I said during TSVWG session at IETF100, I'd like to see it adopted and I= also plan to review it. BR, Maksim ________________________________ From: Black, David > Date: Thu, Dec 14, 2017 at 11:27 PM Subject: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 t= o end 10th January 2018 To: "tsvwg@ietf.org" > I'm tardy in getting to this action item from the TSVWG meeting in Singapor= e ... The TSVWG chairs are considering adoption of the draft "Packetization Layer Path MTU Discovery for Datagram Transports". This draft has been discussed at the previous IETF meeting and on the list,= and the chairs are now looking for input from the group to help inform whe= ther TSVWG should adopt this draft. * Please send an email to this list if you would like to see this work adop= ted in TSVWG, or you have comments on the suitability for adoption. * Please indicate if you are willing to REVIEW such a document during its d= evelopment. Please send all notes of support/comments to the TSVWG list or the WG chair= s by the date above. Best wishes, David and Wes. (TSVWG Co-Chairs) [Gorry is recused from this adoption decision, as he is a= n author of this draft.] [The time period for this adoption call is longer than usual to allow for t= he winter holidays - may yours be joyous!] Abstract This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization layers. The method allows a Packetization layer (or a datagram application that uses it) to probe an network path with progressively larger packets to determine a maximum packet size. The document describes as an extension to RFC 1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for IPv4 and IPv6. This provides functionally for datagram transports that is equivalent to the Packetization layer PMTUD specification for TCP, specified in RFC4821. --_000_650fb7bc27884328b9bfcc9016fa8b73meraru_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,


As I said during TSVWG session at IETF100, I'd like to see it adopted an= d I also plan to review it. 



BR, Maksim 



From= : Black, Da= vid <David.Black@dell.com>
Date: Thu, Dec 14, 2017 at 11:27 PM
Subject: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 t= o end 10th January 2018
To: "tsvwg@ietf.org" <tsvwg@ietf.org>


I’m tardy in getting t= o this action item from the TSVWG meeting in Singapore …

 

The TSVWG chairs are conside= ring adoption of the draft

"Packetization Layer Pa= th MTU Discovery for Datagram Transports".

 

This draft has been discusse= d at the previous IETF meeting and on the list, and the chairs are now look= ing for input from the group to help inform whether TSVWG should adopt this= draft.

 

* Please send an email to th= is list if you would like to see this work adopted in TSVWG, or you have co= mments on the suitability for adoption.

 

* Please indicate if you are= willing to REVIEW such a document during its development.

 

Please send all notes of sup= port/comments to the TSVWG list or the WG chairs by the date above.<= u>

 

Best wishes,

 

David and Wes.=

(TSVWG Co-Chairs) [Gorry is = recused from this adoption decision, as he is an author of this draft.]<= /u>

[The time period for this ad= option call is longer than usual to allow for the winter holidays – m= ay yours be joyous!]

 

Abstract

 

   This document d= escribes a robust method for Path MTU Discovery

   (PMTUD) for dat= agram Packetization layers.  The method allows a

   Packetization l= ayer (or a datagram application that uses it) to probe

   an network path= with progressively larger packets to determine a

   maximum packet = size.  The document describes as an extension to RFC

   1191 and RFC 82= 01, which specify ICMP-based Path MTU Discovery for

   IPv4 and IPv6.&= nbsp; This provides functionally for datagram transports

   that is equival= ent to the Packetization layer PMTUD specification for

   TCP, specified = in RFC4821.

--_000_650fb7bc27884328b9bfcc9016fa8b73meraru_-- From nobody Tue Jan 9 03:11:47 2018 Return-Path: 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 D06CB126C83; Tue, 9 Jan 2018 03:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.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 GvDZObjPW2Og; Tue, 9 Jan 2018 03:11:39 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF2E1250B8; Tue, 9 Jan 2018 03:11:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,335,1511856000"; d="asc'?scan'208,217";a="235566614" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx144-out.netapp.com with ESMTP; 09 Jan 2018 03:11:37 -0800 Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 9 Jan 2018 03:11:37 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 9 Jan 2018 03:11:37 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WltuNfnOLppHJLSHd58+VJ2PeZvkmJcTo4ML+pdP7qU=; b=Z1iUJHIpN2/eqVyeXPzKr99Ql1oZaEptjMYT9t319JuhQmp2fXd+Stm1bGsRmjWbz1meWaNWfMpMs+y+dVbEKJvuwoHZDXimNQFIMs+N2QnTt1tGfOunr0MDwhs1aLEzk18DbCwVjeXI3inJ4spDGOrGBhxlA8ORCsAQ8SfneRA= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Tue, 9 Jan 2018 11:11:35 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0386.008; Tue, 9 Jan 2018 11:11:35 +0000 From: "Eggert, Lars" To: "Black, David" CC: "tsvwg@ietf.org" , QUIC WG Thread-Topic: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 Thread-Index: AdN1GcwEk8+6wIkTQ1++dedJ90kdDwUIM6oA Date: Tue, 9 Jan 2018 11:11:35 +0000 Message-ID: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [203.168.52.212] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 7:A7gwB3kbWWJiOrjcsz2crcDIOOb3oEpdip4rJavhVpJ0d68qGNJavXSAH2CXTuieydTdtF9WAFBqmbUr27quUN+ViqE/w0PSngfAUG67cLK8vtG/Lcgg3WNWFxVwnBXLj0jaPedernELKVRqWCpaeL+VbP44lwgTxUyjAOGAnvcJOPjzZGegHXTWAqgfRhhLtO8ZaRmMIQuOmO5k5adW5R1R/uW2zcnhA8OBEHPp3AAbAJzlLahaeZ4BtsLCmt6i x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 73fc2416-1d53-42b2-d2e4-08d55751bf20 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB1762; x-ms-traffictypediagnostic: BLUPR06MB1762: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(56004941905204); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6055026)(6041268)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1762; x-forefront-prvs: 0547116B72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39380400002)(366004)(346002)(396003)(39860400002)(24454002)(377424004)(199004)(189003)(54906003)(3660700001)(5660300001)(8936002)(53546011)(106356001)(66066001)(6436002)(50226002)(33656002)(105586002)(229853002)(478600001)(102836004)(14454004)(4001150100001)(68736007)(76176011)(3280700002)(77096006)(6486002)(53936002)(97736004)(6506007)(8676002)(8666007)(81156014)(81166006)(99286004)(7736002)(36756003)(236005)(6246003)(54896002)(6512007)(3846002)(230783001)(6116002)(2950100002)(99936001)(86362001)(2900100001)(2906002)(316002)(25786009)(83716003)(6916009)(57306001)(82746002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: rRIlvmGT2Uzx64nf5bzeQoWUjKdG8g+0K4dpP/685PsF9ANVy7HyzMDF0QgjNURscm1++PNolTourmQykUnwqQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_28AA2C8F-9ABF-434C-9A82-878B6E4A2EBC"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 73fc2416-1d53-42b2-d2e4-08d55751bf20 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 11:11:35.1016 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 11:11:41 -0000 --Apple-Mail=_28AA2C8F-9ABF-434C-9A82-878B6E4A2EBC Content-Type: multipart/alternative; boundary="Apple-Mail=_BFBC3FC4-4013-4FC1-8340-348D3832225F" --Apple-Mail=_BFBC3FC4-4013-4FC1-8340-348D3832225F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, would someone clarify what the intended relationship of the mechanism = described in the document and QUIC is? For example, is the intention = here that QUIC should implement this, is this unrelated, or anything in = between? Asking, because if there is an intended relationship, it would be good = to discuss this sooner rather than later. Thanks, Lars > On 2017-12-15, at 7:27, Black, David wrote: >=20 > I=E2=80=99m tardy in getting to this action item from the TSVWG = meeting in Singapore =E2=80=A6 >=20 > The TSVWG chairs are considering adoption of the draft > "Packetization Layer Path MTU Discovery for Datagram Transports". >=20 > This draft has been discussed at the previous IETF meeting and on the = list, and the chairs are now looking for input from the group to help = inform whether TSVWG should adopt this draft. >=20 > * Please send an email to this list if you would like to see this work = adopted in TSVWG, or you have comments on the suitability for adoption. >=20 > * Please indicate if you are willing to REVIEW such a document during = its development. >=20 > Please send all notes of support/comments to the TSVWG list or the WG = chairs by the date above. >=20 > Best wishes, >=20 > David and Wes. > (TSVWG Co-Chairs) [Gorry is recused from this adoption decision, as he = is an author of this draft.] > [The time period for this adoption call is longer than usual to allow = for the winter holidays =E2=80=93 may yours be joyous!] >=20 > Abstract >=20 > This document describes a robust method for Path MTU Discovery > (PMTUD) for datagram Packetization layers. The method allows a > Packetization layer (or a datagram application that uses it) to = probe > an network path with progressively larger packets to determine a > maximum packet size. The document describes as an extension to RFC > 1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for > IPv4 and IPv6. This provides functionally for datagram transports > that is equivalent to the Packetization layer PMTUD specification = for > TCP, specified in RFC4821. --Apple-Mail=_BFBC3FC4-4013-4FC1-8340-348D3832225F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

would = someone clarify what the intended relationship of the mechanism = described in the document and QUIC is? For example, is the intention = here that QUIC should implement this,  is this unrelated, or = anything in between?

Asking, because if there is an intended relationship, it = would be good to discuss this sooner rather than later.

Thanks,
Lars

On 2017-12-15, at 7:27, Black, = David <David.Black@dell.com> wrote:

I=E2=80=99m tardy in getting to this action item from the = TSVWG meeting in Singapore =E2=80=A6
 
The TSVWG chairs are considering = adoption of the draft
"Packetization Layer Path MTU Discovery for Datagram = Transports".
 
This draft has been discussed at the previous IETF meeting = and on the list, and the chairs are now looking for input from the group = to help inform whether TSVWG should adopt this draft.
 
* Please = send an email to this list if you would like to see this work adopted in = TSVWG, or you have comments on the suitability for adoption.
 
* Please = indicate if you are willing to REVIEW such a document during its = development.
 
Please send all notes of support/comments to the TSVWG list = or the WG chairs by the date above.
 
Best wishes,
 
David and = Wes.
(TSVWG = Co-Chairs) [Gorry is recused from this adoption decision, as he is an = author of this draft.]
[The time period for this adoption call is longer than usual = to allow for the winter holidays =E2=80=93 may yours be joyous!]
 
Abstract
 
   This document describes a robust method for Path = MTU Discovery
   (PMTUD) for datagram Packetization layers.  = The method allows a
   Packetization layer (or a datagram application = that uses it) to probe
   an network path with progressively larger = packets to determine a
   maximum packet size.  The document = describes as an extension to RFC
   1191 and RFC 8201, which = specify ICMP-based Path MTU Discovery for
   IPv4 and IPv6.  This = provides functionally for datagram transports
   that is equivalent to the Packetization layer = PMTUD specification for
   TCP, specified in = RFC4821.

= --Apple-Mail=_BFBC3FC4-4013-4FC1-8340-348D3832225F-- --Apple-Mail=_28AA2C8F-9ABF-434C-9A82-878B6E4A2EBC 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlpUo2QACgkQVLXDCb9w wVeUxxAA02NV4VwI7tM4IDmss3y6653u2FT/Td5Ca48NDDyASzkHKAeWbpTKtgdG slfDKfdMDmNfIg/p6RX5jo1CFxeKmzmDblxFSOQOCLSdxfsHYsSid/a709OJ+Ls6 lTwh7WxvPQBnQjxtaC2aRPHcoykGZfj6UX0kgolLTTbSSQpOQ1dZWDklsRcVfRGs gFSlip63b487xq3/ymL3/ChgfD5g2AmKho+Bfg+0fi3PMPQq5iXPGGMquwKww91h 4BRH39ShddiPALyfQ3SKjxXaDdG/EiaB/5sUgVBmV0LJpU/k/uKITb+hLNE0Qtp/ sD1srnOcICXpgYFgMGn0HP0OmsAMm0GYcZewtL1ewqVyRMOdKUXu4DHkBDvJBH0J l+ZFXQJW1v4IpnliRhgH7YgJH8lgkhQMbmuDxjh7jsW/3K9L5+QashTPJARVvWZJ T6rw5xu2v1GOT317cUqQ65whI1x8Iwr5c6NcBLoc6Vo+A/s9SfcdpAJw5UgQJ1/z ooG4XJgTHw44RMqnmvLRNa1BYhOv/C5U3y9mkTaS3A4noyMexZXig/QkqmhfPyup UXfB9b8HUOMZ+s/9cIHrQeR/kFtgk4ts1hLZMhue+Fw/t5UduHVK4Y3ATVA9K/zu 11hwE6BGWYMBqx3OhlXyJp/KAZ3V3IkjBaeUWZvVlWItdBb8t2s= =ulGh -----END PGP SIGNATURE----- --Apple-Mail=_28AA2C8F-9ABF-434C-9A82-878B6E4A2EBC-- From nobody Tue Jan 9 03:38:32 2018 Return-Path: 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 32E4B127369 for ; Tue, 9 Jan 2018 03:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.329 X-Spam-Level: X-Spam-Status: No, score=-4.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, T_RP_MATCHES_RCVD=-0.01] 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 12SpkNyKoEL2 for ; Tue, 9 Jan 2018 03:38:29 -0800 (PST) Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (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 8427A126DEE for ; Tue, 9 Jan 2018 03:38:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1515497908; x=1547033908; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/C62NytaGOW4yy+2y4MyY2eeMBKjcurU/KJI8FMlmVE=; b=745E1yK6kqgUPwHQT3LG5NMlul5hAxRjo9jle3u2lWXKRmkT+rCZPKel sPv00UwsCEJ/WZyO5020YpMUsbHk6kSdkTjj5Jxq0M2EDEkpjnP1Epd5n zQgGelCRhlK+PLT6+6bwk7M6BX9LLzhbrK3rtg8A5NM5CQWBlGtDmKsHG HemIwNjrbPkOY8tlfk8ypCKzQWE+O0Zfh4liJKgcyygEZGZcndkYil7Hz kW02Kj/Ct1HFkT8RY6Wm7W22BB1YthDI+ZGuB0/kVzn5PmAc/y7LAwCV0 h8VGHT7lZToYXBkA9dJyUZ8TTV8xUKN6aF2vuQ5uLpGKv1TCBl4XgO2Ws w==; Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP; 09 Jan 2018 12:38:23 +0100 X-IronPort-AV: E=Sophos;i="5.46,335,1511823600"; d="scan'208,217";a="790567799" Received: from he105667.emea1.cds.t-internal.com ([10.169.118.63]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 09 Jan 2018 12:38:22 +0100 Received: from HE101951.EMEA1.cds.t-internal.com (10.169.118.77) by HE105667.emea1.cds.t-internal.com (10.169.118.63) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Jan 2018 12:38:22 +0100 Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE101951.EMEA1.cds.t-internal.com (10.169.118.77) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 9 Jan 2018 12:38:22 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.20) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Jan 2018 12:37:57 +0100 Received: from LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.139) by LEXPR01MB0093.DEUPRD01.PROD.OUTLOOK.DE (10.158.163.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Tue, 9 Jan 2018 11:38:20 +0000 Received: from LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE ([fe80::881d:620f:1ec4:a17a]) by LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE ([fe80::881d:620f:1ec4:a17a%15]) with mapi id 15.20.0386.009; Tue, 9 Jan 2018 11:38:20 +0000 From: To: CC: Thread-Topic: Adoption call: draft-fairhurst-tsvwg-iana-dscp-registry-02 to end 22nd January 2018 Thread-Index: AdOGZTW3fzNwxL6cSgK8G+kecVQ37AC2PY/Q Date: Tue, 9 Jan 2018 11:38:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de; x-originating-ip: [164.19.3.41] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LEXPR01MB0093; 7:S39PMuzS5GlFXxPEtJGR9uKLftxelFwFij6YnZOjPHK6Fgc2rkLux0I/58I2K8U82Qrxxm5JxcU5W5M9kH/nF9W2foXahQaL04zjwcVuPMLfO/8d/S5GamZvhKmLnjUf6FuV6ibWKo5u1pTq4i9jl1Z3v//pLkdkcVlu/Yuc2v+tHTTmXTnzUT+/OXwDHvqgWxPtg4YYNZ1P+HsqmNA+spBO1EZhIp4JIBiUNffydbMLPsoL5DUaZ1PUF2/szls0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9a62e8f2-34a9-47ea-aa78-08d557557c01 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:LEXPR01MB0093; x-ms-traffictypediagnostic: LEXPR01MB0093: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:LEXPR01MB0093; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:LEXPR01MB0093; x-forefront-prvs: 0547116B72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(39380400002)(376002)(366004)(189003)(199004)(66066001)(106356001)(2906002)(2900100001)(81166006)(8676002)(3846002)(790700001)(6116002)(102836004)(7736002)(68736007)(33656002)(75402003)(8936002)(7696005)(76176011)(105586002)(81156014)(478600001)(52396003)(4326008)(53936002)(5250100002)(3280700002)(8666007)(6306002)(3660700001)(230783001)(9686003)(72206003)(5660300001)(54896002)(14454004)(316002)(6916009)(97736004)(86362001)(74482002)(55016002)(2950100002)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0093; H:LEXPR01MB0094.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:1; LANG:en; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-microsoft-antispam-message-info: TWVVNQzR9BChFsf0It9SfoQorP6nmEttKRwbGQHWx7skhqMXWL0K+M1rgGiG8UCqz9h7qEt2d3q0gzX1oUn3Pg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LEXPR01MB0094D0C1D6568EEB27AABF3C9C100LEXPR01MB0094DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9a62e8f2-34a9-47ea-aa78-08d557557c01 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 11:38:20.6645 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0093 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-iana-dscp-registry-02 to end 22nd January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 11:38:31 -0000 --_000_LEXPR01MB0094D0C1D6568EEB27AABF3C9C100LEXPR01MB0094DEUP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, * Please send an email to this list if you would like to see this work adop= ted in TSVWG, or you have comments on the suitability for adoption. I support adoption. * Please indicate if you are willing to REVIEW such a document during its d= evelopment. I'm willing to review the document. Regards, Ruediger --_000_LEXPR01MB0094D0C1D6568EEB27AABF3C9C100LEXPR01MB0094DEUP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

David,

 

* Please send an email to th= is list if you would like to see this work adopted in TSVWG, or you have co= mments on the suitability for adoption.

 

I support adoption.

 

* Please indicate if you are= willing to REVIEW such a document during its development.

 

I’m willing to review = the document.

 

Regards,

 

Ruediger

 

 

--_000_LEXPR01MB0094D0C1D6568EEB27AABF3C9C100LEXPR01MB0094DEUP_-- From nobody Wed Jan 10 06:16:48 2018 Return-Path: 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 1C2C01270AE for ; Wed, 10 Jan 2018 06:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 du5KSUxDIxEB for ; Wed, 10 Jan 2018 06:16:45 -0800 (PST) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8DB12420B for ; Wed, 10 Jan 2018 06:16:45 -0800 (PST) Received: by accordion.employees.org (Postfix, from userid 1736) id 85E962D5085; Wed, 10 Jan 2018 14:16:44 +0000 (UTC) Date: Wed, 10 Jan 2018 14:16:44 +0000 From: Derek Fawcus To: "Eggert, Lars" Cc: "Black, David" , "tsvwg@ietf.org" Message-ID: <20180110141644.GA70621@accordion.employees.org> References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> User-Agent: Mutt/1.9.1 (2017-09-22) Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 14:16:47 -0000 On Tue, Jan 09, 2018 at 11:11:35AM +0000, Eggert, Lars wrote: > Hi, > > would someone clarify what the intended relationship of the mechanism described in the document and QUIC is? For example, is the intention here that QUIC should implement this, is this unrelated, or anything in between? > > Asking, because if there is an intended relationship, it would be good to discuss this sooner rather than later. Similarly in section 1 (para 1 & 9) mention is made of its applicability to DCCP, but then nothing is mentioned about it subsequently. Should this document also cover the details for DCCP at the same level as for UDP? DF From nobody Wed Jan 10 07:33:09 2018 Return-Path: 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 1FF1812D7F3 for ; Wed, 10 Jan 2018 07:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 zhb6rTKIKHAx for ; Wed, 10 Jan 2018 07:33:06 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id F416A12751F for ; Wed, 10 Jan 2018 07:33:05 -0800 (PST) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id ADA031B00237 for ; Wed, 10 Jan 2018 15:32:33 +0000 (GMT) Message-ID: <5A563210.3050605@erg.abdn.ac.uk> Date: Wed, 10 Jan 2018 15:32:32 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <20180110141644.GA70621@accordion.employees.org> In-Reply-To: <20180110141644.GA70621@accordion.employees.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 15:33:08 -0000 On 10/01/2018, 14:16, Derek Fawcus wrote: > On Tue, Jan 09, 2018 at 11:11:35AM +0000, Eggert, Lars wrote: >> Hi, >> >> would someone clarify what the intended relationship of the mechanism described in the document and QUIC is? For example, is the intention here that QUIC should implement this, is this unrelated, or anything in between? >> >> Asking, because if there is an intended relationship, it would be good to discuss this sooner rather than later. > Similarly in section 1 (para 1& 9) mention is made of its applicability to DCCP, > but then nothing is mentioned about it subsequently. > > Should this document also cover the details for DCCP at the same level as for UDP? > > DF The DCCP Spec includes content on PMTUD, therefore it's not quite the same case as UDP, but the concepts of probing coild be applicable - although I do not know of any DCCP implementation that considered PMTUD. I'd be happy to thinkl about inputs from people using DCCP - speak up if there are key issues that you're experiencing with PMTU discovery and DCCP or with DCCP/UDP. Gorry From nobody Wed Jan 10 07:39:35 2018 Return-Path: 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 555F212D862; Wed, 10 Jan 2018 07:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 FXp2wHXeUCDN; Wed, 10 Jan 2018 07:39:32 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id BE1C212751F; Wed, 10 Jan 2018 07:39:32 -0800 (PST) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 43C021B00062; Wed, 10 Jan 2018 15:38:56 +0000 (GMT) Message-ID: <5A563390.8050403@erg.abdn.ac.uk> Date: Wed, 10 Jan 2018 15:38:56 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Eggert, Lars" CC: "Black, David" , QUIC WG , "tsvwg@ietf.org" References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> In-Reply-To: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 15:39:34 -0000 On 09/01/2018, 11:11, Eggert, Lars wrote: > Hi, > > would someone clarify what the intended relationship of the mechanism > described in the document and QUIC is? For example, is the intention > here that QUIC should implement this, is this unrelated, or anything > in between? > The work originates from updates to the IPv6 base spec, and the need to consider how to do PLPMTUD for transports other than TCP. There's practical code for UDP-Options, and SCTP, and that is presently evolving with the Spec. I suspect someone could use the final method with QUIC - since it's also a UDP-based transport. I don' knopw of anyone planning PMTUD for QUIC - please get in touch if that is on your radar. > Asking, because if there is an intended relationship, it would be good > to discuss this sooner rather than later. > Thanks, > Lars > Best wishes, Gorry >> On 2017-12-15, at 7:27, Black, David > > wrote: >> >> I’m tardy in getting to this action item from the TSVWG meeting in >> Singapore … >> The TSVWG chairs are considering adoption of the draft >> "Packetization Layer Path MTU Discovery for Datagram Transports". >> This draft has been discussed at the previous IETF meeting and on the >> list, and the chairs are now looking for input from the group to help >> inform whether TSVWG should adopt this draft. >> * Please send an email to this list if you would like to see this >> work adopted in TSVWG, or you have comments on the suitability for >> adoption. >> * Please indicate if you are willing to REVIEW such a document during >> its development. >> Please send all notes of support/comments to the TSVWG list or the WG >> chairs by the date above. >> Best wishes, >> David and Wes. >> (TSVWG Co-Chairs) [Gorry is recused from this adoption decision, as >> he is an author of this draft.] >> [The time period for this adoption call is longer than usual to allow >> for the winter holidays – may yours be joyous!] >> Abstract >> This document describes a robust method for Path MTU Discovery >> (PMTUD) for datagram Packetization layers. The method allows a >> Packetization layer (or a datagram application that uses it) to probe >> an network path with progressively larger packets to determine a >> maximum packet size. The document describes as an extension to RFC >> 1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for >> IPv4 and IPv6. This provides functionally for datagram transports >> that is equivalent to the Packetization layer PMTUD specification for >> TCP, specified in RFC4821. > From nobody Wed Jan 10 10:23:11 2018 Return-Path: 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 6593B12D77E for ; Wed, 10 Jan 2018 10:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXjGcDMtRM44 for ; Wed, 10 Jan 2018 10:23:04 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 9419112D7E4 for ; Wed, 10 Jan 2018 10:23:02 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eZL1f-0005zz-Vm for tsvwg@ietf.org; Wed, 10 Jan 2018 19:23:00 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eZL1a-000807-Mh for tsvwg@ietf.org; Wed, 10 Jan 2018 13:22:58 -0500 Received: (qmail 9432 invoked from network); 10 Jan 2018 18:22:53 -0000 Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Jan 2018 18:22:52 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C153) In-Reply-To: <5A563390.8050403@erg.abdn.ac.uk> Date: Wed, 10 Jan 2018 08:22:50 -1000 Cc: "Eggert, Lars" , "Black, David" , "tsvwg@ietf.org" , QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.17) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5t+upY0sYTZYy6v6oxD2NtUXv9krsgRhBn0ayn6qsUc7AxcDYLQWPWOw vKJpm+ErX61PdOWeIW8R8TgUu5HhPnLJS6VNMALPKMXxnJGC3V/PTGulXfuaNr1V9B1E4+3dI5VM iIKmvXxtALVuD1NjPz48uEFOG92DI83j3LMNDNEdZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31VgwWqLoIJoKisE2LaVktjk2yVwR56jylmLFnIswFzA nc3NpdQi2IbmjBHIcsRA1snh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3Gd20T8xFITcF1bVYFM5+Dh5nHEeB4hpRrmo/duzUUp/Lq CGJzNk1dCcc9feDSDvuObzzzBvOYF5vBG3n/6Z/3YnLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+AqMI8XB32z4L/a53NbOeOoj2lB9TLiDMfXuvSrucRXrlnGtGdG3g+ozMfeTuFOSvpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 18:23:06 -0000 > On Jan 10, 2018, at 5:38 AM, Gorry Fairhurst wrote:= > ... >=20 > I suspect someone could use the final method with QUIC - since it's also a= UDP-based transport. I don' knopw of anyone planning PMTUD for QUIC - pleas= e get in touch if that is on your radar. The initial packets in QUIC are sent with min IPv6 MTU. During the initial e= xchange, the nodes send the maximum packet size that they might accept. QUIC= does not specify the actual probing algorithm but does specify that PMTU is= per path. Several QUIC implementations do PMTUD already, building simple probes with Q= UIC's Ping and Padding frames. Probes are then encrypted, and sent as QUIC p= ackets in UDP with segmentation turned off. If the probe packet is acknowled= ged, the applications know that this much MTU can be sent. Note the encrypted part. Replacing such mechanisms by a clear text exchange i= s not desirable. -- Christian Huitema=20= From nobody Wed Jan 10 10:57:33 2018 Return-Path: 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 313AB127023; Wed, 10 Jan 2018 10:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 yX05TtvDGR7N; Wed, 10 Jan 2018 10:57:29 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A6C1200B9; Wed, 10 Jan 2018 10:57:29 -0800 (PST) Received: from [10.0.3.2] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 2533672106C12; Wed, 10 Jan 2018 19:57:25 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Michael Tuexen In-Reply-To: <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> Date: Wed, 10 Jan 2018 19:57:22 +0100 Cc: Gorry Fairhurst , "Black, David" , "Eggert, Lars" , "tsvwg@ietf.org" , QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 18:57:32 -0000 > On 10. Jan 2018, at 19:22, Christian Huitema = wrote: >=20 >=20 >> On Jan 10, 2018, at 5:38 AM, Gorry Fairhurst = wrote: >> ... >>=20 >> I suspect someone could use the final method with QUIC - since it's = also a UDP-based transport. I don' knopw of anyone planning PMTUD for = QUIC - please get in touch if that is on your radar. >=20 > The initial packets in QUIC are sent with min IPv6 MTU. During the = initial exchange, the nodes send the maximum packet size that they might = accept. QUIC does not specify the actual probing algorithm but does = specify that PMTU is per path. >=20 > Several QUIC implementations do PMTUD already, building simple probes = with QUIC's Ping and Padding frames. Probes are then encrypted, and sent = as QUIC packets in UDP with segmentation turned off. If the probe packet = is acknowledged, the applications know that this much MTU can be sent. Your description of the probe packets is the one we have in mind. It = just needs to be specified. The more interesting part of the document is the way (when and which = size) you probe, not how you probe. >=20 > Note the encrypted part. Replacing such mechanisms by a clear text = exchange is not desirable. And not intended... Best regards Michael >=20 > -- Christian Huitema=20 From tom@quantonium.net Thu Jan 11 13:09:23 2018 Return-Path: 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 BF30412EBAC for ; Thu, 11 Jan 2018 13:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-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 kxTOKUtEdxmf for ; Thu, 11 Jan 2018 13:09:21 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 DD56812E036 for ; Thu, 11 Jan 2018 13:09:20 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id i11so7944880wmf.4 for ; Thu, 11 Jan 2018 13:09:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=RB1NaZ+BV7Hsc5ynJABj71/O/25o3s163F+0nlWv5NA=; b=sxn04x0uQ54dpRr8Zs5Mw+96fJtF6kK6zRV4idf/cTbEcsJDy9Ft9jmjp91FyWPBMF 5/9HyLAFpz6vrqcmyG4mtmO5Pys3EK935X1cdHFBOZalaUw1NJKHzrE1RBgFWSKwO4T0 a4FwzIGEybgpeeQ4NNJBE7t2sNurx0rk/DfWNh+YWvXt22M4rqBEYBHdCHABeZ1MfZc4 2wrT5V/0XsMGdB3bXX/FAXcigx8USnPK2eplkzz8D0BvTufWTaoSE9x6Ueh5tjcS+sCf eROnx3qdcDgriucD2nYln7oJ2ojB768ZzQ4c+SrKCuepeykyGeU/Ck5Hg14QhEi/Uv+U nWiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=RB1NaZ+BV7Hsc5ynJABj71/O/25o3s163F+0nlWv5NA=; b=gLdR2dUPx6bYGee9saWUCKvRcQT2qjPK2zjcQuPh5TEaK7OlrlHxepy30fgU8W24J4 EUksaPShP9oUQFvgTzgcPptZXF5KKEwAw20k7eGZfO4kmK+tjk9b/AkMcbJTr7z0xnNu 5M4wMsSWtglwpm652fODjOPXlzI1XJQ8uh8gqfhbpLvexah0KKgaAeJP0smTSMVkuxaM cvSr6BOvEotK4s8BvZF31UrHY8f0O/MQleJY2+J+gjjzfouk8QgVAu9JE05kCbHyzN4l 6NUPHqASrVxrWkCYuxw76u+CQXUu2EnEAilbiU9rGGlpGWh3/wh4i/hAe1euVW4n8kym OeLg== X-Gm-Message-State: AKwxytfO8qqqg0Kvo2pRjHBQG4B9rMXdS147OTD4fRiG8wofCsR+xy3G aWFkZvcAgm0QCJ/dNrfdMxlcBTA0Zk2KEdq1lXJB1g== X-Google-Smtp-Source: ACJfBouXYZYpuxptpcFOYgIXnN8lZdviRBNujsN6pNcc4QoiWX6xZuM04dcyeue3rZb9tFl+x4KqiR6RpMStj0DN004= X-Received: by 10.28.143.204 with SMTP id r195mr2391205wmd.51.1515704959045; Thu, 11 Jan 2018 13:09:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.208.204 with HTTP; Thu, 11 Jan 2018 13:09:18 -0800 (PST) In-Reply-To: <151569998986.1808.5962574573199407272.idtracker@ietfa.amsl.com> References: <151569998986.1808.5962574573199407272.idtracker@ietfa.amsl.com> From: Tom Herbert Date: Thu, 11 Jan 2018 13:09:18 -0800 Message-ID: To: tsvwg@ietf.org, panrg@irtf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-herbert-fast-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 21:10:02 -0000 Hello, I posted this draft on "Firewall and Service Tickets" draft. This is a proposed method to allow hosts and applications to signal the network to make requests for services to be applied to flows. The concept of a rich and extensible protocol to signal the network was inspired by the SPUD/PLUS work, however this proposal uses IPv6 extension headers instead of UDP shim headers and tries to strictly control exposure application characteristics or content to untrusted parties. I've cross posted this ti tsvwg an panrg as I'm not yet sure where this work would belong. Any feedback is very welcome! Thanks, Tom ---------- Forwarded message ---------- From: Date: Thu, Jan 11, 2018 at 11:46 AM Subject: New Version Notification for draft-herbert-fast-00.txt To: Tom Herbert A new version of I-D, draft-herbert-fast-00.txt has been successfully submitted by Tom Herbert and posted to the IETF repository. Name: draft-herbert-fast Revision: 00 Title: Firewall and Service Tickets Document date: 2018-01-11 Group: Individual Submission Pages: 21 URL: https://www.ietf.org/internet-drafts/draft-herbert-fast-00.txt Status: https://datatracker.ietf.org/doc/draft-herbert-fast/ Htmlized: https://tools.ietf.org/html/draft-herbert-fast-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-herbert-fast-00 Abstract: This document describes the Firewalls and Service Tickets protocol. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network service to be applied. Applications request tickets from a local agent in the network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to a packets. A single ticket may provide both firewall and service ticket information. Tickets are sent in either IPv6 Destination options or Hop-by-Hop options. 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 Fri Jan 12 14:55:10 2018 Return-Path: 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 AD3FD128961; Fri, 12 Jan 2018 14:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 R1TTwTHVuPFC; Fri, 12 Jan 2018 14:54:52 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C3812D830; Fri, 12 Jan 2018 14:54:15 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A1028B8216A; Fri, 12 Jan 2018 14:53:51 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, tsvwg@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180112225351.A1028B8216A@rfc-editor.org> Date: Fri, 12 Jan 2018 14:53:51 -0800 (PST) Archived-At: Subject: [tsvwg] =?utf-8?q?RFC_8311_on_Relaxing_Restrictions_on_Explicit_C?= =?utf-8?q?ongestion_Notification_=28ECN=29_Experimentation?= X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 22:55:01 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8311 Title: Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation Author: D. Black Status: Standards Track Stream: IETF Date: January 2018 Mailbox: david.black@dell.com Pages: 20 Characters: 48310 Updates: RFC 3168, RFC 4341, RFC 4342, RFC 5622, RFC 6679 I-D Tag: draft-ietf-tsvwg-ecn-experimentation-08.txt URL: https://www.rfc-editor.org/info/rfc8311 DOI: 10.17487/RFC8311 This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint. This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. 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 Jan 17 17:31:51 2018 Return-Path: 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 A0EA412EAD8 for ; Wed, 17 Jan 2018 17:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=leNejI2g; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=D4cyvONd 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 Sc0GxVORv_1b for ; Wed, 17 Jan 2018 17:31:46 -0800 (PST) Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (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 9BFDC12D890 for ; Wed, 17 Jan 2018 17:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1516239106; x=1547775106; h=from:to:subject:date:message-id:mime-version; bh=sEmjlc/1tz0QsihAOQjHoVVrkOw2Ecaj7kXPqJrGlBU=; b=leNejI2g6aw8BP4wY9KkEbSJiI5QdLanaKZqGnWy3GrzvVVgPRxZx7Dt 65yYjbDWYIUtQUR6ovfsbL7LAUOY+aMZjSxg4oivAQ2K8dYCVvGah6XGa bY9SWP0+dsn0rqahYTKy2/L9GoRd4TN6c/0UoxSSxIh+kL+sqViccU+au Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Aq9bYRh1Y1rDLgVo0smDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seIXK/ad9pjvdHbS+e9qxAeQG9mDsrQc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q99pHPfglEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7S60/Vza/4KdxUBLmiD?= =?us-ascii?q?kJOSMl8G/ZicJwjb5Urx26qhNl34LZZJuYOOZicq/De94RWGpPXtxWVyxEGo6w?= =?us-ascii?q?YZYCD+4bMulErInxv0YFoxWkCgmyBePg1zFEjWLx0KM0yeshDwDG0xE6E98TtH?= =?us-ascii?q?Tbtsn6NKQJXO+o0qbIyTHDY+lK1jf67YjFaxYsquyPU7JoacfcyEoiGxnbglie?= =?us-ascii?q?t4DpJS6Z2+QCvmSB6+dtVvqjh3M7pw1rvzSj2schhpPKi44P11zJ+yV0zJ47Jd?= =?us-ascii?q?KmS0N3fdupHZ5TuiyVM4Z2TMYvTmF1tykg1LELvIO3cDURx5kiyBPSZf+KfoiO?= =?us-ascii?q?7xn+TuieOy14i2hgeL+nghay9lWvxfPkW8mv1VZKsjJFkt7RtnARzxDT6taISv?= =?us-ascii?q?96/kq5xzmPzBrc5+5eLU8pi6XbL5ohzqc3lpoOrUTMBSj2mFjwjKCLaEko4Omo?= =?us-ascii?q?6/znYrXjqZ6QLZN7igb7Mqg2m8y/B/o3MhQWUmWa+umwzqPv8EPnTLlQk/E7kq?= =?us-ascii?q?bUvIreKMkYvqK5BhVa0ocn6xaxFTem19EYkGEJIl1fZhKHjpXmN0vTLfD8F/iw?= =?us-ascii?q?n1esnSx2yP/YOr3hBo/BIWTEkLfkZbp98VJTyBIvzdBD4JJZEq0BIOntWk7/u9?= =?us-ascii?q?zVFR45PBKow+bpEtl90ZkeWW3cSpOeZenOqkGX6couLvWCIogPt3y1f+Q++eHh?= =?us-ascii?q?pX40hVFberOmi8g5cne9S75MJ0ySYj6krt4fEGtA9l4SRfLrhBuoVTdYZF6+Uq?= =?us-ascii?q?Y4oDo8DdT1Xs/4WomxjenZj2+AFZpMazUeBw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HsAAC5919amGKa6ERcHAEBAQQBAQoBA?= =?us-ascii?q?YJKIoErEHQnB50OmTAUgT9DCoU7AoRlQBcBAQEBAQEBAQEBAhABAQEBAQYNCwY?= =?us-ascii?q?oJAuCOCIRSyEGMgEBAQEBAQEBAQEBAQEBAQEBARcCPRMCGAEBMhMfGxEBGQQBA?= =?us-ascii?q?QtWHQkBBBMIiUdkAaoygxGGPwEBCAIeCIZRgViIRQSBPAESASGCWG6CNItkjhq?= =?us-ascii?q?JbQYCiS2OPYYdi12XAgIEAgQFAhqBPCABgRhwb1KCKgmCW4FzeIoUgSWBFwEBA?= =?us-ascii?q?Q?= X-IPAS-Result: =?us-ascii?q?A2HsAAC5919amGKa6ERcHAEBAQQBAQoBAYJKIoErEHQnB50?= =?us-ascii?q?OmTAUgT9DCoU7AoRlQBcBAQEBAQEBAQEBAhABAQEBAQYNCwYoJAuCOCIRSyEGM?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBARcCPRMCGAEBMhMfGxEBGQQBAQtWHQkBBBMIiUd?= =?us-ascii?q?kAaoygxGGPwEBCAIeCIZRgViIRQSBPAESASGCWG6CNItkjhqJbQYCiS2OPYYdi?= =?us-ascii?q?12XAgIEAgQFAhqBPCABgRhwb1KCKgmCW4FzeIoUgSWBFwEBAQ?= Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jan 2018 19:31:45 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2018 07:31:45 +0600 Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w0I1Vibq017933 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 17 Jan 2018 20:31:44 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com w0I1Vibq017933 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1516239104; bh=6C3rRHSAwxkDctxc+jvs5INP/aI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=D4cyvONd3rIgj/0bQAycFCQ7rAnOnhybHGPw9dqrGEXledWrloVGRdxZziKgjRR0P HNHwc0ps/9rfqDXkOpVtG9WYkMAzyJgNPKoX0l7xUmf99UQRJwXQPJCYWX/G321H1F /ml64HWSJtgl5qzWc0JusTC0fCFnOj3odff5eg5g= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com w0I1Vibq017933 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd54.lss.emc.com (RSA Interceptor) for ; Wed, 17 Jan 2018 20:31:27 -0500 Received: from MXHUB316.corp.emc.com (MXHUB316.corp.emc.com [10.146.3.94]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w0I1VTrn024459 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Wed, 17 Jan 2018 20:31:29 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB316.corp.emc.com ([10.146.3.94]) with mapi id 14.03.0352.000; Wed, 17 Jan 2018 20:31:29 -0500 To: "tsvwg@ietf.org" Thread-Topic: draft-fairhurst-tsvwg-datagram-plpmtud-02 adopted Thread-Index: AdOP/A6ufRbCT3U3RR+2Qnu1b4Ve9Q== Date: Thu, 18 Jan 2018 01:31:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FF6FC9CMX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: [tsvwg] draft-fairhurst-tsvwg-datagram-plpmtud-02 adopted X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 01:31:49 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FF6FC9CMX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There were multiple messages in favor of adoption of this draft, some discu= ssion of its applicability to other protocols and no messages opposed to ad= option of this draft. This draft is now adopted by the TSVWG working group - the authors should s= ubmit a -00 working group version of the draft (draft-ietf-tsvwg-...). Many thanks to Wes Eddy, Joe touch, Vincent Roca and Maksim Proshin for agr= eeing to review this draft as it progresses. Thanks, --David From: Black, David Sent: Thursday, December 14, 2017 3:28 PM To: tsvwg@ietf.org Cc: Black, David Subject: Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10= th January 2018 I'm tardy in getting to this action item from the TSVWG meeting in Singapor= e ... The TSVWG chairs are considering adoption of the draft "Packetization Layer Path MTU Discovery for Datagram Transports". This draft has been discussed at the previous IETF meeting and on the list,= and the chairs are now looking for input from the group to help inform whe= ther TSVWG should adopt this draft. * Please send an email to this list if you would like to see this work adop= ted in TSVWG, or you have comments on the suitability for adoption. * Please indicate if you are willing to REVIEW such a document during its d= evelopment. Please send all notes of support/comments to the TSVWG list or the WG chair= s by the date above. Best wishes, David and Wes. (TSVWG Co-Chairs) [Gorry is recused from this adoption decision, as he is a= n author of this draft.] [The time period for this adoption call is longer than usual to allow for t= he winter holidays - may yours be joyous!] Abstract This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization layers. The method allows a Packetization layer (or a datagram application that uses it) to probe an network path with progressively larger packets to determine a maximum packet size. The document describes as an extension to RFC 1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for IPv4 and IPv6. This provides functionally for datagram transports that is equivalent to the Packetization layer PMTUD specification for TCP, specified in RFC4821. --_000_CE03DB3D7B45C245BCA0D243277949362FF6FC9CMX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There were multiple messages in favor of adoption of this draft, some= discussion of its applicability to other protocols and no messages opposed= to adoption of this draft.

 

This draft is now adop= ted by the TSVWG working group – the authors should submit a -00 work= ing group version of the draft (draft-ietf-tsvwg-…).

 

Many thanks to Wes Edd= y, Joe touch, Vincent Roca and Maksim Proshin for agreeing to review this d= raft as it progresses.

 

Thanks, --David

 

From: Black, David
Sent: Thursday, December 14, 2017 3:28 PM
To: tsvwg@ietf.org
Cc: Black, David <david.black@emc.com>
Subject: Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to= end 10th January 2018

 

I’m tardy in getting to this action item fr= om the TSVWG meeting in Singapore …

 

The TSVWG chairs are considering adoption of the = draft

"Packetization Layer Path MTU Discovery for = Datagram Transports".

 

This draft has been discussed at the previous IET= F meeting and on the list, and the chairs are now looking for input from th= e group to help inform whether TSVWG should adopt this draft.

 

* Please send an email to this list if you would = like to see this work adopted in TSVWG, or you have comments on the suitabi= lity for adoption.

 

* Please indicate if you are willing to REVIEW su= ch a document during its development.

 

Please send all notes of support/comments to the = TSVWG list or the WG chairs by the date above.

 

Best wishes,

 

David and Wes.

(TSVWG Co-Chairs) [Gorry is recused from this ado= ption decision, as he is an author of this draft.]

[The time period for this adoption call is longer= than usual to allow for the winter holidays – may yours be joyous!]<= o:p>

 

Abstract

 

   This document describes a robust met= hod for Path MTU Discovery

   (PMTUD) for datagram Packetization l= ayers.  The method allows a

   Packetization layer (or a datagram a= pplication that uses it) to probe

   an network path with progressively l= arger packets to determine a

   maximum packet size.  The docum= ent describes as an extension to RFC

   1191 and RFC 8201, which specify ICM= P-based Path MTU Discovery for

   IPv4 and IPv6.  This provides f= unctionally for datagram transports

   that is equivalent to the Packetizat= ion layer PMTUD specification for

   TCP, specified in RFC4821.

 

--_000_CE03DB3D7B45C245BCA0D243277949362FF6FC9CMX307CL04corpem_-- From nobody Fri Jan 19 07:40:32 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 833E012D9FF for ; Fri, 19 Jan 2018 07:40:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151637643153.2376.2910991314606250229.idtracker@ietfa.amsl.com> Date: Fri, 19 Jan 2018 07:40:31 -0800 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 15:40:31 -0000 Changed milestone "Submit " Transport Options for UDP" as a Proposed Standard RFC", set due date to December 2018 from April 2018. URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Fri Jan 19 12:44:53 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6538512E045 for ; Fri, 19 Jan 2018 12:44:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151639469241.17366.5746275409153574998.idtracker@ietfa.amsl.com> Date: Fri, 19 Jan 2018 12:44:52 -0800 From: IETF Secretariat Archived-At: Subject: [tsvwg] Milestones changed for tsvwg WG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 20:44:52 -0000 Changed milestone "Submit 'Packetization Layer Path MTU Discovery for Datagram Transports' as a Proposed Standard RFC", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/tsvwg/about/ From nobody Fri Jan 19 19:18:46 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5DCA126CBF; Fri, 19 Jan 2018 19:18:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151641832182.3163.5991614599671930276@ietfa.amsl.com> Date: Fri, 19 Jan 2018 19:18:41 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2018 03:18:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Transport Options for UDP Author : Joe Touch Filename : draft-ietf-tsvwg-udp-options-02.txt Pages : 27 Date : 2018-01-19 Abstract: Transport protocols are extended through the use of transport header options. This document experimentally extends UDP by indicating the location, syntax, and semantics for UDP transport layer options. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-02 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-02 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 Sat Jan 20 22:10:54 2018 Return-Path: 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 EC83C127241 for ; Sat, 20 Jan 2018 22:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuwZTEjnOhCV for ; Sat, 20 Jan 2018 22:10:49 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 5D5E5126DED for ; Sat, 20 Jan 2018 22:10:49 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ed8q7-0007KY-0J for tsvwg@ietf.org; Sun, 21 Jan 2018 07:10:47 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ed8q0-0001Q8-VT for tsvwg@ietf.org; Sun, 21 Jan 2018 01:10:45 -0500 Received: (qmail 25705 invoked from network); 21 Jan 2018 06:10:37 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Jan 2018 06:10:37 -0000 To: Michael Tuexen References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> Cc: Gorry Fairhurst , "Black, David" , "Eggert, Lars" , "tsvwg@ietf.org" , QUIC WG From: Christian Huitema Message-ID: <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> Date: Sat, 20 Jan 2018 20:10:34 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> Content-Type: multipart/alternative; boundary="------------D0A2405547FB08E6C3809962" X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5il7EG9TbWSGhDGl5JbJQMoXv9krsgRhBn0ayn6qsUc7AxcDYLQWPWOw vKJpm+ErX61PdOWeIW8R8TgUu5HhPnJC7BfLwPAprJgXEz+mTa2DTGulXfuaNr1V9B1E4+3dI5VM iIKmvXxtALVuD1NjPz5fZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31VgwWqLoIJoKisE2LaVktjkoBooiqCtwqmCSyE26E80 CcIIa9pF9PUqqEB2bD5cBVrh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GYnRqIO2TPU1F0bSG6T2DJZnHEeB4hpRrmo/duzUUp/Kk srS1edYbOHZeK24FwQY9Ur/FmUv0D+GzhBYicKWDwnLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+G45OmBNdsUklj47JM2Zh1oj2lB9TLiDMfXuvSrucRXry8B6sEcpHNQcjlAOoToGvpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 06:10:51 -0000 This is a multi-part message in MIME format. --------------D0A2405547FB08E6C3809962 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/10/2018 8:57 AM, Michael Tuexen wrote: >> Several QUIC implementations do PMTUD already, building simple probes = with QUIC's Ping and Padding frames. Probes are then encrypted, and sent = as QUIC packets in UDP with segmentation turned off. If the probe packet = is acknowledged, the applications know that this much MTU can be sent. > Your description of the probe packets is the one we have in mind. It ju= st needs to be specified. > The more interesting part of the document is the way (when and which si= ze) you probe, > not how you probe. >> Note the encrypted part. Replacing such mechanisms by a clear text exc= hange is not desirable. > And not intended... Since you mentioned it, I implemented "application level" PMTUD in my implementation of QUIC (https://github.com/private-octopus/picoquic). Basic "probe" strategy. Start with the min value (from IPv6), then learn the peer-supported value during the handshake (standard QUIC), then send probes to perform a binary search between min and max. Stop the binary search if the range of search is less than 10 bytes. No ICMP dependency. Some overhead, but that is amortized by sending a dozen packets or so at the maximum size instead of the default size. -- Christian Huitema --------------D0A2405547FB08E6C3809962 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 1/10/2018 8:57 AM, Michael Tuexen wrote:

Several QUIC implementations do PMTUD already, building simple probes with QUIC's Ping and Padding frames. Probes are then encrypted, and sent as QUIC packets in UDP with segmentation turned off. If the probe packet is acknowledged, the applications know that this much MTU can be sent.
Your description of the probe packets is the one we have in mind. It just needs to be specified.
The more interesting part of the document is the way (when and which size) you probe,
not how you probe.
Note the encrypted part. Replacing such mechanisms by a clear text exchange is not desirable.
And not intended...

Since you mentioned it, I implemented "application level" PMTUD in my implementation of QUIC (https://github.com/private-octopus/picoquic). Basic "probe" strategy. Start with the min value (from IPv6), then learn the peer-supported value during the handshake (standard QUIC), then send probes to perform a binary search between min and max. Stop the binary search if the range of search is less than 10 bytes. No ICMP dependency. Some overhead, but that is amortized by sending a dozen packets or so at the maximum size instead of the default size.

-- Christian Huitema
--------------D0A2405547FB08E6C3809962-- From nobody Sun Jan 21 00:28:44 2018 Return-Path: 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 1CAA1127241; Sun, 21 Jan 2018 00:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 QCm3NIf0nT6c; Sun, 21 Jan 2018 00:28:34 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 C8C8F120725; Sun, 21 Jan 2018 00:28:34 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id t22so6384721ioa.7; Sun, 21 Jan 2018 00:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=pHvLDSoPhIToZ2A7CUeArUyLwpGyphMOE7TAXm5L1VM=; b=c20a58TC4Qx06hfRqJqVITAuiZjqTY5OYgUwipsxCyoGazwaL3yfJGsO97AbvBOVbh arM0KMgoEqpW2x1DgOAqm4JN7fYsvTcIa0ZNprrnNR9q8kT2IA4h+QJ/Oxs/Z3F+RF9a XygoIPDYwE4LDTLZ8Ox3exVRAahBie0DAYl512Ro/jONdD8cnNle0i4gdV98+bf/l2bh XuHRwBLzp0UjXeVt+R+Jawjz38nufftXJD9CWUKEwghBkFK5c1Cf+k9i0FGNvDceJ4QX bKNLQr6INezZPIiObzkSxf1RU2QmDBGrv5N0qNml8+JKw7lBAPBLidDZjXt5hE3pNoRb XG+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=pHvLDSoPhIToZ2A7CUeArUyLwpGyphMOE7TAXm5L1VM=; b=ggSminGFYZjsmfsULjZ5EgY3G4JzckzN4rKIl5Ice0BBOLwfiVpGRYbiFNK1uLAJ42 UW2EM/tNnmlx2jl6bYFBgU7i9Gvy1+59zxcyjMZubd4sBOYSAVurysr1eHUjgrHonFea RKxn4PHFlCggj+WjugDC49uIblX6xHYWZq3KxnevYXk1a0au9PQ6TDnlsfHkIVfAknSI x69ZPE1t9o8KPRzv7EWKmkwwDqmX6HUnCOP8nKPrNo8Yn3zrCSig3y4xvn4jzZfo6Kqg qgwUEFGit05EfCN6uxDkwUR3tu3riI0KYFL3SedKNoIszhu4KHQiiRIAeSEinqOSZT2B JfqA== X-Gm-Message-State: AKwxyte36gXNeQiYyqRcRL70IQjEpwg5n0vFlQgsibnxHP8VmhYCe3WK JlHsM1ciBTFcnHMXa3CjA1HVbfuiymvFajbGGlY= X-Google-Smtp-Source: AH8x227NzXt1LSCiVGkSc+vfI3cuPWnTLsy5oBnniCzZJPI6aoe9k8+3kTXA30amVF3Dd7LFFWSdDrVDq6N+MlOUNdI= X-Received: by 10.107.3.209 with SMTP id e78mr3870586ioi.96.1516523313813; Sun, 21 Jan 2018 00:28:33 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 21 Jan 2018 00:28:32 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 21 Jan 2018 00:28:32 -0800 Message-ID: To: Christian Huitema , Michael Tuexen Cc: Gorry Fairhurst , "Black, David" , QUIC WG , "Eggert, Lars" , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a113dea6469dcbc05634519de" Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 08:28:37 -0000 --001a113dea6469dcbc05634519de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since you mentioned it, I implemented "application level" PMTUD in my implementation of QUIC (https://github.com/private-octopus/picoquic). Basic "probe" strategy. Start with the min value (from IPv6), then learn the peer-supported value during the handshake (standard QUIC), then send probes to perform a binary search between min and max. Stop the binary search if the range of search is less than 10 bytes. No ICMP dependency. Some overhead, but that is amortized by sending a dozen packets or so at the maximum size instead of the default size. -- Christian Huitema How you considered exponential search where you start with a conservative limit for the upper bound, then exponentially increase that limit until maxPMTU. It is not faster than binary search if each size is equally likely, but that is probably not true. I assume it would use less bandwidth if the max is much larger than the typical PMTU, and allow the application to start using larger MTU=E2=80=99s= earlier since early guesses are more likely to succeed. /* roughly like this - untestet */ a =3D minPMTU b =3D maxPMTU k =3D initDelta /* 1 or larger, e.g. minPMTU / 4 */ while a <=3D b k =3D min(a + k, b) - a n =3D binsearch(a, a + k - 1) if n return n a =3D a + k /* this doubles the search range */ end return not found https://en.wikipedia.org/wiki/Exponential_search --001a113dea6469dcbc05634519de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Since you mentioned it, I implemented "= application level" PMTUD in my implementation of QUIC (ht= tps://github.com/private-octopus/picoquic). Basic "probe" str= ategy. Start with the min value (from IPv6), then learn the peer-supported = value during the handshake (standard QUIC), then send probes to perform a b= inary search between min and max. Stop the binary search if the range of se= arch is less than 10 bytes. No ICMP dependency. Some overhead, but that is = amortized by sending a dozen packets or so at the maximum size instead of t= he default size.

-- Christian Huitema

How you considered exponential search where you start with a co= nservative limit for the upper bound, then exponentially increase that limi= t until maxPMTU. It is not faster than binary search if each size is equall= y likely, but that is probably not true.
I assume it would use le= ss bandwidth if the max is much larger than the typical PMTU, and allow the= application to start using larger MTU=E2=80=99s earlier since early guesse= s are more likely to succeed.

/* roughly like this= - untestet */
a =3D minPMTU
b =3D maxPMTU
k = =3D initDelta /* 1 or larger, e.g. minPMTU / 4 */
while a <=3D= b
=C2=A0 k =3D min(a + k, b) - a
=C2=A0 n = =3D binsearch(a, a + k - 1)=C2=A0
=C2=A0 if n return n
= =C2=A0 a =3D a + k /* this doubles the search range */
end
<= div>return not found


--001a113dea6469dcbc05634519de-- From nobody Sun Jan 21 01:50:39 2018 Return-Path: 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 88B39124239; Sun, 21 Jan 2018 01:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 oeO3q0_0xlS2; Sun, 21 Jan 2018 01:50:30 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 4E4C41201F8; Sun, 21 Jan 2018 01:50:30 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id 68so6660602ite.4; Sun, 21 Jan 2018 01:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=CLm0fKvh23szIeaCKf8WY+OmJ+IgiRrQdPlo/abD7H0=; b=Pi6tdFcNLHY5EFyBLVLlc8Rd7S7hOgq7a0fudMuUzjzYG7ytXd+oVVoPOWY/J5NfhF ElJeGM39LQi3/DIhC+O6TC/uWJO155rcADR343IZk+SVCJX9YwBskOx89l0m4qX1Ksfx +cfVtkjFxqyFHmMJk15kNWenEs0p65WBZ0D6o8IxsafE40qqOLT4CUc4DuJSWe9MiAOW wKjRRUQs9W+2e+68BgSOhjqish1+w2IBWtd9SWjX24At87aWGVTLtaYeo5S98jQU9yYf /iHBHQJ15MMYDLRV/7+UK6Yv1gw+K1bg46UNgHVQ44Dr/oEzurHZoaxUTzoP+KXX+cYU 63PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=CLm0fKvh23szIeaCKf8WY+OmJ+IgiRrQdPlo/abD7H0=; b=pFYBvm6wfsvC1AAGWHfqDjqX5l8dsOCN3iO88LlgnV6cjAPG01YVsMhRByM4GukkJj wGeHNj1NFSyyv1pn1r1Yf8iyzDOldIU0xkqfhfdA8GicoJ7q66xAHzuVtrdxBcc9NMTv oJs/AUn47nuiv4d5Ur1QBkDH5ifr9AwbHOyX5h1JD2ZndoGhq5TzGC5HW03IC25Zq4nL HsocV8GL+M+LEmoVdIeecmSYrTH+2/Br+kBdp5rMJG+zsM+7/srCf5MsKCHAry3PDq8+ u0ohnD3Edzj6pZU2ZE/+ocfB46MkROxmonevV32yvL0PhgpcrQIvn3bc4i3hFXdxgqVY ofng== X-Gm-Message-State: AKwxytfX68747GPc/El7kKg+CZqUc5VKqhxUbvLwnKlDpmw6LqtaonR5 vIKVb+E8XqgBkhPcNzRiWdaHCusYthb+/RaNlVM= X-Google-Smtp-Source: AH8x2267rljw79xUqIJ3esxJu7tPe0KiFiAL3cEswXIGTtRf/Q6/an3S0Kh1113wTGN8HC2W/K3PA6xN2G+rZdjCVmc= X-Received: by 10.36.189.129 with SMTP id x123mr2752657ite.31.1516528229648; Sun, 21 Jan 2018 01:50:29 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 21 Jan 2018 01:50:28 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 21 Jan 2018 01:50:28 -0800 Message-ID: To: Christian Huitema , Michael Tuexen Cc: Gorry Fairhurst , "Black, David" , QUIC WG , "Eggert, Lars" , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c196d286b8f990563463e38" Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 09:50:33 -0000 --94eb2c196d286b8f990563463e38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here is a Fibonacci variant the grows slower. Not sure it is any better, but the intention is to avoid probing very large packets too early. It could probably be applied recursively to avoid bin search altogether. The same idea might be applicable to reducing the congestion window as opposed to doubling or halving. /* Fibonacci variant */ /* roughly like this - untestet */ unit =3D 10 /* min probe increment */ a =3D minPMTU / unit b =3D maxPMTU / unit k1 =3D initDelta /* 1 or larger, e.g. a / 4 */ k0 =3D 0 while a + k0 <=3D b k2 =3D k0 + k1 n =3D binsearch(a + k0, min(a + k1 - 1, b), unit) if n return n k0 =3D k1 k1 =3D k2 end /* binsearch probes multiples of unit and calls updatePMTUEstimate(n) whenever n is a larger valid probe than previously reported */ Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 21 January 2018 at 09.28.32, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: Since you mentioned it, I implemented "application level" PMTUD in my implementation of QUIC (https://github.com/private-octopus/picoquic). Basic "probe" strategy. Start with the min value (from IPv6), then learn the peer-supported value during the handshake (standard QUIC), then send probes to perform a binary search between min and max. Stop the binary search if the range of search is less than 10 bytes. No ICMP dependency. Some overhead, but that is amortized by sending a dozen packets or so at the maximum size instead of the default size. -- Christian Huitema How you considered exponential search where you start with a conservative limit for the upper bound, then exponentially increase that limit until maxPMTU. It is not faster than binary search if each size is equally likely, but that is probably not true. I assume it would use less bandwidth if the max is much larger than the typical PMTU, and allow the application to start using larger MTU=E2=80=99s= earlier since early guesses are more likely to succeed. /* roughly like this - untestet */ a =3D minPMTU b =3D maxPMTU k =3D initDelta /* 1 or larger, e.g. minPMTU / 4 */ while a <=3D b k =3D min(a + k, b) - a n =3D binsearch(a, a + k - 1) if n return n a =3D a + k /* this doubles the search range */ end return not found https://en.wikipedia.org/wiki/Exponential_search --94eb2c196d286b8f990563463e38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Here is a Fibonacci = variant the grows slower.
Not sure it is any better, but the intention is to avoid probi= ng very large packets too early.
It could probably be applied recursively to avoid bin s= earch altogether.
The same idea might be applicable to reducing the congestion window as= opposed to doubling or halving.

<= div id=3D"bloop_customfont" style=3D"color:rgb(0,0,0);margin:0px">
/* Fi= bonacci variant */
/* roughly like this - untestet */<= /div>
unit =3D 10 /* min probe increment */
a =3D minPMTU / = unit
b =3D maxPMTU / unit
k1 =3D initDelta /* 1= or larger, e.g. a / 4 */
k0 =3D 0
while a + k0= <=3D b
=C2=A0 k2 =3D k0 + k1
=C2=A0 n =3D b= insearch(a + k0, min(a + k1 - 1, b), unit)
=C2=A0 if n return= n
=C2=A0 k0 =3D k1
=C2=A0 k1 =3D k2
end
/* binsearch probes multiples of unit and calls
=C2=A0 =C2=A0updatePMTUEstimate(n) whenever n is a larger
=C2=A0 =C2=A0valid probe than previously reported=C2=A0*/

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8r= gensen


On 21 January 2018 a= t 09.28.32, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:


Since you mentioned it, I implemented "application level" PMTUD in my implementation of QUIC (https://github= .com/private-octopus/picoquic). Basic "probe" strategy. Start with the min value (from IPv6), the= n learn the peer-supported value during the handshake (standard QUIC), then send probes to perform a binary search between min and max. Stop the binary search if the range of search is less than 10 bytes. No ICMP dependency. Some overhead, but that is amortized by sending a dozen packets or so at the maximum size instead of the default size.

-- Christian Huitema


How you considered exponential search where you start with a conservative limit for the upper bound, then exponentially increase that limit until maxPMTU. It is not faster than binary search if each size is equally likely, but that is probably not true.
I assume it would use less bandwidth if the max is much larger than the typical PMTU, and allow the application to start using larger MTU=E2=80=99s earlier since early guesses are more likely to succeed.

/* roughly like this - untestet */
a =3D minPMTU
b =3D maxPMTU
k =3D initDelta /* 1 or larger, e.g. minPMTU / 4 */
while a <=3D b
=C2=A0 k =3D min(a + k, b) - a
=C2=A0 n =3D binsearch(a, a + k - 1)=C2=A0
=C2=A0 if n return n
=C2=A0 a =3D a + k /* this doubles the search range */
end
return not found


--94eb2c196d286b8f990563463e38-- From nobody Sun Jan 21 13:17:02 2018 Return-Path: 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 063F21243F3 for ; Sun, 21 Jan 2018 13:17:01 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 daNF4aEdTki3 for ; Sun, 21 Jan 2018 13:16:59 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 78A18120726 for ; Sun, 21 Jan 2018 13:16:59 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id s39so16286364qth.7 for ; Sun, 21 Jan 2018 13:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=4LAFyYI3nPsSZw278oNbZmnRVCiv6f44D+c5aDEdwWU=; b=BBcoModPQStWW/vsEOyPg8rMA54pwPBUUZ/SIhMLA46th/iRoMUVepJ2rC4eXkBLNg Gxoj3MmXCRUKU/Eu6gSbGuTTdE6j2KNdYHsDoO7cRSpZfC3ezmzTKo9+usVnwtEh6ZXT 4RUhi5lq4wK1csZnnfJglEQObAA1oW4MPj0iHBwxnGkNm9MEYIRPmRq3DXYx8hpgJVZt dusydmiz/RlUeJ5sDqvPqIM5dgKE1ZUYr+XjUS3vSTkH213GGN031Aluw/lDHf8glx82 QeEubg4RvEmzmQZGlGLGe9afjw7x594vtv/gbHmZRGoeLGbExrPiWZF8B5LNc3kBfNGU Oizg== 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=4LAFyYI3nPsSZw278oNbZmnRVCiv6f44D+c5aDEdwWU=; b=mQypsvxHc/mXO0E+w9mvL5YY8tbdiphrvnFRfCDvwJsYKsuWMvuJsCcJQV2GSbHDHh jmj0sdH5c7Jf83mXicBgLFCy8EWLXpPBopZprhuMQ6qkHI8qtyYRGUevDlyaYEXbjG2p Kvs8mSY//rhgxYE0+h7XCj1U14SIJkpr818qBnL8LWXO7GO5zguTJEETQ1qAkBdUfLym trehBaQKaBpmP1A6WxtoJyy9AhY0FwYm1yTulRwQCH9E29+xAFGTSmKQPECnA3tC7kPX P9FyTF+X162Qy4AtHSTGmBb8+umO8u9QpafK1Be9m96O1dR4KuKVwOROQUR06DN59bS1 HL6w== X-Gm-Message-State: AKwxytecDDgLt6AHQSqdFF2UfyMY2Dci4QQH/k50WQhuKwi4rB6CDlIT hzUN8JVtR6HrVPjsX/kzWwoXYtutPjdwFPIwcVj3wecq X-Google-Smtp-Source: AH8x227xF/dA4FVPcGGZK9r5DH1hOY0pbHFGzhIQBK6mvSdEaw0oultCYvlaQuUTf+qiiLZsQFtbtg2cdiJqwihsVAk= X-Received: by 10.55.137.132 with SMTP id l126mr7235939qkd.270.1516569418473; Sun, 21 Jan 2018 13:16:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.56.229 with HTTP; Sun, 21 Jan 2018 13:16:58 -0800 (PST) From: Tom Herbert Date: Sun, 21 Jan 2018 13:16:58 -0800 Message-ID: To: touch@strayalpha.com, tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [tsvwg] Comment on draft-ietf-tsvwg-udp-options-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 21:17:01 -0000 Hi Joe, A few comments: I'm not sure what "required options" are and can't find a definition in he draft. The term "required option" seems to be a bit of an oxymoron. May this refers to options that a individual receivers can require to be present? >From the doc: A rule that "no more than 3" consecutive NOPs creates its own DOS vulnerability. Can you elaborate of this vulnerability? In looking at polynomials for CRC-16 for GUE, I didn't get a strong sense that CRC-16-CCITT is ubiquitous. CRC-16 (CRC_16-IBM) is supported by USB, ANSI standard, and is implemented in Linux (CRC-16-CCITT currently is not). For GUE, we defined options for either CRC-CCITT or CRC-16, it might be worth considering that for UDP options. ACS and authentication fail to protect the UDP options in the case that the kind field for these options is corrupted. For instance, if an ACS checksum kind field flips from 3 to zero, the receiver would see EOL instead of ACS. I believe this is a general problem any time checksum or security is put in options. For GUE, we added a disclaimer like this (draft-ietf-intarea-gue-extensions-02) "Note that the GUE checksum does not protect against the checksum flag (K flag) being corrupted. If an encapsulator sets the checksum flag and option but the K bit flips to be zero, then a decapsulator will incorrectly process the GUE packet as not having a checksum field. To mitigate this issue an encapsulator and depcapsulator might agree that checksum is always required. This agreement could be established by configuration or GUE capability negotiation" Tom From nobody Sun Jan 21 14:47:25 2018 Return-Path: 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 BAE90127201 for ; Sun, 21 Jan 2018 14:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham 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 1w1nqZ93JxiG for ; Sun, 21 Jan 2018 14:47:15 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 D610E126C25 for ; Sun, 21 Jan 2018 14:47:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=FZFvBbEWJV1ZT8Qd1rHqcD1gNdZqk21O/mm+Y42M9Tw=; b=FpJSyEh4cFMF/YLtrFV6YBhsb IwJDwEyCQ//+wTLJeYWBAv5y7L1gB/0H04g5KG8l+q4WYcqRrKvI7AR23H66EgnBZOKI69vWjTFO4 /Ul8nrLWwlv3LGVGsDJma6RCUZCz1kjkG5IiFFiPuyc8MkTUvNmZFA0t3HcOzIzfTkI/mTamnzZq2 zAskxrYJfyqfji/Xu7Z5lLYbfB2vOPvACd165EuSCiD2RMd/wsTsYPfVgiiiI8syqW4cG9wSyPyjY WRWN+/7Rz/VTdUivSn80OkkAmNQiSBNHc04xJa3A9oCmqtwnz3Ptl6Cu22TdNORi+6FDs69IiN6H7 9BG9Q2CkQ==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:51423 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1edOOG-000lyS-7t; Sun, 21 Jan 2018 17:47:08 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Joe Touch In-Reply-To: Date: Sun, 21 Jan 2018 14:47:02 -0800 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <272B6C51-AD9D-4AFB-9FFE-0CB40E6D1A37@strayalpha.com> References: To: Tom Herbert X-Mailer: Apple Mail (2.3273) 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: [tsvwg] Comment on draft-ietf-tsvwg-udp-options-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 22:47:23 -0000 HI, Tom, > On Jan 21, 2018, at 1:16 PM, Tom Herbert wrote: >=20 > Hi Joe, >=20 > A few comments: >=20 > I'm not sure what "required options" are and can't find a definition > in he draft. The term "required option" seems to be a bit of an > oxymoron. May this refers to options that a individual receivers can > require to be present? If an endpoint supports UDP options, these are the ones that it is = required to support. I will clarify that in the next update. >=20 >> =46rom the doc: A rule that "no more than 3" consecutive NOPs creates > its own DOS vulnerability. Can you elaborate of this vulnerability? Pushing meaningful options behind dozens of NOPs increases endpoint work = to parse the header. Previous list discussion indicated that because = there was never a real need for more than three (e.g., for single-byte = option realignment to 32-bit boundaries), that could be used as a test. = The work required to perform this test is trivial compared to the work = of parsing the options, so I don=E2=80=99t see this as creating a new = vulnerability. >=20 > In looking at polynomials for CRC-16 for GUE, I didn't get a strong > sense that CRC-16-CCITT is ubiquitous. CRC-16 (CRC_16-IBM) is > supported by USB, ANSI standard, and is implemented in Linux > (CRC-16-CCITT currently is not). For GUE, we defined options for > either CRC-CCITT or CRC-16, it might be worth considering that for UDP > options. We want to pick one rather than create ambiguity and additional work. I = don=E2=80=99t much care which one we pick; there was previous discussion = on the one we picked, but we can re-open that if you have a reason. >=20 > ACS and authentication fail to protect the UDP options in the case > that the kind field for these options is corrupted. Sure - the only alternative is to require these options, in which case = their corruption would be detected. However, an endpoint that is = expecting one or both of these would know when a packet failed to = include it. > For instance, if > an ACS checksum kind field flips from 3 to zero, the receiver would > see EOL instead of ACS. I believe this is a general problem any time > checksum or security is put in options. For GUE, we added a disclaimer > like this (draft-ietf-intarea-gue-extensions-02) I can add some text addressing this. >=20 > "Note that the GUE checksum does not protect against the checksum flag > (K flag) being corrupted. If an encapsulator sets the checksum flag > and option but the K bit flips to be zero, then a decapsulator will > incorrectly process the GUE packet as not having a checksum field. >=20 > To mitigate this issue an encapsulator and depcapsulator might agree > that checksum is always required. This agreement could be established > by configuration or GUE capability negotiation=E2=80=9D Sure - that=E2=80=99s what I said above; it would depend on the = expectation, which can be configured or negotiated. Joe >=20 > Tom >=20 From nobody Sun Jan 21 20:42:43 2018 Return-Path: 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 5AF771270A3 for ; Sun, 21 Jan 2018 20:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 qQuwErs868xj for ; Sun, 21 Jan 2018 20:42:39 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 DC9671241F8 for ; Sun, 21 Jan 2018 20:42:38 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx18.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1edTwI-0007jm-TU for tsvwg@ietf.org; Mon, 22 Jan 2018 05:42:36 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1edTwH-0005ae-38 for tsvwg@ietf.org; Sun, 21 Jan 2018 23:42:34 -0500 Received: (qmail 9234 invoked from network); 22 Jan 2018 04:42:32 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Jan 2018 04:42:32 -0000 To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Michael Tuexen References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> Cc: Gorry Fairhurst , "Black, David" , "Eggert, Lars" , "tsvwg@ietf.org" , QUIC WG From: Christian Huitema Message-ID: <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net> Date: Sun, 21 Jan 2018 18:42:27 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BF4705958E1D67DBB5B8A056" X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5r3d1FEZaJyy6RdGXSw7HVoXv9krsgRhBn0ayn6qsUc7AxcDYLQWPWOw vKJpm+ErX61PdOWeIW8R8TgUu5HhPnK38d4FYMJ18qq2r1t0MX4pTGulXfuaNr1V9B1E4+3dI3nk BRYAruZ5hO/GfxnCDKfexuySguwLMduKZTz1yvfdjj0HlFDoqoWF20+xKQ35+nd/nGlMBQ0xDQkm A/S/XltWjP649SQzhF817kql58kAx71HfxpF/K3Kf4qEIfLm3dpo8E55I3oL4X/9gaBZfvr6VL1B tSX2x7FdoqxZLLNInsq4c1pop2DuIERl592w1UzGVaY28QIxbnHhmVmUg//xFvReUB/vUq9cRUSN fRacYvJxnE2uvPYPCbpmnXes/ii2IAbWxB6xZ+NuqELn3pmRVYKU9W9tbmVXJBqdHHDm4W04ooUi IegHnDOOrq+/aMk+XoreKQ2SPH1UIIzo7c3uTDbeuuD7RyXX9xP+P0f0Ag9a4/umK8TKOyIhy/MM CWJiDTNcG3JDJbPAgvYc1/Lh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3Gd20T8xFITcF1bVYFM5+Dh5nHEeB4hpRrmo/duzUUp/KF wDYBeSemKbii9YvUlgY150ku1BnD/V+CzyU6QOlKX3LYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+AqMI8XB32z4L/a53NbOeOoj2lB9TLiDMfXuvSrucRXrlnGtGdG3g+ozMfeTuFOSvpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 04:42:41 -0000 This is a multi-part message in MIME format. --------------BF4705958E1D67DBB5B8A056 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/20/2018 11:50 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Here is a Fibonacci variant the grows slower. > Not sure it is any better, but the intention is to avoid probing very > large packets too early. > It could probably be applied recursively to avoid bin search altogether= =2E > The same idea might be applicable to reducing the congestion window as > opposed to doubling or halving. > > /* Fibonacci variant */ > /* roughly like this - untestet */ > unit =3D 10 /* min probe increment */ > a =3D minPMTU / unit > b =3D maxPMTU / unit > k1 =3D initDelta /* 1 or larger, e.g. a / 4 */ > k0 =3D 0 > while a + k0 <=3D b > k2 =3D k0 + k1 > n =3D binsearch(a + k0, min(a + k1 - 1, b), unit) > if n return n > k0 =3D k1 > k1 =3D k2 > end > /* binsearch probes multiples of unit and calls > updatePMTUEstimate(n) whenever n is a larger > valid probe than previously reported */ > Yes, there are multiple ways to go about sending probes. In the QUIC case, the peer sends its own version of MAX MTU during the handshake. So what I did was simply try the peer's MTU, and if that fail do a binary search between that and the initial value. The peer MTU is typically between 1470 and 1500, so the binary search converges very quickly. There are certainly ways to do better, especially if the peer sets its own MTU to some large value, e.g. in a data center environment. For example, one could have a table of probability of finding some particular MTU. And then apply logic based on how much the connection wants to send, what it costs to send a probe, and what is the likely gain if the probe succeeds. You could use that to choose the next probed value. Or to decide to stop probing if no plausible next value can bring a potential gain. Or to send several probes in parallel... -- Christian Huitema =20 --------------BF4705958E1D67DBB5B8A056 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 1/20/2018 11:50 PM, Mikkel Fahnøe Jørgensen wrote:
Here is a Fibonacci variant the grows slower.
Not sure it is any better, but the intention is to avoid probing very large packets too early.
It could probably be applied recursively to avoid bin search altogether.
The same idea might be applicable to reducing the congestion window as opposed to doubling or halving.

/* Fibonacci variant */
/* roughly like this - untestet */
unit = 10 /* min probe increment */
a = minPMTU / unit
b = maxPMTU / unit
k1 = initDelta /* 1 or larger, e.g. a / 4 */
k0 = 0
while a + k0 <= b
  k2 = k0 + k1
  n = binsearch(a + k0, min(a + k1 - 1, b), unit)
  if n return n
  k0 = k1
  k1 = k2
end
/* binsearch probes multiples of unit and calls
   updatePMTUEstimate(n) whenever n is a larger
   valid probe than previously reported */

Yes, there are multiple ways to go about sending probes. In the QUIC case, the peer sends its own version of MAX MTU during the handshake. So what I did was simply try the peer's MTU, and if that fail do a binary search between that and the initial value. The peer MTU is typically between 1470 and 1500, so the binary search converges very quickly.

There are certainly ways to do better, especially if the peer sets its own MTU to some large value, e.g. in a data center environment. For example, one could have a table of probability of finding some particular MTU. And then apply logic based on how much the connection wants to send, what it costs to send a probe, and what is the likely gain if the probe succeeds. You could use that to choose the next probed value. Or to decide to stop probing if no plausible next value can bring a potential gain. Or to send several probes in parallel...

-- Christian Huitema

 

--------------BF4705958E1D67DBB5B8A056-- From nobody Mon Jan 22 09:04:55 2018 Return-Path: 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 E36371277BB for ; Mon, 22 Jan 2018 09:04:53 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 Nn30idEgIHyd for ; Mon, 22 Jan 2018 09:04:52 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 E29A812762F for ; Mon, 22 Jan 2018 09:04:51 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id g14so13346119qti.2 for ; Mon, 22 Jan 2018 09:04:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=g3jj2HNJkS3tggT2u66or5Kb1z9Cdo1zx3BLs42Z0wM=; b=SX7Du0Jnbp1qzrOcGQRpXrclZqrzg6V/WY8NyGsKR7Uj6dpD1wDQD4kBIVaaf2rc4d 3GjAQYZRcAUimT1HuJkKa3sUxYwE7btc4MMMdOezK2azdwx+iAZE4/YzLrmcc/4TnDcV pTcXPcZpbdL+8u6fBkRc7QwV9JOaedlovAv5kg9Aj9FcGMUk/uzVchN/NQMQ50OS9mWp t069eX9Yu0nEhdG4pyxBPMaRQvjcEkmk4NthW+xZhV7VDV6d0HlYAjNhP7IhzBjbk3PL fDtSelFGKfxRF2EnfCz8gflNZlVms/qmNvtVkwji2t9hyArcH4INHCuQfWDjsCIn+/lZ gIfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=g3jj2HNJkS3tggT2u66or5Kb1z9Cdo1zx3BLs42Z0wM=; b=sD5m4z/b2wphgqn7d+a0QP1T7BVWKrdJMhuKC1ApMsAAYmzaGHqGrksbsXYHLHKLik e989ZmXU4D4SlQ3J4d5uzGoJgo1TO8+oMNUSQJ3O2uNbiZagsslKqG4anSmOthK3EEHD ptw0wpashsjiL2ggHANONmAuUgLIwRk+LJtbrOIu7kQtXhfZYG3g8NMOlrHDMCbgOI/4 ji5iZimaZzx735mxdAFaGpY9eeEsvm4jOrmxjomZ6nNXkweM5rYiXBEm5uuoxoAr3Aqg 7K9rppxofv+pkUmH01gwKKUi1jpeFy3NizimbVGVekg/r3foDWnJ6sBHW0Yo8n0emR6t MOlA== X-Gm-Message-State: AKwxytdYvjcziGkBCll/704FjxGOwafyYzVGdrPZHJ+xKuI+JHhzLQiu WiGkgOkSEr3Aczm1xoCDKn1R5mEDsmz4uEB+fRJ46w== X-Google-Smtp-Source: AH8x224pWXk/LqTyv6t2ditcAmYnnE2pRK0RBRn7u0ro4hLQhcaGVALFyPhef0dcCqJbee1LyME6Il/UvlXAK0adJz4= X-Received: by 10.55.121.132 with SMTP id u126mr8380556qkc.29.1516640690773; Mon, 22 Jan 2018 09:04:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.56.229 with HTTP; Mon, 22 Jan 2018 09:04:50 -0800 (PST) In-Reply-To: <272B6C51-AD9D-4AFB-9FFE-0CB40E6D1A37@strayalpha.com> References: <272B6C51-AD9D-4AFB-9FFE-0CB40E6D1A37@strayalpha.com> From: Tom Herbert Date: Mon, 22 Jan 2018 09:04:50 -0800 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-udp-options-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 17:04:54 -0000 On Sun, Jan 21, 2018 at 2:47 PM, Joe Touch wrote: > HI, Tom, > >> On Jan 21, 2018, at 1:16 PM, Tom Herbert wrote: >> >> Hi Joe, >> >> A few comments: >> >> I'm not sure what "required options" are and can't find a definition >> in he draft. The term "required option" seems to be a bit of an >> oxymoron. May this refers to options that a individual receivers can >> require to be present? > > If an endpoint supports UDP options, these are the ones that it is requir= ed to support. I will clarify that in the next update. Are all of the options defined in the draft required? >> >> In looking at polynomials for CRC-16 for GUE, I didn't get a strong >> sense that CRC-16-CCITT is ubiquitous. CRC-16 (CRC_16-IBM) is >> supported by USB, ANSI standard, and is implemented in Linux >> (CRC-16-CCITT currently is not). For GUE, we defined options for >> either CRC-CCITT or CRC-16, it might be worth considering that for UDP >> options. > > We want to pick one rather than create ambiguity and additional work. I d= on=E2=80=99t much care which one we pick; there was previous discussion on = the one we picked, but we can re-open that if you have a reason. I don't have a strong preference, either CRC-16 or CRC-16-CCITT will work. (that seems to be the consensus from original discussion also). Both of these are used and both have been implemented in HW, and, as I said, CRC-16 is already in Linux so that's a shorter path to bring up support in GUE at least. I don't see much cost in allowing both as long as it's unamiguous which one is being used. Tom From nobody Mon Jan 22 09:19:37 2018 Return-Path: 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 EC489120727 for ; Mon, 22 Jan 2018 09:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham 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 75AqqHdulX1Y for ; Mon, 22 Jan 2018 09:19:34 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 0253A1241F3 for ; Mon, 22 Jan 2018 09:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To: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=wM++lEooe3B67XYH6lpKP7nWcS9Piw9sqKHIa/+meHE=; b=q5sWd1YUZoTeboEVW0V+Id7Q8 U1I4dYV7hBFrzsMB+ABMyjtrQvgS0Mfb+FE2q2hCpePVZ3V4BVQ4HjIdx+GJNnfGEi3gLLAHubA7F qcWZ6ZKCW3hZBTPUqhFOxNL4MTEI3wcCR+PtLYMxSXqnhXTJyXumiYBnF9D2ZNX2VaVB5niNdL2J4 kbhqkchL14+n/maS5exHrfMXrJnNa3XOK/5jeQn3cc4yHavHpoijA7anmj3iYFYv0ypqyoG6VpqeF sDjKWWxzCTG2+z7CUMc5jQiuAEjrgWASIZT7JTCSoWpQosE5cICHqgHQGy5+ywjI32JWy2jcinijO u86dUi4lQ==; Received: from [204.140.240.55] (port=60039 helo=[172.26.20.142]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1edfkg-003UFz-Ip; Mon, 22 Jan 2018 12:19:23 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Joe Touch X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Mon, 22 Jan 2018 09:19:20 -0800 Cc: tsvwg Content-Transfer-Encoding: quoted-printable Message-Id: <2DAB50B0-CEB5-4918-8DB2-444E159FC53E@strayalpha.com> References: <272B6C51-AD9D-4AFB-9FFE-0CB40E6D1A37@strayalpha.com> To: Tom Herbert 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: [tsvwg] Comment on draft-ietf-tsvwg-udp-options-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 17:19:36 -0000 Hi Tom, > On Jan 22, 2018, at 9:04 AM, Tom Herbert wrote: >=20 >> On Sun, Jan 21, 2018 at 2:47 PM, Joe Touch wrote: >> HI, Tom, >>=20 >>> On Jan 21, 2018, at 1:16 PM, Tom Herbert wrote: >>>=20 >>> Hi Joe, >>>=20 >>> A few comments: >>>=20 >>> I'm not sure what "required options" are and can't find a definition >>> in he draft. The term "required option" seems to be a bit of an >>> oxymoron. May this refers to options that a individual receivers can >>> require to be present? >>=20 >> If an endpoint supports UDP options, these are the ones that it is requir= ed to support. I will clarify that in the next update. >=20 > Are all of the options defined in the draft required? See the =E2=80=9C*=E2=80=9D in the list in Sec 5. We can certainly expand th= at to include others.=20 >=20 >>>=20 >>> In looking at polynomials for CRC-16 for GUE, I didn't get a strong >>> sense that CRC-16-CCITT is ubiquitous. CRC-16 (CRC_16-IBM) is >>> supported by USB, ANSI standard, and is implemented in Linux >>> (CRC-16-CCITT currently is not). For GUE, we defined options for >>> either CRC-CCITT or CRC-16, it might be worth considering that for UDP >>> options. >>=20 >> We want to pick one rather than create ambiguity and additional work. I d= on=E2=80=99t much care which one we pick; there was previous discussion on t= he one we picked, but we can re-open that if you have a reason. >=20 > I don't have a strong preference, either CRC-16 or CRC-16-CCITT will > work. (that seems to be the consensus from original discussion also). > Both of these are used and both have been implemented in HW, and, as I > said, CRC-16 is already in Linux so that's a shorter path to bring up > support in GUE at least. I don't see much cost in allowing both as > long as it's unamiguous which one is being used. The cost is implementation complexity and the benefit seems negligible.=20 Joe=20= From nobody Mon Jan 22 15:32:42 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D430512D84E; Mon, 22 Jan 2018 15:32:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151666396082.29540.11827480572945882237@ietfa.amsl.com> Date: Mon, 22 Jan 2018 15:32:40 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-datagram-plpmtud-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 23:32:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : Packetization Layer Path MTU Discovery for Datagram Transports Authors : Godred Fairhurst Tom Jones Michael Tuexen Irene Ruengeler Filename : draft-ietf-tsvwg-datagram-plpmtud-00.txt Pages : 27 Date : 2018-01-22 Abstract: This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization layers. The method allows a Packetization layer (or a datagram application that uses it) to probe an network path with progressively larger packets to determine a maximum packet size. The document describes as an extension to RFC 1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for IPv4 and IPv6. This provides functionally for datagram transports that is equivalent to the Packetization layer PMTUD specification for TCP, specified in RFC4821. When published, this specification updates RFC4821. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-00 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-datagram-plpmtud-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 Thu Jan 25 02:41:12 2018 Return-Path: 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 8BC8612D967; Thu, 25 Jan 2018 02:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 5Nra79a4boWQ; Thu, 25 Jan 2018 02:41:06 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB4B126CBF; Thu, 25 Jan 2018 02:41:06 -0800 (PST) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7BFC91B001CF; Thu, 25 Jan 2018 10:41:04 +0000 (GMT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id B9E7E216CA; Thu, 25 Jan 2018 05:41:00 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 25 Jan 2018 05:41:00 -0500 X-ME-Sender: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [139.133.204.4]) by mail.messagingengine.com (Postfix) with ESMTPA id C785124640; Thu, 25 Jan 2018 05:40:59 -0500 (EST) Date: Thu, 25 Jan 2018 10:40:57 +0000 From: Tom Jones To: Christian Huitema Cc: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Michael Tuexen , Gorry Fairhurst , "tsvwg@ietf.org" , QUIC WG Message-ID: <20180125104057.GA9797@tom-desk.erg.abdn.ac.uk> References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 10:41:10 -0000 On Sun, Jan 21, 2018 at 06:42:27PM -1000, Christian Huitema wrote: > > > On 1/20/2018 11:50 PM, Mikkel Fahne Jrgensen wrote: > > Here is a Fibonacci variant the grows slower. > > Not sure it is any better, but the intention is to avoid probing very > > large packets too early. > > It could probably be applied recursively to avoid bin search altogether. > > The same idea might be applicable to reducing the congestion window as > > opposed to doubling or halving. > > > > /* Fibonacci variant */ > > /* roughly like this - untestet */ > > unit = 10 /* min probe increment */ > > a = minPMTU / unit > > b = maxPMTU / unit > > k1 = initDelta /* 1 or larger, e.g. a / 4 */ > > k0 = 0 > > while a + k0 <= b > > k2 = k0 + k1 > > n = binsearch(a + k0, min(a + k1 - 1, b), unit) > > if n return n > > k0 = k1 > > k1 = k2 > > end > > /* binsearch probes multiples of unit and calls > > updatePMTUEstimate(n) whenever n is a larger > > valid probe than previously reported */ > > > Yes, there are multiple ways to go about sending probes. In the QUIC > case, the peer sends its own version of MAX MTU during the handshake. So > what I did was simply try the peer's MTU, and if that fail do a binary > search between that and the initial value. The peer MTU is typically > between 1470 and 1500, so the binary search converges very quickly. Thanks for the comment, this is an interesting approach we probably need some discussion of the probe size search algorithm in the draft. Is the ~1500 value something you have manually configured or have you found it from the host? maxdgram on my machine is 9216. > There are certainly ways to do better, especially if the peer sets its > own MTU to some large value, e.g. in a data center environment. For > example, one could have a table of probability of finding some > particular MTU. And then apply logic based on how much the connection > wants to send, what it costs to send a probe, and what is the likely > gain if the probe succeeds. You could use that to choose the next probed > value. Or to decide to stop probing if no plausible next value can bring > a potential gain. Or to send several probes in parallel... > RFC1191 suggested a table with some common values. I would try: - validating the base ~1280 - probing for ~1500 - if that works probing for the Max MTU from the peer then falling back to a search algorithm to close the gap if it is a sensible size. - [tj] From nobody Thu Jan 25 02:59:08 2018 Return-Path: X-Original-To: tsvwg@ietf.org Delivered-To: tsvwg@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 026DF12DA12; Thu, 25 Jan 2018 02:59:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151687794696.14413.14394806466417256236@ietfa.amsl.com> Date: Thu, 25 Jan 2018 02:59:07 -0800 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-aqm-dualq-coupled-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 10:59:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group WG of the IETF. Title : DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S) Authors : Koen De Schepper Bob Briscoe Olga Bondarenko Ing-jyh Tsang Filename : draft-ietf-tsvwg-aqm-dualq-coupled-03.txt Pages : 36 Date : 2018-01-24 Abstract: Data Centre TCP (DCTCP) was designed to provide predictably low queuing latency, near-zero loss, and throughput scalability using explicit congestion notification (ECN) and an extremely simple marking behaviour on switches. However, DCTCP does not co-exist with existing TCP traffic---DCTCP is so aggressive that existing TCP algorithms approach starvation. So, until now, DCTCP could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification defines `DualQ Coupled Active Queue Management (AQM)' to allow scalable congestion controls like DCTCP to safely co-exist with classic Internet traffic. The Coupled AQM ensures that a flow runs at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but without inspecting transport layer flow identifiers. When tested in a residential broadband setting, DCTCP achieved sub-millisecond average queuing delay and zero congestion loss under a wide range of mixes of DCTCP and `Classic' broadband Internet traffic, without compromising the performance of the Classic traffic. The solution also reduces network complexity and eliminates network configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-03 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-aqm-dualq-coupled-03 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 Thu Jan 25 02:59:48 2018 Return-Path: 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 3F08312E88E for ; Thu, 25 Jan 2018 02:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cablelabs.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 14ihOaHAg-Vf for ; Thu, 25 Jan 2018 02:59:45 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0117.outbound.protection.outlook.com [104.47.42.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 346E312E896 for ; Thu, 25 Jan 2018 02:59:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cablelabs.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VJsdQJRU1a580LFaCjOL5w+wgvTlcB+b9u/HTLRuvMY=; b=WrKXZX9ylPCW5QvaR21g7Sug3XqJ2lBzJiJ15eQfhGwYIlTy99QnD0h2uRzsbnO8s5LEBP3z0YMfQ57MIsq+v7eEpK6BS+7NzXHoyYemcU/6C1lFJDK6XOOVMvNl+ERhHF3zUyykww67Ya5j52Q64YQ3WS4X2YVEQQJlnDTWwc0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=B.Briscoe-contractor@cablelabs.com; Received: from [10.209.65.93] (31.221.87.68) by SN4PR0601MB3629.namprd06.prod.outlook.com (2603:10b6:803:4b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Thu, 25 Jan 2018 10:59:39 +0000 To: tsvwg IETF list From: Bob Briscoe Message-ID: Date: Thu, 25 Jan 2018 10:59:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Originating-IP: [31.221.87.68] X-ClientProxiedBy: CWLP265CA0028.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:11::16) To SN4PR0601MB3629.namprd06.prod.outlook.com (2603:10b6:803:4b::11) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ac32dd14-7680-4b4a-b550-08d563e2bb3c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060)(7193020); SRVR:SN4PR0601MB3629; X-Microsoft-Exchange-Diagnostics: 1; SN4PR0601MB3629; 3:Svf5UPDGnGUmsVhcUZu9YA1tHvQOyu3tUFMOVYt68PLewegVt/7yB662B8kUqB2M/MbThjWOjKu4XGxekcXzMFsomOD65ofkjOOtbaayL+1X0qrtcxpfiJuWGWRbomhIlxzdit9+aUQkBsXqjxGrbSe/Gxi6fKeaz7GLB9CG5z6O1uTD9m8JO12Mzc+QquSJ9p5EKbO4UPfZISC9rl2lOdcKwoM4LSXNl1v3gVCZbuw47ExBLcfL3zkSTHEJClZx; 25:sOUU3ROc2N65n5J0uToCFEcLXCrTP3IJzFmJvHArBi161vKF9byz+9mXp0A7HByhr9j4A67NMRLM49vBzDiPc6eZFd+ZagOmGX/p2BXiiGmiVdn+miw4xbFN05fvmyt4nhOJHtUX/hYLvDkCyNC0A0+yTQGSmQKYHFbx1zbDTvac9xdhodH/gI+F0q2G4hRDWEd5cTa+XnhxJOMPYKh3IILD83O+wj8ReatqCBoanuVtVyV/NjIGsuGN4u3ogMZGHohSw2szXOvaEpNf1KMfamfnWybUz36OarDQC8q/x/bWVsp8rhQbX+oxVqmzy6izeZeTcQVeTpM8Ou7Zm6lLvw==; 31:xgd/CwAzhAs69p3DEcduPCEAS/2Qumy8FPHHQQRTgh9KBV8Gl8tDXHxPUcz+Kp1wGJQbY71if7uP4plefdmgYFxNpOa467iE8RST6xDzQErUkrMmomTCVOx4HRUfSkATCFJvbjyI/2I8BU/ukFGRuSxJLPShk1ao0lkHwcOEAsRG4JR1eHlIUP3wqALM2Oji3Lgpx6YlLHGv7HbWjfiHoNL3FfpnM4VHoJr5TFYP1Rs= X-MS-TrafficTypeDiagnostic: SN4PR0601MB3629: X-Microsoft-Exchange-Diagnostics: 1; SN4PR0601MB3629; 20:GL0NwOK1ivXJ2RKY1tag+LQlSSEGpcIgazGzzy/KWqEsFMDQW9bq0X/FYN04URD0CY4ve1nBSFxsfJX9K/dB9Im6Lldvkk/cC7O7pCMg1OK1JcgYqajLlQ9OhsiAEbtQx84ChIaTrCzi+zNO0y3/Tgvq77+IBKVDNUrcplvPb576RxT/ocV3J4a1EXheKReRMr/1USsGDEhQxcMMnfDydWtOrGyD1f0Lc3tC3wS8XCdZnoBWxBv+UcIhf8v0GMrJ+8aJ5/RBwVf8Gc0v3bhFsKn3V/QkxDLxLBZuoto/YyQjOsyNZAOMXONFMhWhqZ/CS4jRdEs21iJjAaad7K9vlZCj9jTPVjC76Fldksz2lvyBmAjdHAVFsA57nv0rbd+Zfgm/Vi4WCkMdFSpWxSr+g7y5ybIdT4R3iMKfLmzvYGxtDZEwLX7q03UyZ8EMpzPbjPr5KL3gHscMLwcZSTVsnFG4KYiRyCeKW1JP4btMzlzL4hjY07C9m1m676emzcK3; 4:sQUaV7jkpg4owa9H06eDsAVUE17MjA9Bsq8bkwhitvtnhtl5LxpKQTUeW6gzoTOY3+4CrcVnYUM9zJDYSOOoDHOraxsoOqy/H/dSOIbT4lJxW6TnNiGuyET+pWNYSii+89VQL6fUDq11mT46Cv0cPPTotDqFhebKyTY9Zj+rKQ39nGc0QecymrtRqse9s680VRGnLmI8e1opCdv7SQqmmJLCaW4qOVU4N3gVGatZGJfP5+ehtDJVeP1YPFXtXKG45EcrIvwWMWW3CfLIlKvZlw== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231023)(2400081)(944501161)(6041288)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:SN4PR0601MB3629; BCL:0; PCL:0; RULEID:; SRVR:SN4PR0601MB3629; X-Forefront-PRVS: 0563F2E8B7 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(366004)(396003)(376002)(39380400002)(39850400004)(346002)(199004)(189003)(6666003)(64126003)(3846002)(26005)(58126008)(81166006)(81156014)(50466002)(6486002)(67846002)(65806001)(83506002)(8676002)(23676004)(230783001)(2486003)(386003)(186003)(52146003)(65956001)(53936002)(66066001)(72206003)(6116002)(55236004)(36756003)(105586002)(47776003)(52116002)(5660300001)(68736007)(106356001)(316002)(86362001)(305945005)(16576012)(31696002)(77096007)(16526018)(25786009)(230700001)(2906002)(65826007)(6916009)(15650500001)(97736004)(31686004)(8936002)(7736002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN4PR0601MB3629; H:[10.209.65.93]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: cablelabs.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtTTjRQUjA2MDFNQjM2Mjk7MjM6RFpCTGkwRGNZUEZBWW95SG5hQ09CbUo2?= =?utf-8?B?bkdjUGNFd3lPMytQUGxLOFkxNUgwMkt6NjN2ZFg2SGJObnRQbUhjY1hyVlZs?= =?utf-8?B?bWdrNS9waHloeDZrWDBVSmJoVm9zR2ZRR1YrcDh1NDR6Qit1OVBsckVoSXlU?= =?utf-8?B?cmc0am9wYzJaL3g5eVVmUjVsU0ROYW44cDdteE9TczJLZkJxcE1FbWJCSTlh?= =?utf-8?B?dTBqVit5aDlaU0NIV0Z2aHp4aXgyeHBNakMvZ2w1VHlBWDJ1dHlTNnBLUjVM?= =?utf-8?B?NkNkZWdBNmk5LzVDZ3YwZEIrZkllUGdnbG52REhiUW5URGY2eEE0NzZ6cEk5?= =?utf-8?B?K3UxVXoxRGR5dXpKbWVoK2VvSzBvRTJjN2ZPVFYxWmxWMFIyYnkzU0x4OHk0?= =?utf-8?B?TGpzem8zVDhXaWY4eXNoRmMwUm5jVWdEMjZ6ckRTa1JYQUVzNWZhM3kxR3Jm?= =?utf-8?B?aEp2WmtmeHp0RjFnVnFKRkFON0luUERMNnl1WWxva0NOekJ2ck1aME1ncldF?= =?utf-8?B?UFk1N0FoWWtpRnh0NjdJcHVNSWgrTzVFQ1gvYU1tc2lIbmxzZzZwRXJFQ0o4?= =?utf-8?B?WFJoUzludTJzUG5nNVhZNHBDaXBoMkdleHBsTVA0VEtzV2FaZ1ZFa2tMNjBr?= =?utf-8?B?RTUxL2xoemhXSXNHTkxhT29LMWRzLzJtTTZUd04rR1AwaHFYWTNGMnZoOGZK?= =?utf-8?B?LzBQRjVNVXdxRDNQbjQwU1BMZ2tiMmc1bmx3U3NmMER4QzlYcXdlb2VZYjhj?= =?utf-8?B?ZEc0QVhIc2Y1dkVWRzRXV2FKMGp3U3hDVzVuQ1pyMWprazNlMzBMdEJxZ2VT?= =?utf-8?B?cmsvbmRBei80MjNwNEZiTlBYRUwrZXMyS01VVnF4OUlrdlF4d2VXSHpENmd4?= =?utf-8?B?SThNSzNtV1hFb1p1M3J4dEQ1UFZCQWRJeGhjOXczdDg0QytNVW1IVW80aVQy?= =?utf-8?B?L1NCeXJNNUNURnFlZlBITk84RjlncVMwMnZEVHcwNDdIMVBuaWViTks3RW5r?= =?utf-8?B?Z2pYQi9xdE5uTUc3T2E4QmlMOXViR2Y4WmtTYXpvOUZVOWNISWlYVlVoL3d6?= =?utf-8?B?NGYzeFlFWUVpaWNwQzhvS1RPNk1TUEh6RCtWUGl3ZkRqSEZheTFLL2FIM21B?= =?utf-8?B?R3UvcFlEcVBRU0tEdHNhSkg0SmlBSnRNMmlOcEtDZjZITldPS2ZEQW5XdEZm?= =?utf-8?B?K0FNZjhqSEdPaTI3bGJqMVJQQ3dVT3JxQ2FzdGttSVIyL0hlSTBKcnB4dWR4?= =?utf-8?B?azlDNlRjSjd1T0ZvTW5VLzZKTGh2QUxhNml0cW9iSGJ2Y2hEU2VUYjVoa2J0?= =?utf-8?B?N0tWYmFRUk1OVUdoVExQT1cxbzlCZElTQnMxM2Jsa3IvdGhERk9hNmlJVVl6?= =?utf-8?B?MjY5blpoVHVuTkNmSlo3QU1ER3JPVDlYODhwYlNqdnltUWxrcHJ5alU2MGNI?= =?utf-8?B?Qzk3UWdvVC9PbHVCeEV3SG04R256ME1vc05INmU4K253K2kwdEViMTlHWUgx?= =?utf-8?B?K1gwdUdSVmoySEFMODIrNnl2ZUhXOEtWYWVFZ3JVZEY4TTZVc1N5Y3p3ZS9F?= =?utf-8?B?ZVZ5czhxSEF6ZXFtUEYrZXhUZjErUkFyQXRnZkRCRFVJMmhHQWpOTEdQVmMz?= =?utf-8?B?VlE2b0xIeElrenQyYld6aHl4ZGRDb2RhaFl3bXNYS0FNNTk5V1dOZTRCUHV5?= =?utf-8?B?M3Fic2F2VURUZXE0OGpzRWVUNmF6eGFJL0FOWjZ4SG93SXRyaXBjYzJPWUxM?= =?utf-8?B?b20wV0duZUlBVHpTQzhQMGF0c0R2L2MvSWkvVUFhZHp5N3ZKazBjU2lHNGww?= =?utf-8?Q?aDMD41jYD+900QC?= X-Microsoft-Exchange-Diagnostics: 1; SN4PR0601MB3629; 6:7ocX1VSc6afJ7VJSndt2fGGHjij4OHoSNJboYkVRfO/4h8grkYdd4HCtw4didRUiejURtTb5JAsIqLBduaDsKDwSVDzOZpPnDSwMRmLFbu0teTnciSYoQ8bGq0DyTfzRk3sJXW7m7CJmKnvgUlmAuVc3zQpMllKTgYb5SS5fDdbhckmNJGkj7h47FxzwXtRGAjUezun79DzI8/+94ECzAV8VlXnWChbUc1vdrqIS8si3QGtpPNsk990RRZxI0HCl1F0U1JWjV+KDnfXgkQ9ynlFcbZzr8T49295+/czyv/W5Hij75azrImmCyskgqEzJhcyqkpTXcmun3Fx7bFoYhiDY3L4XqhnPx3Sm7UZbUQA=; 5:KRJFY8k8ISu3W49HRRbq05XXUyEbEoe98bE7CvXQ8DTAF0dM8sdrtOk2FrbEIrJjGCRgLBD4flqCA53iQLVDMAotXrRzG9tbOQCFmuLM2UsvnXVfvbBg6A6GhYNRxz0bstsBVA9eImtvSPmif6BBKyyaFdIBVnJWBP/GjyR9U6g=; 24:tAR7T1b+aWqq9tgJRLiuxA8iq9KAce5/ILeLwJcHd32iLk/Ye314RnlwTHEUwOS2gSXxdMYF7dINNT6Zjwk/mTCEjE4DGdlvGO5vEMf0OhY=; 7:6uchn8mM/HjenGz+KhUz7Yv/MMfKrbDCVA23sNAXhWhGADgVqEvGsxR4PtF504+jywsqdSK5iBtwZSzfzXdWsNRV8Zy9cYIyBKBperJZCFaqe7OAHrlJCl911KpjrlbRDHxgKzY0x8Lm9Pr1Z9CaaUJ0Eopvvx6VYyr1Tp9bLyxx0pP5TmVQ7LgebwVG7Nkw+JKT93yZz/TpqIxgoR6AP1v/J6aBLI/iNK5QJXIucKsxbTq5iC0VImvHtRRbZmEs SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: cablelabs.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2018 10:59:39.3494 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ac32dd14-7680-4b4a-b550-08d563e2bb3c X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ce4fbcd1-1d81-4af0-ad0b-2998c441e160 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0601MB3629 Archived-At: Subject: [tsvwg] draft-ietf-tsvwg-aqm-dualq-coupled update X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 10:59:47 -0000 Folks, We've updated the draft on the L4S dualq-coupled AQM, based on continuing evaluation work. As well as minor improvements throughout, the main changes are: * S.2.4: Tidied up some sloppiness in the description of the probability level where it is coupled across the queues. * S2.5.1: Priority of L4S over Classic MUST be conditional to prevent starvation (was SHOULD) * S.4.1: Overload handling section: Completely restructured, to give clear problem descriptions and solution choices. DualPI2 Pseudocode Appendix A * Generalized the scheduler between the two queues to either WRR or time-shifted FIFO and explains the pros and (minor) cons of each. * Generalized the queue delay measurement technique to either sojourn time or rate-based estimation * Generalized the native L4S AQM to either a step or a ramp function. * Added an open issues appendix (D). Cheers Bob From nobody Thu Jan 25 05:02:07 2018 Return-Path: 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 576CE129966; Thu, 25 Jan 2018 05:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xUApPTFCHVMX; Thu, 25 Jan 2018 05:02:00 -0800 (PST) Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (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 B157012751F; Thu, 25 Jan 2018 05:01:59 -0800 (PST) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id w0PD0GUk021077 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jan 2018 14:00:16 +0100 Received: from [2001:638:809:ff1f::8295:dc66] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eeh80-0003b3-TL; Thu, 25 Jan 2018 13:59:40 +0100 From: "Philipp S. Tiesel" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EBD182D4-1C4F-4445-BBBC-A549E4DDC1AD" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 25 Jan 2018 14:00:14 +0100 In-Reply-To: <20180125104057.GA9797@tom-desk.erg.abdn.ac.uk> Cc: Christian Huitema , Gorry Fairhurst , Michael Tuexen , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , "tsvwg@ietf.org" To: Tom Jones References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net> <20180125104057.GA9797@tom-desk.erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 13:02:02 -0000 --Apple-Mail=_EBD182D4-1C4F-4445-BBBC-A549E4DDC1AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25. Jan 2018, at 11:40, Tom Jones wrote: >=20 > On Sun, Jan 21, 2018 at 06:42:27PM -1000, Christian Huitema wrote: >>=20 >>=20 >> On 1/20/2018 11:50 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >>> Here is a Fibonacci variant the grows slower. >>> Not sure it is any better, but the intention is to avoid probing = very >>> large packets too early. >>> It could probably be applied recursively to avoid bin search = altogether. >>> The same idea might be applicable to reducing the congestion window = as >>> opposed to doubling or halving. >>>=20 >>> /* Fibonacci variant */ >>> /* roughly like this - untestet */ >>> unit =3D 10 /* min probe increment */ >>> a =3D minPMTU / unit >>> b =3D maxPMTU / unit >>> k1 =3D initDelta /* 1 or larger, e.g. a / 4 */ >>> k0 =3D 0 >>> while a + k0 <=3D b >>> k2 =3D k0 + k1 >>> n =3D binsearch(a + k0, min(a + k1 - 1, b), unit) >>> if n return n >>> k0 =3D k1 >>> k1 =3D k2 >>> end >>> /* binsearch probes multiples of unit and calls >>> updatePMTUEstimate(n) whenever n is a larger >>> valid probe than previously reported */ >>>=20 >> Yes, there are multiple ways to go about sending probes. In the QUIC >> case, the peer sends its own version of MAX MTU during the handshake. = So >> what I did was simply try the peer's MTU, and if that fail do a = binary >> search between that and the initial value. The peer MTU is typically >> between 1470 and 1500, so the binary search converges very quickly. >=20 > Thanks for the comment, this is an interesting approach we probably = need > some discussion of the probe size search algorithm in the draft.=20 Ack; =E2=80=93 I think the main question is whether you want a generic algorithm or something that is optimised for today=E2=80=99s Internet, but also somehow works otherwise. >=20 > Is the ~1500 value something you have manually configured or have you > found it from the host? maxdgram on my machine is 9216. 1500 is default for Ethernet without Jumbo Frames. >> There are certainly ways to do better, especially if the peer sets = its >> own MTU to some large value, e.g. in a data center environment. For >> example, one could have a table of probability of finding some >> particular MTU. And then apply logic based on how much the connection >> wants to send, what it costs to send a probe, and what is the likely >> gain if the probe succeeds. You could use that to choose the next = probed >> value. Or to decide to stop probing if no plausible next value can = bring >> a potential gain. Or to send several probes in parallel... >>=20 >=20 > RFC1191 suggested a table with some common values. I would try: >=20 > - validating the base ~1280 > - probing for ~1500 > - if that works probing for the Max MTU from the peer >=20 > then falling back to a search algorithm to close the gap if it is a > sensible size. I think the table from RFC1191 will need updating, but I think this approach works best: - validating the base ~1280 - probe table of common MTUs (linear or binary search)=20 including Max MTU=20 - do some search between the largest working / smallest non-working MTU Whereby I would use some exponential search variant (not tested): =20 MTUsearch (a,b,step): if probeMTU(b-step): MTU :=3D b-step a :=3D b-step step =3D step/2 else b =3D b-step step =3D step*2 if b > a MTUsearch(a,b,step) =20 =20 Rational behind that is that MTUs will usually be LL-MTU (hopefully in = the table) minus some encapsulation. AVE! Philipp S. Tiesel / phils=E2=80=A6 --Apple-Mail=_EBD182D4-1C4F-4445-BBBC-A549E4DDC1AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 25. Jan 2018, at 11:40, Tom Jones <tom@erg.abdn.ac.uk> = wrote:

On Sun, Jan 21, 2018 at 06:42:27PM -1000, Christian Huitema = wrote:


On 1/20/2018 11:50 PM, Mikkel Fahn=C3=B8e = J=C3=B8rgensen wrote:
Here is a Fibonacci variant the grows slower.
Not= sure it is any better, but the intention is to avoid probing very
large packets too early.
It could probably be = applied recursively to avoid bin search altogether.
The = same idea might be applicable to reducing the congestion window as
opposed to doubling or halving.

/*= Fibonacci variant */
/* roughly like this - untestet = */
unit =3D 10 /* min probe increment */
a =3D= minPMTU / unit
b =3D maxPMTU / unit
k1 =3D = initDelta /* 1 or larger, e.g. a / 4 */
k0 =3D 0
while a + k0 <=3D b
 k2 =3D k0 + k1
 n =3D binsearch(a + k0, min(a + k1 - 1, b), unit)
 if n return n
 k0 =3D k1
 k1 =3D k2
end
/* binsearch = probes multiples of unit and calls
=   updatePMTUEstimate(n) whenever n is a larger
=   valid probe than previously reported */

Yes, there are multiple ways to go about sending = probes. In the QUIC
case, the peer sends its own version = of MAX MTU during the handshake. So
what I did was simply = try the peer's MTU, and if that fail do a binary
search = between that and the initial value. The peer MTU is typically
between 1470 and 1500, so the binary search converges very = quickly.

Thanks for the = comment, this is an interesting approach we probably need
some discussion of the probe size search algorithm in the = draft.

Ack; =E2=80=93 I think the main question is = whether you want a generic
algorithm or something that is = optimised for today=E2=80=99s Internet,
but also somehow works = otherwise.


Is the ~1500 value something = you have manually configured or have you
found it from the = host? maxdgram on my machine is 9216.

1500 is default for Ethernet without Jumbo = Frames.

There = are certainly ways to do better, especially if the peer sets its
own MTU to some large value, e.g. in a data center = environment. For
example, one could have a table of = probability of finding some
particular MTU. And then apply = logic based on how much the connection
wants to send, what = it costs to send a probe, and what is the likely
gain if = the probe succeeds. You could use that to choose the next probed
value. Or to decide to stop probing if no plausible next = value can bring
a potential gain. Or to send several = probes in parallel...


RFC1191 suggested a table with some common values. I would = try:

- validating the base ~1280
= - probing for ~1500
- if that works probing for the = Max MTU from the peer

then falling back to = a search algorithm to close the gap if it is a
sensible = size.


I think = the table from RFC1191 will need updating, but I think this
approach works best:
 - validating = the base ~1280
 - probe table of common MTUs = (linear or binary search) 
  =  including Max MTU 
 - do some = search between the largest working / smallest non-working MTU

Whereby I would use some = exponential search variant (not tested):
 
 MTUsearch = (a,b,step):
   if = probeMTU(b-step):
      MTU :=3D = b-step
      a =   :=3D b-step
      step = =3D step/2
   else
      b =3D b-step
  =     step =3D step*2
   if b = > a
      MTUsearch(a,b,step) =    
 
Rational behind that is that MTUs will usually be = LL-MTU (hopefully in the table) minus some encapsulation.

AVE!
  Philipp S. Tiesel / phils=E2=80=A6
= --Apple-Mail=_EBD182D4-1C4F-4445-BBBC-A549E4DDC1AD-- From nobody Thu Jan 25 07:35:42 2018 Return-Path: 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 518C7126B6E; Thu, 25 Jan 2018 07:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 fuGZ-9o4rNHf; Thu, 25 Jan 2018 07:35:38 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 D1B92124BAC; Thu, 25 Jan 2018 07:35:37 -0800 (PST) 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=FfGdriwYytEWGlxuf7uNTlckCg/hfQET5xagf7XnmE8=; b=z3Ld/Jonzq7bxPb5M4euU0KZX /bNovbVBw+Va23U4FDXrOHtpcM43mmxNdl2Qyi4A2Ru9loCJiX2e8TcccW9LagLHyNjRI/+LrOvHq zAlAoPovlyK8NiP4hYdX6ijLtVccWh9JmlenUSRmhveIGvNlKQAgn8VtQnAfQcXlUNH3oFGV7uA9c i7ElNzEXfZM55FsiPSGDvTXs+SBJc9folOlkX3M/SfFKicPfeDU9RQ9R1JE9x4UWRabOb3lIwxLAA 5yAqflOYF945LxUUzFDyaFAcPsONzTpD1B+SVkaGezd7cLfmqNXld3vCvJ8HarRzUVAnQcaY8va1S NcB2mortw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49886 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eejYG-003oSm-PX; Thu, 25 Jan 2018 10:35:03 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_249E98D2-0E71-4E2E-9F3A-4712DBCB74B4" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Joe Touch In-Reply-To: Date: Thu, 25 Jan 2018 07:34:38 -0800 Cc: Tom Jones , Gorry Fairhurst , "tsvwg@ietf.org" , Christian Huitema , Michael Tuexen , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG Message-Id: References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net> <20180125104057.GA9797@tom-desk.erg.abdn.ac.uk> To: "Philipp S. Tiesel" X-Mailer: Apple Mail (2.3445.5.20) 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: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 15:35:40 -0000 --Apple-Mail=_249E98D2-0E71-4E2E-9F3A-4712DBCB74B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 25, 2018, at 5:00 AM, Philipp S. Tiesel = wrote: >=20 >=20 >=20 >> On 25. Jan 2018, at 11:40, Tom Jones > wrote: >> ... >> Thanks for the comment, this is an interesting approach we probably = need >> some discussion of the probe size search algorithm in the draft.=20 >=20 > Ack; =E2=80=93 I think the main question is whether you want a generic > algorithm or something that is optimised for today=E2=80=99s Internet, > but also somehow works otherwise. 1) we should have a generic algorithm that should be applicable across = all PLPMTUD variants, unless there are specific reasons otherwise. This = is a wheel that should not be reinvented for each packetization layer = protocol. 2) whatever you *think* =E2=80=9Ctoday=E2=80=99s Internet is=E2=80=9D, = you=E2=80=99re wrong today and you=E2=80=99ll be very wrong in the = future. Design to work well in most environments most of the time, and = you=E2=80=99ll have =E2=80=9Coptimized=E2=80=9D for the most important = case for the Internet - ubiquity and longevity. Joe= --Apple-Mail=_249E98D2-0E71-4E2E-9F3A-4712DBCB74B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 25, 2018, at 5:00 AM, Philipp S. Tiesel <phils@in-panik.de> = wrote:


On 25. Jan 2018, at 11:40, Tom = Jones <tom@erg.abdn.ac.uk> wrote:
...
Thanks for the comment, this is an = interesting approach we probably need
some discussion of = the probe size search algorithm in the draft. 

Ack; =E2=80=93 I think the main = question is whether you want a generic
algorithm or = something that is optimised for today=E2=80=99s Internet,
but also somehow works = otherwise.

1) we = should have a generic algorithm that should be applicable across all = PLPMTUD variants, unless there are specific reasons otherwise. This is a = wheel that should not be reinvented for each packetization layer = protocol.

2) whatever you *think* = =E2=80=9Ctoday=E2=80=99s Internet is=E2=80=9D, you=E2=80=99re wrong = today and you=E2=80=99ll be very wrong in the future. Design to work = well in most environments most of the time, and you=E2=80=99ll have = =E2=80=9Coptimized=E2=80=9D for the most important case for the Internet = - ubiquity and longevity.

Joe
= --Apple-Mail=_249E98D2-0E71-4E2E-9F3A-4712DBCB74B4--