From nobody Wed May 3 14:21:07 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 557F4129BCC; Wed, 3 May 2017 14:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 PfdeKgoy7RFN; Wed, 3 May 2017 14:21:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F43F129B9A; Wed, 3 May 2017 14:19:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BFEFDB80A50; Wed, 3 May 2017 14:19:09 -0700 (PDT) To: heard@pobox.com, kk@teraoptic.com, floyd@aciri.org, black_david@emc.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: priyanka@amsl.com, iesg@ietf.org, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170503211909.BFEFDB80A50@rfc-editor.org> Date: Wed, 3 May 2017 14:19:09 -0700 (PDT) Archived-At: Subject: [tsvwg] [Errata Verified] RFC3168 (4997) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:21:06 -0000 The following errata report has been verified for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/rfc3168/eid4997 -------------------------------------- Status: Verified Type: Editorial Reported by: C. M. Heard Date Reported: 2017-04-17 Verified by: priyanka (IESG) Section: Header Original Text ------------- Updates: 2474, 2401, 793 Corrected Text -------------- Updates: 2474, 2460, 2401, 793 Notes ----- RFC 3168 updates RFC 2460 but does not indicate this in its header block. Specifically, Section 5.3 of RFC 3168 requires that the ECN field of a reassembled IPv6 datagram be calculated from the ECN fields of all of the fragments, rather than simply copying it from the initial fragment as specified in RFC 2460. There are other missing Updates: fields; see e.g. Erratum 2660. -------------------------------------- RFC3168 (draft-ietf-tsvwg-ecn-04) -------------------------------------- Title : The Addition of Explicit Congestion Notification (ECN) to IP Publication Date : September 2001 Author(s) : K. Ramakrishnan, S. Floyd, D. Black Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF Verifying Party : IESG From nobody Wed May 3 14:35: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 A6BD3128B93 for ; Wed, 3 May 2017 14:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 4DCdAjpDBX7W for ; Wed, 3 May 2017 14:35:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90136129353 for ; Wed, 3 May 2017 14:33:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C88EBB80CA7; Wed, 3 May 2017 14:33:22 -0700 (PDT) To: kk@teraoptic.com, floyd@aciri.org, black_david@emc.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, david.black@emc.com, gorry@erg.abdn.ac.uk, wes@mti-systems.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Cc: heard@pobox.com, tsvwg@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170503213322.C88EBB80CA7@rfc-editor.org> Date: Wed, 3 May 2017 14:33:22 -0700 (PDT) Archived-At: Subject: [tsvwg] [Editorial Errata Reported] RFC3168 (4997) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:35:13 -0000 The following errata report has been submitted for RFC3168, "The Addition of Explicit Congestion Notification (ECN) to IP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/rfc3168/eid4997 -------------------------------------- Type: Editorial Reported by: C. M. Heard Section: Header Original Text ------------- Updates: 2474, 2401, 793 Corrected Text -------------- Updates: 2474, 2460, 2401, 793 Notes ----- RFC 3168 updates RFC 2460 but does not indicate this in its header block. Specifically, Section 5.3 of RFC 3168 requires that the ECN field of a reassembled IPv6 datagram be calculated from the ECN fields of all of the fragments, rather than simply copying it from the initial fragment as specified in RFC 2460. There are other missing Updates: fields; see e.g. Erratum 2660. 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. -------------------------------------- RFC3168 (draft-ietf-tsvwg-ecn-04) -------------------------------------- Title : The Addition of Explicit Congestion Notification (ECN) to IP Publication Date : September 2001 Author(s) : K. Ramakrishnan, S. Floyd, D. Black Category : PROPOSED STANDARD Source : Transport Area Working Group Area : Transport Stream : IETF From nobody Wed May 3 14:35:36 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 258D91293E0; Wed, 3 May 2017 14:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 5w8-xVqLyuQx; Wed, 3 May 2017 14:35:33 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DC212717E; Wed, 3 May 2017 14:34:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C5B791C68C0; Wed, 3 May 2017 14:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlcAfxsdw5pw; Wed, 3 May 2017 14:33:59 -0700 (PDT) Received: from sandygiozasmbp2.home (unknown [47.156.91.59]) by c8a.amsl.com (Postfix) with ESMTPSA id 84B751C5A6F; Wed, 3 May 2017 14:33:59 -0700 (PDT) From: Sandy Ginoza Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 3 May 2017 14:34:05 -0700 References: <20170503211909.BFEFDB80A50@rfc-editor.org> To: heard@pobox.com, kk@teraoptic.com, floyd@aciri.org, black_david@emc.com, The IESG , tsvwg@ietf.org In-Reply-To: <20170503211909.BFEFDB80A50@rfc-editor.org> Message-Id: <9BD8482C-8CFB-48DA-A1DC-EC1A17484BFC@amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [tsvwg] [Errata Verified] RFC3168 (4997) X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 21:35:35 -0000 Greetings all, Please disregard the message below. The erratum was moved to = =E2=80=9CVerfied=E2=80=9D by mistake. The original state of = =E2=80=9CReported=E2=80=9D has been restored. Our apologies for the = confusion. =20 Thanks, Sandy > On May 3, 2017, at 2:19 PM, RFC Errata System = wrote: >=20 > The following errata report has been verified for RFC3168, > "The Addition of Explicit Congestion Notification (ECN) to IP".=20 >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/rfc3168/eid4997 >=20 > -------------------------------------- > Status: Verified > Type: Editorial >=20 > Reported by: C. M. Heard > Date Reported: 2017-04-17 > Verified by: priyanka (IESG) >=20 > Section: Header >=20 > Original Text > ------------- > Updates: 2474, 2401, 793 >=20 > Corrected Text > -------------- > Updates: 2474, 2460, 2401, 793 >=20 >=20 >=20 > Notes > ----- > RFC 3168 updates RFC 2460 but does not indicate this in its header = block. >=20 > Specifically, Section 5.3 of RFC 3168 requires that the ECN field of a = reassembled IPv6 datagram be calculated from the ECN fields of all of = the fragments, rather than simply copying it from the initial fragment = as specified in RFC 2460. >=20 > There are other missing Updates: fields; see e.g. Erratum 2660. >=20 > -------------------------------------- > RFC3168 (draft-ietf-tsvwg-ecn-04) > -------------------------------------- > Title : The Addition of Explicit Congestion Notification = (ECN) to IP > Publication Date : September 2001 > Author(s) : K. Ramakrishnan, S. Floyd, D. Black > Category : PROPOSED STANDARD > Source : Transport Area Working Group > Area : Transport > Stream : IETF > Verifying Party : IESG >=20 From nobody Fri May 5 15:13:06 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 D34E5126E64; Fri, 5 May 2017 15:13:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149402238482.8504.3421378854070282666@ietfa.amsl.com> Date: Fri, 05 May 2017 15:13:04 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-l4s-arch-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:13:05 -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 : Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture Authors : Bob Briscoe Koen De Schepper Marcelo Bagnulo Filename : draft-ietf-tsvwg-l4s-arch-00.txt Pages : 31 Date : 2017-05-05 Abstract: This document describes the L4S architecture for the provision of a new Internet service that could eventually replace best efforts for all traffic: Low Latency, Low Loss, Scalable throughput (L4S). It is becoming common for _all_ (or most) applications being run by a user at any one time to require low latency. However, the only solution the IETF can offer for ultra-low queuing delay is Diffserv, which only favours a minority of packets at the expense of others. In extensive testing the new L4S service keeps average queuing delay under a millisecond for _all_ applications even under very heavy load, without sacrificing utilization; and it keeps congestion loss to zero. It is becoming widely recognized that adding more access capacity gives diminishing returns, because latency is becoming the critical problem. Even with a high capacity broadband access, the reduced latency of L4S remarkably and consistently improves performance under load for applications such as interactive video, conversational video, voice, Web, gaming, instant messaging, remote desktop and cloud-based apps (even when all being used at once over the same access link). The insight is that the root cause of queuing delay is in TCP, not in the queue. By fixing the sending TCP (and other transports) queuing latency becomes so much better than today that operators will want to deploy the network part of L4S to enable new products and services. Further, the network part is simple to deploy - incrementally with zero-config. Both parts, sender and network, ensure coexistence with other legacy traffic. At the same time L4S solves the long-recognized problem with the future scalability of TCP throughput. This document describes the L4S architecture, briefly describing the different components and how the work together to provide the aforementioned enhanced Internet service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-l4s-arch-00 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 5 15:13:39 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 AF6DE1294F7; Fri, 5 May 2017 15:13:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149402241168.8434.10328462084541234863@ietfa.amsl.com> Date: Fri, 05 May 2017 15:13:31 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 22:13:32 -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 : Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay Authors : Koen De Schepper Bob Briscoe Filename : draft-ietf-tsvwg-ecn-l4s-id-00.txt Pages : 32 Date : 2017-05-05 Abstract: This specification defines the identifier to be used on IP packets for a new network service called low latency, low loss and scalable throughput (L4S). It is similar to the original (or 'Classic') Explicit Congestion Notification (ECN). 'Classic' ECN marking was required to be equivalent to a drop, both when applied in the network and when responded to by a transport. Unlike 'Classic' ECN marking, for packets carrying the L4S identifier, the network applies marking more immediately and more aggressively than drop, and the transport response to each mark is reduced and smoothed relative to that for drop. The two changes counterbalance each other so that the throughput of an L4S flow will be roughly the same as a 'Classic' flow under the same conditions. However, the much more frequent control signals and the finer responses to them result in ultra-low queuing delay without compromising link utilization, even during high load. Examples of new active queue management (AQM) marking algorithms and examples of new transports (whether TCP-like or real- time) are specified separately. The new L4S identifier is the key piece that enables them to interwork and distinguishes them from 'Classic' traffic. It gives an incremental migration path so that existing 'Classic' TCP traffic will be no worse off, but it can be prevented from degrading the ultra-low delay and loss of the new scalable transports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-l4s-id-00 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 7 02:52: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 199D81293E4 for ; Sun, 7 May 2017 02:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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] 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 abl8r3sJHMVh for ; Sun, 7 May 2017 02:52:21 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 391361292D3 for ; Sun, 7 May 2017 02:52:20 -0700 (PDT) X-AuditID: c1b4fb2d-b3dff7000000196b-a5-590eee527a28 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 18.2C.06507.25EEE095; Sun, 7 May 2017 11:52:19 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.339.0; Sun, 7 May 2017 11:52:18 +0200 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=x65QaewK1eKDIRU+AM1L2IwfsnsGGG80Xy7aL1Tlu4k=; b=muWkvdwGwE2b7z/kuRa7/VfKhdSKYE7jH/Wsu7shGwZ0rQE8G6/3p2Zw3S03zl7lQ7R3n6E9YJU/YPXhr5DZxQQTp77ShP9pj0AFVuui41fravhug8q3suEVSnVjGW1OoamIWxGznNYAWaT4uV3Ih+rQnLJf+UM0q2Md/tNu2pE= Received: from DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) by DBXPR07MB352.eurprd07.prod.outlook.com (10.141.12.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Sun, 7 May 2017 09:52:17 +0000 Received: from DBXPR07MB351.eurprd07.prod.outlook.com ([10.141.12.151]) by DBXPR07MB351.eurprd07.prod.outlook.com ([10.141.12.151]) with mapi id 15.01.1084.011; Sun, 7 May 2017 09:52:16 +0000 From: Ingemar Johansson S To: "De Schepper, Koen (Nokia - BE/Antwerp)" , "Bob Briscoe (ietf@bobbriscoe.net)" , tsvwg IETF list , "Black, David (david.black@emc.com)" CC: Ingemar Johansson S Thread-Topic: Enhanced ECN support in 5G Thread-Index: AdLHFxcSu2xsg/6KTy+IWITHA+tFTw== Date: Sun, 7 May 2017 09:52:16 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia-bell-labs.com; dkim=none (message not signed) header.d=none;nokia-bell-labs.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DBXPR07MB352; 7:bzXJ7T+a2qZOcsKE6mcrVnh3sDcIcYwSsT6NFHXlixMzrVlcSym2t+BTq4TD4EPg0ghfN1js0z2GxVu5XTbOpRqU1/M8ww4QAp4h4DdPySkeELk+2kGBMH862ei3gMLkLo/Qa9mdkS03MmArknLpJUInhPE9fivzPoaF4pDeIX87/asHQUvPPNey/JHEZLCKwkYOgHGzYyM/qz0uhAE97JtbYrMNde4QDiLAUtTR+ZybfnabXUyORwRmjWgpkqbFlWFzRB4UZnNwjh0clKOXtgN94yHJ7ISUbGiPZVyLZ+jOcv9sUCezILcUufKrzp3IsOmKOn7IigXLlFsVTWhazg== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(39410400002)(39450400003)(39400400002)(39850400002)(39840400002)(86362001)(3846002)(102836003)(33656002)(2900100001)(966004)(6116002)(790700001)(38730400002)(50986999)(3280700002)(107886003)(6506006)(77096006)(66066001)(54896002)(54356999)(3660700001)(53936002)(6306002)(99286003)(9686003)(4326008)(236005)(55016002)(6436002)(5660300001)(8666007)(8558605004)(2906002)(606005)(7696004)(122556002)(189998001)(7906003)(7736002)(478600001)(74316002)(8676002)(81166006)(19609705001)(8936002)(19623455009); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB352; H:DBXPR07MB351.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-ms-office365-filtering-correlation-id: 3ce85494-07af-4d59-f4a7-08d4952ebeb4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DBXPR07MB352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700033)(100105000095)(100000701033)(100105300095)(100000702033)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703033)(100105400095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(100000704033)(100105200095)(100000705033)(100105500095); SRVR:DBXPR07MB352; BCL:0; PCL:0; RULEID:(100000800033)(100110000095)(100000801033)(100110300095)(100000802033)(100110100095)(100000803033)(100110400095)(100000804033)(100110200095)(100000805033)(100110500095); SRVR:DBXPR07MB352; x-forefront-prvs: 03008837BD spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR07MB3515EC567BC83E30AF9DDD5C2E90DBXPR07MB351eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2017 09:52:16.5396 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB352 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SeUiTYRzHed5jvq5mb1PzhwfYFIzEdSlYWCokLCLxIDwias0XXeqUvSYq FGqENFM8JniAR840w0DREk3TOaeCppmUs9Qs/yiPCJWJLCW3p8D/Pt+DH88XHoYU99KujFKV walV8hSJQEhVxb4O9ov+5RB3evLdscCuoTa7wOGlejrQaG4iAo1r84IQSrayOEXLDIYaSqbT 7RCyfPNTQQQVLwxK4FKUmZz61KXbwqQ1y9100/msvp1FIheZ/DXIngHWHyy7c6QGCRkxa0Bg GCglsBhBUGJpQ1ZBsUUkFPxuQTgpJ2CpuZzCYgiBZaGFsB4TsEHwXL9tazmxGwgaSuttAcle gK2RXdLKjqwXlHVvC6zsxJ6AVx01dpil8LHHYOtQrDfkr5mQlUVsPEwXjdh8xHrA4vYChW+6 wNxyHYFXsKB7M0lidoaf3/do3G9EkLeu0CBm3/eEpa5wXPGA6bpChLmQBHO+HeZmGsZNXrh+ DYbXY7B9H1bH8mjMSiiraPrHN0Br1Aisc4EdoKG9s4DCgTtMbVYSeK4rzM88Rpjd4ceXPho/ Pw1GF1bIEuRTfWBN9YGo2rb+KIxVLVPYl8JshVaA2ReeNaySmP2gck9PHfTrkV0rcuY5nk9N PHtOyqmVCp5PU0lVXEYH2v9Sg50Wv270YjVUj1gGSQ6LPI84xIlpeSafnapHwJASJ1HA8r4l SpBn53DqtFvqeykcr0duDCVxEYX0T8WK2UR5BpfMcemc+n9KMPauuUjnAb3hYt3XFsolIafn 7Uvvb8fVtaMbQq/sMMi93Fq7fLXg0RNHc3P/dsQHPlIbej31Dn0xYGLA3Tc5ImL2YfChP1EK U/gVaelGeXuMq3/x5qBEW9P7QBo18dlMSjM7sm5GzrzPio+P1qymVzduufmMaoubx42K7OFP YSHG6HQJxSfJz5wk1bz8L8jBo3NOAwAA Archived-At: Subject: [tsvwg] Enhanced ECN support in 5G X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 09:52:23 -0000 --_000_DBXPR07MB3515EC567BC83E30AF9DDD5C2E90DBXPR07MB351eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi To whom it may concern. The submission below is posted to 3GPP RAN2. The intention is to add suppor= t for timely and efficient ECN marking in NR (5G) . This will make it easie= r to eventually implement support for L4S in 5G. http://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_98/Docs/R2-1704368.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 A mistake is to commit a misunderstanding Bob Dylan =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_DBXPR07MB3515EC567BC83E30AF9DDD5C2E90DBXPR07MB351eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

To whom it may concern.

The submission below is posted to 3GPP RAN2. The int= ention is to add support for timely and efficient ECN marking in NR (5G) . = This will make it easier to eventually implement support for L4S in 5G.

 

http://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_= 98/Docs/R2-1704368.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

 

A mistake is to commit a misunderstanding
       =              &n= bsp;Bob Dylan
=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<= /o:p>

 

--_000_DBXPR07MB3515EC567BC83E30AF9DDD5C2E90DBXPR07MB351eurprd_-- From nobody Tue May 9 14:47:46 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 9917E1200F1; Tue, 9 May 2017 14:47:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149436645760.4377.8921134662806494652@ietfa.amsl.com> Date: Tue, 09 May 2017 14:47:37 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 21:47:38 -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 : Diffserv to IEEE 802.11 Mapping Authors : Tim Szigeti Jerome Henry Fred Baker Filename : draft-ietf-tsvwg-ieee-802-11-02.txt Pages : 33 Date : 2017-05-09 Abstract: As internet traffic is increasingly sourced-from and destined-to wireless endpoints, it is crucial that Quality of Service be aligned between wired and wireless networks; however, this is not always the case by default. This document specifies a set Differentiated Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings to reconcile the marking recommendations offered by the IETF and the IEEE so as to maintain consistent QoS treatment between wired and IEEE 802.11 wireless networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-02 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ieee-802-11-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ieee-802-11-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 9 15:04: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 3047212EB5E; Tue, 9 May 2017 15:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 rqbSgnvm9Y_a; Tue, 9 May 2017 15:04:31 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5DA1296B3; Tue, 9 May 2017 15:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23340; q=dns/txt; s=iport; t=1494367471; x=1495577071; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=kpM5O15XcYTNaXwpOMp/t5v/kyidD+ye+72A4YiD8rI=; b=VPhfcvPqVZ20rchMP/ewpINjRV+JegpfS9UZrwbG7reBwZ4TCB+dl/u6 ZeVnC4x9M4IRciJGrPqZrZV3xyqljbuJOmcZ3u6pSmEAhi48JX1W0Zvgg Ej3xigfckiZyil5RESx7XVH4SE6KzQr29cbPSyrjXGhYLOHa294tWieh2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAAAHPBJZ/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1ViMloHjXqnR4IPAiqFeIRvPxgBAgEBAQEBAQFrHQuFNg0TMQc?= =?us-ascii?q?HEgEcIkImAQQODROFeYQNDrEtAoMbOopwAQEBAQEBAQMBAQEBAQEBARsFMogKA?= =?us-ascii?q?YIPhVIBAU2FNwWHD4ItiD+MCgGHG4MzgyyFFYINhTuDZoZGlD8BHziBCnAVRoR?= =?us-ascii?q?vBQUXgWN2AYY2Ag0XB4EDgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.38,316,1491264000"; d="scan'208";a="422341532" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2017 22:04:29 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v49M4Ti0019031 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2017 22:04:29 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 May 2017 17:04:28 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Tue, 9 May 2017 17:04:28 -0500 From: "Tim Szigeti (szigeti)" To: "tsvwg@ietf.org" CC: Vincent Roca , "Black, David" , Gorry Fairhurst , "Brian E Carpenter" , "Ruediger.Geib@telekom.de" , "Cullen Jennings (fluffy)" , "fredbakersba@gmail.com" , "Jerome Henry (jerhenry)" , "draft-ietf-tsvwg-ieee-802-11@ietf.org" Thread-Topic: Summary of Comments/Changes: draft-ietf-tsvwg-ieee-802-11-02 Thread-Index: AdLJD4ldl2/ryidVSRi4oCJU08gl+g== Date: Tue, 9 May 2017 22:04:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.132.12.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [tsvwg] Summary of Comments/Changes: draft-ietf-tsvwg-ieee-802-11-02 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 22:04:34 -0000 First off, I'd like to thank David Black, Gorry Fairhurst, Ruediger Geib, V= incent Roca, Brian Carpenter, Tom Jones and Cullen Jennings for providing e= xcellent constructive comments on this PS. The feedback is very valuable an= d makes for a better PS. As David well put it: an extensive set of comments= is like a "backhanded compliment", and that's how I'm taking it ;-) Next, I'd like to share a summary of the comments and actions taken that ha= ve gone into the latest revision, posted today: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-02=20 -tim --- SUMMARY OF COMMENTS AND CHANGES: draft-ietf-tsvwg-ieee-802-11-02 Source/Date: V. Roca 12/20/16 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.ht= ml =20 Comment: "1- Abstract is pretty similar to the general introduction... I'd = suggest to shorten the abstract and go deeper into details in Section 1 to = avoid such differences." Action: Abstract has been shortened per suggestion --- Source/Date: V. Roca 12/20/16 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.htm= l =20 Comment: "2-Section 4.1.1: Could you please simplify the following sentence= : "So too SHOULD Network Control..." Action: Sentence has been reworded per suggestion ("Network control traffic= marked CS6 DSCP SHOULD also be...") --- Source/Date: V. Roca 12/20/16 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.htm= l =20 Comment: "3-Section 5.3: the notion of "DSCP trust" is a little bit strange= . For me, the notion of trust is associated to a security assessment. For i= nstance, marking could be trusted because it's handled by a secure mechanis= m, because the packet integrity is verifiable, etc. From what I understand,= "trusted" means that DSCP marking is more accurate (6 bits) than UP markin= g (3 bits). That's totally different." Action: A formal definition of "trust" specific to the context of this docu= ment (and in line with the way this term has been used extendedly in RFC459= 4) has been added to a new Terminology section (Section 1.6). Specifically= : " Trust: From a QoS-perspective, trust refers to the accepting of the QoS m= arkings of a packet by a network device. Trust is typically extended at Lay= er 3 (by accepting the DSCP), but may also be extended at lower layers, suc= h as at Layer 2 by accepting User Priority markings. For example, if an acc= ess point is configured to trust DSCP markings and it receives a packet mar= ked EF, then it would treat the packet with the Expedite Forwarding PHB and= propagate the EF marking value (DSCP 46) as it transmits the packet. Alter= natively, if a network device is configured to operate in an untrusted mann= er, then it would remark packets as these entered the device, typically to = DF (or to a different marking value at the network administrator's preferen= ce). Note: The terms "trusted" and "untrusted" are used extensively in RFC = 4594." --- Source/Date: V. Roca 12/20/16 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.htm= l =20 Comment: "4-Section 8, "Security considerations": this section is strange a= s it references a single threat. Do you mean that no other risk exists Whet= her this is the case or not, this should be clearly said." Action: Security Considerations section (Section 8) has been heavily revise= d and expanded; similarly, multiple sections throughout the document (notab= ly Sections 4.1.1, 5.2, 5.3 and 5.4) have all been revised to include secur= ity-related concerns and recommendations. --- Source/Date: V. Roca 12/20/16 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.htm= l =20 Comment: "5-Section 8, "Security considerations": More generally, if a end= -host can cheat while marking its traffic, then DoS are pretty easy to laun= ch. Is there any solution to this problem? One can probably reduce risks, f= or instance by rate limiting techniques on a per source MAC or IP address b= asis (assuming this address has not been forged), but solving risks totally= seems difficult without strong authentication. Perhaps WPA/WPA2 could help= here? I don't know what you think about it?" Action: All of these considerations and recommendations have been included = in the expanded and revised Security Considerations section (Section 8) --- Source/Date: V. Roca 12/20/16 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.htm= l =20 Comment: "6-Section 8, "Security considerations": I'm also wondering if the= DSCP/UP mapping process can be considered secure? Section 3 gives some ins= ights ("all wireless endpoint devices support the ability to support fully-= configurable mappings..."). A malware may corrupt this end-host mapping, no= ?" Action: This consideration has been included in the expanded and revised Se= curity Considerations section (Section 8) --- Source/Date: V. Roca 12/20/16 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.htm= l =20 Comment: "7-Section 8, "Security considerations": Having an empty 8.1 Priv= acy considerations section is strange. Say explicitely that you don't think= this document has any impact here." Action: The Privacy Considerations section has been deleted --- Source/Date: V. Roca 12/20/16 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14878.htm= l =20 Comment: "Typos and other details..." Action: All typos have been corrected, per suggestions --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l=20 Comment: "Major Issues [1] Security!! This text in Section 3 ... strikes = me as sufficient to send a knowledgeable security directorate reviewer into= low earth orbit. I would hope the recent IoT-botnet-based DDoS attacks ma= ke it painfully clear that the operating systems and applications in endpoi= nt devices cannot be trusted, at least as the term "trust" is used here... = IMNSHO, Section 5.3 needs a complete rethink and rewrite. [In My Not-So-Hu= mble Opinion] The Security Considerations in section 8 also need attention= , as this topic is not mentioned there." Action: All sections referenced in the comments have been completely re-wri= tten with the recommendations revised based on the feedback. This includes = Section 3, Section 8 (Security Considerations) and Section 5 (Upstream Mapp= ing/Marking Recommendations). Additionally, the term "trust" has been expli= citly defined (in the new Terminology Section 1.6) in the same context (of = QoS) as it is extensively used in RFC 4594.=20 --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Major Issues [2] Diffserv domain/region boundaries... I think a = new section on this topic is called for as it applies to traffic in both di= rections." Action: A new section has been added (Section 2.1 Diffserv Domain Boundarie= s) and all points in the comments have been addressed --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Major Issues [3] Section 4 - Relationship to RFC 4594 In Section= 4, significant discussion, and often actual text are reproduced from RFC 4= 594, without making it clear that RFC 4594 is the source. For example, Sec= tion 4.1 (without subsections) is entirely from RFC 4594 (there is nothing = in there that isn't covered by RFC 4594). All of section 4 needs to be edi= ted to indicate what concepts are repeated from RFC 4594 vs. what is new to= this draft. " Action: All sections (and especially Section 4) have been edited to indicat= e what concepts are repeated from RFC4594, as well as the specific section = of that RFC that these are being referenced from --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Minor Issues [A] Optimality s/b Consistency... the draft is wri= tten in terms of optimizing and (even worse)optimal QoS. The latter is not= realistic - a fine companion to the tooth fairy, Santa Claus and the Easte= r Bunny. I suggest changing from optimal QoS as the goal to consistent QoS... This needs to be done throughout the draft. All related terms need= to be changed, e.g., "sub-optimal" -> "inconsistent" or "less consistent" Action: "Optimal" has been changed to "consistent" throughout the document;= all related terms have likewise been changed, per suggestion --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Minor Issues [B] 1.2. Interaction with RFC 7561 ["]The GSMA sp= ecification was developed without reference to the service plan documented = in Section 1.1, and conflicts both in the services specified and the code p= oints specified for them. ["] The above sentence is unclear. Section 1.1 = does not describe a service plan (e.g., that term doesn't occur there), and= the nature of the conflict is unclear. I suggest focusing this sentence t= o say that RFC 7561 and RFC 4594 conflict and add text to section 1.1 about= the role of RFC 4594. The term "service plan" is also vague in this cont= ext, and probably should not be used - see RFC 4594 for ideas on what to sa= y instead." Action: Section 1.2 has been reworded per suggestions. The referenced part = now reads: " The GSMA specification was developed without reference to exis= ting IETF specifications for various services, referenced in Section 1.1. T= hus, [RFC7561] conflicts with the overall Diffserv traffic-conditioning ser= vice plan, both in the services specified and the code points specified for= them." --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Minor Issues [C] This draft needs a terminology section, as the = initial expansions of acronyms are sprinkled across a number of places incl= uding the Abstract. The terminology section needs to include AP, UP, DSCP,= WiFi, QoS, and all the acronyms in the 6.x section headings. Also, please= ensure that WiFi is never hyphenated across a line break as Wi-Fi. While t= his concern is nominally editorial, it is a significant hurdle for document= accessibility to non-experts, and hence I've tagged it as a minor issue." Action: A new Terminology section (Section 1.6) has been added to the docum= ent, with all called out terms explicitly added (along with others). --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Minor Issues [D] Section 2. Comparison and Default Interoperati= on ... "Comparison" -> "Service Comparison" to fit the scope of the sectio= n. ["] The following comparisons between IEEE 802.11 and DiffServ should be= noted:["] "comparisons" -> "service comparisons" OR insert "services" aft= er "Diffserv" Also note that lower case 's' is the correct capitalization = of Diffserv (i.e., not camel-case DiffServ)." Action: Changes have been made to Section 2 per the suggestions. Also all i= nstances of "DiffServ" have been corrected to "Diffserv" throughout the doc= ument. --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Minor Issues [E] 2.2. Default UP-to-DSCP Mappings and Conflicts= ["] Mapping UP 4 (Multimedia Conferencing and/or Real-Time Interactive) to= CS4, thus losing the ability to distinguish between these two distinct tra= ffic classes["] Need to explain somewhere how to differentiate between thes= e two distinct traffic classes for this bullet item and following ones. Als= o, are these traffic classes defined by RFC 4594 or 802.11? That's not clea= r for bullets after the first one in the list where the quoted text is the = second bullet item. " Action: Added specific references to the respective RFC 4594 sections for t= he recommendations of how to differentiate services for each of the called = out service classes in Section 2.2 --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Minor Issues [F] 4.1.1. Network Control Protocols (DSCP usage) = ["] Following this recommendation, it is RECOMMENDED that all packets mark= ed to DiffServ Codepoints not in use over the wireless network be dropped o= r remarked at the edge of the DiffServ domain.["] This general recommendat= ion should not be buried in a section on network control protocols. At the= very least it should be elevated to section 4 and included in the summary = in section [4.]3. Also, this recommendation originates from RFC 2475 and s= hould be described accordingly, although the recommendation may not be stat= ed as concisely in RFC 2475 by comparison to RFC 4594." Action: This recommendation has been elevated to Section 2.1, to Section 4,= and to the summary in Section 4.3, as per suggestions --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Minor Issues [G] 4.1.1. Network Control Protocols (drop CS6 at = domain boundaries)... A specific concern is that I think this recommendation to drop CS6 prevents running routing protocols across t= he wireless-to-wired boundary in this case. While not typical, I believe t= hat this can be done, although in the specific case of routing protocols, t= he boundary AP ought to be a participant in any IGP (internal) routing prot= ocol. OTOH, I suppose one could run an EGP (external) routing protocol, e.= g., BGP here, and the AP is unlikely to be an inter-domain BGP speaker. Som= e more discussion seems to be in order, and the discussion should probably = also note that encapsulated routing protocols for encapsulated or overlay n= etworks (e.g., VPN, NVO3) are not network control traffic for any physical = network at the AP, and hence SHOULD NOT be marked with CS6 in the first pla= ce." Action: Revised the section per suggestions and included the specific recom= mended comments. --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Minor Issues [H] 4.2.7. Low-Latency Data ["] In line with the r= ecommendations made in Section 4.2.2, mapping Low- Latency Data to UP 3 may= allow such to receive a superior level of service via transmit queues serv= icing the EDCAF hardware for the Best Effort Access Category (AC_BE).["] Th= is cross-reference to Section 4.2.2 is hard to follow. The discussion of E= DCAF hardware behavior should be factored out to somewhere near the start o= f Section 4. While this concern is nominally editorial, it is a significan= t clarity problem for non-experts, and hence I've tagged it as a minor issu= e."=20 Action: Revised these sections and elevated the discussion of EDCAF to the= start of Section 4 (as suggested). --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Minor Issues [I] 4.3. DSCP-to-UP Mapping Recommendations Summar= y In Figure 1, the "(See Section 4.1.1)" text for Network Control traffic w= on't suffice for an implementer who is looking at the 4.3 summary because S= ection 4 in its entirety caused a tl;dr [too long; didn't read] reaction. = Please add a short paragraph summarizing what to do (always drop CS7, drop = CS6 at Diffserv boundaries, otherwise map CS6 to ...)."=20 Action: Revised Figure 1 in Section 4.3 per suggestions --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Minor Issues [J] 5.1. Upstream DSCP-to-UP Mapping ["] it is R= ECOMMENDED that such wireless client operating systems utilize instead the = same DSCP-to-UP mapping recommendations presented in Section 4 and/or fully= customizable UP markings.["] I don't understand "and/or fully customizabl= e UP markings." As written, this allows arbitrary mappings to be consisten= t with the recommendation which is surely not what was intended. I suggest= ending the sentence with a period after "Section 4" and handling customiza= ble UP markings in a separate sentence. Action: Revised the sentence exactly as suggested. --- Source/Date: D. Black 01/04/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.htm= l =20 Comment: "Editorial/Nits..." Action: All editorial suggestions have been implemented --- Source/Date: B. Carpenter 01/12/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.htm= l=20 Comment: "As stated in RFC 2474... The defense against this class of thef= t- and denial-of-service attacks consists of the combination of traffic con= ditioning at DS domain boundaries with security and integrity of the networ= k infrastructure within a DS domain. If the network includes devices that h= ave been maliciously programmed to set EF on every packet, and if a router = implements EF correctly, the result would be that every packet beyond the c= apacity allocated to EF "SHOULD be dropped" according to RFC 3246. So the s= ervice would be significantly worse than best effort. The same therefore ap= plies to any 802.11 marking that is mapped to EF. There could be similar bu= t less serious effects from spurious CSx or AFxy markings." Action: This security recommendation has been added to the heavily revised = and expanded Security Considerations section (Section 8) --- Source/Date: B. Carpenter 01/12/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.htm= l =20 Comment: " You can't trust markings from random devices. Unless devices ha= ve been identified, authenticated and authorized they aren't trustworthy. S= everal WGs are expending considerable effort on this problem; I'm no expert= , but draft-ietf-anima-bootstrapping-keyinfra is one example." Action: This important security consideration has now been explicitly calle= d out in Section 5.3 " Upstream DSCP-Trust at the Wireless Access Point", w= hich begins: "It is NOT RECOMMENDED to trust DSCP markings from devices tha= t are not authenticated and authorized; these are considered untrusted sour= ces." This same consideration is explicitly called out again in Section 8 "= Security Considerations", which repeats that "it is NOT RECOMMENDED to trus= t DSCP markings from devices that are not authenticated and authorized, as = these are considered untrusted sources. This is especially relevant for IoT= , as billions of devices are being connected to IP networks, many of which = have little or no security." --- Source/Date: B. Carpenter 01/12/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.htm= l =20 Comment: "BTW, I noticed that section 5.3 refers to sections 3.1 and 3.2, = which don't exist." Action: The references have been corrected to point to Sections 2.2 (Defaul= t DSCP-to-UP Mapping) and 2.3 (Default UP-to-DSCP Mapping) --- Source/Date: B. Carpenter 01/12/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.htm= l =20 Comment: "Since the QoS characteristics of wired and wireless networks are= quite different, it might in fact be exactly the right place for a diffser= v domain boundary, complete with traffic classification, re-marking and pol= icing." Action: This recommendation has been made, per the suggestion, in Sections = 2.1 and 4.1.1 --- Source/Date: B. Carpenter 01/12/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.htm= l =20 Comment: "If somebody has legitimately marked traffic as CS6 or CS7, we w= ould be arrogant to assume that we know better and the packet can be droppe= d. Saying that it should be re-marked, even to CS0, would be reasonable. RP= L (RFC 6550) is absolutely intended to cross wireless/wired boundaries. I d= on't know whether RPL deployments apply CS6 but it seems entirely reasonabl= e that they might. It's apparently been discussed in 6tisch, which is IEEE = 802.15.4." Action: All six occurrences of the 'recommendation' to drop unused codepoin= ts at the wireless edge are actually already phrased "dropped or remarked",= meeting the above suggestion. --- Source/Date: B. Carpenter 01/12/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14885.htm= l =20 Comment: "Maybe this draft should cite draft-tsvwg-le-phb instead of RFC36= 62?" Action: draft-tsvwg-le-phb is expired; whereas RFC3662 is the current guidi= ng reference for Lower Effort PDB --- Source/Date: T. Jones [forwarded to TSVWG by G. Fairhurst] 02/24/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14925.htm= l=20 Comment: "As requested, I have reviewed draft-ietf-tsvwg-ieee-802-11-01, y= ou 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 happ= y with your explanation of how this works." Action: This addresses D. Black's comment from 1/4/17 "Unfortunately, I'm = not able to review Section 6's discussion of how 802.11 (WiFi) works for co= rrectness, so someone who is an 802.11 expert will need to check that text.= =20 https://www.ietf.org/mail-archive/web/tsvwg/current/msg14883.html=20 --- Source/Date: T. Jones [forwarded to TSVWG by G. Fairhurst] 02/24/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14925.htm= l =20 Comment: " In addition I wanted to verify against a code base that the map= pings were operating correctly. I have included a comparison to the FreeBSD= 80211 stack, which agrees with your description." Action: This comment [and the supplied code] validates 2.2. Default DSCP-to= -UP Mappings operations, specifically the part that reads: "a common pract= ice 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 Mos= t Significant Bits (MSB) of the DSCP are used as the corresponding L2 marki= ngs." --- Source/Date: T. Jones [forwarded to TSVWG by G. Fairhurst] 02/24/17 Reference: https://www.ietf.org/mail-archive/web/tsvwg/current/msg14925.htm= l =20 Comment: " - 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) ^^^^^^^" =20 Action: I cannot discern any difference between the OLD and the NEW; no act= ion taken From nobody Wed May 10 05:41:47 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 5C0A6126DFB; Wed, 10 May 2017 05:41:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149442006934.1705.3901411921595846207@ietfa.amsl.com> Date: Wed, 10 May 2017 05:41:09 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-aqm-dualq-coupled-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 12:41:09 -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 : DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput Authors : Koen De Schepper Bob Briscoe Olga Bondarenko Ing-jyh Tsang Filename : draft-ietf-tsvwg-aqm-dualq-coupled-00.txt Pages : 25 Date : 2017-05-10 Abstract: Data Centre TCP (DCTCP) was designed to provide predictably low queuing latency, near-zero loss, and throughput scalability using explicit congestion notification (ECN) and an extremely simple marking behaviour on switches. However, DCTCP does not co-exist with existing TCP traffic---throughput starves. So, until now, DCTCP could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification defines `DualQ Coupled Active Queue Management (AQM)' to allow scalable congestion controls like DCTCP to safely co-exist with classic Internet traffic. The Coupled AQM ensures that a flow runs at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but without inspecting transport layer flow identifiers. When tested in a residential broadband setting, DCTCP achieved sub-millisecond average queuing delay and zero congestion loss under a wide range of mixes of DCTCP and `Classic' broadband Internet traffic, without compromising the performance of the Classic traffic. The solution also reduces network complexity and eliminates network configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-aqm-dualq-coupled-00 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 10 08:00: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 4572A129BE8 for ; Wed, 10 May 2017 08:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZIydSqA6YEG for ; Wed, 10 May 2017 08:00:15 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 0E6C8129B64 for ; Wed, 10 May 2017 08:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:Cc:References:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=F3AOglJINJE+qL0PtqR63HN8VWe0wEFuokBcB+kmB2I=; b=hlSLWxaJPvAkkheQjIyJGbhi6 mu6GILaqJHCrv6/oFs7qj2AD8zjeQuVF6ZO3YCRH+h3yw15YDhxOLkhaiuNJ6kPQzmL0cKJO5SBio uDv7CwpMOc1EpFpbaeONglgV87W9TteUq8aTJYozzPBm6Thyi4pacSQwETj/W7U3rsTKiVIqAjH0V WDNB+k+/sHjjDCNfCZvxfpooAEqoaZGoGJp+c70g09qtZYp7oiT11qp9BcbevrXeq3svOItXx2gK4 EkAausRbmOO72NMPCyFF8fl5o0CZ36rjhkfKl0w/tsQJMsqAUMVCtob/ziF3jNW62C6WGAo9tyCOd hz9X3DPrg==; Received: from 188.6.208.46.dyn.plus.net ([46.208.6.188]:43108 helo=[192.168.0.4]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1d8T65-0005hA-Ai; Wed, 10 May 2017 16:00:13 +0100 To: Ingemar Johansson S References: Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" , tsvwg IETF list , "Black, David (david.black@emc.com)" From: Bob Briscoe Message-ID: <8377b05d-faa9-47de-6fa2-54ab545deb7a@bobbriscoe.net> Date: Wed, 10 May 2017 16:00:12 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A9E47E17A43BC6CCCAEB4E75" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] Enhanced ECN support in 5G X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:00:17 -0000 This is a multi-part message in MIME format. --------------A9E47E17A43BC6CCCAEB4E75 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Ingemar, [repeating and adding to my reply to your posting on iccrg, cos I overlooked your identical message to tsvwg] Thanks for this. The proposal to do ECN-marking at the RLC layer is important. It will need to consider incremental deployment though, cos there will be loads of user equipment for some years that don't contain any logic to understand ECN at the RLC layer. Incremental ECN deployment at L2 has been solved in various ways. Probably the neatest is how it is being done in TRILL (draft-ietf-trill-ecn-support) (see ecn-encap-guidelines for pointers to other approaches). I've sent you a marked up corrected copy offlist, cos the ECN deployment statements are misleading. * Apple's ECN deployment is primarily on Ethernet and Wifi (50% on latest OSs, 5% on previous). * On mobile-connected devices, Apple enables ECN solely for 3 carriers: T-Mobile, Three, Telstra See video of conference: Networking for the Modern Internet (video requires Safari, or you can look it up in the iOS WWDC app ). Cheers Bob On 07/05/17 10:52, Ingemar Johansson S wrote: > > Hi > > To whom it may concern. > > The submission below is posted to 3GPP RAN2. The intention is to add > support for timely and efficient ECN marking in NR (5G) . This will > make it easier to eventually implement support for L4S in 5G. > > http://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_98/Docs/R2-1704368.zip > > Regards > > Ingemar > > ================================== > > Ingemar Johansson M.Sc. > > Master Researcher > > Ericsson AB > > Wireless Access Networks > > Labratoriegränd 11 > > 971 28, Luleå, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > A mistake is to commit a misunderstanding > Bob Dylan > ================================== > -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------A9E47E17A43BC6CCCAEB4E75 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Ingemar, [repeating and adding to my reply to your posting on iccrg, cos I overlooked your identical message to tsvwg]

