From nobody Thu Feb 2 11:11:29 2017 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 B8F52129538 for ; Thu, 2 Feb 2017 11:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Drzaz_K-LikN for ; Thu, 2 Feb 2017 11:11:14 -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 CE731129519 for ; Thu, 2 Feb 2017 11:11:14 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B71EFB81E4A; Thu, 2 Feb 2017 11:11:14 -0800 (PST) To: randall@lakerest.net, tuexen@fh-muenster.de, ka-cheong.poon@oracle.com, peterlei@cisco.com, vladislav.yasevich@hp.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, gorry@erg.abdn.ac.uk, david.black@emc.com, wes@mti-systems.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170202191114.B71EFB81E4A@rfc-editor.org> Date: Thu, 2 Feb 2017 11:11:14 -0800 (PST) Archived-At: Cc: text/plain@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, tsvwg@ietf.org, charset=UTF-8@rfc-editor.org Subject: [tsvwg] [Technical Errata Reported] RFC6458 (4921) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:11:15 -0000 The following errata report has been submitted for RFC6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6458&eid=4921 -------------------------------------- Type: Technical Reported by: Jonathan Leighton Section: 9.1 Original Text ------------- If sd is an IPv4 socket, the addresses passed must be IPv4 addresses. If the sd is an IPv6 socket, the addresses passed can either be IPv4 or IPv6 addresses. Corrected Text -------------- If sd is an IPv4 socket, the passed addresses must be IPv4 addresses. If sd is an IPv6 socket, the passed addresses must be IPv6 addresses. Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4 address. Note that some implementations optionally allow IPv4 addresses to be passed in directly. Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6458 (draft-ietf-tsvwg-sctpsocket-32) -------------------------------------- Title : Sockets API Extensions for the Stream Control Transmission Protocol (SCTP) Publication Date : December 2011 Author(s) : R. Stewart, M. Tuexen, K. Poon, P. Lei, V. Yasevich Category : INFORMATIONAL Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Fri Feb 3 02:20:05 2017 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 662D1129BCE for ; Fri, 3 Feb 2017 02:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 oBt71aqagFem for ; Fri, 3 Feb 2017 02:20:02 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 A9828127078 for ; Fri, 3 Feb 2017 02:20:02 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1cZayG-0004Rc-PP; Fri, 03 Feb 2017 11:20:00 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id A769AB00206; Fri, 3 Feb 2017 11:20:00 +0100 (CET) To: "Black, David" , "tsvwg@ietf.org" References: From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: Date: Fri, 3 Feb 2017 11:20:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1486117200. Archived-At: Subject: Re: [tsvwg] LE PHB draft - relationship to RFCs 3662 and 4594 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 10:20:04 -0000 Hi David, Am 17.12.2016 um 01:10 schrieb Black, David: > First of all, many thanks for working on this draft. I will find the time to do a > more detailed review of its contents, but wanted to quickly cover some > more process oriented matters regarding RFC updating. > > The header of draft-ietf-tsvwg-le-phb-00 currently says: > Updates: 3662,4594 (if approved) > > That usually requires some supporting text to explain the updates (e.g., there > are ADs who will look for that text): > > 1) My understanding of the discussion has been that this draft should obsolete > RFC 3662, with this draft replacing it as the definition of the Lower Effort PHB. Yes, I changed that for the next version. > 2) Please add a section indicating exactly what is being changed in RFC 4594. Thanks for the hint, makes sense. I did that, it will be included in the next version. Regards, Roland From nobody Sun Feb 5 07:06:03 2017 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 3E8161279EB for ; Sun, 5 Feb 2017 07:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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_MED=-2.3, 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=ericsson.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 gpX_q0G9QNGh for ; Sun, 5 Feb 2017 07:05:58 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 CAF851204D9 for ; Sun, 5 Feb 2017 07:05:57 -0800 (PST) X-AuditID: c1b4fb30-b83ff70000007389-b0-58973f521d64 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id BE.6D.29577.25F37985; Sun, 5 Feb 2017 16:05:56 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.319.2; Sun, 5 Feb 2017 16:05:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=s7W4jEUjrO0Rdpf8T56FP67uUxAEq+IiNZzL/vMOjy0=; b=fjRlzlLr/hCmgx5JzPjOqIUcIal7TxS/gdWiEcWpdeMc74tfwLgL0ruy+PDaUo1Z+S+Sne5mRgC4I4By9OSm5CQKIY5EGYTVawSHh6Urok9xpTb1zBnoy6dcqY4kgRQxbt7nDFQXvtU68RpfxTU6RtCqm5ZZtMjNKctsz2i44y8= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB0637.eurprd07.prod.outlook.com (10.141.43.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Sun, 5 Feb 2017 15:05:53 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0888.022; Sun, 5 Feb 2017 15:05:51 +0000 From: Ingemar Johansson S To: "tsvwg@ietf.org" , "'gorry@erg.abdn.ac.uk' (gorry@erg.abdn.ac.uk)" , "'mirja.kuehlewind@tik.ee.ethz.ch'" , Spencer Dawkins at IETF , Gonzalo Camarillo , "Black, David" Thread-Topic: 3GPP Clarification on the use of Explicit Congestion Notification (ECN) Thread-Index: AdJ/v8InZ2OFhaCURdSjDo34BDEC9Q== Date: Sun, 5 Feb 2017 15:05:51 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [213.113.27.92] x-microsoft-exchange-diagnostics: 1; DB4PR07MB0637; 7:dagdacwfIsnKavvTUsUWoo6XoqDw7sUZ+ZLpjsgQsWbBXPToSJIAZX7fYh4H2Twl9A31Bg5RWSgG75IxP072/fWh4lbmJv/Sp1G+5GbjPRm2iO77aN/paLp+qHbG3sCqm/yDhYwSgep1pW4AGtsonww/Fn48volAn9V9e+3Zl1/x/MqKaSHG7xh8Tx5eERHi0v0jePNRxhqdX9RJYwStPVZdg2QW72hGC4IovzACykateSKaQmActyQtb8swq3eBat5zUrHdwo3htGxtHSByXYy77dih6HWwsaqxxLvS6seXrZQH6ZvOGrbtellH6poJTFtHDWeJHNTd1HbK6j10rSclDqoSztGbxfty7AcjMbbr0dhWi+pXeIy8QZ8LP6Q7+32ri6kD0s+ArSCCZhLVH0YSrGj8JfsH10TJ5otM16AcThuzu3lbzExSfgQy/pfEq7Gvcqtw6Hy/7XD0nrzo8wFDQQ1Ue9IldDP1b4pApylGtMtwGaE6Gh02w60g/utscOtcAf9/bgA5pF0ZPjyKNQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(199003)(8558605004)(2900100001)(4001430100002)(6116002)(3846002)(790700001)(5660300001)(4326007)(105586002)(3280700002)(102836003)(2501003)(7696004)(2906002)(106356001)(189998001)(8666007)(236005)(39060400001)(99286003)(54906002)(3660700001)(122556002)(74316002)(86362001)(9686003)(55016002)(19609705001)(25786008)(9326002)(68736007)(8936002)(6436002)(966004)(50986999)(107886002)(38730400001)(92566002)(97736004)(5001770100001)(81156014)(54356999)(81166006)(53936002)(33656002)(8676002)(606005)(66066001)(77096006)(6306002)(7736002)(6506006)(101416001)(54896002)(7906003)(491001)(19623455009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB0637; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: cf1eeb62-9cce-4918-ad69-08d44dd879c7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB0637; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(20170203043)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:DB4PR07MB0637; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB0637; x-forefront-prvs: 0209425D0A received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3488D0EBF3C25159710A190C2410DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2017 15:05:51.5767 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB0637 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SXUhTYRjHe8/XjsPR29J8Wgo1TaGalZQt1CyCmBdBSODqRledUtQtdnR+ 3XiRy/yoFbO1FWY55heVlVGREo3UHFK7SNOYuchSU0gNtahGHs8E737PJ///w8OSci+tYHP0 BZxRr8tTMlLKrn0KquOpNu2uWz6knnU0Uuop802k7v7cQKvb26yU2mXtJNU90yPMQUbzfdRL a67Zb5Camp8ThOa5Y0SicTp/E5qemXnmGHNSmnyGy8sxccadB7Kk2eU1AeL8i6Tib/YBVI66 E6tQCAt4D3SO3GeqkJSV4/sIGqr9hBj0IvB/naaFgMK1JFTc9FPCiBxbCfBMnBW5G0GrK1Rg BidDi3sRCQNh2EvA3cftS3tZlsQl4L1yQuhZj9Oh/9MQLXAYzoCXHQOMyPHwrH6QEJjCMeC5 7EcCy/BJGLz+QSIwwlEwuvhpWQOJI+Dj2G1CtIDB2fmOFDkcJr8EaLH/NMwN19KCBMBb4LW1 SJAGuJ+Cx08sEjF4yoBv6G9w0VFwdpvJFfZV/gxyLgTMHxmR86B5qguJw00ENHW0BAuR4PPY GPEqHDTdq0CiYwWMvL8U5EiY8HXRogMDuMYqkQXFOVYZcqwqOZYPsA767GOUmI+HoTorI/J2 cN2ZIkVWwY2Am1qdb0CSVhTOc/yp/HMJCfGcMec0zxv08Xqu4BFa+rNXHX92PUOT44fcCLNI GSqbSbFp5bTOxJfkuxGwpDJMFp24lJKd0ZWUckZDprEwj+PdaBNLKSNkiS2jGXJ8TlfA5XLc ec64UiXYEEU5aiNDtj4sy9rY/Arc/xSetLV9n3ffK8oeTpFlKsua0AVbtMOStuDOMM27fpn2 Bwx7Lf6k5N6zMX21iSqvZ19hnXr8dVRGHb9Gt2NRlVqv2KetbrwYuzDXM5pW9WCCKS1k7f7D R//0Rpni3h4phtSU91LzhqubS9PfjMf+0M+GKyk+W7d7G2nkdf8BGH470GMDAAA= Archived-At: Cc: Ingemar Johansson S Subject: [tsvwg] 3GPP Clarification on the use of Explicit Congestion Notification (ECN) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2017 15:06:00 -0000 --_000_DB4PR07MB3488D0EBF3C25159710A190C2410DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi The document below with accompanying changes requests, submitted to the RAN= 2 #97 meeting on feb 13-17, addresses part of the LS ( https://datatracker.= ietf.org/liaison/1499 ) http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_97/Docs/R2-1701090.zip Regards Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com No, you can=B4t tell people anything You've got to show 'em Bruce Springsteen =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DB4PR07MB3488D0EBF3C25159710A190C2410DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

The document below with accompanying changes request= s, submitted to the RAN2 #97 meeting on feb 13-17, addresses part of the LS= ( https://datatracker.i= etf.org/liaison/1499  )

 

http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_= 97/Docs/R2-1701090.zip

 

Regards

Ingemar

=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

Ingemar Johansson = M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

 =     No, you can=B4t tell people anything

 =         You’ve got to show ‘= em

 =              Br= uce Springsteen
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

--_000_DB4PR07MB3488D0EBF3C25159710A190C2410DB4PR07MB348eurprd_-- From nobody Mon Feb 6 02:11:15 2017 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 D6DAB129CD2; Mon, 6 Feb 2017 02:11:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.42.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148637587387.18849.12474166484371667160.idtracker@ietfa.amsl.com> Date: Mon, 06 Feb 2017 02:11:13 -0800 Archived-At: Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-le-phb-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 10:11:14 -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 of the IETF. Title : A Lower Effort Per-Hop Behavior (LE PHB) Author : Roland Bless Filename : draft-ietf-tsvwg-le-phb-01.txt Pages : 10 Date : 2017-02-06 Abstract: This document specifies properties and characteristics of a Lower Effort (LE) per-hop behavior (PHB). The primary objective of this LE PHB is to protect best-effort (BE) traffic (packets forwarded with the default PHB) from LE traffic in congestion situations, i.e., when resources become scarce, best-effort traffic has precedence over LE traffic and may preempt it. There are numerous uses for this PHB, e.g., for background traffic of low precedence, such as bulk data transfers with low priority in time, non time-critical backups, larger software updates, web search engines while gathering information from web servers and so on. This document recommends a standard DSCP value for the LE PHB. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-le-phb-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 6 03:52:35 2017 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 79A37129535 for ; Mon, 6 Feb 2017 03:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 e7aDAe9xkEgz for ; Mon, 6 Feb 2017 03:52:32 -0800 (PST) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 885D7129CE0 for ; Mon, 6 Feb 2017 03:52:32 -0800 (PST) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1cahqP-0001G2-1i; Mon, 06 Feb 2017 12:52:29 +0100 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id E4694B006A8; Mon, 6 Feb 2017 12:52:28 +0100 (CET) To: Ruediger.Geib@telekom.de References: <147705109053.23777.17372666504266526697.idtracker@ietfa.amsl.com> <08b67545-ddb1-65bf-cd86-f3ed487d25e9@gmail.com> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology Message-ID: <00e2166b-fc88-3cdc-aa18-bbc295e82bd1@kit.edu> Date: Mon, 6 Feb 2017 12:52:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1486381949. Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-tsvwg-le-phb-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 11:52:34 -0000 Hi Rüdiger, thanks for the comments. I just submitted a new version of the draft and tried to incorporate most of your comments. Comments inline. Am 02.12.2016 um 13:30 schrieb Ruediger.Geib@telekom.de: > I observe that the text as is contains two “SHOULD”. I think to > recall statements of either WG chairs or ADs that a low number of > “SHOULD” and the absence “MUST” standards language is insufficient to > justify standards track. Maybe David or Gorry could add a statement > whether my recollections reflects an individual point of view rather > than IETF policy. > > This is to say, I RECOMMEND to add some more standards language… :-) I tried to do that. However, since DiffServ is quite flexibly defined (w.r.t. internal marking and PHB mapping), I wasn't able to identify many places for MUSTs. > -----Comments-------------- > > 1. Introduction > > intended for traffic of sufficiently low urgency > > traffic has got a low priority in time, which does not necessarily > imply that it is generally of minor importance > > traffic for which delivery is considered optional. > > 1.1. Applicability > > for sending extremely non-critical traffic > > [RG] the above definitions of traffic suitable for LE transport may > be harmonized. I'm not sure whether 'does not imply minor importance' > and 'extremely non-critical' match each other really well. Maybe: > The PHB LE is applicable for traffic and applications of a user > accepting the presence of severe congestion conditions during any > time an LE marked IP flow is sent. > > [RG] See also RFC 4594 (whose definition may be an option here too): > Low-Priority Data for applications or services that can tolerate > short or long interruptions of packet flows. The Low-Priority Data > service class can be viewed as "don't care" to some degree I tried to harmonize this now, please check the new version. > ----------------------- > > OLD: This is a PHB that allows networks to protect themselves from > selected types of traffic rather than giving a selected traffic > aggregate preferential treatment. Moreover, it may also exploit all > unused resources from other PHBs NEW: The LE PHB allows networks to > protect themselves from selected types of traffic rather than giving > a selected traffic aggregate preferential treatment. Moreover, the > LE PHB may also exploit all unused resources from other PHBs > > [RG] I'd suggest to explicitly mention LE in that section. Done. > ------------------------------ > > 1.2. Deployment Considerations > > No harm to other traffic: since the LE PHB has got the lowest > priority it does not take resources from other PHBs. Deployment > across different provider domains causes no trust issues or attack > vectors to existing traffic. o No parameters or configuration: the > LE PHB requires no parameters and no configuration of traffic > profiles and so on. > > [RG] Please state whether this a deployment example. This should > clarify whether the described deployment is intended to be normative > (is a 'lowest priority [queue]' the only way to deploy the LE PHB? I > don't think so). Tried to make this more clear in the section. > ------------------- > > 2. PHB Description > > [RG] sw /This PHB../ The LE PHB/ twice in this sentence Done. > A packet forwarded with this PHB SHOULD have lower precedence than > packets forwarded with the default PHB. Ideally, LE packets should > be forwarded only if no best-effort packet is waiting for its > transmission. A straightforward implementation could be a simple > priority scheduler serving the default PHB queue with higher > priority than the lower-effort PHB queue. Alternative > implementations may use scheduling algorithms that assign a very > small weight to the LE class. This, however, may sometimes cause > better service for LE packets compared to BE packets in cases when > the BE share is fully utilized and the LE share not. > > [RG] I'm not sure, whether (precedence? applies (but I'm not a native > speaker). May be a generic description of the properties should be > added or replace this section: In the case of congestion, LE marked > traffic SHOULD (MUST?) be dropped prior to dropping any default PHB > traffic (my take). This leaves space for queuing LE traffic, if > desired. If the statement is should be dropped immediately in case of > congestion of the default PHB (i.e. no queuing), I'm fine with that > too. > > [RG] Related to the original text, please note that the BE traffic > will consume any spare LE bandwidth. During congestion, both will > compete for spare bandwidth of other classes by their weight and will > consume their minimum guaranteed bandwidth. Your original text > doesn't mention congestion as a pre-condition for LE traffic getting > better performance than BE traffic. Tried to incorporate these comments. > --------------------------------------------- 3. Traffic > Conditioning Actions As for most other PHBs an initial classification > and marking would usually be performed at the first DS boundary node. > In many cases, packets may also be pre-marked in DS aware end systems > by applications due to their specific knowledge about the particular > precedence of packets. There is no incentive for DS domains to > distrust this initial marking, because letting LE traffic enter a DS > domain causes no harm. > > [RG] I'd prefer the conditioning section to express a requirement of > explicit user consent to LE transport in any part of his > communication. Maybe: - SHOULD be pre-marked as LE by DS aware user > terminals originating traffic - MAY be classified an marked LE by > User managed devices within the user domain - Default PHB traffic > MUST NOT be classified and remarked to LE by a DS boundary node which > isn't managed by a user. I used the alternative phrases: If possible, packets SHOULD be pre-marked in DS-aware end systems by applications due to their specific knowledge about the particular precedence of packets. Non-LE traffic (e.g., BE traffic) SHOULD not be remarked to LE on a regular basis without consent or knowledge of the user. > ------------------- > > Usually, the amount of LE traffic is implicitly limited by queueing > mechanisms and related discard actions of the PHB. Therefore, there > is normally no need to meter and police LE traffic explicitly. > > [RG] sw /queueing/queuing/ Not sure, RFC2474 also uses queueing. RFC editor will let me know :-) > [RG] LE traffic MUST NOT be metered and SHOULD NOT be policed? I think this statement would be too strong. Assume that someone wants to forward LE, but hasn't got any LE queue left, so it must be mapped to the BE PHB. I order to make sure that it doesn't adversely affect the BE aggregate, one could use a token bucket policer at the ingress to limit the LE bandwidth. I don't want to preclude that, though the disadvantage compared to the queue solution it quite obvious. > -------------------------- > > 4. Recommended DS Codepoint > > [RG] sw /The recommended/The RECOMMENDED/ > > RFC 4594 [RFC4594] recommended to use CS1 as codepoint (as mentioned > in [RFC3662]. > > [RG] RFC4594 in a way also adds information related to LE marking if > a domain doesn’t support LE. I’d suggest to add a Diffserv-intercon > discussion here. Suggested text: > > [RG] It is further suggested that a sending domain internally marking > LE traffic by CS1 remarks traffic by the LE DSCP 000 010 recommended > above, if it is forwarded to a domain applying Diffserv-intercon and > its treatment of CS1 marked traffic is unknown. This raises the > probability that the DSCP is preserved end-to-end, whereas as CS1 > marked packet may be remarked by the default DSCP by the receiving > domain. > > [RG] Extract of RFC 4594: In network segments that use IP precedence > marking, only one of the two service classes can be supported, > High-Throughput Data or Low-Priority Data. We RECOMMEND that the > DSCP value(s) of the unsupported service class be changed to 000xx1 > on ingress and changed back to original value(s) on egress of the > network segment that uses precedence marking. For example, if > Low-Priority Data is mapped to Standard service class, then 000001 > DSCP marking MAY be used to distinguish it from Standard marked > packets on egress. Thanks for pointing that out. I now added the following text: o [RFC4594] recommended to remark Low-Priority Data to DSCP '000001' inside a DS domain that uses IP precedence marking. By using the herein defined LE DSCP such remarking is not necessary, so even if Low-Priority Data is unsupported (i.e., mapped to the default PHB) the LE DSCP should be kept across the domain as RECOMMENDED in Section 5. Regards, Roland From nobody Mon Feb 6 20:13:38 2017 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 1100612996B for ; Mon, 6 Feb 2017 20:13:37 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1trmTtsADpS for ; Mon, 6 Feb 2017 20:13:35 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 AB0D0129969 for ; Mon, 6 Feb 2017 20:13:35 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id 11so76767498qkl.3 for ; Mon, 06 Feb 2017 20:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=/7FiZvBXpJx6uwq8oJ/QffUvbLyegSGoFjSapByxCVA=; b=FuvL/D68Zang6uKMpbSm/dDHUyLe1qjhFCL3xECt+jAbzHeWtPh6lbvOovfCiu/IX0 /8991Ub3R6vwk6Wci13B5PW8TUHgBlN76Ty3BegGydG5j5DHRyhXiXqi/RV1u0RS/hQ3 hNH8nSaqOQito2xoZnUlhPn9JkYOCAOkJ0eiKuI8ThJRklHjMCu6VkMpGYnjwBVXCExx R0pSdiJ1gkAHz/S/fRlZBpmSPAR6EJh5QVYTn33OK0wpE3dSrIwAkwJNhga/xwHfHzom GpM2F69KL/3EmZtrQ1vMTF0JmVmrZG+WuHcvsNExEavAlymIeQ+yiiuGSVWgtCf443Vc vFRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=/7FiZvBXpJx6uwq8oJ/QffUvbLyegSGoFjSapByxCVA=; b=pAVNBR82cqxWCtD3v9HmKarXxQ9x3oQ6Mpe/P3V+JQCbNqZIKFIf5/tIkVU+bnWTPz eFGhT4BAgKh50rWCuJrcxvVU5y/3RmIGapyIjdPbTciN3LSj+Yw1ZZ/zhsTJCYvdZ7X7 06pYyKE2f9HAlUj3Xx5isMAGfMpDSY6r+di+gROKCKIbxBexq+Ba3koMjj3SSngZl8Ja 0KexzOWIyemrKakw+oR1esZGsJYvvbWJ/49Sjg8UpsmKKYBl9MnS9OGGFbLCbEpKOfPA 32C452zX6DtMAmUavTQe7PFEcvdyRf/OpVEAt4FoEApye4/mp8UUWm7cMmhY9FjVkPtN 8Szw== X-Gm-Message-State: AMke39kZZBnAWSbIfTVVH+CKffSGZaKX+v1wkmcZA8HbBRqHLlPQNzdWb9Xq5Y3PqFCNsQ== X-Received: by 10.55.151.7 with SMTP id z7mr13455927qkd.316.1486440814671; Mon, 06 Feb 2017 20:13:34 -0800 (PST) Received: from [172.20.0.116] ([63.139.220.94]) by smtp.gmail.com with ESMTPSA id r10sm2382345qte.1.2017.02.06.20.13.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 20:13:34 -0800 (PST) To: "tsvwg@ietf.org" From: Wesley Eddy Message-ID: <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com> Date: Mon, 6 Feb 2017 23:13:32 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] L4S work in TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 04:13:37 -0000 Hello, as a co-chair, I'm checking to make sure we have the critical mass to go forward with L4S in TSVWG. Over time, there has been good discussion on this spread across several lists and groups (ICCRG, AQM, TCP-Prague, etc.). The ADs have asked that going forward TSVWG be the home for this work, so I think we can limit discussion to TSVWG now (assuming relevant parties are on-list). The three documents at present around this are: 1. https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00 2. https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled-00 3. https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02 There was interest in working these in TSVWG at the last IETF meeting (noted in the minutes), and we want that discussion to continue on the mailing list. Please respond if you're interested in participating in this work by helping to review, analyze, implement, test, simulate, deploy, etc. and agree that TSVWG should add milestones on the L4S problem, based on the current drafts. Or if you have other thoughts, those would be interesting too. Thanks! From nobody Mon Feb 6 20:48:48 2017 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 D12061299CD for ; Mon, 6 Feb 2017 20:48:47 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVrj3LJ4Gu8c for ; Mon, 6 Feb 2017 20:48:46 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1B91299CA for ; Mon, 6 Feb 2017 20:48:46 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id k15so124962807qtg.3 for ; Mon, 06 Feb 2017 20:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=hVS+hOo51Z7YpDpbSsoZay3HY7tDlBmBCvkzR7zBqsg=; b=HtZzFAxUUyOWbegkTSaxGWWjAo7bTPwnPpNMlA4LdwZfDjC70BYgJKC3EhOW5bHSvW 4pOTuBmu1Aa9CPsUGONFXnQsdYxzWWCx5IvwDFGpmX+X74qwfuU/UuDlurQGTRqZCd6V 5VPs3nBFltfB0sSddljFrdnEAII3n8/GRBrUBVD2M+ISdoRC5//QfXCrrhni0oj5xyHJ 9QTrEPmmUw+e4RPHSO5tRmSgYdJhkLmmSp0St6A5PyAlAyWV+nZ0sSoaLGjfJCofI1Pa sNLEocTPyZladpZoBbnNYwXueRonAgRhFiWwUVab2oTQ23aNM9FLwINiWE7z4pDr68RH ZQng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=hVS+hOo51Z7YpDpbSsoZay3HY7tDlBmBCvkzR7zBqsg=; b=CcCbBPeno0mlecpxnBmIeC1DbWbfI24NS1MolNf7OGjRO683LhaRPECnIj+Kil+vum OyXh3er933Gt2NRtfY8VYzp9n/N/H0P9vth+UGotVqvYUqeB7M0Nkjmi5gzMviLuaTcC wMztyqX3wAvSu/g3bDQrEjVYpieOwW/Gwgi4jat7nVA5hmnbVs1SZXCFgOn/3HY8+fPw /5aMIJcHzQWNXZXWthAYjupBERBrXHPqaTebyeJZIEXr94lgGx5MSDpZn355JyLZkx68 PRXAPewYlX4Gs8wMJYzEMinz06a3hK6tmeERLKp6Iemv/lhNWYNTS/1HCyY7g6/bTe/K XWPw== X-Gm-Message-State: AMke39lSpRO9t8XwKk/8J/aiSVD+0wx+HGvvHIBxnfC1mku/hDagmxRjfkXo/7ocJjMfgw== X-Received: by 10.200.36.41 with SMTP id c38mr13455331qtc.57.1486442925320; Mon, 06 Feb 2017 20:48:45 -0800 (PST) Received: from [172.20.0.116] ([63.139.220.94]) by smtp.gmail.com with ESMTPSA id n2sm2435671qtf.18.2017.02.06.20.48.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Feb 2017 20:48:44 -0800 (PST) To: "tsvwg@ietf.org" From: Wesley Eddy Message-ID: Date: Mon, 6 Feb 2017 23:48:43 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] comments on L4S architecture draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 04:48:48 -0000 I have some comments to share on the architecture draft: https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00 These are mostly positive comments, and many can be considered longer-term, in my opinion, not urgent nor blocking adopting in TSVWG. 1. It seems to me that L4S can address some pain points that operators have. I'm sure the authors have got some input on this from operators, but it might be good to include more of a deployment walkthrough in the draft. It mentions incremental deployment as being possible, but I think there could be a more clear discussion of what incremental utility there is, how to start, etc. 2. I think the real "selling point" is that operators won't need to provision separate transport underlays for certain high-performance applications (e.g. that might use DCTCP) versus other traffic. L4S can enable better performance with less pre-configuration, baked-in settings, or twiddling with knobs. The draft doesn't really seem to directly attack the current practices of partitioning resources and how labor-intensive and fragile this can be. L4S could be a big improvement for some people. 3. In addition to being an architecture description, the draft also serves as a bit of a "work plan" for what needs to be done (e.g. in Section 4). The wording is a bit strong sometimes, saying things "need" to be done, but really the benefits of L4S can accrue incrementally as some of that work happens, and some of the work items mentioned may not really be needed at all. For instance, DCCP scalable CC doesn't need to be in place for L4S to have benefit, and L4S wouldn't fail just because none of the existing mostly-unused DCCP codebases implement the new CCID. What truly "needs" to happen to start showing benefits could be better distinguished from what ultimately could happen. 4. The caption on Figure 1 has incorrect numbering with regard to the figure (number 1 and 2 are swapped in the caption, I believe). Additionally, in the text above the figure, bullet numbering order of 2, 1, 3 is stressful to read (though I think was probably done on purpose for left-right relation to the diagram?). 5. In the discussion of ECN at the beginning of section 5.1, it could be more clear that this is in regard to traffic in the L4S class, and that other traffic using the "classic" queue doesn't need to use ECN. 6. Some of the comparison/contrast statements with fq_codel don't seem quite right, since FQ is achieving a different goal than simply enabling scalable and classic traffic to coexist. For instance, FQ is also limiting impact of very bad-behaving flows on other flows (e.g. bad flows may follow neither the scalable nor classic paradigms of CC!). 7. Another possible use case for section 6 might be networks where service function chaining is prevalent and delay across the network needs to be minimized because traffic is criss-crossing through possibly odd paths that are much different than just the shortest set of physical hops between source and destination. 8. Virtual switch implementations may be important in addition to physical. 9. Would onion routing systems also be a potential beneficiary of L4S, if they used scalable transports? They normally have a lot of delay and delay variation. 10. The benefits and descriptions in the document make sense to me, but I also know of the history and related work that the document builds upon. I wonder if it's as clear to other people coming fresh? For many operations type of people, this may be the case, so feedback there would be useful, I think. 11. Some of the text represents a state of affairs that will change (e.g. page 7 discussing progress), and it should be considered whether this stuff would be of value to go into an RFC or not. From nobody Tue Feb 7 00:41:19 2017 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 4C4AD12961D for ; Tue, 7 Feb 2017 00:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VXkK2HtauZd for ; Tue, 7 Feb 2017 00:41:16 -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 78A5A12946F for ; Tue, 7 Feb 2017 00:41:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.33,345,1477954800"; d="scan'208,217";a="212304872" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.110]) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2017 09:41:12 +0100 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_7E01E5CD-A9BF-4BAE-8B10-158CFCFF6907" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 7 Feb 2017 09:41:11 +0100 References: <148645572084.16308.14733891775494215646.idtracker@ietfa.amsl.com> To: tsvwg WG , nwcrg@irtf.org Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-roca-tsvwg-rlc-fec-scheme-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 08:41:18 -0000 --Apple-Mail=_7E01E5CD-A9BF-4BAE-8B10-158CFCFF6907 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello everybody, As promised during last IETF, here is an I-D for a FEC scheme to be used = along with FECFRAME extended to convolutional codes (mis-called FECFRAME version 2 = so far). I'm cross-posting this to the NWCRG mailing list as there are many very = interesting research aspects on block FEC codes versus convolutional FEC codes for all = situations where latency does matter. In short:=20 With a multicast/broadcast (extended) FECFRAME session for real-time = content, these codes significantly improve robustness in harsh environments, with less = repair traffic and lower FEC-related latency (close to zero for good receivers).=20 Regards, Vincent > De: internet-drafts@ietf.org > Objet: New Version Notification for = draft-roca-tsvwg-rlc-fec-scheme-00.txt > Date: 7 f=C3=A9vrier 2017 =C3=A0 09:22:00 UTC+1 > =C3=80: "Vincent Roca" >=20 >=20 > A new version of I-D, draft-roca-tsvwg-rlc-fec-scheme-00.txt > has been successfully submitted by Vincent Roca and posted to the > IETF repository. >=20 > Name: draft-roca-tsvwg-rlc-fec-scheme > Revision: 00 > Title: Random Linear Codes (RLC) Forward Error = Correction (FEC) Scheme for FECFRAME > Document date: 2017-02-07 > Group: Individual Submission > Pages: 19 > URL: = https://www.ietf.org/internet-drafts/draft-roca-tsvwg-rlc-fec-scheme-00.tx= t > Status: = https://datatracker.ietf.org/doc/draft-roca-tsvwg-rlc-fec-scheme/ > Htmlized: = https://tools.ietf.org/html/draft-roca-tsvwg-rlc-fec-scheme-00 >=20 >=20 > Abstract: > This document describes a fully-specified FEC scheme for the > convolutional Random Linear Codes (RLC) over GF(2^^m), where m = equals > 1 (binary case), 4 or 8, that can be used to protect arbitrary media > streams along the lines defined by FECFRAME extended to = convolutional > codes. These convolutional FEC codes rely on an encoding window = that > slides over the source symbols, generating new repair symbols > whenever needed. Compared to block FEC codes, these convolutional > FEC codes offer key advantages in terms of reduced FEC-related > latency while often providing improved erasure recovery = capabilities. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_7E01E5CD-A9BF-4BAE-8B10-158CFCFF6907 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello everybody,

