From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-iad.dyndns.com (mxout-078-iad.mailhop.org [216.146.32.78]) by lists.bufferbloat.net (Postfix) with ESMTP id 522792E0271 for ; Tue, 15 Mar 2011 22:41:22 -0700 (PDT) Received: from scan-12-iad.mailhop.org (scan-12-iad.local [10.150.0.209]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id 884F43703F9 for ; Wed, 16 Mar 2011 05:41:21 +0000 (UTC) X-Spam-Score: -8.0 (--------) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 64.102.122.148 Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by mail-12-iad.dyndns.com (Postfix) with ESMTP id 33E1A370339 for ; Wed, 16 Mar 2011 05:41:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3304; q=dns/txt; s=iport; t=1300254081; x=1301463681; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=xRU3SUEStglLbzeGvF6T3XvAI1M+2u8tVivcb/8hy3c=; b=iBnq9sSbHCKthXmhkGF5F8/KYE3ftW0ytRavblLo+v5BC71oCkCyqxi7 /jCm9zqaKyyIJqlKd5T0DEEJ7Ne7eBpe+IswS7KpKUTNJowuZhHNPKlkD YOOoxiIwe7fuMjg55G4yND4jWy8pmLZrDSWxIwPm3SMITGKMoSvpsseMx 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIbqf02tJV2d/2dsb2JhbACmDXekNpxThWIEhTCHL4NO X-IronPort-AV: E=Sophos;i="4.63,193,1299456000"; d="scan'208,223";a="225649274" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 16 Mar 2011 05:41:20 +0000 Received: from stealth-10-32-244-221.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2G5fEUd015691; Wed, 16 Mar 2011 05:41:20 GMT Received: from [127.0.0.1] by stealth-10-32-244-221.cisco.com (PGP Universal service); Tue, 15 Mar 2011 22:41:20 -0700 X-PGP-Universal: processed; by stealth-10-32-244-221.cisco.com on Tue, 15 Mar 2011 22:41:20 -0700 Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D7F4121.40307@freedesktop.org> Date: Tue, 15 Mar 2011 22:41:04 -0700 Message-Id: <2927A265-BB9F-4466-BA03-1522AFF989C3@cisco.com> References: <4D7F4121.40307@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1082) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] Random idea in reaction to all the discussion of TCP flavours - timestamps? 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: Wed, 16 Mar 2011 05:41:22 -0000 =46rom my perspective, the way to address this is to go back to first = principles. Van/Sally's congestion control algorithms, both the loss sensitive ones = and ECN, depend heavily on Jain's work in the 1980's, his patent dated = 1994, and the Frame Relay and CLNS work on FECN and "Congestion = Experienced". Jain worked from a basic concept, that of a "knee" and a = "cliff": In concept: A | g| | "capacity" or "bottleneck bandwidth" o| |- - - - - - - - - - - - - - - - - - - - - o | .' \ d | .' knee \ cliff p | .' \ u | .' \ t | .' \ | .' \ |.' \ +----------------------------------------- window --> More likely reality: | | "capacity" or "bottleneck bandwidth" g |- - - - - - - - - - - - - - - - - - - - - o | __..,--=3D o | _,' `. d | _,' |<-->| |<-->|, p | ,' knee cliff \ u | ,' \ t | ,' `.._ | / `'-----' +`----------------------------------------- window --> In short, the "knee" corresponds with the least window that maximizes = goodput, and the cliff corresponds with the largest window value that = maximizes goodput *plus*one* - the least window that results in a = reduction of goodput. In real practice, it's more approximate than the = theory might suggest, but the concept measurably works. The question is how you measure whether you have reached it. Van's = question of mean queue depth, from my perspective, is a good = approximation but misses the point. You can think about the knee in = another way; if it is least window that maximizes goodput, it is a point = at which increasing your window is unlikely to increase your goodput. = =46rom the network's perspective, that is the point at which the queue = always has something in it. There are lots of interesting ways to = measure and state that, but it's what it comes down to. There is no more = unused bandwidth at the bottleneck that adding another packet to the mix = will take advantage of. At that point, it's a zero sum game: if one = session manages to increase its share of the available capacity, some = other session or set of sessions has to slow down. =46rom that perspective, one could argue that the simplest approach is = to note the wall-clock time whenever a class or queue's depth falls = below some threshold. If the class or queue goes longer than = without doing that, flagging an ECN CE or dropping a packet is probably = in order. The thing is - you want to be variable, so that your = mark/drop rate can track a reasonable number. If you do that, the queue = will remain somewhere in the neighborhood of the knee, and all of its = sessions will as well. The question isn't "what is the magic mean queue = depth for min-threshold to be set to"; it's "what mark/drop rate is = sufficient to keep the queue somewhat shallow most of the time". =20=