Subject: Re: [PCN] Off list: Comments on re ecn border cheat

From: Bob Briscoe <[email-masked]>
Date: Fri, 22 Dec 2006 17:55:53 +0000

Rüdiger,

The most important part of this mail is right at the end in response to 
your sum-up. On the way are my clarifications where I think my draft must 
have confused you...

At 16:34 18/12/2006, Geib, Ruediger wrote:
>Hi Bob,
>
>although border cheating isn't part of the currently
>discussed pcn charter, I prefer to communicate my
>comments using this mail exploder. I'm happy to
>continue this discussion privately, should others
>feel this to be preferable.

As no-one seems to have objected to this being on-list, let's continue.

>You propose a mechanism allowing to identify ingress
>gateways to a PCN region ignoring feedback on ECN
>marked packets which was given them. Your
>argumentation is that intermediate transit networks
>providing bulk CL transport must have a way to
>ensure "fair use of resources" while maintaining the
>agreed CL service level.
>
>You are right in your conclusion on the required
>ability of a transit network to monitor the behaviour
>of traffic sinks

...and sources

>after pre congestion notifcation
>occurred within this transit network, I think. While
>I think, that the mechanism you propose is smart and
>may work, I'm not sure, whether the accounting
>mechanism surrounding it should or could be
>standardised by IETF.

Certainly, I don't expect the accounting mechanism to need IETF standards. 
My intent is always to give operators the freedom to choose what they agree 
bilaterally with each other. The intent was purely to standardise a new 
metric (downstream congestion) that can be used in various ways by 
operators for accounting at borders.

[Network economics says that the true cost of usage of a network is solely 
the congestion, and pricing in a competitive market will gradually converge 
to true cost. So it's important that a network architecture provides 
congestion as a metric, for commercial agreements to be built on, given its 
in end-users interests for the Internet market to be competitive.]

Does the I-D make it clear that I'm not expecting IETF standardisation of 
the accounting? I tried to say this in the para in section 5.3 on 
Pre-requisite Contractual Arrangements, starting "operators are free to 
choose how they incorporate it into their interconnection contracts..."? Or 
should I say this more explicitly somehow?

If this gets chartered later, this scheme would require IETF 
standardisation of the behaviour of edge gateways (the draft includes some 
MUSTs and SHOULDs in this respect), but there will be no need for the IETF 
to standardise any accounting procedures at borders. Accounting procedures 
might be standardised elsewhere (e.g. ITU-T, ETSI-TISPAN). But there will 
still be a need for this informational draft to explain the overall intent.

I will think how I can make all this standards intent clearer.

>I'd prefer not to enter a detailed discussion on
>the usefulness of your proposed solution. Instead,
>I'd like to list a couple of thoughts coming to
>my mind:
>
>- The egress gateway feeds back the PCN information
>   to the ingress gateway. It could at least monitor
>   RSVP signaling after PCN feedback has been given
>   by it.
>   If it expects PATH messages after PCN feedback
>   to be followed by PathErr sent from the ingress
>   and receives refreshes instead, a cheat is easily
>   identified. But that is obviously of no help, if
>   the traffic contract of an admitted reservation
>   isn't kept.

Yes, the egress gateway can police reservation traffic because it 
understands flows. I took that as a given - something that the introduction 
of PCN doesn't alter. I need to make that clear. Thanks.

Imagine the interior networks A,B&C in the generic scenario shown in Fig 1 
can't see reservation signalling at all (the ingress & egress gateways 
could even encrypt signalling between themselves). The anti-cheating 
mechanism ensures networks A,B&C can encourage the edge gateways to do 
admission control properly even tho they don't see the per-flow signalling.

>- Ingress/Egress gateway per flow policing probably
>   is the only way to ensure correct behaviour of
>   sources (and avoid cheats on consumed bandwidths).

Agreed - we're not changing that - I'll make that clear.

>- The transit networks sell a bulk service. They
>   aren't aware of any per flow events and don't
>   care as long as the CL/PCN service operates
>   properly.
>
>- The transit provider charges for CL traffic
>   volumes

[Charging for CL traffic volumes isn't a particularly necessary or sensible 
proposition (if there's no congestion, traffic volume doesn't cost 
anything), but they could do this.]

