[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 --