Re: [PCN] [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03

"Francois Le Faucheur (flefauch)" <> Thu, 22 November 2012 13:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 710E521F842A; Thu, 22 Nov 2012 05:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.066
X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p7ndR2oUGAmy; Thu, 22 Nov 2012 05:45:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A964C21F8947; Thu, 22 Nov 2012 05:40:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=61019; q=dns/txt; s=iport; t=1353591930; x=1354801530; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Bq+U7mxA3VtJw6XwKpFA8GGdR3XmWrrKijozJzW1o4U=; b=g0/dmcAjLHzX4EXmZCREvo/AR4V1HlwYDDYmH/EXoEAi5mdInrCu+QCP MSoZQa7q6sqqs2INVHVdWgoRPRgZ8KPUOG+Ajd8Eo9kaAnlKWmb0Qo0G5 UJ03UiIBGdWT/kfX88tb65JCKtuEwGxydOEJZPyAAc+OQU4GnPITD4zZu w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=McAfee;i="5400,1158,6903"; a="145259423"
Received: from ([]) by with ESMTP; 22 Nov 2012 13:40:14 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qAMDeEcl012749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Nov 2012 13:40:14 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Thu, 22 Nov 2012 07:40:14 -0600
From: "Francois Le Faucheur (flefauch)" <>
To: Bob Briscoe <>
Thread-Topic: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03
Thread-Index: AQHNx2Ysq6goFkOn1k+WwIO3Y651p5f2Q5KA
Date: Thu, 22 Nov 2012 13:40:13 +0000
Message-ID: <>
References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <> <> <> <> <38323AE1-362C-4DBF-87A0-2D468586CC53@mimectl> <> <1E38B46D-C270-4D6E-B97A-619C00259FEC@mimectl> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D258244xmbrcdx10ciscocom_"
MIME-Version: 1.0
Cc: "<>" <>, "<>" <>, "Anurag Bhargava \(anuragb\)" <>, "<>" <>, "<>" <>
Subject: Re: [PCN] [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCN WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Nov 2012 13:45:59 -0000

Hello Bob, Georgios,

>From a scan of the thread and an off-line discussion with Georgios, my perception of the situation is:

* PCN edges need to maintain logical aggregate constructs (i.e. ingress-egrees PCN state) and map e2e reservations to these aggregate constructs
* we need to convey aggregate PCN info from edge to edge
* no actual reservation state is needed inside the PCN Core

This could be achieved by:

* adapting RFC 4860 aggregation procedures to fit PCN with as little change as possible over RFC4860
* hence performing aggregate RSVP signaling (even if it is to be ignored by PCN interior nodes)
* using this aggregate RSVP signaling to convey PCN info edge to edge


* adapting RFC 4860 aggregation procedures to fit PCN with more significant changes over RFC4860 (i.e. you keep the aspect of the procedures that have to do with maintaining aggregate states and to do with mapping e2e to aggregates, but you drop procedures that have too do with aggregate RSVP signaling and aggregate reservation establishment/maintenance)
* hence not performing aggregate RSVP signaling
* piggy-backing PCN info inside e2e RSVP signaling.

I think both approaches are probably viable. I tend to think the difference between the two is actually not that big at the end of the day because the key of the logic is how you maintain aggregate states at the edge and how you map 2e2 RSVP to these aggregates (i.e. the concept of aggregation within RFC4860 - independently of the notion of aggregate RSVP signaling) and I don't think the ingress-egress signaling channel (i.e. aggregate RSVP or e2e RSVP) is so significant given the PCN specifics.
I think the drawbacks you pointed out, Bob, in your initial message are probably not as serious as you suggested, given aggregate RSVP signaling would be ignored by interior nodes (for example, I don't see why aggregate RSVP signaling would impact rerouting inside the PCN core since packets from individual sessions would be routed independently of the reservation. As another example you mentioned that it might double the signaling processing load on edges while i suspect it would only increase by some fraction given the level of aggregate signaling should be much lower than collective e2e signaling). Nevertheless, If an approach along the lines of (B) removes the drawbacks completely while behaving as well, then that may be a better approach.

An attractive properly of (A) is that RFC4860 operations has been thought through and there has been some implementation of RSVP Aggregation, so we have some confidence that the solution can deal with the more challenging situations (rerouting in core, failure of an ingress edge, failure of an egress edge, rerouting towards a different edge,…).
My suggestion would be to try identify if a (B)-type approach can be devised with comparable properties in dealing with basic as well as more challenging situations, or conversely if the (A)-type approach really has some superior behavior afforded by the extra ingress-egress dedicated signaling channel. That should be a key deciding factor.
Perhaps Georgios could look into this direction?

I hope that helps


Caveat: I am operating based on slowly-but-surely fainting intimacy with PCN and RSVP aggregation technologies

On 20 Nov 2012, at 22:29, Bob Briscoe wrote:


See other email. Pls focus on the specifics (you will need to go back to my original email in the thread, because the specifics were immediately cut from the thread when Tom understood them).

The IETF can choose to continue along a path that it originally agreed, whether right or wrong, but it is important to discuss whether it is right or wrong first.


At 10:29 17/11/2012,<> wrote:

Hi Bob,

So, what you actually proposing is to discard a specification that has been accepted by both PCN and tsvwg WGs to be considered as a WG specification and to use a specification that you are proposing and that is conceptually and architecturally wrong.

The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), is in my opinion architecturally and conceptually wrong!

The reason is the following!

In PCN we need a signaling protocol that is able to: (1) to carry information from PCN-egress-edge to PCN-ingress-edge and (2) the carried information needs to be related to an aggregated state, i.e., the ingress-egress-aggregate state.

The e2e RSVP (RFC2205) can only support requirement (1), but is not able to support (2), since the e2e RSVP carries information that is associated with a per flow state maintained at the edges.

Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can support both requirements, since one of the features that are supported by both is to carry objects that are associated to an aggregated state maintained at the edges. In the context of PCN, the aggregated state is the ingress egress aggregate state.

Best regards,


Van: Bob Briscoe [<>]
Verzonden: vrijdag 16 november 2012 21:14
To: Karagiannis, G. (EWI)
Onderwerp: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03


Yes, I apologise for not reviewing earlier. I appreciate you followed the procedure.

My problem was that a quick read of tsvwg-rsvp-pcn wasn't enough to understand it. So I stayed quiet even though I wasn't so happy about the direction, because I didn't have enough understanding to feel I could argue.

Only in the last week or so, I collected together all the references and re-read them and their references, and made a concerted effort to understand what your draft was proposing. I have to say, it was quite a struggle (over a few days and the write-up took 2 days).

However, I admit that it would have been preferable for everyone if I had made this effort earlier.


At 13:02 16/11/2012,<> wrote:

Hi Bob,


Thanks for your comments!

Regarding your statement: What I meant in my previous email is that our individual draft that was used as a working basis for this WG draft  was already using the generic aggregation RSVP (RFC 4860) as the existing signaling protocol, see:

Moreover, during IETF 81, this individual draft has been presneted, where also the rationale of using (RFC 4860) was also the following slides see presentation slides (slide 5):


In particular in slide 4 mentions:

"All PCN charter items are fulfilled, except:

Submit Encoding and Transport of PCN from Domain Egress to Ingress to the IESG for consideration as a Proposed Standard RFC

Pairs of PCN edge nodes use ingress-egress-aggregates (IEA):

Need a signaling protocol to transport PCN information from PCN-egress-node to PCN-ingress-node and to maintain ingress-egress-aggregate between each pair of PCN edge nodes"

Furthermore Slide 5 mentions:


"IETF QoS signaling protocols to solve problem:

Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 5979)

Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175)

Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC4860)

