From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <chromatix99@gmail.com>
Received: from mail-vn0-x232.google.com (mail-vn0-x232.google.com
	[IPv6:2607:f8b0:400c:c0f::232])
	(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 6C95821F284;
	Thu, 30 Apr 2015 07:38:08 -0700 (PDT)
Received: by vnbg7 with SMTP id g7so7409596vnb.11;
	Thu, 30 Apr 2015 07:38:05 -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;
	bh=H4hYweOhT3qm0VV4AM+QU60lmP5Ev30tVinSlm4Rkvs=;
	b=YjkhcBw+lQXj0wm46QqiZTcWiJGrPVgh6DRgeF0UFtDmnoC4rFu9Fk9X1VbUK+0TXt
	NAiFfQW1uQGaFYhmSPKFbFdRWgLvEGpI0ku5pefPLAFaxkCCdl1QKNk/ttdTzCiuu7i3
	NSZ3jCw8yWUxu5vXZLvd5eA3rmyYfjIoWe6dWt5WS6+Kv78cSJIhTfFnwMqciokrBhk/
	t4Dx4UVx8bPeOF3nla1HQ8jvDE2KnOWf3wKs7mX4ru0NdTGhrnTVZ36TzvU5+tbj1zeO
	8FGaIHbPsDynJANDs4wZ4hK144qtsvCD2QypcTjWv3uOS4epZ+LWH4deGI6Mr592cOLL
	HPWA==
MIME-Version: 1.0
X-Received: by 10.52.251.107 with SMTP id zj11mr8164605vdc.96.1430404685459;
	Thu, 30 Apr 2015 07:38:05 -0700 (PDT)
Received: by 10.52.12.167 with HTTP; Thu, 30 Apr 2015 07:38:05 -0700 (PDT)
Received: by 10.52.12.167 with HTTP; Thu, 30 Apr 2015 07:38:05 -0700 (PDT)
In-Reply-To: <CAA93jw4ax3c+Ak7Rn4zvzZPFJWu6V5HL3q8Nx2vUvfBvXOM4Pg@mail.gmail.com>
References: <CAA93jw7eDmjBreiB0BFysMmi85_zX_QiDsfGywiGN+r4c5snug@mail.gmail.com>
	<CAJq5cE3Tnb2002MTaiGaY-7P9sdZ0AQd36-zDMynGfzf_EWwaQ@mail.gmail.com>
	<CAA93jw4ax3c+Ak7Rn4zvzZPFJWu6V5HL3q8Nx2vUvfBvXOM4Pg@mail.gmail.com>
Date: Thu, 30 Apr 2015 17:38:05 +0300
Message-ID: <CAJq5cE0scZvJqqoRSQ+LF3BZqVk+EZX4xz3-ZVrA_U2-yd4Qjw@mail.gmail.com>
From: Jonathan Morton <chromatix99@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134d45e2976080514f20b98
Cc: cake@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net"
	<cerowrt-devel@lists.bufferbloat.net>, bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Cake] documentation review request and out of
 tree cake builds for openwrt/etc.
X-BeenThere: cerowrt-devel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
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: Thu, 30 Apr 2015 14:38:39 -0000

--001a1134d45e2976080514f20b98
Content-Type: text/plain; charset=UTF-8

It took me a while to get around to thinking about this, partly because my
phone inexplicably refuses to believe snapon exists.

I have two possible explanations for these results. Maybe both apply to
some extent.

Dropping packets rather than marking them results in an increase in ack
density in the reverse direction, because delayed acks get temporarily
disabled. The strength of this effect depends on the BDP and the depth of
delayed acks.

Increasing the number of simultaneous flows might increase the CPU load of
connection tracking for NAT. Are you shaping and doing NAT on the same box?
I think this might be the basic reason for increased latency.

- Jonathan Morton

--001a1134d45e2976080514f20b98
Content-Type: text/html; charset=UTF-8

<p dir="ltr">It took me a while to get around to thinking about this, partly because my phone inexplicably refuses to believe snapon exists.</p>
<p dir="ltr">I have two possible explanations for these results. Maybe both apply to some extent.</p>
<p dir="ltr">Dropping packets rather than marking them results in an increase in ack density in the reverse direction, because delayed acks get temporarily disabled. The strength of this effect depends on the BDP and the depth of delayed acks.</p>
<p dir="ltr">Increasing the number of simultaneous flows might increase the CPU load of connection tracking for NAT. Are you shaping and doing NAT on the same box? I think this might be the basic reason for increased latency.</p>
<p dir="ltr"> - Jonathan Morton<br>
</p>

--001a1134d45e2976080514f20b98--