[aqm] A bit of history on RFC970 and RFC896 from john nagle
Dave Taht <dave.taht@gmail.com> Fri, 15 April 2016 02:38 UTC
Return-Path: <dave.taht@gmail.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7E012E687 for <aqm@ietfa.amsl.com>; Thu, 14 Apr 2016 19:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cww_qfcQwxg for <aqm@ietfa.amsl.com>; Thu, 14 Apr 2016 19:38:14 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BEC12E682 for <aqm@ietf.org>; Thu, 14 Apr 2016 19:38:13 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id w85so112370353oiw.0 for <aqm@ietf.org>; Thu, 14 Apr 2016 19:38:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to :content-transfer-encoding; bh=fe16c3qYCZXFcutibSrOVJPaKGHIxT465Ie8q+wnFmE=; b=EpCTEfFAUPflu8Z6/zZyiftZx5XPziYkNp1+Dbn7+b9nxcRN7DKU7D66ILXaaErC/A jeF2oq2/6OzGYAF/QsEN9TY3SbTwReHq3BWCeScHs0Xj3odLBsolMbt3H2PAHEF2ZV1o hHrqsTGNflry43NOJHefUq6P9YzwemqOx355/y/unngZRbIp4+4b/CkdoyJR6uJV+J6t pVuqfCobnyTky9/5wk1D/1k2uxhPawrk0koIDAADWYQKUBgMK1PV4ohnikscpqBXNqoH htusN9ZhLcQnuWmRVu1EIQSxVWoVJUG+mHAT2v/Glkx9kQv1qLt+tbK5WGrbC7raErkH Vjbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-transfer-encoding; bh=fe16c3qYCZXFcutibSrOVJPaKGHIxT465Ie8q+wnFmE=; b=JJGuibEy8wCBiPo6iUjFc9RAEDiNoDRJ1uv1X+eKiDc1ew7drh8p+9AM7Nefe6BASg BqollJN2Nuq7Yc8Xu66p+GfrBs2eYUFFlHgdllE6YyloMzu3sMhArZr5bMqEatn/yHwz mkWyANR2zUY8GGDwKuzhA5ETwV/z9NUr5HQkh3iCe/LJP4BguHiqpq9w5EOtu2lr4ZlY O6F+SeiE0oq1hFlreFM9wtQP36sPtDKSp9L5xCyjTnOZvNASLLM4Gfyy8IajMVDgSncE XAA3wbxYZ0Z3Y8rP2q11DQrfZl7pFgsEnPkHDpFbLuNeT1XAgxtJ7f72HGGsP1Prcjpf J61Q==
X-Gm-Message-State: AOPr4FVCa6as1G6nBwVR58cOuH8683nC01oBg7SMyEr7F6gXnSRdmM5a/DHi49E63n2yCuvozxF24GDGpUjoHA==
MIME-Version: 1.0
X-Received: by 10.157.57.132 with SMTP id y4mr8739515otb.169.1460687893128; Thu, 14 Apr 2016 19:38:13 -0700 (PDT)
Received: by 10.202.79.194 with HTTP; Thu, 14 Apr 2016 19:38:13 -0700 (PDT)
Date: Thu, 14 Apr 2016 19:38:13 -0700
Message-ID: <CAA93jw4sf1EAtUx4XriKkmwV9URgCwrR1ZSH5dAde=DqZLjfQQ@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
To: "aqm@ietf.org" <aqm@ietf.org>, bloat <bloat@lists.bufferbloat.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/aqm/86QF0BuFYN83J63NRX6xgjhJh8I>
Subject: [aqm] A bit of history on RFC970 and RFC896 from john nagle
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2016 02:38:15 -0000
---------- Forwarded message ---------- From: John Nagle Date: Thu, Apr 14, 2016 at 7:14 PM Subject: Re: Bufferbloat and FQ and you To: Dave Taht <dave.taht@gmail.com> Cc: ropan@cisco.com On 04/14/2016 03:33 PM, Dave Taht wrote: > > https://www.rfc-editor.org/rfc/rfc7806.txt was published today. "There is extensive history in the set of algorithms collectively referred to as "fair queuing". The model was initially discussed in [RFC970], which proposed it hypothetically as a solution to the TCP Silly Window Syndrome issue in BSD 4.1." That's somewhat wrong. First, tinygram prevention (the "Nagle algorithm") is not about "silly window syndrome". Silly window syndrome occurs when the window is full, and the reader does a small read, resulting in the sender being allowed a small write, resulting in very short messages. The solution is clearly to not offer more window until there's at least one full size datagram worth of window available. Tinygram prevention is a problem when the window is empty, not full, and the writer is doing small writes. The question is how to consolidate those writes. It's not obvious how to do this without impacting interactive response. The classic solution, from X.25, was an accumulation timer with a human response time sized delay. That's a bad idea, but unfortunately the people who put in delayed ACKs didn't know that. They were trying to fix TELNET responsiveness at Berkeley, which was using a large number of dumb terminals connected to terminal servers at the time. Delayed ACKs with a fixed timer are useful in that situation, and in few others. Actually, this didn't involve 4.1BSD's netowrking; we at Ford Aerospace were running a heavily modified version of 3COM's UNET TCP/IP stack on various UNIX systems. That TCP/IP stack lost out because it cost about $4000 per node for the software. The tinygram stuff was in my RFC 896, and isn't really relevant to fair queuing or congestion management in routers and other middle boxes. The important part of RFC970 is at the section headed "Game Theoretic Aspects of Network Congestion". This discusses the relationship between endpoints and middle boxes, and the need to create an ecosystem which does not reward bad endpoint behavior. The [NOFAIR]] reference is interesting. Yes, fairness is gameable. But FIFO is so much worse, as the bufferbloat people point out. It's worth thinking about when a packet becomes useless and should be dropped. If the packet times out (this was originally what TTL was for; it was a seconds count), it can be dropped as obsolete. A router which looks above the IP level could also detect that the packet has been superseded by a later packet in the same flow, that is, there's a retransmitted copy also queued. If enough resources are available, that's the only packet dropping you have to do. As an optimization, you can also drop packets that are so far back in queues that they'll time out before they're sent. It's worth viewing that as a goal - don't drop any packets that would be useful if they were delivered. Just reorder based on notions of fairness and quality of service. This is the opposite of Random Early Drop, but that's sort of a meat-axe approach. Bufferbloat is only bad if the queuing is FIFO-dumb. It's fine to have lots of queue space if you manage it well. (I'm retired from all this. It's up to you guys now.) John Nagle -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org
- [aqm] A bit of history on RFC970 and RFC896 from … Dave Taht
- Re: [aqm] [Bloat] A bit of history on RFC970 and … Juliusz Chroboczek