As promised during last IETF, here is an I-D for a FEC scheme = to be used along with
FECFRAME extended to = convolutional codes (mis-called FECFRAME version 2 so far).

I'm cross-posting this = to the NWCRG mailing list as there are many very interesting = research
aspects on block FEC codes versus = convolutional FEC codes for all situations where latency
does matter.

In short: 
With a = multicast/broadcast (extended) FECFRAME session for real-time content, = these
codes significantly improve robustness in = harsh environments, with less repair traffic and lower
FEC-related latency (close to zero for good = receivers). 

Regards,

  Vincent


De: = internet-drafts@ietf.org
Objet: = New Version = Notification for draft-roca-tsvwg-rlc-fec-scheme-00.txt
Date: = 7 f=C3=A9vrier 2017 =C3=A0 = 09:22:00 UTC+1
=C3=80: = "Vincent Roca" <vincent.roca@inria.fr>


A new version = of I-D, draft-roca-tsvwg-rlc-fec-scheme-00.txt
has been = successfully submitted by Vincent Roca and posted to the
IETF repository.

Name: = draft-roca-tsvwg-rlc-fec-scheme
Revision: 00
Title:= = Random Linear Codes (RLC) Forward Error Correction (FEC) Scheme = for FECFRAME
Document date: 2017-02-07
Group:= = Individual Submission
Pages: 19
URL: =            https://www.ietf.org/internet-drafts/draft-roca-tsvwg-rlc-fec-s= cheme-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-roca-tsvwg-rlc-fec-schem= e/
Htmlized:       https://tools.ietf.org/html/draft-roca-tsvwg-rlc-fec-scheme-00<= /a>


Abstract:
=   This document describes a fully-specified FEC scheme for = the
  convolutional Random Linear Codes (RLC) = over GF(2^^m), where m equals
  1 (binary = case), 4 or 8, that can be used to protect arbitrary media
=   streams along the lines defined by FECFRAME extended to = convolutional
  codes.  These = convolutional FEC codes rely on an encoding window that
=   slides over the source symbols, generating new repair = symbols
  whenever needed.  Compared to = block FEC codes, these convolutional
  FEC = codes offer key advantages in terms of reduced FEC-related
=   latency while often providing improved erasure recovery = capabilities.




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


= --Apple-Mail=_7E01E5CD-A9BF-4BAE-8B10-158CFCFF6907-- From nobody Tue Feb 7 06:44:15 2017 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 EFD53129C69 for ; Tue, 7 Feb 2017 06:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Uo7GOPpHThB for ; Tue, 7 Feb 2017 06:44:12 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2604D129C45 for ; Tue, 7 Feb 2017 06:44:12 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 18BA39091C7; Tue, 7 Feb 2017 09:44:11 -0500 (EST) Date: Tue, 7 Feb 2017 09:44:11 -0500 From: John Leslie To: Wesley Eddy Message-ID: <20170207144411.GR10525@verdi> References: <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Cc: tsvwg@ietf.org Subject: Re: [tsvwg] L4S work in TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 14:44:14 -0000 Wesley Eddy wrote: > > Hello, as a co-chair, I'm checking to make sure we have the critical > mass to go forward with L4S in TSVWG. I'm happy to add my 66 kilograms. ;^) > Over time, there has been good discussion on this spread across several > lists and groups (ICCRG, AQM, TCP-Prague, etc.). The ADs have asked > that going forward TSVWG be the home for this work, so I think we can > limit discussion to TSVWG now (assuming relevant parties are on-list). > > The three documents at present around this are: > > 1. https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00 > 2. https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled-00 > 3. https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02 Bob has done pretty well on these: I don't want to criticize his work; but I'd be happy to join in the discussion. > There was interest in working these in TSVWG at the last IETF meeting > (noted in the minutes), and we want that discussion to continue on the > mailing list. :^) > Please respond if you're interested in participating in this work by > helping to review, analyze, implement, test, simulate, deploy, etc. and > agree that TSVWG should add milestones on the L4S problem, based on the > current drafts. Or if you have other thoughts, those would be > interesting too. I'll do what you tell me to; but my day-job will keep me pretty busy until February 20. -- John Leslie From nobody Wed Feb 15 02:04:00 2017 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 073F51299D2 for ; Wed, 15 Feb 2017 02:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.787 X-Spam-Level: X-Spam-Status: No, score=-8.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-2WdUjUeKa9 for ; Wed, 15 Feb 2017 02:03:46 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 F2C2E129ACE for ; Wed, 15 Feb 2017 02:03:45 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 21C14CC6453C4; Wed, 15 Feb 2017 10:03:42 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v1FA3hF2002424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Feb 2017 11:03:43 +0100 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id v1FA3dK3006418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 15 Feb 2017 10:03:41 GMT Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.65]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Wed, 15 Feb 2017 11:03:38 +0100 From: "De Schepper, Koen (Nokia - BE)" To: Wesley Eddy , "tsvwg@ietf.org" Thread-Topic: [tsvwg] L4S work in TSVWG Thread-Index: AQHSgPiTLsOzqZT4CkS/64snsNwqu6Fp3lRg Date: Wed, 15 Feb 2017 10:03:37 +0000 Message-ID: References: <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com> In-Reply-To: <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] L4S work in TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 10:03:48 -0000 SGksDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdHN2d2cgW21haWx0 bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2VzbGV5IEVkZHkNCj4gU2Vu dDogZGluc2RhZyA3IGZlYnJ1YXJpIDIwMTcgNToxNA0KPiBUbzogdHN2d2dAaWV0Zi5vcmcNCj4g U3ViamVjdDogW3RzdndnXSBMNFMgd29yayBpbiBUU1ZXRw0KPiANCj4gSGVsbG8sIGFzIGEgY28t Y2hhaXIsIEknbSBjaGVja2luZyB0byBtYWtlIHN1cmUgd2UgaGF2ZSB0aGUgY3JpdGljYWwNCj4g bWFzcyB0byBnbyBmb3J3YXJkIHdpdGggTDRTIGluIFRTVldHLg0KDQpJIGFtIGNvbnRpbnVpbmcg d29ya2luZyBvbiB0aGUgTDRTIHRvcGljcyAoRHVhbFEsIFBJMiBhbmQgVENQLVByYWd1ZSkuDQoN Cj4gDQo+IE92ZXIgdGltZSwgdGhlcmUgaGFzIGJlZW4gZ29vZCBkaXNjdXNzaW9uIG9uIHRoaXMg c3ByZWFkIGFjcm9zcyBzZXZlcmFsDQo+IGxpc3RzIGFuZCBncm91cHMgKElDQ1JHLCBBUU0sIFRD UC1QcmFndWUsIGV0Yy4pLiAgVGhlIEFEcyBoYXZlIGFza2VkDQo+IHRoYXQgZ29pbmcgZm9yd2Fy ZCBUU1ZXRyBiZSB0aGUgaG9tZSBmb3IgdGhpcyB3b3JrLCBzbyBJIHRoaW5rIHdlIGNhbg0KPiBs aW1pdCBkaXNjdXNzaW9uIHRvIFRTVldHIG5vdyAoYXNzdW1pbmcgcmVsZXZhbnQgcGFydGllcyBh cmUgb24tbGlzdCkuDQo+IA0KPiBUaGUgdGhyZWUgZG9jdW1lbnRzIGF0IHByZXNlbnQgYXJvdW5k IHRoaXMgYXJlOg0KPiANCj4gMS4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJy aXNjb2UtdHN2d2ctbDRzLWFyY2gtMDANCj4gDQo+IDIuIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1icmlzY29lLXRzdndnLWFxbS1kdWFscS1jb3VwbGVkLTAwDQo+IA0KPiAzLiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYnJpc2NvZS10c3Z3Zy1lY24tbDRzLWlk LTAyDQo+IA0KPiBUaGVyZSB3YXMgaW50ZXJlc3QgaW4gd29ya2luZyB0aGVzZSBpbiBUU1ZXRyBh dCB0aGUgbGFzdCBJRVRGIG1lZXRpbmcNCj4gKG5vdGVkIGluIHRoZSBtaW51dGVzKSwgYW5kIHdl IHdhbnQgdGhhdCBkaXNjdXNzaW9uIHRvIGNvbnRpbnVlIG9uIHRoZQ0KPiBtYWlsaW5nIGxpc3Qu DQo+IA0KPiBQbGVhc2UgcmVzcG9uZCBpZiB5b3UncmUgaW50ZXJlc3RlZCBpbiBwYXJ0aWNpcGF0 aW5nIGluIHRoaXMgd29yayBieQ0KPiBoZWxwaW5nIHRvIHJldmlldywgYW5hbHl6ZSwgaW1wbGVt ZW50LCB0ZXN0LCBzaW11bGF0ZSwgZGVwbG95LCBldGMuIGFuZA0KPiBhZ3JlZSB0aGF0IFRTVldH IHNob3VsZCBhZGQgbWlsZXN0b25lcyBvbiB0aGUgTDRTIHByb2JsZW0sIGJhc2VkIG9uIHRoZQ0K PiBjdXJyZW50IGRyYWZ0cy4gIE9yIGlmIHlvdSBoYXZlIG90aGVyIHRob3VnaHRzLCB0aG9zZSB3 b3VsZCBiZQ0KPiBpbnRlcmVzdGluZyB0b28uDQoNCkknbSBpbnZvbHZlZCBpbiBtb3N0IG9mIHRo ZSBhYm92ZS4NCg0KS29lbi4NCg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gDQo+IA0KDQo= From nobody Thu Feb 16 00:09:38 2017 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 15C671299C4 for ; Thu, 16 Feb 2017 00:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.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 FF1S57lB4bBU for ; Thu, 16 Feb 2017 00:09:34 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 A6BDB1299A0 for ; Thu, 16 Feb 2017 00:09:33 -0800 (PST) X-AuditID: c1b4fb25-93e1698000001738-e4-58a55e3b1460 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id E2.DE.05944.B3E55A85; Thu, 16 Feb 2017 09:09:32 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 16 Feb 2017 09:09:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U8Na8EmZCMmNlZScyAvrqQwpLaD6dS5z+NXSycX4y3g=; b=JHfZ6SOMhta+yVWd4hRe5uPm7IFKNlE94yL81TeVkHhv+jV6ej7XcRWOkwAUaMawE+oH5+waDBYARITtJ7Pyd7NiJ0aeVL35EvNld40vv00KFq1yv0yWs6pSr/d9dhnY/gGPejevlRHjEdaYsKXE+3xq44kJ0HhajqGe10GezyY= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Thu, 16 Feb 2017 08:09:30 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0919.011; Thu, 16 Feb 2017 08:09:30 +0000 From: Ingemar Johansson S To: "tsvwg@ietf.org" , "wes@mti-systems.com" Thread-Topic: L4S work in TSVWG Thread-Index: AdKIK5HbOVlfJ+QeR1+RkcSplvXlRg== Date: Thu, 16 Feb 2017 08:09:30 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-office365-filtering-correlation-id: 85523951-9645-4fec-9ee6-08d456432241 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB346; x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 7:fWJk0zvt2rbORH5d+xa+4GC3/LMyysaXjSU2fpVsYfu5tewJcxahWvEp0Ii5Y8EVkkoPdSY5CQfAq1waT4XMg/hy87txH9zllJDVzd5nwIcifZFQC5UftRDhrtHPcRMnuWzFeEUoxcr9VbPl9SIgwLPSYD4shcJFWc1ckTp7EBd2RLnJLIGuAH+q9eDtWkvWLleafiv9YoZLCcIoGds696v12BSDe3P+AlSXFKbIFsb4LyzS9yV+PdZuVo+mFrw9r4iEO9ASpkZ1Vhq7hBYDmbibGLODwtuqzcoua23xKxPwuC6/Te95wBFQNmGEywm6mvhaF1kWrKG2/RsWBWo1yg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(8676002)(81156014)(53936002)(2501003)(3280700002)(77096006)(6506006)(8936002)(189998001)(6436002)(38730400002)(3846002)(6116002)(9686003)(99286003)(2900100001)(97736004)(102836003)(66066001)(3660700001)(25786008)(81166006)(6306002)(6246003)(92566002)(389900002)(55016002)(2906002)(54356999)(101416001)(122556002)(5660300001)(50986999)(229853002)(7696004)(86362001)(305945005)(7736002)(74316002)(106356001)(33656002)(68736007)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 08:09:30.2104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42KZGbFdRdcmbmmEwddp7BbH3txls7j+nd2B yWPJkp9MHidP9bIFMEVx2aSk5mSWpRbp2yVwZZzt28lY8IKn4tm1m2wNjHu4uhg5OSQETCTm HLjC1sXIxSEksI5R4lnzD1YI5wSjxKN5LWAOi0Avs0Tr/2/MEJlpTBIXd31ignCOMUr8/feZ FWQYm4CNxMpD3xlBbBGBEIn+Cy/BbGEBeYkNj+9AxRUkDs2dxwph60ks+fseLM4ioCqx4coq ZhCbVyBKovfyS7AaRgFZifvf77GA2MwC4hK3nsxngjhcQGLJnvPMELaoxMvH/6DqkyU+3ewF sjmA4goSD7f6QZT4Suxcegmq3Efi9/U17CD3Swh0M0scebKTCaI+U2LKP02IGi2JjiOzmCBq ZjBJrFzWyQiRkJG4ses0C0RiDqvEzNtNYAcJCaRKLF/bCvWwlMTdK51QtozEizt7WSEe0JFY sPsTG4StLbFs4WvmCYzqs5D8NgtJ2SwkZbPA4SIocXLmE5YFjCyrGEWLU4uTctONjPVSizKT i4vz8/TyUks2MQLTxsEtv1V3MF5+43iIUYCDUYmH90POkggh1sSy4srcQ4wSHMxKIryPgpdG CPGmJFZWpRblxxeV5qQWH2KU5mBREuc1W3k/XEggPbEkNTs1tSC1CCbLxMEp1cCo6Cm02lat 93pX8tyr2q1v7RQ4D1SrJ99ZZaJ3cOKzj/7vVvtJq4kEX6v8zbTAb/VZdY/HKTnx9v43p319 ZX04dpOHIrvLfuna9/Jh2reVdwTVsPK13xNgdfZ8KPtG8XxIu8DnojtlL67HfYph2XSOv/vM zgL5htaCHTb/J1gz/ds8LXGylq4SS3FGoqEWc1FxIgAKEAzPFwMAAA== Archived-At: Subject: Re: [tsvwg] L4S work in TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 08:09:37 -0000 Hi Yes, I am very interested in this work and will contribute to the work. /Ingemar >=20 > Message: 1 > Date: Mon, 6 Feb 2017 23:13:32 -0500 > From: Wesley Eddy > To: "tsvwg@ietf.org" > Subject: [tsvwg] L4S work in TSVWG > Message-ID: <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com> > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed >=20 > Hello, as a co-chair, I'm checking to make sure we have the critical mass= to go > forward with L4S in TSVWG. >=20 > Over time, there has been good discussion on this spread across several l= ists > and groups (ICCRG, AQM, TCP-Prague, etc.). The ADs have asked that going > forward TSVWG be the home for this work, so I think we can limit discussi= on > to TSVWG now (assuming relevant parties are on-list). >=20 > The three documents at present around this are: >=20 > 1. https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00 >=20 > 2. https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled-00 >=20 > 3. https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02 >=20 > There was interest in working these in TSVWG at the last IETF meeting > (noted in the minutes), and we want that discussion to continue on the > mailing list. >=20 > Please respond if you're interested in participating in this work by help= ing to > review, analyze, implement, test, simulate, deploy, etc. and agree that > TSVWG should add milestones on the L4S problem, based on the current > drafts. Or if you have other thoughts, those would be interesting too. >=20 > Thanks! >=20 >=20 >=20 From nobody Thu Feb 16 11:33:09 2017 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 21AD41295A5 for ; Thu, 16 Feb 2017 11:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 8uFKFMsceZpo for ; Thu, 16 Feb 2017 11:33:07 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142AB12955E for ; Thu, 16 Feb 2017 11:33:07 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id k15so23449315qtg.3 for ; Thu, 16 Feb 2017 11:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RLs6+sUCITTrHr7bIuZLDH3/shYmji+cWY7cvA5Txec=; b=WNbEa4mYPn/+614Be1/DYqI09fDQEYWq9/e+t83Pp+L0nDmAnxNKauPojhe22wevmC wm3F4V0zD4FYvfRvuUcM+XlFgFrbfoqEzHnP91LUnCC8L9Or7e8EAVO6ADRB1sR0A2Ho XGH8VJ4PCpsvuUh6y5HZmec4yFw6ja2zsLBMk= 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; bh=RLs6+sUCITTrHr7bIuZLDH3/shYmji+cWY7cvA5Txec=; b=cZ1n/gD9wskkIGxua7p5BKwXa6a9JU07S2U+mkInQslx5WMDIg/ZmXprV145kI3an7 AKzTXS8dTDIgs5sQZ+EwLPy97d/fdiv9zLXuLHMuA8Wq+DfzdP2jAd2Zcr3kF4g62TNF rDIGEfMm9jTSu9FQ7gCiFFu0klU5xmpKSrZiuroJLL5iK1CiTfcEyyi+rKLrpfn1y4R0 aDcxE0bWqK3YuwbC7o3/Eu3pjwAc3Ht/I5gERD6gbKeDqA4o0L7HvCwpPAAq6YgXBb03 e1eUgm/H0SY71BysjK0ft6Af9BmhC9IsNj73asRC3ls+fzB/aNNdkxaqTT42cNiIWeKp VNDw== X-Gm-Message-State: AMke39l457LIkXJkhx7+Cj7iVdp5Ej1YwLEb5w3tHMHs9p4bWiyJB0wxH7ZqqzAvg1u3tmFZ7mGMFsti7qK7Ws/b X-Received: by 10.200.45.211 with SMTP id q19mr3720841qta.115.1487273585935; Thu, 16 Feb 2017 11:33:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.41.75 with HTTP; Thu, 16 Feb 2017 11:33:05 -0800 (PST) In-Reply-To: References: From: Pat Thaler Date: Thu, 16 Feb 2017 11:33:05 -0800 Message-ID: To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=001a11401d2ac6d7540548aaddd0 Archived-At: Cc: "tsvwg@ietf.org" Subject: Re: [tsvwg] L4S work in TSVWG X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:33:09 -0000 --001a11401d2ac6d7540548aaddd0 Content-Type: text/plain; charset=UTF-8 I'm supportive of this going forward in TSVWG and interested in contributing. On Thu, Feb 16, 2017 at 12:09 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > Yes, I am very interested in this work and will contribute to the work. > > /Ingemar > > > > > Message: 1 > > Date: Mon, 6 Feb 2017 23:13:32 -0500 > > From: Wesley Eddy > > To: "tsvwg@ietf.org" > > Subject: [tsvwg] L4S work in TSVWG > > Message-ID: <274f4ce5-d7da-75f3-5a84-751f87864962@mti-systems.com> > > Content-Type: text/plain; charset=utf-8; format=flowed > > > > Hello, as a co-chair, I'm checking to make sure we have the critical > mass to go > > forward with L4S in TSVWG. > > > > Over time, there has been good discussion on this spread across several > lists > > and groups (ICCRG, AQM, TCP-Prague, etc.). The ADs have asked that going > > forward TSVWG be the home for this work, so I think we can limit > discussion > > to TSVWG now (assuming relevant parties are on-list). > > > > The three documents at present around this are: > > > > 1. https://tools.ietf.org/html/draft-briscoe-tsvwg-l4s-arch-00 > > > > 2. https://tools.ietf.org/html/draft-briscoe-tsvwg-aqm-dualq-coupled-00 > > > > 3. https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02 > > > > There was interest in working these in TSVWG at the last IETF meeting > > (noted in the minutes), and we want that discussion to continue on the > > mailing list. > > > > Please respond if you're interested in participating in this work by > helping to > > review, analyze, implement, test, simulate, deploy, etc. and agree that > > TSVWG should add milestones on the L4S problem, based on the current > > drafts. Or if you have other thoughts, those would be interesting too. > > > > Thanks! > > > > > > > > --001a11401d2ac6d7540548aaddd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm supportive of this going forward in TSVWG and inte= rested in contributing.

