[secdir] SecDir review of draft-ietf-aqm-pie
Warren Kumari <warren@kumari.net> Mon, 02 May 2016 16:31 UTC
Return-Path: <warren@kumari.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E3D12D586 for <secdir@ietfa.amsl.com>; Mon, 2 May 2016 09:31:59 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9yJM6B8dFyH for <secdir@ietfa.amsl.com>; Mon, 2 May 2016 09:31:57 -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 A98A612D581 for <secdir@ietf.org>; Mon, 2 May 2016 09:31:56 -0700 (PDT)
Received: by mail-qk0-x22e.google.com with SMTP id r184so76889090qkc.1 for <secdir@ietf.org>; Mon, 02 May 2016 09:31:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=x/D6urV9ZXBi3theapQl5muwQy3zf5Gn6lJZZirU02c=; b=UVxrK46P5M0FIoMqpdBkbkZ7zSME3+M0b48b3OlX0WKu7belMntHAQOJyGBZ6R26/g CZmbTyRGM/N0sRPWg9uvxsmd5fJAJ50IjNvSOnQUg3yHD4T5Tih6uMBycnjyCTYEedi+ 4pk+YG0qNoVRCyfpVjmONRjINNH9rYcfTIQNzeBKrSJM+qdI0FT4emZUIdULkPio+EkI jk9d04RNLxOQWGd9K95gYRuUHsPjEBE/UmPhbE9oGBUYh/diWsQMoOaAYBYirrWKv6B9 me2bllw6BB+wmLWg3M0rdcOwBDMjaZgcdxRDT2NI3irJVadTRGOn3kefsNJ+kgUi06uZ 99rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=x/D6urV9ZXBi3theapQl5muwQy3zf5Gn6lJZZirU02c=; b=VnXufXNoLeZ73meQ18ysIeZHLtaxhuoatGS7gBI/IJskPDHSQC756+lYpMK+6GQMyT YwxGGAaxZUPy5OLoBPEOAJpnK1J99+QyrQJakLWV+nLqmei/PsMlp1ZrosqmI4xgMOs6 bHPIh76DFzRUjg1rZc4NlBsYDQkTWYI3inTOaaPdoR+ItctHQdEPSC6tKw2VwetTl1vh vMtsbPIbdvNbalGIXLzzYcQwWYis6+ywavlR8EyF5V5w/Qyh+tpjiYq3GMadtj3Bl+VC JCXvJRn2QG0cDRBTx70Bx+F1kNMpmTmsSXLuGDvdgAS+wLXd65W+v2keAyCADqF7Ivjb 1QUg==
X-Gm-Message-State: AOPr4FVOTB+0HcTVCgAf+3Y6zVMPf2w4d99b0sNfWrTJaQLRjgcrmYdAunZbFM0bUq5PKOBI1/YGN7pF/tLNDZhr
X-Received: by 10.55.168.195 with SMTP id r186mr35129244qke.24.1462206715563; Mon, 02 May 2016 09:31:55 -0700 (PDT)
MIME-Version: 1.0
From: Warren Kumari <warren@kumari.net>
Date: Mon, 02 May 2016 16:31:46 +0000
Message-ID: <CAHw9_iJfoq-xdQxdB6M=NQ0Xp+ip-BBRqRYRH9dA4caKJH4o2A@mail.gmail.com>
To: IETF Security Directorate <secdir@ietf.org>, draft-ietf-aqm-pie.all@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="001a114d3280df16710531de87c6"
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/gzPQgo3_IxGTQcfuLVYV8yO8WbY>
Subject: [secdir] SecDir review of draft-ietf-aqm-pie
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2016 16:31:59 -0000
Be ye not afraid... I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Version reviewed: draft-ietf-aqm-pie-06 - PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem Summary: LGTM, Security AD attention not required. Details: No major issues, some nits. Feel free to integrate or ignore. Notes: >5 authors. Many of the authors are experienced, so they probably already know the RFC Ed might make sad face at you. Comments in [O]riginal, [P]roposed, [R]eason. Abstract Bufferbloat is a phenomenon where excess buffers in the network cause [O] phenomenon where excess [P] phenomenon in which excess [R] grammar high latency and jitter. As more and more interactive applications [SNIP] There is a pressing need to design intelligent queue management schemes that can control latency and jitter; and hence provide desirable quality of service to users. [O] jitter; and hence [P] jitter, and hence [R] grammar [SNIP] The design does not require per-packet timestamp, so it incurs very small overhead and is [O] require per-packet timestamp, [P] require per-packet timestamps, [R] grammar [O] incurs very small overhead [P] incurs very little overhead [R] word choice 1. Introduction The explosion of smart phones, tablets and video traffic in the Internet brings about a unique set of challenges for congestion control. To avoid packet drops, many service providers or data center operators require vendors to put in as much buffer as possible. With rapid decrease in memory chip prices, these requests are easily [O] With rapid decrease in memory chip price, [P] Because of the rapid decrease in memory chip prices, accommodated to keep customers happy. While this solution succeeds in assuring low packet loss and high TCP throughput, it suffers from a major downside. The TCP protocol continuously increases its sending rate and causes network buffers to fill up. TCP cuts its rate only when it receives a packet drop or mark that is interpreted as a congestion signal. However, drops and marks usually occur when network buffers are full or almost full. As a result, excess buffers, initially designed to avoid packet drops, would lead to highly elevated queueing latency and jitter. It is a delicate balancing act to design a queue management scheme that not only allows short-term burst to smoothly pass, but also controls the average latency in the presence of long-running greedy flows. [O] It is a delicate balancing act to design a queue management scheme that not only allows short-term burst to smoothly pass, but also controls the average latency in the presence of long-running greedy flows. [P] Designing a queue management scheme that allows short-term bursts to pass smoothly as well as controlling the average latency in the presence of long-running greedy flows is a delicate balancing act. [R] readability [SNIP] New algorithms are beginning to emerge to control queueing latency directly to address the bufferbloat problem [CoDel]. Along these lines, PIE also aims to keep the benefits of RED: such as easy [O] the benefits of RED: such as easy [P] the benefits of RED, including easy [R] readability and grammar implementation and scalability to high speeds. Similar to RED, PIE randomly drops an incoming packet at the onset of the congestion. The congestion detection, however, is based on the queueing latency instead of the queue length like RED. [SNIP] In October 2013, CableLabs' DOCSIS 3.1 specification [DOCSIS_3.1] mandated that cable modems implement a specific variant of the PIE design as the active queue management algorithm. In addition to cable specific improvements, the PIE design in DOCSIS 3.1 [DOCSIS-PIE] has improved the original design in several areas, including de- randomization of coin tosses and enhanced burst protection. This draft separates the PIE design into the basic elements that are MUST to be implemented and optional SHOULD/MAY enhancement elements. [O] that are MUST to be implemented [R] This is awkward, but maybe should be left as is? Or delete "are"? 4. The Basic PIE Scheme As illustrated in Fig. 1, PIE conceptually comprises three simple MUST [O] PIE conceptually comprises three simple [P] PIE is comprised of three simple [R] I think this is what is meant -- PIE is made of three MUST components, not PIE makes those three components? components: a) random dropping at enqueueing; b) periodic drop probability update; c) latency calculation. [SNIP] 5.2 Departure Rate Estimation One way to calculate latency is to obtain the departure rate. The draining rate of a queue in the network often varies either because other queues are sharing the same link, or the link capacity fluctuates. [O] because other queues are sharing the same link, or the link capacity fluctuates. [P] because other queues are sharing the link or because the link capacity fluctuates. [R] clarity 9. Security Considerations This document describes an active queue management algorithm based on implementations in Cisco products. This algorithm introduces no specific security exposures. 10. IANA Considerations There are no actions for IANA. -- END --
- [secdir] SecDir review of draft-ietf-aqm-pie Warren Kumari
- Re: [secdir] SecDir review of draft-ietf-aqm-pie Rong Pan (ropan)