All can be used, but for time being selected RFC 4860 due:

possible deployment interest

supports RFC 3175 and additional features such as:

support of multiple IEAs from same pair of PCN edge nodes

support of bandwidth reduction for individual flows (RFC 4495)"


Before IETF 81 and during IETF 81 this point has been discussed.

The outcome of these discussions is that short after IETF 81, the individual draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01)

become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which also was using RFC 4860 as the base signaling protocol.


It will be very helpful if the PCN WG chairs (Scott and/or Steve) and the tsvwg WG chairs (Gorry and/or James) could confirm the above statement!


So both the PCN WG and tsvwg WG agreed that this specifictaion should use as basis the generic RSVP aggregation protocol!




In a subsequent email and on a later moment I will also answer to your further remarks!


Best regards,

Van: Bob Briscoe [<>]
Verzonden: donderdag 15 november 2012 14:07
To: Karagiannis, G. (EWI);<>
Cc:<>;<>;<>;<>; PCN IETF list;<>
Onderwerp: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03

Georgios, Anurag,

Below is the main point of my review, arguing that aggregate reservations are redundant. I'm reviewing as:
- a member of the RSVP directorate
- one of the early PCN design team
- a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based.

I would have missed any decision to use aggregate reservations. Pls point me to the relevant discussion (e.g. Subject line / date).