Thanks for this. The proposal to do ECN-marking at the RLC layer is important. It will need to consider incremental deployment though, cos there will be loads of user equipment for some years that don't contain any logic to understand ECN at the RLC layer. Incremental ECN deployment at L2 has been solved in various ways. Probably the neatest is how it is being done in TRILL (draft-ietf-trill-ecn-support) (see ecn-encap-guidelines for pointers to other approaches).

I've sent you a marked up corrected copy offlist, cos the ECN deployment statements are misleading.
* Apple's ECN deployment is primarily on Ethernet and Wifi (50% on latest OSs, 5% on previous).
* On mobile-connected devices, Apple enables ECN solely for 3 carriers: T-Mobile, Three, Telstra
   See video of conference: Networking for the Modern Internet (video requires Safari, or you can look it up in the iOS WWDC app).

Cheers



Bob


On 07/05/17 10:52, Ingemar Johansson S wrote:

Hi

To whom it may concern.

The submission below is posted to 3GPP RAN2. The intention is to add support for timely and efficient ECN marking in NR (5G) . This will make it easier to eventually implement support for L4S in 5G.

 

http://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_98/Docs/R2-1704368.zip

 

Regards

Ingemar

 

==================================

Ingemar Johansson  M.Sc.

Master Researcher

 

Ericsson AB

Wireless Access Networks

Labratoriegränd 11

971 28, Luleå, Sweden

Phone +46-1071 43042

SMS/MMS +46-73 078 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
                     Bob Dylan
==================================

 


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------A9E47E17A43BC6CCCAEB4E75-- From nagesh.shamnur@huawei.com Thu May 11 22:21: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 5C482129508 for ; Thu, 11 May 2017 22:21:19 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 5ghIitpMxTgF for ; Thu, 11 May 2017 22:21:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9EB01294EC for ; Thu, 11 May 2017 22:15:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGL22700; Fri, 12 May 2017 05:15:10 +0000 (GMT) Received: from DGGEMA404-HUB.china.huawei.com (10.3.20.45) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 12 May 2017 06:15:09 +0100 Received: from DGGEMA504-MBS.china.huawei.com ([169.254.3.23]) by DGGEMA404-HUB.china.huawei.com ([10.3.20.45]) with mapi id 14.03.0301.000; Fri, 12 May 2017 13:14:51 +0800 From: Nagesh shamnur To: "tsvwg@ietf.org" CC: Ashutosh prakash Thread-Topic: Query regarding handling of invalid message in SCTP Thread-Index: AdLK3gPtOt90RU28SIyZyOEknARdKQ== Date: Fri, 12 May 2017 05:14:50 +0000 Message-ID: <4AC96705FB868F42B2075BA50F806DEB5670553A@DGGEMA504-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.209.60] Content-Type: multipart/alternative; boundary="_000_4AC96705FB868F42B2075BA50F806DEB5670553ADGGEMA504MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.591544DF.00DF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.23, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 699f1b8ea12cd6205e0d99de54920dd3 Archived-At: Subject: [tsvwg] Query regarding handling of invalid message in SCTP X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 05:35:23 -0000 --_000_4AC96705FB868F42B2075BA50F806DEB5670553ADGGEMA504MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Group, Good Morning. This mail is to clarify regarding the handlin= g of SCTP messages in a particular scenario as given below: RFC 4960 Snippet: If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it SHOULD respond with an ABORT chunk. It SHOULD also specify the cause of abort, such as the type of the missing mandatory parameters, etc., by including the error cause parameters with the ABORT chunk. The Verification Tag field in the common header of the outbound SCTP packet containing the ABORT chunk MUST be set to the Initiate Tag value of the peer. When a SCTP client in COOKIE-WAIT state receives INIT-ACK b= ut with invalid parameter or chunk length, then as per the above RFC snippe= t, it says to send ABORT to peer, but doesn't mentions the handling with re= spect to TCB. Whether the TCB should be freed and endpoint down indication = needs to be given to application or wait for subsequent INIT-ACK from peer = hoping that the subsequent message would correct this issue and hence resul= t in normal association establishment. What would be the right way of handling such an situation? Regards, Nagesh. --_000_4AC96705FB868F42B2075BA50F806DEB5670553ADGGEMA504MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Group,

        &nbs= p;       Good Morning. This mail is to clarif= y regarding the handling of SCTP messages in a particular scenario as given= below:

 

RFC 4960 Snippet:

If an endpoint r= eceives an INIT, INIT ACK, or COOKIE ECHO chunk but

   dec= ides not to establish the new association due to missing mandatory

   par= ameters in the received INIT or INIT ACK, invalid parameter

   val= ues, or lack of local resources, it SHOULD respond with an ABORT=

   chu= nk.  It SHOULD also specify the cause of abort, such as the type<= /o:p>

   of = the missing mandatory parameters, etc., by including the error

   cau= se parameters with the ABORT chunk.  The Verification Tag field in

   the= common header of the outbound SCTP packet containing the ABORT<= /span>

   chu= nk MUST be set to the Initiate Tag value of the peer.

 

        &nbs= p;       When a SCTP client in COOKIE-WAIT st= ate receives INIT-ACK but with invalid parameter or chunk length, then as p= er the above RFC snippet, it says to send ABORT to peer, but doesn’t = mentions the handling with respect to TCB. Whether the TCB should be freed and endpoint down indication needs to be g= iven to application or wait for subsequent INIT-ACK from peer hoping that t= he subsequent message would correct this issue and hence result in normal a= ssociation establishment.

        &nbs= p;       What would be the right way of handl= ing such an situation?

 

Regards,

Nagesh.

 

--_000_4AC96705FB868F42B2075BA50F806DEB5670553ADGGEMA504MBSchi_-- From nobody Fri May 12 06:11:07 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 3F84B129AEA for ; Fri, 12 May 2017 06:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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, T_KAM_HTML_FONT_INVALID=0.01, 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 2cBBQ9Vcep5n for ; Fri, 12 May 2017 06:11:01 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 2823E129B7E for ; Fri, 12 May 2017 06:05:38 -0700 (PDT) X-AuditID: c1b4fb2d-b25ff7000000196b-99-5915b31f4f82 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 82.8D.06507.F13B5195; Fri, 12 May 2017 15:05:36 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 12 May 2017 15:05:35 +0200 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=YuOcgsMIiQgjQmaD8D8Fou5fI3o1ZqK4svZDPIF2vLY=; b=fuhgcMnxW924EXKUWnmzx0TdAkE7hYv0faVjSH+142wFH570a2t9cS8F2pSMzUbasp45xZwDyHtizsJr1s5gcm+FesXPnHtPC13zzChszv/3SEcQGZKX+crZIZadDHSViWmV8YufRPBv6b139qH13jKZbz3E58FyHFy6wdjo+8M= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB347.eurprd07.prod.outlook.com (10.141.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 12 May 2017 13:05:34 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0%15]) with mapi id 15.01.1084.015; Fri, 12 May 2017 13:05:34 +0000 From: Ingemar Johansson S To: Bob Briscoe CC: "De Schepper, Koen (Nokia - BE/Antwerp)" , tsvwg IETF list , "Black, David (david.black@emc.com)" Thread-Topic: Enhanced ECN support in 5G Thread-Index: AdLHFxcSu2xsg/6KTy+IWITHA+tFTwChwiQAAGB9m8A= Date: Fri, 12 May 2017 13:05:33 +0000 Message-ID: References: <8377b05d-faa9-47de-6fa2-54ab545deb7a@bobbriscoe.net> In-Reply-To: <8377b05d-faa9-47de-6fa2-54ab545deb7a@bobbriscoe.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bobbriscoe.net; dkim=none (message not signed) header.d=none;bobbriscoe.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.85] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB347; 7:argBRyBfMzYvzOrECXjjDAr9fh7RAMBFz+WX7yZdJtpxIUNyHlD+6+eZYSdlJ5sIymPEUjsyVpkkC7SvN9Vh+xfjkkQIbatmB23SeSkuePFY5VUXl2Ac/N3OWaZtdtkpzu0lcI7nYkQ/ZoVoMuCFc/gUSbbGH/6Jel0+7fzMtrDR5gKx9rYPsCpQQLqDb2dlJXt+LEDJ1hoK6WT7QS8Psf5W8JALrR9iP5H8ntUgdD9C0UhGsc1xmCwfwVIs+aM9JqofTbRq720lV5lw/KETeM7U+OokWPalykQ4kiT4kX2BOXhX23lFjJQ3Jss7t+Qy+a6rScGq2PLlbuqiW8gOhg== x-ms-office365-filtering-correlation-id: 5e1e3c07-5758-402e-c8c7-08d49937937c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB347; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(23117731428927)(171798753090565)(202460600054446)(21748063052155)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148); SRVR:DB4PR07MB347; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB347; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39840400002)(39850400002)(39450400003)(39400400002)(39410400002)(51914003)(24454002)(8936002)(2906002)(3660700001)(55016002)(54356999)(3280700002)(81166006)(7736002)(606005)(6246003)(9686003)(236005)(6506006)(53936002)(229853002)(2950100002)(8676002)(5660300001)(8666007)(74316002)(8558605004)(53546009)(50986999)(7696004)(4326008)(76176999)(25786009)(478600001)(99286003)(561944003)(5250100002)(3846002)(966004)(790700001)(102836003)(6116002)(7906003)(6306002)(66066001)(54896002)(38730400002)(6436002)(53376002)(9326002)(33656002)(6916009)(2900100001)(110136004)(189998001)(19623455009); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB347; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3485657BD30A581BD162E10C2E20DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2017 13:05:33.9199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB347 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfSzUcRzH973f7373I7e+XYdPjtJVSw8eSjNKkc2yNiV/NKzR4TcUh/tJ sdUwD4UaJnmo7vK0ydAUWTi5hLJ0oWU1jGwVPWkepqTcfWvz3+vzeb+/n6d9WUrSJrRio5QJ nEqpiJYzpnRJwEMve9v75oFOtbotrk1P6kSuT8c1Qtfu+SqBa/fnEcaT9pka0wt9urrKaJ/K ykWBT9p8OeNHB5m6h3PRUYmcyvHQadPI3FY9E3f7zIXB4jUpqDg4G5mwgPdB//PfdDYyZSW4 C8E7tVZAgl4EE29eGxUaX6WgoSdDRJQiAWSnq4UkGEcwlX9TYCjGYHeo0S2gbMSyUrwNarK2 GjwUbkKgr2sWGjzr8XbIy5kSGViK7aC5sewf7wftaL2R6ZW3hYs5lIHFOAi6ejIp0qwAQWtB hlEwwV7Qp9MwBkbYBsYWRmkDU9gS3k6qBWQ7DJVtLynC5vDp/bJxaoRLELR31BsnBWwL403H iMcGBtQ5yOABnENB1rUmERF8QV+qFRH/RUirPkgwCubGNhBHLoLuzN2Ev69cSG1B2BqGKtJE pOQfIdSMdCByCCsYGbqC8tCO0lVjE46Fxa+lqNS4/zp4VjJJk7wDDF8vZAjvguo70xRheyhe 1tGr8xokuovMeY7nYyL2Ojtwqqgwno9VOii5hEa08qc6H/yyb0G104d1CLNIbibWVEsDJUJF Ip8Uo0PAUnKpWNNgHigRhyuSkjlVbIjqXDTH65CMpeWWYk+tPkCCIxQJ3FmOi+NU/1UBa2KV gnxdVC52A6kWjJ+HIn7zkndvOxPq7WYVWjZxdDi+od8/1u1WctG0meze5eDHhf5zXmnWP2m0 pKdPRs86O5268TF/E+XIHz8/M5teNOPxRVtyJFV6wKlirbzyR5inIkZom9q+sflRX1Xzh5YQ 2QvZosNgh8z3xKWk5M5XBSPj5f7f5DQfqdizk1Lxir8T+NrqTwMAAA== Archived-At: Subject: Re: [tsvwg] Enhanced ECN support in 5G X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 13:11:05 -0000 --_000_DB4PR07MB3485657BD30A581BD162E10C2E20DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yes, I hope that it will be possible to land this, we will know more by the= end of next week. And thanks for the clarifications around Apple=B4s ECN deployment. /Ingemar From: Bob Briscoe [mailto:ietf@bobbriscoe.net] Sent: den 10 maj 2017 17:00 To: Ingemar Johansson S Cc: De Schepper, Koen (Nokia - BE/Antwerp) ; tsvwg IETF list ; Black, David (david.black@emc.com= ) Subject: Re: Enhanced ECN support in 5G Ingemar, [repeating and adding to my reply to your posting on iccrg, cos I = overlooked your identical message to tsvwg] Thanks for this. The proposal to do ECN-marking at the RLC layer is importa= nt. It will need to consider incremental deployment though, cos there will = be loads of user equipment for some years that don't contain any logic to u= nderstand ECN at the RLC layer. Incremental ECN deployment at L2 has been s= olved in various ways. Probably the neatest is how it is being done in TRIL= L (draft-ietf-trill-ecn-support) (see ecn-encap-guidelines for pointers to = other approaches). I've sent you a marked up corrected copy offlist, cos the ECN deployment st= atements are misleading. * Apple's ECN deployment is primarily on Ethernet and Wifi (50% on latest O= Ss, 5% on previous). * On mobile-connected devices, Apple enables ECN solely for 3 carriers: T-M= obile, Three, Telstra See video of conference: Networking for the Modern Internet (video requires Safari, or you c= an look it up in the iOS WWDC app). Cheers Bob On 07/05/17 10:52, Ingemar Johansson S wrote: Hi To whom it may concern. The submission below is posted to 3GPP RAN2. The intention is to add suppor= t for timely and efficient ECN marking in NR (5G) . This will make it easie= r to eventually implement support for L4S in 5G. http://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_98/Docs/R2-1704368.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 A mistake is to commit a misunderstanding Bob Dylan =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 -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_DB4PR07MB3485657BD30A581BD162E10C2E20DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Yes, I hope that it= will be possible to land this, we will know more by the end of next week.

And thanks for the = clarifications around Apple=B4s ECN deployment.

 

/Ingemar=

 

From:= Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: den 10 maj 2017 17:00
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@noki= a-bell-labs.com>; tsvwg IETF list <tsvwg@ietf.org>; Black, David (= david.black@emc.com) <david.black@emc.com>
Subject: Re: Enhanced ECN support in 5G

 

Ingemar, [repeating a= nd adding to my reply to your posting on iccrg, cos I overlooked your ident= ical message to tsvwg]

Thanks for this. The proposal to do ECN-marking at the RLC layer is importa= nt. It will need to consider incremental deployment though, cos there will = be loads of user equipment for some years that don't contain any logic to u= nderstand ECN at the RLC layer. Incremental ECN deployment at L2 has been solved in various ways. Probably= the neatest is how it is being done in TRILL (draft-ietf-trill-ecn-support= ) (see ecn-encap-guidelines for pointers to other approaches).

I've sent you a marked up corrected copy offlist, cos the ECN deployment st= atements are misleading.
* Apple's ECN deployment is primarily on Ethernet and Wifi (50% on latest O= Ss, 5% on previous).
* On mobile-connected devices, Apple enables ECN solely for 3 carriers: T-M= obile, Three, Telstra
   See video of conference: Networking for the Modern Internet (video requires Safari, or you = can look it up in the iOS= WWDC app).

Cheers



Bob

On 07/05/17 10:52, Ingemar Johansson S wrote:

Hi

To whom it may concern.

The submission below is posted to 3GPP RAN2. The int= ention is to add support for timely and efficient ECN marking in NR (5G) . = This will make it easier to eventually implement support for L4S in 5G.

 

http://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_= 98/Docs/R2-1704368.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 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

&nbs= p;

A mistake is to commit a misunderstanding
       =              &n= bsp;Bob Dylan
=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

 



-- 
________________________________________________________________<=
/o:p>
Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/
--_000_DB4PR07MB3485657BD30A581BD162E10C2E20DB4PR07MB348eurprd_-- From nobody Fri May 12 06:39:59 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 0BF84127876 for ; Fri, 12 May 2017 06:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.688 X-Spam-Level: X-Spam-Status: No, score=-4.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_HELO_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 XnojQGHkYD1J for ; Fri, 12 May 2017 06:39:54 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) (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 83752126C2F for ; Fri, 12 May 2017 06:34:40 -0700 (PDT) Received: from [85.158.136.83] by server-10.bemta-5.messagelabs.com id B2/81-01734-FE9B5195; Fri, 12 May 2017 13:34:39 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRWlGSWpSXmKPExsWi75nTrftqp2i kwcaXfBZbD69ltzj6cAGrxczX21gsjr25y+bA4vHq/gVWjyNHZrN4/Pp6lc1jyZKfTAEsUayZ eUn5FQmsGfOn32Iq+DmJsWJvu00D44Q2xi5GLg4hge2MEs/+HmeCcA4zSjy+fBTK2cQo8W/7O +YuRk4ONgFXiaO77rCD2CICcRKL3xxhBbGZBZIlTjxfwAhiCwuoS0zofgVVoyGxbdNsKNtIYs bb2ywgNouAqsSH67fBZvIKhEtsPr4Z6oyHjBK7Hx1g62Lk4OAUiJbYOKsCpIZRQFbiS+NqZoh d4hK3nsxnArElBAQkluw5zwxhi0q8fPwP6p48iZNrnrNAzBeUODnzCZgtBLT3xKE5bBMYRWYh GTULScssJC0QcT2JG1OnsEHY2hLLFr5mhrB1JWb8O8SCLL6AkX0Vo0ZxalFZapGukZleUlFme kZJbmJmjq6hgalebmpxcWJ6ak5iUrFecn7uJkZghNYzMDDuYLw92e8QoyQHk5Io7yVW0Ughvq T8lMqMxOKM+KLSnNTiQ4wyHBxKErwbdgDlBItS01Mr0jJzgKkCJi3BwaMkwusNkuYtLkjMLc5 Mh0idYlSUEud9DZIQAElklObBtcHS0yVGWSlhXkYGBgYhnoLUotzMElT5V4ziHIxKwry3Qabw ZOaVwE1/BbSYCWhx/x9hkMUliQgpqQbGWmYflg0nbW/mrb0srLDbxMx89ZX152ZNSmp/tm3yB RV5x34eDvHm0z9yb31QmLZmkuBdvechf2fH+zxi2cjHOWnqQv25XGt+hqxhbZv/vvTKksB3Os z7nky331WteKOoZ53Ls5f7g+Mi9afG9t3bnvzsIudquzMaiTcc6oz+nuj5tPDARMsqIyWW4ox EQy3mouJEAG6lMI1KAwAA X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-15.tower-36.messagelabs.com!1494596066!83239433!9 X-Originating-IP: [47.73.108.139] X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3131 invoked from network); 12 May 2017 13:34:34 -0000 Received: from vgdpm13vr.vodafone.com (HELO voxe01hw.internal.vodafone.com) (47.73.108.139) by server-15.tower-36.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 May 2017 13:34:34 -0000 Received: from VOEXH07W.internal.vodafone.com (47.73.211.205) by edge1.vodafone.com (195.232.244.46) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 12 May 2017 15:34:27 +0200 Received: from VOEXC06W.internal.vodafone.com (145.230.101.26) by VOEXH07W.internal.vodafone.com (47.73.211.205) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 12 May 2017 15:34:27 +0200 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.82]) by VOEXC06W.internal.vodafone.com ([192.168.89.204]) with mapi id 14.03.0294.000; Fri, 12 May 2017 15:34:26 +0200 From: "Smith, Kevin, (R&D) Vodafone Group" To: Ingemar Johansson S , Bob Briscoe CC: "Black, David (david.black@emc.com)" , "tsvwg IETF list" Thread-Topic: Enhanced ECN support in 5G Thread-Index: AQHSyyFBD9Kzp5YtskuXuq4t7ay8AqHwrI4Q Date: Fri, 12 May 2017 13:34:26 +0000 Message-ID: References: <8377b05d-faa9-47de-6fa2-54ab545deb7a@bobbriscoe.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A4BAAB326B17CE40B45830B745F70F1001054C3637VOEXM17Winter_" MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] Enhanced ECN support in 5G X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 13:39:57 -0000 --_000_A4BAAB326B17CE40B45830B745F70F1001054C3637VOEXM17Winter_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ingemar, all, Just a thought - we've presented before on the opportunity for end-to-end c= ongestion controls to account for the highly-volatile radio access link. Wi= th ECN marking proposed at the RLC, does this create that opportunity? i.e.= include the current radio conditions as a factor in the 'when to mark' L4S= algorithm. 'Volatility' could be gleaned from the same logic used to determine the Rec= eption buffering, or possibly from the UE's Channel Quality Indicators that= are reported to the MAC scheduler. What do you reckon? All best, Kevin From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Ingemar Johansson = S Sent: 12 May 2017 14:06 To: Bob Briscoe Cc: Black, David (david.black@emc.com) ; tsvwg IETF li= st Subject: Re: [tsvwg] Enhanced ECN support in 5G Hi Yes, I hope that it will be possible to land this, we will know more by the= end of next week. And thanks for the clarifications around Apple=B4s ECN deployment. /Ingemar From: Bob Briscoe [mailto:ietf@bobbriscoe.net] Sent: den 10 maj 2017 17:00 To: Ingemar Johansson S > Cc: De Schepper, Koen (Nokia - BE/Antwerp) >; tsvwg IETF list >; Black, David (david.black@emc.com) > Subject: Re: Enhanced ECN support in 5G Ingemar, [repeating and adding to my reply to your posting on iccrg, cos I = overlooked your identical message to tsvwg] Thanks for this. The proposal to do ECN-marking at the RLC layer is importa= nt. It will need to consider incremental deployment though, cos there will = be loads of user equipment for some years that don't contain any logic to u= nderstand ECN at the RLC layer. Incremental ECN deployment at L2 has been s= olved in various ways. Probably the neatest is how it is being done in TRIL= L (draft-ietf-trill-ecn-support) (see ecn-encap-guidelines for pointers to = other approaches). I've sent you a marked up corrected copy offlist, cos the ECN deployment st= atements are misleading. * Apple's ECN deployment is primarily on Ethernet and Wifi (50% on latest O= Ss, 5% on previous). * On mobile-connected devices, Apple enables ECN solely for 3 carriers: T-M= obile, Three, Telstra See video of conference: Networking for the Modern Internet (video requires Safari, or you c= an look it up in the iOS WWDC app). Cheers Bob On 07/05/17 10:52, Ingemar Johansson S wrote: Hi To whom it may concern. The submission below is posted to 3GPP RAN2. The intention is to add suppor= t for timely and efficient ECN marking in NR (5G) . This will make it easie= r to eventually implement support for L4S in 5G. http://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_98/Docs/R2-1704368.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 A mistake is to commit a misunderstanding Bob Dylan =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 -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_A4BAAB326B17CE40B45830B745F70F1001054C3637VOEXM17Winter_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ingemar, all,

 

Just a thought – we’ve presented before on the opportunity= for end-to-end congestion controls to account for the highly-volatile radi= o access link. With ECN marking proposed at the RLC, does this create that opportunity? i.e. include the current radio con= ditions as a factor in the ‘when to mark’ L4S algorithm.

 

‘Volatility’ could be gleaned from the same logic used to = determine the Reception buffering, or possibly from the UE’s Channel = Quality Indicators that are reported to the MAC scheduler.

 

What do you reckon?

 

All best,

Kevin

 

 

 

 

F= rom: tsvwg [mail= to:tsvwg-bounces@ietf.org] On Behalf Of Ingemar Johansson S
Sent: 12 May 2017 14:06
To: Bob Briscoe <ietf@bobbriscoe.net>
Cc: Black, David (david.black@emc.com) <david.black@emc.com>; = tsvwg IETF list <tsvwg@ietf.org>
Subject: Re: [tsvwg] Enhanced ECN support in 5G

 

Hi

 

Yes,= I hope that it will be possible to land this, we will know more by the end= of next week.

And = thanks for the clarifications around Apple=B4s ECN deployment.

 

/Ing= emar

 

F= rom: Bob Briscoe= [mailto:ietf@bobbriscoe.net]
Sent: den 10 maj 2017 17:00
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.com= >; tsvwg IETF list <tsvwg@ietf.org<= /a>>; Black, David (david.black@e= mc.com) <david.black@emc.com>
Subject: Re: Enhanced ECN support in 5G

 

= Ingemar, [repeating and adding to my reply to your posting on iccrg, cos I = overlooked your identical message to tsvwg]

Thanks for this. The proposal to do ECN-marking at the RLC layer is importa= nt. It will need to consider incremental deployment though, cos there will = be loads of user equipment for some years that don't contain any logic to u= nderstand ECN at the RLC layer. Incremental ECN deployment at L2 has been solved in various ways. Probably= the neatest is how it is being done in TRILL (draft-ietf-trill-ecn-support= ) (see ecn-encap-guidelines for pointers to other approaches).

I've sent you a marked up corrected copy offlist, cos the ECN deployment st= atements are misleading.
* Apple's ECN deployment is primarily on Ethernet and Wifi (50% on latest O= Ss, 5% on previous).
* On mobile-connected devices, Apple enables ECN solely for 3 carriers: T-M= obile, Three, Telstra
   See video of conference: Networking for the Modern Internet (video requires Safari, or you = can look it up in the iOS= WWDC app).

Cheers



Bob

On 07/05/17 10:52, Ingemar Joha= nsson S wrote:

Hi

To whom it may concern.

The submission below is posted = to 3GPP RAN2. The intention is to add support for timely and efficient ECN = marking in NR (5G) . This will make it easier to eventually implement suppo= rt for L4S in 5G.

 

http://www.3gpp.org/ftp/T= SG_RAN/WG2_RL2/TSGR2_98/Docs/R2-1704368.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 R= esearcher

 

Ericsson= AB

Wireless= Access Networks

Labrator= iegr=E4nd 11

971 28, = Lule=E5, Sweden

Phone &#= 43;46-1071 43042

SMS/MMS = +46-73 078 3289

<= a href=3D"mailto:ingemar.s.johansson@ericsson.com">ingemar.s.johansson@erics= son.com

<= a href=3D"www.ericsson.com">www.ericsson.com

 

A mistake is to commit a misunderstanding
       =              &n= bsp;Bob Dylan
=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=

 

 

-- 
_________________________________________________=
_______________
Bob Briscoe      &n=
bsp;            =
;            http://bobbriscoe.net/
--_000_A4BAAB326B17CE40B45830B745F70F1001054C3637VOEXM17Winter_-- From nobody Fri May 12 10:28:38 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 6E39B1293F4; Fri, 12 May 2017 10:28:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: gorry@erg.abdn.ac.uk, spencerdawkins.ietf@gmail.com, tsvwg-chairs@ietf.org, tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149461011735.13500.4585163835795324657.idtracker@ietfa.amsl.com> Date: Fri, 12 May 2017 10:28:37 -0700 Archived-At: Subject: [tsvwg] tsvwg - New Meeting Session Request for IETF 99 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 17:28:37 -0000 A new meeting session request has just been submitted by Gorry Fairhurst, a Chair of the tsvwg working group. --------------------------------------------------------- Working Group Name: Transport Area Working Group Area Name: Transport Area Session Requester: Gorry Fairhurst Number of Sessions: 2 Length of Session(s): 1 Hour, 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: intarea tsvarea iccrg aqm rmcat tcpm mptcp taps ippm quic tcpinc rtgwg opsarea Second Priority: dtn rtcweb v6ops tram dispatch Third Priority: artarea ccamp People who must be present: David L. Black Gorry Fairhurst Spencer Dawkins Wesley Eddy Mirja Kuehlewind Resources Requested: Special Requests: [If rtcweb has 2 sessions, 1 should not conflict] [Must not conflict with Transport Area BoFs] --------------------------------------------------------- From nobody Fri May 12 11:56: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 DF71B129AD3 for ; Fri, 12 May 2017 11:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 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, T_KAM_HTML_FONT_INVALID=0.01, 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 tHOuvGM5PayQ for ; Fri, 12 May 2017 11:56:21 -0700 (PDT) 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 12299128CD5 for ; Fri, 12 May 2017 11:52:34 -0700 (PDT) X-AuditID: c1b4fb30-663149a00000015f-18-59160471126b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 96.BF.00351.17406195; Fri, 12 May 2017 20:52:33 +0200 (CEST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 12 May 2017 20:52:32 +0200 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=ZyIN8WRO/COMEdP63VMdssirPaNbwBlRsfymRs/PW9g=; b=VfhjTBigtbRW3PylD5Qi+iU83sLF91qr9yqqkUksjxMS3278rYSOK5d/YyQiazkbYzUJ+TJTEmhptiG7zCt1QTHdx99Etx/cqknNL3ow3i2WN3v7JMfSNF8nWqVKuRYWdH3LKxPWrGT7HUh1GRdr3azXIm1O3P3PrWj4Cxe3mYo= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB347.eurprd07.prod.outlook.com (10.141.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 12 May 2017 18:52:31 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4ccf:ee16:33c7:4af0%15]) with mapi id 15.01.1084.015; Fri, 12 May 2017 18:52:31 +0000 From: Ingemar Johansson S To: "Smith, Kevin, (R&D) Vodafone Group" , "Bob Briscoe" CC: "Black, David (david.black@emc.com)" , "tsvwg IETF list" Thread-Topic: Enhanced ECN support in 5G Thread-Index: AdLHFxcSu2xsg/6KTy+IWITHA+tFTwChwiQAAGB9m8AAARjJAAAAhEcw Date: Fri, 12 May 2017 18:52:31 +0000 Message-ID: References: <8377b05d-faa9-47de-6fa2-54ab545deb7a@bobbriscoe.net> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: vodafone.com; dkim=none (message not signed) header.d=none;vodafone.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [213.113.27.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB347; 7:ljQzzM9mfC0APtZpM7CzLje/StSPcZy9Q8amM7WAoDF2wiDv+IfcADK7O3jmLHqO1qF0GAqw4wcMrpa6BhTU9dHKNQd/jyeYRLzi0D0/qj/fDZUoitWAPvAXrjHWFJN7881evR7x8rSqZxl6fUhNtDVOdbcYC/jWXk/mSLlWKF9fBWYjJ+I6lq9cWszkUPreZHqgJg9kCiAE2kuj9QWSxaNCLutSk+lByz5InoUzLDBmQk/KMEnRib1x+QSftrjJU1tfRntR13YtTyF2E658IbNkuZIRzyBt0k0Q3HS9VKwmzrxCVQl4Haxw5iNKt9iEJl91KTffXhO7LggviIEgKA== x-ms-office365-filtering-correlation-id: a89d3a8e-866e-4bcd-e46a-08d499680b8f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DB4PR07MB347; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67444318432085)(37575265505322)(23117731428927)(171798753090565)(202460600054446)(21748063052155)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148); SRVR:DB4PR07MB347; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB347; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39400400002)(39410400002)(39850400002)(39840400002)(39450400003)(39860400002)(24454002)(51914003)(76094002)(561944003)(5250100002)(25786009)(53936002)(99286003)(478600001)(53376002)(2900100001)(38730400002)(6436002)(33656002)(86362001)(189998001)(790700001)(966004)(6116002)(102836003)(3846002)(66066001)(7906003)(6306002)(9326002)(54896002)(93886004)(8676002)(236005)(6506006)(229853002)(2950100002)(54906002)(5660300001)(8656002)(9686003)(8936002)(3660700001)(606005)(3280700002)(7736002)(81166006)(6246003)(54356999)(2906002)(55016002)(4326008)(7696004)(50986999)(76176999)(8666007)(53546009)(8558605004)(74316002)(19623455009)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB347; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348EAF9A4DDFB9E039117F8C2E20DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2017 18:52:31.0916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB347 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyyUcRzH932e5+4et26+HZdPfqzcakpcQqWmloVds379oTBbru4Z6vzo HpSm7ZRRyKxopOacH0VaEWIV5zqNWWUisnHkRyPG+sNplnL3XFv/vd6fz/v7+bUvTYr1PGc6 PjGFUScqVFK+kCqNeHXA+zK1KdLnll4S0PzumSCga0LLC5j8qiMC3s+P8o9Q8jlTH09uNJZR 8qqqX4S8oOQ5OkVFCQOVjCo+jVHvPhwjjMsZOJ2c/wJdzX89SGjQfBnKRXY0YH+oWK5bZyEt xkYEnV31PE50I6guzacsgsJ3SGjJahRwmfsEZHYMkZyYQLBofiqwFOPjQKg1mK2FHfFFmC0w URYmsRKWckcICztgDyjMmxNwnh3Q0lhm41DoLW3jW5jC22FycN5aR4SjoGup1ta5gYDqmdX1 zjRthyPgbraXxYOwG5jMY7ZeTjAyVU5wy2GoevOJ5FgCs5Nr1t0QvodgpfUmZakD2B2MRVc4 jxv0l+dZjwE4jwSzbsF2pePQ8HOcz3EBgu7qGO5tPJiqXDn/QwQzmrcCTiwRMD06ZJvCFQYq b9gSU3zQF3bbTuEMowO3USHa+eC/yTlOgqbsZiuL8EboKZ2iuLgMhouL+BzvgpqKHyTH3lCy ZqD+j2uRoA5JWIY9nxDr6ytj1PEXWDYpUZbIpDSi9X/V2bTq04pmvwcZEKaRdINovEMSKeYp 0tj0BAMCmpQ6isKW10MipSL9GqNOOqdOVTGsAbnQlNRJFNTeFyHGsYoU5hLDJDPqf1mCtnPW IMLeWaX0atvmog3XaeorxX8SQqUxbvuwO5NReFQY7Fv8Zaz/erR/XUimQ/bceEae18mzqZ4n pnv2By1+9niiM4dUx7brK7Q+hw7ubarw83jcm/Xbj5bpa4Z10famb5mPzmS6BG8JC9d2Hluo 9NC25xBC12nNyx608nFhc+sHYquUYuMUezxJNav4C0uZ93NTAwAA Archived-At: Subject: Re: [tsvwg] Enhanced ECN support in 5G X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 18:56:24 -0000 --_000_DB4PR07MB348EAF9A4DDFB9E039117F8C2E20DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yes, the potentially very varying throughput characteristics of 5G makes L4= S technology very attractive. Initial experiments have shown that L4S can t= rack fast changing throughput very well, I have so far only mustered with s= ome initial experiments but they are very promising, others may have better= results to show. How to do the actual L4S ECN marking is implemented (in 5G) is likely subje= ct to research work and may be proprietary implementation details, I am no= t sure that a standards text will go into details around ECN marking, in so= me form it resembles scheduling and link adaptation algorithms, which are b= oth proprietary. The important part standards wise as I see it is to enable that the ECN mar= king is carried efficiently. The proposed 3GPP contribution enables this fo= r 5G-NR so that it is possible to ECN mark packets on the RLC layers. Regards /Ingemar From: Smith, Kevin, (R&D) Vodafone Group [mailto:Kevin.Smith@vodafone.com] Sent: den 12 maj 2017 15:34 To: Ingemar Johansson S ; Bob Briscoe Cc: Black, David (david.black@emc.com) ; tsvwg IETF li= st Subject: RE: Enhanced ECN support in 5G Hi Ingemar, all, Just a thought - we've presented before on the opportunity for end-to-end c= ongestion controls to account for the highly-volatile radio access link. Wi= th ECN marking proposed at the RLC, does this create that opportunity? i.e.= include the current radio conditions as a factor in the 'when to mark' L4S= algorithm. 'Volatility' could be gleaned from the same logic used to determine the Rec= eption buffering, or possibly from the UE's Channel Quality Indicators that= are reported to the MAC scheduler. What do you reckon? All best, Kevin From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Ingemar Johansson = S Sent: 12 May 2017 14:06 To: Bob Briscoe > Cc: Black, David (david.black@emc.com) >; tsvwg IETF list > Subject: Re: [tsvwg] Enhanced ECN support in 5G Hi Yes, I hope that it will be possible to land this, we will know more by the= end of next week. And thanks for the clarifications around Apple=B4s ECN deployment. /Ingemar From: Bob Briscoe [mailto:ietf@bobbriscoe.net] Sent: den 10 maj 2017 17:00 To: Ingemar Johansson S > Cc: De Schepper, Koen (Nokia - BE/Antwerp) >; tsvwg IETF list >; Black, David (david.black@emc.com) > Subject: Re: Enhanced ECN support in 5G Ingemar, [repeating and adding to my reply to your posting on iccrg, cos I = overlooked your identical message to tsvwg] Thanks for this. The proposal to do ECN-marking at the RLC layer is importa= nt. It will need to consider incremental deployment though, cos there will = be loads of user equipment for some years that don't contain any logic to u= nderstand ECN at the RLC layer. Incremental ECN deployment at L2 has been s= olved in various ways. Probably the neatest is how it is being done in TRIL= L (draft-ietf-trill-ecn-support) (see ecn-encap-guidelines for pointers to = other approaches). I've sent you a marked up corrected copy offlist, cos the ECN deployment st= atements are misleading. * Apple's ECN deployment is primarily on Ethernet and Wifi (50% on latest O= Ss, 5% on previous). * On mobile-connected devices, Apple enables ECN solely for 3 carriers: T-M= obile, Three, Telstra See video of conference: Networking for the Modern Internet (video requires Safari, or you c= an look it up in the iOS WWDC app). Cheers Bob On 07/05/17 10:52, Ingemar Johansson S wrote: Hi To whom it may concern. The submission below is posted to 3GPP RAN2. The intention is to add suppor= t for timely and efficient ECN marking in NR (5G) . This will make it easie= r to eventually implement support for L4S in 5G. http://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_98/Docs/R2-1704368.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 A mistake is to commit a misunderstanding Bob Dylan =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 -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --_000_DB4PR07MB348EAF9A4DDFB9E039117F8C2E20DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Yes, the potentiall= y very varying throughput characteristics of 5G makes L4S technology very a= ttractive. Initial experiments have shown that L4S can track fast changing = throughput very well, I have so far only mustered with some initial experiments but they are very promising, o= thers may have better results to show.

 

