From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a103.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A996E3CB35 for ; Thu, 19 Jul 2018 15:04:39 -0400 (EDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id BAFF93000EC1C; Thu, 19 Jul 2018 12:04:38 -0700 (PDT) Received: from kmnmbp.local (47-208-211-81.trckcmtc01.res.dyn.suddenlink.net [47.208.211.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 99C193000EC1B; Thu, 19 Jul 2018 12:04:38 -0700 (PDT) To: codel@lists.bufferbloat.net References: From: Kathleen Nichols Message-ID: <42959aa5-a266-bd75-a49b-38a726695f11@pollere.com> Date: Thu, 19 Jul 2018 12:04:38 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Codel] self tuning codel X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 19:04:39 -0000 On 7/18/18 3:42 PM, Dave Taht wrote: > there's so much math in this that I cannot make heads or tails of it. > > https://www.eee.hku.hk/~kcleung/papers/conferences/bufferbloat_multi-bott= leneck:INFOCOM_2018/PID5170809.pdf > Dave, I would never presume to critique math in a paper co-authored by Steve Low, but I wonder about the model/premise of this work (quotes are taken directly from the paper so I don't misrepresent anything): > We consider TCP > Reno in our model since it is one of the most popular TCP > algorithms and our analysis in this paper mainly focuses on > AQM algorithms. I think the paper constructs bottlenecks as places where the arrival rate exceeds the departure rate? Then, there is this: > The essential idea of Algorithm 1 is that every AQM router > needs to know all the packet dropping probabilities at the > bottleneck links in order to compute the window sizes of the > flows from (5). In fact, Algorithm 1 is motivated by the widely > used Open Shortest Path First (OSPF) routing protocol [17]. > In OSPF, there is a designated router (DR) for every network > segment, which is responsible for gathering and forwarding > link state updates. Thus, we let a specific AQM router serve > as a centralized DR in the system. All routers send packet > dropping probability updates to DR. DR then updates its list > of packet dropping probabilities and sends it to all routers Does this seem possible to anyone? There's an inherent assumption here that "dropping probabilities" are constant over a period of time that is long compared to the time to do the above. In what I've seen of traffic and AQMs this seems unlikely but I'm certainly not as well-informed on this as some people. I have suggested that the setting of interval might be something to examine (that is to be adaptable in some way) from the beginning. So it's nice to see someone take a cut at this but I'm not sure the basic notion, that the interval is supposed to be giving the end hosts enough time to respond to a drop, has been retained here. > From (34), we observe that the range of I0 is determined by > several factors and will vary if these factors change over time. > A static value of I0 cannot always guarantee the stability of > the TCP/CoDel system. Thus, we propose Self-tuning CoDel > to dynamically adjust I0 for CoDel at every bottleneck link > based on network conditions, as shown in Algorithm 2. Of course, the big problem is that the time to respond, or RTD, is going to be different for every communicating pair and will increase with congestion. This seems like a pretty hard problem to solve *optimally* and I don't see how this contributes to a solution since its model is pretty simple compared to what is seen in the Internet today. > In this subsection, we present ns-2 simulation results to > demonstrate that our proposed Self-tuning CoDel can effectively > improve the system stability and performance. We use > TCP Reno as the source algorithm, and compare Self-tuning > CoDel with CoDel and PIE, which are two popular modern > AQM algorithms, in terms of the stability of queueing delay So that's all I could find about the simulation model. It *appears* (but I won't put words in anyone's mouth, I sure hate it when folks do that to me) these are a bunch of "forever" Reno TCP flows. There are a lot of really bad ns-2 TCP models out there. And it is really hard to get simulations to resemble the traffic patterns I've seen in packet traces from the Real World. I had to look twice to see this was published in 2018. What? I also wonder about the notion of "stability" of queue delays. I would expect a healthy system to have spikes in delay but not persistent delay. But I'm willing to entertain other viewpoints. So, there IS a lot of math I don't understand and stuff I might understand if I took the time, so I just look at the un-mathy stuff and try to figure out what is the purpose of this work? How does it apply? Kathie