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

[Bob Briscoe <[e-mail]>]

Georgios,

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.


Bob

At 13:02 16/11/2012, [e-mail] wrote:

>Hi Bob,
>
>$B!!(B
>
>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>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
>
>$B!!(B
>
>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:
>
>$B!!(B
>
>"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)"
>
>$B!!(B
>
>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.
>
>$B!!(B
>
>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!
>
>$B!!(B
>
>So both the PCN WG and tsvwg WG agreed that this specifictaion 
>should use as basis the generic RSVP aggregation protocol!
>
>$B!!(B
>
>$B!!(B
>
>$B!!(B
>
>In a subsequent email and on a later moment I will also answer to 
>your further remarks!
>
>$B!!(B
>
>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]>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: "<mailto:[e-mail]>[e-mail] " 
>><<mailto:[e-mail]>[e-mail] >
>>Date: Saturday, November 10, 2012 8:10 AM
>>To: "<mailto:[e-mail]>[e-mail]" 
>><<mailto:[e-mail]>[e-mail]>
>>Cc: "<mailto:[e-mail]>[e-mail]" 
>><<mailto:[e-mail]>[e-mail]>, Anurag Bhargava 
>><<mailto:[e-mail]>[e-mail]>, 
>>"<mailto:[e-mail]>[e-mail]" 
>><<mailto:[e-mail]>[e-mail]>, 
>>"<mailto:[e-mail]>[e-mail] " 
>><<mailto:[e-mail]>[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 [<mailto:[e-mail]>[e-mail]]
>>Verzonden: vrijdag 9 november 2012 16:33
>>To: Karagiannis, G. (EWI)
>>Cc: <mailto:[e-mail]>[e-mail]; 
>><mailto:[e-mail]>[e-mail]; 
>><mailto:[e-mail]>[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, 
>><mailto:[e-mail]>[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, 
>><mailto:[e-mail]>[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 [<mailto:[e-mail]>[e-mail]]
>> >Verzonden: maandag 5 november 2012 13:23
>> >To: Karagiannis, G. (EWI)
>> >Cc: <mailto:[e-mail]>[e-mail]; 
>> <mailto:[e-mail]>[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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design