How to do the actua= l L4S ECN marking is implemented (in 5G) is likely subject to research work= and  may be proprietary implementation details, I am not sure that a = standards text will go into details around ECN marking, in some form it resembles scheduling and link adaptation algo= rithms, which are both proprietary.

 

The important part = standards wise as I see it is to enable that the ECN marking is carried eff= iciently. The proposed 3GPP contribution enables this for 5G-NR so that it = is possible to ECN mark packets on the RLC layers.

 

Regards<= /span>

/Ingemar=

 

From:= Smith, Kevin, (R&D) Vodafone Group [m= ailto:Kevin.Smith@vodafone.com]
Sent: den 12 maj 2017 15:34
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; Bo= b Briscoe <ietf@bobbriscoe.net>
Cc: Black, David (david.black@emc.com) <david.black@emc.com>; = tsvwg IETF list <tsvwg@ietf.org>
Subject: RE: Enhanced ECN support in 5G

 

Hi Inge= mar, all,

&n= bsp;

Just a = thought – we’ve presented before on the opportunity for end-to-= end congestion controls to account for the highly-volatile radio access lin= k. With ECN marking proposed at the RLC, does this create that opportunity? i.e. include the current radio conditions as a fa= ctor in the ‘when to mark’ L4S algorithm.

&n= bsp;

‘= Volatility’ could be gleaned from the same logic used to determine th= e Reception buffering, or possibly from the UE’s Channel Quality Indi= cators that are reported to the MAC scheduler.

&n= bsp;

What do= you reckon?

&n= bsp;

All bes= t,

Kevin

&n= bsp;

&n= bsp;

&n= bsp;

&n= bsp;

From:= tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Ingemar Johansson S
Sent: 12 May 2017 14:06
To: Bob Briscoe <ie= tf@bobbriscoe.net>
Cc: Black, David (davi= d.black@emc.com) <david.black@emc.com>; tsvwg IETF list <tsvwg@ietf.org>
Subject: Re: [tsvwg] Enhanced ECN support in 5G

 

Hi

 

Yes, I hope that it= will be possible to land this, we will know more by the end of next week.

And thanks for the = clarifications around Apple=B4s ECN deployment.

 

/Ingemar=

 

From:= Bob Briscoe [mailto:ietf@bobbriscoe.net]
Sent: den 10 maj 2017 17:00
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: De Schepper, Koen (Nokia - BE/Antwerp) <koen.de_schepper@nokia-bell-labs.= com>; tsvwg IETF list <tsvwg@ietf.org>; Black, David (david.black@em= c.com) <david.black@emc.com= >
Subject: Re: Enhanced ECN support in 5G

 

Ingemar, [repeating a= nd adding to my reply to your posting on iccrg, cos I overlooked your ident= ical message to tsvwg]

Thanks for this. The proposal to do ECN-marking at the RLC layer is importa= nt. It will need to consider incremental deployment though, cos there will = be loads of user equipment for some years that don't contain any logic to u= nderstand ECN at the RLC layer. Incremental ECN deployment at L2 has been solved in various ways. Probably= the neatest is how it is being done in TRILL (draft-ietf-trill-ecn-support= ) (see ecn-encap-guidelines for pointers to other approaches).

I've sent you a marked up corrected copy offlist, cos the ECN deployment st= atements are misleading.
* Apple's ECN deployment is primarily on Ethernet and Wifi (50% on latest O= Ss, 5% on previous).
* On mobile-connected devices, Apple enables ECN solely for 3 carriers: T-M= obile, Three, Telstra
   See video of conference: Networking for the Modern Internet (video requires Safari, or you = can look it up in the iOS= WWDC app).

Cheers



Bob

On 07/05/17 10:52, Ingemar Johansson S wrote:

Hi

To whom it may concern.

The submission below is posted to 3GPP RAN2. The int= ention is to add support for timely and efficient ECN marking in NR (5G) . = This will make it easier to eventually implement support for L4S in 5G.

 

http://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_= 98/Docs/R2-1704368.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 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

&nbs= p;

A mistake is to commit a misunderstanding
       =              &n= bsp;Bob Dylan
=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

 

 = 

-- 
________________________________________________________________<=
/o:p>
Bob Briscoe          =
;            &n=
bsp;        http://bobbriscoe.net/
--_000_DB4PR07MB348EAF9A4DDFB9E039117F8C2E20DB4PR07MB348eurprd_-- From nobody Tue May 16 15:24: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 6725D1287A7 for ; Tue, 16 May 2017 15:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 LT5bm6dPRQRU for ; Tue, 16 May 2017 15:24:51 -0700 (PDT) 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 BD23512944E for ; Tue, 16 May 2017 15:21:09 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4GMK72n010166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 May 2017 15:20:08 -0700 (PDT) References: <149497285236.6715.16431988651696096924.idtracker@ietfa.amsl.com> To: tsvwg From: Joe Touch X-Forwarded-Message-Id: <149497285236.6715.16431988651696096924.idtracker@ietfa.amsl.com> Message-ID: <535c973d-73c5-4a0f-5cba-49bf1fc31cde@isi.edu> Date: Tue, 16 May 2017 15:20:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <149497285236.6715.16431988651696096924.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------814A662E8B3042A325F8FC72" Content-Language: en-US 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-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 22:24:53 -0000 This is a multi-part message in MIME format. --------------814A662E8B3042A325F8FC72 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi, all, This version (09) includes changes to address DOS concerns raised by Tom Herbert. I would like the chairs to initiate a call for WG adoption, intended towards Standards Track, updating RFC 786. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-touch-tsvwg-udp-options-09.txt Date: Tue, 16 May 2017 15:14:12 -0700 From: internet-drafts@ietf.org To: Joseph Touch , Joe Touch A new version of I-D, draft-touch-tsvwg-udp-options-09.txt has been successfully submitted by Joe Touch and posted to the IETF repository. Name: draft-touch-tsvwg-udp-options Revision: 09 Title: Transport Options for UDP Document date: 2017-05-16 Group: Individual Submission Pages: 27 URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-09.txt Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-09 Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-09 Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-09 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 --------------814A662E8B3042A325F8FC72 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi, all,

This version (09) includes changes to address DOS concerns raised by Tom Herbert.

I would like the chairs to initiate a call for WG adoption, intended towards Standards Track, updating RFC 786.

Joe


