Re: [Stackevo-discuss] When provider networks don't t trust the stack set by the end points ....

Szilveszter Nadas <Szilveszter.Nadas@ericsson.com> Tue, 08 December 2015 09:57 UTC

Return-Path: <Szilveszter.Nadas@ericsson.com>
X-Original-To: stackevo-discuss@ietfa.amsl.com
Delivered-To: stackevo-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052C51AC3CF for <stackevo-discuss@ietfa.amsl.com>; Tue, 8 Dec 2015 01:57:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 VzSIaVHRyPpM for <stackevo-discuss@ietfa.amsl.com>; Tue, 8 Dec 2015 01:57:17 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C06F1AC3D8 for <stackevo-discuss@iab.org>; Tue, 8 Dec 2015 01:57:17 -0800 (PST)
X-AuditID: c1b4fb3a-f79df6d0000013b1-71-5666a97a49b6
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F7.62.05041.A79A6665; Tue, 8 Dec 2015 10:57:14 +0100 (CET)
Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 10:57:14 +0100
From: Szilveszter Nadas <Szilveszter.Nadas@ericsson.com>
To: Linda Dunbar <linda.dunbar@huawei.com>, "stackevo-discuss@iab.org" <stackevo-discuss@iab.org>
Thread-Topic: When provider networks don't t trust the stack set by the end points ....
Thread-Index: AdExPua6p20KTYEoSD+piZoHokKNhAAWebBg
Date: Tue, 8 Dec 2015 09:57:13 +0000
Message-ID: <EA4C43BE752A194597B002779DF69BAE23F20C3A@ESESSMB303.ericsson.se>
References: <4A95BA014132FF49AE685FAB4B9F17F657DADD4A@dfweml701-chm>
In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DADD4A@dfweml701-chm>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE23F20C3AESESSMB303erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7t27VyrQwgyn79C3utkxksji0fAeT A5NHy5G3rB63rr5kDmCK4rJJSc3JLEst0rdL4Mq4cSSw4E5IxYSm/awNjCs9uxg5OSQETCQ+ dC9lgrDFJC7cW8/WxcjFISRwmFFi1dd5zBDOIkaJOesfsoNUsQlYSDSs3MwGYosIJEvMOb+c EcRmFnCUeHTuDTOILSwQIbFo2xpWiJpIiX1/D0HVG0l8mnSRBcRmEVCRmDrlBthMXgFfif7p 58DqhQRcJE51rQSzOQVcJeY+ug52HSPQdd9PrWGC2CUucevJfKirBSSW7DnPDGGLSrx8/I8V wlaUaH/aAHVbvsTpswfZIHYJSpyc+YRlAqPoLCSjZiEpm4WkDCKuJ3Fj6hQ2CFtbYtnC18wQ tq7EjH+HWJDFFzCyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjLeDW35b7WA8+NzxEKMA B6MSD6/B9dQwIdbEsuLK3EOMEhzMSiK8vLPSwoR4UxIrq1KL8uOLSnNSiw8xSnOwKInzNjM9 CBUSSE8sSc1OTS1ILYLJMnFwSjUwFlpfaPjNuvb0mZ8rm45Ou+qgIWZ552qn3efVTzdNatlV faQt+1nEnVcHEjYIT87dvqf3Y2rL/Hv7j2f/vsPatXrRnbsGC87nr3gXd6JietCjCis5fR9D pjscmrYTuDVYTPbMEstbetWbceHMST8uHHHc0ZubNO2WIeehvUlyF7z/9R2S0V02uV+JpTgj 0VCLuag4EQCbJPq4swIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/LO1iRB1USSpBxccIQKujiOWrKdo>
Cc: =?iso-8859-1?Q?Attila_Mih=E1ly?= <attila.mihaly@ericsson.com>
Subject: Re: [Stackevo-discuss] When provider networks don't t trust the stack set by the end points ....
X-BeenThere: stackevo-discuss@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IP Stack Evolution Discussion List <stackevo-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo-discuss/>
List-Post: <mailto:stackevo-discuss@iab.org>
List-Help: <mailto:stackevo-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 09:57:21 -0000

Hi,

Regarding the trust issue in the SPUD signaling, that can be solved by having consequences of a choice and communicating that to an endpoint. Though that is not really declarative communication anymore but at least it is safe to ignore. We summarized such considerations in this position paper:
https://www.iab.org/wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_16.pdf

When it comes to multiple layers in SPUD, I am not sure I understand your point. I do not see a problem with middleboxes adding additional information to e.g. the CBOR map in the SPUD header (as long as that does not cause MTU problems). With a well-defined key any header can be added, it is quite flexible. If there are MTU issues then a separate SPUD signaling PDU can be created. This is valid for the SPUD prototype protocol, when it comes to the general SPUD concept there is no consensus: some people think that we shall limit the possible types (and length) of metadata as much as possible.

Cheers,
Szilveszter

From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On Behalf Of Linda Dunbar
Sent: Monday, December 07, 2015 23:31
To: stackevo-discuss@iab.org
Subject: [Stackevo-discuss] When provider networks don't t trust the stack set by the end points ....

I find the use cases for SPUD are very real and definitely need a good approach to make it happen.

However, a lot of discussions have been centered around the SPUD layer being encoded by End Points, and expect the network to apply certain rules for those traffic. Having an In-band standard signaling among end points and network has its advantages: allowing network to treat packets without getting into the encrypted payload, and not requiring any  extra components across the networks between the end points.

However,  Virtually all traffic today go through provider networks (most likely multiple). Provider network usually don't (can't) trust the signaling or requests from end points because any end points can set their own traffic as "requiring the least latency" or "passing through the network".  Provider network set traffic based on the SLA clients pay.  For example all the DiffServ set by the endpoints are ignored by the provider network, instead Provider Network set its own DiffServ based on the SLA from the customers.

The Network Service Header (NSH) introduced by SFC (http://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ ) is effectively another layer of stack added to the packets (added by the ingress node).

My question is:
Should SPUD allow multiple types of layer added to data packets? Or only focusing on the layer end points can add?

My two cents.

Linda Dunbar