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

"Black, David" <david.black@emc.com> Mon, 09 February 2015 16:41 UTC

Return-Path: <david.black@emc.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 302441A1AC7; Mon, 9 Feb 2015 08:41:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lOMlmC-hEiPA; Mon, 9 Feb 2015 08:41:20 -0800 (PST)
Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C4E1A1B00; Mon, 9 Feb 2015 08:39:08 -0800 (PST)
Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t19Gd1xM023337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2015 11:39:02 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t19Gd1xM023337
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1423499943; bh=KcFkLsh7r1RqAruzX7CAkeVzBKo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=blg6d+F/CaMORqkVV6RKCnfC40gDQGuKb98ZhRPchbyVCbnUgWyYUfKxfb3c1UmwU 8V6o5tZjHDehNHNO4NnANupZqD44cNDUI/cou8uSjvt7nJr3WeXCTNAb9PmwsyKAJl 5AjjyPIjjlvtiVJZbRCcV5FCJEGATOvxAF8iyWTw=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t19Gd1xM023337
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd05.lss.emc.com (RSA Interceptor); Mon, 9 Feb 2015 11:38:38 -0500
Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.222.70.171]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t19GcgF0013446 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Feb 2015 11:38:43 -0500
Received: from MXHUB203.corp.emc.com (10.253.68.29) by mxhub31.corp.emc.com (128.222.70.171) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 9 Feb 2015 11:38:42 -0500
Received: from MX104CL02.corp.emc.com ([169.254.8.236]) by MXHUB203.corp.emc.com ([10.253.68.29]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 11:38:41 -0500
From: "Black, David" <david.black@emc.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
Subject: RE: [tsvwg] QoS and IP everywhere Was: Naive question
Thread-Topic: [tsvwg] QoS and IP everywhere Was: Naive question
Thread-Index: AQHQRITb8jijbTl+H0ayddR4ABFVEJzogTdQ
Date: Mon, 9 Feb 2015 16:38:41 +0000
Message-ID: <CE03DB3D7B45C245BCA0D2432779493635FE2B@MX104CL02.corp.emc.com>
References: <CAMm+LwjR9_+bL2Ky1Z-bPNhWbJm=FmXn0=OaW_k8ofqnLt=o9Q@mail.gmail.com>
In-Reply-To: <CAMm+LwjR9_+bL2Ky1Z-bPNhWbJm=FmXn0=OaW_k8ofqnLt=o9Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.250.33.67]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D2432779493635FE2BMX104CL02corpemcc_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: DLM_1, public, GIS Solicitation
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/J9S6PxgFGX5wFFkynGhmWx4lFgg>
Cc: Michael Richardson <mcr@sandelman.ca>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Richard Shockey <richard@shockey.us>, 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 16:41:23 -0000

> 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

From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Monday, February 09, 2015 11:07 AM
To: Ruediger.Geib@telekom.de
Cc: IETF Discussion Mailing List; Jim Gettys; Richard Shockey; tsvwg@ietf.org; Michael Richardson
Subject: [tsvwg] QoS and IP everywhere Was: Naive question



On Mon, Feb 9, 2015 at 3:47 AM, <Ruediger.Geib@telekom.de<mailto:Ruediger.Geib@telekom.de>> wrote:
As Brian pointed out, https://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/ proposes a method "how to get the labeling/queueing across the AS boundary". Input is welcome.

Commercial DiffServ interconnection products are available. They may however not be be widespread.

If you however ask the question how to transit the complete QoS concept and codepoints of a sending domain to a customer connected to another domain - that hasn't been standardized yet.
If your expectation is that a consumer (device) sets priorities of packets and carriers honour these markings, a technical and commercial model accepted by all parties is required. I'm not aware of one (I'm not interested in discussing how to get one on this list).
There's also no generally specified set of packet marks within the Best Effort class, which can transparently cross carrier boundaries on an end to end basis. That might offer a separation of WAN and LAN or application QoS marks (should this be useful).

Having had cause to look at Internet architecture in some detail of late for a paper. I think we have actually lost something important with the push for 'IP everywhere'.

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.


One of the architectural questions that comes up is how do we define the difference between the Network (packet) layer and the transport layer? I think the best, cleanest definition is to say that the network layer is stateless. If you have per packet state then you are doing transport.

Which gives a very clean distinction between IntServ and DiffServ approaches to QoS. Both require modification of the switches on the path. But IntServ requires the path to perform some transport layer functions because it requires per session state.

IntServ:

A                                  A
T <--> t <--> t <--> t <--> t <--> T
N <--> N <--> N <--> N <--> N <--> N
P <--> P <--> P <--> P <--> P <--> P

(where t stands for just the QoS part of transport)

DiffServ:

A                                  A
T                                  T
N <--> N <--> N <--> N <--> N <--> N
P <--> P <--> P <--> P <--> P <--> P


That does not mean IntServ is some abomination denying the basic principles of the Internet. Modern devices are far more capable than in 1983. There is no reason to believe that the correct layer at which to cap Inter-network complexity is some fixed universal constant. But it does show it is likely to be harder to deploy.


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

Any normal interaction is going to involve at least three networks, the customer network, their ISP's network and the destination network of the content provider. More usually there will be four networks.