Re: [Chirp] [arch-d] possible new IAB programme on Internet resilience

Brian E Carpenter <> Thu, 23 January 2020 22:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E31A120100 for <>; Thu, 23 Jan 2020 14:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vz8xcokzvuLq for <>; Thu, 23 Jan 2020 14:16:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29B39120077 for <>; Thu, 23 Jan 2020 14:16:32 -0800 (PST)
Received: by with SMTP id s64so2072300pgb.9 for <>; Thu, 23 Jan 2020 14:16:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XTGR3YgptYzs9aBzVN2jL53UguvemEj3M4SAPHQ4kKE=; b=OGFcXM12HfefywotbzjKIAtQ0zkVzuz3eTVAcAEnNnOATIx6Kxa1Wr6GzgGiW/s2ti wFyXfBGY3aspQjrb2uhChwF/rqJwkd0x8oqQk3F++QEzDSuBsv+HaZ4w+zv0pR3wpLof kjdJeO5yH8+6Ttxc4CJ4dSMm3o3st96zlUG6e2MGSHCKtxVAkvM0K1w3LPrfMWJvAh0v adrVQW64ZsIBlbSNmy/l/8cONXqYOiZo5NG1pf7xU1xFxv2Z/2eD0DPubdfbCvmqJyxX JvgCBSNrZ/ArdkQqxU17cUjh0g0HUWzgZBenH2yhEexCxvIFhyu/mSEgR2zp9KkJ2HL0 2H0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XTGR3YgptYzs9aBzVN2jL53UguvemEj3M4SAPHQ4kKE=; b=b4seuknkk1CImPyFcdfwuSIHgH+khkqhAMVZeY73nUL8Q4/kxWrUTrneczCvhcHL6F DHy5KswMJ0TgntO0kQEwOrIQtegl/+z9erwdtvoGKtn79EAnjuoZi6ZZ55DYlGykyDs7 6otM7lTFixHgk7ngB2vhnKYM/Hi7x0A9Lun1M1s8TgWOFCvJUc3lYm0XmbiiKtkI5+aN SjlaOYtPfMH+Bb+5TyDArpSoS2GQLUtbGoVSNDM/qJ35QOYgzVIMx5B5Y/HqG33qotiB dpHiVSOPsAGAs9969knQXwSDOLpQwG8Aeq12iYpvfiWZfs3puouTvQK+/V6K0tRyT7bd HEWA==
X-Gm-Message-State: APjAAAXhbfUZZ3Ddydj0qc/eXCWkrQ3mLQmKkUPf44/dXQCzF2DjASIT 0YmRcbigOZKwIH+HwX2K7bOmL4S9
X-Google-Smtp-Source: APXvYqxcRbnkIa5uqc1kuW1BGILU7drWNAos5uTh4W5LPTVgdatQV6lpnTJGZktU11UuqvkBPYkXNw==
X-Received: by 2002:a65:4d46:: with SMTP id j6mr591054pgt.63.1579817791075; Thu, 23 Jan 2020 14:16:31 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id g26sm3772715pfo.130.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jan 2020 14:16:30 -0800 (PST)
To: Toerless Eckert <>
Cc: Spencer Dawkins at IETF <>,
References: <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Fri, 24 Jan 2020 11:16:24 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Chirp] [arch-d] possible new IAB programme on Internet resilience
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "CHallenges for Internet Resilience \(proto-\)Program" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jan 2020 22:16:35 -0000

Answering on the chirp list:

On 16-Jan-20 05:13, Toerless Eckert wrote:
> On Wed, Jan 15, 2020 at 10:07:55AM +0900, Spencer Dawkins at IETF wrote:
>> This was probably true when I joined the IESG in 2013, which seems like
>> just yesterday in IETF timelines, but after the MPLS-in-UDP kerfluffle, the
>> TSV ADs and RTG ADs agreed that for specifications that might not behave
>> well on the open Internet, what we would ask was that these proposals
>> include a description of what safety mechanisms needed to be in place if
>> the protocol being described WAS running over the open Internet.
>> We put together a design team to figure out what to do, and that eventually
>> led to Transport Circuit Breakers, as in,
>> also BCP 208, which built on,
>> an early example of the kind of "congestion considerations" I'm talking
>> about, and produced by that design team.
>> I agree that this is hard, but it is possible to do better than best effort.
> If i may stay to me naming best effort (BE) Internet traffic as horses then i
> agree that this was very good work to ensure horses will not be harmed
> on 2030 internet highways. Alas, i can not really see what else IETF is doing 
> for a 2030 internet higway to support anything more than horses.

Because horses have proved to be very robust?

What do you think has changed relative to the fundamentals of Baran's analysis in 1962, and the mathematics of queuing theory as applied to networks by Kleinrock in 1974? For that matter, what has changed in Shannon's observation that all communication channels are subject to random noise?

I do agree that in controlled environments we can get ever closer to the Shannon limit, use carefully chosen queuing algorithms, and define robust alternative paths. Otherwise DetNet would be a waste of space. But how can we ever do this outside a controlled environment?


> [rant]
> I really wished the IETF would wake up to the need to not only bother about
> horses and work more on better than BE modes of transport for those future networks.
> CC work is still regurgitating the "all flows are equal" mantra and "we don't
> define exactly what equal means", and we know forever this is not sufficient.
> DetNet is already a decade behind IEEE TSN without any ability to build products,
> IP doesn't even have all the pieces to support it (only MPLS), switched ethernets 
> networks widely replacing IP networks in growth markets such as metropolitan
> networks, any form of traffic differentiation is immediately faced with more
> "net neutrality" misinterpretation in the IETF than encouragement to actually
> work on it, and the expectation of the IETF for new work to adopt itself
> to the historic structure of the IETF, its magically closed IAB, fine
> grained subdivision of work across WGs and the like is just mindboggingly
> unhelpful to strategic future work.
> [/rant]
> Cheers
>     Toerless
>> Best,
>> Spencer
>>> To me, this is really like asking new transportation standards to explain
>>> how
>>> they are compatible with horse manure because horses are still the
>>> golden standard for transportation.  So we continuously reinforce this
>>> historic
>>> lowest common denominator and do not encourage really systematically
>>> the value proposition of better quality/resilience network infrastructures.
>>> Toerless
>>> _______________________________________________
>>> Architecture-discuss mailing list
>> _______________________________________________
>> Architecture-discuss mailing list