Re: [tsvwg] QoS and IP everywhere Was: Naive question

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 09 February 2015 17:19 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE351A1B0D; Mon, 9 Feb 2015 09:19:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 JYeLI1dMfFVu; Mon, 9 Feb 2015 09:19:25 -0800 (PST)
Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 321B71A1AC6; Mon, 9 Feb 2015 09:19:25 -0800 (PST)
Received: by labhz20 with SMTP id hz20so14845726lab.0; Mon, 09 Feb 2015 09:19:23 -0800 (PST)
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:content-type; bh=+Vz6sNNbEZ0qlQ/wtjML7u+QhHM5ozna19H3e7PBJrk=; b=A+VYY4ZUCYrh3MbRYC24Nk0jVlGX3JszkHtlIhJa5+xS7GA+oT+BWV6pXlglg4RdDz eXiK1llN8/jPNiG9YeVIxZ8vzDBZEAwCOfRDWDRtuYKkU/Z/jFfqJ5NdjSdfCzvIUb3l bpAz+ZyuN7pLvtfEDmp/pq8SYiu/yTWwetEb+tbh1m24ekipRn/iRbwR9CEMUQ2fVCUi HERHsbEEJRuqj40ZFjBr1vE02cdqTnLRl3dSAZvnIR3wa0VCB3IxHjmcyQ0tELKDzjRG BYBpNWw5A5XR+opVk7167srey88ZGLBTqJ9XFdtYp21h51yh/70i2V/F8SSCcDZtnvE0 OmDA==
MIME-Version: 1.0
X-Received: by 10.113.11.12 with SMTP id ee12mr18868211lbd.79.1423502363723; Mon, 09 Feb 2015 09:19:23 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.147.193 with HTTP; Mon, 9 Feb 2015 09:19:23 -0800 (PST)
In-Reply-To: <CE03DB3D7B45C245BCA0D2432779493635FE2B@MX104CL02.corp.emc.com>
References: <CAMm+LwjR9_+bL2Ky1Z-bPNhWbJm=FmXn0=OaW_k8ofqnLt=o9Q@mail.gmail.com> <CE03DB3D7B45C245BCA0D2432779493635FE2B@MX104CL02.corp.emc.com>
Date: Mon, 9 Feb 2015 12:19:23 -0500
X-Google-Sender-Auth: c5sDwaC1dB34ULa8edPQOrhV3wg
Message-ID: <CAMm+LwjyjC=5Svr7g7N52sgmnBSjNMMoGTr8AqM6HhY=deAnkw@mail.gmail.com>
Subject: Re: [tsvwg] QoS and IP everywhere Was: Naive question
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: "Black, David" <david.black@emc.com>
Content-Type: multipart/alternative; boundary=001a1133a5b4ba0f60050eaaf874
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/aH-PsZHlTb10HWDnGUyp-BDZwAY>
Cc: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, Michael Richardson <mcr@sandelman.ca>, Richard Shockey <richard@shockey.us>, "tsvwg@ietf.org" <tsvwg@ietf.org>, IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 09 Feb 2015 17:19:28 -0000

On Mon, Feb 9, 2015 at 11:38 AM, Black, David <david.black@emc.com>; wrote:

>  > IP everywhere does not mean that the difference between the network
> and the inter-network goes away. Making
>
> > QoS happen inside a network and across an Inter-network are two very
> different problems.
>
>
>
> I agree -
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/
> recognizes this, and cleanly separates QoS within a network from what
> happens at network boundaries, as does ...
>
>
>
> > Forgetting the distinction between the network and the inter-network
> gives us a choice between only network layer everywhere or only packet layer
>
> > everywhere.
>
> >
>
> > If we recognize the border, we might end up with a stack something like
> this:
>
> >
>
> > ZServ:
>
> >
>
> > A                                   A
>
> > T             Q <-|-> Q             T
>
> > N <--> N <--> N <-|-> N <--> N <--> N
>
> > P <--> P <--> P <-|-> P <--> P <--> P
>
>
>
> Gee, this looks familiar - see RFC 2475 on DiffServ architecture, and in
> particular the difference that it draws between classification
> functionality that is appropriate within a network vs. at its edges (i.e.,
> DiffServ recognizes that border).  The DiffServ Intercon draft is trying to
> iterate across networks, because DiffServ differentiation as currently
> deployed tends not to cross network boundaries well.
>
>
>
> Thanks,
> --David
>

Well that is what is so frustrating about digging into the architecture.

It is obvious to me that we have to re-discover the difference between
networks and inter-networks to make sense of security. For years people
have been spouting nonsense about firewalls having no place on the net,
middleboxes are evil and so on.


What is missing from the IP stack is tools to let people manage their
networks. And one of the reasons those have been missing to date was that
they were the bit some vendors thought they would sell as their secret
sauce to enterprise customers.

But the enterprise isn't where the money is made, its consumer devices that
make the big profits. Take a look at the Apple market cap, bigger than all
the 'Enterprise' vendors put together.

Consumers are not going to be able to manage home automation networks
unless they have tools that make the process really easy. As in, when a box
goes wrong, the network management boxen tells them which box went wrong
with a picture of it.