From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <swmike@swm.pp.se>
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by lists.bufferbloat.net (Postfix) with ESMTPS id A95693B25E
 for <cerowrt-devel@lists.bufferbloat.net>;
 Wed, 21 Sep 2016 06:15:16 -0400 (EDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501)
 id 67E44A3; Wed, 21 Sep 2016 12:15:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail;
 t=1474452915; bh=S6ow2bkQMXAz3GnddjhorT8eodECQmnV8GjQ7Fg22XE=;
 h=Date:From:To:cc:Subject:In-Reply-To:References:From;
 b=mpch/yHvyI9kaN7rqYDrpKPCFaX4M0UoUhNyj9pdrskRS6dPcS6nxgDFVVai62qhc
 4W6N6gxsQSi2NRwlkzNomoCttmkSVIRbkFdEAjJMMw1xxqrsl8CNVAJjVB6xZP9ECV
 KdVyUUyi0die0GGb4O8DV9J12gB+xJPUDRfMqzi0=
Received: from localhost (localhost [127.0.0.1])
 by uplift.swm.pp.se (Postfix) with ESMTP id 5E6B4A2;
 Wed, 21 Sep 2016 12:15:15 +0200 (CEST)
Date: Wed, 21 Sep 2016 12:15:15 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Dave Taht <dave.taht@gmail.com>
cc: "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
In-Reply-To: <CAA93jw5hR7bjxYNgzWQOSAtKWG+0oUGLFk+dmvmSMgkx5YTzuA@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1609211210280.1477@uplift.swm.pp.se>
References: <CAMZR1YDj_QB3sE1VXbn0GCUYF072x-E2DFVXSAKSgW1uTja_OQ@mail.gmail.com>
 <CAA93jw4+oTz00qvScSOyDmQyeEfhoYs__cB_1LJ-AZDHymUfkQ@mail.gmail.com>
 <92a6ae25-530f-1837-addd-8a9ef07dd022@gmail.com>
 <CAA93jw5hR7bjxYNgzWQOSAtKWG+0oUGLFk+dmvmSMgkx5YTzuA@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: Re: [Cerowrt-devel] BBR congestion control algorithm for TCP in
 net-next
X-BeenThere: cerowrt-devel@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Development issues regarding the cerowrt test router project
 <cerowrt-devel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/cerowrt-devel>,
 <mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/cerowrt-devel>
List-Post: <mailto:cerowrt-devel@lists.bufferbloat.net>
List-Help: <mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/cerowrt-devel>,
 <mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2016 10:15:16 -0000

On Wed, 21 Sep 2016, Dave Taht wrote:

> I dunno, I'm just reading tea leaves here!
>
> can't wait for the paper!

+1.

I would like to understand how BBR interacts with a window-fully-open 
classic TCP session and FIFO induced delay that is in steady-state before 
the BBR session starts.

So let's say I have 100ms of lightspeed-in-fiber RTT, and I am then 
running a file transfer with some other TCP algorithm which is sitting 
there, window fully open, creating an additional 100ms of 
stupid-router-FIFO-buffering delay.

So new BBR TCP session comes along, sees 200ms of RTT, and starts sending. 
I guess the classic TCP algorithm still keeps its window fully open, and 
doesn't care that RTT now increased to 210ms by the BBR flow packets.

Now what? BBR flow sees increased latency, and backs off, right? So how 
much of the bandwidth will each flow get? How do these interact?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se