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

Replying to one point here ...

On Tue, Jan 14, 2020 at 12:38 AM Toerless Eckert <tte@cs.fau.de> wrote:

> On Tue, Dec 31, 2019 at 07:27:17PM +0000, Lucy Lynch wrote:
> > As an example - an Internet optimized for the web may not be the same
> > internet that supports real time data collection and shared computation
> in
> > the context of big science. How do we avoid closing out capabilities as
> we
> > optimize for others? Narrowing of choices looks like a path to a limited
> and
> > more brittle model to me.
>
> Indeed. With the new unique value propositions of new applications
> like mobile phones and video streaming, the network layer quality and
> availability acceptable to users deteriorated quite a bit over pre-IP
> solutions.
>
> There was a lot of growth of more network service reliability/quality
> demanding applications, but it all happened in vertical industries and
> mostly private networks and is IMHO still heavily discriminated against
> by the way the IETF operates.
>
> The IETF only has "Internet best (lousy) effort" as the gold standard:
> Every
> new standard is forced to argue how it would behave well if
> unintentionally leaking onto the BE Internet, no new standard is harrassed
> to support better quality/reliability network layer services (IntServ,
> DiffServ, DetNet, etc. pp).
>

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 https://tools.ietf.org/html/rfc8084,
also BCP 208, which built on https://tools.ietf.org/html/rfc7510#section-5,
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.

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@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>