Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services

Toerless Eckert <tte@cs.fau.de> Thu, 09 April 2020 23:42 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A553A13EF for <architecture-discuss@ietfa.amsl.com>; Thu, 9 Apr 2020 16:42:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 PBxGTPpm5rUi for <architecture-discuss@ietfa.amsl.com>; Thu, 9 Apr 2020 16:42:56 -0700 (PDT)
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 AC0E83A13EE for <architecture-discuss@ietf.org>; Thu, 9 Apr 2020 16:42:56 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E0F8E548017; Fri, 10 Apr 2020 01:42:51 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D800B440040; Fri, 10 Apr 2020 01:42:51 +0200 (CEST)
Date: Fri, 10 Apr 2020 01:42:51 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Tony Li <tony1athome@gmail.com>, architecture-discuss@ietf.org
Message-ID: <20200409234251.GG44502@faui48f.informatik.uni-erlangen.de>
References: <229AAF4A-C43F-46E9-97C6-99CC124E9B48@gmail.com> <20200409212841.GK28965@faui48f.informatik.uni-erlangen.de> <0A15B52E-2A67-4D6A-AACF-8A92FB67ADEC@gmail.com> <53EFFD37-57EB-4288-AE19-2EB2DC3BDE39@gmail.com> <20200409215925.GA44502@faui48f.informatik.uni-erlangen.de> <4BB15D5F-735F-409D-B518-DD99A4428794@gmail.com> <20200409222341.GC44502@faui48f.informatik.uni-erlangen.de> <952F886C-1B20-4E80-9948-D5D7EFF3BAA6@gmail.com> <20200409231646.GF44502@faui48f.informatik.uni-erlangen.de> <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1936E4A5-6E5A-41AA-BA7F-B9EBEEE170C7@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/-tCYa8gP4VoqKcHvk51d4ScWlK4>
Subject: Re: [arch-d] ETSI launches new group on Non-IP Networking addressing 5G new services
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Apr 2020 23:42:59 -0000

On Thu, Apr 09, 2020 at 04:27:09PM -0700, Dino Farinacci wrote:
> > I don't think i need to run a lot of new things end-to-end across
> > the planet. I'd be happy if i can run it across a metro space to
> > edge-DCs. at least for everything commercially relevant. 
> > global DC to DC traffic is typically across variety of priate
> > networks anyhow.
> 
> Even if you had a completely new 4-hop network (non-IP) with multiple paths, you could not guarantee zero packet loss. And what I understand from the requirements, you can???t have delayed packets either. So retransmission cannot be used as a tool.

Not sure how this relates to my paragraph above, but yes,
solutions that offer higher resilience and lower packet loss
at lowest latency are crucial for more critical services IMHO
in the future.
> 
> So the only option you have with a new protocol or with IP is to send the same packet over diverse paths. The more diverse paths you have, the greater probablity the packet will not be dropped. And for Brian???s point, you have to measure queuing delay to you can pick 5 out of the 10 diverse paths that meet your delay requirement. And the delay will change so quickly, packet will already be launched into a congestive path. 

I would alredy be happy if we had a better overall system standard
to simply operationale path diversity. distributed MRT IGP
extensions was the only thing i rememer we did, and while
its cool, it doesn't offer lowest latency (shorted path
length compared to centralized diverse path calculation).
Hence also proposal from our side like PPR for easier
forwarding plane agnostic path engineering.

What you are talking about are cool ideas which have been
had in more ad-hoc networks for a while now, but i wonder
how well they would really improve resilience over
the more traditional mechanisms (like simple N-path diversity).

>From one of the older discuss i had, ROLL for example
was not allowed way back to charter more forwarding
plane centric functions (stick to routing), so ideas
such as having those intelligent functions such that
flexible forwarding planes like the following did
not happen in IETF yet:

"try to send  packet to link i with up to j retransmissions, max total wait time k, afterwards try link l,..."

Similarily of course extenible to replicate for reasons
of resilience.

> You can only do this with an overlay so the edge of the network can select different paths by simply changing the destination address (either with tunneling or translation). But its a hard problem that may be unsolvable. You would have to set expectations very clearly what this new architecture provides and how and when it fails.

The simple n-path diverse pathset calculation is easy to
use in any network, thats why its a good starting point
the more dynamic mechanisms you mention are still good
research topics IMHO. At least for quantitive evaluations.

> Having said that, you may as well build solutions that are IP based. You don???t really need an IPvN.

If RFC8200 wouldn't make extensions so convoluted and
expensive for controlled networks, i think i could do
everything needed for network layer as IPv6 extensions,
 except things where i really don't like the initial IPv6 
header. For example integrating the best ideas of MPLS.
And whenever i really do not want 2 * 128 bit addresses.
Such as when we come up with better privacy models
where the source address was waste of space.

Cheers
    toerless

> Dino

-- 
---
tte@cs.fau.de