From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 69C7321F457 for ; Fri, 18 Jul 2014 17:23:25 -0700 (PDT) Received: by mail-oi0-f43.google.com with SMTP id u20so2206687oif.30 for ; Fri, 18 Jul 2014 17:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=bXJyd3G4V55wppxgMSES2ifx9P3sFTdCAIO3LYNcjsg=; b=UIIzSbCSCg3i+HE282rvaG0yQ1H9fN5IrfxrWamfg9QYJDuricYAU1VtrxwRmXHy0W lvlKJaa+Ly3F2z3hWQ+LVAJ5VUO/SfQnK/hWllgiV0cypwULSvWN9dDJ26dXSk1zTtkf H0ggnn5PsDhzthbaMRVwkKyoqtbPBD0IW2BVIqPthxHvQ91GN1tfeeDMJ8vbMfX3mzfc Lr9zBBvgiL38WlC5OIrN8xExeUj9UHxfzXplRvmT3t5fR0jNLwyHDOTVxDVrY+YcEYbz nTtNDvv1cn38g7uAQEwcRZZQhNCdjtsa17UwEv5jk3WKZ63nWXzKpqbZu3mtRInYGaso PLnA== MIME-Version: 1.0 X-Received: by 10.182.96.71 with SMTP id dq7mr12133806obb.42.1405729404217; Fri, 18 Jul 2014 17:23:24 -0700 (PDT) Received: by 10.202.93.195 with HTTP; Fri, 18 Jul 2014 17:23:24 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Jul 2014 17:23:24 -0700 Message-ID: From: Dave Taht To: David Lang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] Fastpass: A Centralized "Zero-Queue" Datacenter Network X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 00:23:25 -0000 On Fri, Jul 18, 2014 at 4:27 PM, David Lang wrote: > On Fri, 18 Jul 2014, David Lang wrote: > >> On Fri, 18 Jul 2014, Jim Reisert AD1C wrote: >> >>> "Fastpass is a datacenter network framework that aims for high >>> utilization with zero queueing. It provides low median and tail >>> latencies for packets, high data rates between machines, and flexible >>> network resource allocation policies. The key idea in Fastpass is >>> fine-grained control over packet transmission times and network >>> paths." >>> >>> Read more at.... >>> >>> http://fastpass.mit.edu/ >> >> >> >> and all it takes is making one central point aware of all the >> communications that is going to take place so that it can coordinate >> everything. >> >> That is sure to scale to an entire datacenter, and beyond that to the >> Internet >> Your tag is incomplete, therefore the rest of your argument fits under it too. :) What I find really puzzling is that this paper makes no references to the fair queuing literature at all. I was even more puzzled by one of the cited papers when it came out, where what they are implementing is basically just a version of "shortest queue first": http://web.stanford.edu/~skatti/pubs/sigcomm13-pfabric.pdf vs http://www.internetsociety.org/sites/default/files/pdf/accepted/4_sqf_isoc.= pdf (can't find the sqf paper I wanted to cite, I think it's in the cites above= ) Which also didn't cite any of the fair queue-ing literature that goes back to 1989.They use different terms ("priorities"), language, etc, which indicates that it was never read... and yet it seems, once you translate the terminology, all the ideas and papers cited in both the mit and stanford papers seem to have clear roots in FQ. Maybe it takes having to fundamentally change the architecture of the internet to get an idea published nowadays? You have to make it unimplementable and non-threatening to the powers-that-be? Studiously avoid work from the previous decade? Maybe the authors have to speak in code? Or maybe an idea looks better when multiple people discover it and describe it different ways, and ultimately get together to resolve their differences? Don't know... If you substitute out pfabric's suggested complete replacement for IP and TCP for a conventional IP architecture and drop some of their version of shortest queue first, and substitute nearly any form of fair queuing (SQF is quite good, however, fq_codel seems better), you get similar, possibly even better, results, and you don't need to change anything important. Going back to the MIT paper, I liked that they measured "normal" queuing delay in the data center (not looking at the paper now... 3.4ms?) under those conditions, showed what could happen if buffering was reduced by a huge amount (no matter the underlying algorithm doing so), liked the fact they worked with a very advanced, clever SDK that rips out networking from the linux kernel core (and moves most packet processing into intel's huge cache), and a few other things that were very interesting. Yes, the central clock idea is a bit crazy, but with switching times measured in ns, it might actually work over short (single rack) distances. And the "incast" problem is, really, really hard and benefits from this sort of approach. There's a whole new ietf wg dedicated (dclc I think it's called). There is often hidden value in many a paper, even if the central idea is problematic. In particular, I'd *really love* to rip most of the network stack out of the kernel and into userspace. And I really like the idea of writable hardware that can talk to virtual memory from userspace (the zynq can) --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article