From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4BF8621F20B for ; Mon, 22 Jun 2015 09:12:19 -0700 (PDT) Received: by obpn3 with SMTP id n3so33327521obp.0 for ; Mon, 22 Jun 2015 09:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Jd02t+sz2Gm/i1Yv9vDdE0IWnaXac0jbgZxO+Rbe4d0=; b=H/IssdUwWS38s6ClE62KoTVPbboNKg0YgUkA/2NrQBRIhU0bo6tFMj1Pnk/wyOQyJM uSmAWhDzu82XEjRMsqcELiym1mOKlnCFmJbdao/LcuMd7+3NLmbPLKKxz4R27jzTHX7J O4iJz1T1Bz9evRyYvAaIh1n4pLlbvvJ1C9jLSOfBRY1hXJWV+Pj0C8bG7ajqN1TP7AOv zNZrmeoIVOhF38FE4gs4OLA6SVZoBRMTNTdgJuwmirrbW1J0N2BpjntyIAh0wAaqnPYO 6TckvH2P8RXbspUysdLzmWC8115pz531GPVW1k1F0L5QgL7/0MtmU/65YI6WHJK1O1hH qHZQ== MIME-Version: 1.0 X-Received: by 10.202.216.138 with SMTP id p132mr24143787oig.133.1434989538863; Mon, 22 Jun 2015 09:12:18 -0700 (PDT) Received: by 10.202.105.129 with HTTP; Mon, 22 Jun 2015 09:12:18 -0700 (PDT) In-Reply-To: <87vbefn3el.wl-jch@pps.univ-paris-diderot.fr> References: <87vbefn3el.wl-jch@pps.univ-paris-diderot.fr> Date: Mon, 22 Jun 2015 09:12:18 -0700 Message-ID: From: Dave Taht To: Juliusz Chroboczek Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] TCP congestion detection - random thoughts 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: Mon, 22 Jun 2015 16:12:48 -0000 On Mon, Jun 22, 2015 at 8:55 AM, Juliusz Chroboczek wrote: > To add to what my honourable prelocutors have said, =C2=B5TP, which is us= ed by > modern BitTorrent implementations, uses the LEDBAT congestion control > algorithm, which is based on delay. The fact that LEDBAT is crowded out = by > Reno is a desirable feature in this case -- you do want your BitTorrent > traffic to be crowded out by HTTP and friends. > > https://en.wikipedia.org/wiki/LEDBAT Yep. I note that OWD is more desirable than RTT, particularly in modern asymmetric networks that have a ratio of up to down bandwidths of 1x10 or more. A lot of folk have treated that return path as inconsequential when it can actually be the biggest source of delay or be the most contested part of the path. After having much success in squashing torrent down to being invisible using classification in cake last week, I realized this morning that also putting the short acks into the same bin was perhaps not always the right thing as that hurt download throughput..... Perhaps stretch(ier) acks are feasible in ledbat/torrent? Or revisiting the packet size to shrink once again under contention? Reducing the number of flows? > > -- Juliusz > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast