From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by huchra.bufferbloat.net (Postfix) with ESMTP id 28BD921F150 for ; Wed, 20 Mar 2013 09:12:53 -0700 (PDT) Received: from [IPv6:2001:470:96b9:1:14cb:af2e:2e24:2838] (ibis.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:1:14cb:af2e:2e24:2838]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 02A9D4C49A0 for ; Wed, 20 Mar 2013 17:12:51 +0100 (CET) Message-ID: <5149E002.6030901@net.t-labs.tu-berlin.de> Date: Wed, 20 Mar 2013 17:12:50 +0100 From: Oliver Hohlfeld User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: bloat@lists.bufferbloat.net References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Bloat] Solving bufferbloat with TCP using packet delay 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: Wed, 20 Mar 2013 16:12:53 -0000 Steffan, > I also subscribed to this mailinglist and see alot of proposed > solutions to be AQM. Well, AQM is one possible answer. While AQM is discussed for years, it never found widespread deployment. Proper RED configuration was close to black magic. Based on preliminary results, Codel seems a promising candidate to bring AQM back into the game (at least for edge routers). However, the most basic fix is reducing the buffer size in exacerbated buffer configurations (bufferbloat is mostly a problem in the edge. Buffers in the core are often reasonably sized). When buffers can not be changed, AQM provides a good fix. Another aspect is managing congestion in the network (e.g., by QoS mechanisms). We recently investigated the problem from the perspective of end-users (see [1]) and found congestion to be a key aspect that reduces user satisfaction. [1] BufferBloat: How Relevant? A QoE Perspective on Buffer Sizing. http://downloads.ohohlfeld.com/paper/bufferbloat-qoe-tr.pdf > But hardly any talk about solving buffer bloat by using a TCP variant > that that uses packet delay as a way to determine the send rate. We did > not come across any papers that argue that these TCP variants are not a > good solution. I do have a few concerns: - There is no flag day that would make users switch to new TCP variants. There are plenty of TCP flavors used already. How would you ensure deployment of a delay sensitive variant? - While TCP traffic is dominant in the Internet's traffic mix, many real-time (or delay sensitive) applications use UDP. In these cases, your fix would not apply. > In our view AQM needs alot of new hardware to be implemented and > a TCP variant would perhaps be easier to implement and is also able to > solve bufferbloat. Think also about the widespread deployment of a new TCP variant. How easy is it to get an TCP update deployed on all the different software stacks that are out there? To me, it appears to be practically infeasible. > So I have a few questions I would like to ask you: > - Is TCP using packet delay considered as part of the solution for > bufferbloat? > > - What are the problems of TCP delay variants that keep it from solving > bufferbloat? > > - What are the drawbacks of the TCP delay variants that would favor AQM > over TCP? > > - What are the advantages of TCP delay varaints that would favor TCP > over AQM? Sounds like a nice research problem. I'd love to see an extensive evaluation on this. Oliver