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

[<[e-mail]>]

Hi  Bob,

Thanks for your comments!

Before answering to your comments I would like to emphasize that I strongly agree with the analysis done by Francois in the following email (with an additional email sent by me) on the two options of accomplishing RSVP over PCN signaling support:

http://www.ietf.org/mail-archive/web/tsvwg/current/msg11601.html
http://www.ietf.org/mail-archive/web/tsvwg/current/msg11602.html

In addition to that, we agree with the proposal of Francois of choosing option (A)  since the 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,…).

Therefore, we have used the argumentation provided by Francois in Section 1.2 of (new draft version) draft-ietf-tsvwg-rsvp-pcn-04 to justify why RFC4860 should be used to accomplish the RSVP over PCN signaling support.

After mentioning the above I will try to answer your comments below, in line!



> From: Bob Briscoe [mailto:[e-mail]]
>  Sent: donderdag 15 november 2012 14:08
> To: Karagiannis, G. (EWI); [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail];
> PCN IETF list; [e-mail]
> Subject: 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.

Georgios: This is an additional functionality that needs to be supported by the PCN-ingress-nodes and PCN-egress-nodes. This is already provided by RFC 4860. Please see the argumentation given above of why we should choose RFC 4860 instead of defining a new solution.

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

Georgios: New aggregation related features are required. These aggregation related features are provided by RFC 4860.  Please see the argumentation given above why we should choose RFC 4860 instead of defining a new solution.


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

Georgios: This is only one of the goals of using RFC3175, RFC4860, the other one is to aggregate and provide all the required protocol operations to achieve the aggregation of e2e RSVP flows/states into RSVP aggregated flows/states.  The latter needs to also be accomplished within the PCN context, where the states associated to the e2e flows need to be matched to the Ingress-Egress-Aggregate state. Therefore in the PCN context it is needed to add the required protocol operation at PCN edge nodes to achieve this. These additional aggregation based protocol operations are already provided by RFC 4860.  Please see the argumentation given above of why we should choose RFC 4860 instead of defining a new solution for this purpose.


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

Georgios: Agree with the above. This can be accomplished, see (new draft version) draft-ietf-tsvwg-rsvp-pcn-04, by configuring the PCN-interior-nodes to distinguish neither RSVP generic aggregated sessions and their associated messages [RFC4860], nor e2e RSVP sessions and their associated messages [RFC2205].


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

Georgios: The load and processing of the Aggregated PATH and Aggregated RESV messages compared to the processing of the total load and processing of e2e RSVP messages is to be neglected.

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

Georgios: I agree with Francois, when saying that the drawbacks pointed out by Bob are probably not as serious as Bob suggested, given that the Aggregated RSVP signaling would be ignored by interior nodes. In particular, we 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.


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

Georgios: This is only required for the first reservation that sets up an aggregate, which will not occur often. This means that this extra latency is to be neglected.


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

Georgios: But also in the PCN context it is needed to maintain information about which e2e flows are associated with a Ingress-Egress-Aggregate, such that when a severe congestion occurs the ingress could release the accurate number of the selected e2e flows that are associated with the same Ingress-Egress-Aggregate.
So an additional protocol operation has to be specified and implemented in the PCN edge nodes to maintain this association between e2e flows and the Ingress-Egress-Aggregate states. These additional aggregation based protocol operations are already provided by RFC 4860.  Please see the argumentation given above of why we should choose RFC 4860 instead of defining a new solution for this purpose.



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

Georgios: The answer given above related to the Aggregated PATH message holds also for the Aggregated RESV message.

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

Georgios: I do not agree, using e2e RESV to carry the PCN object has severe drawbacks.
In particular, what happens in the situation where there is a change of route for a given e2e RSVP reservation/session (i.e. changing its PCN-ingress-node and/or PCN-egress-node)  right when the PCN-egress-node decides to use a e2e RSVP signalling message (associated with this e2e RSVP session) to notify the aggregate PCN information (PCN admission control and/or flow termination information) to the PCN-ingress-node?
In this situation it is possible that the aggregated PCN information (the PCN object) will not be received by the right PCN-ingress-node, having as implication that the congestion in the PCN domain will not be solved accurately and in time!
This problem cannot occur when an Aggregated RESV message is used to carry the PCN object.



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

Georgios: As I already mentioned above, we agree with the proposal of Francois of choosing option (A)  since the 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,…).

Therefore, we have used the argumentation provided by Francois in Section 1.2 of (new draft version) draft-ietf-tsvwg-rsvp-pcn-04 to justify why RFC4860 should be used to accomplish the RSVP over PCN signaling support.

Best regards,
Georgios