Re: [irtf-discuss] Why do we need to go with 128 bits address space ?

Fred Baker <fredbaker.ietf@gmail.com> Thu, 22 August 2019 03:06 UTC

Return-Path: <fredbaker.ietf@gmail.com>
X-Original-To: irtf-discuss@ietfa.amsl.com
Delivered-To: irtf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D3212003F for <irtf-discuss@ietfa.amsl.com>; Wed, 21 Aug 2019 20:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: 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 hHbExenwAoJY for <irtf-discuss@ietfa.amsl.com>; Wed, 21 Aug 2019 20:06:10 -0700 (PDT)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 2B86E120018 for <irtf-discuss@irtf.org>; Wed, 21 Aug 2019 20:06:10 -0700 (PDT)
Received: by mail-pg1-x534.google.com with SMTP id k3so2578684pgb.10 for <irtf-discuss@irtf.org>; Wed, 21 Aug 2019 20:06:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pZVs5obqBi4olSBxb3SqS6OUTw00BvPHLLWSrNjWpGc=; b=OW9PnS8rvwI9uYeHhQCt+6Iz0naDqK6KWJmjxkEgqQNRMMFJct0tm3oEvYGU0zVD2o eX9nuFchSP2IaBPnqiiDITb+RbpDJPevXbx+x9zVT+NarPulP4v3ST1ROe3sMxHKby8M B6KjhoEE85AOhUZ987p1MVS5Kxbl4X10wjtJUs+8RUegiSatSI5v+PI/xZQjOWzwp7lD cv8EBY3M/zauuJoE2Sqn3ufT0XLcZqp+5xxQAGyiR3CiGLFdCUzRaqcMIv8LjtTr06jI G8MVU1pUJ25mvkZfNhXPEG5YWOtlIpzKYDuwFc29wjHrNSj8Ga4f447MWfQgmtrpmAzF oYig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pZVs5obqBi4olSBxb3SqS6OUTw00BvPHLLWSrNjWpGc=; b=lAczd5iPZs0V9LeAu6SJvo4zYEi7TY/phtWLR/3LQP9S9IN6wsyfSaUi1JRuaYBReN n/0ivcoF6GHk0LvaRGvz4NClwISDn16WkSGMbSUKq+wTf+3FVsZPv0GgzD8VCd8J9QOu 3IqSk+Q2/X0lpOATx+X8wGmXYktWIxgZy0H9ylNubm3+rLomcqPw1lxxNh3My8A668Fh e7cV6a/CeaBQTBWjqFXIBFs+MTYJ5bvOXKuCuS7uPwRS/JciEHDjBVIQIn6F4maRx4Yt tfMSqP+rTIJU1wfRknHgjAIrrLW0P4wycJW46zXSI1ndw3fQep05L66RN8d+iMc/w7xo 70QQ==
X-Gm-Message-State: APjAAAWWdC033zFisFunFwqYZIs2C9vOvW6xfkwe9dq+KqPT3RSVYnR2 xr/j6vU7fhICcsNdW6oGZwM=
X-Google-Smtp-Source: APXvYqzqCGwRjDZjmlyFDk1cPVUhzJXOpq3P2kWUIzCCEPlvZDO9rhCpaqhhMutDERIGA4nUn6yrjA==
X-Received: by 2002:a17:90a:fc90:: with SMTP id ci16mr3186165pjb.48.1566443169567; Wed, 21 Aug 2019 20:06:09 -0700 (PDT)
Received: from ?IPv6:2600:8801:d004:600:9c18:cfe1:da1f:c221? ([2600:8801:d004:600:9c18:cfe1:da1f:c221]) by smtp.gmail.com with ESMTPSA id v184sm21798112pgd.34.2019.08.21.20.06.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Aug 2019 20:06:08 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\))
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <ded4f1d5-924b-77f1-90f4-11dc4869a8a7@necom830.hpcl.titech.ac.jp>
Date: Wed, 21 Aug 2019 20:06:07 -0700
Cc: Robert Raszuk <robert@raszuk.net>, "irtf-discuss@irtf.org" <irtf-discuss@irtf.org>, "6man@ietf.org" <6man@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C7ABF067-3376-46EF-BB57-7275D6350133@gmail.com>
References: <CAPTMOt+cGhBqHmT3yZVChv-PCMqxT-WPDcDdM3RuTc1TMfFeVg@mail.gmail.com> <4278D47A901B3041A737953BAA078ADE148C2FE4@DGGEML532-MBX.china.huawei.com> <10708d7b-a4bc-f9d8-a644-7c5617f5ebf3@gont.com.ar> <CAPTMOtLyiUpi4L+7TpLePvm=JtpEnw-Yv1NCKvO63_HK2jFnCA@mail.gmail.com> <447e5dae-2ae9-b9fe-baa2-111c028d3b68@necom830.hpcl.titech.ac.jp> <CAOj+MMH=wb+v137TvQkZ+KxaBobA8qYmvoHkFzEgi9-PP-Lqxg@mail.gmail.com> <df102b3b-d337-8852-c5dc-f7aa4f479d77@necom830.hpcl.titech.ac.jp> <CAF46EB5-03AE-495C-A85D-73B3A9B7EB02@gmail.com> <ded4f1d5-924b-77f1-90f4-11dc4869a8a7@necom830.hpcl.titech.ac.jp>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
X-Mailer: Apple Mail (2.3578.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/irtf-discuss/c0s7dOcIBiR5hsM9VJL2MTVDWWQ>
Subject: Re: [irtf-discuss] Why do we need to go with 128 bits address space ?
X-BeenThere: irtf-discuss@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF general and new-work discussion list <irtf-discuss.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/irtf-discuss/>
List-Post: <mailto:irtf-discuss@irtf.org>
List-Help: <mailto:irtf-discuss-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/irtf-discuss>, <mailto:irtf-discuss-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2019 03:06:12 -0000

Actually, I would argue that the essential paragraph is the first sentence of the introduction. The paragraph you quote is commonly quoted, but the introduction is far more applicable and useful.

"The principle, called the end-to-end argument, suggests that functions placed at low levels of a system may be redundant or of little value when compared with the cost of providing them at that low level." The paper goes on to amplify the concept by arguing against retransmission within the network (which was common on LAPB links when the paper was written), and to discuss reliable networks, which was a major argument between the ARPANET designers and the designers of X.25.

The paragraph you quote suggests that the key decider in any session is the application; that's true to the extent that the application selects the destination. But even that has issues; in multicast or anycast, the application at most selects the service, and in unicast, it doesn't select the route. But the key point, and the point that people usually argue based on the paper, is that a lower layer shouldn't preempt or surprise a higher layer. It is a service, carrying out instructions from the layer(s) above it, and if it does nothing else it should faithfully implement those instructions - rather than, for example, sending the packet somewhere else.

> On Aug 21, 2019, at 5:27 PM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
> 
> Fred Baker wrote:
> 
>> I'm familiar with the paper "End to end arguments in system design"
>> as well. I'm also familiar with John Day, although I suspect I have
>> learned more from him than he has learned from me.
> 
> Good. So, you should be aware that the essential paragraph
> of the paper is:
> 
>   The function in question can completely and
>   correctly be implemented only with the knowledge
>   and help of the application standing at the end
>   points of the communication system. Therefore,
>   providing that questioned function as a feature of
>   the communication system itself is not possible.
>   (Sometimes an incomplete version of the function
>   provided by the communication system may be
>   useful as a performance enhancement.)
> 
> applying it for multihoming:
> 
>   Multihoming can completely and
>   correctly be implemented only with the knowledge
>   and help of the application standing at the end
>   points of the communication system.
> 
> note that "application" of the paper actually includes
> transport and network layers of the end systems.
> 
>> That said, we don't operate on the end2end principle in the Internet,
>> in the sense of the application determining the route its packets
>> will take to a destination.
> 
> It has nothing to do with the end to end argument quoted above.
> 
>> it uses routing protocols scubas BGP, OSP, and IS-IS t > determine the routing of packets without the application being aware
>> or involved.
> 
> For proof and extension of E2E argument to intermediate systems (not
> actually end to end, anymore), see my lecture note:
> 
> 	http://www.ocw.titech.ac.jp/index.php?module=General&action=DownLoad&file=201904901-2662-0-35.pdf&type=cal&JWC=201904901
> 
> the last slide explains how OSPF follows the E2E principle better
> than RIP.
> 
> 						Masataka Ohta