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

[<[e-mail]>]

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:



http://tools.ietf.org/id/draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.txt



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



http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf

　

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,

Georgios

________________________________
Van: Bob Briscoe [[e-mail]]
Verzonden: donderdag 15 november 2012 14:07
To: Karagiannis, G. (EWI); [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; PCN IETF list; [e-mail]
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}

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

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

==PATH==

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.

==RESV==

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.


Bob

At 18:23 14/11/2012, [e-mail] 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,
Georgios




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

Anurag,

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.


Bob

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.

Thx
-Anurag

From: "[e-mail]<mailto:[e-mail]> " <[e-mail]<mailto:[e-mail]> >
Date: Saturday, November 10, 2012 8:10 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Anurag Bhargava <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]> " <[e-mail]<mailto:[e-mail]> >
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,

Georgios


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

Georgios,

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, [e-mail]<mailto:[e-mail]> 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.


Bob



At 12:28 05/11/2012, [e-mail]<mailto:[e-mail]> wrote:
>Hi Ken,
>
>Thank you very much!
>We will try to catch Francois and discuss the last (in line) issue with him!
>
>Best regards,
>Georgios
>
>________________________________________
>Van: ken carlberg [[e-mail]<mailto:[e-mail]>]
>Verzonden: maandag 5 november 2012 13:23
>To: Karagiannis, G. (EWI)
>Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
>Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03
>
>Georgios,
>
> > 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.
>
>cheers,
>
>-ken

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design