From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by huchra.bufferbloat.net (Postfix) with ESMTP id 9B9D221F0E7 for ; Wed, 3 Apr 2013 11:14:51 -0700 (PDT) Received: from pirx.pps.jussieu.fr (bob75-6-82-238-73-9.fbx.proxad.net [82.238.73.9]) by smtp1-g21.free.fr (Postfix) with ESMTP id EA454940229; Wed, 3 Apr 2013 20:14:21 +0200 (CEST) Received: from localhost ([127.0.0.1] helo=pirx.pps.jussieu.fr) by pirx.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1UNSCs-0001dK-4o; Wed, 03 Apr 2013 20:14:46 +0200 Date: Wed, 03 Apr 2013 20:14:46 +0200 Message-ID: <87zjxfscq1.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Steffan Norberhuis In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: bloat@lists.bufferbloat.net 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, 03 Apr 2013 18:14:54 -0000 > - Is TCP using packet delay considered as part of the solution for > bufferbloat? Not on this list, apparently. However, there has been a fair amount of research on that approach in the late noughts. I'd suggest you search for papers on TCP Vegas, TCP-LP and LEDBAT. In particular, LEDBAT is very widely deployed as part of uTP. (Your students are probably using it right now for making a backup of their DVD collection.) > - What are the problems of TCP delay variants that keep it from > solving bufferbloat? The main issue is the so-called late joiner advantage: these algorithms tend to give an unfair advantage to flows that only joined when the network was already congested, as compared to older flows. I don't know if the issue has been solved yet, it's been some time since I last looked at that stuff. > - 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? Please be aware that they are not competitors: the two can coexist in the same network. I would say that there is consensus that AQM is necessary, and that delay-based congestion control is a nice thing to have for low-priority traffic (e.g. uTP). In other words, you cannot do without AQM, but that certainly doesn't mean there aren't people interested in deploying low-delay congestion control. -- Juliusz