-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tsvwg-udp-options-09.txt
Date: Tue, 16 May 2017 15:14:12 -0700
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-09.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

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

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
--------------814A662E8B3042A325F8FC72-- From nobody Tue May 16 15:39:13 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 DAE0E12EC3B for ; Tue, 16 May 2017 15:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 4_CV7v57c9_q for ; Tue, 16 May 2017 15:39:09 -0700 (PDT) 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 70C6D12ECF0 for ; Tue, 16 May 2017 15:34:32 -0700 (PDT) Received: from [128.9.184.184] ([128.9.184.184]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v4GMXpqR025637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 16 May 2017 15:33:52 -0700 (PDT) From: Joe Touch To: tsvwg References: <149497285236.6715.16431988651696096924.idtracker@ietfa.amsl.com> <535c973d-73c5-4a0f-5cba-49bf1fc31cde@isi.edu> Message-ID: <66a4e8c4-82c0-78c9-9706-03edaf256744@isi.edu> Date: Tue, 16 May 2017 15:33:51 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <535c973d-73c5-4a0f-5cba-49bf1fc31cde@isi.edu> Content-Type: multipart/alternative; boundary="------------26A8D6D86CB3F34DCAFF28A4" Content-Language: en-US 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-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 22:39:11 -0000 This is a multi-part message in MIME format. --------------26A8D6D86CB3F34DCAFF28A4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit PS - I had forgotten to address multicast in this version. I'm anticipating "SHOULD NOT" use in that case, except where you know the receiver's capabilities via other means, but that too would be subject to what the WG decides if adopted. Joe On 5/16/2017 3:20 PM, Joe Touch wrote: > > Hi, all, > > This version (09) includes changes to address DOS concerns raised by > Tom Herbert. > > I would like the chairs to initiate a call for WG adoption, intended > towards Standards Track, updating RFC 786. > > Joe > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-touch-tsvwg-udp-options-09.txt > Date: Tue, 16 May 2017 15:14:12 -0700 > From: internet-drafts@ietf.org > To: Joseph Touch , Joe Touch > > > > A new version of I-D, draft-touch-tsvwg-udp-options-09.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. > > Name: draft-touch-tsvwg-udp-options > Revision: 09 > Title: Transport Options for UDP > Document date: 2017-05-16 > Group: Individual Submission > Pages: 27 > URL: https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-09.txt > Status: https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ > Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-09 > Htmlized: https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-09 > Diff: https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-09 > > 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 --------------26A8D6D86CB3F34DCAFF28A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

PS - I had forgotten to address multicast in this version.

I'm anticipating "SHOULD NOT" use in that case, except where you know the receiver's capabilities via other means, but that too would be subject to what the WG decides if adopted.

Joe


On 5/16/2017 3:20 PM, Joe Touch wrote:

Hi, all,

This version (09) includes changes to address DOS concerns raised by Tom Herbert.

I would like the chairs to initiate a call for WG adoption, intended towards Standards Track, updating RFC 786.

Joe


-------- Forwarded Message --------
Subject: New Version Notification for draft-touch-tsvwg-udp-options-09.txt
Date: Tue, 16 May 2017 15:14:12 -0700
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-09.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

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

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

--------------26A8D6D86CB3F34DCAFF28A4-- From nobody Tue May 16 17:35: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 05247127286 for ; Tue, 16 May 2017 17:35:15 -0700 (PDT) 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=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 YRkOxmjQ5vhT for ; Tue, 16 May 2017 17:35:13 -0700 (PDT) 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 3DD0B120725 for ; Tue, 16 May 2017 17:31:44 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id a72so143978588qkj.2 for ; Tue, 16 May 2017 17:31:44 -0700 (PDT) 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=9C2Uhs/dKE20TiZP0ZZqVRVNRZGmOMk5z7Rl6NrEEIw=; b=cti8hpuzqTZ3yfXR3mX3l8IY88y6w/OEiGk9RWJDIMeXMYdipxMl8l/XHTx8En89Ow bbPhV9mFfvU7KVicVDg7MOpBnB4gaNnvyQoN9LlMjPIF1fYOpu5pQ2TaaJW8ny3e5eEJ Fsq0PfvKpIPqCXfkzwA2wiCcSEMq2viVtT36JWE1/v0LHnviRPDhsxVdJO2B8H49D8HX YdxDJU1zikBSy5lrEra5JnmB9xB0z5CIJKsSCy/qt5K1fOLBhvBssmICoBluJhU/d7QR p814hpZ8y1t2fgcLYre1RO0bpnXt4aU/T7hPn4A4nRuCGpbcQDjhO7NMHk422Kx7Dhbh 0ctw== 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=9C2Uhs/dKE20TiZP0ZZqVRVNRZGmOMk5z7Rl6NrEEIw=; b=X9AW9KJPqIgMhXuKPVtd3O31f2DKUXhBxdV2IGSIw9z6FvnaCiKZep4hxSizu2EqWx e5ojInvX9BXxi/0aI4jKp51F4LbTUH5RH09QDpncegAvfNY+dbjed/RYPNNi+9JiZMT+ ppogncjE2lTzVezAJWaPm3lTjzEIQzBCA0xaKn9ZfpnpMHZuU8vG6dDu2yF9Bt0UmuW3 bc5BXXbds8Eu/j7uWr5s+0pEzDNdEm454tA2N0AWQj7X5u0AQWKn+ECkgc74BVDGl+M/ 1ZZChj54R5IIGqPZzdj3hVb9IB/mEFDePTrxr8YScLebZTTN7BqXpUNlnaG7yfX739hf qCdw== X-Gm-Message-State: AODbwcDoCeXnaxryX3WIaS4PTZU8ZgpJBnW81grA7oenOm6CYBNh31U6 /IU5RFaP2ktQ12SWI2rEkd1aOgsOrEUE X-Received: by 10.55.197.92 with SMTP id p89mr602062qki.34.1494981103335; Tue, 16 May 2017 17:31:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Tue, 16 May 2017 17:31:42 -0700 (PDT) In-Reply-To: <535c973d-73c5-4a0f-5cba-49bf1fc31cde@isi.edu> References: <149497285236.6715.16431988651696096924.idtracker@ietfa.amsl.com> <535c973d-73c5-4a0f-5cba-49bf1fc31cde@isi.edu> From: Tom Herbert Date: Tue, 16 May 2017 17:31:42 -0700 Message-ID: To: Joe Touch Cc: tsvwg Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 00:35:15 -0000 Joe, >From the draft: "[NOTE: Tom Herbert suggested we declare "more than 3 consecutive NOPs" a fatal error to reduce the potential of using NOPs as a DOS attack, but IMO there are other equivalent ways (e.g., using RESERVED or other UNASSIGNED values) and the "no more than 3" creates its own DOS vulnerability)" RFC4942 discusses this for IPv6 options in "2.1.9.5. Misuse of Pad1 and PadN Options". PadN might also be nice to have in UDP options. Tom On Tue, May 16, 2017 at 3:20 PM, Joe Touch wrote: > Hi, all, > > This version (09) includes changes to address DOS concerns raised by Tom > Herbert. > > I would like the chairs to initiate a call for WG adoption, intended towards > Standards Track, updating RFC 786. > > Joe > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-touch-tsvwg-udp-options-09.txt > Date: Tue, 16 May 2017 15:14:12 -0700 > From: internet-drafts@ietf.org > To: Joseph Touch , Joe Touch > > > A new version of I-D, draft-touch-tsvwg-udp-options-09.txt > has been successfully submitted by Joe Touch and posted to the > IETF repository. > > Name: draft-touch-tsvwg-udp-options > Revision: 09 > Title: Transport Options for UDP > Document date: 2017-05-16 > Group: Individual Submission > Pages: 27 > URL: > https://www.ietf.org/internet-drafts/draft-touch-tsvwg-udp-options-09.txt > Status: > https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/ > Htmlized: https://tools.ietf.org/html/draft-touch-tsvwg-udp-options-09 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-touch-tsvwg-udp-options-09 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-touch-tsvwg-udp-options-09 > > 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 May 16 23:35:18 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 135411292CE; Tue, 16 May 2017 23:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 kVV2a4IX-GIS; Tue, 16 May 2017 23:35:14 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1199F127077; Tue, 16 May 2017 23:32:08 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 682A31B017B6; Wed, 17 May 2017 09:26:57 +0100 (BST) Message-ID: <591BEE59.8030709@erg.abdn.ac.uk> Date: Wed, 17 May 2017 07:31:53 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: tsvwg@ietf.org CC: tsvwg-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [tsvwg] Adoption call: draft-touch-tsvwg-udp-options-09 to end 31st May 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 06:35:17 -0000 The TSVWG chairs are considering adoption of the draft "Transport Options for UDP". This draft has been discussed at previous IETF meetings and on the list, and the chairs are now looking for input from the group to help inform whether TSVWG should adopt this draft. * Please send an email to this list if you would like to see this work adopted in TSVWG, or you have comments on the suitability for adoption. * Please indicate if you are willing to REVIEW such a document during its development. Please send all notes of support/comments to the TSVWG list or the WG chairs by the date above. Best wishes, Gorry, David and Wes. (TSVWG Co-Chairs) 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. From nobody Wed May 17 01:07: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 3FB28129B95; Wed, 17 May 2017 01:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 49S7Twe7IERW; Wed, 17 May 2017 01:07:45 -0700 (PDT) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1CD12EB1A; Wed, 17 May 2017 01:03:40 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 3B52B20306; Wed, 17 May 2017 10:03:39 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 0F7E31A0074; Wed, 17 May 2017 10:03:39 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0339.000; Wed, 17 May 2017 10:03:38 +0200 From: To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" CC: "tsvwg-chairs@ietf.org" Thread-Topic: [tsvwg] Adoption call: draft-touch-tsvwg-udp-options-09 to end 31st May 2017 Thread-Index: AQHSztfHv4yE/0+QV0WFVP+cRPTL66H4J6Fg Date: Wed, 17 May 2017 08:03:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933009E71C35@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <591BEE59.8030709@erg.abdn.ac.uk> In-Reply-To: <591BEE59.8030709@erg.abdn.ac.uk> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] Adoption call: draft-touch-tsvwg-udp-options-09 to end 31st May 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 08:07:48 -0000 Dear chairs, all,=20 I'm following this draft mainly from a multi-path standpoint for UDP flows = that may be facilitated if UDP options are supported. =20 I support this effort to be adopted as a tsvwg document.=20 Cheers, Med > -----Message d'origine----- > De=A0: tsvwg [mailto:tsvwg-bounces@ietf.org] De la part de Gorry Fairhurs= t > Envoy=E9=A0: mercredi 17 mai 2017 08:32 > =C0=A0: tsvwg@ietf.org > Cc=A0: tsvwg-chairs@ietf.org > Objet=A0: [tsvwg] Adoption call: draft-touch-tsvwg-udp-options-09 to end > 31st May 2017 >=20 > The TSVWG chairs are considering adoption of the draft > "Transport Options for UDP". This draft has been discussed at previous > IETF meetings and on the list, and the chairs are now looking for > input from the group to help inform whether TSVWG should adopt this draft= . >=20 > * Please send an email to this list if you would like to see this work > adopted in TSVWG, or you have comments on the suitability for adoption. >=20 > * Please indicate if you are willing to REVIEW such a document during > its development. >=20 > Please send all notes of support/comments to the TSVWG list or the WG > chairs > by the date above. >=20 > Best wishes, >=20 > Gorry, David and Wes. > (TSVWG Co-Chairs) >=20 > Abstract >=20 > 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 From nobody Wed May 17 01:34:54 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 2B941129C6B; Wed, 17 May 2017 01:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 F_7RqSTnuenC; Wed, 17 May 2017 01:34:49 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id A84D81200CF; Wed, 17 May 2017 01:30:57 -0700 (PDT) Received: from auth1-smtp.messagingengine.com (auth1-smtp.messagingengine.com [66.111.4.227]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id BF23A1B015A4; Wed, 17 May 2017 11:25:59 +0100 (BST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 093F621A3A; Wed, 17 May 2017 04:30:55 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Wed, 17 May 2017 04:30:55 -0400 X-ME-Sender: X-Sasl-enc: JR/19VlvcbovRwkxuZiueKEk6wnRYu0ugliVZLfTaCa3 1495009854 Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [139.133.204.4]) by mail.messagingengine.com (Postfix) with ESMTPA id 7422F2418C; Wed, 17 May 2017 04:30:54 -0400 (EDT) Date: Wed, 17 May 2017 09:30:52 +0100 From: tj To: Gorry Fairhurst Cc: tsvwg@ietf.org, tsvwg-chairs@ietf.org Message-ID: <20170517083052.GA95372@tom-desk.erg.abdn.ac.uk> References: <591BEE59.8030709@erg.abdn.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <591BEE59.8030709@erg.abdn.ac.uk> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [tsvwg] Adoption call: draft-touch-tsvwg-udp-options-09 to end 31st May 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 08:34:52 -0000 Dear Chairs, All, On Wed, May 17, 2017 at 07:31:53AM +0100, Gorry Fairhurst wrote: > * Please indicate if you are willing to REVIEW such a document during > its development. I am willing to REVIEW this document during its development. I am currently working on an implementation on top of FreeBSD. - [tj] From nobody Wed May 17 08:34:20 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 33B9B128A32 for ; Wed, 17 May 2017 08:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSL5Zw1UegmL for ; Wed, 17 May 2017 08:34:17 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 2F11212EB0E for ; Wed, 17 May 2017 08:27:49 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id f55so12332857qta.3 for ; Wed, 17 May 2017 08:27:49 -0700 (PDT) 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=lrKnNzjnne9r61aF+6nmA6HTDFgXJiNCY6ImjeoDEtY=; b=omp8Q3Byv+EkJkpzGI2g12KwItkbRCN7boMkmydndNJ9NZt6hPtOGoJiJ5y5VKR165 bIZqv0kCcv5w5TqRYzTBiuPkw+LyPOFkvXnyLGbUHZ86D7WWA5XMlUUz7gKqkUbBvlC0 fWFg+49+SaX0mCtvyHDM+5FVlkUWHIhepgjvr6W3vc1z0n4jv/tfF/T3QSHwWgOH+Gsq 9/m2IRu+BLQmfra6JQdY3SumAuReHrweRoMpiZDTy6vYlQGyJCityCQ4+F2qpm9rM7WD 0BSARHg4db1juDA0xCz9EXajc35NfWxb8+GlEAMoVSrhnDuJdXOok7PJVkb+2Dh9E+fX KbkA== 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=lrKnNzjnne9r61aF+6nmA6HTDFgXJiNCY6ImjeoDEtY=; b=cSchiuebhMy01FiKDDCRvJw+WFc4pv3JS3eMoETauvGYOSSJNeD+Kj2W8BD18eOyYR w1WTuTFGmVic9ryZOKvgJIZjWieLsArQunLkFtUDljDYZPa5wFJJTUfyDxgIEHxLcx4s zV0uO2oYuAICWQK1o398vcJS/m6dMMQO2orIheD4XjS/4A/lqfSJCGoMgDE2WvuG6dYa mRC8vXWIdHccev1VB62uAHN9BpM2rIJDArJpMRX4OxUzi8Z5WQ18P0iGzKZDDHgMoBX7 +Gx7u1l1sCVewHoZpTtUF9iWwFYGuyglsz8ATcxsseyX+vTDKfiOYgww/C2xPqpXJcNI yEnQ== X-Gm-Message-State: AODbwcAC1C1ObZHHuOysuE4zG4u93yuKlRryaYLMvzFKRIyLxv3BjoHT BwCBr2Zrz4wW4ETRANLhv9LC04bPCSwF X-Received: by 10.200.43.33 with SMTP id 30mr3515062qtu.210.1495034868334; Wed, 17 May 2017 08:27:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.10 with HTTP; Wed, 17 May 2017 08:27:48 -0700 (PDT) In-Reply-To: <591BEE59.8030709@erg.abdn.ac.uk> References: <591BEE59.8030709@erg.abdn.ac.uk> From: Tom Herbert Date: Wed, 17 May 2017 08:27:48 -0700 Message-ID: To: "gorry@erg.abdn.ac.uk" Cc: tsvwg , tsvwg-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tsvwg] Adoption call: draft-touch-tsvwg-udp-options-09 to end 31st May 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 15:34:18 -0000 On Tue, May 16, 2017 at 11:31 PM, Gorry Fairhurst wrote: > The TSVWG chairs are considering adoption of the draft > "Transport Options for UDP". This draft has been discussed at previous > IETF meetings and on the list, and the chairs are now looking for > input from the group to help inform whether TSVWG should adopt this draft. > > * Please send an email to this list if you would like to see this work > adopted in TSVWG, or you have comments on the suitability for adoption. > > * Please indicate if you are willing to REVIEW such a document during > its development. > I support adoption and am will to REVIEW it. Tom > Please send all notes of support/comments to the TSVWG list or the WG chairs > by the date above. > > Best wishes, > > Gorry, David and Wes. > (TSVWG Co-Chairs) > > 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. > > From nobody Wed May 17 10:39: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 39163120046 for ; Wed, 17 May 2017 10:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 nPr2VWDB-L7e for ; Wed, 17 May 2017 10:39:05 -0700 (PDT) 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 78D2B129480 for ; Wed, 17 May 2017 10:34:19 -0700 (PDT) Received: from [128.9.184.128] ([128.9.184.128]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4HHXn5S015204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 May 2017 10:33:49 -0700 (PDT) To: Tom Herbert Cc: tsvwg References: <149497285236.6715.16431988651696096924.idtracker@ietfa.amsl.com> <535c973d-73c5-4a0f-5cba-49bf1fc31cde@isi.edu> From: Joe Touch Message-ID: <517abc3b-940e-7e2d-c943-7ac64387f0cc@isi.edu> Date: Wed, 17 May 2017 10:33:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US 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-09.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2017 17:39:07 -0000 Hi, Tom, On 5/16/2017 5:31 PM, Tom Herbert wrote: > Joe, > > >From the draft: > > "[NOTE: Tom Herbert suggested we declare "more than 3 consecutive > NOPs" a fatal error to reduce the potential of using NOPs as a DOS > attack, but IMO there are other equivalent ways (e.g., using RESERVED > or other UNASSIGNED values) and the "no more than 3" creates its own > DOS vulnerability)" > > RFC4942 discusses this for IPv6 options in "2.1.9.5. Misuse of Pad1 > and PadN Options". PadN might also be nice to have in UDP options. IMO, at best, PadN merely serves to eat an option codepoint. At worst, PadN provides a covert channel (if not checked) or results in nearly the same processing cost (if checked). I don't like the idea of dropping "unusual" patterns - either a pattern should be prohibited or allowed. The biggest problem, AFAICT, is that these prohibitions all end up amplifying the DOS impact, e.g., by requiring more checks during processing. We can certainly discuss this further if others want, once this is accepted as a WG document. Joe From nobody Mon May 22 16:21: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 02747129439 for ; Mon, 22 May 2017 16:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 CVvst3cGbrSN for ; Mon, 22 May 2017 16:21:53 -0700 (PDT) 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 11692126CC4 for ; Mon, 22 May 2017 16:21:53 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 856FD83E66 for ; Mon, 22 May 2017 19:21:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; s=sasl; bh=rZr0ZK 3IytyfDca8uxsE5TUnFNc=; b=U3Ii0jc75McvsEaEAOKFYDLVxz3Ve++Cdwm66k YiuTLwNgZg377S1TGgOoNdHILei4yayKj5Qo0P3zbtwFJlv/AfFmNxIIbFtb9uU/ ARz8mdb+XlVAW2e58HHGYdNdLerJQfEwEmaho/pJcPCPYGoJm3XDN+DefZ924cNc 3skGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :from:date:message-id:subject:to:content-type; q=dns; s=sasl; b= OCTKh6zjnNecwuOwKCEBHAVC5V62Dsf1Kj+4tqh03GmrldZrL/nDB1fY7XuJOuj1 T+BLckRTh2oyymcjbpxUqWkcMpxVxgTZNmOilcNBb1XSJsSpuL5e5AsVUqtWtWpa fcdoXrde22h7VwXdsbFhojp4bxpxGbRvJ3XejyMURjI= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 7F4A683E65 for ; Mon, 22 May 2017 19:21:51 -0400 (EDT) Received: from mail-qk0-f170.google.com (unknown [209.85.220.170]) (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 18ACB83E64 for ; Mon, 22 May 2017 19:21:51 -0400 (EDT) Received: by mail-qk0-f170.google.com with SMTP id a72so118771115qkj.2 for ; Mon, 22 May 2017 16:21:51 -0700 (PDT) X-Gm-Message-State: AODbwcAQvP0p87/5dygUFZVoJUeCFrYTka+NY9tzapmh92qHjFoYmHvI ngo3LYQjYugQgG1scPm/jlUUaL8xiw== X-Received: by 10.55.161.72 with SMTP id k69mr24859651qke.81.1495495310715; Mon, 22 May 2017 16:21:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.72 with HTTP; Mon, 22 May 2017 16:21:30 -0700 (PDT) From: "C. M. Heard" Date: Mon, 22 May 2017 16:21:30 -0700 X-Gmail-Original-Message-ID: Message-ID: To: tsvwg Content-Type: text/plain; charset="UTF-8" X-Pobox-Relay-ID: 6F534C42-3F45-11E7-926F-EFB41968708C-06080547!pb-smtp1.pobox.com Archived-At: Subject: Re: [tsvwg] Adoption call: draft-touch-tsvwg-udp-options-09 to end 31st May 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 23:21:54 -0000 On Wed, 17 May 2017 07:31:53 +0100, Gorry Fairhurst wrote: > * Please send an email to this list if you would like to see this work > adopted in TSVWG, or you have comments on the suitability for > adoption. I would like to see this work adopted by TSVWG. > * Please indicate if you are willing to REVIEW such a document during > its development. I am willing to REVIEW this document during its development. Mike Heard From nobody Mon May 22 23:42:49 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 D95D21294AB; Mon, 22 May 2017 23:42:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tsvwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149552176185.18049.1360111706174012981@ietfa.amsl.com> Date: Mon, 22 May 2017 23:42:41 -0700 Archived-At: Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-tunnel-congestion-feedback-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 06:42:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group of the IETF. Title : Tunnel Congestion Feedback Authors : Xinpeng Wei Zhu Lei Lingli Deng Filename : draft-ietf-tsvwg-tunnel-congestion-feedback-05.txt Pages : 19 Date : 2017-05-22 Abstract: This document describes a method to measure congestion on a tunnel segment based on recommendations from RFC 6040, "Tunneling of Explicit Congestion Notification", and to use IPFIX to communicate the congestion measurements from the tunnel's egress to a controller which can respond by modifying the traffic control policies at the tunnel's ingress. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-tunnel-congestion-feedback/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tsvwg-tunnel-congestion-feedback-05 https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-tunnel-congestion-feedback-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-tunnel-congestion-feedback-05 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 May 22 23:46: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 0E6601294A3 for ; Mon, 22 May 2017 23:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 VFIqtfgllqIN for ; Mon, 22 May 2017 23:46:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C42E1267BB for ; Mon, 22 May 2017 23:46:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNP07301; Tue, 23 May 2017 06:46:19 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 23 May 2017 07:46:18 +0100 Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 23 May 2017 14:46:12 +0800 From: "Weixinpeng (Jackie)" To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-05.txt Thread-Index: AQHS04/JEEJ5CeLzIk+8XSj1/1/av6IBeJDA Date: Tue, 23 May 2017 06:46:12 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5923DABC.0012, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 47c10e898916721b4a336fcce84f7cff Archived-At: Subject: [tsvwg] FW: New Version Notification for draft-ietf-tsvwg-tunnel-congestion-feedback-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 06:46:24 -0000 SGkgYWxsLA0KIEEgbmV3IHZlcnNpb24gb2YgVENGIGRyYWZ0IGlzIHN1Ym1pdHRlZC4gVGhhbmtz IQ0KDQpSZWdhcmRzLA0KLVhpbnBlbmcoSmFja2llKQ0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj5Gcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddDQo+U2VudDogVHVlc2RheSwgTWF5IDIzLCAyMDE3IDI6NDMgUE0NCj5U bzogWmh1bGVpIChNQkIgUmVzZWFyY2gpOyBaaHVsZWkgKE1CQiBSZXNlYXJjaCk7IFdlaXhpbnBl bmcgKEphY2tpZSk7DQo+dHN2d2ctY2hhaXJzQGlldGYub3JnOyBMaW5nbGkgRGVuZw0KPlN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj5kcmFmdC1pZXRmLXRzdndnLXR1bm5l bC1jb25nZXN0aW9uLWZlZWRiYWNrLTA1LnR4dA0KPg0KPg0KPkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrLTA1LnR4dA0KPmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlucGVuZyBXZWkgYW5kIHBvc3RlZCB0 byB0aGUgSUVURg0KPnJlcG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0LWlldGYtdHN2d2ctdHVu bmVsLWNvbmdlc3Rpb24tZmVlZGJhY2sNCj5SZXZpc2lvbjoJMDUNCj5UaXRsZToJCVR1bm5lbCBD b25nZXN0aW9uIEZlZWRiYWNrDQo+RG9jdW1lbnQgZGF0ZToJMjAxNy0wNS0yMw0KPkdyb3VwOgkJ dHN2d2cNCj5QYWdlczoJCTE5DQo+VVJMOg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYQ0KPmNrLTA1 LnR4dA0KPlN0YXR1czoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYWNrLw0KPkh0bWxpemVkOg0KPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9u LWZlZWRiYWNrLTA1DQo+SHRtbGl6ZWQ6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1pZXRmLXRzdndnLXR1bm5lbC1jb25nZXN0aW9uLWZlZWRiYQ0KPmNrLTA1 DQo+RGlmZjoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10 c3Z3Zy10dW5uZWwtY29uZ2VzdGlvbi1mZWVkYmFjay0wDQo+NQ0KPg0KPkFic3RyYWN0Og0KPiAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgbWV0aG9kIHRvIG1lYXN1cmUgY29uZ2VzdGlvbiBv biBhIHR1bm5lbA0KPiAgIHNlZ21lbnQgYmFzZWQgb24gcmVjb21tZW5kYXRpb25zIGZyb20gUkZD IDYwNDAsICJUdW5uZWxpbmcgb2YNCj4gICBFeHBsaWNpdCBDb25nZXN0aW9uIE5vdGlmaWNhdGlv biIsIGFuZCB0byB1c2UgSVBGSVggdG8gY29tbXVuaWNhdGUNCj4gICB0aGUgY29uZ2VzdGlvbiBt ZWFzdXJlbWVudHMgZnJvbSB0aGUgdHVubmVsJ3MgZWdyZXNzIHRvIGEgY29udHJvbGxlcg0KPiAg IHdoaWNoIGNhbiByZXNwb25kIGJ5IG1vZGlmeWluZyB0aGUgdHJhZmZpYyBjb250cm9sIHBvbGlj aWVzIGF0IHRoZQ0KPiAgIHR1bm5lbCdzIGluZ3Jlc3MuDQo+DQo+DQo+DQo+DQo+UGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue May 23 01:19: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 3F22412956B for ; Tue, 23 May 2017 01:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8KxLLJGplgTt for ; Tue, 23 May 2017 01:19:24 -0700 (PDT) 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 616E612954D for ; Tue, 23 May 2017 01:19:24 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id E74A61B01862; Tue, 23 May 2017 11:14:13 +0100 (BST) Message-ID: <5923F086.8030804@erg.abdn.ac.uk> Date: Tue, 23 May 2017 09:19:18 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: szigeti@cisco.com, fredbakersba@gmail.com, tsvwg@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - editorial comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 08:19:26 -0000 I have some comments on: https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-02 and also an observation about the new text in the last revision. The top-level observation (I'll follow-up with another email if needed about specific text) is that the latest revision discusses the way in which access points and wireless devices can change the DSCP marking or drop traffic because of the DSCP marking. My point is that I do see real benefit in recommendations on how to forward DSCPs across APs and I suspect, if done correctly, this can greatly ease the consistent use of DSCP. I like the way this maps PHBs, and I hope this can allow all equipment to support a well-understood default treatment. However, I think the new remarking and drop recommendations in this new version are not helpful in this general context as **general guidance** to manufacturers and users of 802.11 equipment. Although RFC 4594 Section 3.1 (etc) allows a diffserv domain to configure polices at the edge, the types of policy (and security and QoS implications) that are needed depends on the deployment scenario - and I do not see the current rules as being good defaults for all of the wide variety of 802.11 equipment. What works in managed environments in enterprises, public wifi access, isn't what is best when I place it in my home network, use as a layer 2 infrastructure in a very general sense, as a bridge to other layer 2 infrastructure (zigbee, etc), etc. I, for one, would not wish to see a plethora of simple APs to implement default dropping of classes they do not have PHB support for and remarking of other packets to what they see as the best DSCP for my traffic - to me, that would really mess-up ability to use diffserv in other segments of the network - and is really quite at odds with what I see is currently possible where most markings are actually being passed through most network links. Specifically, I fear the present text could become an impediment to sender marking of DSCP across IP networks in general. I am not even sure this is the correct document to talk about what I would call managed 802.11 networks, but if it reallty is - then I think this needs to be clearly separated from other uses. The editorial comments are below, best wishes, Gorry Fairhurst ---- - rephrase? OLD: a [RFC3246] EF PHB service NEW: an EF PHB service [RFC3246] - rephrase? OLD: a [RFC2597] AF PHB service MEW: an AF PHB service [RFC2597] - Comment, if there is no other classification or marking policy enforcement point, then this sets the DSCP that will be used on the remainder of the Internet path. Could we say that? TEXT: This derived DSCP value is then used for QoS treatment between the wireless access point and the nearest classification and marking policy enforcement point (which may be the centralized wireless LAN controller, relatively deep within the network). - Comment, the new text below reads like this is always the case, whereas there is now work in the IETF to revise these definitions. I think there is value in pointing to the WG ID on this topic as informational, and I think we need to reconsider citing “draft-tsvwg-le-phb“ as well as RFC3662. TEXT: and causing legitimate business-relevant High-Throughput Data to receive a [RFC3662] Lower Effort PDB, for which it is not intended - Question, is it helpful to insert /present/ before wireless device to suggest that this is not necessarily the preferred approach. TEXT: Most wireless device operating systems generate UP values by the same method as described in Section 2.2 (i.e From nobody Tue May 23 02:57:40 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 59DAB128D19 for ; Tue, 23 May 2017 02:57:38 -0700 (PDT) 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, FREEMAIL_FROM=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 (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 SFq74Rk45XEQ for ; Tue, 23 May 2017 02:57:36 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03142124C27 for ; Tue, 23 May 2017 02:57:36 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id w10so194828514oif.0 for ; Tue, 23 May 2017 02:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=28TJpJGdK392XP4iTl5uCp/o8eIpQNeAzDfstG/6YtM=; b=QdcVasPHXN7MCgb152xOycR/FwLsCFXJ3L/9jI10iOVDA7bTQqKRJQqQ0/JF3Q8a/p S2i4NtYA2XHrluTbbaWBve6LMXKmoeNlTY55nNEmzhoS+P5dKVZMCF1hruNhpxvy8OKh MYgJUwRmHEDxJONHlYFfxo8Je+kYQOfmy6LKowdGfa9XM8dWfOlYRtDo7zKKg4yRVztu 8tUTegC95oQzme1V9j5gf7rpK7MRVAxIqtKVZtHpVWnqtNyav7E4GSvycGmAyAOfezrS /BiVtSa0Y82/yp8DkKIWjMn4X93ampKjT3N0wNEihfSGfTgvcLzSL9wqFl1posbSse1I w0EQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=28TJpJGdK392XP4iTl5uCp/o8eIpQNeAzDfstG/6YtM=; b=NRrw87tcGhugWM7LEVC9to3YVK1YR78wOUWE+QEemBVYtZPcGtv3+PjXUJ3GxZrwbr NFWP5xODhWIPw1oD6G7SOcIChBky21STTHqu8qNPgx+b3rNvY5Fjqidjy7YiLBxLOPYQ XuONJubQ3n4CP8e3S5LICVXNaEFLY0Q2XOVrNUfkVL97pktIEQecgZcurGOtBOD815n+ PHLxBGbwQsQb7l+vaeq+l2XgmS0QtzpWaCVHo6vVt/4MavHPqipL0GbMIfK4/A6fRAM2 wnSNbO7XsIMZ17BeF0/RQ/lYBwr4nSkTCxvBnZ5Kb92d4mLQUGBFanNbfFYH6AoNhd8O RMYg== X-Gm-Message-State: AODbwcAm/DzKMJQ2WlbsERqDYnPJh+EyN5p30xg85KC5YERnA5+cekBX zLE7rab7LexZQw== X-Received: by 10.202.105.75 with SMTP id e72mr12460476oic.180.1495533455205; Tue, 23 May 2017 02:57:35 -0700 (PDT) Received: from [100.168.126.73] (ma15636d0.tmodns.net. [208.54.86.161]) by smtp.gmail.com with ESMTPSA id s108sm69755otb.52.2017.05.23.02.57.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 02:57:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPhone Mail (14F5089a) In-Reply-To: <5923F086.8030804@erg.abdn.ac.uk> Date: Tue, 23 May 2017 10:57:32 +0100 Cc: szigeti@cisco.com, tsvwg@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2538E6AA-DE0B-433E-BCAC-39C160AA5E17@gmail.com> References: <5923F086.8030804@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk Archived-At: Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - editorial comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 09:57:38 -0000 Thanks, Gorry. Tim, I'm on vacation. You'll need to handle this. But this is similar to the= concern I raised on our call regarding CS6/CS7. Sent using a machine that autocorrects in interesting ways... > On May 23, 2017, at 9:19 AM, Gorry Fairhurst wrote:= >=20 > I have some comments on: > https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-02 >=20 > and also an observation about the new text in the last revision. >=20 > The top-level observation (I'll follow-up with another email if needed abo= ut specific text) is that the latest revision discusses the way in which acc= ess points and wireless devices can change the DSCP marking or drop traffic b= ecause of the DSCP marking. >=20 > My point is that I do see real benefit in recommendations on how to forwar= d DSCPs across APs and I suspect, if done correctly, this can greatly ease t= he consistent use of DSCP. I like the way this maps PHBs, and I hope this ca= n allow all equipment to support a well-understood default treatment. >=20 > However, I think the new remarking and drop recommendations in this new ve= rsion are not helpful in this general context as **general guidance** to man= ufacturers and users of 802.11 equipment. Although RFC 4594 Section 3.1 (etc= ) allows a diffserv domain to configure polices at the edge, the types of po= licy (and security and QoS implications) that are needed depends on the depl= oyment scenario - and I do not see the current rules as being good defaults f= or all of the wide variety of 802.11 equipment. What works in managed enviro= nments in enterprises, public wifi access, isn't what is best when I place i= t in my home network, use as a layer 2 infrastructure in a very general sens= e, as a bridge to other layer 2 infrastructure (zigbee, etc), etc. >=20 > I, for one, would not wish to see a plethora of simple APs to implement de= fault dropping of classes they do not have PHB support for and remarking of o= ther packets to what they see as the best DSCP for my traffic - to me, that w= ould really mess-up ability to use diffserv in other segments of the network= - and is really quite at odds with what I see is currently possible where m= ost markings are actually being passed through most network links. >=20 > Specifically, I fear the present text could become an impediment to sender= marking of DSCP across IP networks in general. I am not even sure this is t= he correct document to talk about what I would call managed 802.11 networks,= but if it reallty is - then I think this needs to be clearly separated from= other uses. >=20 > The editorial comments are below, >=20 > best wishes, >=20 > Gorry Fairhurst >=20 > ---- >=20 > - rephrase? > OLD: > a [RFC3246] EF PHB service > NEW: > an EF PHB service [RFC3246] >=20 > - rephrase? > OLD: > a [RFC2597] AF PHB service > MEW: > an AF PHB service [RFC2597] >=20 > - Comment, if there is no other classification or marking policy > enforcement point, then this sets the DSCP that will be used > on the remainder of the Internet path. Could we say that? > TEXT: > This derived DSCP value > is then used for QoS treatment between the wireless access point and > the nearest classification and marking policy enforcement point > (which may be the centralized wireless LAN controller, relatively > deep within the network). >=20 >=20 > - Comment, the new text below reads like this is always the case, whereas > there is now work in the IETF to revise these definitions. I think > there is value in pointing to the WG ID on this topic as informational, > and I think we need to reconsider citing =E2=80=9Cdraft-tsvwg-le-phb=E2=80= =9C > as well as RFC3662. > TEXT: > and causing legitimate business-relevant > High-Throughput Data to receive a [RFC3662] Lower Effort PDB, for > which it is not intended >=20 > - Question, is it helpful to insert /present/ before wireless device > to suggest that this is not necessarily the preferred approach. > TEXT: > Most wireless device operating systems generate UP values by the > same method as described in Section 2.2 (i.e >=20 From nobody Wed May 24 14:19: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 DB2FC129BDB for ; Wed, 24 May 2017 14:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 sWWg0lPAsxjs for ; Wed, 24 May 2017 14:19:04 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4491F129BC5 for ; Wed, 24 May 2017 14:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9358; q=dns/txt; s=iport; t=1495660739; x=1496870339; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cjuCrfMOh21iHNa4UKVO4b6LB/YqhEpJDmJXD+LPttU=; b=GFNjm4oWzVznb1pZ5DrXnmXm7JH3UZg7o7kzid3EIxKz8AVkzsSkxjmu QxIcMNpPeA9lNewLKM9JMKqiXMngTTXquipN4t6Uw3CutilU0aQfJvqiR y4NXfs5MEsnsIh1vzWRZF3FRhf2d0h3ZGLVaWZnt8nmZ507foNBoXXf9w k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACP9yVZ/4MNJK1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMqK2KBDAeOAJFciCeNUIIPLIV4AoJzPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBOj8FBwQCAQgRBAEBHwkHIREUCQgCBAENBQiKBgMNCA6wHoc0DYQAA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWIPYMcglWBXwESAYYOBZZJMIZvOwGHH4c?= =?us-ascii?q?whE+SAIsyiRsBHzh/C3EVhn89docFBgkXgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,388,1491264000"; d="scan'208";a="252488306" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 May 2017 21:18:58 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4OLIwDo013966 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 May 2017 21:18:58 GMT Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 24 May 2017 16:18:57 -0500 Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Wed, 24 May 2017 16:18:57 -0500 From: "Tim Szigeti (szigeti)" To: "gorry@erg.abdn.ac.uk" , "fredbakersba@gmail.com" , "tsvwg@ietf.org" CC: "Jerome Henry (jerhenry)" Thread-Topic: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments Thread-Index: AQHS051LwDLgd1DAnEe9GMav17WLLaID5vqA Date: Wed, 24 May 2017 21:18:57 +0000 Message-ID: References: <5923F086.8030804@erg.abdn.ac.uk> In-Reply-To: <5923F086.8030804@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.132.12.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - editorial comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 21:19:07 -0000 Hi Gorry, Thanks again for taking the time to review and comment on this draft. A few responses inline... > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: Tuesday, May 23, 2017 1:19 AM > To: Tim Szigeti (szigeti); fredbakersba@gmail.com; tsvwg@ietf.org > Subject: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments >=20 > I have some comments on: > https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-02 >=20 > and also an observation about the new text in the last revision. >=20 > The top-level observation (I'll follow-up with another email if needed ab= out > specific text) is that the latest revision discusses the way in which acc= ess > points and wireless devices can change the DSCP marking or drop traffic > because of the DSCP marking. >=20 I'd like to first stress the point that the remarking and dropping recommen= dations of network control traffic (marked CS6/CS7) at the edge of the wire= d-to-wireless network (as made in Section 4.1.1) were part of the original = 2015 draft, and are not new recommendations in this latest revision.=20 Additionally, these recommendations are drawn from similar recommendations = made in RFC 4594-Section 3.2 which: "RECOMMENDED that packets marked CS7 DSCP (a codepoint that SHOULD be reserved for future use) be dropped or remarked at the edge of the Diffserv domain." Our argument is that when the wireless access point represents the edge of = the network infrastructure (and thus the edge of the Diffserv domain), this= recommendation should hold; otherwise a very easily exploitable DoS attack= -vector (as discussed in Section 8-Security Considerations) is presented: n= amely, that devices can flood traffic marked CS6/CS7 upstream and/or downst= ream to/from the wireless network, causing a DoS for all other traffic flow= s; furthermore, as no network devices would be located downstream in such s= cenarios, then no such traffic would be legitimately marked to CS6/CS7. NOTE: in the cases where the wireless edge is NOT the edge of the network i= nfrastructure, this recommendation would not apply, as clearly expressed in= Section 4.1.1. =20 =20 > My point is that I do see real benefit in recommendations on how to forwa= rd > DSCPs across APs and I suspect, if done correctly, this can greatly ease = the > consistent use of DSCP. I like the way this maps PHBs, and I hope this ca= n > allow all equipment to support a well-understood default treatment. >=20 We're in agreement in principle on this point. We would like the mappings t= o be as broadly encompassing as possible; however, a single recommendation = that works in a deployment model where the AP represents the network edge (= 90%+ use-case), may not work in deployment models where the AP extends the = IP network (e.g. wireless-mesh or an AP-to-AP infrastructures, etc.). As su= ch, we are seeking to make secure and consistent marking recommendations th= at are nonetheless flexible enough to accommodate these distinct use-cases. > However, I think the new remarking and drop recommendations in this new > version are not helpful in this general context as **general guidance** t= o > manufacturers and users of 802.11 equipment.=20 Again, I feel the need to stress that the remarking and dropping recommenda= tions are not new in this version, but have been present from the original = draft in 2015. > Although RFC 4594 Section 3.1 > (etc) allows a diffserv domain to configure polices at the edge, the type= s of > policy (and security and QoS implications) that are needed depends on the > deployment scenario - and I do not see the current rules as being good > defaults for all of the wide variety of 802.11 equipment.=20 Again - agreed. There is no single one-size-fits-all recommendation that pr= ovides consistent QoS treatment in a secure manner for both wireless-edge a= nd wireless-extended-infrastructure deployment model scenarios. This is why= these two distinct use-cases are separated and explicit recommendations ar= e made for each.=20 > What works in > managed environments in enterprises, public wifi access, isn't what is be= st > when I place it in my home network, use as a layer 2 infrastructure in a = very > general sense, as a bridge to other layer 2 infrastructure (zigbee, etc),= etc. >=20 The security recommendations offered for wireless-edge scenarios apply to a= ll such, including enterprise, public wifi and even home networks. For ever= y one of these wireless-edge deployment scenarios, it would be a protection= to the network to prevent packets being sent/received from wireless endpoi= nt devices with markings intended for network infrastructure control flows.= Such endpoint devices would never be legitimately sending or receiving suc= h flows. However, the recommendations to remark or drop packets marked CS6/CS7 (i.e.= network control traffic flows) would not apply in the deployment cases whe= re the network was extended over wireless bridges, as has been clearly call= ed out in Section 4.1.1.=20 Making a single recommendation for these two very distinct wireless deploym= ent scenarios would require a tradeoff: either the wireless-edge deployment= s (which represent the majority use-case) become less secure (as any type o= f marking is honored, including network control flows to/from devices which= should not be sending nor receiving such flows), or the wireless extended = infrastructures do not benefit from protection of their control plane proto= cols. Neither option is beneficial to both scenarios; and as such two disti= nct recommendations are made; one for each. > I, for one, would not wish to see a plethora of simple APs to implement > default dropping of classes they do not have PHB support for and remarkin= g > of other packets to what they see as the best DSCP for my traffic - to me= , OK - but the tradeoff here requires leaving wireless-edge networks exposed = to the simple DoS attack-vector of flooding network control traffic to/from= devices that do not legitimately participate in network control functions.= Is that the tradeoff that TSVWG is recommending? We got beat up pretty bad= in WGLC on predominantly security concerns, such as this one.=20 > that would really mess-up ability to use diffserv in other segments of th= e > network Why would it mess up ability to use Diffserv in other segments of the netwo= rk? In the case where the wireless AP represents the edge of the network (i= .e. the deployment-model where this recommendation applies), remarking or d= ropping flows makes no difference to how these flows would be treated in an= y other part of the network.=20 - and is really quite at odds with what I see is currently possible > where most markings are actually being passed through most network links. >=20 > Specifically, I fear the present text could become an impediment to sende= r > marking of DSCP across IP networks in general. Consistent and in line with RFC 2474, 2475 and 8100, we offer recommendatio= ns for sender markings in Section 5.3, albeit with the appropriate securit= y caveats (that the previous round of commenters explicitly requested us to= make). > I am not even sure this is the > correct document to talk about what I would call managed > 802.11 networks, but if it reallty is - then I think this needs to be cle= arly > separated from other uses. >=20 > The editorial comments are below, >=20 > best wishes, >=20 > Gorry Fairhurst >=20 > ---- >=20 > - rephrase? > OLD: > a [RFC3246] EF PHB service > NEW: > an EF PHB service [RFC3246] Done. >=20 > - rephrase? > OLD: > a [RFC2597] AF PHB service > MEW: > an AF PHB service [RFC2597] >=20 Done. > - Comment, if there is no other classification or marking policy enforcem= ent > point, then this sets the DSCP that will be used on the remainder of the > Internet path. Could we say that? > TEXT: > This derived DSCP value > is then used for QoS treatment between the wireless access point and the > nearest classification and marking policy enforcement point (which may be > the centralized wireless LAN controller, relatively deep within the netwo= rk). Added. >=20 >=20 > - Comment, the new text below reads like this is always the case, whereas > there is now work in the IETF to revise these definitions. I think there = is value > in pointing to the WG ID on this topic as informational, and I think we n= eed to > reconsider citing "draft-tsvwg-le-phb" as well as RFC3662. > TEXT: > and causing legitimate business-relevant High-Throughput Data to receive = a > [RFC3662] Lower Effort PDB, for which it is not intended Added. >=20 > - Question, is it helpful to insert /present/ before wireless device to s= uggest > that this is not necessarily the preferred approach. > TEXT: > Most wireless device operating systems generate UP values by the same > method as described in Section 2.2 (i.e Added. (A new version has been submitted for upload with the above editorial comme= nts made. This will be posted shortly.) Thank you again Gorry for the review and comments. -tim From nobody Wed May 24 14:28: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 3B2DD129B21 for ; Wed, 24 May 2017 14:28:12 -0700 (PDT) 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 u9lzRJ2ewa9c for ; Wed, 24 May 2017 14:28:10 -0700 (PDT) Received: from mail-wr0-x241.google.com (mail-wr0-x241.google.com [IPv6:2a00:1450:400c:c0c::241]) (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 2BB4512778E for ; Wed, 24 May 2017 14:28:10 -0700 (PDT) Received: by mail-wr0-x241.google.com with SMTP id v42so10911728wrc.3 for ; Wed, 24 May 2017 14:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h9XDsOP8qN8upvInu3RaFmR/RKo8XanLo7wJ3vogxT8=; b=MgAkWALhoRWxgNe3d690xAfQkyhbYc4aEClkib49DXY7N6R/6j6+okVUzuKAmO10J+ sN6pFRMgio962uEXr82FfEyuzphrmvjhskj/zGCD3IMNlBZH3oGuUpBeM7y1Ll/pJhRL 1lA2WQYNIe30q3wJho+wu7gLE9M9HQTfLHKcaPZKeMm8wFY68M88MiaNyqIW9hh+lId0 4dUmbw85SIOEIo0nL/nl4KdlDrVqKExM4r0b9bCRp+GOxwfKnmWZfzxBDyndWT4lYuAr rQQxwvGkVSgsk17KaePUk8HsJ7tfNsjtabJVJiEuA5DUNlnDR6BP4+3sJFqAuzou2r7O ryiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=h9XDsOP8qN8upvInu3RaFmR/RKo8XanLo7wJ3vogxT8=; b=P2eD/NleHyw1MT3ismbvusp9+kEd3GOc5x7g0WDmPeiIyLszjImDE178Z2rPn80XVF /pUE7U+RoLn1qK3Dnv8dGMwgDtNZnoUb8H4CKBiFe88RqbVGuirwkafoKgO3UnizxZjz vHZdIUBgDhmtbnBu/KzLo0848qSONPT88G4v+Vqx94Khfd2vhbCMdGUBorOOA7Fe1ff6 x22ofGG/Icew+B9xqn5LVdrzrUvbsOTOWBCnnzeu/dynJVh4DBPKg8TFU/PCxqGTjSWZ WTE079uaEWCtORxfGctGcPZuLtR9ofIrrAiTlgNIfFDOfWu4IbgYvRYRCJr44+Upsnpm gN5g== X-Gm-Message-State: AODbwcCqPWjYerHSqBtqqdsZFa4oZyIOn06DQVgE4/LxsitdC6vATgBm 5LZEg1718EbIQQ== X-Received: by 10.223.166.75 with SMTP id k69mr12524034wrc.115.1495661288637; Wed, 24 May 2017 14:28:08 -0700 (PDT) Received: from [192.168.120.156] (sample.res240.o2.ie. [95.83.240.1]) by smtp.gmail.com with ESMTPSA id q195sm1604012wmd.7.2017.05.24.14.28.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 May 2017 14:28:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: fredbakersba@gmail.com X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Wed, 24 May 2017 22:28:07 +0100 Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "Jerome Henry (jerhenry)" Content-Transfer-Encoding: quoted-printable Message-Id: References: <5923F086.8030804@erg.abdn.ac.uk> To: "Tim Szigeti (szigeti)" Archived-At: Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - editorial comments X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 21:28:12 -0000 .The top-level observation (I'll follow-up with another email if needed abou= t >> specific text) is that the latest revision discusses the way in which acc= ess >> points and wireless devices can change the DSCP marking or drop traffic >> because of the DSCP marking. >>=20 >=20 > I'd like to first stress the point that the remarking and dropping recomme= ndations of network control traffic (marked CS6/CS7) at the edge of the wire= d-to-wireless network (as made in Section 4.1.1) were part of the original 2= 015 draft, and are not new recommendations in this latest revision.=20 >=20 > Additionally, these recommendations are drawn from similar recommendations= made in RFC 4594-Section 3.2 which: >=20 > "RECOMMENDED that packets marked CS7 > DSCP (a codepoint that SHOULD be reserved for future use) be dropped > or remarked at the edge of the Diffserv domain." >=20 > Our argument is that when the wireless access point represents the edge of= the network infrastructure (and thus the edge of the Diffserv domain), this= recommendation should hold;=20 For CS7 (and any DSCP value not implemented in the domain) I would agree tha= t it should be remarked or dropped. For CS6, recall that I have pointed out t= he assumptions that WiFi is the edge of the diffusers domain and has no IP l= ayer routing across it. I think, and have said before that I think, that is a= limiting assumption.= From nobody Wed May 24 15:24: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 2E1FC1242F7; Wed, 24 May 2017 15:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Ui7m4ug8jzFP; Wed, 24 May 2017 15:24:29 -0700 (PDT) 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 4568D129B48; Wed, 24 May 2017 15:24:27 -0700 (PDT) Received: from [128.9.184.77] ([128.9.184.77]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4OMNIYG001558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 May 2017 15:23:19 -0700 (PDT) To: gorry@erg.abdn.ac.uk, tsvwg@ietf.org Cc: tsvwg-chairs@ietf.org References: <591BEE59.8030709@erg.abdn.ac.uk> From: Joe Touch Message-ID: <070f5d06-303c-f1d4-e777-f2dec4a936e6@isi.edu> Date: Wed, 24 May 2017 15:23:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <591BEE59.8030709@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [tsvwg] Adoption call: draft-touch-tsvwg-udp-options-09 to end 31st May 2017 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 22:24:30 -0000 To state the obvious, as author, I support WG adoption of this doc. Joe On 5/16/2017 11:31 PM, Gorry Fairhurst wrote: > The TSVWG chairs are considering adoption of the draft > "Transport Options for UDP". This draft has been discussed at previous > IETF meetings and on the list, and the chairs are now looking for > input from the group to help inform whether TSVWG should adopt this > draft. > > * Please send an email to this list if you would like to see this work > adopted in TSVWG, or you have comments on the suitability for adoption. > > * Please indicate if you are willing to REVIEW such a document during > its development. > > Please send all notes of support/comments to the TSVWG list or the WG > chairs > by the date above. > > Best wishes, > > Gorry, David and Wes. > (TSVWG Co-Chairs) > > 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. > From nobody Wed May 24 15:35: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 D00B51293D9; Wed, 24 May 2017 15:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzvTgLryXoaL; Wed, 24 May 2017 15:35:02 -0700 (PDT) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 13E9E128D64; Wed, 24 May 2017 15:35:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=81Ncocu4YZGvUdeJuLLq3BzB86qq/yQOP0nkw/cdsjM=; b=4NKNCN1aLib0IIlojcqrgomJH vcf2Ro4VWM0Yu2+IK438RwTfg/qUCIzCwQ+ansiWt9ogLtc5ETb/SNPiIi0rsVfHuwbYCZKFvzE7N l6ELGN8BiuHSV8DCMEUlDcwza9FPrDx9qv6bv/bFMQkg2r7S0CUBMBhpMlVO7y4+skhO93sxdNLNF tu3u4+oogtGIacIpICsa3cIoKM6dTd+xOnoLtJKGFBpfI5aRFJR5xcU2eYqqlkdvAoPpyNbhUScmW xA8qAdXWV7oeXDtqVSB1imt+nwEUetqy/KmJaY8QYDGJAtZ5wbW6LjhchXB9h6lMtw4yzLq8crgnM RPYz0ODlw==; Received: from 197.74.9.51.dyn.plus.net ([51.9.74.197]:56094 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dDerr-0002ol-IH; Wed, 24 May 2017 23:34:59 +0100 To: Michael Menth Cc: "Rong Pan (ropan)" , tsvwg IETF list , AQM IETF list References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net> <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net> <471e91b1-c469-3d36-9af1-0411e5661286@uni-tuebingen.de> From: Bob Briscoe Message-ID: Date: Wed, 24 May 2017 23:34:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <471e91b1-c469-3d36-9af1-0411e5661286@uni-tuebingen.de> Content-Type: multipart/alternative; boundary="------------2EEAE8EAF749BE29C695A14A" Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic - moving averages and rate measurement X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 22:35:05 -0000 This is a multi-part message in MIME format. --------------2EEAE8EAF749BE29C695A14A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Michael, I just started reading your paper. Two comments so far: *1) PIE rate averaging is an unfortunate example** *In related work, you mention PIE's measurement of the link rate as an example of use of moving averages. This is an unfortunate example, because the PIE code screws up the calculation. It averages a fraction by averaging the denominator, which I pointed out is wrong in Section 5.3.2 of my PIE review . Quoting... "The [PIE] pseudocode continually measures the sequence of dequeue times, t1, t2, t3,... that it takes to transmit constant amounts of bytes (DQ_THRESHOLD). Then the exponentially weighted moving average (EWMA) of the rate should be: ewma(depart_rate) = DQ_THRESHOLD ∗ ewma(1/t1,1/t2,1/t3,...) != DQ_THRESHOLD / ewma(t1,t2,t3,...) " PIE uses the second (incorrect) formula. In the review, I discuss how wrong this could be, with an example. *2) Exponential Moving Average is an Approximation** *In your moving averages paper, you compare your unbiased exponential moving average (UEMA) algorithm with this commonly used exponential moving average (EMA) algorithm: ewma(X) <- (1-a)*X + a*ewma(X) A few years ago I wondered about this comparison, and wrote a 2-page memo for myself to record the proof. I've temporarily uploaded it here: Moving Averages . I used a Taylor series expansion to show that the iterative formula tends to the exact formula (what you call the unbiased EMA or UEMA) as the number of readings (n) becomes large. When n is not large, you could use the formula at the top of my p2 (just before the Taylor series approximation) to calculate the ratio between the actual (unbiased) UEMA and my regular iterative EMA (REMA). This ratio can be pre-calculated, because its independent of the readings: REMA/UEMA = (1-a)*(Sum_{j=0}^{n-1} a^j) where "theta" in my formula is "a" in yours "Sum_{j=0}^{n-1}" means "the sum from j=0 to j=n-1" Your iterative formula (EMA) starts with an exception, whereas I use an iterative formula that just starts the same as it carries on. To distinguish between them, I have called mine "regular EMA" or REMA. For instance, if a = 0.75 as in your Fig 1(c), then the correction factors for various small numbers of readings, n, are: n UEMA/REMA _____________________ 1 2.29 2 1.73 3 1.46 4 1.31 5 1.22 6 1.15 7 1.11 8 1.08 9 1.06 10 1.04 11 1.03 12 1.02 13 1.02 14 1.01 15 1.01 16 1.01 17 1.01 18 1.00 19 1.00 20 1.00 Cheers Bob On 30/03/17 10:57, Michael Menth wrote: > Hi all, > > Am 30.03.2017 um 11:08 schrieb Jonathan Morton: >>> On 30 Mar, 2017, at 10:46, Bob Briscoe wrote: >>> >>> For PI2 we removed all but 2 and it worked the same or better than PIE in all our tests. I have been assessing each of the other 7 one by one for reinstatement. So far I've rejected 6. I think I can reject this last one by making the sampling time of the base PI algo dependent on the max link rate. Then when the queue goes idle, the base PI algo will decay drop down to zero no slower than the queue drains, without needing this extra heuristic. >> That’s fair enough. >> >> It sounds like the fairly coarsely discrete time intervals in PIE are the main justification for this particular heuristic, so it might be sufficient to document that WRT PIE itself. Using finer time intervals is clearly a better choice for the future. > PIE uses time intervals for measurement purposes and several parameters > contribute. We've recently done some basic work on measurement > methodology that facilitates a comparison of different measurement > approaches and better-informed parametrization by introduction of the > "memory" concept. > https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth17c.pdf > PIE essentially implements TDRM-DTWMA-UEMA illustrated in Fig. 6d. > > The concept of "memory" can also be applied to moving averages which are > also used in PIE for several purposes. Configuration via a "memory" can > make some heuristics more intuitive. > > Best wishes, > > Michael > > > >> - Jonathan Morton >> -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ --------------2EEAE8EAF749BE29C695A14A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Michael,

I just started reading your paper. Two comments so far:

1) PIE rate averaging is an unfortunate example
In related work, you mention PIE's measurement of the link rate as an example of use of moving averages. This is an unfortunate example, because the PIE code screws up the calculation. It averages a fraction by averaging the denominator, which I pointed out is wrong in Section 5.3.2 of my PIE review. Quoting...

"The [PIE] pseudocode continually measures the sequence of dequeue times, t1, t2, t3,... that it takes to transmit constant amounts of bytes (DQ_THRESHOLD). Then the exponentially weighted moving average (EWMA) of the rate should be:

    ewma(depart_rate) = DQ_THRESHOLD ∗ ewma(1/t1,1/t2,1/t3,...)
                     != DQ_THRESHOLD / ewma(t1,t2,t3,...)
"
PIE uses the second (incorrect) formula. In the review, I discuss how wrong this could be, with an example.

2) Exponential Moving Average is an Approximation
In your moving averages paper, you compare your unbiased exponential moving average (UEMA) algorithm with this commonly used exponential moving average (EMA) algorithm:
    ewma(X) <- (1-a)*X + a*ewma(X)

A few years ago I wondered about this comparison, and wrote a 2-page memo for myself to record the proof. I've temporarily uploaded it here: Moving Averages.

I used a Taylor series expansion to show that the iterative formula tends to the exact formula (what you call the unbiased EMA or UEMA) as the number of readings (n) becomes large.

When n is not large, you could use the formula at the top of my p2 (just before the Taylor series approximation) to calculate the ratio between the actual (unbiased) UEMA and my regular iterative EMA (REMA). This ratio can be pre-calculated, because its independent of the readings:
    REMA/UEMA = (1-a)*(Sum_{j=0}^{n-1} a^j)

where
  "theta" in my formula is "a" in yours
  "Sum_{j=0}^{n-1}" means "the sum from j=0 to j=n-1"
  Your iterative formula (EMA) starts with an exception, whereas I use an iterative formula that just starts the same as it carries on. To distinguish between them, I have called mine "regular EMA" or REMA.

For instance, if a = 0.75 as in your Fig 1(c), then the correction factors for various small numbers of readings, n, are:

n       UEMA/REMA
_____________________
1            2.29
2            1.73
3            1.46
4            1.31
5            1.22
6            1.15
7            1.11
8            1.08
9            1.06
10            1.04
11            1.03
12            1.02
13            1.02
14            1.01
15            1.01
16            1.01
17            1.01
18            1.00
19            1.00
20            1.00


Cheers


Bob

On 30/03/17 10:57, Michael Menth wrote:
Hi all,

Am 30.03.2017 um 11:08 schrieb Jonathan Morton:


        

          
On 30 Mar, 2017, at 10:46, Bob Briscoe <ietf@bobbriscoe.net> wrote:

For PI2 we removed all but 2 and it worked the same or better than PIE in all our tests. I have been assessing each of the other 7 one by one for reinstatement. So far I've rejected 6. I think I can reject this last one by making the sampling time of the base PI algo dependent on the max link rate. Then when the queue goes idle, the base PI algo will decay drop down to zero no slower than the queue drains, without needing this extra heuristic.


        

        
That’s fair enough.

It sounds like the fairly coarsely discrete time intervals in PIE are the main justification for this particular heuristic, so it might be sufficient to document that WRT PIE itself.  Using finer time intervals is clearly a better choice for the future.


      

      
PIE uses time intervals for measurement purposes and several parameters
contribute. We've recently done some basic work on measurement
methodology that facilitates a comparison of different measurement
approaches and better-informed parametrization by introduction of the
"memory" concept.
https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth17c.pdf
PIE essentially implements TDRM-DTWMA-UEMA illustrated in Fig. 6d.

The concept of "memory" can also be applied to moving averages which are
also used in PIE for several purposes. Configuration via a "memory" can
make some heuristics more intuitive.

Best wishes,

Michael





      

        
 - Jonathan Morton



      

      

    

    

    
-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

  


--------------2EEAE8EAF749BE29C695A14A--


From nobody Wed May 24 18:43: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 4EE69129465 for ; Wed, 24 May 2017 18:43:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 1FyhEn4WI6Y0 for ; Wed, 24 May 2017 18:43:48 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BBB128796 for ; Wed, 24 May 2017 18:43:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2922; q=dns/txt; s=iport; t=1495676628; x=1496886228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RX/9me2oqqsRLfL7hc3RXfyeyJkp0+ugQ0GnaFCEfnY=; b=h3+3ub9ZKKVMAqthzULd7VhAFK9gCpupD5eO5ftY7jmXT+auS0doSz4T x5kwxCesdRjI/gpMesh6HpAiLuRhtlsRRLhgGb4oUOOcVL3nT3W3JnhlP otQCTkTZ242mtv1eN2MP7fHPLok96HQzLYsaZcZuWzu7B+mnyadV3yiuo 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAACaNSZZ/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1WBbgeOAJFciCeNUIIPhiQCgnM/GAECAQEBAQEBAWsdC4UYAQE?= =?us-ascii?q?BAQIBOj8FBwQCAQgRBAEBHwkHIREUCQgCBA4FCIoGAw0IsE+HNA2EEQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2LWYJVgV8BEgGGDgWdaDsBjk+ET5IAizKJGwEfOH8?= =?us-ascii?q?LcRWFPRyBY3aHFIEhgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.38,389,1491264000"; d="scan'208";a="429058749"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 May 2017 01:43:47 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v4P1hlR2011434 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 May 2017 01:43:47 GMT
Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 24 May 2017 20:43:47 -0500
Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Wed, 24 May 2017 20:43:47 -0500
From: "Tim Szigeti (szigeti)" 
To: "fredbakersba@gmail.com" 
CC: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "Jerome Henry (jerhenry)" 
Thread-Topic: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
Thread-Index: AQHS051LwDLgd1DAnEe9GMav17WLLaID5vqAgABu4YD///HYEA==
Date: Thu, 25 May 2017 01:43:47 +0000
Message-ID: <5d3c37a54bfb4cfab699613e34b32a5f@XCH-RCD-010.cisco.com>
References: <5923F086.8030804@erg.abdn.ac.uk>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.132.12.130]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 01:43:50 -0000

Hi Fred,

> For CS7 (and any DSCP value not implemented in the domain) I would agree
> that it should be remarked or dropped. For CS6, recall that I have pointe=
d out
> the assumptions that WiFi is the edge of the diffusers domain and has no =
IP
> layer routing across it. I think, and have said before that I think, that=
 is a
> limiting assumption.

Nothing is being assumed here Fred. Two distinct recommendations are being =
made:

In the case where the wireless access-point represents the edge of the netw=
ork (and thus simultaneously the edge of the Diffserv domain), then a recom=
mendation is being made to remark or drop packets marked CS6 or CS7 (as the=
re are no downstream devices participating in network control exchanges, an=
d preserving these markings presents an easy attack-vector for WLAN DoS).

In the deployment model where the wireless access-point is NOT the edge of =
the network, then this recommendation does not apply (as brought out in Sec=
tion 4.1.1).

A single recommendation simply will not ensure secure and consistent QoS tr=
eatment in both wireless deployment models.

-tim


> -----Original Message-----
> From: fredbakersba@gmail.com [mailto:fredbakersba@gmail.com]
> Sent: Wednesday, May 24, 2017 2:28 PM
> To: Tim Szigeti (szigeti)
> Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; Jerome Henry (jerhenry)
> Subject: Re: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
>=20
> .The top-level observation (I'll follow-up with another email if needed a=
bout
> >> specific text) is that the latest revision discusses the way in which
> >> access points and wireless devices can change the DSCP marking or
> >> drop traffic because of the DSCP marking.
> >>
> >
> > I'd like to first stress the point that the remarking and dropping
> recommendations of network control traffic (marked CS6/CS7) at the edge o=
f
> the wired-to-wireless network (as made in Section 4.1.1) were part of the
> original 2015 draft, and are not new recommendations in this latest revis=
ion.
> >
> > Additionally, these recommendations are drawn from similar
> recommendations made in RFC 4594-Section 3.2 which:
> >
> > "RECOMMENDED that packets marked CS7
> >   DSCP (a codepoint that SHOULD be reserved for future use) be dropped
> >   or remarked at the edge of the Diffserv domain."
> >
> > Our argument is that when the wireless access point represents the
> > edge of the network infrastructure (and thus the edge of the Diffserv
> > domain), this recommendation should hold;
>=20
> For CS7 (and any DSCP value not implemented in the domain) I would agree
> that it should be remarked or dropped. For CS6, recall that I have pointe=
d out
> the assumptions that WiFi is the edge of the diffusers domain and has no =
IP
> layer routing across it. I think, and have said before that I think, that=
 is a
> limiting assumption.


From nobody Wed May 24 23:49: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 01019126D45 for ; Wed, 24 May 2017 23:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level: 
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 4A8W6McsL-TV for ; Wed, 24 May 2017 23:49:24 -0700 (PDT)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFC91242F7 for ; Wed, 24 May 2017 23:49:18 -0700 (PDT)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 25 May 2017 06:49:18 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id A4B38D788E for ; Wed, 24 May 2017 23:49:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; s=selector1; bh=o2E48RSlnCKnarLqKJ6ngYuTK0E=; b=Kg 9eX13sxL4ZGwEs+Ad2TSslzdufPoCWMj4nHWTCE9D8gmS8/2e8wCNDjCNw6IMR66 v+MdOtWVmmhNN7TztFgODtfSg7P2AOigzw+SpGjN7Bo5eVeXqigJWbEN7l6gIvL5 pVo0/6GW5Y1RsJiAALwonNNNRdvJLLnxEhyy+SdXg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=date:from :to:subject:message-id:references:mime-version:content-type :in-reply-to; q=dns; s=selector1; b=IlXe7TdqiuXFOdHjmQtWQi2D4Cmx HDNh4TX8gjJ8vGKvkRRHUmB8R3o4IMlctnB+5RQqeMEByJRCaldhaS8IF1PDUzc8 XswKnLDu765qY0r6nK7Y/gJ9Pj6BrT2N5KvhUAJkzyJ/HagohRgLnsZMi+T5l6py p4e8axVgJsm3yPM=
Received: by cowbell.employees.org (Postfix, from userid 1736) id 9A9FCD788D; Wed, 24 May 2017 23:49:17 -0700 (PDT)
Date: Thu, 25 May 2017 07:49:17 +0100
From: Derek Fawcus 
To: tsvwg@ietf.org
Message-ID: <20170525064917.GA55692@cowbell.employees.org>
Mail-Followup-To: tsvwg@ietf.org
References: <591BEE59.8030709@erg.abdn.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <591BEE59.8030709@erg.abdn.ac.uk>
User-Agent: Mutt/1.8.2 (2017-04-18)
Archived-At: 
Subject: Re: [tsvwg] Adoption call: draft-touch-tsvwg-udp-options-09 to end 31st May 2017
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 06:49:26 -0000

On Wed, May 17, 2017 at 07:31:53AM +0100, Gorry Fairhurst wrote:
> * Please send an email to this list if you would like to see this work adopted in TSVWG, or you have comments on the suitability for adoption.

I support adoption.

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

I'm willing to continue reviewing it.

DF


From nobody Thu May 25 00:55:58 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 5D03012E036; Thu, 25 May 2017 00:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yFsqfRxwRDNv; Thu, 25 May 2017 00:55:48 -0700 (PDT)
Received: from mx04.uni-tuebingen.de (mx04.uni-tuebingen.de [134.2.5.214]) (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 5F56812DFE0; Thu, 25 May 2017 00:55:47 -0700 (PDT)
Received: from [192.168.1.101] (hsi-kbw-5-56-217-255.hsi17.kabel-badenwuerttemberg.de [5.56.217.255]) by mx04.uni-tuebingen.de (Postfix) with ESMTPSA id 033615C420; Thu, 25 May 2017 09:55:43 +0200 (CEST)
To: Bob Briscoe 
References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net>  <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net>  <471e91b1-c469-3d36-9af1-0411e5661286@uni-tuebingen.de> 
Cc: "Rong Pan (ropan)" , tsvwg IETF list , AQM IETF list 
From: Michael Menth 
Message-ID: 
Date: Thu, 25 May 2017 09:55:40 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic - moving averages and rate measurement
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 07:55:51 -0000

Hi Bob, hi Rong,

Am 25.05.2017 um 00:34 schrieb Bob Briscoe:
> Michael,
> 
> I just started reading your paper. Two comments so far:
> 
> *1) PIE rate averaging is an unfortunate example**
> *In related work, you mention PIE's measurement of the link rate as an
> example of use of moving averages. This is an unfortunate example,
> because the PIE code screws up the calculation. It averages a fraction
> by averaging the denominator, which I pointed out is wrong in Section
> 5.3.2 of my PIE review .
> Quoting...
> 
> "The [PIE] pseudocode continually measures the sequence of dequeue
> times, t1, t2, t3,... that it takes to transmit constant amounts of
> bytes (DQ_THRESHOLD). Then the exponentially weighted moving average
> (EWMA) of the rate should be:
> 
>     ewma(depart_rate) = DQ_THRESHOLD ∗ ewma(1/t1,1/t2,1/t3,...)
>                      != DQ_THRESHOLD / ewma(t1,t2,t3,...)
> "
> PIE uses the second (incorrect) formula. In the review, I discuss how
> wrong this could be, with an example.

Thanks, Bob, for pointing this out to me.

Rong, is PIE doing this by intent (if so, what's the reason?) or is this
a flaw?

> 
> *2) Exponential Moving Average is an Approximation**
> *In your moving averages paper, you compare your unbiased exponential
> moving average (UEMA) algorithm with this commonly used exponential
> moving average (EMA) algorithm:
>     ewma(X) <- (1-a)*X + a*ewma(X)
> 
> A few years ago I wondered about this comparison, and wrote a 2-page
> memo for myself to record the proof. I've temporarily uploaded it here:
> Moving Averages .
> 
> I used a Taylor series expansion to show that the iterative formula
> tends to the exact formula (what you call the unbiased EMA or UEMA) as
> the number of readings (n) becomes large.
> 
> When n is not large, you could use the formula at the top of my p2 (just
> before the Taylor series approximation) to calculate the ratio between
> the actual (unbiased) UEMA and my regular iterative EMA (REMA). This
> ratio can be pre-calculated, because its independent of the readings:
>     REMA/UEMA = (1-a)*(Sum_{j=0}^{n-1} a^j)
> 
> where
>   "theta" in my formula is "a" in yours
>   "Sum_{j=0}^{n-1}" means "the sum from j=0 to j=n-1"
>   Your iterative formula (EMA) starts with an exception, whereas I use
> an iterative formula that just starts the same as it carries on. To
> distinguish between them, I have called mine "regular EMA" or REMA.
> 
> For instance, if a = 0.75 as in your Fig 1(c), then the correction
> factors for various small numbers of readings, n, are:
> 
> n       UEMA/REMA
> _____________________
> 1            2.29
> 2            1.73
> 3            1.46
> 4            1.31
> 5            1.22
> 6            1.15
> 7            1.11
> 8            1.08
> 9            1.06
> 10            1.04
> 11            1.03
> 12            1.02
> 13            1.02
> 14            1.01
> 15            1.01
> 16            1.01
> 17            1.01
> 18            1.00
> 19            1.00
> 20            1.00
Yes, the bias of E(W)MA is caused by the first sample and vanishes over
time. If EMA runs continuously, it has no impact. If EMA is continuously
restarted, it may have an impact. However, this is only a minor aspect
of the paper.
https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth17c.pdf

The major contribution of the paper is a framework that brings together
various types of moving averages, moving histograms and rate measurement
methods. In particular, it relates E(W)MA's "magic weight parameter" to
a memory which is also implemented by other methods (with other
parameters). The concept of a memory simplifies many engineering problems.

Regards,

Michael

> 
> 
> Cheers
> 
> 
> Bob
> 
> On 30/03/17 10:57, Michael Menth wrote:
>> Hi all,
>>
>> Am 30.03.2017 um 11:08 schrieb Jonathan Morton:
>>>> On 30 Mar, 2017, at 10:46, Bob Briscoe  wrote:
>>>>
>>>> For PI2 we removed all but 2 and it worked the same or better than PIE in all our tests. I have been assessing each of the other 7 one by one for reinstatement. So far I've rejected 6. I think I can reject this last one by making the sampling time of the base PI algo dependent on the max link rate. Then when the queue goes idle, the base PI algo will decay drop down to zero no slower than the queue drains, without needing this extra heuristic.
>>> That’s fair enough.
>>>
>>> It sounds like the fairly coarsely discrete time intervals in PIE are the main justification for this particular heuristic, so it might be sufficient to document that WRT PIE itself.  Using finer time intervals is clearly a better choice for the future.
>> PIE uses time intervals for measurement purposes and several parameters
>> contribute. We've recently done some basic work on measurement
>> methodology that facilitates a comparison of different measurement
>> approaches and better-informed parametrization by introduction of the
>> "memory" concept.
>> https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth17c.pdf
>> PIE essentially implements TDRM-DTWMA-UEMA illustrated in Fig. 6d.
>>
>> The concept of "memory" can also be applied to moving averages which are
>> also used in PIE for several purposes. Configuration via a "memory" can
>> make some heuristics more intuitive.
>>
>> Best wishes,
>>
>> Michael
>>
>>
>>
>>>  - Jonathan Morton
>>>
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
> 

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:menth@uni-tuebingen.de
http://kn.inf.uni-tuebingen.de


From nobody Thu May 25 07:14:34 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 0D3E41296B3; Thu, 25 May 2017 07:14:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149572166700.8641.5675183636701405201@ietfa.amsl.com>
Date: Thu, 25 May 2017 07:14:27 -0700
Archived-At: 
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ieee-802-11-03.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 14:14:27 -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           : Diffserv to IEEE 802.11 Mapping
        Authors         : Tim Szigeti
                          Jerome Henry
                          Fred Baker
	Filename        : draft-ietf-tsvwg-ieee-802-11-03.txt
	Pages           : 33
	Date            : 2017-05-24

Abstract:
   As internet traffic is increasingly sourced-from and destined-to
   wireless endpoints, it is crucial that Quality of Service be aligned
   between wired and wireless networks; however, this is not always the
   case by default.  This document specifies a set Differentiated
   Services Code Point (DSCP) to IEEE 802.11 User Priority (UP) mappings
   to reconcile the marking recommendations offered by the IETF and the
   IEEE so as to maintain consistent QoS treatment between wired and
   IEEE 802.11 wireless networks.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ieee-802-11/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-03
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ieee-802-11-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ieee-802-11-03


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri May 26 10:26: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 723D1129459; Fri, 26 May 2017 10:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hg1kJRXCQzc; Fri, 26 May 2017 10:26:02 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 19C3F129329; Fri, 26 May 2017 10:26:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZufaqL8ZdoT9KPu9divz2I/6rT7leMQEWBXqbxnnG/o=; b=B7C7NUnUVOqrDAcBNZDjbgS5kE LGDCZED4nwUX4uHn8EVg00o2Dnl7s3TbQWQdKfveEQtt1OVgaO52nv7Gh4isYXrGwKHUhaRn6WZow JIIe5jEuxQl1gnlgEwE6/wO+f9DGILTbjT1Y7C4qQn6T7/6iEn7xe4zP4FORChDu7dU6TX+W6UOkl hI39b6JWD2gqNkfAYyyqkCSp+twEEiZX172vN4CbzjKXmzo8FBa3eDGJ4oCO+99NN0mJMDPh1vBZN yHYBHimgMgVA9HRoCqhkvf/jC2hDIOzz+/2h6LkIBevfT+U56KC9Olw1gUF3hHex2E7a6EqtLOGwb FiQb6b2w==;
Received: from 197.74.9.51.dyn.plus.net ([51.9.74.197]:37116 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dEIzv-0003Pt-Vg; Fri, 26 May 2017 18:26:00 +0100
To: Michael Menth 
Cc: "Rong Pan (ropan)" , tsvwg IETF list , AQM IETF list 
References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net>  <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net>  <471e91b1-c469-3d36-9af1-0411e5661286@uni-tuebingen.de>  
From: Bob Briscoe 
Message-ID: <404874be-32a9-4425-b2ff-5fbff804b5ee@bobbriscoe.net>
Date: Fri, 26 May 2017 18:25:59 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic - moving averages and rate measurement
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 17:26:05 -0000

Michael,

Yes, I should have said that the most useful aspect of your paper is the 
model that ties all the different algos together allowing comparison.


Bob

On 25/05/17 08:55, Michael Menth wrote:
> Hi Bob, hi Rong,
>
> Am 25.05.2017 um 00:34 schrieb Bob Briscoe:
>> Michael,
>>
>> I just started reading your paper. Two comments so far:
>>
>> *1) PIE rate averaging is an unfortunate example**
>> *In related work, you mention PIE's measurement of the link rate as an
>> example of use of moving averages. This is an unfortunate example,
>> because the PIE code screws up the calculation. It averages a fraction
>> by averaging the denominator, which I pointed out is wrong in Section
>> 5.3.2 of my PIE review .
>> Quoting...
>>
>> "The [PIE] pseudocode continually measures the sequence of dequeue
>> times, t1, t2, t3,... that it takes to transmit constant amounts of
>> bytes (DQ_THRESHOLD). Then the exponentially weighted moving average
>> (EWMA) of the rate should be:
>>
>>      ewma(depart_rate) = DQ_THRESHOLD ∗ ewma(1/t1,1/t2,1/t3,...)
>>                       != DQ_THRESHOLD / ewma(t1,t2,t3,...)
>> "
>> PIE uses the second (incorrect) formula. In the review, I discuss how
>> wrong this could be, with an example.
> Thanks, Bob, for pointing this out to me.
>
> Rong, is PIE doing this by intent (if so, what's the reason?) or is this
> a flaw?
>
>> *2) Exponential Moving Average is an Approximation**
>> *In your moving averages paper, you compare your unbiased exponential
>> moving average (UEMA) algorithm with this commonly used exponential
>> moving average (EMA) algorithm:
>>      ewma(X) <- (1-a)*X + a*ewma(X)
>>
>> A few years ago I wondered about this comparison, and wrote a 2-page
>> memo for myself to record the proof. I've temporarily uploaded it here:
>> Moving Averages .
>>
>> I used a Taylor series expansion to show that the iterative formula
>> tends to the exact formula (what you call the unbiased EMA or UEMA) as
>> the number of readings (n) becomes large.
>>
>> When n is not large, you could use the formula at the top of my p2 (just
>> before the Taylor series approximation) to calculate the ratio between
>> the actual (unbiased) UEMA and my regular iterative EMA (REMA). This
>> ratio can be pre-calculated, because its independent of the readings:
>>      REMA/UEMA = (1-a)*(Sum_{j=0}^{n-1} a^j)
>>
>> where
>>    "theta" in my formula is "a" in yours
>>    "Sum_{j=0}^{n-1}" means "the sum from j=0 to j=n-1"
>>    Your iterative formula (EMA) starts with an exception, whereas I use
>> an iterative formula that just starts the same as it carries on. To
>> distinguish between them, I have called mine "regular EMA" or REMA.
>>
>> For instance, if a = 0.75 as in your Fig 1(c), then the correction
>> factors for various small numbers of readings, n, are:
>>
>> n       UEMA/REMA
>> _____________________
>> 1            2.29
>> 2            1.73
>> 3            1.46
>> 4            1.31
>> 5            1.22
>> 6            1.15
>> 7            1.11
>> 8            1.08
>> 9            1.06
>> 10            1.04
>> 11            1.03
>> 12            1.02
>> 13            1.02
>> 14            1.01
>> 15            1.01
>> 16            1.01
>> 17            1.01
>> 18            1.00
>> 19            1.00
>> 20            1.00
> Yes, the bias of E(W)MA is caused by the first sample and vanishes over
> time. If EMA runs continuously, it has no impact. If EMA is continuously
> restarted, it may have an impact. However, this is only a minor aspect
> of the paper.
> https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth17c.pdf
>
> The major contribution of the paper is a framework that brings together
> various types of moving averages, moving histograms and rate measurement
> methods. In particular, it relates E(W)MA's "magic weight parameter" to
> a memory which is also implemented by other methods (with other
> parameters). The concept of a memory simplifies many engineering problems.
>
> Regards,
>
> Michael
>
>>
>> Cheers
>>
>>
>> Bob
>>
>> On 30/03/17 10:57, Michael Menth wrote:
>>> Hi all,
>>>
>>> Am 30.03.2017 um 11:08 schrieb Jonathan Morton:
>>>>> On 30 Mar, 2017, at 10:46, Bob Briscoe  wrote:
>>>>>
>>>>> For PI2 we removed all but 2 and it worked the same or better than PIE in all our tests. I have been assessing each of the other 7 one by one for reinstatement. So far I've rejected 6. I think I can reject this last one by making the sampling time of the base PI algo dependent on the max link rate. Then when the queue goes idle, the base PI algo will decay drop down to zero no slower than the queue drains, without needing this extra heuristic.
>>>> That’s fair enough.
>>>>
>>>> It sounds like the fairly coarsely discrete time intervals in PIE are the main justification for this particular heuristic, so it might be sufficient to document that WRT PIE itself.  Using finer time intervals is clearly a better choice for the future.
>>> PIE uses time intervals for measurement purposes and several parameters
>>> contribute. We've recently done some basic work on measurement
>>> methodology that facilitates a comparison of different measurement
>>> approaches and better-informed parametrization by introduction of the
>>> "memory" concept.
>>> https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth17c.pdf
>>> PIE essentially implements TDRM-DTWMA-UEMA illustrated in Fig. 6d.
>>>
>>> The concept of "memory" can also be applied to moving averages which are
>>> also used in PIE for several purposes. Configuration via a "memory" can
>>> make some heuristics more intuitive.
>>>
>>> Best wishes,
>>>
>>> Michael
>>>
>>>
>>>
>>>>   - Jonathan Morton
>>>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Fri May 26 11:30: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 B935F1293F9; Fri, 26 May 2017 11:30:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level: 
X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 vYqGOJ-zcKNN; Fri, 26 May 2017 11:30:00 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6EBD1271DF; Fri, 26 May 2017 11:29:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1332; q=dns/txt; s=iport; t=1495823400; x=1497033000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rMRZ8PYaZr3N7EXTGtaU9+y5jIEo4Ib9J0sdRLg8f2g=; b=XfVZdjaE77dCkyb9zxTaVDh4vgQpsXDb5L3VrriaRQPEjrNU7LzidJAM tJYR3WETi6FfpDimHDj9jVDkNBx6VHrdvm7FZWu46sa+Uo2TJznmud/7d J4r4ta3jnzPjVvphw8AUB/3NbKhjucK1GqIVHvM7/zemb+AUIuE9ADHxh c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAQCdcyhZ/4cNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1WBdoNoihinXoIPhiQCGoJwPxgBAgEBAQEBAQFrKIUZBiMEDUUQAgE?= =?us-ascii?q?IDgwCJgICAjAVEAIEAQ2KLgGrJoFsOotTAQEBAQEBAQEBAQEBAQEBAQEBAQEBH?= =?us-ascii?q?YELhVaBYCuCdId7L4IxAQSeIwGTJ5F3lE0BHziBCnQVWAGGb4hyAYEMAQEB?=
X-IronPort-AV: E=Sophos;i="5.38,398,1491264000"; d="scan'208";a="432076793"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2017 18:29:58 +0000
Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v4QITwMP014763 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 May 2017 18:29:58 GMT
Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 26 May 2017 13:29:57 -0500
Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1210.000; Fri, 26 May 2017 13:29:57 -0500
From: "Rong Pan (ropan)" 
To: Bob Briscoe , Michael Menth 
CC: tsvwg IETF list , AQM IETF list 
Thread-Topic: [aqm] Questioning each PIE heuristic - moving averages and rate measurement
Thread-Index: AQHSqTwWerDmuF5Yhk2304NzwwextKIEvUsAgACcqQCAAjGtgP//nIaA
Date: Fri, 26 May 2017 18:29:57 +0000
Message-ID: <9E1B8C70-B6C7-456C-B938-F2C08532FB69@cisco.com>
References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net>  <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net>  <471e91b1-c469-3d36-9af1-0411e5661286@uni-tuebingen.de>   <404874be-32a9-4425-b2ff-5fbff804b5ee@bobbriscoe.net>
In-Reply-To: <404874be-32a9-4425-b2ff-5fbff804b5ee@bobbriscoe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [171.71.130.238]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic - moving averages and rate measurement
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 18:30:02 -0000

TWljaGFlbCBhbmQgQm9iLA0KDQpUaGUgZGVwYXJ0X3JhdGUgaXMgaW52ZXJzZWQgaW4gY2FsY3Vs
YXRpb24gZGVsYXnigKYuDQpEZWxheSA9IHF1ZXVlX2xlbmd0aC9kZXBhcnRfcmF0ZTsgDQpIZW5j
ZSwgY3VycmVudF9xZGVsYXkgPSBxdWV1ZV8uYnl0ZV9sZW5ndGgoKSAqIFBJRS0gPmF2Z19kcV90
aW1lXy9EUV9USFJFU0hPTEQ7DQoNCkJhc2ljYWxseSB0aGUgYXZlcmFnZSBkcV90aW1lIGZvciBk
ZXF1ZXVlaW5nIERRX1RIUkVTSE9MRCBpcyBQSUUtPmRxX3RpbWU7IFdoYXQgaXMgdGhlIGFwcHJv
eGltYXRlIHRpbWUgdG8gZGVxdWUgdGhlIGN1cnJlbnRfcWxlbj8NCkN1cnJlbnRfcWxlbi9EUV9U
SFJFU0hPTEQod2hhdCBwb3J0aW9uIGlzIGN1cnJlbnQgcXVldWUgbGVuZ3RoIHJlbGF0aXZlIHRv
IERRX1RIUkVTSE9MRCk/ICogYXZnX2RxX3RpbWUuDQoNClRoYXQgaXMgdGhlIHJhdGlvbmFsZSBi
ZWhpbmQgaXQuDQoNClRoYW5rcywNCg0KUm9uZw0KDQogICAgPj4gKEVXTUEpIG9mIHRoZSByYXRl
IHNob3VsZCBiZToNCiAgICA+Pg0KICAgID4+ICAgICAgZXdtYShkZXBhcnRfcmF0ZSkgPSBEUV9U
SFJFU0hPTEQg4oiXIGV3bWEoMS90MSwxL3QyLDEvdDMsLi4uKQ0KICAgID4+ICAgICAgICAgICAg
ICAgICAgICAgICAhPSBEUV9USFJFU0hPTEQgLyBld21hKHQxLHQyLHQzLC4uLikNCiAgICA+PiAi
DQogICAgPj4gUElFIHVzZXMgdGhlIHNlY29uZCAoaW5jb3JyZWN0KSBmb3JtdWxhLiBJbiB0aGUg
cmV2aWV3LCBJIGRpc2N1c3MgaG93DQogICAgPj4gd3JvbmcgdGhpcyBjb3VsZCBiZSwgd2l0aCBh
biBleGFtcGxlLg0KICAgID4gVGhhbmtzLCBCb2IsIGZvciBwb2ludGluZyB0aGlzIG91dCB0byBt
ZS4NCiAgICA+DQogICAgPiBSb25nLCBpcyBQSUUgZG9pbmcgdGhpcyBieSBpbnRlbnQgKGlmIHNv
LCB3aGF0J3MgdGhlIHJlYXNvbj8pIG9yIGlzIHRoaXMNCiAgICA+IGEgZmxhdz8NCiAgICA+DQoN
Cg0K


