[rsvp-dir] Fwd: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03

[Bob Briscoe <[e-mail]>]

For the record, the posting below was blocked awaiting moderator 
approval due to too many recipients. I am re-sending just to the 
RSVP-DIR list that raised the objection.

Bob


>Date: Fri, 16 Nov 2012 20:14:33 +0000
>To: <[e-mail]>
>From: Bob Briscoe <[e-mail]>
>Subject: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03
>Cc: <[e-mail]>, <[e-mail]>, 
><[e-mail]>, <[e-mail]>, <[e-mail]>, 
><[e-mail]>, <[e-mail]>, <[e-mail]>, 
><[e-mail]>, <[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

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design