Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed)

[<[e-mail]>]

Hi Phil,

Thanks for the comments! Please see in line!

> Van: [e-mail] [[e-mail]]
> Verzonden: maandag 26 maart 2012 16:13
> Aan: Karagiannis, G. (EWI); [e-mail]
> Onderwerp: RE: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed)
> Assumption 1
> thanks for this.
> note you don't need to change the definition of IEA - just use the definition 
> it already has (in PCN architecture)
Georgios: Okay, thanks I will do that!
> Assumption 2
> please can you point me the right bit of 4860 - about reducing the reserved 
> bandwidth of individual rsvp sessions. couldnt find it immediately.
> whilst mathematically reducing one 100kb/s flow to 50kb/s is equal to 
> terminating one of two 50kb/s flows - however, it requires the PCN 
> decision node to understand that the current 100kb/s inelstic flow has 
> another state where it can operate as a 50kb/s inelsatic flow. it seems 
> to me this requires significantly more complexity (state at decision point, 
> decision making process, possibly signalling etc).
> Again: termination is supposed to be a 'quick and dirty' function when 
> something has gone wrong.
Georgios: RFC 4860 uses RFC 4495 to do the reduction of bandwidth. The Aggregator is already informed before hand about how much bandwidth should be reduced from certain individual flows. So the Aggregator can reduce the bandwidth of these flows at the moment that an amount of bandwidth needs to be reduced from the IEA. This is similar to the situation that a flow needs to be terminated and the Aggregator reduces the complete allocated bandwidth of that flow.

> Anyway, having slept on our chat at the social, I suggest a way forward is the following.
> The draft should define signalling for the scope of PCN, as it's been assumed so far, 
> ie don't mention these two assumptions. This enables PCN to be finished.
> These two extra assumptions are things that should be invisible to 
> PCN - it's just fine-grained information hiding within the policy 
> and decision functions. For instance, we have never talked about a policy 
> on how the decision point should decide which flows to terminate 
> (just how much it needs to terminate) - it could choose randomly, it could 
> choose the most recently established, it could choose the customers who are 
> least important etc. I think your 'flow slowing' is just another piece of policy 
> that PCN doesn't need to talk about. (You could actually say the same thing 
> about assumption 1)

Georgios: Okay, great! 
So your suggestion is to describe in the draft the situation that the severe congestion is solved by terminating flows. As an addition to that,  the draft will emphasize that in some situations different policies can be used to solve the severe congestion, where instead of terminating the complete bandwidth allocated to one or more flows and by using the mechanisms specified by RFC4680 and RFC 4495, only a percentage of the bandwidth allocated to one or more flows will be reduced.

> in passing, note that PCN is about PCN-flows. RFC5559 defines:-
>    o  PCN-flow: the unit of PCN-traffic that the PCN-boundary-node
>       admits (or terminates); the unit could be a single microflow (as
>       defined in [RFC2474]) or some identifiable collection of
>       microflows.
> since your draft needs to cover the relationship of the e2e signalling & PCN, 
> you need to explain the relationship between the e2e rsvp flows and pcn-flows. 
> i suggest you pick the easiest case, which i presume is a 1:1 mapping.
> anyway, going back to my original comments -
> you can delete the one about many-to-one mapping (now you're deleting assumption 1)
> but i think the others still apply.

Georgios: The mapping of e2e rsvp flows to pcn-flows is a one-to-one mapping. 
However the mapping of the RSVP generic aggregated reservation states to the PCN IEA is a many-to-one mapping.

> thanks
> phil

________________________________________
From: [e-mail] [[e-mail]] On Behalf Of [e-mail] [[e-mail]]
Sent: 25 March 2012 23:30
To: [e-mail]
Subject: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed)

Hi all,

In order to satisfy the comments received up to now I am willing to provide the following changes in the draft-ietf-tsvwg-rsvp-pcn.

Proposed change:
Each ingress-egress pair supports only one ingress-egress aggregate. This is identical to what any PCN specification specifies.

The Aggregator (ingress), and DeAggregator (egress) however, can support more than one RSVP generic aagregated reservation state belonging to the same PHB, see RFC4860. The RSVP generic aggregated resevation states that are maintained between the same pair of ingress-egress will use the PCN-BA, which is actually using the same PHB as these RSVP generic aggregated states.

This means that all these RSVP generic aggregated reservation states will use the same PCN admission control procedure, since they will use the same PCN-BA in the PCN domain.

Note that the definition that is given for IEA in draft-ietf-tsvwg-rsvp-pcn-01.txt needs  to be modifed to satisfy the above. Moreover, the last rule given in Section 3.1 that is associated with the admission control procedure needs to be modified to address the fact that all the RSVP generic aggregated resevation states will use the same PCN admission control procedure.
So assumption 1, listed in a previous email does not need to be supported anymore!

What is still remaining is the need of having assumption 2 supported:

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 using the features provided by RFC 4860 a number of inelastic e2e RSVP sessions (individual flows) to be either terminated or reserved bandwidth of the inelastic e2e RSVP sessions (individual flows) is reduced.

Note that due to the above changes, the specification provided in Section 3.11 of draft-ietf-tsvwg-rsvp-pcn-01.txt regarding flow termination needs to be modified. In particular, it is needed to specify that for the situation that the Aggregator/ingress needs to terminate an amount of traffic associated tone PCN IEA, it must be able to know: (1) which RSVP generic aggregated resevation states (associated with this PCN IEA) will be selected and (2) which individual flows belonging to these selected  sates will either be terminated or their bandwidth will be reduced.

Note that 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 PCN IEA, 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
_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn