Re: [aqm] Follow-up: PIE performance in cable modem environments

Preethi Natarajan <> Tue, 07 May 2013 23:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADC5D21F8EFD for <>; Tue, 7 May 2013 16:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.975
X-Spam-Status: No, score=-0.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9LkjBap-9lCy for <>; Tue, 7 May 2013 16:28:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::233]) by (Postfix) with ESMTP id 54C4021F8F03 for <>; Tue, 7 May 2013 16:28:27 -0700 (PDT)
Received: by with SMTP id wy7so761030pbc.38 for <>; Tue, 07 May 2013 16:28:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:user-agent:date:subject:from:to:message-id:thread-topic :in-reply-to:mime-version:content-type; bh=zpY4OaCPLi6PPpcpMA5KN27mT2wQ80oC6vBaZPSEqcM=; b=p7c4/euc9iEWfFjD7w40Qp+2fg/GiUe0sRh2OExwbKa5KMWzqIL8d9XV4sUV9Y6GiM 3Y/Cde/3P7C36Pind6A9qHheTkZZ5vLea/GBiOGvOX/uh1ZE9CHynfOm7nfTdxbNDy/e 7ChId060hl6DaaJtlMVNd0Fjk5GOEAoWJNFsNy/6vYGw0eBVzQGE3IElIx/2dyDkxZUb XhtlN0ewTKBasvO/8tRxo/FQW9lNNgbzgzthSCKnJqEKoNePEEzdLifCu+917EccvYyS tKjm/thOaXSn04A0M1p0gvQqr9cKS/Rt8AOAu3yJE616KjnZ1f9jR/eJ0ZGhqoQRqBnb dDQA==
X-Received: by with SMTP id zh7mr5270721pac.62.1367969307014; Tue, 07 May 2013 16:28:27 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id lq5sm32127103pab.19.2013. for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 07 May 2013 16:28:26 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Tue, 07 May 2013 16:28:21 -0700
From: Preethi Natarajan <>
To: Greg White <>, "" <>, "" <>, "Rong Pan (ropan)" <>
Message-ID: <>
Thread-Topic: [aqm] Follow-up: PIE performance in cable modem environments
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3450788905_47253895"
Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 May 2013 23:28:32 -0000

Hi Greg,

As other posts point out, the byte-mode operation has been around for a
while and it is not unique/new to PIE.

We weren't aware of Bob Briscoe's BCP draft until recently. We understand
the concerns mentioned here. In fact, we encountered the DropTail's
preferential treatment for small packets in our simulations (mentioned in
the BCP draft) and that was our motivation to  experiment with byte-mode.

We think that a good alternative to byte-mode would be ToS/DiffServe-field
based differential dropping, similar to WRED, since that would give similar
benefits as byte-mode. That way, we don't have to stick to byte-mode based
approach for PIE.

The PIE Team

From:  Greg White <>
Date:  Friday, May 3, 2013 3:55 PM
To:  Preethi Natarajan <>, ""
<>, "" <>
Subject:  Re: [aqm] Follow-up: PIE performance in cable modem environments


I did a diff on the new version of the PIE code vs the earlier release and
found, as you stated, that the basic algorithm hasn't changed.  I do see
some other improvements/changes though.  One which, I think, bears
discussion is the weighting of packet drops based on size.

In the new code there is the option (turned on in the simulations I reported
on in my paper) to drop packets according to p*pkt_size/mean_pkt_size where
p is the drop probability calculated by the PIE control law. This serves to
significantly decrease the drop probability of the small VoIP and gaming
packets, which may be sensitive to loss (from a QoE perspective) and
non-responsive to loss (from a congestion control perspective).  This is
evidenced by the low packet loss rate for gaming traffic that I reported in
my paper.

However, I worry that the unintended consequence may be that this weighting
incentivizes application developers toward the use of small packets, which
seems ill advised.



From: Preethi Natarajan <>
Date: Tuesday, April 30, 2013 5:48 PM
To: Greg White <>, Preethi Natarajan
<>, "" <>, ""
<>, "" <>
Cc: "Rong Pan (ropan)" <>, "Bill Ver Steeg (versteb)"
<>, "Chiara Piglione (cpiglion)" <>,
"Mythili Suryanarayana Prabhu (mysuryan)" <>, "Fred Baker
(fred)" <>, Dan Rice <>
Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments


Thank you Greg for the update and the link to the white paper.

We wanted to quickly clarify about how we tuned PIE for DOCSIS.

The basic PIE algorithm has not changed. We updated the simulation code with
the missing line mentioned below (which was a bug). The DOCSIS MAC layer has
this special nature of stop-and-go with 5ms-6ms request and grant delay.
This requires adjustment of any algorithm: for example  CoDel has to
increase its target delay from 5ms to a higher value. Similarly, our new
parameters are to make PIE adjust faster for the DOCSIS stop-and-go
behavior. Please note that eventually all these design parameters will be
automatically set, users of the PIE algorithm would not be required to set
any design parameters.

Again, many thanks for your update.
PIE team

From: Greg White <>
Date: Tuesday, April 30, 2013 3:54 PM
To: Preethi Natarajan <>, ""
<>, "" <>, ""
Cc: "Rong Pan (ropan)" <>, "Bill Ver Steeg (versteb)"
<>, "Chiara Piglione (cpiglion)" <>,
"Mythili Suryanarayana Prabhu (mysuryan)" <>, "Fred Baker
(fred)" <>, Daniel Rice <>
Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments

Additionally, I've re-run my suite of simulations using the updated PIE code
from Cisco.  The results (in much more detail than I presented at ICCRG) are
documented in a white paper available here:
Active Queue Management Algorithms for DOCSIS 3.0

Thanks to Preethi, Rong, et al. for debugging and tuning PIE to work well in
the cable environment, and for sharing the resulting code.

Best Regards,

From: Preethi Natarajan <>
Date: Tuesday, April 23, 2013 5:18 PM
To: "" <>, "" <>,
"" <>
Cc: "Rong Pan (ropan)" <>, "Bill Ver Steeg (versteb)"
<>, "Chiara Piglione (cpiglion)" <>,
"Mythili Suryanarayana Prabhu (mysuryan)" <>, "Fred Baker
(fred)" <>
Subject: [aqm] Follow-up: PIE performance in cable modem environments


This is a follow-up to Greg White's (from Cable Labs) talk at the recent
ICCRG meeting on PIE's performance in cable modem environments.

Post the meeting, Greg was kind to share his ns-2 DOCSIS model with us. We
investigated PIE's performance using this model. The key items from this
1. Bug in PIE code: The previous PIE release (that Greg used for
evaluations) was missing a line of code. This missing line brings down drop
probability under certain conditions and turns out to be critical for the
cable modem scenario. Without this line of code, the drop probability
remains high and takes longer to come down even when the queue delay has
remained lower than the reference. The updated ns-2 PIE code can be found
here ‹
2. Bug in ns-2 TCP/Linux: Greg's cable modem simulations used the TCP Cubic
variant. We discovered a serious bug in ns-2 TCP/Linux Agent (confirmed by
Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and
unresponsive to packet drops/notifications, pretty much like UDP traffic.
Please find more details about the bug here --
We are working with Cable Labs to verify the cable modem results, they'll
soon be available on our FTP site along with the PIE code.

A technical paper about PIE was recently accepted at the IEEE Conference on
High Performance Switching and Routing 2013. A copy of the paper is attached

The Linux PIE implementation is expected to be ready by next week and we'll
follow-up on that as well.

Many thanks,
Preethi on behalf of PIE team.