From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8DE9021F11C for ; Mon, 17 Jun 2013 12:40:53 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so7852323iea.39 for ; Mon, 17 Jun 2013 12:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WVLDH7rXKpeuLtcNVt0YtdjXYIJqWAjkFJGskAFLszs=; b=WXCq3vF7KlH1uibNxjdjQf7/s01Vz9hAOwJcJKT+65uu+9PESRAh0CYGEy/DgqekRq hg9Q7Y5Jlwd4fl3RmcJFds9P9yUqHsyiG23WfXdYHn+koNVbeTC4IxRBhkwoMyKkOAsb aBZbNftY52IxxwQ/1M0nEMuXJh345Bt9SqWXyd6mRidE4XberVaYCRTN0xjTVAuiG/Py j7xVqC/g2pURjFAQUQ9xB7BDgauc6WTGKpXmhKe/OVr1NJx0xqspWTChAYljq9Kf9WfW bh5vdGdsqnFz45k1LdwU+Xu761fsRJv4Gv1FsQFz4hy0EbSZ7W6ciUxxcSbPAUn59vvC DK2w== MIME-Version: 1.0 X-Received: by 10.50.56.50 with SMTP id x18mr5930280igp.87.1371498052899; Mon, 17 Jun 2013 12:40:52 -0700 (PDT) Received: by 10.64.45.137 with HTTP; Mon, 17 Jun 2013 12:40:52 -0700 (PDT) Date: Mon, 17 Jun 2013 12:40:52 -0700 Message-ID: From: Dave Taht To: tsvwg@ietf.org, bloat , iccrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Bloat] some comments on draft-ietf-tsvwg-byte-pkt-congest-10.txt X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:40:53 -0000 This draft "updates" RFC2309 which has already been obsoleted by one of it's original authors and a replacement draft ( http://tools.ietf.org/html/draft-baker-aqm-recommendation-00 ) is in progress. Be that as it may... This draft starts off on the wrong foot, and proceeds downhill rapidly. I am glad that someone is trying to update BCP for their current RED usage, but in general I think it is incorrect to extrapolate from RED's behavior to other behaviors in many cases, so... " This document provides recommendations of best current practice for dropping or marking packets using any active queue management (AQM) algorithm, such as random early detection (RED), BLUE, pre-congestion notification (PCN), etc. " By excluding DRR, SFQ, SQF, Codel, FQ_Codel, PIE and others, and attempting to generalize from experiences with RED to all AQM technologies, it does its potential readers a disservice. I'd change the first sentence to: " This document provides recommendations of best current practice for dropping or marking packets using the RED active queue management (AQM) algorithm, using packet drop and congestion notification" >From that, it is possible to generalize the following, although the backing argument is suspect, which I'll get into later... " We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) in the specific case of RED, the byte-mode packet drop variant that drops fewer small packets should not be used. " "This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms." as RFC2309 itself is being obsoleted, we're going around in circles here. Before tackling byte-pkt-congest-10 directly - a couple asides.. ...snip snip... RFC2309 refers to this 1994 paper: "On the Self-Similar Nature of Ethernet Traffic (Extended Version)" I would certainly like the model and analysis of this paper repeated against modern traffic patterns. Has anyone done this? I loved this paper when it came out.... last paragraph in section 2 of RFC2039 I heartily agree with " In short, scheduling algorithms and queue management should be seen as complementary, not as replacements for each other." And if we can agree that AQM = Active queue *length* management and can come up with a name for FQ+AQM hybrids that works for people (SQM - smart queue management?) so we know what we're talking about when talking about things, certain bits in section 3 get easier to deal with. Because of the overload on AQM I'm going to use SQM throughout what I write below. As one last general example of problems with rfc2039, some of the references are to protocols so ancient and non-deployed as to render the relevant arguments moot: " voice and video, and also multicast bulk data transport [SRM96]. If no action is taken, such unresponsive flows could lead to a new congestive collapse. In general, all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms. For example, recent research has shown the possibility of incorporating congestion avoidance mechanisms such as Receiver- driven Layered Multicast (RLM) within UDP-based streaming applications such as packet video [McCanne96] [Bolot94]. Further research and development on ways to accomplish congestion avoidance for streaming applications will be very important." It would be nice to have relevance to new stuff like webrtc in a new draft of some sort rather than to non-deployed 20 year old protocols. ...ok back to the pkt-congest draft... " Consensus has emerged over the years concerning the first stage: if queues cannot be measured in time, whether they should be measured in bytes or packets. Section 2.1 of this memo records this consensus in the RFC Series. In summary the choice solely depends on whether the resource is congested by bytes or packets." Measuring queues in time is totally feasible as shown by pie and codel, and implementations on weak hardware such as on mips. Last week I got fq_codel running on a raspberri pi and a beaglebone to no observable hit on cpu usage vs pfifo_fast... I'll do an arduino if that's necessary to make the point, harder. Anybody got a 68020 or slower to play with? So an alternative formulation that makes sense is: " When queues cannot be measured in time, should they be measured in bytes or packets? And dropping the rest of this: " Section 2.1 of this memo records this consensus in the RFC Series. In summary the choice solely depends on whether the resource is congested by bytes or packets." Moving on: " This memo updates [RFC2309] to deprecate deliberate preferential treatment of small packets in AQM algorithms. It recommends that (1) packet size should be taken into account when transports read congestion indications, (2) not when network equipment writes them. This memo also adds to the congestion control principles enumerated in BCP 41 [RFC2914]." s/AQM/the RED/g across the draft Still... to get to the meat of my own complaint with the draft and philosophy expoused within, I'll pull out two example paragraphs and try to make my argument.... "However, at the transport layer, TCP congestion control is a widely deployed protocol that doesn't scale with packet size. To date this hasn't been a significant problem because most TCP implementations have been used with similar packet sizes. But, as we design new congestion control mechanisms, this memo recommends that we should build in scaling with packet size rather than assuming we should follow TCP's example." "Although many control packets happen to be small, the alternative of network equipment favouring all small packets would be dangerous. That would create perverse incentives to split data transfers into smaller packets." packets were (at least originally) "a small group or package of anything", I view the incentives to create larger packets as *far, far, far, far more perverse* than the incentives to create smaller ones. There will always be header overhead, there will always be small signalling packets, and there will always be bulk data that can *always* be broken up into packets of smaller size, that gets in the way of more interactive data if the larger packets aren't broken up into packets of smaller size. In my talks of late, I toss a 64GB memory stick across the room at someone - wow! check out that bandwidth! 64GB/sec!! and then challenge someone to try and read the last byte from the file on it going sequentually) (hint, most USB sticks barely do 8MB/sec and you'll be waiting a looong time) If it were up to me I'd have held the internet's MTU to 574 bytes until everybody was running at greater than 1Mbit, and the ratio between the largest packet and smallest held to less than 10x1 for eternity. Big packets affect latency, badly. They are also subject to much higher potential rates of error. At 1500 bytes, header overhead, even with ipv6, is pretty minimal and few gains can be had by increasing it. Jumbo frames are barely accepted in very few circumstances, etc. So the argument and conclusions about larger packet sizes that permeates this document is the opposite of the argument I'd make, throughout. So, as one example: "6. Security Considerations This memo recommends that queues do not bias drop probability towards small packets as this creates a perverse incentive for transports to break down their flows into tiny segments. One of the benefits of implementing AQM was meant to be to remove this perverse incentive that drop-tail queues gave to small packets." I think the author has got the intended statement wrong ("away from" rather than "towards"?)... and my take on it is that the drop tail behavior towards small packets was indeed very desirable, and should be retained in an SQM, to keep latencies low on overload and create incentives for right-sizing packets in general as per their actual transport needs. "In summary, it says that making drop probability depend on the size of the packets that bits happen to be divided into simply encourages the bits to be divided into smaller packets. " YEA! " Byte-mode drop would therefore irreversibly complicate any attempt to fix the Internet's incentive structures." s/complicate/enhance/ The document refers to things like rfc5690 and I long ago lost hope for ECN. The document then makes some blanket statements that aren't backed by data (that I'm aware of) Section 6 " In practice, transports cannot all be trusted to respond to congestion. So another reason for recommending that queues do not bias drop probability towards small packets is to avoid the vulnerability to small packet DDoS attacks that would otherwise result. One of the benefits of implementing AQM was meant to be to remove drop-tail's DoS vulnerability to small packets, so we shouldn't add it back again." I am only aware of a few small packet attacks. (most UDP DNS attacks try to do amplification actuallly) A strict DDOS based on small packets can be made effective against drop tail and somewhat effective against RED. Most attacks I've looked at are actually MUCH less effective against a SQM like fq_codel, given the random hash and equal service guarantees. I would certainly like to take a hard look at the tools used to attack and create Robust RED, so everything in section 6 seems highly theoretical and needs proof. Lastly: section 5.2 needs to be thought about in the age of wireless, which is often TXOP-congested rather than either of the two problems identified, and is kind of pressing. "5.2. Bit- & Packet-congestible Network The position is much less clear-cut if the Internet becomes populated by a more even mix of both packet-congestible and bit-congestible resources (see Appendix B.2). This problem is not pressing, because most Internet resources are designed to be bit-congestible before packet processing starts to congest (see Section 1.1)."