On Thu, Feb 16, 2017 at 12:09 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi

Yes, I am very interested in this work and will contribute to the work.

/Ingemar

>
> Message: 1
> Date: Mon, 6 Feb 2017 23:13:32 -0500
> From: Wesley Eddy <wes@mti-s= ystems.com>
> To: "tsvwg@ietf.org" &= lt;tsvwg@ietf.org>
> Subject: [tsvwg] L4S work in TSVWG
> Message-ID: <274f4ce5-d7da-75f3-5a84-751f87864962@mti-syst= ems.com>
> Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed
>
> Hello, as a co-chair, I'm checking to make sure we have the critic= al mass to go
> forward with L4S in TSVWG.
>
> Over time, there has been good discussion on t= his spread across several lists
> and groups (ICCRG, AQM, TCP-Prague, etc.).=C2=A0 The ADs have asked th= at going
> forward TSVWG be the home for this work, so I think we can limit discu= ssion
> to TSVWG now (assuming relevant parties are on-list).
>
> The three documents at present around this are:
>
> 1. https://tools.ietf.org/html/= draft-briscoe-tsvwg-l4s-arch-00
>
> 2. https://tools.ietf.org/h= tml/draft-briscoe-tsvwg-aqm-dualq-coupled-00
>
> 3. https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02
>
> There was interest in working these in TSVWG at the last IETF meeting<= br> > (noted in the minutes), and we want that discussion to continue on the=
> mailing list.
>
> Please respond if you're interested in participating in this work = by helping to
> review, analyze, implement, test, simulate, deploy, etc. and agree tha= t
> TSVWG should add milestones on the L4S problem, based on the current > drafts.=C2=A0 Or if you have other thoughts, those would be interestin= g too.
>
> Thanks!
>
>
>


