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

On Fri, May 3, 2013 at 3:55 PM, Greg White <g.white@cablelabs.com> wrote:
> Preethi,
>
> 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.
>
> Thoughts?

Optimizing a little bit for smaller packets is an old trick that goes
back to wondershaper, and most likely prior.

Personally, I'd have liked it if the internet MTU had stayed below 580
until the world was running universally at above 4Mbits.

As for how PIE does it, I haven't got the linux sources yet, so I
haven't looked at it.

the *fq_codel settings used in your study used a quantum of 300, which
has much the same effect as however PIE is doing it, most likely.

You can quibble as to how much to de-optimize for big packets, but it
is generally a fairly reliable indicator of bulk vs ack or interactive
traffic,
and optimizing for the smaller packets is very useful on asymmetric
low speed uplinks. It seems like an increasingly less useful
optimization as speeds get higher and higher.

There are some newer interactive protocols (videoconferencing comes to
mind) where packet sizes of larger than 300 bytes seem possible, and
DNSSEC bloats up dns packets - but for the vast majority of other
sorts of traffic, acks, syns, normal dns, dhcp, voip, gaming, etc,
optimizing for size a little bit is a win.

As for disincentivizing the use of big packets, there are plenty of
reasons for bulk transfers to try and send the biggest packet
possible, and even if an app did start sending smaller packets the
per-packet overhead of IP is increasingly trivial above 300 bytes, and
in general smaller packets are better for the sharing of the network,
anyway...

>From wikipedia:

"When data is formatted into packets, the bitrate of the communication
medium can be better shared among users than if the network were
circuit switched."

>
> -Greg
>
>
>
> From: Preethi Natarajan <preethi.cis@gmail.com>
> Date: Tuesday, April 30, 2013 5:48 PM
> To: Greg White <g.white@cablelabs.com>, Preethi Natarajan
> <preethi.cis@gmail.com>, "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org"
> <tsvwg@ietf.org>, "aqm@ietf.org" <aqm@ietf.org>
> Cc: "Rong Pan (ropan)" <ropan@cisco.com>, "Bill Ver Steeg (versteb)"
> <versteb@cisco.com>, "Chiara Piglione (cpiglion)" <cpiglion@cisco.com>,
> "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker
> (fred)" <fred@cisco.com>, Dan Rice <d.rice@cablelabs.com>
>
> Subject: Re: [aqm] Follow-up: PIE performance in cable modem environments
>
> Hi,
>
> 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 <g.white@CableLabs.com>
> Date: Tuesday, April 30, 2013 3:54 PM
> To: Preethi Natarajan <preethi.cis@gmail.com>, "iccrg@irtf.org"
> <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "aqm@ietf.org"
> <aqm@ietf.org>
> Cc: "Rong Pan (ropan)" <ropan@cisco.com>, "Bill Ver Steeg (versteb)"
> <versteb@cisco.com>, "Chiara Piglione (cpiglion)" <cpiglion@cisco.com>,
> "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker
> (fred)" <fred@cisco.com>, Daniel Rice <D.Rice@CableLabs.com>
> 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,
> Greg
>
> From: Preethi Natarajan <preethi.cis@gmail.com>
> Date: Tuesday, April 23, 2013 5:18 PM
> To: "iccrg@irtf.org" <iccrg@irtf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>,
> "aqm@ietf.org" <aqm@ietf.org>
> Cc: "Rong Pan (ropan)" <ropan@cisco.com>, "Bill Ver Steeg (versteb)"
> <versteb@cisco.com>, "Chiara Piglione (cpiglion)" <cpiglion@cisco.com>,
> "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan@cisco.com>, "Fred Baker
> (fred)" <fred@cisco.com>
> Subject: [aqm] Follow-up: PIE performance in cable modem environments
>
> Hello,
>
> 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
> investigation:
>
> 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 —
> ftp://ftpeng.cisco.com/pie/.
> 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 --
> http://sourceforge.net/tracker/?func=detail&aid=3608750&group_id=149743&atid=775392.
>
> 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
> here.
>
> 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.
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html