From nobody Fri May 26 13:27: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 9DBA71287A5; Fri, 26 May 2017 13:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 hk9Q7WJjDr4D; Fri, 26 May 2017 13:27:20 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEC9127ABE; Fri, 26 May 2017 13:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2038; q=dns/txt; s=iport; t=1495830440; x=1497040040; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=M3UznZZUbUK87vqen9UGlFYCGojcxR6zA5eOfLNJWhU=; b=adzr3U9JyFjZ5rdwdeIpGlUsM5DIr22cspSyj83rYVxjYaasKk8+0HAq m5rwOJu1naNBwRt/s+7qMei8BcE5thwWf3z+N4inq3Bi7QCr5NhqOWplA 89EEer2fVlK2PSTmAK3uaxmfrmO2phQ533ZUidSN18TJlLFs7QGygYvEI I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AwAQBqjihZ/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQ0Hg2iKGJFElhqCDyELhXgCGoJwPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?ZAgEDAQEhBA06CxACAQgODAImAgICJQsVEAIEAQ0FiikBEKp7gWw6i1EBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYELhVaBYCsLgmmEaYMSL4IxAQSeIwGTJ5F3lE0?= =?us-ascii?q?BHziBCnQVRhIBhm92h3wBgQwBAQE?=
X-IronPort-AV: E=Sophos;i="5.38,399,1491264000"; d="scan'208";a="253371082"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2017 20:27:19 +0000
Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v4QKRJ66014116 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 May 2017 20:27:19 GMT
Received: from xch-aln-017.cisco.com (173.36.7.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 26 May 2017 15:27:18 -0500
Received: from xch-aln-017.cisco.com ([173.36.7.27]) by XCH-ALN-017.cisco.com ([173.36.7.27]) with mapi id 15.00.1210.000; Fri, 26 May 2017 15:27:18 -0500
From: "Rong Pan (ropan)" 
To: Bob Briscoe , Michael Menth 
CC: tsvwg IETF list , AQM IETF list 
Thread-Topic: [aqm] Questioning each PIE heuristic - moving averages and rate measurement
Thread-Index: AQHSqTwWerDmuF5Yhk2304NzwwextKIEvUsAgACcqQCAAjGtgP//nIaAgAAgygA=
Date: Fri, 26 May 2017 20:27:18 +0000
Message-ID: <1D08E138-629C-4551-AC0E-F0F82E536A6B@cisco.com>
References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net>  <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net>  <471e91b1-c469-3d36-9af1-0411e5661286@uni-tuebingen.de>   <404874be-32a9-4425-b2ff-5fbff804b5ee@bobbriscoe.net> <9E1B8C70-B6C7-456C-B938-F2C08532FB69@cisco.com>
In-Reply-To: <9E1B8C70-B6C7-456C-B938-F2C08532FB69@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.1a.0.160910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [171.71.130.238]
Content-Type: text/plain; charset="utf-8"
Content-ID: <41CC2A6E2B416F4681BB76010E726D09@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic - moving averages and rate measurement
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 20:27:21 -0000

QWRkaXRpb25hbCBjb25zaWRlcmF0aW9uIGlzIHRoYXQgMS90MSB3b3VsZCBpbnZvbHZlIGRpdmlk
ZSwgd2hpY2ggd2lsbCBiZSBoYXJkIHRvIGltcGxlbWVudCBpbiBoYXJkd2FyZeKApg0KDQpSZWdh
cmRzLA0KDQpSb25nDQoNCk9uIDUvMjYvMTcsIDExOjI5IEFNLCAiYXFtIG9uIGJlaGFsZiBvZiBS
b25nIFBhbiAocm9wYW4pIiA8YXFtLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJvcGFu
QGNpc2NvLmNvbT4gd3JvdGU6DQoNCiAgICBNaWNoYWVsIGFuZCBCb2IsDQogICAgDQogICAgVGhl
IGRlcGFydF9yYXRlIGlzIGludmVyc2VkIGluIGNhbGN1bGF0aW9uIGRlbGF54oCmLg0KICAgIERl
bGF5ID0gcXVldWVfbGVuZ3RoL2RlcGFydF9yYXRlOyANCiAgICBIZW5jZSwgY3VycmVudF9xZGVs
YXkgPSBxdWV1ZV8uYnl0ZV9sZW5ndGgoKSAqIFBJRS0gPmF2Z19kcV90aW1lXy9EUV9USFJFU0hP
TEQ7DQogICAgDQogICAgQmFzaWNhbGx5IHRoZSBhdmVyYWdlIGRxX3RpbWUgZm9yIGRlcXVldWVp
bmcgRFFfVEhSRVNIT0xEIGlzIFBJRS0+ZHFfdGltZTsgV2hhdCBpcyB0aGUgYXBwcm94aW1hdGUg
dGltZSB0byBkZXF1ZSB0aGUgY3VycmVudF9xbGVuPw0KICAgIEN1cnJlbnRfcWxlbi9EUV9USFJF
U0hPTEQod2hhdCBwb3J0aW9uIGlzIGN1cnJlbnQgcXVldWUgbGVuZ3RoIHJlbGF0aXZlIHRvIERR
X1RIUkVTSE9MRCk/ICogYXZnX2RxX3RpbWUuDQogICAgDQogICAgVGhhdCBpcyB0aGUgcmF0aW9u
YWxlIGJlaGluZCBpdC4NCiAgICANCiAgICBUaGFua3MsDQogICAgDQogICAgUm9uZw0KICAgIA0K
ICAgICAgICA+PiAoRVdNQSkgb2YgdGhlIHJhdGUgc2hvdWxkIGJlOg0KICAgICAgICA+Pg0KICAg
ICAgICA+PiAgICAgIGV3bWEoZGVwYXJ0X3JhdGUpID0gRFFfVEhSRVNIT0xEIOKIlyBld21hKDEv
dDEsMS90MiwxL3QzLC4uLikNCiAgICAgICAgPj4gICAgICAgICAgICAgICAgICAgICAgICE9IERR
X1RIUkVTSE9MRCAvIGV3bWEodDEsdDIsdDMsLi4uKQ0KICAgICAgICA+PiAiDQogICAgICAgID4+
IFBJRSB1c2VzIHRoZSBzZWNvbmQgKGluY29ycmVjdCkgZm9ybXVsYS4gSW4gdGhlIHJldmlldywg
SSBkaXNjdXNzIGhvdw0KICAgICAgICA+PiB3cm9uZyB0aGlzIGNvdWxkIGJlLCB3aXRoIGFuIGV4
YW1wbGUuDQogICAgICAgID4gVGhhbmtzLCBCb2IsIGZvciBwb2ludGluZyB0aGlzIG91dCB0byBt
ZS4NCiAgICAgICAgPg0KICAgICAgICA+IFJvbmcsIGlzIFBJRSBkb2luZyB0aGlzIGJ5IGludGVu
dCAoaWYgc28sIHdoYXQncyB0aGUgcmVhc29uPykgb3IgaXMgdGhpcw0KICAgICAgICA+IGEgZmxh
dz8NCiAgICAgICAgPg0KICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQogICAgYXFtIG1haWxpbmcgbGlzdA0KICAgIGFxbUBpZXRm
Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXFtDQogICAg
DQoNCg==


From nobody Fri May 26 17:45:17 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 48874129B48; Fri, 26 May 2017 17:45:10 -0700 (PDT)
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, 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=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofDoGhLjL0OC; Fri, 26 May 2017 17:45:08 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 5A26C129447; Fri, 26 May 2017 17:45:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Ii9MO9NytsJbG7jwt7E7TF6PqhimYzPAvKrZ9HDsVVg=; b=blvUdB+EBEc7O/wH38OBUFqxp4 GXk8EFVOzL5qTwTrTxNwPkT4OVa+GJDkssKPfvpySbU/kiLFu2yqkFOWNFP+23qh4FnSvzeKrWqIX KFHxGsWzJABcSCnhJCODv+9Ssn6ar3DvszFnBCtlxbVf2yn+uMhCwHn8icF5AINlXIIiEpkg/gNsY Jxj002fl5p0clds5HeZTlWjNzZm83fOy1E+9EBNcc6j+QZuOmKZVuZ2DSRXV68eUOQsHOV6uqin5L MJYA90ONxd3w5PQPGw5JQtwedZbRXFjeJ3pLh1BvmLZIs17fW73m51M52osgNH8ecyf7qPmsNaHpI QpvNceuA==;
Received: from 197.74.9.51.dyn.plus.net ([51.9.74.197]:38778 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dEPqk-0005k7-J4; Sat, 27 May 2017 01:45:00 +0100
To: "Rong Pan (ropan)" , Michael Menth 
Cc: tsvwg IETF list , AQM IETF list 
References: <9ddba389-e368-9050-3b14-aa235c99fcb8@bobbriscoe.net>  <77D4FC66-C99F-49D0-BB73-27A0CEF70F31@gmail.com> <99a7b737-fc3c-efd0-b6c8-d71a089b7de8@bobbriscoe.net>  <471e91b1-c469-3d36-9af1-0411e5661286@uni-tuebingen.de>   <404874be-32a9-4425-b2ff-5fbff804b5ee@bobbriscoe.net> <9E1B8C70-B6C7-456C-B938-F2C08532FB69@cisco.com>
From: Bob Briscoe 
Message-ID: 
Date: Sat, 27 May 2017 01:44:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <9E1B8C70-B6C7-456C-B938-F2C08532FB69@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tsvwg] [aqm] Questioning each PIE heuristic - moving averages and rate measurement
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 May 2017 00:45:10 -0000

Rong,

That's a good rationale.
I withdraw my criticism of PIE on this point.

The code is OK, it's just the explanation that is misleading. it 
shouldn't say it is measuring the average dequeue rate, and there's no 
need to. It should describe the calculation as a moving average of the 
time to dequeue a set amount of bytes, scaled by the queue size relative 
to that number of bytes.

Cheers


Bob

On 26/05/17 19:29, Rong Pan (ropan) wrote:
> Michael and Bob,
>
> The depart_rate is inversed in calculation delay….
> Delay = queue_length/depart_rate;
> Hence, current_qdelay = queue_.byte_length() * PIE- >avg_dq_time_/DQ_THRESHOLD;
>
> Basically the average dq_time for dequeueing DQ_THRESHOLD is PIE->dq_time; What is the approximate time to deque the current_qlen?
> Current_qlen/DQ_THRESHOLD(what portion is current queue length relative to DQ_THRESHOLD)? * avg_dq_time.
>
> That is the rationale behind it.
>
> Thanks,
>
> Rong
>
>      >> (EWMA) of the rate should be:
>      >>
>      >>      ewma(depart_rate) = DQ_THRESHOLD ∗ ewma(1/t1,1/t2,1/t3,...)
>      >>                       != DQ_THRESHOLD / ewma(t1,t2,t3,...)
>      >> "
>      >> PIE uses the second (incorrect) formula. In the review, I discuss how
>      >> wrong this could be, with an example.
>      > Thanks, Bob, for pointing this out to me.
>      >
>      > Rong, is PIE doing this by intent (if so, what's the reason?) or is this
>      > a flaw?
>      >
>
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Sun May 28 10:42:53 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 C9AA7129435 for ; Sun, 28 May 2017 10:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wWIB17LQZFcR for ; Sun, 28 May 2017 10:42:43 -0700 (PDT)
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 6E3B3129438 for ; Sun, 28 May 2017 10:42:43 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 463BB1B0176D; Sun, 28 May 2017 20:37:01 +0100 (BST)
Message-ID: <592B0BF4.2030204@erg.abdn.ac.uk>
Date: Sun, 28 May 2017 18:42:12 +0100
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "tsvwg@ietf.org" 
CC: gorry@erg.abdn.ac.uk, "Tim Szigeti (szigeti)" ,  "fredbakersba@gmail.com" , "Jerome Henry (jerhenry)" 
References: <5923F086.8030804@erg.abdn.ac.uk>   <5d3c37a54bfb4cfab699613e34b32a5f@XCH-RCD-010.cisco.com> <592A83D6.6080501@erg.abdn.ac.uk>
In-Reply-To: <592A83D6.6080501@erg.abdn.ac.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 May 2017 17:42:50 -0000

This email describes a number of concerns with the inclusion of 
conditioning rules in the 802-11 draft.

The title and abstract of the draft describe a mapping function. 
However, the changes in rev -02 give me serious doubts about the 
remarking and drop recommendations, which I consider for a diffserv edge.

Point 1: I think the WG need to be very clear about the context of 
recommendations. I’d expect the class mappings to PHBs to be applied in 
all equipment that adheres to IETF standards. This should I think be the 
default for all APs - and I'd hope most vendors would start paying 
attention.

Point 2: My concern is that the draft now recommends diffserv edge 
mechanisms that I think are inappropriate for a mapping draft. I suggest 
the conditioning rules apply to specific deployment scenarios. I also 
suggest this does not apply to all equipment - any recommendations need 
to be certain about context for deployment. I think there is quite an 
opportunity for the present text on remarking and drop in the current 
revision to be wrongly interpreted. I seriously fear the inclusion of 
remarking and drop recommendations can make this become an impediment to 
sender marking of DSCP across IP paths that happen to include 802.11 
equipment.

Point 3: The specific conditioning rules argue for pervasive remarking 
of all “unknown” codepoints - this position is a very specific view. If 
stated in a PS for 802.11 this would have serious implications on the 
usefulness of diffserv, and I think the IETF really has to consider 
these in detail before it takes this approach for 802.11.

------------

So, starting with Point 1: I noted previously that I do see real benefit 
in recommendations on how to map DSCPs using 802.11 and I suspect, if 
done correctly, this can greatly ease the consistent use of DSCP.

It may be that the security considerations need to discuss the trust of 
markings and the possible need to remark or drop to protect the AP 
resources. I can also see how CS6 and CS7 may need to be discussed and 
text may have to say things about these when the AP is forms the edge of 
a network.

TEXT:
Traffic marked CS7 DSCP
SHOULD be dropped or remarked at this edge (as it is
typically
unused, as CS7 SHOULD be reserved for future use).
- section 4.1.1. recommends drop or remark, and I struggle here to know 
that this is the correct statement to make in general for 802.11 usage. 
Is it strictly necessary to drop CS6 traffic at an AP, that seems 
plausible in managed (e.g. enterprise) deployment, or on the
upstream to an ISP in a home deployment (maybe in some places the 
operator own the AP?). Between IP networks in my house this seems like 
the wrong thing to do. It may be used by a routing protocol (e.g. RPL as 
noted) could use this DSCP, why can I not use a layer 2 technology to 
move these packets between parts of my IP network with the DSCP that has 
been assigned?

So, really I question if the current phrasing is the correct 
recommendation. I think the WG needs to choose appropriate words here 
but that needs I think to be balanced by explaining that these 
codepoints may be used within a house or whatever for routing and 
functions. - They are not just for the upstream ISP!

Point 2: As you noted, there is a wide variety of 802.11 equipment and 
uses and you highlight two distinct deployment models. 802.11 uses are 
really diverse - they include managed environments in Enterprises, 
public wifi access, home networks, use as layer infrastructure in a very 
general sense, bridging to other layer 2 infrastructure (zigbee, etc).

There now follows concerns about the new text, which largely stems from 
the above context (i.e., in a different document with a different 
purpose the comments would be different).

I am not sure this text is helpful:
" In most commonly-deployed WLAN models, the wireless access point 
represents not only the edge of the Diffserv domain, but also the edge 
of the network infrastructure itself.
As such, only client
devices (and no infrastructure devices) are downstream from the
access points in these deployment models.
"
- Again, there are many cases where this also not the same as well. I 
have a number of APs in my house, and for that matter a zigbee bridge 
that connects IoT devices. For many flows the AP is one hop to the DSL 
modem, but flows also exist between endpoints in the house - e.g. to 
deliver TV content across my home network, or to turn on/off lights or 
simply access the house computer from my laptop.

On Point 3: I think it may be wrong to recommend this:
TEXT:
"
In such deployment models,
it is RECOMMENDED that all packets marked to Diffserv Codepoints not
in use over the wireless network be dropped or remarked at the edge
of the Diffserv domain, as will be discussed in detail in
Section 4.1.1."
- I would really hope APs do not do this, except if they within the 
control network of an upstream service provider that has configured 
consistent rules at the Apps for the service they offer.

I see the next para effectively implies SHOULD NOT remark or drop, in 
some other case - but even though I suspect you are hoping for the 
correct thing I do not see this clearly enough to feel confident that 
others will always understand what to do.

- It also suggests drop and remark are equal, they are not - the there 
behaviour i) (carry as DF (ii) Remark to DF (iii) Drop have quite 
different implications to those trying to write apps that wish to use 
diffserv.
---
TEXT:
”
Thus the QoS treatment of packets at the access point will depend on
the position of the AP in the network infrastructure and on the WLAN
deployment model."
- Oh indeed, but the more I read, the more I’d really rather see how to 
handle edge treatment as a separate document that clearly explains that 
at a diffserv edge you do conditioning and what are the implications of 
the different approaches.
---
TEXT:
It is NOT RECOMMENDED to trust DSCP markings from devices that are
not authenticated and authorized; these are considered untrusted
sources.
- Question: What is the intent here? Are you encouraging DSCP remarking 
(I hope not), or are you saying that the UP marking is assigned using a 
local policy rather than from the DSCP?

- I suspect the context here is not about mapping it is about managed 
use of an AP network. That varies, and I really think this is not the 
document to discuss that. The security considerations could note this - 
but quite honestly, if you expect my light bulbs and TV sets to start 
authenticating with the AP, then I'm going to argue. Do these devices 
benefit from using DSCPs - very very likely.

- Of course, if you were offering infrastucture to a range of customers 
then you may need to consider these issues. Saying SHOULD NOT trust 
seems to suggest you threaten to remark? or just to carry as best-effort 
within this network?
(Back to point 2: We all know that public radio networks need to 
consider resource models, but this is not a PHB mapping question.)
---
TEXT:
"Alternatively, if a network device is configured to
operate in an untrusted manner, then it would remark packets as
these entered the device, typically to DF (or to a different
marking value at the network administrator's preference). Note:
The terms "trusted" and "untrusted" are used extensively in RFC
4594."
- This is NOT what I want from an out-of-the-box AP configuration, and I 
think this muddies the deployment context.
---

More on point 3: I really do not agree with the text in section 5.4:
TEXT:
5.4. Upstream DSCP Marking at the Wireless Access Point

An alternative option to mapping is for the administrator to treat
the wireless edge as the edge of the Diffserv domain and explicitly
set (or reset) DSCP markings in the upstream direction according to
administrative policy. This option is RECOMMENDED over mapping, as
this typically is the most secure solution, as the network
administrator directly enforces the Diffserv policy across the IP
network (versus an application developer and/or the wireless endpoint
device operating system developer, who may be functioning completely
independently of the network administrator).

- Comment. I see the alternative and realise that the edge of a DS 
domain can condition traffic, but it would be truly dismal if every home 
router tried to reset all the DSCPs I use.
- I strongly dislike an approach that drops packets with DSCPs ( except 
for admitted services). I think drop and even remark is a direct hurdle 
for apps to become able to use Diffserv across other network paths. If 
this is approach is taken by a wireless AP - then the network to which 
it connects is now deprived of application-chosen DSCPs. APs are used in 
many ways, e.g., as bridges to other infrastructure in IOT applications 
this recommendation would come in the way of assigning DSCPs for control 
applications in this case. It also produces a different DSCP behaviour 
when I use wifi AP to when I use a wired network segment. I therefore do 
not support this as the recommended approach, what do others think?
---
TEXT:
“it is RECOMMENDED that all packets marked to Diffserv Codepoints not
in use over the wireless network be dropped or remarked”
I strongly disagree with the following recommendation, which was 
formally in the network control section and I had not understood that 
this “all packets” actually was intended as a general recommendation to 
reset all DSCPs.

It becomes very difficult to use diffserv at all if each layer 2 network 
has different remark/drop policies. At the moment many networks neither 
remark nor drop - which I actually think is correct, they are layer 2 
devices and they have not been configured with any information about the 
Diffserv capabilities of the networks they talk to.
---
TEXT:
“Section 4.1.1 RECOMMENDED that all packets marked to Diffserv
Codepoints not in use over the wireless network be dropped or
remarked at the edge of the Diffserv domain. This recommendation
may help mitigate a Denial-of-Service attack vector that exists at
wired-to-wireless edges in the downstream direction. For example,
consider a malicious user flooding traffic marked CS7 or CS6 DSCP
toward the WLAN. These codepoints would map by default to UP 7
and UP 6 (respectively), both of which would be assigned to the
Voice Access Category (AC_VO). Such a flood could cause a Denial-
of-Service to wireless voice applications.”

I think it is useful case to describe, but I do not agree with the 
recommendation for this document.
---
TEXT:
“Section 5.3 made it clear that it is NOT RECOMMENDED to trust DSCP
markings from devices that are not authenticated and authorized,
as these are considered untrusted sources. This is especially
relevant for IoT, as billions of devices are being connected to IP
networks, many of which have little or no security.”

I share the concern here, and I think it is useful case to describe, but 
I do not agree with the recommendation for this document:
- In my home network?

I don’t agree with the current text in section 5.3, which begins:
"It is NOT RECOMMENDED to trust DSCP markings from devices that are not 
authenticated and authorized; these are considered untrusted sources."

---

I do not agree with this:
Section 5.4 RECOMMENDED that the administrator treat the wireless
edge as the edge of the Diffserv domain and explicitly set (or
reset) DSCP markings in the upstream direction according to
administrative policy.
- the discussion goes on to talk about an example with CS6 and CS7,
there may be a case for admission control to this class - or at least 
this PHB - but the general comment of requesting
rewriting of all codepoints goes against current practice as far
as I can see, and also is most unhelpful.

---
TEXT
Suffice it to say that
the security of the devices and networks implementing QoS, including
QoS mapping between wired and wireless networks, SHOULD be considered
in actual deployments.
- I agree that you must protect operator infrastructure, and all people 
who use APs need to make decisions about which traffic to admit to the 
network at a particular QoS level. That does not mean I agree with 
thinking a device need to remark all my traffic because it is not what 
you think is best to cross a wireless/wired boundary.”

-------------------

I look forward to learning more what others think on this,

best wishes,

Gorry Fairhurst





From nobody Sun May 28 12:16:10 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 8999B129461; Sun, 28 May 2017 12:16:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Secretariat 
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149599896855.2050.2270262171268221761.idtracker@ietfa.amsl.com>
Date: Sun, 28 May 2017 12:16:08 -0700
Archived-At: 
Subject: [tsvwg] The TSVWG WG has placed draft-touch-tsvwg-udp-options in state "Call For Adoption By WG Issued"
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 May 2017 19:16:08 -0000

The TSVWG WG has placed draft-touch-tsvwg-udp-options in state 
Call For Adoption By WG Issued (entered by Gorry Fairhurst)

The document is available at
https://datatracker.ietf.org/doc/draft-touch-tsvwg-udp-options/


Comment:
A working group adoption call has been run for:
draft-touch-tsvwg-udp-options-09 to end 31st May 2017


From nobody Sun May 28 12:23:34 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 CD5B1124D37 for ; Sun, 28 May 2017 12:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 5TOTbPzaf10i for ; Sun, 28 May 2017 12:23:31 -0700 (PDT)
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 EF6B81205D3 for ; Sun, 28 May 2017 12:23:30 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 0FE4F1B018A2 for ; Sun, 28 May 2017 22:17:56 +0100 (BST)
Message-ID: <592B239D.3030802@erg.abdn.ac.uk>
Date: Sun, 28 May 2017 20:23:09 +0100
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: tsvwg@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata to conclude 12th June 2017.
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 May 2017 19:23:33 -0000

This email notes the start of a WGLC for draft-ietf-tsvwg-sctp-ndata.

Please send notes to this list or the WG Chairs, if you support 
publication of this draft or have any comments on the current revision 
of this document. The intended status (if the document completes the 
WGLC) is PS.

The WGLC will conclude 12th June 2017.

Best wishes,

Gorry, David and Wes.



From nobody Sun May 28 12:25: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 71339124D37 for ; Sun, 28 May 2017 12:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level: 
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 2h1N7GLITqUO for ; Sun, 28 May 2017 12:25:10 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id EB41E1205D3 for ; Sun, 28 May 2017 12:25:09 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 2630C1B014EA for ; Sun, 28 May 2017 22:19:35 +0100 (BST)
Message-ID: <592B2400.7080407@erg.abdn.ac.uk>
Date: Sun, 28 May 2017 20:24:48 +0100
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: tsvwg@ietf.org
References: <592B239D.3030802@erg.abdn.ac.uk>
In-Reply-To: <592B239D.3030802@erg.abdn.ac.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-sctp-ndata to conclude 12th June 2017.
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 May 2017 19:25:11 -0000

On 28/05/2017, 20:23, Gorry Fairhurst wrote:
> This email notes the start of a WGLC for draft-ietf-tsvwg-sctp-ndata.
>
> Please send notes to this list or the WG Chairs, if you support 
> publication of this draft or have any comments on the current revision 
> of this document. The intended status (if the document completes the 
> WGLC) is PS.
>
> The WGLC will conclude 12th June 2017.
>
> Best wishes,
>
> Gorry, David and Wes.
>
I have the read above document during the WGLC and I would like to add 
the following comments to the WGLC for this draft.

Best wishes,

Gorry

----
OLD:
allowing to have up to
NEW:
allowing up to
- may be better English?
---
OLD:
Therefore it is impossible for the sender to
NEW:
This document allows an SCTP sender to
- The impossibility cited was the case before this document is approved. 
I think
the alternative wording avoids this.
---
OLD:
complaint implementation not supporting
NEW:
complaint implementation that does not support
---
OLD:
which has been omitted from the I-DATA chunk
NEW:
(The I-Data chunk omits a TSN.)
- Slightly confusing wording.
---
Figure 2
I understood Figure 2 perfectly when I last read it, now some time has 
passed I found it a little harder. I think this would be much easier to 
understand if the text explained that this shows a scheduler with two 
queues of messages. Queue 1 has three messages, queue 2 has one larger 
message that is interleaved by dividing ... etc and explain 0...8 etc.
---
Section 3.2, 3.3 etc contain the word “scheduler” in the title, but 
section 3.1 did not, but the text still refers to this as a scheduler, 
so please update the section 3.1 title to include the word “scheduler” 
to be consistent.
---
Section 3.3
- insert comma before /which/.
---
Section 3.6
- Speaks of bandwidth (twice), whereas I think it would be clearer to 
use the word “capacity” since this is about sharing network capacity.
---
Section 4.1
OLD:
Exposition
NEW:
Exposure
- Wrong word!
---
Section 4.1
- For avoidance of doubt, please use the title of the section in RFC6458 
with each entry, i.e., “SCTP Header Information Structure” and “Extended 
SCTP Header Information Structure” and “SCTP Receive Information Structure”.
---


From nobody Sun May 28 12:25:26 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 92609124D37 for ; Sun, 28 May 2017 12:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level: 
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, 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 uDjAfpxlm4JP for ; Sun, 28 May 2017 12:25:11 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id BFE281205D3 for ; Sun, 28 May 2017 12:25:11 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 2C7481B014EA for ; Sun, 28 May 2017 22:19:58 +0100 (BST)
Message-ID: <592B2416.9030003@erg.abdn.ac.uk>
Date: Sun, 28 May 2017 20:25:10 +0100
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: tsvwg@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to conclude 12th June 2017
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 May 2017 19:25:12 -0000

This email notes the start of a WGLC for 
draft-ietf-tsvwg-ecn-experimentation.

Please send notes to this list or the WG Chairs, if you support 
publication of this draft or have any comments on the current revision 
of this document. The intended status (if the document completes the 
WGLC) is PS.

The WGLC will conclude 12th June 2017.

Best wishes,

Gorry, David (author of this ID) and Wes.



From nobody Sun May 28 12:27: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 EE34E129466 for ; Sun, 28 May 2017 12:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 tjR8i8zusZb6 for ; Sun, 28 May 2017 12:27:09 -0700 (PDT)
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 6D280124D37 for ; Sun, 28 May 2017 12:27:09 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 93EAB1B014EA; Sun, 28 May 2017 22:21:34 +0100 (BST)
Message-ID: <592B2476.6030201@erg.abdn.ac.uk>
Date: Sun, 28 May 2017 20:26:46 +0100
From: Gorry Fairhurst 
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: gorry@erg.abdn.ac.uk
CC: tsvwg@ietf.org
References: <592B2416.9030003@erg.abdn.ac.uk>
In-Reply-To: <592B2416.9030003@erg.abdn.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [tsvwg] WGLC for draft-ietf-tsvwg-ecn-experimentation to conclude 12th June 2017
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 May 2017 19:27:11 -0000

On 28/05/2017, 20:25, Gorry Fairhurst wrote:
> This email notes the start of a WGLC for 
> draft-ietf-tsvwg-ecn-experimentation.
>
> Please send notes to this list or the WG Chairs, if you support 
> publication of this draft or have any comments on the current revision 
> of this document. The intended status (if the document completes the 
> WGLC) is PS.
>
> The WGLC will conclude 12th June 2017.
>
> Best wishes,
>
> Gorry, David (author of this ID) and Wes.
>
I have the following comments during the WGLC for the above document:

---
OLD:
it would drop Not-ECT packets .
NEW:
it would drop Not-ECT packets.
- remove space before full stop.
---
Please update the names of all drafts when revising this draft.
---

Best wishes,

Gorry


From nobody Mon May 29 02:57: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 BB965126CC7 for ; Mon, 29 May 2017 02:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.101
X-Spam-Level: 
X-Spam-Status: No, score=-7.101 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PgRNkGvXEHG for ; Mon, 29 May 2017 02:57:28 -0700 (PDT)
Received: from mailout23.telekom.de (MAILOUT23.telekom.de [80.149.113.253]) (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 90BFE124BFA for ; Mon, 29 May 2017 02:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1496051847; x=1527587847; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Zke5l10ENHmu0XYO0DWPeNmB5C5I+Ex8HCXN+N6yhuE=; b=NUB5+jkTN7z7U15YXIMtyyAFH1PAPvbRRd84RSuQiGO0VzSnC+MEEAM4 sFYygGsavaF3c08ErkrH5r2q8sh6gwib/nBQ0Yp9n6Ffg9yneyNKUyzDE 4yvu8JB7dEIPET1ANYC/H59lzOhuHG40L+YdaC1E4sCLZzxGQjFRtpxMd 62aweE+pCrNeQPaKsPSToyKhcYm/Fjk9ugAzMg5VG69YA6zs7OpvRPplm kj82a8d3Jte7tcuO0ACggnBE5qcuYq3i4oZkHEJDpTVp/QSZk5e7nhVMt 1p+DVzZ2uZRFxE5WgXOtOo4BxiFF8RMHv4hxy0LJJ51FzH7cn4GFGkM+F g==;
Received: from q4de8psa169.blf.telekom.de ([10.151.13.200]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2017 11:57:17 +0200
X-IronPort-AV: E=Sophos;i="5.38,413,1491256800"; d="scan'208";a="1330361800"
Received: from he101659.emea1.cds.t-internal.com ([10.134.226.19]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2017 11:57:17 +0200
Received: from HE101653.emea1.cds.t-internal.com (10.134.226.13) by HE101659.emea1.cds.t-internal.com (10.134.226.19) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 29 May 2017 11:57:17 +0200
Received: from HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c]) by HE101653.emea1.cds.t-internal.com ([fe80::8954:80af:2020:572c%27]) with mapi id 15.00.1263.000; Mon, 29 May 2017 11:57:16 +0200
From: 
To: 
CC: , , 
Thread-Topic: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules
Thread-Index: AQHS19ndA9nRN9ENAk2sUdkqCSvAFqILDLSw
Date: Mon, 29 May 2017 09:57:16 +0000
Message-ID: 
References: <5923F086.8030804@erg.abdn.ac.uk>   <5d3c37a54bfb4cfab699613e34b32a5f@XCH-RCD-010.cisco.com> <592A83D6.6080501@erg.abdn.ac.uk> <592B0BF4.2030204@erg.abdn.ac.uk>
In-Reply-To: <592B0BF4.2030204@erg.abdn.ac.uk>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.157.166.173]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 May 2017 09:57:31 -0000

Hi Gorry,

you suggest to limit the scope of draft-ietf-tsvwg-ieee-802-11 to specify a=
 default Diffserv mapping behavior for a commodity piece of Hardware. Any I=
P related policies to be deployed if that piece of Hardware is used in a sp=
ecific deployment should be separated and become part of a document in its =
own.=20

I'm not a Wifi expert, but to me there's a point in your proposal.

Regards,

Ruediger

PS: I also thought about comparing the separation of mapping and policy to =
Diffserv-Intercon, which covers both. There we had some policy related disc=
ussions, about bleaching, for example. The latter is scoped for a specific =
deployment however.


-----Urspr=FCngliche Nachricht-----
Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Gorry Fairhurst
Gesendet: Sonntag, 28. Mai 2017 19:42
An: tsvwg@ietf.org
Cc: gorry@erg.abdn.ac.uk; Jerome Henry (jerhenry); fredbakersba@gmail.com
Betreff: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on c=
onditioning rules

This email describes a number of concerns with the inclusion of conditionin=
g rules in the 802-11 draft.

The title and abstract of the draft describe a mapping function.=20
However, the changes in rev -02 give me serious doubts about the remarking =
and drop recommendations, which I consider for a diffserv edge.

Point 1: I think the WG need to be very clear about the context of recommen=
dations. I'd expect the class mappings to PHBs to be applied in all equipme=
nt that adheres to IETF standards. This should I think be the default for a=
ll APs - and I'd hope most vendors would start paying attention.

Point 2: My concern is that the draft now recommends diffserv edge mechanis=
ms that I think are inappropriate for a mapping draft. I suggest the condit=
ioning rules apply to specific deployment scenarios. I also suggest this do=
es not apply to all equipment - any recommendations need to be certain abou=
t context for deployment. I think there is quite an opportunity for the pre=
sent text on remarking and drop in the current revision to be wrongly inter=
preted. I seriously fear the inclusion of remarking and drop recommendation=
s can make this become an impediment to sender marking of DSCP across IP pa=
ths that happen to include 802.11 equipment.

Point 3: The specific conditioning rules argue for pervasive remarking of a=
ll "unknown" codepoints - this position is a very specific view. If stated =
in a PS for 802.11 this would have serious implications on the usefulness o=
f diffserv, and I think the IETF really has to consider these in detail bef=
ore it takes this approach for 802.11.

------------

So, starting with Point 1: I noted previously that I do see real benefit in=
 recommendations on how to map DSCPs using 802.11 and I suspect, if done co=
rrectly, this can greatly ease the consistent use of DSCP.

It may be that the security considerations need to discuss the trust of mar=
kings and the possible need to remark or drop to protect the AP resources. =
I can also see how CS6 and CS7 may need to be discussed and text may have t=
o say things about these when the AP is forms the edge of a network.

TEXT:
Traffic marked CS7 DSCP
SHOULD be dropped or remarked at this edge (as it is typically unused, as C=
S7 SHOULD be reserved for future use).
- section 4.1.1. recommends drop or remark, and I struggle here to know tha=
t this is the correct statement to make in general for 802.11 usage.=20
Is it strictly necessary to drop CS6 traffic at an AP, that seems plausible=
 in managed (e.g. enterprise) deployment, or on the upstream to an ISP in a=
 home deployment (maybe in some places the operator own the AP?). Between I=
P networks in my house this seems like the wrong thing to do. It may be use=
d by a routing protocol (e.g. RPL as
noted) could use this DSCP, why can I not use a layer 2 technology to move =
these packets between parts of my IP network with the DSCP that has been as=
signed?

So, really I question if the current phrasing is the correct recommendation=
. I think the WG needs to choose appropriate words here but that needs I th=
ink to be balanced by explaining that these codepoints may be used within a=
 house or whatever for routing and functions. - They are not just for the u=
pstream ISP!

Point 2: As you noted, there is a wide variety of 802.11 equipment and uses=
 and you highlight two distinct deployment models. 802.11 uses are really d=
iverse - they include managed environments in Enterprises, public wifi acce=
ss, home networks, use as layer infrastructure in a very general sense, bri=
dging to other layer 2 infrastructure (zigbee, etc).

There now follows concerns about the new text, which largely stems from the=
 above context (i.e., in a different document with a different purpose the =
comments would be different).

I am not sure this text is helpful:
" In most commonly-deployed WLAN models, the wireless access point represen=
ts not only the edge of the Diffserv domain, but also the edge of the netwo=
rk infrastructure itself.
As such, only client
devices (and no infrastructure devices) are downstream from the access poin=
ts in these deployment models.
"
- Again, there are many cases where this also not the same as well. I have =
a number of APs in my house, and for that matter a zigbee bridge that conne=
cts IoT devices. For many flows the AP is one hop to the DSL modem, but flo=
ws also exist between endpoints in the house - e.g. to deliver TV content a=
cross my home network, or to turn on/off lights or simply access the house =
computer from my laptop.

On Point 3: I think it may be wrong to recommend this:
TEXT:
"
In such deployment models,
it is RECOMMENDED that all packets marked to Diffserv Codepoints not in use=
 over the wireless network be dropped or remarked at the edge of the Diffse=
rv domain, as will be discussed in detail in Section 4.1.1."
- I would really hope APs do not do this, except if they within the control=
 network of an upstream service provider that has configured consistent rul=
es at the Apps for the service they offer.

I see the next para effectively implies SHOULD NOT remark or drop, in some =
other case - but even though I suspect you are hoping for the correct thing=
 I do not see this clearly enough to feel confident that others will always=
 understand what to do.

- It also suggests drop and remark are equal, they are not - the there beha=
viour i) (carry as DF (ii) Remark to DF (iii) Drop have quite different imp=
lications to those trying to write apps that wish to use diffserv.
---
TEXT:
"
Thus the QoS treatment of packets at the access point will depend on the po=
sition of the AP in the network infrastructure and on the WLAN deployment m=
odel."
- Oh indeed, but the more I read, the more I'd really rather see how to han=
dle edge treatment as a separate document that clearly explains that at a d=
iffserv edge you do conditioning and what are the implications of the diffe=
rent approaches.
---
TEXT:
It is NOT RECOMMENDED to trust DSCP markings from devices that are not auth=
enticated and authorized; these are considered untrusted sources.
- Question: What is the intent here? Are you encouraging DSCP remarking (I =
hope not), or are you saying that the UP marking is assigned using a local =
policy rather than from the DSCP?

- I suspect the context here is not about mapping it is about managed use o=
f an AP network. That varies, and I really think this is not the document t=
o discuss that. The security considerations could note this - but quite hon=
estly, if you expect my light bulbs and TV sets to start authenticating wit=
h the AP, then I'm going to argue. Do these devices benefit from using DSCP=
s - very very likely.

- Of course, if you were offering infrastucture to a range of customers the=
n you may need to consider these issues. Saying SHOULD NOT trust seems to s=
uggest you threaten to remark? or just to carry as best-effort within this =
network?
(Back to point 2: We all know that public radio networks need to consider r=
esource models, but this is not a PHB mapping question.)
---
TEXT:
"Alternatively, if a network device is configured to operate in an untruste=
d manner, then it would remark packets as these entered the device, typical=
ly to DF (or to a different marking value at the network administrator's pr=
eference). Note:
The terms "trusted" and "untrusted" are used extensively in RFC 4594."
- This is NOT what I want from an out-of-the-box AP configuration, and I th=
ink this muddies the deployment context.
---

More on point 3: I really do not agree with the text in section 5.4:
TEXT:
5.4. Upstream DSCP Marking at the Wireless Access Point

An alternative option to mapping is for the administrator to treat the wire=
less edge as the edge of the Diffserv domain and explicitly set (or reset) =
DSCP markings in the upstream direction according to administrative policy.=
 This option is RECOMMENDED over mapping, as this typically is the most sec=
ure solution, as the network administrator directly enforces the Diffserv p=
olicy across the IP network (versus an application developer and/or the wir=
eless endpoint device operating system developer, who may be functioning co=
mpletely independently of the network administrator).

- Comment. I see the alternative and realise that the edge of a DS domain c=
an condition traffic, but it would be truly dismal if every home router tri=
ed to reset all the DSCPs I use.
- I strongly dislike an approach that drops packets with DSCPs ( except for=
 admitted services). I think drop and even remark is a direct hurdle for ap=
ps to become able to use Diffserv across other network paths. If this is ap=
proach is taken by a wireless AP - then the network to which it connects is=
 now deprived of application-chosen DSCPs. APs are used in many ways, e.g.,=
 as bridges to other infrastructure in IOT applications this recommendation=
 would come in the way of assigning DSCPs for control applications in this =
case. It also produces a different DSCP behaviour when I use wifi AP to whe=
n I use a wired network segment. I therefore do not support this as the rec=
ommended approach, what do others think?
---
TEXT:
"it is RECOMMENDED that all packets marked to Diffserv Codepoints not in us=
e over the wireless network be dropped or remarked"
I strongly disagree with the following recommendation, which was formally i=
n the network control section and I had not understood that this "all packe=
ts" actually was intended as a general recommendation to reset all DSCPs.

It becomes very difficult to use diffserv at all if each layer 2 network ha=
s different remark/drop policies. At the moment many networks neither remar=
k nor drop - which I actually think is correct, they are layer 2 devices an=
d they have not been configured with any information about the Diffserv cap=
abilities of the networks they talk to.
---
TEXT:
"Section 4.1.1 RECOMMENDED that all packets marked to Diffserv Codepoints n=
ot in use over the wireless network be dropped or remarked at the edge of t=
he Diffserv domain. This recommendation may help mitigate a Denial-of-Servi=
ce attack vector that exists at wired-to-wireless edges in the downstream d=
irection. For example, consider a malicious user flooding traffic marked CS=
7 or CS6 DSCP toward the WLAN. These codepoints would map by default to UP =
7 and UP 6 (respectively), both of which would be assigned to the Voice Acc=
ess Category (AC_VO). Such a flood could cause a Denial- of-Service to wire=
less voice applications."

I think it is useful case to describe, but I do not agree with the recommen=
dation for this document.
---
TEXT:
"Section 5.3 made it clear that it is NOT RECOMMENDED to trust DSCP marking=
s from devices that are not authenticated and authorized, as these are cons=
idered untrusted sources. This is especially relevant for IoT, as billions =
of devices are being connected to IP networks, many of which have little or=
 no security."

I share the concern here, and I think it is useful case to describe, but I =
do not agree with the recommendation for this document:
- In my home network?

I don't agree with the current text in section 5.3, which begins:
"It is NOT RECOMMENDED to trust DSCP markings from devices that are not aut=
henticated and authorized; these are considered untrusted sources."

---

I do not agree with this:
Section 5.4 RECOMMENDED that the administrator treat the wireless edge as t=
he edge of the Diffserv domain and explicitly set (or
reset) DSCP markings in the upstream direction according to administrative =
policy.
- the discussion goes on to talk about an example with CS6 and CS7, there m=
ay be a case for admission control to this class - or at least this PHB - b=
ut the general comment of requesting rewriting of all codepoints goes again=
st current practice as far as I can see, and also is most unhelpful.

---
TEXT
Suffice it to say that
the security of the devices and networks implementing QoS, including QoS ma=
pping between wired and wireless networks, SHOULD be considered in actual d=
eployments.
- I agree that you must protect operator infrastructure, and all people who=
 use APs need to make decisions about which traffic to admit to the network=
 at a particular QoS level. That does not mean I agree with thinking a devi=
ce need to remark all my traffic because it is not what you think is best t=
o cross a wireless/wired boundary."

-------------------

I look forward to learning more what others think on this,

best wishes,

Gorry Fairhurst





From nobody Tue May 30 12:09: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 EE57912953F for ; Tue, 30 May 2017 12:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTRf5k1tLLYl for ; Tue, 30 May 2017 12:09:53 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 443A4129434 for ; Tue, 30 May 2017 12:09:53 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id h4so123675426oib.3 for ; Tue, 30 May 2017 12:09:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J2MlY8EQUhSX+ofy3FgCunivYUpq/MynZpsIE48FilQ=; b=TVjA+2M3vK3ek7j5H+6KQXKbJDzdsB2PX6TvbVlaJofKGUZoLugtF3WSZG9T896i1Q AZjidWYhPZaa6Kr62ugHb4o96OUII5k2jklhlG1NqjvgLdNLAUYTNAHgDJb4DFmwAmPg g9FKtRwj1fgmgKL+T/U734hh+aCmSn9uRViA6WFkzVxGTWX4IUaJaAlqJHqI1ryH9Rkt BiEMekPuWJa1Tcyg0+W2w6vgCWiDNBIHWIumjTg481gjhSZS1POnKaFKady+Vx/vchna IKSbBE/y4QdvBPCOen2oXzkfPqdQb5OHfkECl8QSEv+vgXSSGkQAWyBYIOq5o4qTEQ3b /n0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J2MlY8EQUhSX+ofy3FgCunivYUpq/MynZpsIE48FilQ=; b=NNV/qd78FDVP7+H5hm3xAbF+prw37O2pP76jXpRL4tQlgthpUO1/NyoeVn4Iqyw1we zBzl+VwoMTbVCU914gx7K77Tj8++ZC57yoVmGR4RH90agnhMW7cBW6GJD97tmmQ8HZ/s hbL9k4TTymCUytdClStmACsAFWW6xyBME2CAv62nSgLox4doEVkK7fawDTI/ZGIsByIO bLqRXtIF5m/74kuVW3yY8Bj2Bkf5vdJg/VLez6n/fyi/pE6+S/z2+LzwTMnlPltYS1Z8 Pq9UJz0fA/0uBjxhzBZRsGvdi06CNXjehQXa4SmiWiKki9jyUVYxnb6UzKPPTQoZdrPd fKgA==
X-Gm-Message-State: AODbwcDQKmBW0pwxMsXW4OtQXxc4mpSZl5RjwQcRrfw6ZD8VjDBpMyto ACgjqdVVfJtc3zVzkFY=
X-Received: by 10.202.69.6 with SMTP id s6mr10140897oia.193.1496171392668; Tue, 30 May 2017 12:09:52 -0700 (PDT)
Received: from ?IPv6:2600:8802:5600:1da::1007? ([2600:8802:5600:1da::1007]) by smtp.gmail.com with ESMTPSA id w197sm6179308oie.8.2017.05.30.12.09.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 12:09:52 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Fred Baker 
In-Reply-To: <5d3c37a54bfb4cfab699613e34b32a5f@XCH-RCD-010.cisco.com>
Date: Tue, 30 May 2017 12:09:50 -0700
Cc: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "Jerome Henry (jerhenry)" 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5923F086.8030804@erg.abdn.ac.uk>   <5d3c37a54bfb4cfab699613e34b32a5f@XCH-RCD-010.cisco.com>
To: "Tim Szigeti (szigeti)" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 19:09:55 -0000

I'm now back from vacation.

Here's where our views seem to diverge. You argue that you are basing =
the comment about dropping CS6 on RFC 4594. What RFC 4594 says, however, =
is:

   o  Drop or remark CS7 packets at ingress to DiffServ network domain.
   o  CS7 marked packets SHOULD NOT be sent across peering points.
      Exchange of control information across peering points SHOULD be
      done using CS6 DSCP and the Network Control service class.

It doesn't say to drop CS6, and the argument for dropping CS6 is that =
routing traffic is not exchanged on WiFi networks (which is the =
assumption I commented on). That is true today, but may not be true in =
the future. I think the assumption that routing traffic will never be =
exchanged on WiFi networks is a dangerous assumption long term.=20

> On May 24, 2017, at 6:43 PM, Tim Szigeti (szigeti)  =
wrote:
>=20
> Hi Fred,
>=20
>> For CS7 (and any DSCP value not implemented in the domain) I would =
agree
>> that it should be remarked or dropped. For CS6, recall that I have =
pointed out
>> the assumptions that WiFi is the edge of the diffusers domain and has =
no IP
>> layer routing across it. I think, and have said before that I think, =
that is a
>> limiting assumption.
>=20
> Nothing is being assumed here Fred. Two distinct recommendations are =
being made:
>=20
> In the case where the wireless access-point represents the edge of the =
network (and thus simultaneously the edge of the Diffserv domain), then =
a recommendation is being made to remark or drop packets marked CS6 or =
CS7 (as there are no downstream devices participating in network control =
exchanges, and preserving these markings presents an easy attack-vector =
for WLAN DoS).
>=20
> In the deployment model where the wireless access-point is NOT the =
edge of the network, then this recommendation does not apply (as brought =
out in Section 4.1.1).
>=20
> A single recommendation simply will not ensure secure and consistent =
QoS treatment in both wireless deployment models.
>=20
> -tim
>=20
>=20
>> -----Original Message-----
>> From: fredbakersba@gmail.com [mailto:fredbakersba@gmail.com]
>> Sent: Wednesday, May 24, 2017 2:28 PM
>> To: Tim Szigeti (szigeti)
>> Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; Jerome Henry (jerhenry)
>> Subject: Re: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
>>=20
>> .The top-level observation (I'll follow-up with another email if =
needed about
>>>> specific text) is that the latest revision discusses the way in =
which
>>>> access points and wireless devices can change the DSCP marking or
>>>> drop traffic because of the DSCP marking.
>>>>=20
>>>=20
>>> I'd like to first stress the point that the remarking and dropping
>> recommendations of network control traffic (marked CS6/CS7) at the =
edge of
>> the wired-to-wireless network (as made in Section 4.1.1) were part of =
the
>> original 2015 draft, and are not new recommendations in this latest =
revision.
>>>=20
>>> Additionally, these recommendations are drawn from similar
>> recommendations made in RFC 4594-Section 3.2 which:
>>>=20
>>> "RECOMMENDED that packets marked CS7
>>>  DSCP (a codepoint that SHOULD be reserved for future use) be =
dropped
>>>  or remarked at the edge of the Diffserv domain."
>>>=20
>>> Our argument is that when the wireless access point represents the
>>> edge of the network infrastructure (and thus the edge of the =
Diffserv
>>> domain), this recommendation should hold;
>>=20
>> For CS7 (and any DSCP value not implemented in the domain) I would =
agree
>> that it should be remarked or dropped. For CS6, recall that I have =
pointed out
>> the assumptions that WiFi is the edge of the diffusers domain and has =
no IP
>> layer routing across it. I think, and have said before that I think, =
that is a
>> limiting assumption.


From nobody Tue May 30 14:36:38 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 3CEBE124D37; Tue, 30 May 2017 14:36:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: tsvwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.52.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149618019712.19809.8831064655964793058@ietfa.amsl.com>
Date: Tue, 30 May 2017 14:36:37 -0700
Archived-At: 
Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rfc6040update-shim-01.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 21:36:37 -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           : Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
        Author          : Bob Briscoe
	Filename        : draft-ietf-tsvwg-rfc6040update-shim-01.txt
	Pages           : 10
	Date            : 2017-05-30

Abstract:
   RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
   rules for propagation of ECN consistent for all forms of IP in IP
   tunnel.  This specification extends the scope of RFC 6040 to include
   tunnels where two IP headers are separated by at least one shim
   header that is not sufficient on its own for packet forwarding.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-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 Tue May 30 14:49: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 BC5B7127F0E for ; Tue, 30 May 2017 14:49:17 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAbmCyCVFc4T for ; Tue, 30 May 2017 14:49:15 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 3939F127869 for ; Tue, 30 May 2017 14:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ducsuIt7KWQNciTuEJcQFe/84jy32sr51ViJmUZPO+g=; b=fksX1PVxuGHdBJHRgl4ShAvuRQ r0kOymLaXa4UYcBiv3GB57LfVXNeW2Pk2wiToQ7friHj5jKIxVmzknyllEmx9QiHUtPIXW3zPjPII kzrJL/OUkhYnnx7SQIe7XH9JJVR+8s8otjAK7EzrE16d9sHZc5GsD+RpWkzwEU0eg5R7jTc3MKQyP NI8y/sdW7qzuyzX78yKTSq/M8dgcrgT8cxHPgAg2nrPb7IHEuhSqC9gq593Z/ZjFwfeyG5emo2Deu 4axIfAnAKA8XbV7ebcX/ffREYsAmXzrMxf4iOPmC1fzcX6WEs031ywJ87sCLRluGTIqsxQaEVcNaL 8FkVySIg==;
Received: from 197.74.9.51.dyn.plus.net ([51.9.74.197]:58204 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dFp0r-0007Ww-3Q; Tue, 30 May 2017 22:49:13 +0100
To: "Black, David" , tsvwg IETF list 
References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com>
From: Bob Briscoe 
Message-ID: <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net>
Date: Tue, 30 May 2017 22:49:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: [tsvwg] New Version: draft-ietf-tsvwg-rfc6040update-shim-01
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 21:49:18 -0000

David (as doc shepherd) and the tsvwg list,

As requested, I have added specific text that updates the other relevant 
RFCs under IETF change control (GRE and L2TP). I have also explained the 
position in each case for specs not under IETF change control.

I will now go to the relevant WGs (intarea and lt2pext) and ask them to 
improve my first attempt.

I'll cc you and this list as appropriate.

Cheers



Bob

PS. I have also said

    the rules in [RFC6040] for
    propagating the ECN field MUST be applied

whereas before it said "SHOULD". And added an explanation for why "MUST" 
is appropriate:

    The above is written as a 'MUST' because RFC 6040 allows
    a compatibility mode for the encapsulator in cases where the
    decapsulator does not (or cannot) support ECN propagation.






On 30/05/17 22:36, internet-drafts@ietf.org wrote:
> A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-01.txt
> has been successfully submitted by Bob Briscoe and posted to the
> IETF repository.
>
> Name:		draft-ietf-tsvwg-rfc6040update-shim
> Revision:	01
> Title:		Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim
> Document date:	2017-05-30
> Group:		tsvwg
> Pages:		10
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01
>
> Abstract:
>     RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
>     rules for propagation of ECN consistent for all forms of IP in IP
>     tunnel.  This specification extends the scope of RFC 6040 to include
>     tunnels where two IP headers are separated by at least one shim
>     header that is not sufficient on its own for packet forwarding.
>
>                                                                                    
>
>
> 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
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Tue May 30 16:08: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 7DDD4129490; Tue, 30 May 2017 16:08:17 -0700 (PDT)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vi0YmVAQB-Q; Tue, 30 May 2017 16:08:16 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 6CBA1124281; Tue, 30 May 2017 16:08:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Cc:References:To:From:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HeXbdWiJiqYBfI5Q2NOxuZzQOzJfrBHivF4DVS3mHkM=; b=R7Pdxu6ZZAeoF2gWC9iZqrD1On fdWolo7RSOALqGCM3VBxqdUGuQmPXnUHok0akjsxqY5qKIJ8V1027JgmCW8G9IUG85U812DssAxoM /RkARnUOvfQ8vcxrHeufhoBVMrOrwbXtSHuindQQpvhm6ENwVSGamTxNaQJBaLWSwXq5+c03kXWOo gglZ6rVYTMTn9uZFuP5UwyzGM8K6uIGuljpEArye+yxX1YTKiKXAXGdyD2A3RYYyCCBP4vd5V1Rbf j2kgmxx9Y0hi6G8jShhee7U1YAhXBlqdNqgvlepbxAMrCHi+NIPhIfUaO6WBPs+Pq5XAzYKISckT5 lDyvBM2A==;
Received: from 197.74.9.51.dyn.plus.net ([51.9.74.197]:58396 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dFqFJ-0004OK-Ro; Wed, 31 May 2017 00:08:14 +0100
From: Bob Briscoe 
To: intarea IETF list 
References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com> <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net>
Cc: "Black, David" , tsvwg IETF list 
Message-ID: <7850b9ae-7696-8f68-92fc-fd53c7529112@bobbriscoe.net>
Date: Wed, 31 May 2017 00:08:13 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: [tsvwg] Intarea review needed: short draft on ECN propagation IP-shim(s)-IP
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 23:08:17 -0000

Intarea list,

I presented this short draft just under a year ago in intarea. Since 
then it has been adopted as a tsvwg work item.

I have just added specific text to update those tunnel specs that are 
under IETF change control (L2TP and GRE), as well as addressing non-IETF 
specs too (VXLAN, GTP, NVGRE etc).

I would appreciate review from someone in intarea who knows these specs 
better than I do.

If you know L2TP well, pls check the l2tpext list, where I have just 
posted three L2TP-specific question.


Cheers


Bob


On 30/05/17 22:49, Bob Briscoe wrote:
> David (as doc shepherd) and the tsvwg list,
>
> As requested, I have added specific text that updates the other 
> relevant RFCs under IETF change control (GRE and L2TP). I have also 
> explained the position in each case for specs not under IETF change 
> control.
>
> I will now go to the relevant WGs (intarea and lt2pext) and ask them 
> to improve my first attempt.
>
> I'll cc you and this list as appropriate.
>
> Cheers
>
>
>
> Bob
>
> PS. I have also said
>
>    the rules in [RFC6040] for
>    propagating the ECN field MUST be applied
>
> whereas before it said "SHOULD". And added an explanation for why 
> "MUST" is appropriate:
>
>    The above is written as a 'MUST' because RFC 6040 allows
>    a compatibility mode for the encapsulator in cases where the
>    decapsulator does not (or cannot) support ECN propagation.
>
>
>
>
>
>
> On 30/05/17 22:36, internet-drafts@ietf.org wrote:
>> A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-01.txt
>> has been successfully submitted by Bob Briscoe and posted to the
>> IETF repository.
>>
>> Name:        draft-ietf-tsvwg-rfc6040update-shim
>> Revision:    01
>> Title:        Propagating Explicit Congestion Notification Across IP 
>> Tunnel Headers Separated by a Shim
>> Document date:    2017-05-30
>> Group:        tsvwg
>> Pages:        10
>> URL: 
>> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>> Htmlized: 
>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01
>> Diff: 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01
>>
>> Abstract:
>>     RFC 6040 on "Tunnelling of Explicit Congestion Notification" made 
>> the
>>     rules for propagation of ECN consistent for all forms of IP in IP
>>     tunnel.  This specification extends the scope of RFC 6040 to include
>>     tunnels where two IP headers are separated by at least one shim
>>     header that is not sufficient on its own for packet forwarding.
>>
>>
>>
>> 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
>>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Tue May 30 16:51:40 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 7D820129A90 for ; Tue, 30 May 2017 16:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 8wQJvkTxnFlc for ; Tue, 30 May 2017 16:51:30 -0700 (PDT)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05FA31205D3 for ; Tue, 30 May 2017 16:51:30 -0700 (PDT)
Received: by mail-wr0-x22c.google.com with SMTP id g76so121094wrd.1 for ; Tue, 30 May 2017 16:51:29 -0700 (PDT)
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=cAF7GlAMc9sK/0xG2yzawn+5ZylQjPVMz3CmG8ZriA4=; b=tcTTU5BS6PV1hjUTHwuPbIrnoKQguS6srU1I5jxiFotSLXce0+JoGVnnPNSGDBlgof SVc6o0aBUMQJLb66IlQSoX+72mSvIMrD2dDl2heuN396lVCQA4BQIdvYUZfzJriWxRW2 90m+RszQsAnXdmrbJv91AraZ83PPMIXQpsdgyBsVd2rYvpIw5Dp5I6LjDrlA4rFSrNoh DH0bCjubkk/TpaGy6s9z8vbQws96vKFWv2bWR9+/oQVUWq0l5R3/iE38g7wH8z8budB3 hQrTNF/tIFsvJ579RxhY3BQEIqgfR+BLCoJw8K/GZY3KHJwEVuC+OOIS2hJcR28k1wOR Qgow==
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=cAF7GlAMc9sK/0xG2yzawn+5ZylQjPVMz3CmG8ZriA4=; b=OW0FN3BWzrFEeWTENv8ZjgWTEK4SVEudBmzUCcuxnTDWV+kTXhApzh+0jpT+1I81pw L20JzCG70qeZE3IKw9Iu9fQHox9/rtTku5PlUp3rZwSQvNcRrS4eT60GWc1mbPeeHjL+ hbxqglkJ14ZjpLMyALu2zVYCYMyprMAMKZu0vvBvWBYljjLE//O2lRBa436aViN3mGmJ L7k9+j63HttQbraouGcBzrPcnMRT1hS6DhzR1gF1XwIAsnex9sRjL7hbFTBZUmOy/GIt X2bBmn1dekNlNTPborpWkyaERhcu0sIboQDiVIbEA92jFkXW90AQs8Mch+CbBGbxvlva a3Tg==
X-Gm-Message-State: AODbwcC4uSweYqOeJ2ZWnr5zWUzBHCjeScI9z4XNyxzeWZBz7g6C2ecW FwnWMZ9qMa3axHWZvQzxDhr67N3zmG2i
X-Received: by 10.223.128.80 with SMTP id 74mr19448668wrk.30.1496188288527; Tue, 30 May 2017 16:51:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.132.195 with HTTP; Tue, 30 May 2017 16:51:28 -0700 (PDT)
In-Reply-To: <7850b9ae-7696-8f68-92fc-fd53c7529112@bobbriscoe.net>
References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com> <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net> <7850b9ae-7696-8f68-92fc-fd53c7529112@bobbriscoe.net>
From: Tom Herbert 
Date: Tue, 30 May 2017 16:51:28 -0700
Message-ID: 
To: Bob Briscoe 
Cc: intarea IETF list , "Black, David" , tsvwg IETF list 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [tsvwg] [Int-area] Intarea review needed: short draft on ECN propagation IP-shim(s)-IP
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 23:51:33 -0000

On Tue, May 30, 2017 at 4:08 PM, Bob Briscoe  wrote:
> Intarea list,
>
> I presented this short draft just under a year ago in intarea. Since then it
> has been adopted as a tsvwg work item.
>
> I have just added specific text to update those tunnel specs that are under
> IETF change control (L2TP and GRE), as well as addressing non-IETF specs too
> (VXLAN, GTP, NVGRE etc).
>
Hi Bob,

On comment. GRE allows encapsulation of layer 2 (e.g. Ethernet, MPLS,
etc.) and VXLAN only does encapsulation of Ethernet. I don't think
these layer 2 headers could be considered shim headers per the draft,
they are not removed in with the encapsulation headers and are
routable in the layer 2 network. However, the layer 2 packet may
contain an IP packet and in at least once case (VXLAN) there is a
recommendation to apply RFC6040 to an inner IP header.

Maybe the requirements for this scenario should be clarified? I think
it's probably reasonable to say that ECN SHOULD be propagated in this
case.

Tom

> I would appreciate review from someone in intarea who knows these specs
> better than I do.
>
> If you know L2TP well, pls check the l2tpext list, where I have just posted
> three L2TP-specific question.
>
>
> Cheers
>
>
> Bob
>
>
> On 30/05/17 22:49, Bob Briscoe wrote:
>>
>> David (as doc shepherd) and the tsvwg list,
>>
>> As requested, I have added specific text that updates the other relevant
>> RFCs under IETF change control (GRE and L2TP). I have also explained the
>> position in each case for specs not under IETF change control.
>>
>> I will now go to the relevant WGs (intarea and lt2pext) and ask them to
>> improve my first attempt.
>>
>> I'll cc you and this list as appropriate.
>>
>> Cheers
>>
>>
>>
>> Bob
>>
>> PS. I have also said
>>
>>    the rules in [RFC6040] for
>>    propagating the ECN field MUST be applied
>>
>> whereas before it said "SHOULD". And added an explanation for why "MUST"
>> is appropriate:
>>
>>    The above is written as a 'MUST' because RFC 6040 allows
>>    a compatibility mode for the encapsulator in cases where the
>>    decapsulator does not (or cannot) support ECN propagation.
>>
>>
>>
>>
>>
>>
>> On 30/05/17 22:36, internet-drafts@ietf.org wrote:
>>>
>>> A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-01.txt
>>> has been successfully submitted by Bob Briscoe and posted to the
>>> IETF repository.
>>>
>>> Name:        draft-ietf-tsvwg-rfc6040update-shim
>>> Revision:    01
>>> Title:        Propagating Explicit Congestion Notification Across IP
>>> Tunnel Headers Separated by a Shim
>>> Document date:    2017-05-30
>>> Group:        tsvwg
>>> Pages:        10
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01
>>> Htmlized:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01
>>>
>>> Abstract:
>>>     RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
>>>     rules for propagation of ECN consistent for all forms of IP in IP
>>>     tunnel.  This specification extends the scope of RFC 6040 to include
>>>     tunnels where two IP headers are separated by at least one shim
>>>     header that is not sufficient on its own for packet forwarding.
>>>
>>>
>>>
>>> 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
>>>
>>
>
> --
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area


From nobody Tue May 30 18:45:42 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 8EF9C126C2F; Tue, 30 May 2017 18:45:40 -0700 (PDT)
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, 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=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9voNmnD1nOW; Tue, 30 May 2017 18:45:37 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 4C112129B36; Tue, 30 May 2017 18:45:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qIIOoEmEcLNHd6ZavkOg/XRHMnX7ByJAiRS2Zzwf/c0=; b=Ot8BBm3cBQofziM+EtPmRMRLtc /D+YVvT7C1x9PtfV5pXRc7gQReZk9bTvEtznV/XBhcMoEUFKLsS2DVaCAlmdOLx5+atczRWeYRgVY sCkS+0eCkd2Yi2mCMSEHIFWLE0fd2IRPxS8wn1J7IJQD+ZxXwxnPL32L/voga8uAm7gbXuFltSVjl 1iSuDtQLNy766vXL0FzDTpebtWGrZUGLTWl+chgefa43VDIfHgLU1Rmllgz9rnBLETRya9Bq1FO+y WnsQlnN+qDj89Onl1TWbnG5MgK+zSvf8KluwiBtRfDIkeSZnC7urHQg0WRV5ULLklNkLoMnW+FNbH wtXXPWlg==;
Received: from [31.185.135.175] (port=59888 helo=[192.168.0.2]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1dFshb-0005r7-DV; Wed, 31 May 2017 02:45:35 +0100
To: Tom Herbert 
Cc: intarea IETF list , "Black, David" , tsvwg IETF list 
References: <149618019740.19809.6421141487388928973.idtracker@ietfa.amsl.com> <435f45b8-9659-b06f-9adc-415f355ba743@bobbriscoe.net> <7850b9ae-7696-8f68-92fc-fd53c7529112@bobbriscoe.net> 
From: Bob Briscoe 
Message-ID: 
Date: Wed, 31 May 2017 02:45:34 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: 
Subject: Re: [tsvwg] [Int-area] Intarea review needed: short draft on ECN propagation IP-shim(s)-IP
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 01:45:41 -0000

Tom,

On 31/05/17 00:51, Tom Herbert wrote:
> On Tue, May 30, 2017 at 4:08 PM, Bob Briscoe  wrote:
>> Intarea list,
>>
>> I presented this short draft just under a year ago in intarea. Since then it
>> has been adopted as a tsvwg work item.
>>
>> I have just added specific text to update those tunnel specs that are under
>> IETF change control (L2TP and GRE), as well as addressing non-IETF specs too
>> (VXLAN, GTP, NVGRE etc).
>>
> Hi Bob,
>
> On comment. GRE allows encapsulation of layer 2 (e.g. Ethernet, MPLS,
> etc.) and VXLAN only does encapsulation of Ethernet. I don't think
> these layer 2 headers could be considered shim headers per the draft,
> they are not removed in with the encapsulation headers and are
> routable in the layer 2 network. However, the layer 2 packet may
> contain an IP packet
You're right in all cases. After posting the draft, I also realized that 
is usually the case with L2TP as well.

One way to include all these cases in the scope of the draft is to say 
the tunnel endpoint SHOULD check the L2 payload for an IP header, even 
when the L2 header is not being added / removed. But that is rather an 
onerous requirement, don't you think? Especially given this would be 
asking the implementer to violate layering, we can only ask that it is 
done when feasible; it cannot be a hard requirement (e.g. L2 payload 
could be encrypted).

> and in at least once case (VXLAN) there is a
> recommendation to apply RFC6040 to an inner IP header.
What do you mean by "there is a recommendation"? I don't see it in RFC7348?

I am aware that the Linux code for VXLAN does ECN propagation per 
RFC6040. Perhaps that is what you're thinking of?
>
> Maybe the requirements for this scenario should be clarified? I think
> it's probably reasonable to say that ECN SHOULD be propagated in this
> case.
Yes, overnight I shall mull on how best to rephrase the scope of this, 
without too much mission creep.

Cheers


Bob
>
> Tom
>
>> I would appreciate review from someone in intarea who knows these specs
>> better than I do.
>>
>> If you know L2TP well, pls check the l2tpext list, where I have just posted
>> three L2TP-specific question.
>>
>>
>> Cheers
>>
>>
>> Bob
>>
>>
>> On 30/05/17 22:49, Bob Briscoe wrote:
>>> David (as doc shepherd) and the tsvwg list,
>>>
>>> As requested, I have added specific text that updates the other relevant
>>> RFCs under IETF change control (GRE and L2TP). I have also explained the
>>> position in each case for specs not under IETF change control.
>>>
>>> I will now go to the relevant WGs (intarea and lt2pext) and ask them to
>>> improve my first attempt.
>>>
>>> I'll cc you and this list as appropriate.
>>>
>>> Cheers
>>>
>>>
>>>
>>> Bob
>>>
>>> PS. I have also said
>>>
>>>     the rules in [RFC6040] for
>>>     propagating the ECN field MUST be applied
>>>
>>> whereas before it said "SHOULD". And added an explanation for why "MUST"
>>> is appropriate:
>>>
>>>     The above is written as a 'MUST' because RFC 6040 allows
>>>     a compatibility mode for the encapsulator in cases where the
>>>     decapsulator does not (or cannot) support ECN propagation.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 30/05/17 22:36, internet-drafts@ietf.org wrote:
>>>> A new version of I-D, draft-ietf-tsvwg-rfc6040update-shim-01.txt
>>>> has been successfully submitted by Bob Briscoe and posted to the
>>>> IETF repository.
>>>>
>>>> Name:        draft-ietf-tsvwg-rfc6040update-shim
>>>> Revision:    01
>>>> Title:        Propagating Explicit Congestion Notification Across IP
>>>> Tunnel Headers Separated by a Shim
>>>> Document date:    2017-05-30
>>>> Group:        tsvwg
>>>> Pages:        10
>>>> URL:
>>>> https://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rfc6040update-shim-01.txt
>>>> Status:
>>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rfc6040update-shim/
>>>> Htmlized:
>>>> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-01
>>>> Htmlized:
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim-01
>>>> Diff:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rfc6040update-shim-01
>>>>
>>>> Abstract:
>>>>      RFC 6040 on "Tunnelling of Explicit Congestion Notification" made the
>>>>      rules for propagation of ECN consistent for all forms of IP in IP
>>>>      tunnel.  This specification extends the scope of RFC 6040 to include
>>>>      tunnels where two IP headers are separated by at least one shim
>>>>      header that is not sufficient on its own for packet forwarding.
>>>>
>>>>
>>>>
>>>> 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
>>>>
>> --
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/


From nobody Wed May 31 01:37:54 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 07EF81293D9 for ; Wed, 31 May 2017 01:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 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] 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 nX9WnhozqqHZ for ; Wed, 31 May 2017 01:37:51 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 3739E127058 for ; Wed, 31 May 2017 01:37:50 -0700 (PDT)
X-AuditID: c1b4fb3a-6e3519a000004a6a-52-592e80dc4a85
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7F.11.19050.CD08E295; Wed, 31 May 2017 10:37:49 +0200 (CEST)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.72) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 31 May 2017 10:37:29 +0200
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=fa0iThzs4B2ae2zQ0nM0bAsJGUJh+Z7FiZ+KpL51t3A=; b=PcfzgOkz/Chli7jLNIHDOt79OsnzvCn0bO0XSqfvxcwGySdiKglC5lYAVRV+DxeKE/CGPxU2X+C7XdMUQXm03FejWpX5YonqNMe17aTfi7sI1PyG07e718K+Pt3x2mp7iNKYXWwCI4l8j0tweRE39nyV+3xVY3U97zBLNzTnOWM=
Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1143.6; Wed, 31 May 2017 08:37:26 +0000
Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4826:37de:a243:ea2f]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::4826:37de:a243:ea2f%17]) with mapi id 15.01.1143.009; Wed, 31 May 2017 08:37:26 +0000
From: Ingemar Johansson S 
To: "Black, David" 
CC: tsvwg IETF list 
Thread-Topic: WGLC comments on draft-ietf-tsvwg-ecn-experimentation
Thread-Index: AdLZ5w8jVW866mTKRGO1T+XnKF0ESg==
Date: Wed, 31 May 2017 08:37:26 +0000
Message-ID: 
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: dell.com; dkim=none (message not signed) header.d=none;dell.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [192.176.1.84]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:0ON1JqEWuGSkfG4g9GJDf3Ms4ShOdBHnYgzNdkWvmagqzv8Oju6JNxblWxDEQ/YhkSyCmo8nK7xWokvcSnY5scZoabGqmlOvF0TbM7rKFyDpOlG/1C8Vu54x7LA69ILotnytqz09xNFK6x13jDBfnOc2Q9s27ZLEFgagTBJFFyDmkqhFn3xA5OOAv+G4ZSkw8GuxpRJk0VsVAUXHwqqm3fS9vIV4ak97Ll0azf3VcCHEkOE8174Di2yjvxzGj+YJNPpTRxEc3+DPVuJkuQXDClsJfnC1dBJ68HJRdEM8kYHrfUXQFJmaDnFDM/UqET15GI2Jt5SqMTm0qSHlWyjzfg==
x-ms-traffictypediagnostic: DB4PR07MB348:
x-ms-office365-filtering-correlation-id: c47187e3-0223-4a3e-fa9b-08d4a800446f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB4PR07MB348; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; 
x-forefront-prvs: 0324C2C0E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(8936002)(478600001)(7736002)(5660300001)(189998001)(110136004)(38730400002)(2900100001)(6436002)(74316002)(7906003)(81166006)(8676002)(6116002)(102836003)(19609705001)(66066001)(3846002)(790700001)(3280700002)(7696004)(99286003)(14454004)(966005)(6506006)(55016002)(5250100002)(230783001)(33656002)(8666007)(6916009)(2906002)(606005)(86362001)(53936002)(4326008)(25786009)(54356999)(9326002)(9686003)(54896002)(3660700001)(6306002)(50986999)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3485B0A05E2466EC03A4EC2C2F10DB4PR07MB348eurprd_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2017 08:37:26.6331 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHO/cxr9LgNDV/Tpc2rDRzlQRZiZlKGdKTILVIR151pFN2l2kP H0RlTjPD11a+clnTQLBAhRKdYamIEv4h5SzTfBViUL6TvN4F/vc53+/3/M75Hg5DSky0lFGp taxGrUyQi+wofXhjqI8lUxGx50878vtlqKb8On5aRIFE6CN9KRlqNC4Qp4lIO/8YNkGVwmp2 B0TbxZebFujkgaDUl1VLRCaq9s9BtgzgfVDS34JykB0jwe8QfO4YIHhDgj8gaGh05g0K55GQ 9bfSmiomoLJvmRQWwwhysydt+C0i7A8m89xqimEcsBcMl4XwMok9oKh/UcTL9jgApvJiedkB B0NBQQESWAGj9RaaZwpvg+6vPSKexTgSCufb1jIIy+DL3BAljHSCT6MVhNAAg/FNLymwI0yO rND81RDWIZhtybeG3GFKlykSWAYfK3RrZQDrSLA0TVkNL2iumKMEPgG1T0tpgW/Bo3vfkcAq mB9rtuYvQGFHjkgYNEPAq9Zp62mu8OBuudV4QUPB4PLaVHssBUv/fSSwK0wMvqUfIk/DukoC J8Gd5iwbw9oTbIJO/Sgl6AoYKCoUCewNNVU/SIF9oHTFTK3XK5FNLXLkWI5LjPP1VbAa1WWO S1Ir1Ky2Aa1+oLbXSwebUNv4ETPCDJJvFF+KV0RIaGUKl5ZoRsCQcgdxWcqqJI5Rpl1nNUlR mqsJLGdGLgwldxIHtvSFS3CcUsteYdlkVvPfJRhbaSbSfVto952kU4uW9cvVJel5I8XnwqJl QROHB7Qzv0913XDJcdMc9+z2CDvgdrHVta1elb3Yld1el3GsuufkuP30UM38+zOzz3dszsgg kw4F3twiHs7dFSLTjUvrqkxa587gJzO3Te7XzvYejfI2pG/f8Ex9PjRNNpav32+Mje97vDVZ TnHxyr07SQ2n/Ae2T4cZPAMAAA==
Archived-At: 
Subject: [tsvwg] WGLC comments on draft-ietf-tsvwg-ecn-experimentation
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 08:37:53 -0000

--_000_DB4PR07MB3485B0A05E2466EC03A4EC2C2F10DB4PR07MB348eurprd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

I have read through https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experi=
mentation-02 and given that I have read it before I have mostly only editor=
ial nits.

+ Page 13: "..sender SHOULD set the ECT(0) codepoints."  Why is it a SHOULD=
 and not a MUST ?

Minor nits:
+ I-D.briscoe-tsvwg-ecn-l4s-id should be I-D.ietf-tsvwg-ecn-l4s-id
+ Page 9. The text starting with 'Senders are free...' ending with 'SHOULD =
use ECT(0)' make is difficult at first to deduce what is draft/RFC text and=
 what is comments. An alternative would be to enclose all draft/RFC text in=
 double quotes "..." . But this is not important, took me roughly 30 second=
s to interpret the text correctly :)

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

