Re: ietf.org end-to-end principle

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 17 March 2016 13:04 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0D712D946 for <ietf@ietfa.amsl.com>; Thu, 17 Mar 2016 06:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 44uMYlvWDjoG for <ietf@ietfa.amsl.com>; Thu, 17 Mar 2016 06:04:50 -0700 (PDT)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (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 2B69B12D8F1 for <ietf@ietf.org>; Thu, 17 Mar 2016 06:03:29 -0700 (PDT)
Received: by mail-lb0-x22b.google.com with SMTP id oe12so68152802lbc.0 for <ietf@ietf.org>; Thu, 17 Mar 2016 06:03:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Izl2ny2CVq83nMiuUI0jWB/tAdH/4jAdYW04aTDvXNo=; b=0BdyAV4HcjYIQnq8jV9AhDQjExe5Y8uG+YmL+SKHkGUMObHpaVsTGdencIP1tz6hKy IW8hao2+x+MQWC/JhE98uEchRIApTdYQuaYITrApH/FYitgOAjUdBwntpjEagzlJfvLo XEzrfvbCV3c49XgcY+v4AMZX646FbssUl1FeS/jvK7BvO/TzpVCeF7AxFOW3Avzo4A7z lbG4U6zSq79SEzUYbE4DUWwNz0FGdQftkbWTFQpBn4Km1rRAuy8jES67HFGrGr5Np00j c/XWo4iTOD+kO+Y5XwZQH3AggAOhhMsj7qeJg9sbW4yWZEywTQFOmoOQ4UVTFPKX+LBW r8gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Izl2ny2CVq83nMiuUI0jWB/tAdH/4jAdYW04aTDvXNo=; b=iq6OFOOyTQ0jL0GIsoyuRi0JijxVKUdnqsnmYiI5cfAF/Z/4ifeI30ZQHILWYR/uyX 1+BGB1gc36FVBtmpsZAWJFzlOayxyjmb+Nsi8WpYHyjkrBAfN32I3+F5BtUA7G5WHQFG lF5/KdbvVnfidt62erLt5HHZ46K8IuYkINBMIDnWuxzlMaRoc8onewuGIH0a09Cyh5Xn GPoQL7E7pOnYMk20/Lg+5tPTE1atGpzYBtbZeyuYZGEKfGm6pcQ2pUNbCFNRxUBHnaVU ejk1Ta4uDMJyBaSeb+rmPFHgBS9jCCX+1//+j7sz2Q6pCgb1AL3fm+f6gGPnXBtKadni lIVA==
X-Gm-Message-State: AD7BkJKMK4zZbP2Mkma/8CMbOXN2k/DDFEuCmz9KKsiCYgrgiOi71AAkFQKJPp6LC94viQ2AM65GzlBHbmqIwQ==
MIME-Version: 1.0
X-Received: by 10.112.140.129 with SMTP id rg1mr3793301lbb.80.1458219806855; Thu, 17 Mar 2016 06:03:26 -0700 (PDT)
Sender: hallam@gmail.com
Received: by 10.112.151.67 with HTTP; Thu, 17 Mar 2016 06:03:26 -0700 (PDT)
In-Reply-To: <56EA8908.5050109@cs.tcd.ie>
References: <56E90BF9.4090306@cisco.com> <871189680.1322359.1458113811142.JavaMail.yahoo@mail.yahoo.com> <CAHw9_i+yFhJVYvcMLSEgkOkqJjZBsQicCQsi13SaoVQuzxqc8g@mail.gmail.com> <5D6893D1-D61C-490C-91EF-CA5E5C1F484A@piuha.net> <56EA63E3.2070602@restena.lu> <VI1PR07MB15815DEAB1939141F0DCCCF3BC8B0@VI1PR07MB1581.eurprd07.prod.outlook.com> <56EA82FC.5050400@restena.lu> <6D32668528F93D449A073F45707153D8BEC8C8FA@US70UWXCHMBA03.zam.alcatel-lucent.com> <50BC4E4E-822F-4E2F-8F0F-ABE48A5E49E8@telefonica.com> <56EA8908.5050109@cs.tcd.ie>
Date: Thu, 17 Mar 2016 09:03:26 -0400
X-Google-Sender-Auth: MAqjRjwc-n_V701Kh19y3uIKRTQ
Message-ID: <CAMm+LwgjY6f3MMCWJ9nMk-pQ_dtNuT6E2Qj4Qy+=fcB6gvgSyg@mail.gmail.com>
Subject: Re: ietf.org end-to-end principle
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/a1-232Bxl9fjewW0TR9avoeXQ88>
Cc: Josh Howlett <Josh.Howlett@jisc.ac.uk>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2016 13:04:57 -0000

On Thu, Mar 17, 2016 at 6:38 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
>
> On 17/03/16 10:31, DIEGO LOPEZ GARCIA wrote:
>>  whether the good-ole e2e principle is no longer applicable
>
> I always think of it as the end to end argument, not principle,
> and from that perspective, I think it remains entirely applicable.
>
> S.
>

Exactly. And the end to end argument is entirely about the decisions
you make about placing complexity.

What has not changed in 30 years is that the Inter-Network remains an
area where complexity is to be avoided. If you are working at the
packet layer, the end-to-end principle is unchanged.

Above the packet layer, the end-to-end principle was never absolute
and it can't be. A given bilateral communication can only be initiated
by one party which means the other has to be the responder. It is not
possible for an initiator to communicate directly with an initiator.
The only way such a communication can be established is if they both
talk to an intermediary that can act as a responder for both.

If you look at the design of SMTP, you will see this architecture has
been in place for 30-odd years. And it is in Jabber and pretty much
every other 'peer to peer' scheme.


In every protocol, we try to reduce complexity wherever we can. But
there is always a minimum that can't be reduced except at cost to
functionality or performance or creating complexity elsewhere.

If you read the end-to-end paper you will find arguments against
putting that complexity at the ends as well as the network core. In
many but not all cases, a middlebox is exactly where it should go.