I admit I tuned out of much of the later PCN signalling discussion. I found the whole exercise of abstracting PCN away from specific signalling protocols highly tedious; it meant we couldn't sensibly address important issues like message reliability, timeliness etc.

Nonetheless, here's why I believe RSVP aggregation is redundant:

PCN edge-nodes support the concept of an ingress-egress aggregate in their own internal tables, but they don't need to refer to an aggregate on the wire{Note 1}. PCN-ingress and PCN-egress nodes intrinscially know which e2e reservations belong to which aggregate by grouping together those e2e reservations with the same next hop or previous hop respectively.

{Note 1: except in one case described later - but it doesn't require all the other baggage of aggregate reservations}

Aggregate reservations [RFC3175, RFC4860] are designed to reduce the state required on interior nodes. Interior nodes still require state per aggregate reservation, but only reservation state, not classification and scheduling state [RFC3175, Section 1.4.1 last para].

In contrast, as you correctly point out (in Section 2.1.7), PCN requires absolutely no reservation-related state on interior nodes.

Requiring PCN to use aggregate reservations has the following three disadvantages and no advantages:

1) Redundant Processing
The PATH message between aggregator and deaggregator in rsvp-pcn-03 (triggered by an E2E PathErr message from deaggregator to aggregator) is redundant, and just doubles the processing required at the PCN-edge-nodes (if this isn't obvious, I spell it out separately for PATH & RESV messages below).

2) Reduced Resilience
Not only is an aggregate PATH redundant, it actually reduces resilience. Because an aggregate PATH is pinned to interior routers. Therefore, when routing changes, it is more complex and slower to move to the new route. By not pinning to interior routers, PCN was designed to 'just work' over interior routing changes - with no need for any changes to the RSVP PATHs. (But it would still detect overload after a re-route and terminate or rate-reduce flows if necessary.)

3) Extra Latency
A further disadvantage is the extra latency required for the first reservation that sets up an aggregate. This is two ingress-egress round trips minus the round trip time from egress to destination (or one ingress-egress round trip if it is greater). This will rarely add to latency on heavily used ingress-egress aggregates, but it will occur frequently on all the 'long-tail' (lightly used) ingress-egress aggregates.


With RFC 3175 or 4860 aggregate paths, the aggregator forwards the e2e PATH messages with IP protocol number RSVP-E2E-IGNORE and the deaggregator changes them back to RSVP before forwarding onward. Also the aggregator sends an aggregate PATH message, which is processed by each interior node and by the deaggregator.

On a path across a PCN region, given interior nodes ignore aggregate PATH messages as well, the only PCN nodes that handle aggregate messages are the aggregator and the deaggregator. The aggregator and deaggregator process all the e2e PATH messages anyway, so if we require the aggregator to add up all the e2e PATH messages and form them into an aggregate PATH message, this is just extra redundant work for both PCN-edge-nodes.


The deaggregator unicasts e2e RESV messages to the previous RSVP hop, which is the aggregator. Therefore, if we require the deaggregator to add up all the RESV messages and form them into an aggregate RESV message, this is just redundant work for both PCN-edge-nodes, because they both already process all the e2e RESV messages anyway, and no other node uses the aggregate RESV messages.

==PCN object==

This raises the question of how the PCN-egress communicates the various marking rates (the PCN object) to the PCN-ingress. There are two possibilities:
i) the PCN-egress includes a current PCN object in each e2e RESV that it returns to the PCN-ingress. The PCN-ingress strips the PCN object out before forwarding the RESV back to the previous RSVP hop.
ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in pcn-rsvp-03.

Either are possible, because a PCN object carries information about marking probabilities, and PCN works on the assumption that the marking probability of an ingress-egress aggregate is the same as the marking probability of the flows within the aggregate. A PCN object can be contained either in an e2e RESV or an aggregate RESV as long as the PCN-ingress can associate an e2e RESV with the correct aggregate (which it can, because it maintains an internal table of mappings between e2e reservations and their aggregates).

Which of the two is best is a question of message timing...

* For e2e admission decisions, the PCN object is only needed at the time each e2e RESV is sent, so option i) makes sense.

* For flow rate reduction or flow termination decisions, the deaggregator needs to regularly send PCN objects to the ingress.

The PCN-egress is sending regular e2e RESV refresh messages to the PCN-ingress, so a PCN object can be included in each of these. To ensure that PCN objects are sent often enough, I suggest the PCN-egress also maintains a timer per ingress-egress aggregate which it resets every time it sends a PCN object for that IEA. If the timer expires, the PCN-egress sends a PCN object to the PCN-egress even thought it was not triggered by an e2e RESV refresh. We could require the SESSION object in this message to refer to either of:
a) any one of the e2e SESSIONs in the aggregate,
b) the aggregate.

In case (a), the message would need to somehow tell the ingress not to forward this RESV refresh to the RSVP previous hop.

In case (b) in the PCN-ingress table of mappings between e2e SESSIONs and aggregate SESSIONs, it would include an entry for the aggregate that maps to itself. If the result of the look-up is the same as the input, it knows not to forward the RESV refresh further.

The wire protocol doesn't need to identify whether the SESSION is an aggregate or not. This is the one case I mentioned at the start {Note 1} where an aggregate is referred to on the wire.

In summary, PCN already reduces reservation state and processing to nothing on interior nodes. Adding aggregate reservations to PCN requires more processing and state, it unnecessarily pins routes to interior nodes and adds unnecessary latency.


At 18:23 14/11/2012,<> wrote:
Hi Bob,

Regarding the generic aggregated RSVP selection, actually the PCN WG agreed with this selection!
This was actually the first step that was needed for this work, and the PCN WG had no main objections on this selection!

So I do not understand your remark that your comment will have major implications!

Please note that the generic aggregated RSVP is selected since the PCN IEA are associated with flows that are aggregated at the edges. So a signalling protocol that supports aggregation of flows at the edges is very suitable for this purpose! The generic aggregated RSVP is such a signalling protocol!

Best regards,

From: Bob Briscoe []
Sent: woensdag 14 november 2012 12:57
To: Anurag Bhargava (anuragb)
Cc: Karagiannis, G. (EWI)
Subject: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03


I have my comments half-written up. I will try to finish them by the end of today.

They should be orthogonal to the PBAC comment below, so if you wanted to start altering that area, I don't think it would waste too much time.

However, my main comments will concern the use of aggregated reservations (as I said at the mic), so that could have major implications.


At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote:

Hi Bob,
 Thanks for the comments. If U have some text that will be great els I have also started putting some text on the topic U brought up.
 May be we can conference after US thanksgiving week and collaborate the text and try to move forward.

 Please let us know what might be a good time and I can schedule a Webex conf.


From: "<> " <<> >
Date: Saturday, November 10, 2012 8:10 AM
To: "<>" <<>>
Cc: "<>" <<>>, Anurag Bhargava <<>>, "<>" <<>>, "<> " <<> >
Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

Hi Bob,

Thanks very much for the comments! I think that they are very useful!

It will be very beneficiary for the fast progress of this draft if you would like to contribute as a co-author to this draft and write this additional section that describes "that the PCN-ingress can refer flow admission and
termination decisions to a central decision point (using e.g. COPS), which will respond to the PCN-ingress as per RFC2753. (Alternatively the PCN-ingress could itself be the policy decision point.)"

Best regards,


Van: Bob Briscoe [<>]
Verzonden: vrijdag 9 november 2012 16:33
To: Karagiannis, G. (EWI)
Cc:<>;<>;<>; EARDLEY, Phil
Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03


I shall post my full review of this draft in the next few days (needs
typing up - currently scribbled on a paper copy). This email is
solely in response to your answer about on-path vs off-path policy.

At 18:55 04/11/2012,<> wrote:
>So in this case an additional signaling protocol will be
>needed to be specified that covers the signaling between the
>PCN-egress-node and the centralized node
>and between PCN-ingress-node and the centralized node.
>In PCN we decdided to only focus on the specification of the
>signaling protocol that completes the
>feedback loop from PCN-egress-node to PCN-ingress-node and to focus
>on the signaling protocol
>used between the edge nodes and the centralized node.

When I/we originally designed CL-PCN over RSVP (2005), the idea was
that it would fit with the policy-based admission control (PBAC)
architecture of RFC2753. In this architecture, an Intserv node at the
ingress to a domain is the policy enforcement point (PEP), and it
refers to a logically centralised 'policy decision point' (PDP) for
decisions on which flows to block/terminate, typically using COPS.