A mistake is to commit a misunderstanding
                     Bob Dylan
=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_DB4PR07MB3485B0A05E2466EC03A4EC2C2F10DB4PR07MB348eurprd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi


 


I have read through 
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-02 and=
 given that I have read it before I have mostly only editorial nits.


 


+ Page 13: “..sender SHOULD set the ECT(0)=
 codepoints.”  Why is it a SHOULD and not a MUST ?

 


Minor nits:


+ I-D.briscoe-tsvwg-ecn-l4s-id should be I-D.iet=
f-tsvwg-ecn-l4s-id


+ Page 9. The text starting with ‘Senders =
are free…’ ending with ‘SHOULD use ECT(0)’ make is =
difficult at first to deduce what is draft/RFC text and what is comments. A=
n alternative would be to enclose all draft/RFC text in double quotes
 “…” . But this is not important, took me roughly 30 seco=
nds to interpret the text correctly
J


 


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


 


A mistake is to commit a misunderstanding

       =
            &nb=
sp; Bob Dylan

=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<=
/o:p>


 






--_000_DB4PR07MB3485B0A05E2466EC03A4EC2C2F10DB4PR07MB348eurprd_--


From nobody Wed May 31 22:59:54 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 0AC7D127A91 for ; Wed, 31 May 2017 22:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 j7oSkTrLRPXO for ; Wed, 31 May 2017 22:59:50 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94AE12706D for ; Wed, 31 May 2017 22:59:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29153; q=dns/txt; s=iport; t=1496296789; x=1497506389; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=foJagfGtiVgZ6GrSzUPOiUkIWQN+e2aMU/lqSl/aytw=; b=TSa1Z3sfMNGWi/E9/eGtxRRaynLhYq9WWUOE5sVJ9pvRb/sqGjaOhkMB i+oYZ7jcIbPm8hrl2IU2EzvE1BtJYDk2dBx03Fu3hMyW69IpOGGn0I3ip 4MwhUFyiHYLNgs8Upbn6WTs0wR7mto+hAqt4FEEfHrUZNFd/8MMYhI2f0 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAADprC9Z/5JdJa1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMqLYFvB4RjiSKRc3KHN41Rgg+CboM2AoJuPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQIBGiArCAwFBwQCAQgRBAEBHwkHIREUCQgCBAENBQgTiXcDDQiuN?= =?us-ascii?q?YczDYQRAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYhAAYITWDSCWIFhARIBQoVMBYc?= =?us-ascii?q?SgjaNAochOwGOBkuET4IPhTyDbIZKizaEboQxAR84fwt0FRyFKwUcgSY9doc3g?= =?us-ascii?q?SOBDQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.39,278,1493683200"; d="scan'208";a="252210925"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2017 05:59:48 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v515xmsN021555 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2017 05:59:48 GMT
Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Jun 2017 00:59:46 -0500
Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Thu, 1 Jun 2017 00:59:46 -0500
From: "Tim Szigeti (szigeti)" 
To: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" 
CC: "fredbakersba@gmail.com" , "Jerome Henry (jerhenry)" 
Thread-Topic: draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules
Thread-Index: AQHS19nRqhAGXzeKJkuxsecs67EcPKIPaZwQ
Date: Thu, 1 Jun 2017 05:59:46 +0000
Message-ID: <33c57ede33d64b2eb6fcb0019e777373@XCH-RCD-010.cisco.com>
References: <5923F086.8030804@erg.abdn.ac.uk>   <5d3c37a54bfb4cfab699613e34b32a5f@XCH-RCD-010.cisco.com> <592A83D6.6080501@erg.abdn.ac.uk> <592B0BF4.2030204@erg.abdn.ac.uk>
In-Reply-To: <592B0BF4.2030204@erg.abdn.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.22.195]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Jun 2017 05:59:53 -0000

Hi Gorry,

Thank you again for taking the time to review the draft.

Some comments/responses inline...

> -----Original Message-----
> From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
> Sent: Sunday, May 28, 2017 10:42 AM
> To: tsvwg@ietf.org
> Cc: gorry@erg.abdn.ac.uk; Tim Szigeti (szigeti); fredbakersba@gmail.com;
> Jerome Henry (jerhenry)
> Subject: draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on
> conditioning rules
>=20
> This email describes a number of concerns with the inclusion of condition=
ing
> rules in the 802-11 draft.
>=20
> The title and abstract of the draft describe a mapping function.
> However, the changes in rev -02 give me serious doubts about the remarkin=
g
> and drop recommendations, which I consider for a diffserv edge.
>=20

 [TS]=20
I thought we already addressed this point on 5/24/17:

I'd like to first stress the point that the remarking and dropping recommen=
dations of network control traffic (marked CS6/CS7) at the edge of the wire=
d-to-wireless network (as made in Section 4.1.1) were part of the original =
2015 draft, and *are not new* recommendations in this latest revision.=20

Additionally, these recommendations are drawn from similar recommendations =
made in RFC 4594-Section 3.2 which:

 "RECOMMENDED that packets marked CS7
   DSCP (a codepoint that SHOULD be reserved for future use) be dropped
   or remarked at the edge of the Diffserv domain."

Our argument is that when the wireless access point represents the edge of =
the network infrastructure (and thus the edge of the Diffserv domain), this=
 recommendation should hold; otherwise a very easily exploitable DoS attack=
-vector (as discussed in Section 8-Security Considerations) is presented: n=
amely, that devices can flood traffic marked CS6/CS7 upstream and/or downst=
ream to/from the wireless network, causing a DoS for all other traffic flow=
s; furthermore, as no network devices would be located downstream in such s=
cenarios, then no such traffic would be legitimately marked to CS6/CS7.

NOTE: in the cases where the wireless edge is NOT the edge of the network i=
nfrastructure, this recommendation would not apply, as clearly expressed in=
 Section 4.1.1.



> Point 1: I think the WG need to be very clear about the context of
> recommendations. I'd expect the class mappings to PHBs to be applied in a=
ll
> equipment that adheres to IETF standards. This should I think be the defa=
ult
> for all APs - and I'd hope most vendors would start paying attention.
>=20

 [TS]=20
Apple has already paid attention to the recommendations in this draft and i=
s now following these recommendations on over 1 billion iPads and iPhones. =
Similarly every Cisco AP shipped in the last 2 years includes these recomme=
ndations.=20

The sooner we can reach a consensus, the sooner the rest of the industry wi=
ll likely follow suit.


> Point 2: My concern is that the draft now recommends diffserv edge
> mechanisms that I think are inappropriate for a mapping draft.

[TS]=20
Again - no new recommendations have been made. I'm not sure where this disc=
onnect is coming from.


 I suggest the
> conditioning rules apply to specific deployment scenarios.=20

[TS]=20
The conditioning rules *do* apply to very specific scenarios, as detailed i=
n Section 4.1

Section 4.1:
In most commonly-deployed WLAN models, where wireless access point
   represents not only the edge of the Diffserv domain, but also the
   edge of the network infrastructure itself.  Traffic marked CS7 DSCP
   SHOULD be dropped or remarked at this edge (as it is typically
   unused, as CS7 SHOULD be reserved for future use).  Network control
   traffic marked CS6 DSCP SHOULD also be dropped or remarked at this
   edge, considering that only client devices (and no network
   infrastructure devices) are downstream from the wireless access
   points in these deployment models; such client devices would be
   considered as untrusted sources of a network control traffic.  In
   such cases, no Network control traffic would be (legitimately)
   expected to be sent or received from wireless client endpoint
   devices, and thus this recommendation would apply.

   Alternatively, in other deployment models, where the wireless access
   point extends the network infrastructure and thus, typically, the
   Diffserv domain, the above recommendation would not apply, as the
   wired-to-wireless edge does not represent the edge of the Diffserv
   domain.  Furthermore, as these deployment models require Network
   Control traffic to be propagated across the wireless network, it is
   RECOMMENDED to map Network Control traffic marked CS6 to UP 7 (per
   [IEEE.802.11-2016] Section 10.2.4.2, Table 10-1), thereby admitting
   it to the Voice Access Category (AC_VO).  Similarly, if CS7 is in use
   as a network control protocol it would be RECOMMENDED to map it also
   to UP 7.


> I also suggest this
> does not apply to all equipment - any recommendations need to be certain
> about context for deployment.

[TS]=20
Deployment context is very clearly provide (as shown above).


>  I think there is quite an opportunity for the
> present text on remarking and drop in the current revision to be wrongly
> interpreted. I seriously fear the inclusion of remarking and drop
> recommendations can make this become an impediment to sender marking
> of DSCP across IP paths that happen to include 802.11 equipment.
>=20
[TS]
If the "802.11 equipment" referred to extends the IP infrastructure, then t=
he recommendation above is to Map CS6 and CS7 to UP 7.

Otherwise, if the "802.11 equipment" referred to are endpoint devices, then=
 can you provide a use-case where it would be beneficial to map these contr=
ol-plane packet-markings to the 802.11 Access Category intended? If we reco=
mmend this, it presents a significant security vulnerability (i.e. the DoS =
attack vector caused by flooding packets downstream marked CS6 or CS7, whic=
h can disrupt service for ALL wireless devices in BOTH directions. Is this =
actually the recommendation you would prefer in this scenario? Please confi=
rm.
=20

> Point 3: The specific conditioning rules argue for pervasive remarking of=
 all
> "unknown" codepoints - this position is a very specific view.=20
[TS]=20
Nowhere does the PS state to 'pervasively remark all unknown codepoints.=20

What is stated is:

Section 2.1:

In most commonly-deployed WLAN models, the wireless access point
   represents not only the edge of the Diffserv domain, but also the
   edge of the network infrastructure itself.  As such, only client
   devices (and no infrastructure devices) are downstream from the
   access points in these deployment models.  In such deployment models,
   it is RECOMMENDED that all packets marked to Diffserv Codepoints not
   in use over the wireless network be dropped or remarked at the edge
   of the Diffserv domain, as will be discussed in detail in
   Section 4.1.1.


An "unknown" codepoint is different from a codepoint that "is not in use". =
 If the administrator knows that a given codepoint is not in use, then he d=
oes well to remark or drop this traffic at the edge of the network. Again, =
it should be stressed as highlighted above, this recommendation *only* appl=
ies at the edge of the network (i.e. when the wireless edge is concurrently=
 the edge of the network, as well as the edge of the Diffserv domain). Othe=
rwise codepoints 41, 42, 43, 45, 47, 49, 50, 51, 52, 53, 54, 55, 57, 58, 59=
, 60, 61, 62, 63 (as well as unused codepoints in lower ranges) could all g=
enerate the DoS attack described above.



 > If stated in a PS
> for 802.11 this would have serious implications on the usefulness of diff=
serv,
[TS]=20
I don't see how this is so. Across any network infrastructure (wired or wir=
eless) Diffserv codepoints are untouched and unaltered.

The recommendation to remark or drop packets marked to control-plane and/or=
 unused codepoints only applies at the edge of the network.=20

I would argue that the wireless network becomes a significantly less-useful=
 when *any* sender can cause a complete DoS of it by generating packets mar=
ked CS6 or CS7 (or various unused codepoints, as described above) in the up=
stream/downstream direction to/from devices that:
 1) do not participate in network control protocols and operations and
 2) are generating packet markings to codepoints that are not being used, p=
er the administrative policy of the domain.

> and I think the IETF really has to consider these in detail before it tak=
es this
> approach for 802.11.
>=20
> ------------
>=20
> So, starting with Point 1: I noted previously that I do see real benefit =
in
> recommendations on how to map DSCPs using 802.11 and I suspect, if done
> correctly, this can greatly ease the consistent use of DSCP.
>=20
[TS]=20
Can you elaborate on how you feel this should be "done correctly"?

i.e. are you saying that packets marked to control plane markings (or unuse=
d DSCP markings) should always be mapped to corresponding UP values?=20

If so - does the rest of TSVWG agree? You guys beat us up pretty bad last W=
GLC due to security concerns. Now that we've tightened up the security cons=
iderations section (but kept all the recommendations the same), it seems th=
at we're getting beat up again.

We simply can't do both. Either we present a universal mapping, complete wi=
th security vulnerabilities; or we present some deployment-specific recomme=
ndations to address very valid security concerns.=20

Which is it to be?


> It may be that the security considerations need to discuss the trust of
> markings and the possible need to remark or drop to protect the AP
> resources.=20
[TS]=20
The security section does include discuss trust and the need to remark and =
drop; and not just to protect the AP, but all devices on the (egalitarian) =
WLAN.


> I can also see how CS6 and CS7 may need to be discussed and text
> may have to say things about these when the AP is forms the edge of a
> network.
>=20
[TS]=20
The text already contains these distinctions several times, as quoted above=
.=20


> TEXT:
> Traffic marked CS7 DSCP
> SHOULD be dropped or remarked at this edge (as it is typically unused, as=
 CS7
> SHOULD be reserved for future use).
> - section 4.1.1. recommends drop or remark, and I struggle here to know t=
hat
> this is the correct statement to make in general for 802.11 usage.

[TS]=20
The deployment model is clearly spelled out prior to this recommendation; t=
he context is present, even if it wasn't quoted here.


> Is it strictly necessary to drop CS6 traffic at an AP, that seems plausib=
le in
> managed (e.g. enterprise) deployment, or on the upstream to an ISP in a
> home deployment (maybe in some places the operator own the AP?).

[TS]=20
OK - we're in agreement here.


