Re: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn

[<[e-mail]>]

Hi Phil,

Please see in line!


> Van: [e-mail] [[e-mail]]
> Verzonden: zondag 25 maart 2012 17:29
> Aan: Karagiannis, G. (EWI); [e-mail]
> Onderwerp: RE: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn
> surely we're trying to finish the work off, rather than opening up new functionality?
> 'not being precluded' is very different from 'will try to support'!

Georgios: Is not really a new functionality, since it combines the features of RFC 4860 and the PCN specifications to provide the required signaling for PCN.

> on your first suggestion:
> I'm not sure what you mean by 'more than one PCN aware behaviour aggregate between two edge nodes'. 
>If you mean, several forwarding priorities I'd disagree; if you mean several DSCPs each with the 
> same fwding priority, not sure I understand the use case; if you mean ECMP - maybe, but I don't understand 
> what solution you're thinking of (is it something in http://www.bobbriscoe.net/projects/ipe2eqos/pcn/papers/draft-briscoe-tsvwg-cl-architecture-04.txt or some new idea?)
> I'm sceptical, but not sure I understand what your scenario is

Georgios: What I mean is that it is possible that more than one PCN aware aggregates can be used between two edge. If the policy at the edges does not allow it, then only one PCN aware aggregate between the same pair of edge nodes will be used.
What I had to mention is that these two or more PCN aware aggregates will use the same DSCP but will have a different PHB-ID, see Section 2, RFC3140.
This will mean that from the point of view of PCN all these behaviour aggregates that are setup at the edge nodes will use the same (one) PCN-BA.
So the PCN interior nodes will not be aware of the existence of two or more behaviour aggregates.

Regarding the  requested motivating scenario, different scenarios can make use of this. The most motivating one is the scenario described in RFC4860:
    “E2E
   reservations using different preemption priorities (as per
   [RSVP-PREEMP]) need to be aggregated through a Diffserv cloud using
   the same PHB.  Using multiple aggregate reservations for the same PHB
   allows enforcement of the different preemption priorities within the
   aggregation region.  In turn, this allows more efficient management
   of the Diffserv resources, and in periods of resource shortage, this
   allows sustainment of a larger number of E2E reservations with higher
   preemption priorities. For example, [SIG-NESTED] discusses in detail how 
   end-to-end RSVP reservations can be established in a nested VPN 
   environment through RSVP aggregation.”

Please note that the PCN interior nodes are not aware of the existence of two or more behaviour aggregates at the edge nodes.


> on your second point:
> we have always said that PCN is for inelastic flows. with your flow slowing, this is changing the model. we have always 
> said that flow termination is highly unusual action taken in extreme cases when 
> somethng has gone wrong - normally, admission control, plus sensible utilisation, plus 
> flow aggregation, plus that there is lower priority traffic that can flex, should keep the network in a safe operating 
> region. To me, flow slowing sounds like an optimisation that isn't worthwhile.
> So I'm pretty dubious about this one.

Georgios: Using RFC 4495, the reduction of the bandwidth of an individual flow at the PCN-ingress-node can be done immediately. 
So from the point of view of the delay in decreasing the total amount of bandwidth for an aggregate, can be observed that:

o) the situation where a PCN-ingress-node reduces the bandwidth of a 100kb/s flow to 50kb/s (belonging to one aggregate) is the same as the situation that a PCN-ingress-node terminates one 50kb/s flow when two 50kb/s flows belong to the same aggregate.

In other words, the time it takes to terminate a flow is equal (under certain bounds) to the time it takes to reduce the bandwidth of a flow.

Best regards,
Georgios


________________________________________
From: [e-mail] [[e-mail]]
Sent: 25 March 2012 10:15
To: Eardley,PL,Philip,DUB8 R; [e-mail]
Subject: RE: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn

Hi Phil,

The first assumption actuallu allows the possibility of having more than one PCN aware behaviour aggregates being supported between two edge nodes. I think that this is/was not precluded from the current specs.
Or I am wrong?

The second assumption regarding flow slowing is new, but in my opinion was/is not precluded from the current specs.
Or I am wrong?
Note that the goal of flow termination, which is to reduce the bandwidth associated with one PCN aware behaviour aggregate is not changed in order to solve the congestion, i.e., it remains valid.
So the assumption allows the possibility of instead of terminating flows reduce the bandwidth of some flows and achieve the same goal!

Best regards

________________________________________
Van: [e-mail] [[e-mail]]
Verzonden: zaterdag 24 maart 2012 18:04
Aan: Karagiannis, G. (EWI); [e-mail]
Onderwerp: RE: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn

It's Quite a while since I read the edge behavior docs but I don't understand these assumptions. An iea is ask the traffic between two boundary nodes, what's the idea of several? The pcn architecture talks about admission control and flow termination, flow slowing is an interesting idea but seems different to me
________________________________________
From: [e-mail] [[e-mail]] On Behalf Of [e-mail] [[e-mail]]
Sent: 24 March 2012 05:19
To: [e-mail]
Subject: [PCN] hope changes in PCN drafts will not affect validity assumptions in draft-ietf-tsvwg-rsvp-pcn

Hi all,



>From what I can recall the edge behavior drafts could proceed with their publication based on the assumption that the draft-ietf-tsvwg-rsvp-pcn will be standardized in tsvwg.

Due to some changes that are being implemented lately the validity of two main assumptions in the draft-ietf-tsvwg-rsvp-pcn might not hold anymore.
However, this is not clear to me.
I hope that the validity of the following two main assumptions considered in draft-ietf-tsvwg-rsvp-pcn are still valid, without breaking the PCN SM and CL edge behavior specifications:

Assumption 1: More than one IEAs between same pair of PCN edge nodes should be supported, each of them using a different PHB-ID value
Why?: A requesting individual flow has a higher chance to be admitted to an IEA that is NOT in PCN-admission-state
How? When IEA supported by a PCN-ingress-node is in PCN-admission state, then based on local policy, requesting e2e RSVP session (individual flow) should be either rejected or mapped to another IEA that is NOT in PCN-admission-state

Assumption 2: PCN-ingress-node should be able to reduce bandwidth of an individual flow without terminating the flow
Why?: flows will not be terminated unnecessary and at the same time the IEA bandwidth is reduced to solve the severe congestion
How?: When for IEA supported by PCN-ingress-node incoming traffic needs to be reduced then:
based on a local policy and for same IEA, selects a number of e2e RSVP sessions (individual flows) to be either terminated or reserved bandwidth of e2e RSVP sessions (individual flows) is reduced

If these assumptions are not valid anymore then we might need to do changes in the not yet published PCN drafts!

Best regards,
Georgios