Re: e2e [was: Non routable IPv6 registry proposal]

Joseph Touch <> Sun, 24 January 2021 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 955F63A0E47 for <>; Sun, 24 Jan 2021 08:24:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0m4R1RqNmaTy for <>; Sun, 24 Jan 2021 08:24:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF30B3A0E43 for <>; Sun, 24 Jan 2021 08:24:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=DNHz+BzxNZMxTh4qYOVZEHd2C+mvpBu9NjvUu8ota8Q=; b=cViqnbUfB6wdr++mKGy7iQrDV Gysxl+RhiVuGiaFSIt3PJvl3ZhMFAIyVJ4VKksuILU3DgQCgD/KC41DNNn6wtYtKdm7gFwa7twkD6 CYYa2Oroxnt2goVwxbx0a0qxn1If9/EB9cG+jtf7e5NOp4kBR44FbteZRfv0fm+3JAUCKic10l7Hj c83ffXtUeognWcOloXCyk+fs6mOjlUBPSf3QKbbfzPwnAQdhpuOCVqR1e1lm4OP9eejKHyHB/82wi qo8Lho17R8s46jkqp2SZeZZv4C3e1J89qFDg/JyDp+g1pb7BG0dF2ACAiFhrA/eNlUbWPRgyW9TkP qsbMbOwRg==;
Received: from ([]:58520 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1l3iBa-000Fd6-Q4; Sun, 24 Jan 2021 11:24:27 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_61C476F3-0BEB-4953-8060-26B0120A51E0"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Subject: Re: e2e [was: Non routable IPv6 registry proposal]
From: Joseph Touch <>
In-Reply-To: <>
Date: Sun, 24 Jan 2021 08:24:22 -0800
Cc: Fernando Gont <>, Phillip Hallam-Baker <>, IETF Discussion Mailing List <>
Message-Id: <>
References: <> <> <> <> <> <>
To: Brian E Carpenter <>
X-Mailer: Apple Mail (2.3654.
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Jan 2021 16:24:42 -0000

> On Jan 23, 2021, at 1:47 PM, Brian E Carpenter <> wrote:
> Much as I had concerns about draft-ietf-spring-srv6-network-programming,
> I think we should be clear about what e2e is about. It *isn't* about
> idealised transparency or even about forbidding packet mangling.
> For example, what we said in RFC1958 is:
> "The basic argument is that, as a first principle, certain required end-
> to-end functions can only be performed correctly by the end-systems
> themselves."

Speaking of errors… this is a subtle one. Just because some functions can be performed correctly ONLY at the end systems, that does NOT mean the end is the ONLY performer of such functions (a good example of why the word “only” needs to be placed carefully).

> That wasn't the last word, of course: see RFC3724, for example.
> Of course, that version of e2e does mean that any kind of packet
> mangling needs to be checked to see if it harms the e2e principle.
> For example, the e2e principle tells us that the decision to
> retransmit a damaged or lost packet needs to be taken at the
> originating host (which is why performance enhancing proxies are
> obnoxious). …

Agreed that the end is the only place that can ensure all lost packets are replaced. But it is incorrect that it is the only place where lost packets *can* or *should* be replaced.

ARQ and FEC at L2 can have significant benefit and are widely used. Though I agree that some PEPs are obnoxious, this kind can not only be useful, they provide a necessary ability to at least partly mitigate loss over shorter feedback loops.