From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id BBA523B4B6 for ; Thu, 14 Apr 2016 22:38:13 -0400 (EDT) Received: by mail-oi0-x22f.google.com with SMTP id s79so112288137oie.1 for ; 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=J/w6G/8LutQ6HMpzx1CMX331NltJbbQAVR9+z59hpaBeSqeVAK1kwUtlN4Ur0T2qpE 1uLdBJ4bm7RltBxBErO6Y8I0llZqbroDa+aoW+e2Du8ca4mPyFuGCTOjlrVGlrSusAKm CirwUXs3E2sNr1veGtFs+UPTWo+p5kg7x6Qf/Lp8SMVFBhCOReeE/8NuVil28pW4jxjc bNxBq3+kWq3MTgcrBcOzve2HyxKNGruBgHFIqTkMSZbYqshspjuch5xAyy3VZkdK4svV MCsxpAUy2DKB60ksEPo9+R340DvBYLDDj70Qsy7aKrvPlH8NcxJFkdKs9EBtIfBd2hMK HxgQ== X-Gm-Message-State: AOPr4FU/5MIdBX4uwzLX2ey/kkLXx+05AT19vAnrDvtjZnjKsFdFrXowBuzvq9z7rOSeAziR0UwM5OdeI01R9Q== 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: From: Dave Taht To: "aqm@ietf.org" , bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Bloat] A bit of history on RFC970 and RFC896 from john nagle X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 02:38:13 -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 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 --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org