Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague presentation
Dave Taht <dave.taht@gmail.com> Thu, 04 April 2019 11:53 UTC
Return-Path: <dave.taht@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992F112000E for <tsvwg@ietfa.amsl.com>; Thu, 4 Apr 2019 04:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 4DZYbfl__KHT for <tsvwg@ietfa.amsl.com>; Thu, 4 Apr 2019 04:53:36 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 5C304120489 for <tsvwg@ietf.org>; Thu, 4 Apr 2019 04:53:36 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id o129so1391103qke.8 for <tsvwg@ietf.org>; Thu, 04 Apr 2019 04:53:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MWi4kABLAoGA97QyLPYpSSSS+5MNty8pYx3p8n+eFXg=; b=tRNBt65cQS9GFqAGWPmUqHGhq0L7+V4XiuhrmveQP/8ID8KGa5BMIzHuV8ADFq9G2i ouL6F7vQyZCv7d+yH+itiMKKvRuxr3FMzUuyewmR7mB0/RiaivJtsGQKYbqk5MNpWYrS E+AmKNonGjw3h4D6fA68CHwVbg/P1tpoR4Uywfz76ng0ocSPP8LGU+u3Uxjkkx8/S9Px 35hQFrMItWfXFSiMW+V/rz1p7o+OeHpTVVoMRfwpVUH5EtAKqjJj27kELs/n3rZQv/Gu pkRedyGNzY6o9rsbEM+vkVbkFu20vHqMisDw+Z8joyzd8vpxfVs1yrVj5S94fuCES+O7 uPuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MWi4kABLAoGA97QyLPYpSSSS+5MNty8pYx3p8n+eFXg=; b=nwzfdcGAKFEAhwPFP54ppra9Sl+XswqqnrSmS2H2FxbHHKwkU4OY7dIDayaQqwjaS/ /0aHHBVLpusLpqQVZNV2jQ4ucmZ+o2KCoI7W1MhiGJJXHpe+g7OWh8gZIU5z33UnW6u+ QHxEdEqqZeVoNyl0LTpuV1oUKQzfNNqMolhLgy416OMq5+/e3pUeI/+yeoPrrxwwtJ4C FnqXPFNcbKRm9/Jl1GJqvvJ3g9gs0iRzosac62/0uh4gWuQYQR7f/SParW7vj0NmYz8v U+zoT5AY6WtYh9gENZ1RhwpfxutPDGx7TCBUlplEnbhx4ppe23TX/sQ5s8UsPwtvrc60 6xuw==
X-Gm-Message-State: APjAAAW5T6PzlcXSdfkSh1MphkiNaeYrAub8pyxFUjt2CdTYalwEy/Og gNu1pXzhDknH/yTBb0s03t7BkXlQxhT0H8g7+XQ=
X-Google-Smtp-Source: APXvYqzHfxQ1vqf6gkRuNfNPdD/8GWSJuaeBcmPW3Y0Hf86IPvG3iLGI5umKW+g2bptsK28kWIfxtuPv5NVMxbc5K7E=
X-Received: by 2002:a37:a5d8:: with SMTP id o207mr4753507qke.0.1554378815382; Thu, 04 Apr 2019 04:53:35 -0700 (PDT)
MIME-Version: 1.0
References: <623CA1C6-3425-46E6-AFD9-6FD7D0DBE422@gmx.de> <a7bf3c8d-bb9e-e7e8-3343-ccdbac795591@bobbriscoe.net> <82B40A22-F2C2-4D56-868A-F53D7AEA37D7@gmail.com> <4507BFFD-A68A-4E8A-8FFB-347F95E3F2E8@cablelabs.com> <2491A216-4522-4942-BDEB-301D61CC5D03@gmail.com> <FD7FA874-3413-4F62-81CB-0F68B9038CC7@cablelabs.com> <B0F75E09-9264-4AC0-BF35-F084CC6213FC@gmail.com>
In-Reply-To: <B0F75E09-9264-4AC0-BF35-F084CC6213FC@gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Thu, 04 Apr 2019 13:52:54 +0200
Message-ID: <CAA93jw6L66jNgvO9M6CVvQjX66Ha_SWaomzBrFs9QO0pGC-ASg@mail.gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Greg White <g.white@cablelabs.com>, "iccrg@irtf.org" <iccrg@irtf.org>, Sebastian Moeller <moeller0@gmx.de>, Bob Briscoe <in@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, ECN-Sane <ecn-sane@lists.bufferbloat.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/kWLX9E78qq2ygpt5QDaXKZG5KAY>
Subject: Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague presentation
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2019 11:53:39 -0000
Several things... I find discussions of ECN in general very stressful, as I am firmly on the ecn-sane "yellow" team. ECN scares me on the general internet. More than anything else, I'd like to get a big DDOS protection provider and university to tackle all my outstanding issues with using ECN in a general deployment - ranging from what happens with tcp syn ecn enabled attacks, to ddos protection from udp based packet floods, as I outlined in the ecn-sane project's charter: https://www.bufferbloat.net/projects/ecn-sane/wiki/ before I can endorse this work. I have friends that regularly deal with 2TByte/sec DDOS attacks and they have worse blood pressure problems than I do. I've long had no problem with ecn in specialized deployments, under rigidly controlled conditions. The SCE work, in particular, looks to be useful for technologies like nvme over tcp and roce and stuff like that, and I look forward to results there. One of the proudest things I have ever had going in my life is that the backhauls and groundstations for the arkyd-6 spacecraft, used fq_codel with ECN enabled... running lede (openwrt). And though I can't talk about that project much, and probably shouldn't have mentioned even that much here - I tend to feel that any non-backward compatible change to ecn will muck with *my* bird in a 25 year orbit, and I kind of take it a bit personally any naive interference with that contribution to the US space program. I am unsubscribing from the ietf lists as of now, so I can focus on getting testbeds and analytical tools up, as well as finishing up my work on the ipv4 unicast extensions project, which is entirely separate, that I wish I could get more folk to pay attention to. If there is a productive conversation of interest to me, here, using debating techniques I can live with ( https://www.bufferbloat.net/projects/ecn-sane/wiki/rules/ ) please either send a link or cc ecn-sane@lists.bufferbloat.net. Thank you. Dave
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Bob Briscoe
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Jonathan Morton
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Greg White
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Jonathan Morton
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Greg White
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Sebastian Moeller
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Sebastian Moeller
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Sebastian Moeller
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Sebastian Moeller
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Jonathan Morton
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Dave Taht
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Greg White
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Jonathan Morton
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Greg White
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Greg White
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Sebastian Moeller
- Re: [tsvwg] [iccrg] IETF104 ICCRG TCP Prague pres… Jonathan Morton