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

[<[e-mail]>]

Hi Phil,

Section 2 of RFC 4495 explains that during the re-reservation request period of time no packets will traverse the "affected"" aggregate  (which contains the individual flows whose bandwidth needs to be reduced), until it is reestablished. So during that time no packets (belonging to the individual flows whose bandwidth needs to be reduced) will traverse the PCN domain until it is reestablished. See the text copied from Section2 of RFC 4495.


--// --
   This specification makes it possible for the ResvErr message to
   indicate that 20 units are still available for a reservation to
   remain up (the interface's 100 units maximum minus Flow 2's 80
   units).  The reservation initiating node (router or end-system) for
   Flow 1 has the opportunity to renegotiate (via call signaling) for
   acceptable parameters within the existing and available bandwidth for
   the flow (for example, it may decide to change to using a codec such
   as G.729)
--//--

During the re-reservation request period of time no packets will
   traverse the aggregate until it is reestablished.
      - reduces the chances that the reestablishment of the aggregate
        will reserve an inefficient amount of bandwidth, causing the
        likely preemption of more individual flows at the aggregator
        than would be necessary had the aggregator had more information
        (that RSVP does not provide at this time)
-//==

Best regards,
Georgios
________________________________________
Van: [e-mail] [[e-mail]]
Verzonden: dinsdag 27 maart 2012 9:36
Aan: [e-mail]
CC: Karagiannis, G. (EWI); [e-mail]
Onderwerp: RE: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed)

Georgios

on your assumption 2 about slowing a flow rather than terminating it.

you said that the necessary functionality is already in rfc4495
its abstract says:

In such cases,
   when the entire bandwidth allocated to a reservation is not required,
   the reservation need not be torn down.  The solution described in
   this document allows endpoints to negotiate a new (lower) bandwidth
   that falls at or below the specified new bandwidth maximum allocated
   by the network.

this is not the same function. this is about negotiating a new lower bandwidth. the functionality you need is for the PCN decision point to understand in advance that there is a lower rate(s) to which the flow could be reduced if necessary (and both rates are inelastic)

phil

________________________________________
From: T. Moncaster [[e-mail]] On Behalf Of Toby Moncaster [[e-mail]]
Sent: 26 March 2012 15:26
To: Eardley,PL,Philip,DUB8 R
Cc: [e-mail]; [e-mail]
Subject: Re: [PCN] dropping assumption 1 for draft-ietf-tsvwg-rsvp-pcn-01.txt (assumption 2 needed)

I think the two most important points to remember are:

1) The IESG wants to close the PCN working group (and I for one think that seems sensible)

2) This signalling document is meant to be one of the core building blocks that can be bolted together to create a PCN-based admission system. As such it should be written with as few assumptions as possible, and certainly should not be adding new concepts that were never in the original PCN charter.

more inline

On 26 Mar 2012, at 15:13, <[e-mail]> wrote:

> 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)
>
> 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.

And all the documents have made that clear throughout (see the default abstract/intro text that is in nearly all the other documents now).

>
> 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.

+1

> (You could actually say the same thing about assumption 1)
>
> 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.

If you DO feel there is a need for more cases then that should go in as a (very short) appendix.

And remember, so long as this document is crafted correctly (using 2119 language carefully) it can include your assumptions without ever needing to state them. Then if you are keen to have some future extension that looks at flow-slowing you could put that in as an individual draft to TSWWG once PCN is closed.

Toby

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