From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jneilm@gmail.com>
Received: from mail-vw0-f43.google.com (mail-vw0-f43.google.com
	[209.85.212.43]) (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 1CC5D200629
	for <bloat@lists.bufferbloat.net>; Sun,  5 Feb 2012 09:53:56 -0800 (PST)
Received: by vbbfq11 with SMTP id fq11so6334617vbb.16
	for <bloat@lists.bufferbloat.net>; Sun, 05 Feb 2012 09:53:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	bh=NC+zooueDXP5RIXF2ON/te4y/6AwU9US+ubQW+OPc1A=;
	b=Xc/PBqa+kFWj1dmpq9aen4+PM3NHUUJVee8GDbJkiIFBdn/QOK7vcolzHZX2c2BU2S
	3it5pFpVmNT0o8BYil+nAkX40IrSQR9hjnKGjFNbL5FcJELMTbzUoDZyzCLV91bgOeIO
	zG24LeN2wU2VcQsWeWgNlNQ8Luc7I1yxGXl+o=
MIME-Version: 1.0
Received: by 10.52.26.97 with SMTP id k1mr6744475vdg.35.1328464435766; Sun, 05
	Feb 2012 09:53:55 -0800 (PST)
Received: by 10.52.165.165 with HTTP; Sun, 5 Feb 2012 09:53:55 -0800 (PST)
In-Reply-To: <1328427596.14474.9.camel@edumazet-laptop>
References: <CAA93jw7xHNZeT-nvk63fKEwfTSO+9e_8JfOqcmjyALkcK_gPnA@mail.gmail.com>
	<1325481751.2526.23.camel@edumazet-laptop>
	<CAA93jw7xUdAmtnXdr0n76sz76yFiYV687H9PNPh437JVbo8J6g@mail.gmail.com>
	<CAA93jw6N5nwJROMUd1v3eLP3dnBH0NTaUuJOA-QT8AKQg9c+zg@mail.gmail.com>
	<4F046F7B.6030905@freedesktop.org>
	<CAJ2iOjTd989geZzSopO8i5A--0yM_CsDrBH_bFXBNCJwCidm=Q@mail.gmail.com>
	<40C8C302-7B23-4272-8322-1D916BB0CEB2@gmail.com>
	<1328427596.14474.9.camel@edumazet-laptop>
Date: Sun, 5 Feb 2012 12:53:55 -0500
Message-ID: <CAFkTFa8cKedGjZBYwvfc-TJbAzEoEaQ5OXktc3EmiWHjhGsXtg@mail.gmail.com>
From: Justin McCann <jneilm@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] What is fairness,
	anyway? was: Re: finally... winning on wired!
X-BeenThere: bloat@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: General list for discussing Bufferbloat <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
	<mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Sun, 05 Feb 2012 17:53:57 -0000

On Sun, Feb 5, 2012 at 2:39 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote=
:
> Le dimanche 05 f=E9vrier 2012 =E0 02:43 +0200, Jonathan Morton a =E9crit =
:
>> 2) Implement TCP *receive* window management. =A0This prevents the TCP
>> algorithm on the sending side from attempting to find the size of the
>> queues in the network. =A0Search the list archives for "Blackpool" to
>> see my take on this technique in the form of a kernel patch. =A0More
>> sophisticated algorithms are doubtless possible.
>>
> You can tweak max receiver window to be really small.
>...
> Basically you can delay some flows, so that TCP acks are also delayed.

I was thinking of suggesting this (delaying ACKs to avoid cwnd
increase), but doesn't that simply increase the RTT and/or RTT
variance, and basically do the same thing we're trying to avoid? I
suppose you could delay a bit, and then drop some earlier ACKs in case
the sender only increases cwnd per ACK (and not by the number of
segments the ACK covers), but that per-ACK behavior just seems like a
bug to me.

      Justin