QoS and IP everywhere Was: Naive question

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 09 February 2015 16:06 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 1336C1A0354; Mon, 9 Feb 2015 08:06:42 -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 1SY1dct0PQzE; Mon, 9 Feb 2015 08:06:38 -0800 (PST)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 524DA1A1A5C; Mon, 9 Feb 2015 08:06:37 -0800 (PST)
Received: by lams18 with SMTP id s18so14392698lam.13; Mon, 09 Feb 2015 08:06:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=fA8Xi613nYpsfXdwv0CFVFOXecGVjaLWbjcVp7HTTCY=; b=ZGDe3WwwB3VDwIVC8FiVUH2BfFMHFiVoDR2biNrXJ+rxMRFFNFF2+4Ad+BxCiJoiEo q8n8fqRKqnB32S/pkRq5LfT3udUgtejBk8uyEDexUia5hQO6mjnWE1QmcEQN1iddLr+f wVFglAAuygmNnDDL6oM7UTjzJmj5dferXZPQYE94lhas/4AQ1xOhCrHYgF0AH9Le4M6G 0H1h4VpB+QFidFHE2o9AZ08M23u5nKCuQJuHA7ieR7QeKnyVyB8UCnx1Kdll7w5mY4K0 hYfoR3qtaYfzUTL5JUH+zrdVj93Zff0bTknGnT34JnyuVSuk2ViEsYaPeQKtzm9TxMUX OvzQ==
MIME-Version: 1.0
X-Received: by 10.112.243.12 with SMTP id wu12mr17785479lbc.91.1423497995870; Mon, 09 Feb 2015 08:06:35 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.147.193 with HTTP; Mon, 9 Feb 2015 08:06:35 -0800 (PST)
Date: Mon, 9 Feb 2015 11:06:35 -0500
X-Google-Sender-Auth: mYoYp9Ui9a0D7m567eyAHrGdV5Q
Message-ID: <CAMm+LwjR9_+bL2Ky1Z-bPNhWbJm=FmXn0=OaW_k8ofqnLt=o9Q@mail.gmail.com>
Subject: QoS and IP everywhere Was: Naive question
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Ruediger.Geib@telekom.de
Content-Type: multipart/alternative; boundary=001a1133ac5261eb8d050ea9f460
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/LKGNvwSPuBGYtg6n7i-LuElwy3A>
Cc: IETF Discussion Mailing List <ietf@ietf.org>, Richard Shockey <richard@shockey.us>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Michael Richardson <mcr@sandelman.ca>
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:06:42 -0000

On Mon, Feb 9, 2015 at 3:47 AM, <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.