From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (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 E6D0E21F1A1 for ; Tue, 9 Jul 2013 12:10:49 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so5778251pbc.7 for ; Tue, 09 Jul 2013 12:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:x-mailer:content-transfer-encoding:mime-version; bh=3MWs7ZjySVLZayxKRynVqAcKDVHV79bNcLJtVd0xSDU=; b=Nn+0bOQrCNFy/N5A4U0fcCDLP29+hnCbW9c6fHsfsFnYGpJljFCEEGPxmOBzBRO9pS +Z8p8MGfJjOeu8zT0jC44lJw6eVsmCpE9X9U+73vg9uDJaX2G1+55/zz13wssg+BKVo8 Kmzripc65Ba0bFoVgpEBvoXBP4QPPpoLTlivGzNp3IlROnyddx5NwmUl0bhZbeuV47RU OG7DSUkb5ciJSbf3RkpShgEmhf1B4PneksFod3HpGLXbbNL75+OXg60hNdMQmeK3fZ1o DLxkg4rhugrheQ1qDa9sLp+o59fNW7peorOKUuRdfleaH2G40jTb407tCRBOgxtX59c2 4q1g== X-Received: by 10.68.103.228 with SMTP id fz4mr27953123pbb.101.1373397049462; Tue, 09 Jul 2013 12:10:49 -0700 (PDT) Received: from ?IPv6:2620:0:1000:3304:919d:c6e6:e51a:dab0? ([2620:0:1000:3304:919d:c6e6:e51a:dab0]) by mx.google.com with ESMTPSA id rb1sm17185873pbb.29.2013.07.09.12.10.48 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 12:10:49 -0700 (PDT) Message-ID: <1373397048.4979.187.camel@edumazet-glaptop> From: Eric Dumazet To: Jaume Barcelo Date: Tue, 09 Jul 2013 12:10:48 -0700 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] sweet tcp 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: Tue, 09 Jul 2013 19:10:50 -0000 On Tue, 2013-07-09 at 19:38 +0200, Jaume Barcelo wrote: > Hi, > > I was explaining the bufferbloat problem to some undergrad students > showing them the "Bufferbloat: Dark Buffers in the Internet" paper. I > asked them to find a solution for the problem and someone pointed at > Fig. 1 and said "That's easy. All you have to do is to operate in the > sweet point where the throughput is maximum and the delay is minimum". > > It seemed to me that it was a good idea and I tried to think a way to > force TCP to operate close to the optimal point. The goal is to > increase the congestion window until it is larger than the optimal > one. At that point, start decreasing the congestion window until is > lower than the optimal point. > > To be more specific, TCP would be at any time increasing or decreasing > the congestion window. In other words, it will be moving in one > direction (right or left) along the x axis of Fig. 1 of Getty's paper. > Each RTT, the performance is measured in terms of delay and > throughput. If there is a performance improvement, we keep moving in > the same direction. If there is a performance loss, we change the > direction. > > I tried to explain the algorithm here: > https://github.com/jbarcelo/sweet-tcp-paper/blob/master/document.pdf?raw=true > > I am not an expert on TCP, so I decided to share it with this list to > get some expert opinions. Are you familiar with existing delay based algorithms ? A known one is TCP Vegas. Problem is that it would work well only if all flows would use it. Alas, lot of flows (or non flows traffic) will still use Reno/cubic (or no congestion at all) and they will clamp flows that are willing to reduce delays. So that's definitely not 'easy' ...