From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-ewr.dyndns.com (mxout-094-ewr.mailhop.org [216.146.33.94]) by lists.bufferbloat.net (Postfix) with ESMTP id A84472E0271 for ; Tue, 15 Mar 2011 09:34:50 -0700 (PDT) Received: from scan-11-ewr.mailhop.org (scan-11-ewr.local [10.0.141.229]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id 83217930FD9 for ; Tue, 15 Mar 2011 16:34:49 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 74.125.82.171 Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id 0C25E930F08 for ; Tue, 15 Mar 2011 16:34:48 +0000 (UTC) Received: by wyb32 with SMTP id 32so885990wyb.16 for ; Tue, 15 Mar 2011 09:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=5ZZDAY9R3/WaJB5ouwvAXDMGMsyo1TDDKzMVdYDiDLw=; b=ik/vEAh2m7eGNgCEPiCMO4cHOZ/Sii9WuffKaE+cbZxEkLwMybNO4C1oJsmeUM0aGB 0vSmQx9v+lKb364XWZNtXEUmURockcAoCrfMkOtRAN+Fkqkzx1FOORl4+bKLGHwsj208 r7HYk6wn2hiZm8kZtKMnLwEAP3mAPPR/G6wac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=EjGZItqiJLrocYYN6i9ahKmcMN7eu1PIGMyHxHRQfcyLLPd0JRhSDI66UhLVBLHcGb ltOhNd4u8BO5vwq1QERu9takUkUoTfFTyg+1+j2E7arWvGT4bmfCNK3aP6/cNv607KCW 0lM4Z887cpa0E98twbdsDVsUvJZ9/Jc3x0j0I= Received: by 10.227.2.148 with SMTP id 20mr6896320wbj.220.1300206852781; Tue, 15 Mar 2011 09:34:12 -0700 (PDT) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id x1sm7236656wbh.8.2011.03.15.09.34.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Mar 2011 09:34:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: <4D7F4121.40307@freedesktop.org> Date: Tue, 15 Mar 2011 18:34:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <86404DEF-EDFE-498D-8B82-C2BAF2D84A57@gmail.com> References: <4D7F4121.40307@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1082) 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: Tue, 15 Mar 2011 16:34:51 -0000 On 15 Mar, 2011, at 12:36 pm, Jim Gettys wrote: > 0) the buffers can be filled by any traffic, not necessarily your = own (in fact, often that of others), so improving your behaviour, while = admirable, doesn't mean you or others sharing any piece of your won't = suffer. > 1) the bloated buffers are already all over, and updating hosts is = often a very slow process. > 2) suffering from this bloat is due to the lack of signalling = congestion to congestion avoiding protocols. I actually agree. I was looking at the various TCPs to see how well = they would respond to ECN, and ECN can only be created by some kind of = AQM, even if it's a braindead version of RED. Previously, I pointed out that there is no point in buffering more than = about 1-2 seconds of data, full stop - and that includes wireless and = very-thin links (eg. analogue modems). In most cases the appropriate = buffering level is less still. The fundamental limit is the initial-RTO = at 2.5-3 seconds, which happens to correspond to a notional lunar = bounce; once the delay exceeds that, you start to get symptoms of = catastrophic runaway, from both automatic and human feedback sources. The main concern actually seems to be "can we turn on ECN safely" = together with the related "how do we convince everyone to use ECN". = Once ECN is widely deployed, we can more easily convince the routing = people that using it might be a good idea, which is a gateway to AQM for = people who are otherwise skeptical about AQM. It is clear that concerns = still exist for ECN deployment, but that these might only be noticed and = fixed by relevant people once deployment actually happens. Chicken and = egg... Anecdotally, I have ECN turned on for most of my traffic, I = suspect that not all servers I communicate with respond to it, but I = don't see any nasty problems. The other major concern is consumer CPE. Most of this is made by a = relatively small number of manufacturers, who are currently in the = process of IPv6 transition. I seriously think we should make = recommendations to the IPv6 testing guys. Manufacturers will realise = that without a label proclaiming IPv6 support on the box, they will have = a hard time selling stuff in the near future. They do seem to have a = test which verifies that ECN isn't cut away by a router, but this isn't = very precise about ECN behaviour under load. > So the question I have is whether there is some technique whereby = monitoring the timestamps that may already be present in the traffic = (and knowing what "sane" RTT's are) that we can start marking traffic in = time prevent the worst effects of bloating buffers? The timestamps are not globally valid. You would need to observe each = individual flow and maintain some state about them. What's more, you = can't do this using stochastic flow discrimination as some AQMs do to = avoid state-related starvation. Further, I don't think there is even any specification of how quickly = the timestamps should advance - they are really there to disambiguate = the RTT *to the hosts* in a retransmission-rich environment. One host = might advance it every centisecond, another every millisecond, another = might increment it using a global packet counter rather than a timer. = The only thing the timestamps can't do is go backwards, so that they can = serve a secondary function related to LFNs, large windows, and stale = packets from previous connections. So timestamps give the host generating them a (much) better idea of RTT = (which is good news for delay-based and hybrid algorithms) though it can = still be fooled about minRTT if the queue starts full. They can't = realistically be used by routers without making some serious and fragile = assumptions. - Jonathan