--001a11401d2ac6d7540548aaddd0-- From nobody Thu Feb 16 12:37:48 2017 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 E48ED12966D for ; Thu, 16 Feb 2017 12:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, 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 3kR3b8eJ-yjz for ; Thu, 16 Feb 2017 12:37:45 -0800 (PST) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (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 A19CB12967E for ; Thu, 16 Feb 2017 12:37:44 -0800 (PST) Received: by mail-it0-x242.google.com with SMTP id g67so837323itb.3 for ; Thu, 16 Feb 2017 12:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ihUtR7DNTiwd3p0yfxNF+am2ZjstGFp+xB7TII4LFlQ=; b=MMNyfsfh+8IbXGgyjJK3mmN1nuGc7mMtP71njO/R7Oz++7RaxEGfJC01Fn3NxBVwYw TcX/gDWfeji+6ktzbRMAI1QugXq93caqnPphsMmm77uh85Jrf4NOROt8gZMdxjt9zmen BhzDJ1JkwkFjECnTAO0Y0jumCqURVfYQobjss0We2TV934efZyKUM2E2LK8fqyU7Yklu J+HlmUx4R5m/Y2fzhI+ZXKWAKzNSR1+cNY1MD3aHQzT2mBMX+q4VtTVVloUAvH175f63 Icxe6ffS6yi13kZte6JYcjmkOSdoGkrZw1u2XlMKZIhPxtMRioxKN9HkgIOibbTh1azu FgUQ== 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=ihUtR7DNTiwd3p0yfxNF+am2ZjstGFp+xB7TII4LFlQ=; b=QgjWIf3ki37PrSyURzdx9ZfOfu0dc1L1DRH3xdA3oc3kQeOCzlCGjKNOj1qM7LRzw5 PwK6Gpe5VDhK7yBOu5xhCArR2VxUlsWK20cYnXVbfwxj5o7TLATg/bBnkufdsr0I88PS HenaPqagsLwx9hrc0XWwipTb/a8N0+BwVmoK/oANU5cRF7YmwYJwdKfrLxTB22ho+597 MNT5O7HtPz/LSIXoVvnYM7CdZYvJGe2KLrfIsDa7JP+99DcGo3b/vZpMOrU4LBiTBkPf Miyt4A21JOoXmGgulvqhtc0Heb2JH/mFR3NvQ6PScUI8buw6s2wZCBEqHd96nyHWNtCt h3aQ== X-Gm-Message-State: AMke39nxlLeA0Ub89V0Gb0ESdzRXzRBGyvabYFFb45sYY2OdVwo9HdKehAzMF3OD9JnJ3+utLXVFHcueCDZHgQ== X-Received: by 10.36.210.134 with SMTP id z128mr16228546itf.23.1487277463880; Thu, 16 Feb 2017 12:37:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.178.210 with HTTP; Thu, 16 Feb 2017 12:37:43 -0800 (PST) From: Naeem Khademi Date: Thu, 16 Feb 2017 21:37:43 +0100 Message-ID: To: "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05b776eada250548abc492 Archived-At: Subject: [tsvwg] Workshop on Future of Internet Transport (FIT 2017) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:37:47 -0000 --94eb2c05b776eada250548abc492 Content-Type: text/plain; charset=UTF-8 Hi all We think that, the tsvwg (as per its charter), as the transport area working group of the IETF should perhaps be aware of this workshop that aims to visit the topic of Internet transport evolution and different strategies that arises from it (also relates to TAPS WG). Those involved in standardization and its related research work, please feel free to submit in here: http://networking.ifip.org/2017/index.php/workshops/workshop-on-future-of-internet-transport-fit-2017 Cheers, Naeem --94eb2c05b776eada250548abc492 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all=C2=A0

We think that, the tsvwg (= as per its charter), as the transport area working group of the IETF should= perhaps be aware of this workshop that aims to visit the topic of Internet= transport evolution and different strategies that arises from it (also rel= ates to TAPS WG). Those involved in standardization and its related researc= h work, please feel free to submit in here: http://networking.ifip.org/2017/index.php/workshops/workshop-on-fut= ure-of-internet-transport-fit-2017=C2=A0

Cheer= s,
Naeem=C2=A0
--94eb2c05b776eada250548abc492-- From nobody Fri Feb 17 00:27:31 2017 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 B75AC129431 for ; Fri, 17 Feb 2017 00:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.787 X-Spam-Level: X-Spam-Status: No, score=-8.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bx35E6I7ryWV for ; Fri, 17 Feb 2017 00:27:28 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 46B33127078 for ; Fri, 17 Feb 2017 00:27:28 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 98217E873F46F; Fri, 17 Feb 2017 08:27:24 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v1H8RPcJ029442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Feb 2017 09:27:26 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v1H8R51A032646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Feb 2017 08:27:23 GMT Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.65]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Fri, 17 Feb 2017 09:27:17 +0100 From: "De Schepper, Koen (Nokia - BE)" To: Wesley Eddy , "tsvwg@ietf.org" Thread-Topic: [tsvwg] comments on L4S architecture draft Thread-Index: AQHSgP1+PmBNRu1AUkyqMrwabPE1o6Fs7NmA Date: Fri, 17 Feb 2017 08:27:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] comments on L4S architecture draft X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 08:27:31 -0000 SGkgV2VzLA0KDQpUaGFua3MgZm9yIHRoZXNlIHZlcnkgdXNlZnVsIGNvbW1lbnRzLiBXZSB3aWxs IHRha2UgdGhlbSBpbnRvIGFjY291bnQgd2hlbiB3cml0aW5nIHRoZSBuZXh0IHZlcnNpb24ocyku DQoNCktvZW4uDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0c3Z3 ZyBbbWFpbHRvOnRzdndnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBXZXNsZXkgRWRk eQ0KPiBTZW50OiBkaW5zZGFnIDcgZmVicnVhcmkgMjAxNyA1OjQ5DQo+IFRvOiB0c3Z3Z0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBbdHN2d2ddIGNvbW1lbnRzIG9uIEw0UyBhcmNoaXRlY3R1cmUgZHJh ZnQNCj4gDQo+IEkgaGF2ZSBzb21lIGNvbW1lbnRzIHRvIHNoYXJlIG9uIHRoZSBhcmNoaXRlY3R1 cmUgZHJhZnQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1icmlzY29lLXRz dndnLWw0cy1hcmNoLTAwDQo+IA0KPiBUaGVzZSBhcmUgbW9zdGx5IHBvc2l0aXZlIGNvbW1lbnRz LCBhbmQgbWFueSBjYW4gYmUgY29uc2lkZXJlZA0KPiBsb25nZXItdGVybSwgaW4gbXkgb3Bpbmlv biwgbm90IHVyZ2VudCBub3IgYmxvY2tpbmcgYWRvcHRpbmcgaW4gVFNWV0cuDQo+IA0KPiAxLiBJ dCBzZWVtcyB0byBtZSB0aGF0IEw0UyBjYW4gYWRkcmVzcyBzb21lIHBhaW4gcG9pbnRzIHRoYXQg b3BlcmF0b3JzDQo+IGhhdmUuICBJJ20gc3VyZSB0aGUgYXV0aG9ycyBoYXZlIGdvdCBzb21lIGlu cHV0IG9uIHRoaXMgZnJvbSBvcGVyYXRvcnMsDQo+IGJ1dCBpdCBtaWdodCBiZSBnb29kIHRvIGlu Y2x1ZGUgbW9yZSBvZiBhIGRlcGxveW1lbnQgd2Fsa3Rocm91Z2ggaW4gdGhlDQo+IGRyYWZ0LiAg SXQgbWVudGlvbnMgaW5jcmVtZW50YWwgZGVwbG95bWVudCBhcyBiZWluZyBwb3NzaWJsZSwgYnV0 IEkNCj4gdGhpbmsgdGhlcmUgY291bGQgYmUgYSBtb3JlIGNsZWFyIGRpc2N1c3Npb24gb2Ygd2hh dCBpbmNyZW1lbnRhbCB1dGlsaXR5DQo+IHRoZXJlIGlzLCBob3cgdG8gc3RhcnQsIGV0Yy4NCj4g DQo+IDIuIEkgdGhpbmsgdGhlIHJlYWwgInNlbGxpbmcgcG9pbnQiIGlzIHRoYXQgb3BlcmF0b3Jz IHdvbid0IG5lZWQgdG8NCj4gcHJvdmlzaW9uIHNlcGFyYXRlIHRyYW5zcG9ydCB1bmRlcmxheXMg Zm9yIGNlcnRhaW4gaGlnaC1wZXJmb3JtYW5jZQ0KPiBhcHBsaWNhdGlvbnMgKGUuZy4gdGhhdCBt aWdodCB1c2UgRENUQ1ApIHZlcnN1cyBvdGhlciB0cmFmZmljLiAgTDRTIGNhbg0KPiBlbmFibGUg YmV0dGVyIHBlcmZvcm1hbmNlIHdpdGggbGVzcyBwcmUtY29uZmlndXJhdGlvbiwgYmFrZWQtaW4N Cj4gc2V0dGluZ3MsIG9yIHR3aWRkbGluZyB3aXRoIGtub2JzLiBUaGUgZHJhZnQgZG9lc24ndCBy ZWFsbHkgc2VlbSB0bw0KPiBkaXJlY3RseSBhdHRhY2sgdGhlIGN1cnJlbnQgcHJhY3RpY2VzIG9m IHBhcnRpdGlvbmluZyByZXNvdXJjZXMgYW5kIGhvdw0KPiBsYWJvci1pbnRlbnNpdmUgYW5kIGZy YWdpbGUgdGhpcyBjYW4gYmUuICBMNFMgY291bGQgYmUgYSBiaWcgaW1wcm92ZW1lbnQNCj4gZm9y IHNvbWUgcGVvcGxlLg0KPiANCj4gMy4gSW4gYWRkaXRpb24gdG8gYmVpbmcgYW4gYXJjaGl0ZWN0 dXJlIGRlc2NyaXB0aW9uLCB0aGUgZHJhZnQgYWxzbw0KPiBzZXJ2ZXMgYXMgYSBiaXQgb2YgYSAi d29yayBwbGFuIiBmb3Igd2hhdCBuZWVkcyB0byBiZSBkb25lIChlLmcuIGluDQo+IFNlY3Rpb24g NCkuICBUaGUgd29yZGluZyBpcyBhIGJpdCBzdHJvbmcgc29tZXRpbWVzLCBzYXlpbmcgdGhpbmdz ICJuZWVkIg0KPiB0byBiZSBkb25lLCBidXQgcmVhbGx5IHRoZSBiZW5lZml0cyBvZiBMNFMgY2Fu IGFjY3J1ZSBpbmNyZW1lbnRhbGx5IGFzDQo+IHNvbWUgb2YgdGhhdCB3b3JrIGhhcHBlbnMsIGFu ZCBzb21lIG9mIHRoZSB3b3JrIGl0ZW1zIG1lbnRpb25lZCBtYXkgbm90DQo+IHJlYWxseSBiZSBu ZWVkZWQgYXQgYWxsLiAgRm9yIGluc3RhbmNlLCBEQ0NQIHNjYWxhYmxlIENDIGRvZXNuJ3QgbmVl ZCB0bw0KPiBiZSBpbiBwbGFjZSBmb3IgTDRTIHRvIGhhdmUgYmVuZWZpdCwgYW5kIEw0UyB3b3Vs ZG4ndCBmYWlsIGp1c3QgYmVjYXVzZQ0KPiBub25lIG9mIHRoZSBleGlzdGluZyBtb3N0bHktdW51 c2VkIERDQ1AgY29kZWJhc2VzIGltcGxlbWVudCB0aGUgbmV3DQo+IENDSUQuIFdoYXQgdHJ1bHkg Im5lZWRzIiB0byBoYXBwZW4gdG8gc3RhcnQgc2hvd2luZyBiZW5lZml0cyBjb3VsZCBiZQ0KPiBi ZXR0ZXIgZGlzdGluZ3Vpc2hlZCBmcm9tIHdoYXQgdWx0aW1hdGVseSBjb3VsZCBoYXBwZW4uDQo+ IA0KPiA0LiBUaGUgY2FwdGlvbiBvbiBGaWd1cmUgMSBoYXMgaW5jb3JyZWN0IG51bWJlcmluZyB3 aXRoIHJlZ2FyZCB0byB0aGUNCj4gZmlndXJlIChudW1iZXIgMSBhbmQgMiBhcmUgc3dhcHBlZCBp biB0aGUgY2FwdGlvbiwgSSBiZWxpZXZlKS4NCj4gQWRkaXRpb25hbGx5LCBpbiB0aGUgdGV4dCBh Ym92ZSB0aGUgZmlndXJlLCBidWxsZXQgbnVtYmVyaW5nIG9yZGVyIG9mIDIsDQo+IDEsIDMgaXMg c3RyZXNzZnVsIHRvIHJlYWQgKHRob3VnaCBJIHRoaW5rIHdhcyBwcm9iYWJseSBkb25lIG9uIHB1 cnBvc2UNCj4gZm9yIGxlZnQtcmlnaHQgcmVsYXRpb24gdG8gdGhlIGRpYWdyYW0/KS4NCj4gDQo+ IDUuIEluIHRoZSBkaXNjdXNzaW9uIG9mIEVDTiBhdCB0aGUgYmVnaW5uaW5nIG9mIHNlY3Rpb24g NS4xLCBpdCBjb3VsZCBiZQ0KPiBtb3JlIGNsZWFyIHRoYXQgdGhpcyBpcyBpbiByZWdhcmQgdG8g dHJhZmZpYyBpbiB0aGUgTDRTIGNsYXNzLCBhbmQgdGhhdA0KPiBvdGhlciB0cmFmZmljIHVzaW5n IHRoZSAiY2xhc3NpYyIgcXVldWUgZG9lc24ndCBuZWVkIHRvIHVzZSBFQ04uDQo+IA0KPiA2LiBT b21lIG9mIHRoZSBjb21wYXJpc29uL2NvbnRyYXN0IHN0YXRlbWVudHMgd2l0aCBmcV9jb2RlbCBk b24ndCBzZWVtDQo+IHF1aXRlIHJpZ2h0LCBzaW5jZSBGUSBpcyBhY2hpZXZpbmcgYSBkaWZmZXJl bnQgZ29hbCB0aGFuIHNpbXBseSBlbmFibGluZw0KPiBzY2FsYWJsZSBhbmQgY2xhc3NpYyB0cmFm ZmljIHRvIGNvZXhpc3QuICBGb3IgaW5zdGFuY2UsIEZRIGlzIGFsc28NCj4gbGltaXRpbmcgaW1w YWN0IG9mIHZlcnkgYmFkLWJlaGF2aW5nIGZsb3dzIG9uIG90aGVyIGZsb3dzIChlLmcuIGJhZA0K PiBmbG93cyBtYXkgZm9sbG93IG5laXRoZXIgdGhlIHNjYWxhYmxlIG5vciBjbGFzc2ljIHBhcmFk aWdtcyBvZiBDQyEpLg0KPiANCj4gNy4gQW5vdGhlciBwb3NzaWJsZSB1c2UgY2FzZSBmb3Igc2Vj dGlvbiA2IG1pZ2h0IGJlIG5ldHdvcmtzIHdoZXJlDQo+IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5p bmcgaXMgcHJldmFsZW50IGFuZCBkZWxheSBhY3Jvc3MgdGhlIG5ldHdvcmsNCj4gbmVlZHMgdG8g YmUgbWluaW1pemVkIGJlY2F1c2UgdHJhZmZpYyBpcyBjcmlzcy1jcm9zc2luZyB0aHJvdWdoIHBv c3NpYmx5DQo+IG9kZCBwYXRocyB0aGF0IGFyZSBtdWNoIGRpZmZlcmVudCB0aGFuIGp1c3QgdGhl IHNob3J0ZXN0IHNldCBvZiBwaHlzaWNhbA0KPiBob3BzIGJldHdlZW4gc291cmNlIGFuZCBkZXN0 aW5hdGlvbi4NCj4gDQo+IDguIFZpcnR1YWwgc3dpdGNoIGltcGxlbWVudGF0aW9ucyBtYXkgYmUg aW1wb3J0YW50IGluIGFkZGl0aW9uIHRvIHBoeXNpY2FsLg0KPiANCj4gOS4gV291bGQgb25pb24g cm91dGluZyBzeXN0ZW1zIGFsc28gYmUgYSBwb3RlbnRpYWwgYmVuZWZpY2lhcnkgb2YgTDRTLA0K PiBpZiB0aGV5IHVzZWQgc2NhbGFibGUgdHJhbnNwb3J0cz8gIFRoZXkgbm9ybWFsbHkgaGF2ZSBh IGxvdCBvZiBkZWxheSBhbmQNCj4gZGVsYXkgdmFyaWF0aW9uLg0KPiANCj4gMTAuIFRoZSBiZW5l Zml0cyBhbmQgZGVzY3JpcHRpb25zIGluIHRoZSBkb2N1bWVudCBtYWtlIHNlbnNlIHRvIG1lLCBi dXQNCj4gSSBhbHNvIGtub3cgb2YgdGhlIGhpc3RvcnkgYW5kIHJlbGF0ZWQgd29yayB0aGF0IHRo ZSBkb2N1bWVudCBidWlsZHMNCj4gdXBvbi4gIEkgd29uZGVyIGlmIGl0J3MgYXMgY2xlYXIgdG8g b3RoZXIgcGVvcGxlIGNvbWluZyBmcmVzaD8gIEZvciBtYW55DQo+IG9wZXJhdGlvbnMgdHlwZSBv ZiBwZW9wbGUsIHRoaXMgbWF5IGJlIHRoZSBjYXNlLCBzbyBmZWVkYmFjayB0aGVyZSB3b3VsZA0K PiBiZSB1c2VmdWwsIEkgdGhpbmsuDQo+IA0KPiAxMS4gU29tZSBvZiB0aGUgdGV4dCByZXByZXNl bnRzIGEgc3RhdGUgb2YgYWZmYWlycyB0aGF0IHdpbGwgY2hhbmdlDQo+IChlLmcuIHBhZ2UgNyBk aXNjdXNzaW5nIHByb2dyZXNzKSwgYW5kIGl0IHNob3VsZCBiZSBjb25zaWRlcmVkIHdoZXRoZXIN Cj4gdGhpcyBzdHVmZiB3b3VsZCBiZSBvZiB2YWx1ZSB0byBnbyBpbnRvIGFuIFJGQyBvciBub3Qu DQo+IA0KDQo= From nobody Wed Feb 22 09:02:06 2017 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 A24AE129A6C for ; Wed, 22 Feb 2017 09:02:04 -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 0VTDIbfsd82F for ; Wed, 22 Feb 2017 09:02:03 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::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 97C8412998D for ; Wed, 22 Feb 2017 09:02:03 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id z128so3344542pgb.0 for ; Wed, 22 Feb 2017 09:02:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=JX3CRTmEV3ctvtYxsOSFtsgIt4Fn3A0lp/MHQxa40qk=; b=r509BNtZzJPvhcxiSjHCs2Yjx9Cy9AK7OYSPwMJqaCX1JcWrLnTw2Y/JkIbpGE7Dlq zNtWNIUb628nXGaqdT4KYFU9kerrP1xnKw33qX5oztvpCdJx3yZi7f3bVl00Ems9aom0 N0K4YsIgVVwDBTwG3+XdYIU/gYyNxICbFC3xrmo0HNpS8FNl3joXruv4bpju7Q8aMrBS SlY5zmEJ1qidP933Z+/kwgtXGIPvWX0zfPgIelvD1SzB5nXlIrooV/bswLl8knqdOig8 xb8bgTSZ2HcwPWiMRyWMr5I5brnZ2tCIukPeFq8IE3b37+jCY8LpkH6Ce/If+acDkbXp NF/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=JX3CRTmEV3ctvtYxsOSFtsgIt4Fn3A0lp/MHQxa40qk=; b=LyjTGfg77UsxC+s0H3FnjcAGF3ML7bIYvszoqoH0UdkNYpGqKIHAOrNhhTFf0ArT5k hs5WsQZ7uD+xDcOnoQnsjFYEBehtq1vnnVjJAYlKAmXFB2igTicOLRmPaS1crhIVl2la FV4xAX4JsiUqgb/2IKenp5iV0Y6U/R66KAI2qoeSxr8sIZxNK9IgsahTvp0FtmFK0QwN Qmawjrx4QpEghzEJ95Rn5CN2tqIyEN5UFGjDMeWzPcm9RY/X0K9ttJZPpaAIJQOojU+s j9sq2J+XzEIeCZrW5DTZgnSDxf/8ChblMC/NsgCp7UJcL7YiSCzMxRa6ZRPLWogN1TSS Lomw== X-Gm-Message-State: AMke39ms9b6OWtak0UCIoYeLcCSVV83nnwgRBnQnrRaCNov0j3VQpR9LLSOJQ54FHXDOGQ== X-Received: by 10.98.216.202 with SMTP id e193mr22207699pfg.80.1487782923078; Wed, 22 Feb 2017 09:02:03 -0800 (PST) Received: from [172.19.117.21] ([2001:4878:8000:60:90e2:fef5:6095:18f9]) by smtp.gmail.com with ESMTPSA id p15sm4775025pfk.58.2017.02.22.09.02.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 09:02:02 -0800 (PST) From: "Aaron Falk" To: "tsvwg IETF list" Date: Wed, 22 Feb 2017 12:02:00 -0500 Message-ID: <46B80ACD-CFE4-4CFB-BC10-5166A050582A@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [tsvwg] DCCP vulnerability X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 17:02:04 -0000 Anyone know of deployed DCCP implementations? Vulnerability discovered: https://news.ycombinator.com/item?id=13705833 —aaron From nobody Fri Feb 24 00:20:06 2017 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 E90E51293F9 for ; Fri, 24 Feb 2017 00:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 meFrWehrRS6j for ; Fri, 24 Feb 2017 00:20:02 -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 0B656129421 for ; Fri, 24 Feb 2017 00:20:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.35,200,1484002800"; d="scan'208,217";a="214564673" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.149]) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2017 09:19:58 +0100 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_A83D218B-D72F-4535-9519-1C326713F97A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 24 Feb 2017 09:19:56 +0100 References: <148792339515.13927.14947151976422656756.idtracker@ietfa.amsl.com> To: tsvwg WG , nwcrg@irtf.org Message-Id: <58286145-D514-435E-9DC4-A21EA89B7F30@inria.fr> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "Ali C. Begen" Subject: [tsvwg] Fwd: New Version Notification for draft-roca-tsvwg-fecframev2-03.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 08:20:05 -0000 --Apple-Mail=_A83D218B-D72F-4535-9519-1C326713F97A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello everybody, As discussed during previous IETF, we updated our FECFRAME I-D so that: - it extends RFC 6363 (instead of obsoleting it), - it only includes additional text to RFC 6363 (instead of = copying everything). The result is pretty compact (although we copied the long 2 pages 1/2 = definition section of the RFC). We also kept the initial I-D filename for tracking purposes, although = this is no longer a "new" version. This I-D along with our RLC I-D = (https://datatracker.ietf.org/doc/draft-roca-tsvwg-rlc-fec-scheme/ = )=20 are meant to work together.=20 Once again we cross-post this message to the NWCRG mailing list where = the work has been initiated. Regards, Vincent and Ali > De: internet-drafts@ietf.org > Objet: New Version Notification for draft-roca-tsvwg-fecframev2-03.txt > Date: 24 f=C3=A9vrier 2017 =C3=A0 09:03:15 UTC+1 > =C3=80: "Vincent Roca" , "Ali Begen" = >=20 >=20 > A new version of I-D, draft-roca-tsvwg-fecframev2-03.txt > has been successfully submitted by Vincent Roca and posted to the > IETF repository. >=20 > Name: draft-roca-tsvwg-fecframev2 > Revision: 03 > Title: Forward Error Correction (FEC) Framework = Extension to Convolutional Codes > Document date: 2017-02-24 > Group: Individual Submission > Pages: 18 > URL: = https://www.ietf.org/internet-drafts/draft-roca-tsvwg-fecframev2-03.txt > Status: = https://datatracker.ietf.org/doc/draft-roca-tsvwg-fecframev2/ > Htmlized: = https://tools.ietf.org/html/draft-roca-tsvwg-fecframev2-03 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-roca-tsvwg-fecframev2-03 >=20 > Abstract: > RFC 6363 describes a framework for using Forward Error Correction > (FEC) codes with applications in public and private IP networks to > provide protection against packet loss. The framework supports > applying FEC to arbitrary packet flows over unreliable transport and > is primarily intended for real-time, or streaming, media. However > FECFRAME as per RFC 6363 is restricted to block FEC codes. The > present document extends FECFRAME to support convolutional FEC = Codes, > based on a sliding encoding window, in addition to Block FEC Codes. > This is done in a backward compatible way. During multicast/ > broadcast real-time content delivery, these codes significantly > improve robustness in harsh environments, with less repair traffic > and lower FEC-related added latency. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_A83D218B-D72F-4535-9519-1C326713F97A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello everybody,

As discussed during previous IETF, we updated our FECFRAME = I-D so that:
- it extends RFC 6363 (instead of = obsoleting it),
- it only includes additional = text to RFC 6363 (instead of copying everything).
The= result is pretty compact (although we copied the long 2 pages 1/2 = definition section of the RFC).

We also kept the initial I-D filename for tracking purposes, = although this is no longer a "new" version.

This I-D along with our RLC I-D (https://datatracker.ietf.org/doc/draft-roca-tsvwg-rlc-fec-schem= e/) 
are meant to work = together. 

Once again we cross-post this message to the NWCRG mailing = list where the work has been initiated.

Regards,

  Vincent and Ali


De: internet-drafts@ietf.org
Objet: = New Version = Notification for draft-roca-tsvwg-fecframev2-03.txt
Date: = 24 f=C3=A9vrier 2017 =C3=A0 = 09:03:15 UTC+1
=C3=80: = "Vincent Roca" <vincent.roca@inria.fr>, "Ali Begen" <ali.begen@networked.media>

A new version of I-D, draft-roca-tsvwg-fecframev2-03.txt
has been successfully submitted by Vincent Roca and posted to = the
IETF repository.

Name: = draft-roca-tsvwg-fecframev2
Revision: 03
Title:= = Forward Error Correction (FEC) Framework Extension to = Convolutional Codes
Document date: = 2017-02-24
Group: Individual Submission
Pages:= = 18
URL: =            https://www.ietf.org/internet-drafts/draft-roca-tsvwg-fecframev= 2-03.txt
Status: =         https://datatracker.ietf.org/doc/draft-roca-tsvwg-fecframev2/
Htmlized:       https://tools.ietf.org/html/draft-roca-tsvwg-fecframev2-03<= br class=3D"">Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-roca-tsvwg-fecframev2= -03

Abstract:
=   RFC 6363 describes a framework for using Forward Error = Correction
  (FEC) codes with applications in = public and private IP networks to
  provide = protection against packet loss.  The framework supports
  applying FEC to arbitrary packet flows over = unreliable transport and
  is primarily = intended for real-time, or streaming, media.  However
=   FECFRAME as per RFC 6363 is restricted to block FEC codes. =  The
  present document extends FECFRAME = to support convolutional FEC Codes,
  based on = a sliding encoding window, in addition to Block FEC Codes.
=   This is done in a backward compatible way.  During = multicast/
  broadcast real-time content = delivery, these codes significantly
  improve = robustness in harsh environments, with less repair traffic
=   and lower FEC-related added latency.




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


= --Apple-Mail=_A83D218B-D72F-4535-9519-1C326713F97A-- From nobody Fri Feb 24 05:00:31 2017 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 0F0BA1296F9 for ; Fri, 24 Feb 2017 05:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 IH6pn1i1meLR for ; Fri, 24 Feb 2017 05:00:27 -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 EDA131296F6 for ; Fri, 24 Feb 2017 05:00:26 -0800 (PST) Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:206e:eb73:fce8:85c]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8AAC11B00215 for ; Fri, 24 Feb 2017 14:58:09 +0000 (GMT) References: <20170223140651.GA32050@tom-desk.erg.abdn.ac.uk> From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. To: tsvwg WG X-Forwarded-Message-Id: <20170223140651.GA32050@tom-desk.erg.abdn.ac.uk> Message-ID: Date: Fri, 24 Feb 2017 13:00:22 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170223140651.GA32050@tom-desk.erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] Fwd: draft-ietf-tsvwg-ieee-802-11-01 review X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 13:00:30 -0000 Here is some feedback from Tom Jones. This may help in closing the WGLC reviews for the draft-ietf-tsvwg-ieee-802-11-01, authors please consider this as a late WGLC comment. Gorry -------- Forwarded Message -------- Hi Gorry, As requested, I have reviewed draft-ietf-tsvwg-ieee-802-11-01, you asked me to specifically look at the Appendix describing 80211 QoS. From a close read and referring to some standards material on the DCF I am happy with your explanation of how this works. In addition I wanted to verify against a code base that the mappings were operating correctly. I have included a comparison to the FreeBSD 80211 stack, which agrees with your description. 2.1. Default DSCP-to-UP Mappings and Conflicts " While no explicit guidance is offered in mapping (6-Bit) Layer 3 DSCP values to (3-Bit) Layer 2 markings (such as IEEE 802.1D, 802.1p or 802.11e), a common practice in the networking industry is to map these by what we will refer to as 'Default DSCP-to-UP Mapping' (for lack of a better term), wherein the 3 Most Significant Bits (MSB) of the DSCP are transcribed to generate the corresponding L2 markings. " Conversion from DSCP to AC: FreeBSD: Generates the the AC by shifting down the TOS field five places if (eh->ether_type == htons(ETHERTYPE_IP)) { uint8_t tos; /* * IP frame, map the DSCP bits from the TOS field. */ /* NB: ip header may not be in first mbuf */ m_copydata(m, sizeof(struct ether_header) + offsetof(struct ip, ip_tos), sizeof(tos), &tos); tos >>= 5; /* NB: ECN + low 3 bits of DSCP */ d_wme_ac = TID_TO_WME_AC(tos); } else { ... in ieee80211_classify https://github.com/freebsd/freebsd/blob/e5f23e316cc39affdeb94c2f8a9cf2eb581d18a5/sys/net80211/ieee80211_output.c#L1002 The resulting 3 bit value is then mapped to the AC with: #define TID_TO_WME_AC(_tid) ( \ ((_tid) == 0 || (_tid) == 3) ? WME_AC_BE : \ ((_tid) < 3) ? WME_AC_BK : \ ((_tid) < 6) ? WME_AC_VI : \ WME_AC_VO) TID_TO_WME_AC https://github.com/freebsd/freebsd/blob/8e0917e51f5177df86705e80e9927103aaffb65a/sys/net80211/ieee80211.h#L318 If the packet has a vlan tag, its priority is captured and converted to a AC. The final returned AC is the highest between the vlan tag and the DSCPfield value. 4.2.9. Standard Service Class - Typo? OLD: The Standard Service Class loosely corresponds to the 802.11 Best Effort Access Category (AC_BK) NEW: The Standard Service Class loosely corresponds to the 802.11 Best Effort Access Category (AC_BK) ^^^^^^^ - [tj] From nobody Mon Feb 27 15:31:21 2017 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 6D162129457 for ; Mon, 27 Feb 2017 15:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inaplz9Yklkz for ; Mon, 27 Feb 2017 15:31:17 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 C0253129452 for ; Mon, 27 Feb 2017 15:31:17 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v1RNV0K9017002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Feb 2017 15:31:00 -0800 (PST) References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> To: tsvwg From: Joe Touch X-Forwarded-Message-Id: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> Message-ID: <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> Date: Mon, 27 Feb 2017 15:30:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------31F6F2228F16315C5CBBA8A8" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 23:31:19 -0000 This is a multi-part message in MIME format. --------------31F6F2228F16315C5CBBA8A8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all, A new version of the UDP options proposal has been posted. It adds: - fragmentation based on IPv6's mechanism (thanks to Mark Smith) - MSS (thanks to Mark Smith) and TS based on TCP's mechanism - auth/encryption based on TCP-AO and its extensions It clarifies the report of a non-compliant legacy device (thanks to Mike Heard). It also adds a discussion on control block caching, ala RFC2140 for TCP. Feedback welcome. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tsvwg-udp-options-05.txt Date: Mon, 27 Feb 2017 15:24:32 -0800 From: internet-drafts@ietf.org To: Joseph Touch , Joe Touch A new version of I-D, draft-touch-tsvwg-udp-options-05.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 05 Title: Transport Options for UDP Document date: 2017-02-27 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-05.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-05 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. 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 --------------31F6F2228F16315C5CBBA8A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, all,

A new version of the UDP options proposal has been posted.

It adds:

    - fragmentation based on IPv6's mechanism (thanks to Mark Smith)

    - MSS (thanks to Mark Smith) and TS based on TCP's mechanism

    - auth/encryption based on TCP-AO and its extensions

It clarifies the report of a non-compliant legacy device (thanks to Mike Heard).

It also adds a discussion on control block caching, ala RFC2140 for TCP.

Feedback welcome.

Joe

-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tsvwg-udp-options-05.txt
Date: Mon, 27 Feb 2017 15:24:32 -0800
From: internet-drafts@ietf.org
To: Joseph Touch <touch@isi.edu>, Joe Touch <touch@isi.edu> 


A new version of I-D, draft-touch-tsvwg-udp-options-05.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	05
Title:		Transport Options for UDP
Document date:	2017-02-27
Group:		Individual Submission
Pages:		20
URL:            https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-05.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/
Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-05
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-05

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.

                                                                                  


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
--------------31F6F2228F16315C5CBBA8A8-- From nobody Tue Feb 28 08:38:01 2017 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 0E563129633 for ; Tue, 28 Feb 2017 08:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-tsvwg@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CONcjDVlEIGQ for ; Tue, 28 Feb 2017 08:37:52 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 982ED129624 for ; Tue, 28 Feb 2017 08:37:52 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 28 Feb 2017 16:37:52 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 0A989D788E; Tue, 28 Feb 2017 08:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=q4LK2ZcGReIECELyuPbIX3aFGmw=; b=Dm xIypG8KkbTcPIV9guMm+z9Kb5yp+QVk9RZbfH6Sk/J72716YOJSnhAqizsDJuVve etqh8vm/5Q5GdCA9XTyLF7Tyi02rH+GkaBdzKS+NCk44u2306Z8SWHfP5UvZjp4E CZL9b/wHn+oDtV1/JZpHOd41/EpZp/hoIKUn0FXCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=auGwlIu0J8vqUsRCQmdCNHaTJ5RH edVcmNWlTbtHauZDR8QAAyK/PrhMgnVNJLakW6zNfUf+1T14HYXZngRKiPTgubBN 4vUYDmWsodYJtmhKSAdwdGxpX1wRFY7D2fff1a2WBqaVHzWYb0BWfjo3E2fF1geq vgPVFt2TYxy+dpY= Received: by cowbell.employees.org (Postfix, from userid 1736) id F4149D788D; Tue, 28 Feb 2017 08:37:51 -0800 (PST) Date: Tue, 28 Feb 2017 16:37:51 +0000 From: Derek Fawcus To: Joe Touch Message-ID: <20170228163751.GA89477@cowbell.employees.org> Mail-Followup-To: Joe Touch , tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: tsvwg Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 16:38:00 -0000 On Mon, Feb 27, 2017 at 03:30:59p.m. -0800, Joe Touch wrote: > A new version of the UDP options proposal has been posted. I quite like the described scheme, a few comments below: Section 5 question on must implement: Personally I'd say the most interesting / useful are (in order): MSS, FRAG, TIME, LITE, ACS, AE So that would inform my choice of which to make mandatory Section 5.4 (Alternate checksum): By inference one can deduce that 'UDP payload only' must refer to the data region which figure 3 names as the 'UDP user data', and hence also excludes any Lite data. Maybe this (UDP user data) should be explicitly stated? Also which CRC16? I've seen a few. Maybe state its polynomial? Section 7 (UDP options vs. UDP-Lite): 4th para seems to refer to a prior scheme for a LITE option. With the described swap mechanism, there is no need for an EOL option (for Lite purposes), and the Lite data ends up directly following the normal data vs this text stating they are disjoint. So this could be reduced to just the portion comparing the default delivery (or not) of the Lite data. Section 5.3 (Option Checksum) It looks like the described scheme was needed for compatibility with a prior version of the Lite mechanism. You could simplify the option checksum handling by simply defining the first 2 bytes of the surplus area as a 16 bit checksum over the whole of the surplus area while in its Figure 10 form, i.e. not including the Lite data. This would be compatible with the LITE swap scheme you describe in section 5.5, just with one having to swap 6 bytes rather than 4 bytes. It would also take no more space than the existing checksum - assuming such was always included. I can see that this would make the job of a middle box which chose to modify an option (say MSS clamping) easier, but I'd suggest the main gain is simply following a more familiar scheme of the same 16 bit ones complement as elsewhere (even if not negated as one usually does). Section 5.1 (End of Options List) Given the above change to the options checksum, and the stale text in section 7, it would seem that there is no need for the EOL option, and NOP could become 0; however that probably doesn't matter either way. Section 5.8 (Fragmentation) A trivial point, but should this be referred to a segmentation instead? I forsee the confused conversations in future when one is refering to UDP fragments, or Fragmented UDP and having to clarify if one means an IP fragment or this transport level fragmentation scheme. Figure 15 shows a 64 bit Identification field, yet the text refers to a 32 bit field. Which is correct? If fragmentation is present with Lite, and two such packets are received to be reassembled, what happens to the Lite data from each packet? Should this combination be rejected, or defined in some fashion? I've not really looked at Seciton 5.9, as I'd need to refresh myself on the TCP option behaviour. DF From nobody Tue Feb 28 10:58:50 2017 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 F163A1293D6 for ; Tue, 28 Feb 2017 10:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 w6Aau_am_N0s for ; Tue, 28 Feb 2017 10:58:47 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B6612896F for ; Tue, 28 Feb 2017 10:58:47 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 7EC176C602 for ; Tue, 28 Feb 2017 13:58:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; s=sasl; bh=pa5 eOExKS6lKkn1cCCLyh8N/oVA=; b=RAGqlvre6W6Z+QwB6AJL/opxG54lY9PdHwk Y8L1vC/HRX3ZhTIi9MygErhV+18PBGt1tWGIQOBN+WJdEWg8xc9XbgWy7mF9giXk OMrDDdAvdVSG4gozQlY3wLTXruSZkeXs7EYVtRcHDaxoqmcEmViVyCMHEpGBTyyM Fmv/LIzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:cc:content-type; q=dns; s=sasl; b= iQToYb9R4qAL6/f3/X+cmwVHlP+JrCxcwYjMoBRe2RemtfxRlSKmd4iqGf6qbx5w n8FPjHVWFP3KK/OjpwVY/MyoVvBhPU8nxc7uKfcjfDY9AbqeWDBG0G1ZdFNaMwXG ZgoLUXM1/fnWpCxrnDrih+D3XJ+wxxQukwjm+N03K70= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 748C36C600 for ; Tue, 28 Feb 2017 13:58:45 -0500 (EST) Received: from mail-qk0-f174.google.com (unknown [209.85.220.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id DFE386C5FE for ; Tue, 28 Feb 2017 13:58:44 -0500 (EST) Received: by mail-qk0-f174.google.com with SMTP id u188so33325689qkc.2 for ; Tue, 28 Feb 2017 10:58:44 -0800 (PST) X-Gm-Message-State: AMke39nI2MtVVYOObd1wR/evbh0h0XJ6OaF0B2rhsU5PQvEq+ah2+DzU3qiKIh1x8su0bm9zC/D1VVcPQyD8Aw== X-Received: by 10.233.223.129 with SMTP id t123mr4337326qkf.191.1488308324407; Tue, 28 Feb 2017 10:58:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.18.106 with HTTP; Tue, 28 Feb 2017 10:58:24 -0800 (PST) From: "C. M. Heard" Date: Tue, 28 Feb 2017 10:58:24 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: EDBED668-FDE7-11E6-865B-FE3F13518317-06080547!pb-smtp1.pobox.com Archived-At: Cc: Mark Smith , tsvwg Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 18:58:49 -0000 Greetings, I am very pleased with the latest version of this draft, and in particular with the proposed Fragmentation option. It cleanly solves the problem of providing an optional fragmentation capability in UDP that can be incrementally deployed. It appears to be a viable way to solve the problem of fragmented DNSSEC responses getting dropped because of middleboxes filtering IPv4 or IPv6 fragments. Application layer solutions have been proposed (see https://tools.ietf.org/html/draft-muks-dns-message-fragments), but the current proposal has the advantage that it will work for any UDP-based protocol. It will work especially well for request-response protocols such as DNS where the requests typically are small (not requiring fragmentation) but the responses may be large. To use it, the client sends the request in an unfragmented UDP datagram but appends a Fragmentation option with Offset and M both zero. If the server does not support UDP options, it ignores the trailing option and behaves as it does today. If the server does support UDP options and the response won't fit in a single UDP datagram without causing IP layer fragmentation, it transmits the response in several datagrams, using the UDP fragmentation options. This will work especially well for IPv6, where the path MTU is guaranteed to be at least 1280 bytes. Back in 2013 several proposals for UDP layer fragmentation surfaced during a discussion on the 6man list about whether to deprecate IPv6 fragmentation (one was in https://www.ietf.org/mail-archive/web/ipv6/current/msg18703.html). None of those proposals solved the problem of incremental deployability, however, as this one does. Thanks and congratulations for coming up with an elegant solution. I do have some technical comments to make on the Fragmentation option. First, I would like to suggest that the post-reassembly user data length and optionally a post-reassembly user data checksum appear in the UDP Fragmentation option. The reason for including a post-reassembly length is to provide a hint to the implementation how much buffer space to reserve; in order to be foolproof in the face of packet reordering, this needs to be in every fragment. The optional post-reassembly checksum would need to be in at least one Fragmentation option and (like the post-reassembly length) would have to have be the same if it appeared more than once. Its main value is that it provides a stronger verification that the reassembly process was done correctly than the fragment-by-fragment checksum in the UDP header. Finally, if used in conjunction with the Lite option, it provides a means to overcome the following issue: The Fragmentation option needs to be used with extreme care because it will present incorrect datagram boundaries to a legacy receiver. If the Fragmentation option includes its own post-reassembly checksum, then a Lite option could be inserted immediately following the UDP header in each fragment, without loss of functionality. Implementations that do not support UDP options would see UDP fragments so constructed as empty UDP datagrams and would discard them, removing the danger of accidental misinterpretation. I also have an editorial comment on this option. Figure 15 shows the option length as 12 bytes and the Identification field length as 8 bytes, while the text says that the Identification field is 32 bits (4 bytes). This figure needs to be updated to match the text (whatever that turns out to be) and it also needs a new caption. Finally, the text is silent on how Alternate Checksum (ACS) interacts with the Lite option and with the Fragmentation option. My assumption would be that ACS covers the entire payload in one datagram, irrespective of the presence or absence of Lite and Fragmentation, but it would be good to make this explicit. Thanks and regards, Mike Heard On Mon, 27 Feb 2017 15:30:59 -0800, Joe Touch wrote: > > Hi, all, > > A new version of the UDP options proposal has been posted. > > It adds: > > - fragmentation based on IPv6's mechanism (thanks to Mark Smith) > > - MSS (thanks to Mark Smith) and TS based on TCP's mechanism > > - auth/encryption based on TCP-AO and its extensions > > It clarifies the report of a non-compliant legacy device (thanks to Mike Heard). > > It also adds a discussion on control block caching, ala RFC2140 for TCP. > > Feedback welcome. > > Joe > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-touch-tsvwg-udp-options-05.txt > Date: Mon, 27 Feb 2017 15:24:32 -0800 > From: internet-drafts at ietf.org > To: Joseph Touch , Joe Touch > > > A new version of I-D, draft-touch-tsvwg-udp-options-05.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. > > Name: draft-touch-tsvwg-udp-options > Revision: 05 > Title: Transport Options for UDP > Document date: 2017-02-27 > Group: Individual Submission > Pages: 20 > URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-05.txt > Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ > Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-05 > Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-05 > > 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. > > > 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 Tue Feb 28 11:29:55 2017 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 3458A12969F for ; Tue, 28 Feb 2017 11:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 n0CXYc6zJ-B3 for ; Tue, 28 Feb 2017 11:29:47 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 8619F12969C for ; Tue, 28 Feb 2017 11:29:47 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1SJT9bv006978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Feb 2017 11:29:10 -0800 (PST) To: tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> From: Joe Touch Message-ID: <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> Date: Tue, 28 Feb 2017 11:29:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170228163751.GA89477@cowbell.employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 19:29:54 -0000 Hi, Derek, Thank you for the feedback. Below are my responses... Note - one of the caveats is that I'd really like to see this become a WG doc. at some point. I'd prefer to have running code and got very close this past fall (the issue was student cycles, not protocol design), FWIW. Joe On 2/28/2017 8:37 AM, Derek Fawcus wrote: > On Mon, Feb 27, 2017 at 03:30:59p.m. -0800, Joe Touch wrote: >> A new version of the UDP options proposal has been posted. > I quite like the described scheme, a few comments below: > > > Section 5 question on must implement: > > Personally I'd say the most interesting / useful are (in order): > MSS, FRAG, TIME, LITE, ACS, AE > So that would inform my choice of which to make mandatory The set I picked are the minimum required to make the option work. OCS is included because it is default-on, as per previous discussions. I'm glad to have the WG determine what others would be required. IMO, it wouldn't be hard to make MSS, FRAG, TIME, LITE, and ACS required. AE is completely specified (believe it or not - all that was required was to declare the ISN values to substitute for UDP for traffic key generation), but it's also clearly very heavyweight compared to the rest of the options. > Section 5.4 (Alternate checksum): > > By inference one can deduce that 'UDP payload only' > must refer to the data region which figure 3 names as the > 'UDP user data', and hence also excludes any Lite data. > Maybe this (UDP user data) should be explicitly stated? Good point - I'll clarify. It will be the same data covered by the current UDP checksum (UDP header, UDP payload as indicated by the UDP header, and IP pseudoheader). > Also which CRC16? I've seen a few. Maybe state its polynomial? Good point - I don't have a preference, but I'll pick one in common use. > Section 7 (UDP options vs. UDP-Lite): > > 4th para seems to refer to a prior scheme for a LITE > option. Yes - > With the described swap mechanism, there is > no need for an EOL option (for Lite purposes), and > the Lite data ends up directly following the normal > data vs this text stating they are disjoint. Agreed - I'll clean that up. The EOL option still needs to be included (IMO) for similar reasons to the TCP option - to help shortcut option processing when trailer padding is used (e.g., for word-aligned payloads). > So this could be reduced to just the portion comparing > the default delivery (or not) of the Lite data. Agreed. Will do... > Section 5.3 (Option Checksum) > > It looks like the described scheme was needed for > compatibility with a prior version of the Lite > mechanism. This came out of WG discussions, notably because the option area is not covered by the UDP checksum. It predates the inclusion of the Lite mechanism and has no relation. > You could simplify the option checksum handling by > simply defining the first 2 bytes of the surplus > area as a 16 bit checksum over the whole of the > surplus area while in its Figure 10 form, i.e. not > including the Lite data. I agree with the second point (simplified processing), but not the first (requiring OCS), unless we agree that OCS is always required (it is not right now; it is default active, but could be turned off to save space - though I'm not sure why that amount of space would matter). > This would be compatible with the LITE swap scheme > you describe in section 5.5, just with one having > to swap 6 bytes rather than 4 bytes. It would also > take no more space than the existing checksum - assuming > such was always included. It takes two additional bytes - we can't redefine the existing checksum and be compatible with legacy receivers. > I can see that this would make the job of a middle > box which chose to modify an option (say MSS clamping) easier, > but I'd suggest the main gain is simply following > a more familiar scheme of the same 16 bit ones complement > as elsewhere (even if not negated as one usually does). I don't want to design a transport protocol capability based on what a middlebox might do. That's "laws for the lawless", IMO, and there's little point. So I'd rather not address this. > Section 5.1 (End of Options List) > > Given the above change to the options checksum, and the > stale text in section 7, it would seem that there is no > need for the EOL option, and NOP could become 0; however > that probably doesn't matter either way. I'm in favor of keeping EOL because the code to handle it is easy and it might enable other capabilities in the future (i.e., available space after the header). It might be useful to mention that. > Section 5.8 (Fragmentation) > > A trivial point, but should this be referred to a segmentation instead? I'm fine with whatever the WG prefers. > I forsee the confused conversations in future when one is > refering to UDP fragments, or Fragmented UDP and having > to clarify if one means an IP fragment or this transport > level fragmentation scheme. > > Figure 15 shows a 64 bit Identification field, yet the text > refers to a 32 bit field. Which is correct? 32. I think larger isn't needed. I'll fix that... > If fragmentation is present with Lite, and two such packets > are received to be reassembled, what happens to the Lite data > from each packet? Should this combination be rejected, or > defined in some fashion? Good point. I'll think about this and create an ordering list. > I've not really looked at Seciton 5.9, as I'd need to refresh > myself on the TCP option behaviour. OK - glad to have that feedback too. ----- From nobody Tue Feb 28 11:40:14 2017 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 2A8801296A3 for ; Tue, 28 Feb 2017 11:40:13 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 ne-XLDiwh6HV for ; Tue, 28 Feb 2017 11:40:09 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 1C7D21294FD for ; Tue, 28 Feb 2017 11:40:09 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id u188so35201029qkc.2 for ; Tue, 28 Feb 2017 11:40:09 -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; bh=gls8akh8yoc7Kq44v8eLs8yR8O2B6F90ZSpFu1yqlmc=; b=YqrQIFwiUlO5FfaC6tc3+t5ZUQR/eNC2MSKo2J0K1D0EenbE6xrU959+OS+GKuw5Dz xgEsi38JQzyuSuY0REC+QbOODWBrpVlhNj+kHi0M+xo63HTB+I8utOolRBuUIWRF6uMh mP21rG4jN+C/Mk1Swvmw47fEJLUvVYU0k4MvolUkqooExlngoKSlSi5fSfMUB7SjVmHn WZfs4St+/twFrJRWY9c4mC+dI491KmugujYVVqP5cDY0cF6edco0MyAiCc4SO/k3/rG8 ImzrJXajJUT2DeRkxYLifm40pn4xi33hdsMD6k9eq54acxkDaIY9jJyfGf9iyfdyWEFb /Hng== 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; bh=gls8akh8yoc7Kq44v8eLs8yR8O2B6F90ZSpFu1yqlmc=; b=JcODbQW+Jk73Jymczrahi3xAEJUHjDJv8DIgBLKPKCWHb/DjHAz28hoQjcBwvf4QUf 4w46hkOa4LoDu5i6V+FqBClRocSj4XZZ8JTegrtyWU9SWwEUI5RSXYjmv7B1oTMEJXDl NeA7WgsbRCVUSwGY7FfjcNQsHFFzdBfXrpfFtf3CJEpWSovWLSo8+f5FywTiDfYW7+qZ 1+xTWlHPrfv06yt+VAcMdWvHyRr5jJmcRwZxBo1LVLht98QO9+EngYtL8805QD0LBlNX QA42X6W7/DW7hPcjWJE3LK9e2HqH8UYPNIIEfDNrbxvETk7OETjMDwlwab9M7ppR3WBD xmRg== X-Gm-Message-State: AMke39lhmv9S67ZLnIHNDtlcyWLJvLS49KS1eafwPLx97khht/6PCqTTCJwtHeMEW7+osIB0cieCoieGAQAzhA== X-Received: by 10.55.7.7 with SMTP id 7mr2942003qkh.228.1488310808199; Tue, 28 Feb 2017 11:40:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.55.232 with HTTP; Tue, 28 Feb 2017 11:40:07 -0800 (PST) In-Reply-To: <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> From: Tom Herbert Date: Tue, 28 Feb 2017 11:40:07 -0800 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a114c88d80a0f6605499c5ddf Archived-At: Cc: tsvwg Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 19:40:13 -0000 --001a114c88d80a0f6605499c5ddf Content-Type: text/plain; charset=UTF-8 On Mon, Feb 27, 2017 at 3:30 PM, Joe Touch wrote: > Hi, all, > > A new version of the UDP options proposal has been posted. > > It adds: > > - fragmentation based on IPv6's mechanism (thanks to Mark Smith) > > - MSS (thanks to Mark Smith) and TS based on TCP's mechanism > > - auth/encryption based on TCP-AO and its extensions > Hi Joe, You might also want to look at the HMAC for IPv6 SR option for authentication. This method might be more appropriate for connectionless transport. We defined an extension based on it for GUE authentication and are working to generalize the Linux implementation to allow different protocols to use the same authentication mechanism. Tom > It clarifies the report of a non-compliant legacy device (thanks to Mike > Heard). > > It also adds a discussion on control block caching, ala RFC2140 for TCP. > Feedback welcome. > > Joe > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-touch-tsvwg-udp-options-05.txt > Date: Mon, 27 Feb 2017 15:24:32 -0800 > From: internet-drafts@ietf.org > To: Joseph Touch , Joe Touch > > > A new version of I-D, draft-touch-tsvwg-udp-options-05.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. > > Name: draft-touch-tsvwg-udp-options > Revision: 05 > Title: Transport Options for UDP > Document date: 2017-02-27 > Group: Individual Submission > Pages: 20 > URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-05.txt > Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ > Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-05 > Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-05 > > 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. > > > > > 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 > > --001a114c88d80a0f6605499c5ddf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 27, 2017 at 3:30 PM, Joe Touch <touch@isi.edu> w= rote:
=20 =20 =20

Hi, all,

A new version of the UDP options proposal has been posted.

It adds:

=C2=A0=C2=A0=C2=A0 - fragmentation based on IPv6's mechanism (th= anks to Mark Smith)

=C2=A0=C2=A0=C2=A0 - MSS (thanks to Mark Smith) and TS based on TCP&= #39;s mechanism

=C2=A0=C2=A0=C2=A0 - auth/encryption based on TCP-AO and its extensi= ons


Hi Joe,

<= div>You might also want to look at the HMAC for IPv6 SR option for authenti= cation. This method might be more appropriate for connectionless transport.= We defined an extension based on it for GUE authentication and are working= to generalize the Linux implementation to allow different protocols to use= the same authentication mechanism.

Tom
= =C2=A0

It clarifies the report of a non-compliant legacy device (thanks to Mike Heard).

It also adds a discussion on control block caching, ala RFC2140 for TCP.

Feedback wel= come.

Joe

-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tsvwg-udp-options-05.txt
Date: Mon, 27 Feb 2017 15:24:32 -0800
From: internet-drafts= @ietf.org
To: Joseph Touch <touch@isi.ed= u>, Joe Touch <touch@isi.edu> 


A new version of I-D, draft-touch-tsvwg-udp-options-05.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-tsvwg-udp-options
Revision:	05
Title:		Transport Options for UDP
Document date:	2017-02-27
Group:		Individual Submission
Pages:		20
URL:            https://www.ietf.org/internet-drafts/draft-tou=
ch-tsvwg-udp-options-05.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-<=
wbr>options/
Htmlized:       https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-=
05
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-touch-tsv=
wg-udp-options-05

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.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--001a114c88d80a0f6605499c5ddf-- From nobody Tue Feb 28 12:04:16 2017 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 EF9D31296AD for ; Tue, 28 Feb 2017 12:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 HWAAC9LTBvJP for ; Tue, 28 Feb 2017 12:04:13 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 5182E1296AA for ; Tue, 28 Feb 2017 12:04:13 -0800 (PST) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v1SK3xI6017536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Feb 2017 12:04:00 -0800 (PST) To: "C. M. Heard" References: From: Joe Touch Message-ID: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> Date: Tue, 28 Feb 2017 12:03:59 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v1SK3xI6017536 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Mark Smith , tsvwg Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:04:15 -0000 Hi, Mike, On 2/28/2017 10:58 AM, C. M. Heard wrote: > Greetings, > > I am very pleased with the latest version of this draft, and in particular > with the proposed Fragmentation option. It cleanly solves the problem of > providing an optional fragmentation capability in UDP that can be > incrementally deployed. It appears to be a viable way to solve the problem > of fragmented DNSSEC responses getting dropped because of middleboxes > filtering IPv4 or IPv6 fragments. That's a very good point - I'll add that to the discussion of the option. > Application layer solutions have been > proposed (see https://tools.ietf.org/html/draft-muks-dns-message-fragments), > but the current proposal has the advantage that it will work for any > UDP-based protocol. It will work especially well for request-response > protocols such as DNS where the requests typically are small (not requiring > fragmentation) but the responses may be large. To use it, the client sends > the request in an unfragmented UDP datagram but appends a Fragmentation > option with Offset and M both zero. If the server does not support UDP > options, it ignores the trailing option and behaves as it does today. If > the server does support UDP options and the response won't fit in a single > UDP datagram without causing IP layer fragmentation, it transmits the > response in several datagrams, using the UDP fragmentation options. This > will work especially well for IPv6, where the path MTU is guaranteed to be > at least 1280 bytes. > > Back in 2013 several proposals for UDP layer fragmentation surfaced during > a discussion on the 6man list about whether to deprecate IPv6 fragmentation > (one was in https://www.ietf.org/mail-archive/web/ipv6/current/msg18703.html). > None of those proposals solved the problem of incremental deployability, > however, as this one does. Thanks and congratulations for coming up with > an elegant solution. I have to give credit to Mike Smith for suggesting it. > I do have some technical comments to make on the Fragmentation option. > > First, I would like to suggest that the post-reassembly user data length > and optionally a post-reassembly user data checksum appear in the UDP > Fragmentation option. The reason for including a post-reassembly length is > to provide a hint to the implementation how much buffer space to reserve; > in order to be foolproof in the face of packet reordering, this needs to be > in every fragment. The optional post-reassembly checksum would need to be > in at least one Fragmentation option and (like the post-reassembly length) > would have to have be the same if it appeared more than once. Its main > value is that it provides a stronger verification that the reassembly > process was done correctly than the fragment-by-fragment checksum in > the UDP header. I'm thinking now about the ordering of options. I'd really like to allow FRAG to precede others, especially LITE. I see your point about the checksums of the pieces vs. the whole... > Finally, if used in conjunction with the Lite option, it > provides a means to overcome the following issue: > > The Fragmentation option needs to be used with extreme care because > it will present incorrect datagram boundaries to a legacy receiver. > > If the Fragmentation option includes its own post-reassembly checksum, > then a Lite option could be inserted immediately following the UDP > header in each fragment, without loss of functionality. Implementations > that do not support UDP options would see UDP fragments so constructed > as empty UDP datagrams and would discard them, removing the danger of > accidental misinterpretation. Is see how that's useful, but it would also appear to mean we might be able to use LITE twice - once as this trick to hide fragments (which is elegant - thanks!), but also to allow the use of LITE in the final result. I'm not sure whether that makes sense yet, though - if you check to see that the whole thing is there, there's little point in allowing part of the packet to not be checksummed (it already would be). So maybe LITE couples with FRAG only in the way you mention, and no other? > I also have an editorial comment on this option. Figure 15 shows the option > length as 12 bytes and the Identification field length as 8 bytes, while the > text says that the Identification field is 32 bits (4 bytes). This figure > needs to be updated to match the text (whatever that turns out to be) and > it also needs a new caption. Yeah - sorry. That was sloppy of me. I did (FWIW) try to push all the pending updates into the text in about half a day yesterday, so I apologize for it being draftier than it should be. Thanks for pointing that out. > Finally, the text is silent on how Alternate Checksum (ACS) interacts with > the Lite option and with the Fragmentation option. My assumption would be > that ACS covers the entire payload in one datagram, irrespective of the > presence or absence of Lite and Fragmentation, but it would be good to > make this explicit. Absolutely - as I noted, I need to think a little more about this issue and make a recommendation. Glad to hear what others think. AFAICT: OCS covers the header in each fragment ACS, being an alternative to the UDP checksum, covers the UDP user data in each fragment (same as the UDP checksum, so not LITE) As was noted, we might need a total "reassembled" checksum. I'm not clear on whether it makes sense to use LITE with FRAG (except as the trick noted before, to hide fragments from legacy receivers). Joe From nobody Tue Feb 28 12:46:12 2017 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 1DE921296CE for ; Tue, 28 Feb 2017 12:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-tsvwg@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrIO8o_aYWNO for ; Tue, 28 Feb 2017 12:46:08 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 427F21296B6 for ; Tue, 28 Feb 2017 12:46:08 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 28 Feb 2017 20:46:07 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 59FA2D788E; Tue, 28 Feb 2017 12:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=pNXnmr7G37BJSTxwTMk7fIhMTCY=; b=lq +I3Dhy6broXqK7EUaIBialDcWi//wvILAwIRiQFpEwwLGupHWeGyAPCviW3vhhTX x02DiLQrhMflzUs4D3QkjnxUXUKCyRZRnRfbwLzAmqi+7vl4F1XFmSpZdbFogGeh WFj9qloKMLeDdVDOA/IfUOpcWkjSxONzrvlV/cH0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=lmZYOkIi6SEstGRF9eEOqswSi+er FL3oVTwzgYUg/PQAWo9Zoj8kYYDHib8o9RB7hva3+rnMCW6E7phe2q/M5e8n4Jii hs6gD9lCmBygfNmuZDV1B0sWoaSv7jnd498mi26a6VHLsJgAD2Un3xm1fnp2G0s3 P4qE8d+tk7PrnjE= Received: by cowbell.employees.org (Postfix, from userid 1736) id 57AD0D788A; Tue, 28 Feb 2017 12:46:07 -0800 (PST) Date: Tue, 28 Feb 2017 20:46:07 +0000 From: Derek Fawcus To: Joe Touch Message-ID: <20170228204607.GA71184@cowbell.employees.org> Mail-Followup-To: Joe Touch , tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: tsvwg Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:46:10 -0000 On Tue, Feb 28, 2017 at 11:29:09a.m. -0800, Joe Touch wrote: > Note - one of the caveats is that I'd really like to see this become a > WG doc. at some point. Seems like a good idea. > On 2/28/2017 8:37 AM, Derek Fawcus wrote: > > On Mon, Feb 27, 2017 at 03:30:59p.m. -0800, Joe Touch wrote: > > > > Section 5 question on must implement: > > > > Personally I'd say the most interesting / useful are (in order): > > MSS, FRAG, TIME, LITE, ACS, AE > > So that would inform my choice of which to make mandatory Well that was just the order from which I'd chose the mandatory set, I wasn't necessarily suggesting that all be mandatory. For me the suggested mandatory additions would probably be MSS and FRAG, then possibly TIME due to the timing points with reassembly which you mention. > > Section 5.3 (Option Checksum) > > You could simplify the option checksum handling by > > simply defining the first 2 bytes of the surplus > > area as a 16 bit checksum over the whole of the > > surplus area while in its Figure 10 form, i.e. not > > including the Lite data. > I agree with the second point (simplified processing), but not the first > (requiring OCS), unless we agree that OCS is always required (it is not > right now; it is default active, I view requiring it to always be present is a sensible choice as that allows for some level of validation that the surplus area actually is options. As I believe you mention later in the draft. > but could be turned off to save space - > though I'm not sure why that amount of space would matter). Quite. I'd say the cost/benefit weighs in favour of using the space to always have the options summed. > > This would be compatible with the LITE swap scheme > > you describe in section 5.5, just with one having > > to swap 6 bytes rather than 4 bytes. It would also > > take no more space than the existing checksum - assuming > > such was always included. > It takes two additional bytes - we can't redefine the existing checksum > and be compatible with legacy receivers. Sorry, I've lost the thread here. I was not suggesting altering how the normal UDP checksum works. I was mainly driving at how in implementing this in a host stack I'd like to verify the options. Namely that in the absense of the Lite option, it would allow one to use the existing checksum validation routine to run across the whole of the surplus area, and if it summed to the usual (1's complement) zero, it is good. In the presence of Lite option it only becomes slightly more complex, in that one performs the check as two partial sums. This could be combined with whatever logic is extracting/detecting the presence of the options. That would obviously requiring using the usual 1s complement of the 1s complement sum. It would have to occur before normal UDP processing, and be driven off the UDP length and the IP header payload length being different [I'm assuming the presence of a routine like: uint16_t ip_partial_checksum(uint16_t old_sum, void *start, uint16_t length) which sums the supplied range in to the old_sum, returning the new value. Initialisation and final 1s-complement being done outside that routine. ] Or are you referring to existing implementations of your current option code? > I don't want to design a transport protocol capability based on what a > middlebox might do. That's "laws for the lawless", IMO, and there's > little point. So I'd rather not address this. The reference to middle boxes was an unimportant side comment, please forget I mentioned it. The significant point was allowing the same style of checksum as already exists, and hence using the same (or similar) set of routines. Especially since if we assume the checksum is always present, it costs no more in terms of payload that the 8 bit scheme. > > Section 5.1 (End of Options List) > > > > Given the above change to the options checksum, and the > > stale text in section 7, it would seem that there is no > > need for the EOL option, and NOP could become 0; however > > that probably doesn't matter either way. > I'm in favor of keeping EOL because the code to handle it is easy and it > might enable other capabilities in the future (i.e., available space > after the header). It might be useful to mention that. I'm fine either way. > > If fragmentation is present with Lite, and two such packets > > are received to be reassembled, what happens to the Lite data > > from each packet? Should this combination be rejected, or > > defined in some fashion? > Good point. I'll think about this and create an ordering list. Tom's suggestion here was interesting. It would seem to be re-defining the FRAG+LITE case where the UDP User Data is zero length, such that the LITE is now segmented, and non-Lite. I'm not sure about that yet, it feels a bit weird. However, the overall checksum he mentioned could itself be in an option, and would only need to be in one of the fragments. DF From nobody Tue Feb 28 13:07:43 2017 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 4818A129715 for ; Tue, 28 Feb 2017 13:07:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 wjlndIeq6YXN for ; Tue, 28 Feb 2017 13:07:40 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 802CE129713 for ; Tue, 28 Feb 2017 13:07:40 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id n186so37853995qkb.3 for ; Tue, 28 Feb 2017 13:07:40 -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; bh=86teyA18lLVjfHuUzKzUjtJVKwcIj9Stq7er2LvkC68=; b=yjiYMTR2RSlLJtj/4rBPFkNCMvG7ryuHonf2Lw/dV4L7DiAecFrW98bpnJutPdyg42 XOmErbZukcTx0abd2tZ4XduKn6gekd42S8PBASdUtVg1qp+5bgSuf8DKGBJrEwVEYTeL eGvSsK0S5EHTPkLRtZnntSh8Atgs2KXdHfQqhZKtzPMWVVqaWbWaN9EXT5W2Du4soca7 UBQ2kS4hg25XJzESk+o7IIHtX8o9m0Nz90CU68iVbUnqIMyj9n2N7fEyEb7OHzN7ngHK qi08M9KeQENauhsvxmL5ay5ee89AxRsdtJ1Sk5zgYjva8s6KZvsOaZIPasJQmJLTIBkY B0zg== 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=86teyA18lLVjfHuUzKzUjtJVKwcIj9Stq7er2LvkC68=; b=ZaCcSfLGsZ/Rk0yawUfoIuzyHa05yF0kmpo0OzoDkKgIDGVLlKqUR7aOHLq/UwFQi9 Ydr73p5QG/ipcgpQeExb9fThMKdws5mxorvQPIHJBRGJmENsi/OsgfbI6aaQQDr4Bg+P zK0sq3sEnDgqzrT2qkK8mNIM+I2ZlkZ7GWDI7NfJ9Dk3nTpQEN/RieTrI3yY+3XvLCTI oPdOa+Ydkgbk6hY9xlwa4ULv6is3aE0LLYu116+7f1iwxLDC6hRKP7f6wHOog8PTtoYf YGdZEt2reKktJf/vWsxGR2bOIF2ln8v/IA+69enWEzqh1viNMqX0/4uyTzVO2pXIiGy3 AhBw== X-Gm-Message-State: AMke39n+bmIqWn1Jw4p6nv67Hb6uZS6i6hx765qjLMpNSCPVFq6T9gmu51X5LJw/xb9fysWVYnH3vmyg5BgjFw== X-Received: by 10.237.51.5 with SMTP id u5mr5699392qtd.247.1488316059324; Tue, 28 Feb 2017 13:07:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.55.232 with HTTP; Tue, 28 Feb 2017 13:07:38 -0800 (PST) In-Reply-To: <20170228204607.GA71184@cowbell.employees.org> References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> <20170228204607.GA71184@cowbell.employees.org> From: Tom Herbert Date: Tue, 28 Feb 2017 13:07:38 -0800 Message-ID: To: Joe Touch , tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:07:42 -0000 On Tue, Feb 28, 2017 at 12:46 PM, Derek Fawcus wrote: > On Tue, Feb 28, 2017 at 11:29:09a.m. -0800, Joe Touch wrote: >> Note - one of the caveats is that I'd really like to see this become a >> WG doc. at some point. > > Seems like a good idea. > >> On 2/28/2017 8:37 AM, Derek Fawcus wrote: >> > On Mon, Feb 27, 2017 at 03:30:59p.m. -0800, Joe Touch wrote: >> > >> > Section 5 question on must implement: >> > >> > Personally I'd say the most interesting / useful are (in order): >> > MSS, FRAG, TIME, LITE, ACS, AE >> > So that would inform my choice of which to make mandatory > > Well that was just the order from which I'd chose the mandatory set, > I wasn't necessarily suggesting that all be mandatory. > > For me the suggested mandatory additions would probably be MSS and FRAG, > then possibly TIME due to the timing points with reassembly which > you mention. > >> > Section 5.3 (Option Checksum) > >> > You could simplify the option checksum handling by >> > simply defining the first 2 bytes of the surplus >> > area as a 16 bit checksum over the whole of the >> > surplus area while in its Figure 10 form, i.e. not >> > including the Lite data. >> I agree with the second point (simplified processing), but not the first >> (requiring OCS), unless we agree that OCS is always required (it is not >> right now; it is default active, > > I view requiring it to always be present is a sensible choice > as that allows for some level of validation that the surplus > area actually is options. As I believe you mention later > in the draft. > >> but could be turned off to save space - >> though I'm not sure why that amount of space would matter). > > Quite. I'd say the cost/benefit weighs in favour of using > the space to always have the options summed. > >> > This would be compatible with the LITE swap scheme >> > you describe in section 5.5, just with one having >> > to swap 6 bytes rather than 4 bytes. It would also >> > take no more space than the existing checksum - assuming >> > such was always included. >> It takes two additional bytes - we can't redefine the existing checksum >> and be compatible with legacy receivers. > > Sorry, I've lost the thread here. > > I was not suggesting altering how the normal UDP checksum works. > > I was mainly driving at how in implementing this in a host stack I'd > like to verify the options. Namely that in the absense of the Lite > option, it would allow one to use the existing checksum validation > routine to run across the whole of the surplus area, and if it summed > to the usual (1's complement) zero, it is good. > > In the presence of Lite option it only becomes slightly more complex, > in that one performs the check as two partial sums. > > This could be combined with whatever logic is extracting/detecting > the presence of the options. That would obviously requiring using > the usual 1s complement of the 1s complement sum. It would have > to occur before normal UDP processing, and be driven off the UDP > length and the IP header payload length being different > > [I'm assuming the presence of a routine like: > uint16_t ip_partial_checksum(uint16_t old_sum, void *start, uint16_t length) > which sums the supplied range in to the old_sum, returning the new value. > Initialisation and final 1s-complement being done outside that routine. > ] > > > Or are you referring to existing implementations of your current > option code? > >> I don't want to design a transport protocol capability based on what a >> middlebox might do. That's "laws for the lawless", IMO, and there's >> little point. So I'd rather not address this. > > The reference to middle boxes was an unimportant side comment, > please forget I mentioned it. > > The significant point was allowing the same style of checksum > as already exists, and hence using the same (or similar) > set of routines. Especially since if we assume the checksum > is always present, it costs no more in terms of payload that > the 8 bit scheme. > Agreed, probably want to stick with the normal 16-bit Internet checksum it will probably be more efficient since we've optimized implementation of that anyway. >> > Section 5.1 (End of Options List) >> > >> > Given the above change to the options checksum, and the >> > stale text in section 7, it would seem that there is no >> > need for the EOL option, and NOP could become 0; however >> > that probably doesn't matter either way. >> I'm in favor of keeping EOL because the code to handle it is easy and it >> might enable other capabilities in the future (i.e., available space >> after the header). It might be useful to mention that. > > I'm fine either way. > >> > If fragmentation is present with Lite, and two such packets >> > are received to be reassembled, what happens to the Lite data >> > from each packet? Should this combination be rejected, or >> > defined in some fashion? >> Good point. I'll think about this and create an ordering list. > > Tom's suggestion here was interesting. It would seem to be > re-defining the FRAG+LITE case where the UDP User Data is zero length, > such that the LITE is now segmented, and non-Lite. I'm not sure > about that yet, it feels a bit weird. > > However, the overall checksum he mentioned could itself be in an > option, and would only need to be in one of the fragments. > Pretty much all NICs now days can set/verify UDP checksums on TX/RX so we basically get it for free. This is why I doubt we'll ever see UDP-lite in real deployment-- it is far less efficient than using the UDP checksum. In a similar vein, applying a checksum over a packet that is then fragmented is not easily supported in HW, for TX it requires TSO logic for RX we might be able to deduce the reassembled checksum from the checksummed individual fragments but it's a lot of work. I think the LITE functionality is probably here for completeness. CRC might be more interesting though. Tom From nobody Tue Feb 28 13:16:33 2017 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 AA13D1296CD for ; Tue, 28 Feb 2017 13:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ART7OxGtDwVn for ; Tue, 28 Feb 2017 13:16:26 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 DDCFF124281 for ; Tue, 28 Feb 2017 13:16:26 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v1SLG76Q029823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Feb 2017 13:16:07 -0800 (PST) To: tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> <20170228204607.GA71184@cowbell.employees.org> From: Joe Touch Message-ID: Date: Tue, 28 Feb 2017 13:16:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170228204607.GA71184@cowbell.employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-MailScanner-ID: v1SLG76Q029823 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:16:33 -0000 Hi Derek, On 2/28/2017 12:46 PM, Derek Fawcus wrote: > ... >>> Section 5.3 (Option Checksum) > ... >>> This would be compatible with the LITE swap scheme >>> you describe in section 5.5, just with one having >>> to swap 6 bytes rather than 4 bytes. It would also >>> take no more space than the existing checksum - assuming >>> such was always included. >> It takes two additional bytes - we can't redefine the existing checksu= m >> and be compatible with legacy receivers. > Sorry, I've lost the thread here. > > I was not suggesting altering how the normal UDP checksum works. > > I was mainly driving at how in implementing this in a host stack I'd > like to verify the options. Namely that in the absense of the Lite > option, it would allow one to use the existing checksum validation > routine to run across the whole of the surplus area, and if it summed > to the usual (1's complement) zero, it is good. I'm not sure I see that. The existing checksum runs over the IP pseudoheader, the UDP header, and the UDP body. OCS runs over just the option area. Even in the absence of LITE, the UDP checksum wouldn't cover the option area. > In the presence of Lite option it only becomes slightly more complex, > in that one performs the check as two partial sums. > > This could be combined with whatever logic is extracting/detecting > the presence of the options. That would obviously requiring using > the usual 1s complement of the 1s complement sum. It would have > to occur before normal UDP processing, and be driven off the UDP > length and the IP header payload length being different > > [I'm assuming the presence of a routine like: > uint16_t ip_partial_checksum(uint16_t old_sum, void *start, uint16_t= length) > which sums the supplied range in to the old_sum, returning the new val= ue. > Initialisation and final 1s-complement being done outside that routine= =2E > ] > > > Or are you referring to existing implementations of your current > option code? The spec. There are two checksum options: OCS - over just the option area ACS - a stronger replacement for the UDP checksum over the same area as the UDP checksum carries (though it might need to just be the body, since a NAT is going to mess up the IP pseudoheader and UDP ports) > >> I don't want to design a transport protocol capability based on what a= >> middlebox might do. That's "laws for the lawless", IMO, and there's >> little point. So I'd rather not address this. > The reference to middle boxes was an unimportant side comment, > please forget I mentioned it. > > The significant point was allowing the same style of checksum > as already exists, and hence using the same (or similar) > set of routines. Especially since if we assume the checksum > is always present, it costs no more in terms of payload that > the 8 bit scheme. The offload routines could be adapted to handle this, sure. >>> If fragmentation is present with Lite, and two such packets >>> are received to be reassembled, what happens to the Lite data >>> from each packet? Should this combination be rejected, or >>> defined in some fashion? >> Good point. I'll think about this and create an ordering list. > Tom's suggestion here was interesting. It would seem to be > re-defining the FRAG+LITE case where the UDP User Data is zero length, > such that the LITE is now segmented, and non-Lite. I'm not sure > about that yet, it feels a bit weird. > > However, the overall checksum he mentioned could itself be in an > option, and would only need to be in one of the fragments. Right - that would be reassembly verification checksum. Joe From nobody Tue Feb 28 13:17:32 2017 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 73015129739 for ; Tue, 28 Feb 2017 13:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 5sBu9KhQC240 for ; Tue, 28 Feb 2017 13:17:28 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 66E8B129736 for ; Tue, 28 Feb 2017 13:17:28 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v1SLHGgx000469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Feb 2017 13:17:16 -0800 (PST) To: Tom Herbert , tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> <20170228204607.GA71184@cowbell.employees.org> From: Joe Touch Message-ID: Date: Tue, 28 Feb 2017 13:17:16 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v1SLHGgx000469 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:17:31 -0000 Hi, Tom, OK - so I think you and Derek are basically arguing for an Internet checksum to verify reassembly, rather than using a new or stronger one. That's fine with me. Joe From nobody Tue Feb 28 13:36:24 2017 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 E88CB1296CB for ; Tue, 28 Feb 2017 13:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-tsvwg@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4RViWyxvDPY for ; Tue, 28 Feb 2017 13:36:21 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id A83CA126D73 for ; Tue, 28 Feb 2017 13:36:21 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 28 Feb 2017 21:36:20 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 96F31D7890; Tue, 28 Feb 2017 13:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=c+FR1gGvpd9RlzO7E0sKFr7SVE8=; b=eS SJ0fXOu4xIUpmVl+B1InqTj5UK6HyLu4Aoa6GOVnIKJRUCcKvPgxK4hBYQBelcw9 mN0MT6X+Mm/TbeQvMqwmiqDZ6a00VY2XGXNCy4uacBWm847+QY2AuaYizvya7hNL +IrfRTdg/65nZHLOoQGpiSXA9S0n/gKsrz1NWinH4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=aByewJltuF+1WNESixT26yRf+Nsc a6cu36SRZSDLRyAKFvzL8zXnibzBahp5lSOEX30KziwD4icblAsBvGMqbRK3S4mj EtoqiR/cZKOVsIctIsAxffKaFLQY9mHe23lfjMPM3E/yW9kwEwjhu94SfJOxC+ME sOCslmu6so4pzlM= Received: by cowbell.employees.org (Postfix, from userid 1736) id 91256D788F; Tue, 28 Feb 2017 13:36:20 -0800 (PST) Date: Tue, 28 Feb 2017 21:36:20 +0000 From: Derek Fawcus To: Joe Touch Message-ID: <20170228213620.GA4674@cowbell.employees.org> Mail-Followup-To: Joe Touch , tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> <20170228204607.GA71184@cowbell.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: tsvwg Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:36:23 -0000 On Tue, Feb 28, 2017 at 01:16:07p.m. -0800, Joe Touch wrote: > > Sorry, I've lost the thread here. > > > > I was not suggesting altering how the normal UDP checksum works. > > > > I was mainly driving at how in implementing this in a host stack I'd > > like to verify the options. Namely that in the absense of the Lite > > option, it would allow one to use the existing checksum validation > > routine to run across the whole of the surplus area, and if it summed > > to the usual (1's complement) zero, it is good. > I'm not sure I see that. > The existing checksum runs over the IP pseudoheader, the UDP header, and > the UDP body. > > OCS runs over just the option area. > > Even in the absence of LITE, the UDP checksum wouldn't cover the option > area. We're at cross purposes here... I'm not suggesting altering the UDP checksum, I'm referring to replacing (discarding) the OCS option. So in section 4, figure 3 where you describe the surplus area, which is essentially an array of bytes used for options. I'm proposing instead to give it a structure: +------+-------+ | checksum | +------+-------+ ... options ... +------+-------+ Where options is zero or more options as you describe (omitting OCS). Where checksum is the usual checksum algorith over the whole of the surplus area. i.e. such that when the receiver sums the whole of the area checksum through to the end of options, it should sum to 1s-complement zero. (taking in to consideration the length of options being odd). Then for your LITE header scheme, still require that the LITE header be the first option, and rather than swap 4 bytes (the LITE header) as you describe, instead swap 6 bytes (the checksum followed by the LITE header). Hence why I was the referring to partial sums. DF From nobody Tue Feb 28 13:46:51 2017 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 BE16612973E for ; Tue, 28 Feb 2017 13:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=dfawcus+lists-tsvwg@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YY0uIY3Xo_aW for ; Tue, 28 Feb 2017 13:46:48 -0800 (PST) Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD641296D2 for ; Tue, 28 Feb 2017 13:46:48 -0800 (PST) Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 28 Feb 2017 21:46:48 +0000 Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 392D9D788B; Tue, 28 Feb 2017 13:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=bzkTzIY0VJ3V3+XA4UTeqtjIE4Y=; b=Dx rTer7DGFNlkR2Gq22GwNvcYy6+yIbswJt/iVN3SKGvtoDK/UW0EeqVtbtK15DXIw LDsjKhL690+EDK0OMdWv7/Iezmp0/2N6x5yOJjHCwiL4i7VCfE71dBxHzhBcnGis EtIoEb4FXB0CVt1n9dE5c1siGERcUjj8czdgfw2+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:cc:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=Bg7J64CLnYqmZ+dJMHWur44+sL6Z 3pRe0s+qFb79ijxVDH/ULvc86ry2dOOAqJTZavey4l2KMvdotqXFbpMXl4mmmY8u dWmu9m5q9whepgls9Qe8Ea8nUuYlUtya0eVnYdE/e6y+G1ZAQ/V9NE1KzcjmNDOa P1DrQGE6zZEJfUk= Received: by cowbell.employees.org (Postfix, from userid 1736) id 2DF83D788A; Tue, 28 Feb 2017 13:46:48 -0800 (PST) Date: Tue, 28 Feb 2017 21:46:48 +0000 From: Derek Fawcus To: Joe Touch Message-ID: <20170228214648.GB4674@cowbell.employees.org> Mail-Followup-To: Joe Touch , Tom Herbert , tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> <20170228204607.GA71184@cowbell.employees.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Cc: tsvwg Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:46:50 -0000 On Tue, Feb 28, 2017 at 01:17:16p.m. -0800, Joe Touch wrote: > Hi, Tom, > > OK - so I think you and Derek are basically arguing for an Internet > checksum to verify reassembly, rather than using a new or stronger one. Actually, I made a mistake. I attributed to Tom what was I believe was actually suggested by C. M. Heard - namely the suggestion to combine FRAG+LITE as a way of allowing existing hosts to discard fragments. In that he was suggesting adding an overall reassembled checksum, which would be necessary as otherwise the repurposed reassembled Lite payloads would not have a checksum. I was simply pointing out that in that scenario, the same could be achieved with a single CHECKSUM option, carried in only one of the FRAG packets. So there would be no need to change the FRAG header definiton to add a checksum there. In the normal case of reassembling FRAG'ed payloads, I don't see that an overall checksum gains us anything. Possibly an overall CRC would have some value? That would seem to require a second type of ACS-like option, i.e REASSEMBLE-ACS? Again it would only need to be sent with only one of the FRAG containing packets. Is such an addition worth it? DF From nobody Tue Feb 28 14:18:52 2017 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 AB4011293DF for ; Tue, 28 Feb 2017 14:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 CLG1C-4uxxWr for ; Tue, 28 Feb 2017 14:18:49 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 9BAB3128AC9 for ; Tue, 28 Feb 2017 14:18:49 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v1SMIXUN012168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Feb 2017 14:18:33 -0800 (PST) To: Tom Herbert , tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> <20170228204607.GA71184@cowbell.employees.org> <20170228214648.GB4674@cowbell.employees.org> From: Joe Touch Message-ID: <2cb0255e-9ead-e42e-4252-b66c1aee06ba@isi.edu> Date: Tue, 28 Feb 2017 14:18:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170228214648.GB4674@cowbell.employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-MailScanner-ID: v1SMIXUN012168 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:18:50 -0000 Hi, Derek, On 2/28/2017 1:46 PM, Derek Fawcus wrote: > On Tue, Feb 28, 2017 at 01:17:16p.m. -0800, Joe Touch wrote: >> Hi, Tom, >> >> OK - so I think you and Derek are basically arguing for an Internet >> checksum to verify reassembly, rather than using a new or stronger one= =2E > Actually, I made a mistake. I attributed to Tom what was I believe > was actually suggested by C. M. Heard - namely the suggestion to > combine FRAG+LITE as a way of allowing existing hosts to discard fragme= nts. > > In that he was suggesting adding an overall reassembled checksum, > which would be necessary as otherwise the repurposed reassembled > Lite payloads would not have a checksum. I was simply pointing > out that in that scenario, the same could be achieved with a > single CHECKSUM option, carried in only one of the FRAG packets. It matters whether the options are considered to apply before or after reassembly. The trick is what is being reassembled - is it the UDP payload only or something larger? Again, I need to think about this a little more. I'd really like to stick to something simple. > So there would be no need to change the FRAG header definiton to > add a checksum there. > > In the normal case of reassembling FRAG'ed payloads, I don't see > that an overall checksum gains us anything. > > Possibly an overall CRC would have some value? That would seem to > require a second type of ACS-like option, i.e REASSEMBLE-ACS? > Again it would only need to be sent with only one of the FRAG > containing packets. Is such an addition worth it? The two options are: - add a checksum inside the FRAG option that applies the reassembled whol= e - define the options in such a way that some apply before reassembly (e.g., before each FRAG option in each received UDP packet) and some apply after (we'd have to be careful in defining what is created as a result. The second variant is cleaner if there's a way to do it. However we have some possibly conflicting issues: - OCS clearly ought to apply for each fragment (otherwise you might err in reassembly and wait too long to catch it) - AE should apply to each fragment (same rule as OCS - you have enough info to prevent an attack on reassembly) - ACS would usefully apply after reassembly - FRAG shouldn't appear more than once - TIME is useful only before FRAG - MSS is useful only before FRAG (and we might want two different MSS values - the conventional MSS and a UDP reassembly MSS!) =20 Again, this deserves a bit more digestion... Joe - From nobody Tue Feb 28 14:19:25 2017 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 04A5B12956B for ; Tue, 28 Feb 2017 14:19:23 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 bGnc8IJQmuCG for ; Tue, 28 Feb 2017 14:19:22 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9872B12706D for ; Tue, 28 Feb 2017 14:19:20 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id s186so41791675qkb.1 for ; Tue, 28 Feb 2017 14:19:20 -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; bh=D9kgdaJFQ6hHmh0vkJBo0zbzNLkNtZXh/EpJOjK1C2w=; b=ARrnuaa+tmr8O/TTdK+MksKSm4mdBSU/FxmOP/VnYy/T2sPUIx/e1CJdJeu+BcDfHP L0Aib6zpPon1IDSs5RO5nXuQdaVOjGBn9oAKV/qx3dOjzF+rs2Qwonkos7bQO0ulM85h Yhx/qrI1tinSJhw9priCkrxiUP6LTjwiljqZvhdh8LZN/kT1b6xRJr1BuHOHMTU0iEJ8 DKHFG2GLTDFeFJOg2Hu+zeL7YO0pOy9OL5YfNhGIfW403nTvfwalfyNBFVYqMU5Fpu3X RzgBtf8FiUqHhWZfZ2jewjDNzVElndsfmc1ib/az0U7ZfRz7ayZUBEOclNqDRspXP81h cuVw== 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=D9kgdaJFQ6hHmh0vkJBo0zbzNLkNtZXh/EpJOjK1C2w=; b=iOQgi2Bq8jPISmQxdrnwnYvkKaAvm2gM+z7iSZmSN+6LFjgPCiJgr8ahbViBGzDFig UGppcPrdyhGYZ6U8eM+rCMMK/1v6qA9JGPdVL7fhIEBO+qP0bOCc16MWs4LplyeeHnTr B0FizYEqtQwcLpXkriH7LtXrwSZdfBV7S+qeiwVDPplHFAGR+eEMYSDtefeRsLXfgpKY 4osPnr17V6dpMvTzYZ4mRbgGrH+S7WqjZ6maFuhAIu15kHAmL5oRgYOm2pltH60otkvz QRdqlAseGzs6AtZ5FaUfHkrWmdaWO07002Jqk+BfPhpXFkwo9P9NXbaQODFEmXURhnax 7h8g== X-Gm-Message-State: AMke39nXYcQTM2JHyuB9Q6YNSc8SKGx1rFqA/raCLTZb3bLm/SlaB/kj10ANmxZ3Pt1Xja87iLmwuOSCDxQFUg== X-Received: by 10.237.59.186 with SMTP id r55mr6341701qte.25.1488320359652; Tue, 28 Feb 2017 14:19:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.55.232 with HTTP; Tue, 28 Feb 2017 14:19:18 -0800 (PST) In-Reply-To: <20170228214648.GB4674@cowbell.employees.org> References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> <20170228204607.GA71184@cowbell.employees.org> <20170228214648.GB4674@cowbell.employees.org> From: Tom Herbert Date: Tue, 28 Feb 2017 14:19:18 -0800 Message-ID: To: Joe Touch , Tom Herbert , tsvwg Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:19:23 -0000 On Tue, Feb 28, 2017 at 1:46 PM, Derek Fawcus wrote: > On Tue, Feb 28, 2017 at 01:17:16p.m. -0800, Joe Touch wrote: >> Hi, Tom, >> >> OK - so I think you and Derek are basically arguing for an Internet >> checksum to verify reassembly, rather than using a new or stronger one. > > Actually, I made a mistake. I attributed to Tom what was I believe > was actually suggested by C. M. Heard - namely the suggestion to > combine FRAG+LITE as a way of allowing existing hosts to discard fragments. > > In that he was suggesting adding an overall reassembled checksum, > which would be necessary as otherwise the repurposed reassembled > Lite payloads would not have a checksum. I was simply pointing > out that in that scenario, the same could be achieved with a > single CHECKSUM option, carried in only one of the FRAG packets. > > So there would be no need to change the FRAG header definiton to > add a checksum there. > > In the normal case of reassembling FRAG'ed payloads, I don't see > that an overall checksum gains us anything. > > Possibly an overall CRC would have some value? That would seem to > require a second type of ACS-like option, i.e REASSEMBLE-ACS? > Again it would only need to be sent with only one of the FRAG > containing packets. Is such an addition worth it? > I would guess not. I think from an implementation point of view it's almost always better to perform integrity checks, authentication, encryption, or any other packet transforms over each individual fragment. If necessary, fragmentation might include it's on integrity check at reassembly but that might only be over few fields in each fragment not over all the data. This is how we defined processing order in GUE fragmentation occurs before other options are set so that the other options (auth, csum, etc.) are applied per fragment; receiver processes all other options before attempting reassembly. Tom From nobody Tue Feb 28 14:20:16 2017 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 E0F34128DF6 for ; Tue, 28 Feb 2017 14:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 8qCSdf5Szwm4 for ; Tue, 28 Feb 2017 14:20:14 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 E4BB3128AC9 for ; Tue, 28 Feb 2017 14:20:13 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v1SMK6xL012826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Feb 2017 14:20:07 -0800 (PST) To: tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> <20170228204607.GA71184@cowbell.employees.org> <20170228213620.GA4674@cowbell.employees.org> From: Joe Touch Message-ID: <20c0adc2-816a-0a92-8bc4-3b890c896eb3@isi.edu> Date: Tue, 28 Feb 2017 14:20:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170228213620.GA4674@cowbell.employees.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v1SMK6xL012826 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:20:15 -0000 Hi, Derek, On 2/28/2017 1:36 PM, Derek Fawcus wrote: > On Tue, Feb 28, 2017 at 01:16:07p.m. -0800, Joe Touch wrote: >>> Sorry, I've lost the thread here. >>> >>> I was not suggesting altering how the normal UDP checksum works. >>> >>> I was mainly driving at how in implementing this in a host stack I'd >>> like to verify the options. Namely that in the absense of the Lite >>> option, it would allow one to use the existing checksum validation >>> routine to run across the whole of the surplus area, and if it summed >>> to the usual (1's complement) zero, it is good. >> I'm not sure I see that. >> The existing checksum runs over the IP pseudoheader, the UDP header, and >> the UDP body. >> >> OCS runs over just the option area. >> >> Even in the absence of LITE, the UDP checksum wouldn't cover the option >> area. > We're at cross purposes here... > > I'm not suggesting altering the UDP checksum, I'm referring to replacing > (discarding) the OCS option. > > So in section 4, figure 3 where you describe the surplus area, which is > essentially an array of bytes used for options. I'm proposing instead to > give it a structure: > > +------+-------+ > | checksum | > +------+-------+ > ... options ... > +------+-------+ > > Where options is zero or more options as you describe (omitting OCS). We discussed that before. The issue is whether OCS is optional or not. If it isn't, yes - it can come first as you note. > Where checksum is the usual checksum algorith over the whole of the > surplus area. i.e. such that when the receiver sums the whole of the > area checksum through to the end of options, it should sum to 1s-complement > zero. (taking in to consideration the length of options being odd). > > Then for your LITE header scheme, still require that the LITE header > be the first option, and rather than swap 4 bytes (the LITE header) > as you describe, instead swap 6 bytes (the checksum followed by the > LITE header). Hence why I was the referring to partial sums. I see now. Yes, that's another possibility. It depends on what the WG wants in terms of whether OCS is optional or not. Joe From nobody Tue Feb 28 14:21:56 2017 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 4CF701295CC for ; Tue, 28 Feb 2017 14:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 7CivF2pHFVWG for ; Tue, 28 Feb 2017 14:21:54 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 3DB67128AC9 for ; Tue, 28 Feb 2017 14:21:54 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v1SMLTWi015074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Feb 2017 14:21:29 -0800 (PST) To: Tom Herbert , tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> <20170228204607.GA71184@cowbell.employees.org> <20170228214648.GB4674@cowbell.employees.org> From: Joe Touch Message-ID: <58848ac9-3b90-1c39-8f69-7d439bc90d2b@isi.edu> Date: Tue, 28 Feb 2017 14:21:29 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-MailScanner-ID: v1SMLTWi015074 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:21:55 -0000 Hi, Tom, The issue of whether a reassembled unit should have an integrity checksum depends on whom you ask. SEAL/AERO include one, but other protocols do not. Again, I'm open to figuring this out. I'd like a lightweight solution where possible, of course. Joe On 2/28/2017 2:19 PM, Tom Herbert wrote: > On Tue, Feb 28, 2017 at 1:46 PM, Derek Fawcus > wrote: >> On Tue, Feb 28, 2017 at 01:17:16p.m. -0800, Joe Touch wrote: >>> Hi, Tom, >>> >>> OK - so I think you and Derek are basically arguing for an Internet >>> checksum to verify reassembly, rather than using a new or stronger one. >> Actually, I made a mistake. I attributed to Tom what was I believe >> was actually suggested by C. M. Heard - namely the suggestion to >> combine FRAG+LITE as a way of allowing existing hosts to discard fragments. >> >> In that he was suggesting adding an overall reassembled checksum, >> which would be necessary as otherwise the repurposed reassembled >> Lite payloads would not have a checksum. I was simply pointing >> out that in that scenario, the same could be achieved with a >> single CHECKSUM option, carried in only one of the FRAG packets. >> >> So there would be no need to change the FRAG header definiton to >> add a checksum there. >> >> In the normal case of reassembling FRAG'ed payloads, I don't see >> that an overall checksum gains us anything. >> >> Possibly an overall CRC would have some value? That would seem to >> require a second type of ACS-like option, i.e REASSEMBLE-ACS? >> Again it would only need to be sent with only one of the FRAG >> containing packets. Is such an addition worth it? >> > I would guess not. I think from an implementation point of view it's > almost always better to perform integrity checks, authentication, > encryption, or any other packet transforms over each individual > fragment. If necessary, fragmentation might include it's on integrity > check at reassembly but that might only be over few fields in each > fragment not over all the data. This is how we defined processing > order in GUE fragmentation occurs before other options are set so that > the other options (auth, csum, etc.) are applied per fragment; > receiver processes all other options before attempting reassembly. > > Tom From nobody Tue Feb 28 14:52:08 2017 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 EAA18129415 for ; Tue, 28 Feb 2017 14:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 1ze0WOwgCRuG for ; Tue, 28 Feb 2017 14:52:05 -0800 (PST) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 DABA612940E for ; Tue, 28 Feb 2017 14:52:05 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v1SMpdCC008641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Feb 2017 14:51:39 -0800 (PST) To: tsvwg References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> <20170228163751.GA89477@cowbell.employees.org> <7d58ead9-2d1a-d35c-7cd2-90526918838c@isi.edu> <20170228204607.GA71184@cowbell.employees.org> <20170228214648.GB4674@cowbell.employees.org> <58848ac9-3b90-1c39-8f69-7d439bc90d2b@isi.edu> From: Joe Touch Message-ID: <489f9fd5-b085-260e-bbcd-42ae5b0dc328@isi.edu> Date: Tue, 28 Feb 2017 14:51:39 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <58848ac9-3b90-1c39-8f69-7d439bc90d2b@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-MailScanner-ID: v1SMpdCC008641 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [tsvwg] summary of issues for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:52:07 -0000 Hi, all, Thanks for the lively discussion! I hope this bodes well for accepting this as a WG doc. Again, I'd prefer if I had deployable running code, but we do have multiple implementations that worked, just not ready for prime time. Here's a quick summary of the issues just raised, both for me (for the next edit) and in case any new issues are of interest. Please do let me know if I missed or incorrectly summarized anything below... Thanks! Joe ----------------------------------------------------- Editorial: - fix Identification field length in Fig 15v s. text (should be 32 bits) ----------------------------------------------------- Use cases: - add DNSSEC impact on segment size and IP fragment problems with network traversal add ref to draft-muks-dns-message-fragments app-layer solution note that FRAG works well when request is small because it can indicate FRAG support for large response - discuss impact to UDP API who sets these? OS or app? which ones are transparent? which are NOT? ----------------------------------------------------- Option design: FRAG: - should FRAG have a reassembly checksum? - should FRAG have a post-reassembly length verification? - use LITE to support backwards transparent FRAG (thanks, C. M.=20 Heard!) (if so, need final reassembly checksum!) - what happens if LITE and FRAG are present with non-trivial covered/not-covered areas? - rename "segmentation" to avoid confusion with IP layer mechanism? (or is SAR too overloaded with ATM?) ACS: - address ACS interaction with LITE and FRAG (ACS covers UDP payload, but NOT IP or UDP header except len?) - clarify ACS covers each received UDP segment or fragment, NOT reassembled result - indicate which CRC-16 polynomial OCS: - clarify OCS covers header within each received UDP segment or fragment, NOT reassembled result - should OCS be mandatory, and if so, make it just the UDP checksum on the option area? LITE - revise Sec 7 vs. UDP Lite and omit EOL discussion (not relevant given new swap mechanism) EOL - explain possible uses (given removal from Section 7) - if removed, consider changing NOP to 0 Another security option? - HMAC for IPv6 SR option(see Tom Herbert's GUE variant) ALL (general): - revisit MUST IMPLEMENT list (add MSS, FRAG, TIME?) - create a list of required ordering OCS first (always) AE next (if it appears) TIME, MSS FRAG (last? otherwise security/safety mechanisms wouldn't protect the reassembly process?) ----------------------------------------------------- From nobody Tue Feb 28 15:02:28 2017 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 449AF1297C2 for ; Tue, 28 Feb 2017 15:02:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 REakIg4orB7Q for ; Tue, 28 Feb 2017 15:02:26 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 B77791297BC for ; Tue, 28 Feb 2017 15:02:25 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id n186so42144270qkb.3 for ; Tue, 28 Feb 2017 15:02:25 -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; bh=j3sltFUaULLJQAgQNA9LJ1MhregnpM6wLPUEd2ddq3M=; b=dBo2YlVDG34hQr6RNMdqL9nwYR3YPJcoVEWjSi8Zn+vhIuXoEJfZHbz79zaGcYNzpN zYCns8PBUYqtZ/AHYutjiLq9IHX/cNuui1wIiUcAIFxa8/E8vLt577W02bazVB5+kMrF xlgRO+auam0K6YyQ/rRvklyAphiDJAwd6UGVFCIqT/7c+eObRzs1BQQ5yoC/DIqRBaMB zIyj0uO/s0oRga/Wh1unnRKsN3M1YmXxsYLti7XjVl4iLwqQTamKL49C31xBgelutq7I V2HAhcuSw3YQFfM9VouqAE3AnBsUhTLTWBd0qrXWCXAC8n7v7AJximVvjDZp2gR8TZX7 oIbg== 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; bh=j3sltFUaULLJQAgQNA9LJ1MhregnpM6wLPUEd2ddq3M=; b=U4vpyPcQzQt/sHMi9ibP6oX2h2C4y98qL5NuTHaE+QvAw4B5P20gxtlxsUQ3n2nY34 zR3KVCeMHHlkFB6xfSfbX3Swr4zWW0X0cWKZyyLH01d0oHyTqqfzwbGnqJg9cYOEvX+F kh9py9ajX/SlrCCEMdDXnC0dh1+Yf4NZVUEgfZJF3LhOLLZ/WME6y0juN7XnttRS5wa0 URykDMDi0he87KntzA+gbc16BEUyB1r/AMZkrYko5FIIHxp4FV09BsrjWHz47uZguVUn Z19OYZ4mgiCybNm5fznx7+44mKKORn8wbQSp7l5M7kSK+SkYr/dtRc0yVGLq1cr2b15n pjRg== X-Gm-Message-State: AMke39lKIBFnyHFnxIYQl05lnXYBWpFxMuJMQwrJSuSqU5CHY18ZzU0TkJK53X7aPa389iAAKI5dUrYiN+1vXQ== X-Received: by 10.55.7.7 with SMTP id 7mr4009624qkh.228.1488322944915; Tue, 28 Feb 2017 15:02:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.55.232 with HTTP; Tue, 28 Feb 2017 15:02:24 -0800 (PST) In-Reply-To: <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> From: Tom Herbert Date: Tue, 28 Feb 2017 15:02:24 -0800 Message-ID: To: Joe Touch Content-Type: multipart/alternative; boundary=001a114c88d871794905499f3042 Archived-At: Cc: tsvwg Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:02:27 -0000 --001a114c88d871794905499f3042 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 27, 2017 at 3:30 PM, Joe Touch wrote: > Hi, all, > > A new version of the UDP options proposal has been posted. > > It adds: > > - fragmentation based on IPv6's mechanism (thanks to Mark Smith) > > - MSS (thanks to Mark Smith) and TS based on TCP's mechanism > > - auth/encryption based on TCP-AO and its extensions > > It clarifies the report of a non-compliant legacy device (thanks to Mike > Heard). > > It also adds a discussion on control block caching, ala RFC2140 for TCP. > Feedback welcome. > > Joe, >From section 9: "It is useful that the above requirements prevent using UDP options to implement transport-layer fragmentation and reassembly unless that capability has been negotiated with an endpoint in advance for a socket pair. Legacy systems would need to be able to interpret the transport payload fragments as individual transport datagrams." This can probably more broadly be worded as saying that any option that cannot be safely ignored requires the capability to be negotiated. So that clearly includes fragmentation, encryption, and any other option that modifies the payload of the original UDP packet. We can also include authentication in that list since that needs key negotiation also. So probably the next question is whether a checksum or CRC can be ignored by a receiver. Note, VXLAN and LISP have already taken liberty to allow a non-zero received UDP checksum to be ignored, however this contrary to RFC1122 which says: "If a UDP datagram is received with a checksum that is non-zero and invalid, UDP MUST silently discard the datagram." There is similar wording for IP and TCP checksums. I think this is the correct and robust policy for checksum/CRC. If a sender took the time to compute them and set them in the packet then it should be incumbent on the receiver to verify them. The whole point of enabling integrity checks is to catch errors and corruption, if we don't catch the errors at this layer we can only hope that they are caught later on but there's no guarantee. What's worse if I'm debugging an issue and snoop packets on the wire and see that sender is sending checksums but receiver is not catching bad packets then this is completely misleading. Allowing a receiver to ignore checksums undermines usefulness of the mechanism. So IMO, checksums and CRCs are in the class of options that cannot be ignored by a receiver and would need to be negotiated. That leaves TS and MSS options which probably can be safely ignored. Tom --001a114c88d871794905499f3042 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 27, 2017 at 3:30 PM, Joe Touch <touch@isi.edu> w= rote:
=20 =20 =20

Hi, all,

A new version of the UDP options proposal has been posted.

It adds:

=C2=A0=C2=A0=C2=A0 - fragmentation based on IPv6's mechanism (th= anks to Mark Smith)

=C2=A0=C2=A0=C2=A0 - MSS (thanks to Mark Smith) and TS based on TCP&= #39;s mechanism

=C2=A0=C2=A0=C2=A0 - auth/encryption based on TCP-AO and its extensi= ons

It clarifies the report of a non-compliant legacy device (thanks to Mike Heard).

It also adds a discussion on control block caching, ala RFC2140 for TCP.

Feedbac= k welcome.


Joe,

<= /div>
From section 9:

"It is useful that the above requirement= s prevent using UDP options to implement transport-layer fragmentation and reassembly unl= ess that capab= ility has been negotiated with an endpoint in advance for a socket pair. Legacy systems w= ould need to be able to interpret the transport payload fragments as individual transport= datagrams."

This can probably more broadly be worded as saying th= at any option that cannot be safely ignored requires the capability to be n= egotiated. So that clearly includes fragmentation, encryption, and any othe= r option that modifies the payload of the original UDP packet. We can also = include authentication in that list since that needs key negotiation also. = So probably the next question is whether a checksum or CRC can be ignored b= y a receiver.

Note, VXLAN and LISP have already = taken liberty to allow a non-zero received UDP checksum to be ignored, howe= ver this contrary to RFC1122 which says:

=
"If a UDP d= atagram is received with a checksum that is non-zero and invalid, UDP MUST silently discar= d the datagram."

There is similar wording for IP and TCP checksums.<= /div>

<= /div>
I think this= is the correct and robust policy for checksum/CRC. If a sender took the ti= me to compute them and set them in the packet then it should be incumbent o= n the receiver to verify them. The whole point of enabling integrity checks= is to catch errors and corruption, if we don't catch the errors at thi= s layer we can only hope that they are caught later on but there's no g= uarantee. What's worse if I'm debugging an issue and snoop packets = on the wire and see that sender is sending checksums but receiver is not ca= tching bad packets then this is completely misleading. Allowing a receiver = to ignore checksums undermines usefulness of the mechanism.

So IMO, checksums an= d CRCs are in the class of options that cannot be ignored by a receiver and= would need to be negotiated. That leaves TS and MSS options which probably= can be safely ignored.

Tom


--001a114c88d871794905499f3042-- From nobody Tue Feb 28 15:06:41 2017 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 C609B1297CA for ; Tue, 28 Feb 2017 15:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-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=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 7pJo6cZduPtb for ; Tue, 28 Feb 2017 15:06:38 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B35E1297C9 for ; Tue, 28 Feb 2017 15:06:38 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id B9AB06958E for ; Tue, 28 Feb 2017 18:06:36 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=m03IlpgF1+QPtNrqm3QihdtAPZg=; b=pmPozh j+A69eKNBu3AkxtQepLWOLysoVn453GVLVa3J7kDPidJzdGStoqLxxiGRsN/3o9H qdH1YWUOL+5rTmmYVdbTxPcNY75eDIkiCgHIbkc0cnLbiOn8Fzf4cZC7X6Wt/K9v tf3KdRGdIBwbhHbaEkiDGNd0okOpkN+4HkNIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=laTwRtdOb3pG9eW39I8YOpgRU9sFeR+C HqfyaK//SByA19VEITPBrftefbIBinCgfhAjiJzWMQ3J3cgejSRwEmaET2PGHY7p g4p/yMMApoRGGK+9dx7W522VYxma+MGrCyHXoDrWX5GGiAg2stUFlnYUcpzl+xK5 NdBY5bDwaZo= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id B18CA6958B for ; Tue, 28 Feb 2017 18:06:36 -0500 (EST) Received: from mail-qk0-f177.google.com (unknown [209.85.220.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 4033A69585 for ; Tue, 28 Feb 2017 18:06:36 -0500 (EST) Received: by mail-qk0-f177.google.com with SMTP id s186so43467875qkb.1 for ; Tue, 28 Feb 2017 15:06:36 -0800 (PST) X-Gm-Message-State: AMke39lqygJ8kuXwAtiuyqyw+TgJv++eiX+AG4wN/rfZ9BNyAVTKoZFrIE5nDu4wudsOLf4Y8Ylk7ZhPYV0vcQ== X-Received: by 10.200.36.93 with SMTP id d29mr6508708qtd.265.1488323195606; Tue, 28 Feb 2017 15:06:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.18.106 with HTTP; Tue, 28 Feb 2017 15:06:15 -0800 (PST) In-Reply-To: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> From: "C. M. Heard" Date: Tue, 28 Feb 2017 15:06:15 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: 8DC14106-FE0A-11E6-AA4C-A7617B1B28F4-06080547!pb-smtp2.pobox.com Archived-At: Cc: Mark Smith , tsvwg Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:06:40 -0000 On Tue, Feb 28, 2017 at 12:03 PM, Joe Touch wrote: > On 2/28/2017 10:58 AM, C. M. Heard wrote: >> If the Fragmentation option includes its own post-reassembly checksum, >> then a Lite option could be inserted immediately following the UDP >> header in each fragment, without loss of functionality. Implementations >> that do not support UDP options would see UDP fragments so constructed >> as empty UDP datagrams and would discard them, removing the danger of >> accidental misinterpretation. > > Is see how that's useful, but it would also appear to mean we might be > able to use LITE twice - once as this trick to hide fragments (which is > elegant - thanks!), but also to allow the use of LITE in the final > result. I'm not sure whether that makes sense yet, though - if you check > to see that the whole thing is there, there's little point in allowing > part of the packet to not be checksummed (it already would be). > > So maybe LITE couples with FRAG only in the way you mention, and no other? That is exactly how I would envision it. Thanks, Mike Heard From nobody Tue Feb 28 15:14:27 2017 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 B977F129458 for ; Tue, 28 Feb 2017 15:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 Iv_G7SWnSEPl for ; Tue, 28 Feb 2017 15:14:23 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 7D44C129435 for ; Tue, 28 Feb 2017 15:14:23 -0800 (PST) Received: from [128.9.184.129] ([128.9.184.129]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1SNDhCi022296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Feb 2017 15:13:44 -0800 (PST) To: Tom Herbert References: <148823787288.13843.6091386736320524682.idtracker@ietfa.amsl.com> <800de1a6-cb9b-f22b-946a-8b6832fc9a05@isi.edu> From: Joe Touch Message-ID: Date: Tue, 28 Feb 2017 15:13:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D6164A808D7A53A93B2193CD" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: tsvwg Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:14:24 -0000 This is a multi-part message in MIME format. --------------D6164A808D7A53A93B2193CD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Tom, On 2/28/2017 3:02 PM, Tom Herbert wrote: > > ... > > From section 9: > > "It is useful that the above requirements prevent using UDP options to > implement transport-layer fragmentation and reassembly unless that > capability has been negotiated with an endpoint in advance for a > socket pair. Legacy systems would need to be able to interpret the > transport payload fragments as individual transport datagrams." > This can probably more broadly be worded as saying that any option > that cannot be safely ignored requires the capability to be > negotiated. So that clearly includes fragmentation, encryption, and > any other option that modifies the payload of the original UDP packet. It depends; the variant that Mike proposed for FRAG using LITE with a zero-size UDP user payload is backward compatible, but just ends up dropping everything at a legacy receiver). We could actually pull the same trick with any other mechanism that would have corrupted the receiver, FWIW (not just FRAG) (see below, though). > We can also include authentication in that list since that needs key > negotiation also. AE wouldn't (just as TCP-AO doesn't); both rely on predeployed keys. > So probably the next question is whether a checksum or CRC can be > ignored by a receiver. > Note, VXLAN and LISP have already taken liberty to allow a non-zero > received UDP checksum to be ignored, however this contrary to RFC1122 > which says: > "If a UDP datagram is received with a checksum that is non-zero and > invalid, UDP MUST silently discard the datagram." > > There is similar wording for IP and TCP checksums. > > I think this is the correct and robust policy for checksum/CRC. If a > sender took the time to compute them and set them in the packet then > it should be incumbent on the receiver to verify them. The whole point > of enabling integrity checks is to catch errors and corruption, if we > don't catch the errors at this layer we can only hope that they are > caught later on but there's no guarantee. What's worse if I'm > debugging an issue and snoop packets on the wire and see that sender > is sending checksums but receiver is not catching bad packets then > this is completely misleading. Allowing a receiver to ignore checksums > undermines usefulness of the mechanism. I agree that a required checksum cannot be ignored... > > So IMO, checksums and CRCs are in the class of options that cannot be > ignored by a receiver and would need to be negotiated. That leaves TS > and MSS options which probably can be safely ignored. ACS is intended to provide better protection for receivers that support them, but are intended to be ignored by those that do not. Using ACS before reassembly would imply "drop if it fails if you support it" - by design. Using a CRC after reassembly would not, though - it MUST be dropped (but then we'd know it was supported if the reassembly succeeded). Joe --------------D6164A808D7A53A93B2193CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi, Tom,


On 2/28/2017 3:02 PM, Tom Herbert wrote:

...

From section 9:

"It is useful that the above requirements prevent using UDP options to implement transport-layer fragmentation and reassembly unless that capability has been negotiated with an endpoint in advance for a socket pair. Legacy systems would need to be able to interpret the transport payload fragments as individual transport datagrams."
This can probably more broadly be worded as saying that any option that cannot be safely ignored requires the capability to be negotiated. So that clearly includes fragmentation, encryption, and any other option that modifies the payload of the original UDP packet.

It depends; the variant that Mike proposed for FRAG using LITE with a zero-size UDP user payload is backward compatible, but just ends up dropping everything at a legacy receiver). We could actually pull the same trick with any other mechanism that would have corrupted the receiver, FWIW (not just FRAG) (see below, though).

We can also include authentication in that list since that needs key negotiation also.
AE wouldn't (just as TCP-AO doesn't); both rely on predeployed keys.

So probably the next question is whether a checksum or CRC can be ignored by a receiver.
Note, VXLAN and LISP have already taken liberty to allow a non-zero received UDP checksum to be ignored, however this contrary to RFC1122 which says:
"If a UDP datagram is received with a checksum that is non-zero and invalid, UDP MUST silently discard the datagram."

There is similar wording for IP and TCP checksums.

I think this is the correct and robust policy for checksum/CRC. If a sender took the time to compute them and set them in the packet then it should be incumbent on the receiver to verify them. The whole point of enabling integrity checks is to catch errors and corruption, if we don't catch the errors at this layer we can only hope that they are caught later on but there's no guarantee. What's worse if I'm debugging an issue and snoop packets on the wire and see that sender is sending checksums but receiver is not catching bad packets then this is completely misleading. Allowing a receiver to ignore checksums undermines usefulness of the mechanism.
I agree that a required checksum cannot be ignored...

So IMO, checksums and CRCs are in the class of options that cannot be ignored by a receiver and would need to be negotiated. That leaves TS and MSS options which probably can be safely ignored.
ACS is intended to provide better protection for receivers that support them, but are intended to be ignored by those that do not.

Using ACS before reassembly would imply "drop if it fails if you support it" - by design.

Using a CRC after reassembly would not, though - it MUST be dropped (but then we'd know it was supported if the reassembly succeeded).

Joe

--------------D6164A808D7A53A93B2193CD-- From nobody Tue Feb 28 15:16:03 2017 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 1F880129448 for ; Tue, 28 Feb 2017 15:16:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 lQE4RSxPQpeQ for ; Tue, 28 Feb 2017 15:16:01 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 14EB5129435 for ; Tue, 28 Feb 2017 15:16:01 -0800 (PST) Received: from [128.9.184.129] ([128.9.184.129]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1SNFfBw022843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Feb 2017 15:15:42 -0800 (PST) To: "C. M. Heard" References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> From: Joe Touch Message-ID: Date: Tue, 28 Feb 2017 15:15:42 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: Mark Smith , tsvwg Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:16:02 -0000 Mike, Consider this: if we use LITE before FRAG as you propose, then the reassembled result has no checksum yet. so the FRAG header could incorporate LITE if it used two different length fields: one for the whole length, one for the checksummed length. I.e., rather than require full "option" processing after FRAG, we could build LITE support into FRAG itself. Would that make sense? Joe On 2/28/2017 3:06 PM, C. M. Heard wrote: > On Tue, Feb 28, 2017 at 12:03 PM, Joe Touch wrote: >> On 2/28/2017 10:58 AM, C. M. Heard wrote: >>> If the Fragmentation option includes its own post-reassembly checksum, >>> then a Lite option could be inserted immediately following the UDP >>> header in each fragment, without loss of functionality. Implementations >>> that do not support UDP options would see UDP fragments so constructed >>> as empty UDP datagrams and would discard them, removing the danger of >>> accidental misinterpretation. >> Is see how that's useful, but it would also appear to mean we might be >> able to use LITE twice - once as this trick to hide fragments (which is >> elegant - thanks!), but also to allow the use of LITE in the final >> result. I'm not sure whether that makes sense yet, though - if you check >> to see that the whole thing is there, there's little point in allowing >> part of the packet to not be checksummed (it already would be). >> >> So maybe LITE couples with FRAG only in the way you mention, and no other? > That is exactly how I would envision it. > > Thanks, > > Mike Heard From nobody Tue Feb 28 16:42:14 2017 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 9168A12984F for ; Tue, 28 Feb 2017 16:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 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_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=heard@pobox.com header.d=pobox.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 HrOTam2er46c for ; Tue, 28 Feb 2017 16:42:12 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E47C912984B for ; Tue, 28 Feb 2017 16:42:11 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id E34C06CB2D for ; Tue, 28 Feb 2017 19:42:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=PnKhZfxRO7uP656RkGdscN6n4J4=; b=kPLvJi Znqa97zMY9GcX+0QVW1rbqkB5xUeEHEw3sWXvZQhUAokCUQqKfaWZ6tHd16M89wQ N1WbryxMB4Spu3wxRISw7rded2np58sw4lgnFqc72I4DW7GwcHY7K9QjOnMfruWi svk4rvKOw4TSMIdnwewDxjmVJhPKcb9RJAqIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; q=dns; s=sasl; b=feFBox9XKX2FFY3IcVWD8hM9uU350Ome abnALGfY1PCSK/eW+tCq1/zeIckcxe9w3r7LvN/QHCRHRpySWF4TNNf9MEGvSMxp l6sC4ippfC+gxhBC5XP1xk4424/zYwH9gi1QPGFwhN9gmgUj7xPUGDUSXua7G9Ln zocZIAZy3UA= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id D9A676CB2C for ; Tue, 28 Feb 2017 19:42:10 -0500 (EST) Received: from mail-qk0-f169.google.com (unknown [209.85.220.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 477966CB27 for ; Tue, 28 Feb 2017 19:42:10 -0500 (EST) Received: by mail-qk0-f169.google.com with SMTP id u188so46477199qkc.2 for ; Tue, 28 Feb 2017 16:42:10 -0800 (PST) X-Gm-Message-State: AMke39mMeqGd7vfZct+RfcZYQTW6O3mca7FdQjA2K0o94kDGwOW02AMKlBlWqSYqJtDGvcscIXgw6kAh9u2qDw== X-Received: by 10.200.36.93 with SMTP id d29mr7049685qtd.265.1488328929480; Tue, 28 Feb 2017 16:42:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.18.106 with HTTP; Tue, 28 Feb 2017 16:41:49 -0800 (PST) In-Reply-To: References: <3a4a6b78-8146-de4c-6246-7bd09de44f1c@isi.edu> From: "C. M. Heard" Date: Tue, 28 Feb 2017 16:41:49 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Joe Touch Content-Type: text/plain; charset=UTF-8 X-Pobox-Relay-ID: E7817758-FE17-11E6-BEF5-A7617B1B28F4-06080547!pb-smtp2.pobox.com Archived-At: Cc: "C. M. Heard" , Mark Smith , tsvwg Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 00:42:13 -0000 On Tue, Feb 28, 2017 at 3:15 PM, Joe Touch wrote: > Consider this: > > if we use LITE before FRAG as you propose, then the reassembled result > has no checksum yet. > > so the FRAG header could incorporate LITE if it used two different > length fields: one for the whole length, one for the checksummed length. > > I.e., rather than require full "option" processing after FRAG, we could > build LITE support into FRAG itself. > > Would that make sense? I definitely like the idea of building LITE support into FRAG, particularly if one of the side effects is that we always hide fragments from legacy implementations. But let me walk through it to make sure that I understand how it would work. With LITE at the beginning of the payload before FRAG, as I initially suggested, the UDP length is 8 and the UDP checksum protects only the UDP header. LITE specifies how much of the surplus area is user data; the rest is transport options, including FRAG itself. FRAG specifies the fragment offset, the M bit, the identification, and (if the rest of my suggestion is accepted), a post-reassembly length and checksum, If FRAG were to incorporate LITE, it would still appear immediately after the UDP header (which would be unchanged). If you want to incorporate per-fragment UDP options, FRAG would now need to have the offset to the remaining UDP options. So, its fields would now be: kind, length (16 bytes), fragment offset, M bit, identification, post-reassembly length that was checksummed, checksum value, post-reassembly length that was not checksummed, and offset to remaining options. Is that what you had in mind? If so, it would certainly work for me. I believe that a technically viable alternative would be to have instead per-fragment length that was checksummed, checksum value, and per-fragment length that was not checksummed. In that case the offset to the remaining options could be inferred. Another alternative would be to use post-reassembly values and only one set of UDP options for the entire message; the options would then be whatever surplus remained after the last fragment was reassembled, and a separate length field again would not be needed. Let me mention in passing that I tend to agree with the sentiment that the standard Internet checksum is probably the right way to go. If that is provided for the entire reassembled message, you will have feature parity with what is provided by UDP + IP fragmentation. Mike Heard