> Between IP networks in my house this seems like the wrong thing to do. It
> may be used by a routing protocol=20
[TS]=20
The recommendation to drop or remark only applies at the edge of the networ=
k infrastructure. Is your routing protocol communicating to/from user endpo=
int-devices?=20

If on the other hand, the wireless devices *extend* the network infrastruct=
ure, and are thus correctly and legitimately carrying routing protocols, th=
is recommendation does not apply -- as is clearly stated multiple times.



(e.g. RPL as
> noted) could use this DSCP, why can I not use a layer 2 technology to mov=
e
> these packets between parts of my IP network with the DSCP that has been
> assigned?
>=20
[TS]=20
If you're using wireless devices to extend your network in your home, then =
as noted above, the recommendation to drop or remark does not apply.


> So, really I question if the current phrasing is the correct recommendati=
on. I
> think the WG needs to choose appropriate words here but that needs I thin=
k
> to be balanced by explaining that these codepoints may be used within a
> house or whatever for routing and functions. - They are not just for the
> upstream ISP!
>=20
[TS]=20
This isn't a matter of whether the wireless deployment is intended for an e=
nterprise, a public hot-spot, a home network, etc.

The only consideration that applies is whether or not the wireless AP repre=
sents the edge of the IP network;=20
- if so, then a very valid security consideration is addressed by remarking=
 control-plane and unused codepoints (in the downstream direction, that is,=
 toward the endpoint devices);=20
- if not, (i.e. the wireless infrastructure is extending the IP network) th=
en codepoints are passed unaltered and mapped to the appropriate access-cat=
egories


> Point 2: As you noted, there is a wide variety of 802.11 equipment and us=
es
> and you highlight two distinct deployment models. 802.11 uses are really
> diverse - they include managed environments in Enterprises, public wifi
> access, home networks, use as layer infrastructure in a very general sens=
e,
> bridging to other layer 2 infrastructure (zigbee, etc).

 [TS]=20
All of these context use only one of the two general deployment models disc=
ussed:=20
- either the wireless AP represents the edge of the IP network (with only c=
lient endpoint devices downstream)
- or not.


>=20
> There now follows concerns about the new text, which largely stems from
> the above context (i.e., in a different document with a different purpose=
 the
> comments would be different).
>=20
> I am not sure this text is helpful:
> " In most commonly-deployed WLAN models, the wireless access point
> represents not only the edge of the Diffserv domain, but also the edge of
> the network infrastructure itself.
> As such, only client
> devices (and no infrastructure devices) are downstream from the access
> points in these deployment models.
> "
> - Again, there are many cases where this also not the same as well. I hav=
e a
> number of APs in my house, and for that matter a zigbee bridge that
> connects IoT devices. For many flows the AP is one hop to the DSL modem,
> but flows also exist between endpoints in the house - e.g. to deliver TV
> content across my home network, or to turn on/off lights or simply access
> the house computer from my laptop.
>=20

 [TS]=20
Are any downstream devices participating in IP control-plane protocols and =
operations? If so, then this fits the deployment model where wireless devic=
es are extending the IP network infrastructure; if not, then it fits the wi=
reless-edge model. It doesn't matter if this network is in a home, in an en=
terprise or in some other context.


> On Point 3: I think it may be wrong to recommend this:
> TEXT:
> "
> In such deployment models,
> it is RECOMMENDED that all packets marked to Diffserv Codepoints not in
> use over the wireless network be dropped or remarked at the edge of the
> Diffserv domain, as will be discussed in detail in Section 4.1.1."
> - I would really hope APs do not do this, except if they within the contr=
ol
> network of an upstream service provider that has configured consistent ru=
les
> at the Apps for the service they offer.
>=20

 [TS]=20
OK -we can remove that recommendation, but only if you and all of TSVWG are=
 all ok with leaving any wireless network wide-open for a very easy DoS att=
ack.


> I see the next para effectively implies SHOULD NOT remark or drop, in som=
e
> other case - but even though I suspect you are hoping for the correct thi=
ng I
> do not see this clearly enough to feel confident that others will always
> understand what to do.
>=20
> - It also suggests drop and remark are equal, they are not

 [TS]=20
There's no implication that they are equal. A choice is presented to the ad=
ministrator, that is all.

 - the there
> behaviour i) (carry as DF (ii) Remark to DF (iii) Drop have quite differe=
nt
> implications to those trying to write apps that wish to use diffserv.

> ---
> TEXT:
> "
> Thus the QoS treatment of packets at the access point will depend on the
> position of the AP in the network infrastructure and on the WLAN
> deployment model."
> - Oh indeed, but the more I read, the more I'd really rather see how to
> handle edge treatment as a separate document that clearly explains that a=
t a
> diffserv edge you do conditioning and what are the implications of the
> different approaches.

[TS]=20
Are you suggesting we change the context of the PS to Diffserv edge (only).

If so, that would be ironic. As originally that was the context and we were=
 asked to include both deployment models (wireless-edge and extended-infras=
tructure).

> ---
> TEXT:
> It is NOT RECOMMENDED to trust DSCP markings from devices that are not
> authenticated and authorized; these are considered untrusted sources.
> - Question: What is the intent here? Are you encouraging DSCP remarking (=
I
> hope not), or are you saying that the UP marking is assigned using a loca=
l
> policy rather than from the DSCP?
>=20

 [TS]=20
This was a direct comment from the last round of WGLC reviews to address th=
e security concern that just because a device can mark DSCP doesn't necessa=
rily mean that it should be trusted to by the network.


> - I suspect the context here is not about mapping it is about managed use=
 of
> an AP network. That varies, and I really think this is not the document t=
o
> discuss that. The security considerations could note this - but quite hon=
estly,
> if you expect my light bulbs and TV sets to start authenticating with the=
 AP,

 [TS]=20
No one suggested that these devices start authenticating to the AP; it's ju=
st a general security recommendation made at a TSVWG reviewer's direct requ=
est to highlight the security vulnerability to blanketly accept any marking=
s from any device.

If the device is authorized to operate on your network, then fine. If it's =
not, then we're recommending not to trust it.=20


> then I'm going to argue. Do these devices benefit from using DSCPs - very
> very likely.
>=20
[TS]=20
OK - and if someone takes control of the software running on your lightbulb=
s and begins blasting traffic marked CS7/UP7 from your lightbulb, causing a=
 complete DoS of your WLAN, then you're still ok with this?

Look, we can change this if that's what you guys really want. But don't ham=
mer us for security concerns, if (as it seems from this latest round) you a=
ctually want all of these removed.


> - Of course, if you were offering infrastucture to a range of customers t=
hen
> you may need to consider these issues. Saying SHOULD NOT trust seems to
> suggest you threaten to remark? or just to carry as best-effort within th=
is
> network?


[TS]=20
The recommendation reads:
> It is NOT RECOMMENDED to trust DSCP markings from devices that are not
> authenticated and authorized; these are considered untrusted sources.

You're objecting to the recommendation to NOT trust markings from such devi=
ces; are you then really recommending the opposite? i.e. trusting the packe=
t markings of unauthenticated and/or unauthorized devices?

Wow. I really feel like there's an over-rotation against security on this r=
ound of review.



> (Back to point 2: We all know that public radio networks need to consider
> resource models, but this is not a PHB mapping question.)
> ---
> TEXT:
> "Alternatively, if a network device is configured to operate in an untrus=
ted
> manner, then it would remark packets as these entered the device, typical=
ly
> to DF (or to a different marking value at the network administrator's
> preference). Note:
> The terms "trusted" and "untrusted" are used extensively in RFC 4594."
> - This is NOT what I want from an out-of-the-box AP configuration, and I
> think this muddies the deployment context.
> ---

[TS]=20
OK - but again - you can't have it both ways. If you want everything to be =
trusted out-of-the-box, then you have to accept the security vulnerabilitie=
s that this presents.

However, I think that as 90%+ of wireless APs are deployed at the edge of t=
he network (and are NOT being used to extend the IP network infrastructure)=
, that this is the better recommendation for most users' out-of-the-box pre=
ferences.



>=20
> More on point 3: I really do not agree with the text in section 5.4:
> TEXT:
> 5.4. Upstream DSCP Marking at the Wireless Access Point
>=20
> An alternative option to mapping is for the administrator to treat the wi=
reless
> edge as the edge of the Diffserv domain and explicitly set (or reset) DSC=
P
> markings in the upstream direction according to administrative policy. Th=
is
> option is RECOMMENDED over mapping, as this typically is the most secure
> solution, as the network administrator directly enforces the Diffserv pol=
icy
> across the IP network (versus an application developer and/or the wireles=
s
> endpoint device operating system developer, who may be functioning
> completely independently of the network administrator).
>=20
> - Comment. I see the alternative and realise that the edge of a DS domain
> can condition traffic, but it would be truly dismal if every home router =
tried to
> reset all the DSCPs I use.

[TS]=20
That's not being recommended. Trusting DSCP is discussed immediately previo=
usly in Section 5.3 and is a perfectly valid option, even as described:

When business requirements and/or technical constraints and/or
   administrative policies require a trust function at the wireless
   edge, then it is RECOMMENDED to trust DSCP (over [IEEE.802.11-2016]
   UP markings) markings in the upstream direction, for the following
   reasons:

Your home router scenario fits in well with what is being described here. A=
s such, there's no need to interpret Sections 5.3 and 5.4 as presenting 'di=
smal' recommendations.

> - I strongly dislike an approach that drops packets with DSCPs ( except f=
or
> admitted services). I think drop and even remark is a direct hurdle for a=
pps to
> become able to use Diffserv across other network paths.=20

[TS]=20
The dropping/remarking recommendation is made in the downstream direction, =
and only in deployment models where the AP represents the edge of the netwo=
rk. Hence there are no "other network paths" to choose from in this deploym=
ent model, and as such the objection does not apply.


If this is approach is
> taken by a wireless AP - then the network to which it connects is now
> deprived of application-chosen DSCPs. APs are used in many ways, e.g., as
> bridges to other infrastructure in IOT applications this recommendation
> would come in the way of assigning DSCPs for control applications in this
> case.

[TS]=20
We've covered this ground already: if downstream devices are participating =
in network control protocols and operations, then the recommendation does n=
ot apply.=20


 It also produces a different DSCP behaviour when I use wifi AP to when
> I use a wired network segment. I therefore do not support this as the
> recommended approach, what do others think?
> ---
> TEXT:
> "it is RECOMMENDED that all packets marked to Diffserv Codepoints not in
> use over the wireless network be dropped or remarked"
> I strongly disagree with the following recommendation, which was formally=
 in
> the network control section and I had not understood that this "all packe=
ts"
> actually was intended as a general recommendation to reset all DSCPs.
>=20
[TS]=20
All DSCPs <> all DSCPs *not in use*


> It becomes very difficult to use diffserv at all if each layer 2 network =
has
> different remark/drop policies. At the moment many networks neither
> remark nor drop - which I actually think is correct,=20

[TS]=20
Until you're hit by an easily-achievable DoS attack by any app developer. I=
n which case it may not seem as correct.


they are layer 2 devices
> and they have not been configured with any information about the Diffserv
> capabilities of the networks they talk to.
> ---
> TEXT:
> "Section 4.1.1 RECOMMENDED that all packets marked to Diffserv
> Codepoints not in use over the wireless network be dropped or remarked at
> the edge of the Diffserv domain. This recommendation may help mitigate a
> Denial-of-Service attack vector that exists at wired-to-wireless edges in=
 the
> downstream direction. For example, consider a malicious user flooding tra=
ffic
> marked CS7 or CS6 DSCP toward the WLAN. These codepoints would map by
> default to UP 7 and UP 6 (respectively), both of which would be assigned =
to
> the Voice Access Category (AC_VO). Such a flood could cause a Denial- of-
> Service to wireless voice applications."
>=20
> I think it is useful case to describe, but I do not agree with the
> recommendation for this document.


[TS]=20
OK - I think we've been over this quite a few times.=20

If TSVWG really wants us to remove all of these security recommendation, th=
en we will. But I'm extremely hesitant to just yank all these out b/c of on=
e reviewer's comments, especially when so many have expressed concern that =
the PS previously did not include enough security considerations.


> ---
> TEXT:
> "Section 5.3 made it clear that it is NOT RECOMMENDED to trust DSCP
> markings from devices that are not authenticated and authorized, as these
> are considered untrusted sources. This is especially relevant for IoT, as
> billions of devices are being connected to IP networks, many of which hav=
e
> little or no security."
>=20
> I share the concern here, and I think it is useful case to describe, but =
I do not
> agree with the recommendation for this document:

[TS]=20
OK - so again, to be clear, TSVWG really is recommending that we offer a PS=
 that leave WLANs wide open from DoS attacks from any IoT device?

I just want to make sure there's consensus before I go an hack all these re=
commendations out.

> - In my home network?


[TS]=20
I think you're overly-focused on your atypical home network, which (as has =
been previously discussed) can cleanly fit into one or the other deployment=
 models presented in the PS, depending on whether you have any control-plan=
e protocols in use downstream from the wired network. As such, I don't see =
any conflict between the recommendations in the PS and the home network sce=
nario you keep referring to.

>=20
> I don't agree with the current text in section 5.3, which begins:
> "It is NOT RECOMMENDED to trust DSCP markings from devices that are not
> authenticated and authorized; these are considered untrusted sources."
>=20


[TS]=20
Haven't we already covered this ground already, more than once?

> ---
>=20
> I do not agree with this:
> Section 5.4 RECOMMENDED that the administrator treat the wireless edge as
> the edge of the Diffserv domain and explicitly set (or
> reset) DSCP markings in the upstream direction according to administrativ=
e
> policy.
> - the discussion goes on to talk about an example with CS6 and CS7, there
> may be a case for admission control to this class - or at least this PHB =
- but the
> general comment of requesting rewriting of all codepoints goes against
> current practice as far as I can see, and also is most unhelpful.
>=20


[TS]=20
Again - seems like the same objections are being raised multiple times.=20


> ---
> TEXT
> Suffice it to say that
> the security of the devices and networks implementing QoS, including QoS
> mapping between wired and wireless networks, SHOULD be considered in
> actual deployments.
> - I agree that you must protect operator infrastructure, and all people w=
ho
> use APs need to make decisions about which traffic to admit to the networ=
k
> at a particular QoS level. That does not mean I agree with thinking a dev=
ice
> need to remark all my traffic because it is not what you think is best to=
 cross a
> wireless/wired boundary."
>=20


[TS]=20
It has nothing to do with that I think best crosses a wired/wireless bounda=
ry.

If the operator is using codepoints that cross the wired/wireless boundary,=
 then these should be honored and preserved; this is clearly spelled out.

If the operator is using codepoints for control plane protocols beyond the =
wired/wireless boundary, then these should be honored and preserved; this i=
s clearly spelled out.

If not, then these are recommended to be dropped at the edge of the network=
 (only).

> -------------------
>=20
> I look forward to learning more what others think on this,
>=20


[TS]=20
So do I. As the comments to date have been guiding us in the opposite direc=
tion.

-tim

> best wishes,
>=20
> Gorry Fairhurst
>=20
>=20
>=20


From nobody Wed May 31 23:14:57 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 26185129B46 for ; Wed, 31 May 2017 23:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 NtQXo7lLa-JO for ; Wed, 31 May 2017 23:14:53 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DC11272E1 for ; Wed, 31 May 2017 23:14:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15659; q=dns/txt; s=iport; t=1496297693; x=1497507293; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=12e7Icx02vy0L5gFLzW2K7mEvYIXYyu9XRjgNEiKVfY=; b=NVK8AfAD1btiiMPqyuJM6wDRUyvsuUtBhMyRrh7TLdLsaW9nny1wNNeO 6t382+v9+R9+tndRRoyetSRm5du/Zeksn+ayfCXnfSs38W8LGS7HcBqi3 VzFdg5riyAGLfgKSHfW0IC2lor1dAigGDaOqGpnAxItyYO/Dng9UdlFz8 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAAAvsC9Z/4gNJK1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNXgW8HhGOJIpFzcoc3jVGCD4YkAoJvPxgBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBZQYCDAwEAgEIEQQBASgHIREUCQgCBAENBQgTiXcDDQiuLIczDYQRA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYhAgmw0gliBYgwGAUKFTAWHEoI2hyeFW4c?= =?us-ascii?q?hOwGOBkuET4IPhTyDbIZKizaJHwEfOH8LdBUchSs6gQ09docpDheBDIENAQEB?=
X-IronPort-AV: E=Sophos;i="5.39,278,1493683200"; d="scan'208";a="432032089"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Jun 2017 06:14:51 +0000
Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v516EplS012324 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2017 06:14:51 GMT
Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Jun 2017 01:14:50 -0500
Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Thu, 1 Jun 2017 01:14:50 -0500
From: "Tim Szigeti (szigeti)" 
To: "Ruediger.Geib@telekom.de" , "gorry@erg.abdn.ac.uk" 
CC: "Jerome Henry (jerhenry)" , "tsvwg@ietf.org" , "fredbakersba@gmail.com" 
Thread-Topic: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules
Thread-Index: AQHS19nRqhAGXzeKJkuxsecs67EcPKILaAUAgAQhC8A=
Date: Thu, 1 Jun 2017 06:14:50 +0000
Message-ID: <80ee670f49a54acdbc923ace2917c75a@XCH-RCD-010.cisco.com>
References: <5923F086.8030804@erg.abdn.ac.uk>   <5d3c37a54bfb4cfab699613e34b32a5f@XCH-RCD-010.cisco.com> <592A83D6.6080501@erg.abdn.ac.uk> <592B0BF4.2030204@erg.abdn.ac.uk> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.22.195]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on conditioning rules
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Jun 2017 06:14:56 -0000

Hi Ruediger,

Good to hear from you.=20

Some comments/questions inline,

> -----Original Message-----
> From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of
> Ruediger.Geib@telekom.de
> Sent: Monday, May 29, 2017 2:57 AM
> To: gorry@erg.abdn.ac.uk
> Cc: Jerome Henry (jerhenry); tsvwg@ietf.org; fredbakersba@gmail.com
> Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about tex=
t
> on conditioning rules
>=20
> Hi Gorry,
>=20
> you suggest to limit the scope of draft-ietf-tsvwg-ieee-802-11 to specify=
 a
> default Diffserv mapping behavior for a commodity piece of Hardware

[TS]=20
OK - but keep in mind that a single Diffserv mapping behavior for a commodi=
ty piece of hardware, regardless of how it's used, can present some signifi=
cant security vulnerabilities. Are we sure that this is what we want to rec=
ommend in a PS?

. Any
> IP related policies to be deployed if that piece of Hardware is used in a
> specific deployment should be separated and become part of a document in
> its own.

[TS]=20
Won't that cause even more confusion? In this PS, there is a relatively min=
or part that addresses the exception use-case where APs are used to extend =
the infrastructure (and specifically relate to control plane markings only)=
. Other than that, the mapping behavior is a universal recommendation.=20

Would really a separate draft/PS be warranted for this minor use-case? That=
 in all other respects would be the same overall recommendations?

Please elaborate/clarify.

TIA.

-tim

>=20
> I'm not a Wifi expert, but to me there's a point in your proposal.
>=20
> Regards,
>=20
> Ruediger
>=20
> PS: I also thought about comparing the separation of mapping and policy t=
o
> Diffserv-Intercon, which covers both. There we had some policy related
> discussions, about bleaching, for example. The latter is scoped for a spe=
cific
> deployment however.
>=20
>=20
> -----Urspr=FCngliche Nachricht-----
> Von: tsvwg [mailto:tsvwg-bounces@ietf.org] Im Auftrag von Gorry Fairhurst
> Gesendet: Sonntag, 28. Mai 2017 19:42
> An: tsvwg@ietf.org
> Cc: gorry@erg.abdn.ac.uk; Jerome Henry (jerhenry);
> fredbakersba@gmail.com
> Betreff: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - Concerns about text on
> conditioning rules
>=20
> This email describes a number of concerns with the inclusion of condition=
ing
> rules in the 802-11 draft.
>=20
> The title and abstract of the draft describe a mapping function.
> However, the changes in rev -02 give me serious doubts about the remarkin=
g
> and drop recommendations, which I consider for a diffserv edge.
>=20
> Point 1: I think the WG need to be very clear about the context of
> recommendations. I'd expect the class mappings to PHBs to be applied in a=
ll
> equipment that adheres to IETF standards. This should I think be the defa=
ult
> for all APs - and I'd hope most vendors would start paying attention.
>=20
> Point 2: My concern is that the draft now recommends diffserv edge
> mechanisms that I think are inappropriate for a mapping draft. I suggest =
the
> conditioning rules apply to specific deployment scenarios. I also suggest=
 this
> does not apply to all equipment - any recommendations need to be certain
> about context for deployment. I think there is quite an opportunity for t=
he
> present text on remarking and drop in the current revision to be wrongly
> interpreted. I seriously fear the inclusion of remarking and drop
> recommendations can make this become an impediment to sender marking
> of DSCP across IP paths that happen to include 802.11 equipment.
>=20
> Point 3: The specific conditioning rules argue for pervasive remarking of=
 all
> "unknown" codepoints - this position is a very specific view. If stated i=
n a PS
> for 802.11 this would have serious implications on the usefulness of diff=
serv,
> and I think the IETF really has to consider these in detail before it tak=
es this
> approach for 802.11.
>=20
> ------------
>=20
> So, starting with Point 1: I noted previously that I do see real benefit =
in
> recommendations on how to map DSCPs using 802.11 and I suspect, if done
> correctly, this can greatly ease the consistent use of DSCP.
>=20
> It may be that the security considerations need to discuss the trust of
> markings and the possible need to remark or drop to protect the AP
> resources. I can also see how CS6 and CS7 may need to be discussed and te=
xt
> may have to say things about these when the AP is forms the edge of a
> network.
>=20
> TEXT:
> Traffic marked CS7 DSCP
> SHOULD be dropped or remarked at this edge (as it is typically unused, as=
 CS7
> SHOULD be reserved for future use).
> - section 4.1.1. recommends drop or remark, and I struggle here to know t=
hat
> this is the correct statement to make in general for 802.11 usage.
> Is it strictly necessary to drop CS6 traffic at an AP, that seems plausib=
le in
> managed (e.g. enterprise) deployment, or on the upstream to an ISP in a
> home deployment (maybe in some places the operator own the AP?).
> Between IP networks in my house this seems like the wrong thing to do. It
> may be used by a routing protocol (e.g. RPL as
> noted) could use this DSCP, why can I not use a layer 2 technology to mov=
e
> these packets between parts of my IP network with the DSCP that has been
> assigned?
>=20
> So, really I question if the current phrasing is the correct recommendati=
on. I
> think the WG needs to choose appropriate words here but that needs I thin=
k
> to be balanced by explaining that these codepoints may be used within a
> house or whatever for routing and functions. - They are not just for the
> upstream ISP!
>=20
> Point 2: As you noted, there is a wide variety of 802.11 equipment and us=
es
> and you highlight two distinct deployment models. 802.11 uses are really
> diverse - they include managed environments in Enterprises, public wifi
> access, home networks, use as layer infrastructure in a very general sens=
e,
> bridging to other layer 2 infrastructure (zigbee, etc).
>=20
> There now follows concerns about the new text, which largely stems from
> the above context (i.e., in a different document with a different purpose=
 the
> comments would be different).
>=20
> I am not sure this text is helpful:
> " In most commonly-deployed WLAN models, the wireless access point
> represents not only the edge of the Diffserv domain, but also the edge of
> the network infrastructure itself.
> As such, only client
> devices (and no infrastructure devices) are downstream from the access
> points in these deployment models.
> "
> - Again, there are many cases where this also not the same as well. I hav=
e a
> number of APs in my house, and for that matter a zigbee bridge that
> connects IoT devices. For many flows the AP is one hop to the DSL modem,
> but flows also exist between endpoints in the house - e.g. to deliver TV
> content across my home network, or to turn on/off lights or simply access
> the house computer from my laptop.
>=20
> On Point 3: I think it may be wrong to recommend this:
> TEXT:
> "
> In such deployment models,
> it is RECOMMENDED that all packets marked to Diffserv Codepoints not in
> use over the wireless network be dropped or remarked at the edge of the
> Diffserv domain, as will be discussed in detail in Section 4.1.1."
> - I would really hope APs do not do this, except if they within the contr=
ol
> network of an upstream service provider that has configured consistent ru=
les
> at the Apps for the service they offer.
>=20
> I see the next para effectively implies SHOULD NOT remark or drop, in som=
e
> other case - but even though I suspect you are hoping for the correct thi=
ng I
> do not see this clearly enough to feel confident that others will always
> understand what to do.
>=20
> - It also suggests drop and remark are equal, they are not - the there
> behaviour i) (carry as DF (ii) Remark to DF (iii) Drop have quite differe=
nt
> implications to those trying to write apps that wish to use diffserv.
> ---
> TEXT:
> "
> Thus the QoS treatment of packets at the access point will depend on the
> position of the AP in the network infrastructure and on the WLAN
> deployment model."
> - Oh indeed, but the more I read, the more I'd really rather see how to
> handle edge treatment as a separate document that clearly explains that a=
t a
> diffserv edge you do conditioning and what are the implications of the
> different approaches.
> ---
> TEXT:
> It is NOT RECOMMENDED to trust DSCP markings from devices that are not
> authenticated and authorized; these are considered untrusted sources.
> - Question: What is the intent here? Are you encouraging DSCP remarking (=
I
> hope not), or are you saying that the UP marking is assigned using a loca=
l
> policy rather than from the DSCP?
>=20
> - I suspect the context here is not about mapping it is about managed use=
 of
> an AP network. That varies, and I really think this is not the document t=
o
> discuss that. The security considerations could note this - but quite hon=
estly,
> if you expect my light bulbs and TV sets to start authenticating with the=
 AP,
> then I'm going to argue. Do these devices benefit from using DSCPs - very
> very likely.
>=20
> - Of course, if you were offering infrastucture to a range of customers t=
hen
> you may need to consider these issues. Saying SHOULD NOT trust seems to
> suggest you threaten to remark? or just to carry as best-effort within th=
is
> network?
> (Back to point 2: We all know that public radio networks need to consider
> resource models, but this is not a PHB mapping question.)
> ---
> TEXT:
> "Alternatively, if a network device is configured to operate in an untrus=
ted
> manner, then it would remark packets as these entered the device, typical=
ly
> to DF (or to a different marking value at the network administrator's
> preference). Note:
> The terms "trusted" and "untrusted" are used extensively in RFC 4594."
> - This is NOT what I want from an out-of-the-box AP configuration, and I
> think this muddies the deployment context.
> ---
>=20
> More on point 3: I really do not agree with the text in section 5.4:
> TEXT:
> 5.4. Upstream DSCP Marking at the Wireless Access Point
>=20
> An alternative option to mapping is for the administrator to treat the wi=
reless
> edge as the edge of the Diffserv domain and explicitly set (or reset) DSC=
P
> markings in the upstream direction according to administrative policy. Th=
is
> option is RECOMMENDED over mapping, as this typically is the most secure
> solution, as the network administrator directly enforces the Diffserv pol=
icy
> across the IP network (versus an application developer and/or the wireles=
s
> endpoint device operating system developer, who may be functioning
> completely independently of the network administrator).
>=20
> - Comment. I see the alternative and realise that the edge of a DS domain
> can condition traffic, but it would be truly dismal if every home router =
tried to
> reset all the DSCPs I use.
> - I strongly dislike an approach that drops packets with DSCPs ( except f=
or
> admitted services). I think drop and even remark is a direct hurdle for a=
pps to
> become able to use Diffserv across other network paths. If this is approa=
ch is
> taken by a wireless AP - then the network to which it connects is now
> deprived of application-chosen DSCPs. APs are used in many ways, e.g., as
> bridges to other infrastructure in IOT applications this recommendation
> would come in the way of assigning DSCPs for control applications in this
> case. It also produces a different DSCP behaviour when I use wifi AP to w=
hen
> I use a wired network segment. I therefore do not support this as the
> recommended approach, what do others think?
> ---
> TEXT:
> "it is RECOMMENDED that all packets marked to Diffserv Codepoints not in
> use over the wireless network be dropped or remarked"
> I strongly disagree with the following recommendation, which was formally=
 in
> the network control section and I had not understood that this "all packe=
ts"
> actually was intended as a general recommendation to reset all DSCPs.
>=20
> It becomes very difficult to use diffserv at all if each layer 2 network =
has
> different remark/drop policies. At the moment many networks neither
> remark nor drop - which I actually think is correct, they are layer 2 dev=
ices
> and they have not been configured with any information about the Diffserv
> capabilities of the networks they talk to.
> ---
> TEXT:
> "Section 4.1.1 RECOMMENDED that all packets marked to Diffserv
> Codepoints not in use over the wireless network be dropped or remarked at
> the edge of the Diffserv domain. This recommendation may help mitigate a
> Denial-of-Service attack vector that exists at wired-to-wireless edges in=
 the
> downstream direction. For example, consider a malicious user flooding tra=
ffic
> marked CS7 or CS6 DSCP toward the WLAN. These codepoints would map by
> default to UP 7 and UP 6 (respectively), both of which would be assigned =
to
> the Voice Access Category (AC_VO). Such a flood could cause a Denial- of-
> Service to wireless voice applications."
>=20
> I think it is useful case to describe, but I do not agree with the
> recommendation for this document.
> ---
> TEXT:
> "Section 5.3 made it clear that it is NOT RECOMMENDED to trust DSCP
> markings from devices that are not authenticated and authorized, as these
> are considered untrusted sources. This is especially relevant for IoT, as
> billions of devices are being connected to IP networks, many of which hav=
e
> little or no security."
>=20
> I share the concern here, and I think it is useful case to describe, but =
I do not
> agree with the recommendation for this document:
> - In my home network?
>=20
> I don't agree with the current text in section 5.3, which begins:
> "It is NOT RECOMMENDED to trust DSCP markings from devices that are not
> authenticated and authorized; these are considered untrusted sources."
>=20
> ---
>=20
> I do not agree with this:
> Section 5.4 RECOMMENDED that the administrator treat the wireless edge as
> the edge of the Diffserv domain and explicitly set (or
> reset) DSCP markings in the upstream direction according to administrativ=
e
> policy.
> - the discussion goes on to talk about an example with CS6 and CS7, there
> may be a case for admission control to this class - or at least this PHB =
- but the
> general comment of requesting rewriting of all codepoints goes against
> current practice as far as I can see, and also is most unhelpful.
>=20
> ---
> TEXT
> Suffice it to say that
> the security of the devices and networks implementing QoS, including QoS
> mapping between wired and wireless networks, SHOULD be considered in
> actual deployments.
> - I agree that you must protect operator infrastructure, and all people w=
ho
> use APs need to make decisions about which traffic to admit to the networ=
k
> at a particular QoS level. That does not mean I agree with thinking a dev=
ice
> need to remark all my traffic because it is not what you think is best to=
 cross a
> wireless/wired boundary."
>=20
> -------------------
>=20
> I look forward to learning more what others think on this,
>=20
> best wishes,
>=20
> Gorry Fairhurst
>=20
>=20
>=20


From nobody Wed May 31 23:18:26 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 1730C12EB26 for ; Wed, 31 May 2017 23:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 EkG5OyKllT6N for ; Wed, 31 May 2017 23:18:23 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CC5112EB22 for ; Wed, 31 May 2017 23:18:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4956; q=dns/txt; s=iport; t=1496297903; x=1497507503; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7NyYiWegBNruqrS3wESsJ4E6rxpVXvFB4AL1BxFRkGM=; b=QTTcFUcWbQZ+ulCDwI2ypOEHQYVvL2S8CBWWvJV+U7coUfrB8WdT/FCr DxFRqDah2n8VhSdBDYT/xSo45JTPKRBZjXhZLQtTSM/reGsurhybrgpZ2 rwlxOI4raMe9Ks6TvIyNp6CG6veKJk1XYvfPDN+KEFK3O+YYsZAowQDp3 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAABcsS9Z/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1eBbweOBZFziCmNUYIPhiQCgm8/GAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgE6PwwEAgEIEQQBAQEeCQchERQJCAIEDgUIigoDDQiuMIczDYQRAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYtggliBYQELBwGGDgWWeoZxOwGOUYRPkgGLNokfAR8?= =?us-ascii?q?4fwt0FYVMHIFjdocoDxeBDIENAQEB?=
X-IronPort-AV: E=Sophos;i="5.39,278,1493683200"; d="scan'208";a="34230863"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Jun 2017 06:18:22 +0000
Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v516ILK5023969 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2017 06:18:21 GMT
Received: from xch-rcd-010.cisco.com (173.37.102.20) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Jun 2017 01:18:21 -0500
Received: from xch-rcd-010.cisco.com ([173.37.102.20]) by XCH-RCD-010.cisco.com ([173.37.102.20]) with mapi id 15.00.1210.000; Thu, 1 Jun 2017 01:18:21 -0500
From: "Tim Szigeti (szigeti)" 
To: Fred Baker 
CC: "gorry@erg.abdn.ac.uk" , "tsvwg@ietf.org" , "Jerome Henry (jerhenry)" 
Thread-Topic: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
Thread-Index: AQHS051LwDLgd1DAnEe9GMav17WLLaID5vqAgABu4YD///HYEIAJVYMAgAH4XjA=
Date: Thu, 1 Jun 2017 06:18:21 +0000
Message-ID: <319a1a49ae9e45a4835ebbddc8c7cf05@XCH-RCD-010.cisco.com>
References: <5923F086.8030804@erg.abdn.ac.uk>   <5d3c37a54bfb4cfab699613e34b32a5f@XCH-RCD-010.cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.22.195]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [tsvwg] draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Jun 2017 06:18:25 -0000

Hi Fred,

Glad to hear your back from vacation.

A couple of comments inline...

> -----Original Message-----
> From: Fred Baker [mailto:fredbakersba@gmail.com]
> Sent: Tuesday, May 30, 2017 12:10 PM
> To: Tim Szigeti (szigeti)
> Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; Jerome Henry (jerhenry)
> Subject: Re: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
>=20
> I'm now back from vacation.
>=20
> Here's where our views seem to diverge. You argue that you are basing the
> comment about dropping CS6 on RFC 4594. What RFC 4594 says, however, is:
>=20
>    o  Drop or remark CS7 packets at ingress to DiffServ network domain.
>    o  CS7 marked packets SHOULD NOT be sent across peering points.
>       Exchange of control information across peering points SHOULD be
>       done using CS6 DSCP and the Network Control service class.
>=20
> It doesn't say to drop CS6, and the argument for dropping CS6 is that rou=
ting
> traffic is not exchanged on WiFi networks (which is the assumption I
> commented on).=20

[TS]=20
The context is very clearly limited to WiFi networks where the AP represent=
s the edge of the network, and not WiFi networks in general.

When the only devices downstream are end-user client devices, then routing =
protocols are not legitimately expected to be exchanged.=20

 > That is true today, but may not be true in the future. I think
> the assumption that routing traffic will never be exchanged on WiFi netwo=
rks
> is a dangerous assumption long term.

[TS]=20
We certainly don't think that. This is why the deployment model of wireless=
 networks that extend the IP infrastructure (and over which routing traffic=
 is legitimately exchanged) is clearly called out and addressed..

HTH clarify Fred.

-tim

>=20
> > On May 24, 2017, at 6:43 PM, Tim Szigeti (szigeti) 
> wrote:
> >
> > Hi Fred,
> >
> >> For CS7 (and any DSCP value not implemented in the domain) I would
> >> agree that it should be remarked or dropped. For CS6, recall that I
> >> have pointed out the assumptions that WiFi is the edge of the
> >> diffusers domain and has no IP layer routing across it. I think, and
> >> have said before that I think, that is a limiting assumption.
> >
> > Nothing is being assumed here Fred. Two distinct recommendations are
> being made:
> >
> > In the case where the wireless access-point represents the edge of the
> network (and thus simultaneously the edge of the Diffserv domain), then a
> recommendation is being made to remark or drop packets marked CS6 or CS7
> (as there are no downstream devices participating in network control
> exchanges, and preserving these markings presents an easy attack-vector f=
or
> WLAN DoS).
> >
> > In the deployment model where the wireless access-point is NOT the edge
> of the network, then this recommendation does not apply (as brought out i=
n
> Section 4.1.1).
> >
> > A single recommendation simply will not ensure secure and consistent Qo=
S
> treatment in both wireless deployment models.
> >
> > -tim
> >
> >
> >> -----Original Message-----
> >> From: fredbakersba@gmail.com [mailto:fredbakersba@gmail.com]
> >> Sent: Wednesday, May 24, 2017 2:28 PM
> >> To: Tim Szigeti (szigeti)
> >> Cc: gorry@erg.abdn.ac.uk; tsvwg@ietf.org; Jerome Henry (jerhenry)
> >> Subject: Re: draft-ietf-tsvwg-ieee-802-11-02 - editorial comments
> >>
> >> .The top-level observation (I'll follow-up with another email if
> >> needed about
> >>>> specific text) is that the latest revision discusses the way in
> >>>> which access points and wireless devices can change the DSCP
> >>>> marking or drop traffic because of the DSCP marking.
> >>>>
> >>>
> >>> I'd like to first stress the point that the remarking and dropping
> >> recommendations of network control traffic (marked CS6/CS7) at the
> >> edge of the wired-to-wireless network (as made in Section 4.1.1) were
> >> part of the original 2015 draft, and are not new recommendations in th=
is
> latest revision.
> >>>
> >>> Additionally, these recommendations are drawn from similar
> >> recommendations made in RFC 4594-Section 3.2 which:
> >>>
> >>> "RECOMMENDED that packets marked CS7  DSCP (a codepoint that
> SHOULD
> >>> be reserved for future use) be dropped  or remarked at the edge of
> >>> the Diffserv domain."
> >>>
> >>> Our argument is that when the wireless access point represents the
> >>> edge of the network infrastructure (and thus the edge of the
> >>> Diffserv domain), this recommendation should hold;
> >>
> >> For CS7 (and any DSCP value not implemented in the domain) I would
> >> agree that it should be remarked or dropped. For CS6, recall that I
> >> have pointed out the assumptions that WiFi is the edge of the
> >> diffusers domain and has no IP layer routing across it. I think, and
> >> have said before that I think, that is a limiting assumption.