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

Toerless Eckert <tte@cs.fau.de> Thu, 23 January 2020 22:55 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: chirp@ietfa.amsl.com
Delivered-To: chirp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418661200B4 for <chirp@ietfa.amsl.com>; Thu, 23 Jan 2020 14:55:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 buwLZ3ELfT2i for <chirp@ietfa.amsl.com>; Thu, 23 Jan 2020 14:55:42 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFAFB1200B7 for <chirp@iab.org>; Thu, 23 Jan 2020 14:55:42 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id DC2D7548048; Thu, 23 Jan 2020 23:55:36 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D5A64440059; Thu, 23 Jan 2020 23:55:36 +0100 (CET)
Date: Thu, 23 Jan 2020 23:55:36 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, chirp@iab.org
Message-ID: <20200123225536.GG14549@faui48f.informatik.uni-erlangen.de>
References: <f13e1588-35e0-2493-93d2-add3480bb207@cs.tcd.ie> <alpine.BSF.2.21.99999.352.1912311910270.24431@hans.rg.net> <20200113153741.GH14549@faui48f.informatik.uni-erlangen.de> <CAKKJt-dq6TNBo8h0sSuJ=x_Ah0UeY7ybDys+=0Q0WjqS4i_KgQ@mail.gmail.com> <20200115161329.GQ14549@faui48f.informatik.uni-erlangen.de> <8a38e60b-1c6b-f93e-729a-1d98a59f883f@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8a38e60b-1c6b-f93e-729a-1d98a59f883f@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/chirp/lZ9ve_KKHT-Dh_3RTEtnHoUg32g>
Subject: Re: [Chirp] [arch-d] possible new IAB programme on Internet resilience
X-BeenThere: chirp@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "CHallenges for Internet Resilience \(proto-\)Program" <chirp.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/chirp>, <mailto:chirp-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/chirp/>
List-Post: <mailto:chirp@iab.org>
List-Help: <mailto:chirp-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/chirp>, <mailto:chirp-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2020 22:55:45 -0000

On Fri, Jan 24, 2020 at 11:16:24AM +1300, Brian E Carpenter wrote:
> > 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?

Because networks with just best effort are dirt roads and cars wouldn't
be able to drive faster on them ;-)

> 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?

Bounded latency from Rene Cruz 1991 leading to guaranteed services in
IETF in mid 90th, TSN in 2010, DetNet still slowly moving trying to
reinvent the same wheel without being given enough freedom to innovate
on the protocol stack. Continental drift is faster.

Congestion control research over the past 20 years, understanding how we
can do better more equal or policy defined inequal bandwidth
management.

Much more powerful high-speed forwarding planes and scheduling hardware
than e.g.: 1990th ATM switches or even 2010 best-in-class-routers.

I could go on and on, but that sidebar of mine you're referring to
wasn't specifically targeted to resilience, so maybe we should take
this back to arch-d instead of chirp.

> For that matter, what has changed in Shannon's observation that all communication channels are subject to random noise?

Fiber links, high performance L1/L2 FEC, non-blocking forwarding
favbrics. Outside of radio and IoT, you pretty much can get to
< 10^-12 loss thats not controllable by scheduling/queuing policies.
Even long Internet paths.

Not quite sure why these questions/answers where relevant for my
original rant, but of course i am happy to answer ;-)

> 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?

In my simple abstraction, anything where a wide-area transit SP is involved is
uncontrolled. Whenever it is not, the use-case can be a controlled
environment given the right technologies.

I think we will get more and more controlled environments. What i would
like to call the future Internet Fronthaul is IMHO between users/devices
and edge-data-centers, aka: metropolitan size networks. Thats where
latency is low and has different criticality to different type of
traffic. Thats where we can likely get > 90% of traffic paths to not
use any wide-area transit, so networks passed will have contracts with
either end of the communication, allowing to have business models for
all those better-than-best effort services - including higher resilience
(to stay on chirp topic).

Shannon limit is not of interest to these aspects IMHO, but rather
service/contrat differentiation of different type of network traffic.
Shannon limit may be of interest in aspects of congestion/flow-control,
which still has issues with high-capacity network path.
I call this controlled environments.

Cheers
    Toerless

>     Brian
> 
> > 
> > [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
> >>>