From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-11-iad.dyndns.com (mxout-173-iad.mailhop.org [216.146.32.173]) by lists.bufferbloat.net (Postfix) with ESMTP id A3DE12E0117 for ; Thu, 24 Feb 2011 07:00:49 -0800 (PST) Received: from scan-12-iad.mailhop.org (scan-12-iad.local [10.150.0.209]) by mail-11-iad.dyndns.com (Postfix) with ESMTP id 03515171087 for ; Thu, 24 Feb 2011 15:00:39 +0000 (UTC) X-Spam-Score: -8.0 (--------) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 171.68.10.87 Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mail-11-iad.dyndns.com (Postfix) with ESMTP id 2ECE0171074; Thu, 24 Feb 2011 15:00:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=7258; q=dns/txt; s=iport; t=1298559638; x=1299769238; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Ii+O5aCE4b+HeY3QQuZdck1JRqBTxlQTRWcljxxl24M=; b=d94kpFCeuaT5Uwx7ztXPLefvIjri0S3O0USnv/k9U4fPoFSUP53IbR/P 8UW8QHM5bYumYQfmTUtbYki4s65xqLq1UbVvtM47413MQbM8pCR/ig0Tf Sj63sRBMJNBk42JjwWsTIfkG57J8/dghGHVt34TwaK5XPhXEAh+6akLOb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHsBZk2rR7Hu/2dsb2JhbACmKHOhe5tshWAEhRCFd4EVgz0 X-IronPort-AV: E=Sophos;i="4.62,218,1297036800"; d="scan'208";a="334663211" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 24 Feb 2011 15:00:37 +0000 Received: from Freds-Computer.local ([10.21.87.171]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p1OF0TmC007067; Thu, 24 Feb 2011 15:00:34 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 24 Feb 2011 08:00:35 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 24 Feb 2011 08:00:35 -0700 Subject: Re: [Bloat] Please enter issues into the issue tracker - Issue system organisation needed. Mime-Version: 1.0 (Apple Message framework v1082) From: Fred Baker In-Reply-To: <4D6668F4.5010705@freedesktop.org> Date: Thu, 24 Feb 2011 08:00:15 -0700 Message-Id: References: <4D6668F4.5010705@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-devel@lists.bufferbloat.net, bloat@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 15:00:50 -0000 Thanks, Jim. One thing that would help me; I have been a fan of RFC 2309 and RFC 3168 = for some time. I suspect is that between them any given queue should be = manageable to a set depth; tests I have run suggest that with RED = settings, average queue depth under load approximates min-threshold = pretty closely, and ECN has the advantage that it manages to do so = without dropping traffic. I suspect that this community's efforts will = support that. Some thoughts: First, if the premise is wrong or there is a materially better solution, = I'm all ears. Second, if the premise is correct, I'd like data that I can put in front = of people to get them to configure it. Third, there is a long-standing debate between Van and Sally on what = units to use with min-threshold. Sally argues, or argued, in favor of = byte count, as that correlates with time and biases mark/drop toward = large datagrams, which is to say datagrams carrying data - which happen = to be the datagrams that act as signals to Reno-et-al. Van argues, or = argued, in favor of buffers, as what is being managed is the router's = buffer resource. In our implementations, we provide for both options, = and personally Sally's model makes more mathematical sense to me. Is = there a "best practice" we can document? Is there a "best practice" we = can document regarding min-threshold and max-threshold settings? In private email, I shared an approach that might make tuning a little = more reliable and not require a max-threshold. If there is material = being developed - an updated version of RED-Lite, or experience with = other approaches, anything that would allow us to make the AQM algorithm = self-tuning would be of great interest. The result of any such = self-tuning algorithm is that it should be usable with dropping or = marking, should keep the line operating at full utilization as long as = there is traffic to send (eg not depend on the line occasionally going = idle), maintain the queue at a "reasonably low delay" level under normal = circumstances, not result in a given session being forced to shut down = entirely, and not result in multiple drops on the same session within = the same RTT in the normal case. There is one special case that I have wondered about from time to time; = the impact of loss of SYNs or SYN-ACKs. The network I started thinking = about that in what an African network that was seriously = underprovisioned (they needed to, and eventually did, spend more money) = on a satcom link. In essence, I wondered if there was a way that one = could permit the first or second retransmission of a SYN as opposed to = the initial one to get through in times of heavy load. The effect might = be to let an existing session quiesce. That falls under "research" :-) We have issues with at least some of our hardware in this; on the GSR, = for example, queues are on the output card but IP processing is on the = input card, meaning that we have lost all IP-related information by the = time one would like to set ECN CE or inspect the DSCP value, and on the = input card we have no real-time (microsecond-scale) way to inspect queue = depth or integrated rate of a queue on the output card. The GSR is a = mite elderly, but still widely used, and no, folks aren't going to = replace cards at this stage in its life. So, ideas people have on = working around such issues would be of interest. On Feb 24, 2011, at 7:19 AM, Jim Gettys wrote: > We have lots of different issues to track. We are uncovering more and = more with time, and the responsibility for the issues is all over the = Internet ecology. >=20 > These issues include drivers in multiple operating systems, queue = disciplines, OS distribution problems, broken networks, broadband gear, = ISP's with broken configurations, routers with broken configurations, = etc, etc, etc. Many of the responsible organizations are completely = unaware they have issues at the moment, and when they do wake up, the = need to have a work list. Serious as bufferbloat is, and generating = tremendous support costs as it does, it is hidden among most = organisations issue tracking as obscure, hard to explain problems, that = have heretofore defied analysis. >=20 > I think both for the sanity of the upstream open source projects and = companies that depend on it, commercial software and hardware vendors, = and our own sanity, it's time to start to keep track of these problems. >=20 > A simple example is in the following mail, where Juliusz identified a = bunch of Linux drivers with problems communicating back-pressure. > = https://lists.bufferbloat.net/pipermail/bloat/2011-February/000036.html >=20 > These driver bugs, of course, can and will be worked upstream in the = project and/or responsible organisation; but from a practical point of = view, these issues aren't really going to be fixed until people can = actually take action on their own (by upgrading affected OS's, routers, = broadband gear, etc. as appropriate). >=20 > So I think we need to track bufferbloat issues in possibly a different = way (and maybe with a bit different work flow) than a usual tracking = system. >=20 > First > =3D=3D=3D=3D=3D > I think we need to capture what we know. I encourage people to start = entering issues in the bloat tracker found at: >=20 > http://www.bufferbloat.net/projects/bloat/issues/new >=20 > Note that redmine lets us move issues from one (sub)project to = another, so we're best off capturing what we know immediately; we can = sort and redeal later. >=20 > Note: "We're all bozos on this glass bus, no stones allowed". We know = there are problems all over; issue descriptions should always be polite = and constructive, please! >=20 > Noting these issues will help people already involved (the mailing = list had > 120 people the last I looked, from large numbers of = organisations) take concrete action. Issues buried in mail threads are = too easy to lose. >=20 > Second > =3D=3D=3D=3D=3D=3D > As this effort grows, we'll need to organise the result, and delegate = it appropriately as the effort scales. >=20 > Today, we're probably best off with a single project: but we hope = certainly that won't be reasonable with time, possibly almost = immediately. >=20 > We installed Redmine in particular as it has a competent issue = tracking system, as well as good (sub)project management, which can = easily be delegated to others (one of the huge problems with Bugzilla or = Trac is the lack of project management). >=20 > If anyone is looking for a way to help bufferbloat and has experience = with tracking systems on large, complex projects, I'd love to see = someone organise this effort, and put some thought and structure into = the categories, (sub)projects and work flow of issue states. I know from = my OLPC experience just how important this can be, though this is a = somewhat different situation. >=20 >=20 > Best regards, > - Jim >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat