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

From: Linda Dunbar <[email-masked]>
Date: Mon, 7 Dec 2015 22:30:40 +0000

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

---

From: Szilveszter Nadas <[email-masked]>
Date: Tue, 8 Dec 2015 09:57:13 +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:[email-masked]] On Behalf Of Linda Dunbar
Sent: Monday, December 07, 2015 23:31
To: [email-masked]
Subject: [Stackevo-discuss] When provider networks don't t trust the stack set by the end points ....

My question is:

My two cents.

Linda Dunbar

---

From: Brian Trammell <[email-masked]>
Date: Tue, 8 Dec 2015 13:29:21 +0100

Hi, Linda,

> On 07 Dec 2015, at 23:30, Linda Dunbar <[email-masked]> wrote:
> 
> 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.

As presently envisioned in the stackevo-explicit-coop draft, this is not so much an expectation that the network will apply certain rules, as an exposure of information about traffic in the hope that the network will use that information, together with network-specific policy, to make better decisions about how to handle the 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.

Yep. A big issue here, in my opinion, is that DSCP provides an imperative signaling facility, where each codepoint is tied to some particular "type" of traffic (see table 2 in RFC 4594), such that (1) most of the treatments expected can disadvantage other traffic on the same paths and (2) there is an incentive to mark "better" treatment than required for a given application.

Removing incentives to over-mark would be one way to make this work in an interdomain environment. There are several approaches here: First, markings that are declarative ("this traffic has property X") as opposed to imperative ("reserve 300kb/s for this flow"), such that the endpoint cannot predict the outcome of the marking, would tend to reduce incentives to lie. One could also define markings in terms of tradeoffs as opposed to priorities: latency-sensitive traffic generally has higher loss tolerance. Markings for "worse than standard" treatment could be used for loss- and-latency tolerant bulk transfer transports, as well, trading off something against nothing.

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

Not sure what you mean by multiple types of layer. Certainly, a lot of the thought that's gone in to SPUD as of the present set of requirements is end-to-end, but there's no reason the mechanisms couldn't be applied to two tunnel endpoints as opposed to application endpoints.

Thanks, cheers,

Brian