>and provides an SLA on two things:
>   * CL performance (close to loss free)
>   * Probability to cause ECN marks to be set on
>     an internal bottleneck (let's call it a "network
>     busy indication", should have a low probability).

Yes, that's one possible SLA.

>- Per transit domain (ingress-egress?) aggregate
>   PCN and CL reports may have to be produced anyway.
>   They prove who has contributed to a network busy
>   situation in a chain of networks for ECN marks.
>   For CL traffic, they prove loss free operation.

The phrase "(ingress-egress?) aggregate" is /not/ what I am suggesting. It 
sounds complicated whereas the idea I have described is designed to make 
border accounting very simple.

There is no need for a transit domain to separate up its traffic into 
ingress-egress aggregates. All it has to do is measure the whole bulk of CL 
traffic crossing its border with another operator (say the A->B border) 
over say a month. This measurement can remain local to that border and 
requires no comparison or correlation with any other measurements from any 
other border. The SLA between A and B only depends on this local 
measurement of traffic between them. They both see the traffic at this 
point, so they don't have to trust any measurements from anywhere else in 
the network.

Given the rest of the protocol arrangement, this local border measurement 
alone tells them how much congestion A has dumped into B.

>- The downstream egress (gateway) can't determine
>   where and by which network an ECN mark has been
>   set. I'd expect the egress border routers/gateways
>   noticing ECN marked traffic not to have an interest
>   in cheating as they could hit own customers.

The re-feedback solution doesn't rely on someone not cheating /just in 
case/ they hurt their customers - it aims to make the incentives unambiguous.

Without re-feedback, an egress gateway seeing PCN marking might suppress 
the marking or suppress PCN feedback on the basis that the pre-congestion 
was in an upstream network. It could gain from selling more reservations to 
its downstream customers. It might reckon that the service to its own 
customers wouldn't be degraded, because PCN marking doesn't mean the 
upstream network is actually congested yet, so it can eat into the other 
network's other services (e.g. corporate VPNs).

With re-feedback, if an upstream network is congested, and the egress 
gateway suppresses the PCN marking, or the feedback, this leads to a 
'negative' balance at the border where this traffic arrives from the 
upstream network. The mechanisms described in the draft allow the upstream 
network to detect this negative balance and remove such traffic flows (and 
any expected SLA would give them the incentive to do this).

>- The ingress can only cheat on a secure basis, if
>   it can be sure that it isn't the own network
>   producing the ECN marks. This assumes some form of
>   ECN feedback from its border router (assuming the
>   ingress gateway to be part of a domain, not a
>   single service production point).

No, again I don't think you're reading it right. There is no feedback from 
border routers. The whole idea is to simplify border routers in the future.

The re-feedback mechanism only requires feedback (at a slow rate) from 
egress to ingress gateway. Border routers merely forward traffic. And they 
meter passively for local use only, as we discussed earlier.

[If this becomes the way a border works, it should eventually be possible 
to have a straight-through optical interconnect at the border. Of course, 
there are other things border routers do in the data plane that are 
problematic to do in pure optics, but it will be useful to know we can do 
inter-provider admission control without adding to the list of things that 
require an optical-electronic-optical conversion.]

>- The hard part seems to be to identify and trace
>   back a cheater in the case of a chain of transit
>   networks and pre congestions marks set by a
>   downstream network are ignored by an upstream
>   ingress gateway. But that assumes that the ingress
>   operator knows that congestion isn't occuring close
>   to him and probaly also requires the egress gateway
>   to cooperate.

I have chosen not to try to help networks /identify/ the source of a cheat. 
The re-feedback solution ensures that, where there are sensible penalties 
agreed bilaterally between networks for breaking SLAs, a cheating network 
will have to pay a penalty to its neighbour that makes it not worth 
cheating. The ultimate effect will be the cheater pays, and the network it 
harmed eventually receives the penalty. Other non-cheating networks that 
may be between them will both pay and receive penalties, effectively 
passing along the penalty.

[Whether everything balances out fairly depends on the SLAs they all agree. 
I have described at least one type of SLA that would balance out fairly if 
they all used it. However, I don't want to mandate that they must use just 
this one, of course.]

Penalties proportionate to the cheat /deter/ cheating. They don't 
/identify/ the cheater. In this scheme, just because you make your 
neighbour pay you a penalty, it doesn't mean you think your neighbour is 
cheating. Other much more complicated probe-based schemes might be used (in 
parallel) to /identify/ cheaters, but I'm proposing something simpler but 
sufficient.

I guess I need to start by explaining this motivation.

>To sum up, I'd prefer a deeper analysis of the scenarios
>and architectures around cheating before discussing
>solutions.

Certainly. I tried to write up both the problem and the solution, so that 
anyone who cared to read it all could start to satisfy themselves that PCN 
potentially had enough legs to go beyond just an intra-domain scenario.

I would be very happy to take a more measured approach to this whole area, 
if others are interested too. In that case, yes, we should start with a 
problem statement alone. I suggest the general problem is how to police 
microflow admission control at borders without per-flow processing. Or we 
could limit the scope of the problem to a PCN context.

Even though this isn't yet PCN chartered work, would you be interested in 
working on an I-D on this with me in parallel to the PCN w-g, so it's ready 
for when the PCN group re-charter in about a year's time?

Once the problem is clarified, we should see if we can dream up other 
solutions. However, policing of a response to network layer congestion by 
the transport was a very hard problem to solve elegantly. Solving it across 
an internetwork has been much much harder. So I suspect any alternative 
solutions are going to look pretty similar to this one, unless someone 
makes an innovative breakthrough.

>I've read the March version of your draft - after a brief
>glance on the June version. I still think they mostly
>represent my thoughts on your input.

Diffs from the previous draft were minimal. You can see them hilited via a 
link at:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#repcn>
For the benefit of the list, you can also get the draft in various formats, 
and presentations of it via this link.

Merry thingy

Bob

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196  

_______________________________________________
PCN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pcn