To make this doc fit the PBAC framework, all we have to do is:
* Describe the PCN-ingress only as the PCN-ingress and not as the
decision point (find 'decision' throughout doc and fix).
* Add a section saying the PCN-ingress can refer flow admission and
termination decisions to a central decision point (using e.g. COPS),
which will respond to the PCN-ingress as per RFC2753. (Alternatively
the PCN-ingress could itself be the policy decision point.)
* Refer to this new PBAC section from Section 3.11 giving the
admission decision procedure.

* Some people might think this means COPS will need new protocol
elements to carry PCN marking rates to the policy decision point. But
PCN marking rates are irrelevant to the policy decision: the
PCN-ingress just uses PCN to determine whether it needs to block or
terminate, and it refers to the policy decision point for which flows
to block/terminate.

* Unfortunately, neither of the two PCN system descriptions [RFC6661,
RFC6662] describe a PBAC-based case. The architecture [RFC5559]
refers to the PBAC framework [RFC2753] but unfortunately doesn't
spell out how it fits. Originally, I referenced PBAC from RFC5559,
but just as the PCN w-g was closing I realised that (some?) others in
the PCN w-g were working under the assumption that the only way to
talk to a centralised policy node was from the egress, possibly
without being aware of the contents of RFC2753.

I think it's OK to introduce a new architectural arrangement in this
RSVP doc, given RFC2753 is specific to the way RSVP works.


At 12:28 05/11/2012,<> wrote:
>Hi Ken,
>Thank you very much!
>We will try to catch Francois and discuss the last (in line) issue with him!
>Best regards,
>Van: ken carlberg [<>]
>Verzonden: maandag 5 november 2012 13:23
>To: Karagiannis, G. (EWI)
>Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03
> > Georgios: We will try to explain the rationale of why we consider
> that RSVP can only be used for the situation that the
> > decision point is collocated with the PCN-ingress-node. The main
> reason of this is that in the case that the
> > decision point is collocated with the PCN-ingress-node,the
> required signaling protocol used to complete a
> > feedback loop from egress to ingress can be an entirely on-path
> protocol, like what RSVP is.
> > In the situation that the the decision point is a centralized
> node, then the required signaling protocol
> > can be a combination of an on-path and off-path protocol. This is
> because the
> > decision point might not be located on the data path! So in this
> case an additional signaling protocol will be
> > needed to be specified that covers the signaling between the
> PCN-egress-node and the centralized node
> > and between PCN-ingress-node and the centralized node.
> > In PCN we decdided to only focus on the specification of the
> signaling protocol that completes the
> > feedback loop from PCN-egress-node to PCN-ingress-node and to
> focus on the signaling protocol
> > used between the edge nodes and the centralized node.
> > This is also the reason of why PCN WG decided to only focus on
> the situation that the decision point is
> > collocated with the PCN-ingress-node.
>Great, this is helpful, and this is the information that needs to be
>in the draft.
> >> 6) This comment is just for you to contemplate -- I'm not
> expecting any changes.
> >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs.
> >> And it seems a lot of this is a carry over from rfc-4860, so in
> a sense you are inheriting an approach that
> >> was agreed to from an earlier effort.  But I wonder in the back
> of my mind, what impact occurs if
> >> an implementor doesn't follow the SHOULD?  Does the design break
> in supporting PCN?
> >> Again, I want to stress that this isnt a show stopper, but I
> would appreciate it if you gave it some thought.
> >
> > Georgios: Yes, in several cases the design might break in supporting PCN.
> > This is also the reason of using SHOULD instead of MAY. Do you
> want us to explain this in more detail in the draft?
>well, actually, I was more curious as to why a number of these cases
>are SHOULD instead of MUST.  Again, the SHOULD's in your document
>seem to be a carry-over from rfc-4860 (which set the precedent), so
>its a bit unfair for you to explain what was done in an earlier
>effort.  I just wanted to make sure you gave some thought to the
>subject.  And if things will break if SHOULD is not followed by an
>implementer/configuration, then maybe you should be more stringent
>and change things to MUST.  Perhaps a brief private conversation
>with Francois Le Faucheur will be helpful.

Bob Briscoe,                                BT Innovate & Design

Bob Briscoe,                                BT Innovate & Design

Bob Briscoe,                                BT Innovate & Design

Bob Briscoe,                                BT Innovate & Design

Bob Briscoe,                                BT Innovate & Design