From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 BFBCB3CB35; Wed, 19 Sep 2018 12:45:22 -0400 (EDT) Received: by mail-qt0-x236.google.com with SMTP id t39-v6so5700378qtc.8; Wed, 19 Sep 2018 09:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=QyWOn2eZA3uR5t0pqff+E0JNPz3YJLApjuNe+oDdtL8=; b=CXM3v0pJT45XkxcULHBBs2UhLK4eSgJrvMLmJSS1K1bJYdu3YzoLIPbATnZpJaHiRq bqbt2LYJ3zOsx7NLY4wkGzlFb8BR37LKxbYn4DuX/HRAY1FUkMFstJm9EyWRU57aHH4a zTx4zYcyFhIjGcZS2Q/SGdHPYAq+pAFt4osHOd/vZEzRYUh6UJUkYOXaWhlqvCaxB71r 7/1ZOsXhQNaCzTs/GOdgo/3yEbD5UoduoHCE5HkR/vG5TXJwYGLM1ax33jCW1mdb49d8 5UNB4MoS7Jl1MJ3D9KVDBRnW6MAoaMbQNl5kT6sLDSkEkAzB5gMJpw5ZIgg+hjOlYL0x SRIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=QyWOn2eZA3uR5t0pqff+E0JNPz3YJLApjuNe+oDdtL8=; b=e072+4hRO56nRcpPQTo7FtFncBnE4BLaQwSsPPmhYSK2iJD1FdZMQNDq1TF7ujY7P1 5bAenMPAFxYhQi3/NXW5bXwlsgVE/ag+jyArxu3xa3Isa908JeRtqAw2426X7Tb6XlQX JM4ml1jLX06K1Y87qbDNb07XbI1XK04Xg9LVZjtPKmyMzV0Bk2exfNBTayeKNKy66/8a 1uD/fDd3eGMDqEOncVwLEAdUbaEYECoxCXZIzn7V3UCtaBSVFatYg5v8BD70JfwdUl6G j9lgpRXTKZL1qH8H1fyWSR0HWxEWv0nF5mGQfBFM8fwpEVvHsTrm5O+37thW8g80EsNY 9a+w== X-Gm-Message-State: APzg51BBjLFXNQfqJpjN3GpPObaDT3bJfqgMjjJLW34TPR1pkYN/tfzn /+AzkCKtPct9e0IbaOSBOD3+jO/Ya3k81AB5z2fn6nSY X-Google-Smtp-Source: ANB0VdYhQegaduql11W2vkD77gDb9z9XKpAM+IUXLEhDq9AM4iZdL6rulZXQqUxOHm+FVQq94e1W8HlIFJ6pMwVxXHI= X-Received: by 2002:a0c:b584:: with SMTP id g4-v6mr25338734qve.94.1537375521908; Wed, 19 Sep 2018 09:45:21 -0700 (PDT) MIME-Version: 1.0 From: Dave Taht Date: Wed, 19 Sep 2018 09:45:09 -0700 Message-ID: To: ecn-sane@lists.bufferbloat.net, bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [Bloat] data/control plane 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: Wed, 19 Sep 2018 16:45:22 -0000 For a while now a control plane/data plane distinction has permeated much of academia. Ostensibly this take on matters made some things simpler. My take was, to mis-quote jwz's take on regex's: "Now you have two problems". Having the complexity of two "wires" or two busses hurts MTBF, raises costs, introduces desynchronization problems, and so on. To some extent my support of FQ techniques was to find better ways of multiplexing control and data signals along a single bus. More recent additions, such as AQM and classification, further this. If you go looking however, no matter how clean an architecture, there are always "control" packets on a data or control plane. Easy examples are LLC packets in DSL, management frames in wifi, and arp. More complicated ones are spanning tree, ethernet pause frames and the plethora of other schemes the IEEE has been coming up with to at least theoretically deal with congestion. Easy examples as to why these sorts of packets are needed abound - block arp, LLC or spanning tree for a minute and your network fails. Get wifi management frames out of order, and wifi fails. One of the many things I like about pie and codel is that by focusing on latency, they interoperate fairly well with various flow control schemes, but life here remains imperfect. Yet these control packets also are subject to a need for rate control themselves. I keep trying to remember the paper's name that showed that 75% of the wifi packets in a stadium were management frames, in particular. All the ants scurrying about are largely unmanaged and unobserved. What we started to call "ants" - relative to the mice, elephants, and lemmings - in the early stages of the bufferbloat project - are worrying me, more and more. On Wed, Sep 19, 2018 at 8:13 AM Dave Taht wrote: > > At one level, my hope in starting this project is that once enough > researchers realize that ECN is now ubiquitous in apple's products, > all kinds of new ideas and research will emerge and we won't have to > do any more work. :) > > In my case, though, I rather wanted to promote a skeptical look at the > edge cases. A quick look at things like /etc/services or the long list > of ethertypes https://www.iana.org/assignments/ieee-802-numbers/ieee-802-= numbers.xhtml#ieee-802-numbers-1 > is sufficient cause to worry. > > I'm pretty good with short, ringing phrases, and hereby give away most > of these potential paper titles away to whoever wants to use them. > > I'm going to talk to two or three of these in the coming weeks, but to > at least get the list out of my system: > > Where ECN is unfair > When ECN is evil > ECN along the edge > ECN as an attack vector > DCTCP along asymmetric paths > Towards making ecn generally deployable > Fair queuing failures > ack-filtering in practice > ECN has mass! > ecn over wifi > syn/ack limiting as rate control > self congestion as aqm > ecn on alternative protocols > sch_cake and blue > ECN should be an earlier congestion signal than loss? > Mosh's reaction to ecn > ECN outbound on residential links > GSO considered harmful > Making tcp go slower makes it faster > Damage from an ecn enabled DDOS > FQ is not enough > ECN on meshy protocols > ECN vs ISIS > > -- > > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 -- Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619