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

[Bob Briscoe <[e-mail]>]

Georgios,

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.


Bob

At 10:29 17/11/2012, [e-mail] 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,
>
>Georgios
>
>
>----------
>Van: Bob Briscoe [[e-mail]]
>Verzonden: vrijdag 16 november 2012 21:14
>To: Karagiannis, G. (EWI)
>Cc: [e-mail]; [e-mail]; [e-mail]; 
>[e-mail]; [e-mail]; [e-mail]; 
>[e-mail]; [e-mail]; [e-mail]; 
>[e-mail]
>Onderwerp: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03
>
>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>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