From bob.briscoe@bt.com Thu Nov 15 05:07:45 2012 Return-Path: X-Original-To: rsvp-dir@ietfa.amsl.com Delivered-To: rsvp-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34321F88FF for ; Thu, 15 Nov 2012 05:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04EtqKTIDizA for ; Thu, 15 Nov 2012 05:07:45 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 1D06B21F878C for ; Thu, 15 Nov 2012 05:07:41 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 13:07:40 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 13:07:39 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Thu, 15 Nov 2012 13:07:34 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1352984850566; Thu, 15 Nov 2012 13:07:30 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.9.241]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAFD7RA0009392; Thu, 15 Nov 2012 13:07:27 GMT Message-ID: <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Nov 2012 13:07:31 +0000 To: , From: Bob Briscoe In-Reply-To: References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_662145354==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: tsvwg@ietf.org, philip.eardley@bt.com, anuragb@cisco.com, carlberg@g11.org.uk, rsvp-dir@ietfa.amsl.com, PCN IETF list Subject: [rsvp-dir] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: rsvp-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RSVP directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:07:45 -0000 --=====================_662145354==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 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, karagian@cs.utwente.nl 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:bob.briscoe@bt.com] >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: "karagian@cs.utwente.nl " ><karagian@cs.utwente.nl > >Date: Saturday, November 10, 2012 8:10 AM >To: "bob.briscoe@bt.com" ><bob.briscoe@bt.com> >Cc: "carlberg@g11.org.uk" ><carlberg@g11.org.uk>, Anurag Bhargava ><anuragb@cisco.com>, >"tsvwg@ietf.org" ><tsvwg@ietf.org>, >"philip.eardley@bt.com " ><philip.eardley@bt.com > >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 [bob.briscoe@bt.com] >Verzonden: vrijdag 9 november 2012 16:33 >To: Karagiannis, G. (EWI) >Cc: carlberg@g11.org.uk; >anuragb@cisco.com; >tsvwg@ietf.org; 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, >karagian@cs.utwente.nl 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, >karagian@cs.utwente.nl 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 [carlberg@g11.org.uk] > >Verzonden: maandag 5 november 2012 13:23 > >To: Karagiannis, G. (EWI) > >Cc: tsvwg@ietf.org; > anuragb@cisco.com > >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 --=====================_662145354==.ALT Content-Type: text/html; charset="us-ascii" 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, karagian@cs.utwente.nl 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:bob.briscoe@bt.com]
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: "karagian@cs.utwente.nl " <karagian@cs.utwente.nl >
Date: Saturday, November 10, 2012 8:10 AM
To: "bob.briscoe@bt.com" <bob.briscoe@bt.com>
Cc: "carlberg@g11.org.uk" <carlberg@g11.org.uk>, Anurag Bhargava <anuragb@cisco.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "philip.eardley@bt.com " <philip.eardley@bt.com >
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 [bob.briscoe@bt.com]
Verzonden: vrijdag 9 november 2012 16:33
To: Karagiannis, G. (EWI)
Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; 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, karagian@cs.utwente.nl 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, karagian@cs.utwente.nl 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 [carlberg@g11.org.uk]
>Verzonden: maandag 5 november 2012 13:23
>To: Karagiannis, G. (EWI)
>Cc: tsvwg@ietf.org; anuragb@cisco.com
>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 --=====================_662145354==.ALT-- From bob.briscoe@bt.com Thu Nov 15 13:02:23 2012 Return-Path: X-Original-To: rsvp-dir@ietfa.amsl.com Delivered-To: rsvp-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C852F21F8A0B for ; Thu, 15 Nov 2012 13:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.357 X-Spam-Level: X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hlJ7zqQJAVb for ; Thu, 15 Nov 2012 13:02:19 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 8669B21F869B for ; Thu, 15 Nov 2012 13:02:18 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 21:02:17 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 21:02:16 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Thu, 15 Nov 2012 21:02:14 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353013332993; Thu, 15 Nov 2012 21:02:12 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.9.241]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAFL2BWE010641; Thu, 15 Nov 2012 21:02:11 GMT Message-ID: <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Nov 2012 21:02:14 +0000 To: Tom Taylor From: Bob Briscoe In-Reply-To: <50A51B8C.4010806@gmail.com> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: PCN IETF list , karagian@cs.utwente.nl, anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [rsvp-dir] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: rsvp-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RSVP directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:02:23 -0000 Tom, The RSVP message I'm proposing doesn't say "Never mind the SESSION in this message, I'm related to every flow with the same first hop". It says "These are the marking probabilities for the SESSION in this message". Then the PCN-ingress (not the message) infers that all other flows that share the same aggregate will share the same marking probability, because PCN marking on interior nodes is random and unbiased. It's a subtle distinction, but it preserves the semantics of RSVP messages, without the three disadvantages of setting up an RSVP aggregate that I mentioned. You will have seen from the rest of the message that I have not rejected the concept of aggregation, I am merely saying that the PCN-ingress and PCN-egress can hold the concept internally. Bob At 16:42 15/11/2012, Tom Taylor wrote: >I'm not sure the semantics of the PCN information -- particularly as >it relates to flow termination -- are correct without some sort of >concept of aggregation. Or can you really define an RSVP object that >has semantics "Never mind the SESSION in this message, I'm related >to every flow with the same first hop"? > >On 15/11/2012 8:07 AM, Bob Briscoe wrote: >>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). >... ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Thu Nov 15 13:35:21 2012 Return-Path: X-Original-To: rsvp-dir@ietfa.amsl.com Delivered-To: rsvp-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E7021F8477 for ; Thu, 15 Nov 2012 13:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waHKvPCQDzZz for ; Thu, 15 Nov 2012 13:35:20 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 735FC21F849A for ; Thu, 15 Nov 2012 13:35:19 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR67-UKRD.bt.com (10.187.101.22) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 21:35:17 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 21:35:17 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Thu, 15 Nov 2012 21:35:13 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353015311759; Thu, 15 Nov 2012 21:35:11 +0000 Received: from MUT.jungle.bt.co.uk ([10.73.9.241]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAFLZ95f010718; Thu, 15 Nov 2012 21:35:09 GMT Message-ID: <201211152135.qAFLZ95f010718@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 15 Nov 2012 21:34:39 +0000 To: , "Anurag Bhargava (anuragb)" From: Bob Briscoe In-Reply-To: References: <20121011194603.11308.61516.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: pcn@ietf.org, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [rsvp-dir] [PCN] FW: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-03.txt X-BeenThere: rsvp-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RSVP directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:35:22 -0000 Georgios & Anurag, Thank you for this draft. Below is my review, as: - a member of the RSVP directorate - one of the PCN design team - a co-author of draft-lefaucheur-rsvp-ecn, on which this draft is based. I have already sent my main technical concerns in two separate emails, summarised below (but I suggest we use the separate threads to discuss): 1. It would be easy to allow for an off-path policy-decision point (PDP), as per RFC2753 (policy-based admission control (PBAC) framework) 2. PCN already reduces reservation state and processing to nothing on interior nodes. Adding aggregate reservations to PCN adds 3 disadvantages and no advantages: - it requires more processing and state in interior nodes and boundary-nodes - it unnecessarily pins routes to interior nodes and - it adds unnecessary latency. This email reviews comprehensibility and raises a large number of lesser technical concerns (26 to be precise), as well as editorial nits (many of which may be irrelevant if I'm right about the major technical concerns). ==General style== I didn't find the style useful at all. Sections 1, 2 & 3 defer everything meaningful into pointers to other RFCs. This makes it incomprehensible, even if you know all the references intimately. Lixia's suggestion that you refer to the specific sections of other RFCs won't be enough. An RFC should be understandable without re-reading its references (readers should have read them, but they shouldn't be expected to remember every detail). I have to say we are moving very slowly, and backwards. When Francois Le Faucheur first wrote the ancestor to this draft (7 years ago!), I could understand it immediately, and in half the pages it covered nearly everything in this draft and covered the gaps I have listed below. [In the interests of full disclosure: I became a co-author of draft-lefaucheur-tsvwg-rsvp-ecn-00, nonetheless Francois's pre-00 draft was more comprehensible and complete than this one, even before the co-authors did the first reviews.] This draft says very little itself, but ends up much longer. For example Section 3 tediously repeats content-free text like: " In this document it is considered that for <Title> the same methods can be used as the ones described in <reference>". Not only section 3; sections 1 & 2 also rely wholly on references, making them just as incomprehensible. I also agree with the other reviewers' suggestions to focus the introduction initially on what this draft adds, and move the background material after that. In summary: avoid phrases like "the same methods as" or "standard RSVP aggregation [...] procedures are used". Instead just say directly how it works. ==Normative & Technical Points== ==Gaps== * How an aggregate reservation is created vs. how one is used if it is already present * How next hop addresses are discovered (a PCN domain is only one RSVP hop unlike with RSVP aggregation, so although the process is similar, this needs to be described explicitly) * How PCN interior nodes ignore RSVP messages: - by configuration? - or by the PCN-ingress switching aggregate PATH messages to IP protocol number RSVP-E2E-IGNORE (which isn't strictly the right name but would have the right effect)? * Error conditions, for instance when messages don't contain the expected objects, e.g. [draft-lefaucheur-tsvwg-rsvp-ecn-01, page 6 bullet 1]. * How per-node state is maintained and the interaction with RSVP soft state refresh messages is not discussed. PCN-related state is unlike other RSVP state, in that it continually varies (it is controlled by a varying signal). Therefore it needs to be clear that the fields of the PCN object reflect the current value when sent, not their original value, which is what an RSVP implementer would normally expect. ==Specific sections== 1. Introduction " This document, and according to [RFC4860] MAY also be used end-to-end directly by end-systems attached to a Diffserv network. " No. See RFC5559 for PCN applicability - there is insufficient aggregation for PCN to work effectively e2e. The PCN applicability statement in RFC5559 should be stated here instead: PCN is only applicable to links with aggregation levels where the bit-rate of the largest flow is tens of times smaller than the smallest available link rate in the PCN region. OLD: In this document it is considered that the PCN-nodes MUST be able to support the functionality specified in [RFC5670], [RFC5559], [RFC6660], [RFC6661], [RFC6662]. NEW: To comply with this specification, PCN-nodes MUST be able to support the functionality specified in [RFC5670], [RFC5559] [RFC6660], and either [RFC6661] or [RFC6662]. Section 2.1 first para: " In addition, in this document it is considered that the PCN-boundary nodes are able to distinguish and process (1) RSVP SESSIONS for generic aggregated sessions and their messages according to [RFC4860], (2) e2e RSVP sessions and messages according to [RFC2205]. " Say how (by the addresses that the RSVP messages are addressed to). " Furthermore, it is considered that the PCN-interior-nodes are not able to distinguish neither RSVP generic aggregated sessions and their associated messages [RFC4860], nor e2e RSVP sessions and their associated messages [RFC2205]. " Say how (see two possibilities in 'Gaps' above). This is also not explained in Sections 2.1.7., 3.2 & 3.7, which are all meant to be about this. Section 2.1 bottom of p11: "The RSVP SESSION object for generic aggregate reservations is based on the RSVP SESSION object specified in [RFC4860] augmented with the following information: o) the IPv4 DestAddress, IPv6 DestAddress SHOULD be set to the IPv4 or IPv6 destination addresses, respectively, of the Deaggregator (PCN-egress-node) " Say how - see 'Gaps' above - the whole process of RFC4860 (e2e PATH, e2e PathErr, aggregate PATH) finds the right address, but this needs to be described because in PCN the RSVP hop is across multiple IP nodes (the whole PCN-domain), unlike with RSVP aggregation. Section 2.1.2. " The PCN-traffic (e.g., e2e microflows) belonging to an ingress- egress-aggregate can be classified only at the PCN-boundary-nodes using the combination of (1) PCN-BA (i.e., combination of the DSCP and ECN fields), (2) IP addresses of the specific pair of PCN- boundary-nodes used by a ingress-egress-aggregate. [...] Moreover, the PCN-traffic (e.g., e2e microflows) belonging to a RSVP generic aggregated reservation can be classified only at the PCN-boundary-nodes (i.e., Aggregator and Deaggregator) by using the RSVP SESSION object for RSVP generic aggregated reservations, see [RFC4860]. " Are you assuming a tunnel? You haven't said so? Otherwise the traffic doesn't contain the PCN-boundary-node addresses. Section 2.1.8. Inter-domain Routes PCN charter scope precludes inter-domain considerations. I personally would happy to have discussion of inter-domain matters in here, but it will not be complete, because we would need to discuss security & integrity of PCN objects, but the PCN charter precluded that. Section 2.1.10. Multi-level Aggregation " PCN does not consider multi-level aggregations within the PCN domain. " You have referenced generic aggregate reservations throughout [RFC4680], rather than just aggregate reservations [RFC3175]. I understand the difference is that RFC4860 supports e.g. multiple levels of precedence. So why say we don't consider multi-level aggregation? Section 3.1 " o) The e2e RSVP reservation session associated with an e2e Path message that arrives at the external interface of the PCN- ingress-node is mapped/matched onto an existing RSVP generic aggregation reservation state. " You haven't said how the existing aggregate is created in the first place (see 'Gaps' above). Section 3.1 (twice) " A new error code "PCN-domain rejects e2e reservation" MUST be augmented to the RSVP error codes to inform the sender that a PCN domains rejects the e2e reservation request. " Disagree. The regular error code "01: Admission Control failure" should be used, so that end-system implementations understand that the call has been blocked. It should also use the regular "Sub-code = 2: Requested bandwidth unavailable". If the PCN-ingress uses a different code, it will imply to other RSVP nodes including end-systems that admission control did not fail. If it uses the 01 error code but a different sub-code it will imply that AC failed, but not because of insufficient bandwidth. PCN is one (of many) mechanisms to determine whether a reservation should be blocked. For other nodes, it is not relevant to describe the mechanism (PCN) that was used to determine that there was insufficient bandwidth. Section 3.1 " o) If for the same ingress-egress-aggregated and the same RSVP generic aggregated reservation then (1) the PCN-admission- state and/or (2) the state for the RSVP generic aggregated reservation are/is "block", the flow SHOULD NOT be admitted [...] The way of how the PCN-admission-state is maintained is specified in [RFC6661] and [RFC6662]. The way of how the RSVP generic aggregated reservation state is maintained is specified in [RFC4860]. " As discussed in my email arguing against aggregate reservations, the e2e RESV message can carry an up-to-date PCN object for the PCN-ingress to decide whether to admit the flow signalled by the same message, given the PCN-ingress already handles e2e RESV messages. There is no need to rely on admission state determined earlier, given the PCN-egress already sends an e2e RESV message to the PCN-ingress at admission time. Section 3.2 and 3.7 (and 2.1.7). Neither section says how interior nodes are arranged to ignore RSVP messages (see 'Gaps' earlier which suggests two possible approaches). Section 3.8 (last sentence) " The address of the PCN-ingress- node is the one specified in the same ingress-egress-aggregate." I cannot work out how Section 3.11 Separation of the policy enforcement role of the PCN-ingress from a policy decision role (that may be off-path) will need to be added to the first bullet of this section (see other email). Section 3.11 " However, based on a local policy, the Aggregator could use other procedures of terminating microflows. " Please delete. Policy determines /which/ flows are terminated, not /how/ the termination procedure works. Section 3.12 I don't understand the purpose of this section - section 3.11 seems to have already said everything that section 3.12 says. Section 3.13 Say why an aggregate reservation would need to be removed: - no e2e reservations left in the aggregate? - such severe pre-congestion that every flow in the aggregated has to be terminated (!!!???) Section 4. Protocol Elements " The protocol elements in this document are using the protocol Elements defined in [RFC4860], augmented with the following rules: " This doc uses a number of protocol elements from the base RSVP spec, not just the extras defined in RFC4860. BTW, protocol elements are generally called classes in RSVP documents (and instances of them are called objects). Also the grammar and capitalisation in this sentence is pretty poor. Section 4. Protocol Elements The first two bullets are inappropriate here and more appropriate to section 3. Section 4.1 PCN Object I don't see why the PCN object needs to contain the IP addresses of the PCN-ingress and PCN-egress. These will be in the SESSION object earlier in the list of RSVP objects, and RFC2205 says that the SESSION object defines the session for the other objects that follow. This also means we don't need different PCN objects for IPv4 & IPv6. Section 4.1 PCN Object s/rate/fraction/ I don't think you mean rate, which implies with respect to time. I think you mean the fraction of bytes in packets with each marking relative to the total bytes in PCN marked packets. Section 4.1 PCN Object I suggest that the PCN object always reports the fractions of all three non-zero values of the PCN (aka ECN) field, even for single marking (SM) mode that doesn't use one of the codepoints. Then PCN-egress implementations and the PCN object on the wire can be the same for both SM & CL modes (I think), and only the ingress has to be different. Section 4.1 PCN Object (and IANA Considerations) IANA need to be told the high order 2 bits of the Class-Num, to exploit the Unknown Class rules of [RFC2205, section 3.10]. I suggest the Class-Num is 10bbbbbb, so that any node outside a PCN domain that receives a PCN object and doesn't understand it will strip it off and forward the remainder of the RSVP message. Ideally we would want the RSVP message (with or without the PCN object) to be forwarded and an error message raised, but that option is not available; RSVP only allows an error message to be raised when it discards a whole message. Section 4.1 PCN Object The section defines a PCN CL Flow IDs object. It's not clear whether it is meant to be a different object from the PCN object, or an extension to it. I think it would be clearer to make it a separate RSVP object, although in theory a PCN-ingress could work out that a PCN CL Flow IDs object is included, by a calculation from the object length (because the base PCN object is always a fixed length). I don't see the point of the LENGTH field (for the number of flow ID objects), given RSVP gives the length of an object in octets, from which the number of flow ID objects can be derived (divide by 16 for IPv4 or divide by 40 for IPv6). Also RSVP objects have to align on 4 octet boundaries. ==Editorial Nits== Globally: s/In this document it is considered that.../ /To comply with this specification.../ Abstract: s/specifies the extensions to/ /specifies extensions to/ 1. Intro s/collocated/ /colocated/ s/extensions to the Generic Aggregated RSVP [RFC4860] for the support of/ /extensions to Generic Aggregated RSVP [RFC4860] for support of/ OLD Furthermore, this document and according to [RFC4860], in absence of e2e RSVP flows, a variety of policies (not defined in this document) can be used at the Aggregator to set the DSCP of packets passing into the aggregation region and how they are mapped onto generic aggregate reservations. These policies are not described in this document but are a matter of local configuration. NEW In a similar way to [RFC4860], the Aggregator can detect flows based on policy (not defined in this document) rather than using e2e RSVP flow signalling. Then it can map them onto aggregate reservations and set the DSCP of the packets of these flows as they pass into the aggregation region. Section 1.1. Terminology " Ingress-egress-aggregate (IEA): [...] combination of (1) fields), (2) IP addresses of the " Some text appears to be missing here. Section 1.1. Terminology OLD: t-recvFail An ingress-egress-aggregate timer that is used at The Decision point (in this document at the PCN- ingress-node) which when expires raises an alarm to management, and activates the PCN-ingress-node to block the admission of new PCN-flows. This timer expires when it value is equal to T-fail and is reset when a report, i.e., RSVP aggregated RESV message, is received for a RSVP generic aggregated reservation (which is matched to one ingress-egress-aggregate). NEW: t-recvFail A timer per ingress-egress-aggregate that the PCN-ingress-node sets every time it receives an RSVP RESV message for that ingress-egress-aggregate. When its value reaches T-fail it is assumed that the PCN-ingress has lost contact with the PCN-egress. Therefore the PCN-ingress blocks admission of new PCN-flows into that aggregate and raises a management alarm. REASONING: The order in which the clauses were written made it hard to understand, there was nothing to say what it measured, and it wasn't clear what scope was implied by "it blocks PCN-flows". Section 1.1 Terminology Underscores (e.g t_meas) are often used in the terminology section, whereas hyphens (e.g. t-meas) are used in the body text. Section 2.1 Overview There is no Section 2.2, so all the sub-sections of 2.1.X could be promoted. Section 2.1.1 s/used, SHOULD/used SHOULD/ Section 2.1.2. OLD: The PCN-traffic is marked using PCN-marking and is classified using The PCN-BA (i.e., combination of the DSCP and ECN fields). NEW: The PCN-ingress marks a PCN-BA useing PCN-marking (i.e., combination of the DSCP and ECN fields), which interior nodes use to classify PCN-traffic. REASONING: Avoid passive verbs - ambiguous. Section 2.1.3 s/for the determination of/to determine the address of/ Section 2.1.4 " o) PCN-ingress-node MUST use one or more policies to estimate whether an e2e RSVP reservation session associated with an e2e Path message that arrives at the external interface of the PCN-ingress- node can be mapped onto an existing RSVP generic aggregation reservation state. " This is a straightforward mapping function, it shouldn't involve policy. Also mappings are deterministic - the word estimate is wrong. Section 3.1 " o) If the timer t-recvFail expires [...] o) If the timer t-recvFail does NOT expire [...] " Switch the order of these two bullets, to describe the normal (successful) behaviour first. Section 3.1 s/ingress-egress-aggregated/ /ingress-egress-aggregate/ s/then (1)/ /(1) [However, I suggest earlier that the technical sense should be substantially changed, possibly making these editorial changes irrelevant.] Section 3.8. OLD: The PCN object is specified in this document and is used for the report of the data measured by the PCN-egress-node, for a particular ingress-egress-aggregate, see [RFC6661], and [RFC6662]. NEW: The PCN-egress-node reports the marking probabilities it measures for a particular ingress-egress-aggregate in a PCN object, as specified in Section 4 (see also [RFC6661], and [RFC6662]). REASONING: Poor sentence order. Section 3.11. s/associated to one ingress-egress-aggregate/ /associated with one ingress-egress-aggregate/ Section 3.15 Repeats Section 2.1.9. Unnecessary. Section 4. s/by an PCN-egress node/ /by a PCN-egress node/ Regards Bob At 19:55 11/10/2012, karagian@cs.utwente.nl wrote: >Hi all, > >Please note that draft-ietf-tsvwg-rsvp-pcn-03.txt has just been submitted! >All comments received during the tsvwg meeting in Vancouver and >during the tsvwg and pcn mailing lists have been worked out! > >If you have any other comments please send them to the tsvwg mailing list! > >Best regards, >Georgios > > >________________________________________ >Van: internet-drafts@ietf.org [internet-drafts@ietf.org] >Verzonden: donderdag 11 oktober 2012 21:46 >Aan: tsvwg-chairs@tools.ietf.org; >draft-ietf-tsvwg-rsvp-pcn@tools.ietf.org; martin.stiemerling@neclab.eu >Onderwerp: New Version Notification - draft-ietf-tsvwg-rsvp-pcn-03.txt > >A new version (-03) has been submitted for draft-ietf-tsvwg-rsvp-pcn: >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-pcn-03.txt > > >The IETF datatracker page for this Internet-Draft is: >https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn/ > >Diff from previous version: >http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rsvp-pcn-03 > >IETF Secretariat. >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Fri Nov 16 12:03:22 2012 Return-Path: <bob.briscoe@bt.com> X-Original-To: rsvp-dir@ietfa.amsl.com Delivered-To: rsvp-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F5A21F8A74 for <rsvp-dir@ietfa.amsl.com>; Fri, 16 Nov 2012 12:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt56ItBGv8Al for <rsvp-dir@ietfa.amsl.com>; Fri, 16 Nov 2012 12:03:21 -0800 (PST) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE9421F8525 for <rsvp-dir@ietfa.amsl.com>; Fri, 16 Nov 2012 12:03:21 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 16 Nov 2012 20:03:16 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Fri, 16 Nov 2012 20:03:17 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Fri, 16 Nov 2012 20:03:16 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353096194692; Fri, 16 Nov 2012 20:03:14 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAGK3C3s014269; Fri, 16 Nov 2012 20:03:12 GMT Message-ID: <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 16 Nov 2012 20:03:11 +0000 To: Tom Taylor <tom.taylor.stds@gmail.com> From: Bob Briscoe <bob.briscoe@bt.com> In-Reply-To: <50A56804.3090208@gmail.com> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> <50A56804.3090208@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: PCN IETF list <pcn@ietf.org>, karagian@cs.utwente.nl, anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [rsvp-dir] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: rsvp-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RSVP directorate <rsvp-dir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rsvp-dir> List-Post: <mailto:rsvp-dir@ietf.org> List-Help: <mailto:rsvp-dir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 16 Nov 2012 20:03:22 -0000 Tom, The edge behaviour RFCs attempted to abstract over any signalling protcol, but I think they ended up being biased towards the ITU way of doing things, rather than an abstraction that encompassed both RACF and RSVP, which was probably too ambitious. Is you piggy-backing draft effectively what I am describing - piggy-backing on e2e signalling? I don't believe we need any more abstract drafts if that's what you mean - we need to focus on RSVP specifically now. We could perhaps re-boot from Francois's original draft. Bob At 22:09 15/11/2012, Tom Taylor wrote: >OK, I guess I see your point. I was too focussed on the calculations >that are done at the Decision Point. > >It makes me wonder if I should revive that piggy-backing edge >behaviour draft I once started. > >On 15/11/2012 4:02 PM, Bob Briscoe wrote: >>Tom, >> >>The RSVP message I'm proposing doesn't say "Never mind the SESSION in >>this message, I'm related to every flow with the same first hop". It >>says "These are the marking probabilities for the SESSION in this >>message". Then the PCN-ingress (not the message) infers that all other >>flows that share the same aggregate will share the same marking >>probability, because PCN marking on interior nodes is random and unbiased. >> >>It's a subtle distinction, but it preserves the semantics of RSVP >>messages, without the three disadvantages of setting up an RSVP >>aggregate that I mentioned. >> >>You will have seen from the rest of the message that I have not rejected >>the concept of aggregation, I am merely saying that the PCN-ingress and >>PCN-egress can hold the concept internally. >> >> >>Bob >> >>At 16:42 15/11/2012, Tom Taylor wrote: >>>I'm not sure the semantics of the PCN information -- particularly as >>>it relates to flow termination -- are correct without some sort of >>>concept of aggregation. Or can you really define an RSVP object that >>>has semantics "Never mind the SESSION in this message, I'm related to >>>every flow with the same first hop"? >... ________________________________________________________________ Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Tue Nov 20 13:15:20 2012 Return-Path: <bob.briscoe@bt.com> X-Original-To: rsvp-dir@ietfa.amsl.com Delivered-To: rsvp-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789F21F8235 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.458 X-Spam-Level: X-Spam-Status: No, score=-3.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBjlSTwdcmIr for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:15:19 -0800 (PST) Received: from hubrelay-by-04.bt.com (hubrelay-by-04.bt.com [62.7.242.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2C921F8475 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:15:19 -0800 (PST) Received: from EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) by EVMHR04-UKBR.bt.com (10.216.161.36) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:15:16 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR72-UKRD.domain1.systemhost.net (10.36.3.110) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:15:17 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Tue, 20 Nov 2012 21:15:12 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353446111158; Tue, 20 Nov 2012 21:15:11 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAKLF8bf002759; Tue, 20 Nov 2012 21:15:09 GMT Message-ID: <201211202115.qAKLF8bf002759@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2012 21:15:10 +0000 To: Tom Taylor <tom.taylor.stds@gmail.com> From: Bob Briscoe <bob.briscoe@bt.com> In-Reply-To: <50A7E859.1020305@gmail.com> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> <50A56804.3090208@gmail.com> <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> <50A7E859.1020305@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: PCN IETF list <pcn@ietf.org>, karagian@cs.utwente.nl, anuragb@cisco.com, tsvwg@ietf.org, rsvp-dir@ietfa.amsl.com Subject: Re: [rsvp-dir] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: rsvp-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RSVP directorate <rsvp-dir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rsvp-dir> List-Post: <mailto:rsvp-dir@ietf.org> List-Help: <mailto:rsvp-dir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 20 Nov 2012 21:15:20 -0000 Tom, I've lost the context - I don't think I said an IEA "is composed of all flows with the same next hop" or anything like this. If it helps, I'm not changing the defintion of an IEA, I'm just saying it doesn't have to be identified in any wire-protocol; it can be known about solely internally on PCN-boundary nodes. Bob At 19:41 17/11/2012, Tom Taylor wrote: >Stepping back a bit here, I have to question your definition of an >ingress-egress aggregate. When you say it is composed of all flows >with the same next hop, what sort of topology are you assuming? The >definition makes sense only if the next hop entity is an egress node. > >If that is not the case, then I would say an ingress-egress >aggregate is defined as the set of all flows where the RESV message >comes from the same egress node. > >On 16/11/2012 3:03 PM, Bob Briscoe wrote: >>Tom, >> >>The edge behaviour RFCs attempted to abstract over any signalling >>protcol, but I think they ended up being biased towards the ITU way of >>doing things, rather than an abstraction that encompassed both RACF and >>RSVP, which was probably too ambitious. >> >>Is you piggy-backing draft effectively what I am describing - >>piggy-backing on e2e signalling? >> >>I don't believe we need any more abstract drafts if that's what you mean >>- we need to focus on RSVP specifically now. We could perhaps re-boot >>from Francois's original draft. >> >> >> >>Bob >> >>At 22:09 15/11/2012, Tom Taylor wrote: >>>OK, I guess I see your point. I was too focussed on the calculations >>>that are done at the Decision Point. >>> >>>It makes me wonder if I should revive that piggy-backing edge >>>behaviour draft I once started. >>> >>>On 15/11/2012 4:02 PM, Bob Briscoe wrote: >>>>Tom, >>>> >>>>The RSVP message I'm proposing doesn't say "Never mind the SESSION in >>>>this message, I'm related to every flow with the same first hop". It >>>>says "These are the marking probabilities for the SESSION in this >>>>message". Then the PCN-ingress (not the message) infers that all other >>>>flows that share the same aggregate will share the same marking >>>>probability, because PCN marking on interior nodes is random and >>>>unbiased. >>>> >>>>It's a subtle distinction, but it preserves the semantics of RSVP >>>>messages, without the three disadvantages of setting up an RSVP >>>>aggregate that I mentioned. >>>> >>>>You will have seen from the rest of the message that I have not rejected >>>>the concept of aggregation, I am merely saying that the PCN-ingress and >>>>PCN-egress can hold the concept internally. >>>> >>>> >>>>Bob >>>> >>>>At 16:42 15/11/2012, Tom Taylor wrote: >>>>>I'm not sure the semantics of the PCN information -- particularly as >>>>>it relates to flow termination -- are correct without some sort of >>>>>concept of aggregation. Or can you really define an RSVP object that >>>>>has semantics "Never mind the SESSION in this message, I'm related to >>>>>every flow with the same first hop"? >>>... >> >>________________________________________________________________ >>Bob Briscoe, BT Innovate & Design > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design From bob.briscoe@bt.com Tue Nov 20 13:25:47 2012 Return-Path: <bob.briscoe@bt.com> X-Original-To: rsvp-dir@ietfa.amsl.com Delivered-To: rsvp-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9AC21F8815 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW4cNCisEBJ0 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:25:46 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id BFF0F21F8787 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:25:45 -0800 (PST) Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:25:44 +0000 Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:25:43 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Tue, 20 Nov 2012 21:25:37 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353446735337; Tue, 20 Nov 2012 21:25:35 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAKLPXVQ002786; Tue, 20 Nov 2012 21:25:33 GMT Message-ID: <201211202125.qAKLPXVQ002786@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2012 21:25:33 +0000 To: <karagian@cs.utwente.nl> From: Bob Briscoe <bob.briscoe@bt.com> In-Reply-To: <3AC1435F-846D-44CB-8F60-1E43C572AA0B@mimectl> References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> <50A56804.3090208@gmail.com> <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> <3AC1435F-846D-44CB-8F60-1E43C572AA0B@mimectl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_287273207==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Cc: rsvp-dir@ietfa.amsl.com, anuragb@cisco.com, tsvwg@ietf.org, pcn@ietf.org, tom.taylor.stds@gmail.com Subject: Re: [rsvp-dir] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: rsvp-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RSVP directorate <rsvp-dir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rsvp-dir> List-Post: <mailto:rsvp-dir@ietf.org> List-Help: <mailto:rsvp-dir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 20 Nov 2012 21:25:47 -0000 --=====================_287273207==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Georgios, See the discussion with Tom - he gets what I'm saying. Also, in my mail that started this thread (15 november 2012 14:07) I explained why you can get the benefits of aggregation by solely holding the concept of IEAs on the PCN-boundary nodes, without identifying an aggregate in the signalling protocol at all. I also explained why identifying an aggregate in the signalling protocol led to three worse properties and nothing better. Please argue with that, rather than talking about aggregates only in conceptual terms - and only in terms of whole RFCs, rather than specifics - that is where the problem stemmed from, I believe. Bob At 10:26 17/11/2012, karagian@cs.utwente.nl wrote: >Hi Bob, Hi Tom, > > > >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 [bob.briscoe@bt.com] >Verzonden: vrijdag 16 november 2012 21:03 >To: Tom Taylor >Cc: Karagiannis, G. (EWI); anuragb@cisco.com; tsvwg@ietf.org; >rsvp-dir@ietfa.amsl.com; PCN IETF list >Onderwerp: Re: [PCN] Redundant aggregate reservations: >draft-ietf-tsvwg-rsvp-pcn-03 > >Tom, > >The edge behaviour RFCs attempted to abstract over any signalling >protcol, but I think they ended up being biased towards the ITU way >of doing things, rather than an abstraction that encompassed both >RACF and RSVP, which was probably too ambitious. > >Is you piggy-backing draft effectively what I am describing - >piggy-backing on e2e signalling? > >I don't believe we need any more abstract drafts if that's what you >mean - we need to focus on RSVP specifically now. We could perhaps >re-boot from Francois's original draft. > > > >Bob > >At 22:09 15/11/2012, Tom Taylor wrote: > >OK, I guess I see your point. I was too focussed on the calculations > >that are done at the Decision Point. > > > >It makes me wonder if I should revive that piggy-backing edge > >behaviour draft I once started. > > > >On 15/11/2012 4:02 PM, Bob Briscoe wrote: > >>Tom, > >> > >>The RSVP message I'm proposing doesn't say "Never mind the SESSION in > >>this message, I'm related to every flow with the same first hop". It > >>says "These are the marking probabilities for the SESSION in this > >>message". Then the PCN-ingress (not the message) infers that all other > >>flows that share the same aggregate will share the same marking > >>probability, because PCN marking on interior nodes is random and unbiased. > >> > >>It's a subtle distinction, but it preserves the semantics of RSVP > >>messages, without the three disadvantages of setting up an RSVP > >>aggregate that I mentioned. > >> > >>You will have seen from the rest of the message that I have not rejected > >>the concept of aggregation, I am merely saying that the PCN-ingress and > >>PCN-egress can hold the concept internally. > >> > >> > >>Bob > >> > >>At 16:42 15/11/2012, Tom Taylor wrote: > >>>I'm not sure the semantics of the PCN information -- particularly as > >>>it relates to flow termination -- are correct without some sort of > >>>concept of aggregation. Or can you really define an RSVP object that > >>>has semantics "Never mind the SESSION in this message, I'm related to > >>>every flow with the same first hop"? > >... > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_287273207==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> Georgios,<br><br> See the discussion with Tom - he gets what I'm saying. <br><br> Also, in my mail that started this thread (15 november 2012 14:07) I explained why you can get the benefits of aggregation by solely holding the concept of IEAs on the PCN-boundary nodes, without identifying an aggregate in the signalling protocol at all.<br><br> I also explained why identifying an aggregate in the signalling protocol led to three worse properties and nothing better.<br><br> Please argue with that, rather than talking about aggregates only in conceptual terms - and only in terms of whole RFCs, rather than specifics - that is where the problem stemmed from, I believe.<br><br> <br><br> Bob<br><br> At 10:26 17/11/2012, karagian@cs.utwente.nl wrote:<br><br> <blockquote type=cite class=cite cite="">Hi Bob, Hi Tom,<br><br>  <br><br> The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), is in my opinion architecturally and conceptually wrong!<br><br> The reason is the following!<br><br>  <br><br> 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.<br><br>  <br><br> 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.<br><br>  <br><br> 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.<br><br>  <br><br> Best regards,<br><br> Georgios<br><br>  <br> <hr> <font face="Tahoma" size=2><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> vrijdag 16 november 2012 21:03<br> <b>To:</b> Tom Taylor<br> <b>Cc:</b> Karagiannis, G. (EWI); anuragb@cisco.com; tsvwg@ietf.org; rsvp-dir@ietfa.amsl.com; PCN IETF list<br> <b>Onderwerp:</b> Re: [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03<br> </font><br> <font size=2>Tom,<br><br> The edge behaviour RFCs attempted to abstract over any signalling <br> protcol, but I think they ended up being biased towards the ITU way <br> of doing things, rather than an abstraction that encompassed both <br> RACF and RSVP, which was probably too ambitious.<br><br> Is you piggy-backing draft effectively what I am describing - <br> piggy-backing on e2e signalling?<br><br> I don't believe we need any more abstract drafts if that's what you <br> mean - we need to focus on RSVP specifically now. We could perhaps <br> re-boot from Francois's original draft.<br><br> <br><br> Bob<br><br> At 22:09 15/11/2012, Tom Taylor wrote:<br> >OK, I guess I see your point. I was too focussed on the calculations <br> >that are done at the Decision Point.<br> ><br> >It makes me wonder if I should revive that piggy-backing edge <br> >behaviour draft I once started.<br> ><br> >On 15/11/2012 4:02 PM, Bob Briscoe wrote:<br> >>Tom,<br> >><br> >>The RSVP message I'm proposing doesn't say "Never mind the SESSION in<br> >>this message, I'm related to every flow with the same first hop". It<br> >>says "These are the marking probabilities for the SESSION in this<br> >>message". Then the PCN-ingress (not the message) infers that all other<br> >>flows that share the same aggregate will share the same marking<br> >>probability, because PCN marking on interior nodes is random and unbiased.<br> >><br> >>It's a subtle distinction, but it preserves the semantics of RSVP<br> >>messages, without the three disadvantages of setting up an RSVP<br> >>aggregate that I mentioned.<br> >><br> >>You will have seen from the rest of the message that I have not rejected<br> >>the concept of aggregation, I am merely saying that the PCN-ingress and<br> >>PCN-egress can hold the concept internally.<br> >><br> >><br> >>Bob<br> >><br> >>At 16:42 15/11/2012, Tom Taylor wrote:<br> >>>I'm not sure the semantics of the PCN information -- particularly as<br> >>>it relates to flow termination -- are correct without some sort of<br> >>>concept of aggregation. Or can you really define an RSVP object that<br> >>>has semantics "Never mind the SESSION in this message, I'm related to<br> >>>every flow with the same first hop"?<br> >...<br><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design <br> </blockquote> <x-sigsep><p></x-sigsep> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design</font></body> </html> --=====================_287273207==.ALT-- From bob.briscoe@bt.com Tue Nov 20 13:40:02 2012 Return-Path: <bob.briscoe@bt.com> X-Original-To: rsvp-dir@ietfa.amsl.com Delivered-To: rsvp-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D447921F866C for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.155 X-Spam-Level: X-Spam-Status: No, score=-3.155 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeLM9r+Ftvt5 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:40:00 -0800 (PST) Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD5421F86BA for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:39:58 -0800 (PST) Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:39:56 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:39:55 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Tue, 20 Nov 2012 21:39:48 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353447588498; Tue, 20 Nov 2012 21:39:48 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAKLdkdb002838 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 21:39:46 GMT Message-ID: <201211202139.qAKLdkdb002838@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2012 21:39:47 +0000 To: <rsvp-dir@ietfa.amsl.com> From: Bob Briscoe <bob.briscoe@bt.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_288126433==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Subject: [rsvp-dir] Fwd: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: rsvp-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RSVP directorate <rsvp-dir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rsvp-dir> List-Post: <mailto:rsvp-dir@ietf.org> List-Help: <mailto:rsvp-dir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 20 Nov 2012 21:40:03 -0000 --=====================_288126433==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed 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: <karagian@cs.utwente.nl> >From: Bob Briscoe <bob.briscoe@bt.com> >Subject: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 >Cc: <carlberg@g11.org.uk>, <tsvwg@ietf.org>, ><philip.eardley@bt.com>, <pcn@ietf.org>, <rsvp-dir@ietfa.amsl.com>, ><sob@harvard.edu>, <slblake@petri-meat.com>, <gorry@erg.abdn.ac.uk>, ><jmpolk@cisco.com>, <anuragb@cisco.com> > >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, karagian@cs.utwente.nl 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 [bob.briscoe@bt.com] >>Verzonden: donderdag 15 november 2012 14:07 >>To: Karagiannis, G. (EWI); anuragb@cisco.com >>Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; >>philip.eardley@bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com >>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, karagian@cs.utwente.nl 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:bob.briscoe@bt.com>mailto:bob.briscoe@bt.com] >>>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:karagian@cs.utwente.nl>karagian@cs.utwente.nl " >>><<mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl > >>>Date: Saturday, November 10, 2012 8:10 AM >>>To: "<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com" >>><<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com> >>>Cc: "<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk" >>><<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk>, Anurag Bhargava >>><<mailto:anuragb@cisco.com>anuragb@cisco.com>, >>>"<mailto:tsvwg@ietf.org>tsvwg@ietf.org" >>><<mailto:tsvwg@ietf.org>tsvwg@ietf.org>, >>>"<mailto:philip.eardley@bt.com>philip.eardley@bt.com " >>><<mailto:philip.eardley@bt.com>philip.eardley@bt.com > >>>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:bob.briscoe@bt.com>bob.briscoe@bt.com] >>>Verzonden: vrijdag 9 november 2012 16:33 >>>To: Karagiannis, G. (EWI) >>>Cc: <mailto:carlberg@g11.org.uk>carlberg@g11.org.uk; >>><mailto:anuragb@cisco.com>anuragb@cisco.com; >>><mailto:tsvwg@ietf.org>tsvwg@ietf.org; 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:karagian@cs.utwente.nl>karagian@cs.utwente.nl 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:karagian@cs.utwente.nl>karagian@cs.utwente.nl 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:carlberg@g11.org.uk>carlberg@g11.org.uk] >>> >Verzonden: maandag 5 november 2012 13:23 >>> >To: Karagiannis, G. (EWI) >>> >Cc: <mailto:tsvwg@ietf.org>tsvwg@ietf.org; >>> <mailto:anuragb@cisco.com>anuragb@cisco.com >>> >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 --=====================_288126433==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> 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.<br><br> Bob<br><br> <br> <blockquote type=cite class=cite cite="">Date: Fri, 16 Nov 2012 20:14:33 +0000<br> To: <karagian@cs.utwente.nl><br> From: Bob Briscoe <bob.briscoe@bt.com><br> Subject: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03<br> Cc: <carlberg@g11.org.uk>, <tsvwg@ietf.org>, <philip.eardley@bt.com>, <pcn@ietf.org>, <rsvp-dir@ietfa.amsl.com>, <sob@harvard.edu>, <slblake@petri-meat.com>, <gorry@erg.abdn.ac.uk>, <jmpolk@cisco.com>, <anuragb@cisco.com><br><br> Georgios,<br><br> Yes, I apologise for not reviewing earlier. I appreciate you followed the procedure.<br><br> 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.<br><br> 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). <br><br> However, I admit that it would have been preferable for everyone if I had made this effort earlier.<br><br> <br> Bob<br><br> At 13:02 16/11/2012, karagian@cs.utwente.nl wrote:<br><br> <blockquote type=cite class=cite cite="">Hi Bob,<br><br> $B!!(B<br><br> Thanks for your comments!<br><br> 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:<br><br>  <br><br> <a href="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</a> <br><br>  <br><br> 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):<br><br>  <br><br> <a href="http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf" eudora="autourl"> http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf</a><br><br> $B!!(B<br><br> In particular in slide 4 mentions:<br><br> "All PCN charter items are fulfilled, except:<br><br> Submit Encoding and Transport of PCN from Domain Egress to Ingress to the IESG for consideration as a Proposed Standard RFC<br><br> Pairs of PCN edge nodes use ingress-egress-aggregates (IEA):<br><br> 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"<br><br> Furthermore Slide 5 mentions:<br><br> $B!!(B<br><br> "IETF QoS signaling protocols to solve problem:<br><br> Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 5979)<br><br> Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175)<br><br> Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC4860)<br><br> All can be used, but for time being selected RFC 4860 due:<br><br> possible deployment interest<br><br> supports RFC 3175 and additional features such as: <br><br> support of multiple IEAs from same pair of PCN edge nodes <br><br> support of bandwidth reduction for individual flows (RFC 4495)"<br><br> $B!!(B<br><br> Before IETF 81 and during IETF 81 this point has been discussed.<br><br> The outcome of these discussions is that short after IETF 81, the individual draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) <br><br> become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which also was using RFC 4860 as the base signaling protocol.<br><br> $B!!(B<br><br> 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!<br><br> $B!!(B<br><br> So both the PCN WG and tsvwg WG agreed that this specifictaion should use as basis the generic RSVP aggregation protocol!<br><br> $B!!(B<br><br> $B!!(B<br><br> $B!!(B<br><br> In a subsequent email and on a later moment I will also answer to your further remarks!<br><br> $B!!(B<br><br> Best regards,<br><br> Georgios<br> <hr> <font face="Tahoma" size=2><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> donderdag 15 november 2012 14:07<br> <b>To:</b> Karagiannis, G. (EWI); anuragb@cisco.com<br> <b>Cc:</b> carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; philip.eardley@bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com<br> <b>Onderwerp:</b> Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03<br> </font><br> Georgios, Anurag,<br><br> Below is the main point of my review, arguing that aggregate reservations are redundant. I'm reviewing as:<br> - a member of the RSVP directorate<br> - one of the early PCN design team<br> - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based.<br><br> I would have missed any decision to use aggregate reservations. Pls point me to the relevant discussion (e.g. Subject line / date).<br><br> 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. <br><br> Nonetheless, here's why I believe RSVP aggregation is redundant:<br><br> 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.<br><br> {Note 1: except in one case described later - but it doesn't require all the other baggage of aggregate reservations}<br><br> ==Background==<br> 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].<br><br> In contrast, as you correctly point out (in Section 2.1.7), PCN requires absolutely no reservation-related state on interior nodes.<br><br> ==Disadvantages==<br> Requiring PCN to use aggregate reservations has the following three disadvantages and no advantages:<br><br> 1) Redundant Processing<br> 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). <br><br> 2) Reduced Resilience<br> 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.)<br><br> 3) Extra Latency<br> 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.<br><br> ==PATH==<br><br> 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.<br><br> 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.<br><br> ==RESV==<br><br> 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.<br><br> ==PCN object==<br><br> 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:<br> 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.<br> ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in pcn-rsvp-03.<br><br> 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).<br><br> Which of the two is best is a question of message timing...<br><br> * For e2e admission decisions, the PCN object is only needed at the time each e2e RESV is sent, so option i) makes sense.<br><br> * For flow rate reduction or flow termination decisions, the deaggregator needs to regularly send PCN objects to the ingress. <br><br> 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:<br> a) any one of the e2e SESSIONs in the aggregate, <br> b) the aggregate.<br><br> In case (a), the message would need to somehow tell the ingress not to forward this RESV refresh to the RSVP previous hop.<br><br> 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. <br><br> 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.<br><br> <br><br> 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.<br><br> <br> Bob<br><br> At 18:23 14/11/2012, karagian@cs.utwente.nl wrote:<br> <blockquote type=cite class=cite cite="">Hi Bob,<br>  <br> Regarding the generic aggregated RSVP selection, actually the PCN WG agreed with this selection!<br> This was actually the first step that was needed for this work, and the PCN WG had no main objections on this selection!<br>  <br> So I do not understand your remark that your comment will have major implications!<br>  <br> 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!<br>  <br>  <br> Best regards,<br> Georgios<br>  <br>  <br>  <br>  <br> <b>From:</b> Bob Briscoe [<a href="mailto:bob.briscoe@bt.com">mailto:bob.briscoe@bt.com</a>] <br> <b>Sent:</b> woensdag 14 november 2012 12:57<br> <b>To:</b> Anurag Bhargava (anuragb)<br> <b>Cc:</b> Karagiannis, G. (EWI)<br> <b>Subject:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br>  <br> Anurag,<br><br> I have my comments half-written up. I will try to finish them by the end of today.<br><br> 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. <br><br> However, my main comments will concern the use of aggregated reservations (as I said at the mic), so that could have major implications.<br><br> <br> Bob<br><br> At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote:<br><br> Hi Bob,<br>  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.<br>  May be we can conference after US thanksgiving week and collaborate the text and try to move forward.<br><br>  Please let us know what might be a good time and I can schedule a Webex conf.<br><br> Thx<br> -Anurag<br><br> From: "<a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> " <<a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> ><br> Date: Saturday, November 10, 2012 8:10 AM<br> To: "<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>" <<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>><br> Cc: "<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>" <<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>>, Anurag Bhargava <<a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a>>, "<a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>" <<a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>>, "<a href="mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> " <<a href="mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> ><br> Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br><br> Hi Bob,<br><br>  <br><br> Thanks very much for the comments! I think that they are very useful! <br><br>  <br><br> 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 <br> 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.)"<br> <br>  <br><br> Best regards,<br><br> Georgios<br><br>  <br> <hr> <b>Van:</b> Bob Briscoe [<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> vrijdag 9 november 2012 16:33<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; <a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a>; <a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; EARDLEY, Phil<br> <b>Onderwerp:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br><br> Georgios,<br><br> I shall post my full review of this draft in the next few days (needs <br> typing up - currently scribbled on a paper copy). This email is <br> solely in response to your answer about on-path vs off-path policy.<br><br> At 18:55 04/11/2012, <a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> wrote:<br> >So in this case an additional signaling protocol will be<br> >needed to be specified that covers the signaling between the <br> >PCN-egress-node and the centralized node<br> >and between PCN-ingress-node and the centralized node.<br> >In PCN we decdided to only focus on the specification of the <br> >signaling protocol that completes the<br> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus <br> >on the signaling protocol<br> >used between the edge nodes and the centralized node.<br><br> When I/we originally designed CL-PCN over RSVP (2005), the idea was <br> that it would fit with the policy-based admission control (PBAC) <br> architecture of RFC2753. In this architecture, an Intserv node at the <br> ingress to a domain is the policy enforcement point (PEP), and it <br> refers to a logically centralised 'policy decision point' (PDP) for <br> decisions on which flows to block/terminate, typically using COPS.<br><br> To make this doc fit the PBAC framework, all we have to do is:<br> * Describe the PCN-ingress only as the PCN-ingress and not as the <br> decision point (find 'decision' throughout doc and fix).<br> * Add a section saying the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), <br> which will respond to the PCN-ingress as per RFC2753. (Alternatively <br> the PCN-ingress could itself be the policy decision point.)<br> * Refer to this new PBAC section from Section 3.11 giving the <br> admission decision procedure.<br><br> * Some people might think this means COPS will need new protocol <br> elements to carry PCN marking rates to the policy decision point. But <br> PCN marking rates are irrelevant to the policy decision: the <br> PCN-ingress just uses PCN to determine whether it needs to block or <br> terminate, and it refers to the policy decision point for which flows <br> to block/terminate.<br><br> * Unfortunately, neither of the two PCN system descriptions [RFC6661, <br> RFC6662] describe a PBAC-based case. The architecture [RFC5559] <br> refers to the PBAC framework [RFC2753] but unfortunately doesn't <br> spell out how it fits. Originally, I referenced PBAC from RFC5559, <br> but just as the PCN w-g was closing I realised that (some?) others in <br> the PCN w-g were working under the assumption that the only way to <br> talk to a centralised policy node was from the egress, possibly <br> without being aware of the contents of RFC2753.<br><br> I think it's OK to introduce a new architectural arrangement in this <br> RSVP doc, given RFC2753 is specific to the way RSVP works.<br><br> <br> Bob<br><br> <br><br> At 12:28 05/11/2012, <a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> wrote:<br> >Hi Ken,<br> ><br> >Thank you very much!<br> >We will try to catch Francois and discuss the last (in line) issue with him!<br> ><br> >Best regards,<br> >Georgios<br> ><br> >________________________________________<br> >Van: ken carlberg [<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>]<br> >Verzonden: maandag 5 november 2012 13:23<br> >To: Karagiannis, G. (EWI)<br> >Cc: <a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; <a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a><br> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03<br> ><br> >Georgios,<br> ><br> > > Georgios: We will try to explain the rationale of why we consider <br> > that RSVP can only be used for the situation that the<br> > > decision point is collocated with the PCN-ingress-node. The main <br> > reason of this is that in the case that the<br> > > decision point is collocated with the PCN-ingress-node,the <br> > required signaling protocol used to complete a<br> > > feedback loop from egress to ingress can be an entirely on-path <br> > protocol, like what RSVP is.<br> > > In the situation that the the decision point is a centralized <br> > node, then the required signaling protocol<br> > > can be a combination of an on-path and off-path protocol. This is <br> > because the<br> > > decision point might not be located on the data path! So in this <br> > case an additional signaling protocol will be<br> > > needed to be specified that covers the signaling between the <br> > PCN-egress-node and the centralized node<br> > > and between PCN-ingress-node and the centralized node.<br> > > In PCN we decdided to only focus on the specification of the <br> > signaling protocol that completes the<br> > > feedback loop from PCN-egress-node to PCN-ingress-node and to <br> > focus on the signaling protocol<br> > > used between the edge nodes and the centralized node.<br> > > This is also the reason of why PCN WG decided to only focus on <br> > the situation that the decision point is<br> > > collocated with the PCN-ingress-node.<br> ><br> >Great, this is helpful, and this is the information that needs to be <br> >in the draft.<br> ><br> > >> 6) This comment is just for you to contemplate -- I'm not <br> > expecting any changes.<br> > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs.<br> > >> And it seems a lot of this is a carry over from rfc-4860, so in <br> > a sense you are inheriting an approach that<br> > >> was agreed to from an earlier effort.  But I wonder in the back <br> > of my mind, what impact occurs if<br> > >> an implementor doesn't follow the SHOULD?  Does the design break <br> > in supporting PCN?<br> > >> Again, I want to stress that this isnt a show stopper, but I <br> > would appreciate it if you gave it some thought.<br> > ><br> > > Georgios: Yes, in several cases the design might break in supporting PCN.<br> > > This is also the reason of using SHOULD instead of MAY. Do you <br> > want us to explain this in more detail in the draft?<br> ><br> >well, actually, I was more curious as to why a number of these cases <br> >are SHOULD instead of MUST.  Again, the SHOULD's in your document <br> >seem to be a carry-over from rfc-4860 (which set the precedent), so <br> >its a bit unfair for you to explain what was done in an earlier <br> >effort.  I just wanted to make sure you gave some thought to the <br> >subject.  And if things will break if SHOULD is not followed by an <br> >implementer/configuration, then maybe you should be more stringent <br> >and change things to MUST.  Perhaps a brief private conversation <br> >with Francois Le Faucheur will be helpful.<br> ><br> >cheers,<br> ><br> >-ken<br><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design <br><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design</blockquote><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design </blockquote><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design </blockquote> <x-sigsep><p></x-sigsep> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design</body> </html> --=====================_288126433==.ALT-- From bob.briscoe@bt.com Tue Nov 20 13:41:56 2012 Return-Path: <bob.briscoe@bt.com> X-Original-To: rsvp-dir@ietfa.amsl.com Delivered-To: rsvp-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2EF21F86EE for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX4c11AzwWYx for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:41:52 -0800 (PST) Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) by ietfa.amsl.com (Postfix) with ESMTP id 31E4721F86E5 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:41:51 -0800 (PST) Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:41:46 +0000 Received: from dyw02134app01.domain1.systemhost.net (193.113.249.13) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:41:49 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com (147.149.196.177) by dyw02134app01.domain1.systemhost.net (10.35.25.214) with Microsoft SMTP Server id 14.2.309.2; Tue, 20 Nov 2012 21:41:47 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353447707899; Tue, 20 Nov 2012 21:41:47 +0000 Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAKLfj6h002853 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 21:41:45 GMT Message-ID: <201211202141.qAKLfj6h002853@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2012 21:41:46 +0000 To: <rsvp-dir@ietfa.amsl.com> From: Bob Briscoe <bob.briscoe@bt.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_288246115==.ALT" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 Subject: [rsvp-dir] Fwd: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 X-BeenThere: rsvp-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RSVP directorate <rsvp-dir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/rsvp-dir> List-Post: <mailto:rsvp-dir@ietf.org> List-Help: <mailto:rsvp-dir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 20 Nov 2012 21:41:56 -0000 --=====================_288246115==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed For the record, the posting below is blocked awaiting moderator approval due to too many recipients. I am re-sending just to the RSVP-DIR list that raised the objection. In future I'll cut the distr. Bob >Date: Tue, 20 Nov 2012 21:29:26 +0000 >To: <karagian@cs.utwente.nl> >From: Bob Briscoe <bob.briscoe@bt.com> >Subject: RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03 >Cc: <carlberg@g11.org.uk>, <tsvwg@ietf.org>, ><philip.eardley@bt.com>, <pcn@ietf.org>, <rsvp-dir@ietfa.amsl.com>, ><sob@harvard.edu>, <slblake@petri-meat.com>, <gorry@erg.abdn.ac.uk>, ><jmpolk@cisco.com>, <anuragb@cisco.com> > >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, karagian@cs.utwente.nl 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 [bob.briscoe@bt.com] >>Verzonden: vrijdag 16 november 2012 21:14 >>To: Karagiannis, G. (EWI) >>Cc: carlberg@g11.org.uk; tsvwg@ietf.org; philip.eardley@bt.com; >>pcn@ietf.org; rsvp-dir@ietfa.amsl.com; sob@harvard.edu; >>slblake@petri-meat.com; gorry@erg.abdn.ac.uk; jmpolk@cisco.com; >>anuragb@cisco.com >>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, karagian@cs.utwente.nl 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 [bob.briscoe@bt.com] >>>Verzonden: donderdag 15 november 2012 14:07 >>>To: Karagiannis, G. (EWI); anuragb@cisco.com >>>Cc: carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; >>>philip.eardley@bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com >>>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, karagian@cs.utwente.nl 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:bob.briscoe@bt.com>mailto:bob.briscoe@bt.com] >>>>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:karagian@cs.utwente.nl>karagian@cs.utwente.nl " >>>><<mailto:karagian@cs.utwente.nl>karagian@cs.utwente.nl > >>>>Date: Saturday, November 10, 2012 8:10 AM >>>>To: "<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com" >>>><<mailto:bob.briscoe@bt.com>bob.briscoe@bt.com> >>>>Cc: "<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk" >>>><<mailto:carlberg@g11.org.uk>carlberg@g11.org.uk>, Anurag >>>>Bhargava <<mailto:anuragb@cisco.com>anuragb@cisco.com>, >>>>"<mailto:tsvwg@ietf.org>tsvwg@ietf.org" >>>><<mailto:tsvwg@ietf.org>tsvwg@ietf.org>, >>>>"<mailto:philip.eardley@bt.com>philip.eardley@bt.com " >>>><<mailto:philip.eardley@bt.com>philip.eardley@bt.com > >>>>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:bob.briscoe@bt.com>bob.briscoe@bt.com] >>>>Verzonden: vrijdag 9 november 2012 16:33 >>>>To: Karagiannis, G. (EWI) >>>>Cc: <mailto:carlberg@g11.org.uk>carlberg@g11.org.uk; >>>><mailto:anuragb@cisco.com>anuragb@cisco.com; >>>><mailto:tsvwg@ietf.org>tsvwg@ietf.org; 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:karagian@cs.utwente.nl>karagian@cs.utwente.nl 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:karagian@cs.utwente.nl>karagian@cs.utwente.nl 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:carlberg@g11.org.uk>carlberg@g11.org.uk] >>>> >Verzonden: maandag 5 november 2012 13:23 >>>> >To: Karagiannis, G. (EWI) >>>> >Cc: <mailto:tsvwg@ietf.org>tsvwg@ietf.org; >>>> <mailto:anuragb@cisco.com>anuragb@cisco.com >>>> >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 ________________________________________________________________ Bob Briscoe, BT Innovate & Design --=====================_288246115==.ALT Content-Type: text/html; charset="us-ascii" <html> <body> For the record, the posting below is blocked awaiting moderator approval due to too many recipients. I am re-sending just to the RSVP-DIR list that raised the objection. In future I'll cut the distr.<br><br> <br> Bob<br><br> <blockquote type=cite class=cite cite="">Date: Tue, 20 Nov 2012 21:29:26 +0000<br> To: <karagian@cs.utwente.nl><br> From: Bob Briscoe <bob.briscoe@bt.com><br> Subject: RE: Redundant aggregate reservations:  draft-ietf-tsvwg-rsvp-pcn-03<br> Cc: <carlberg@g11.org.uk>, <tsvwg@ietf.org>, <philip.eardley@bt.com>, <pcn@ietf.org>, <rsvp-dir@ietfa.amsl.com>, <sob@harvard.edu>, <slblake@petri-meat.com>, <gorry@erg.abdn.ac.uk>, <jmpolk@cisco.com>, <anuragb@cisco.com><br><br> Georgios,<br><br> 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).<br><br> 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.<br><br> <br> Bob<br><br> At 10:29 17/11/2012, karagian@cs.utwente.nl wrote:<br><br> <blockquote type=cite class=cite cite="">Hi Bob,<br><br>  <br><br> 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.<br><br>  <br><br> The solution that you are proposing, i.e., use of the e2e RSVP (RFC2205), is in my opinion architecturally and conceptually wrong!<br><br> The reason is the following!<br><br>  <br><br> 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.<br><br> 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.<br><br> 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.<br><br>  <br><br> Best regards,<br><br> Georgios<br><br> <hr> <font face="Tahoma" size=2><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> vrijdag 16 november 2012 21:14<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> carlberg@g11.org.uk; tsvwg@ietf.org; philip.eardley@bt.com; pcn@ietf.org; rsvp-dir@ietfa.amsl.com; sob@harvard.edu; slblake@petri-meat.com; gorry@erg.abdn.ac.uk; jmpolk@cisco.com; anuragb@cisco.com<br> <b>Onderwerp:</b> RE: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03<br> </font><br> Georgios,<br><br> Yes, I apologise for not reviewing earlier. I appreciate you followed the procedure.<br><br> 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.<br><br> 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). <br><br> However, I admit that it would have been preferable for everyone if I had made this effort earlier.<br><br> <br> Bob<br><br> At 13:02 16/11/2012, karagian@cs.utwente.nl wrote:<br><br> <blockquote type=cite class=cite cite="">Hi Bob,<br><br> $B!!(B<br><br> Thanks for your comments!<br><br> 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:<br><br>  <br><br> <a href="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</a> <br><br>  <br><br> 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):<br><br>  <br><br> <a href="http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf"> http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf</a><br><br> $B!!(B<br><br> In particular in slide 4 mentions:<br><br> "All PCN charter items are fulfilled, except:<br><br> Submit Encoding and Transport of PCN from Domain Egress to Ingress to the IESG for consideration as a Proposed Standard RFC<br><br> Pairs of PCN edge nodes use ingress-egress-aggregates (IEA):<br><br> 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"<br><br> Furthermore Slide 5 mentions:<br><br> $B!!(B<br><br> "IETF QoS signaling protocols to solve problem:<br><br> Next Steps in Signaling Protocol (NSIS) subset (RFC 5971, RFC 5974, RFC 5979)<br><br> Aggregation of RSVP for IPv4 and IPv6 Reservations (RFC3175)<br><br> Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations (RFC4860)<br><br> All can be used, but for time being selected RFC 4860 due:<br><br> possible deployment interest<br><br> supports RFC 3175 and additional features such as: <br><br> support of multiple IEAs from same pair of PCN edge nodes <br><br> support of bandwidth reduction for individual flows (RFC 4495)"<br><br> $B!!(B<br><br> Before IETF 81 and during IETF 81 this point has been discussed.<br><br> The outcome of these discussions is that short after IETF 81, the individual draft (draft-karagiannis-pcn-tsvwg-rsvp-pcn-01) <br><br> become (after small modifications) the draft-ietf-tsvwg-rsvp-pcn-00, which also was using RFC 4860 as the base signaling protocol.<br><br> $B!!(B<br><br> 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!<br><br> $B!!(B<br><br> So both the PCN WG and tsvwg WG agreed that this specifictaion should use as basis the generic RSVP aggregation protocol!<br><br> $B!!(B<br><br> $B!!(B<br><br> $B!!(B<br><br> In a subsequent email and on a later moment I will also answer to your further remarks!<br><br> $B!!(B<br><br> Best regards,<br><br> Georgios<br> <hr> <font face="Tahoma" size=2><b>Van:</b> Bob Briscoe [bob.briscoe@bt.com]<br> <b>Verzonden:</b> donderdag 15 november 2012 14:07<br> <b>To:</b> Karagiannis, G. (EWI); anuragb@cisco.com<br> <b>Cc:</b> carlberg@g11.org.uk; anuragb@cisco.com; tsvwg@ietf.org; philip.eardley@bt.com; PCN IETF list; rsvp-dir@ietfa.amsl.com<br> <b>Onderwerp:</b> Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03<br> </font><br> Georgios, Anurag,<br><br> Below is the main point of my review, arguing that aggregate reservations are redundant. I'm reviewing as:<br> - a member of the RSVP directorate<br> - one of the early PCN design team<br> - a co-author of draft-lefaucheur-rsvp-ecn-01, on which this draft is based.<br><br> I would have missed any decision to use aggregate reservations. Pls point me to the relevant discussion (e.g. Subject line / date).<br><br> 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. <br><br> Nonetheless, here's why I believe RSVP aggregation is redundant:<br><br> 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.<br><br> {Note 1: except in one case described later - but it doesn't require all the other baggage of aggregate reservations}<br><br> ==Background==<br> 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].<br><br> In contrast, as you correctly point out (in Section 2.1.7), PCN requires absolutely no reservation-related state on interior nodes.<br><br> ==Disadvantages==<br> Requiring PCN to use aggregate reservations has the following three disadvantages and no advantages:<br><br> 1) Redundant Processing<br> 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). <br><br> 2) Reduced Resilience<br> 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.)<br><br> 3) Extra Latency<br> 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.<br><br> ==PATH==<br><br> 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.<br><br> 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.<br><br> ==RESV==<br><br> 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.<br><br> ==PCN object==<br><br> 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:<br> 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.<br> ii) the PCN-egress attaches a PCN object to an aggregate reservation, as in pcn-rsvp-03.<br><br> 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).<br><br> Which of the two is best is a question of message timing...<br><br> * For e2e admission decisions, the PCN object is only needed at the time each e2e RESV is sent, so option i) makes sense.<br><br> * For flow rate reduction or flow termination decisions, the deaggregator needs to regularly send PCN objects to the ingress. <br><br> 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:<br> a) any one of the e2e SESSIONs in the aggregate, <br> b) the aggregate.<br><br> In case (a), the message would need to somehow tell the ingress not to forward this RESV refresh to the RSVP previous hop.<br><br> 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. <br><br> 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.<br><br> <br><br> 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.<br><br> <br> Bob<br><br> At 18:23 14/11/2012, karagian@cs.utwente.nl wrote:<br> <blockquote type=cite class=cite cite="">Hi Bob,<br>  <br> Regarding the generic aggregated RSVP selection, actually the PCN WG agreed with this selection!<br> This was actually the first step that was needed for this work, and the PCN WG had no main objections on this selection!<br>  <br> So I do not understand your remark that your comment will have major implications!<br>  <br> 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!<br>  <br>  <br> Best regards,<br> Georgios<br>  <br>  <br>  <br>  <br> <b>From:</b> Bob Briscoe [<a href="mailto:bob.briscoe@bt.com">mailto:bob.briscoe@bt.com</a>] <br> <b>Sent:</b> woensdag 14 november 2012 12:57<br> <b>To:</b> Anurag Bhargava (anuragb)<br> <b>Cc:</b> Karagiannis, G. (EWI)<br> <b>Subject:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br>  <br> Anurag,<br><br> I have my comments half-written up. I will try to finish them by the end of today.<br><br> 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. <br><br> However, my main comments will concern the use of aggregated reservations (as I said at the mic), so that could have major implications.<br><br> <br> Bob<br><br> At 20:14 13/11/2012, Anurag Bhargava (anuragb) wrote:<br><br> Hi Bob,<br>  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.<br>  May be we can conference after US thanksgiving week and collaborate the text and try to move forward.<br><br>  Please let us know what might be a good time and I can schedule a Webex conf.<br><br> Thx<br> -Anurag<br><br> From: "<a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> " <<a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> ><br> Date: Saturday, November 10, 2012 8:10 AM<br> To: "<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>" <<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>><br> Cc: "<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>" <<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>>, Anurag Bhargava <<a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a>>, "<a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>" <<a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>>, "<a href="mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> " <<a href="mailto:philip.eardley@bt.com">philip.eardley@bt.com</a> ><br> Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br><br> Hi Bob,<br><br>  <br><br> Thanks very much for the comments! I think that they are very useful! <br><br>  <br><br> 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 <br> 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.)"<br><br>  <br><br> Best regards,<br><br> Georgios<br><br>  <br> <hr> <b>Van:</b> Bob Briscoe [<a href="mailto:bob.briscoe@bt.com">bob.briscoe@bt.com</a>]<br> <b>Verzonden:</b> vrijdag 9 november 2012 16:33<br> <b>To:</b> Karagiannis, G. (EWI)<br> <b>Cc:</b> <a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>; <a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a>; <a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; EARDLEY, Phil<br> <b>Onderwerp:</b> Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03<br><br> Georgios,<br><br> I shall post my full review of this draft in the next few days (needs <br> typing up - currently scribbled on a paper copy). This email is <br> solely in response to your answer about on-path vs off-path policy.<br><br> At 18:55 04/11/2012, <a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> wrote:<br> >So in this case an additional signaling protocol will be<br> >needed to be specified that covers the signaling between the <br> >PCN-egress-node and the centralized node<br> >and between PCN-ingress-node and the centralized node.<br> >In PCN we decdided to only focus on the specification of the <br> >signaling protocol that completes the<br> >feedback loop from PCN-egress-node to PCN-ingress-node and to focus <br> >on the signaling protocol<br> >used between the edge nodes and the centralized node.<br><br> When I/we originally designed CL-PCN over RSVP (2005), the idea was <br> that it would fit with the policy-based admission control (PBAC) <br> architecture of RFC2753. In this architecture, an Intserv node at the <br> ingress to a domain is the policy enforcement point (PEP), and it <br> refers to a logically centralised 'policy decision point' (PDP) for <br> decisions on which flows to block/terminate, typically using COPS.<br><br> To make this doc fit the PBAC framework, all we have to do is:<br> * Describe the PCN-ingress only as the PCN-ingress and not as the <br> decision point (find 'decision' throughout doc and fix).<br> * Add a section saying the PCN-ingress can refer flow admission and <br> termination decisions to a central decision point (using e.g. COPS), <br> which will respond to the PCN-ingress as per RFC2753. (Alternatively <br> the PCN-ingress could itself be the policy decision point.)<br> * Refer to this new PBAC section from Section 3.11 giving the <br> admission decision procedure.<br><br> * Some people might think this means COPS will need new protocol <br> elements to carry PCN marking rates to the policy decision point. But <br> PCN marking rates are irrelevant to the policy decision: the <br> PCN-ingress just uses PCN to determine whether it needs to block or <br> terminate, and it refers to the policy decision point for which flows <br> to block/terminate.<br><br> * Unfortunately, neither of the two PCN system descriptions [RFC6661, <br> RFC6662] describe a PBAC-based case. The architecture [RFC5559] <br> refers to the PBAC framework [RFC2753] but unfortunately doesn't <br> spell out how it fits. Originally, I referenced PBAC from RFC5559, <br> but just as the PCN w-g was closing I realised that (some?) others in <br> the PCN w-g were working under the assumption that the only way to <br> talk to a centralised policy node was from the egress, possibly <br> without being aware of the contents of RFC2753.<br><br> I think it's OK to introduce a new architectural arrangement in this <br> RSVP doc, given RFC2753 is specific to the way RSVP works.<br><br> <br> Bob<br><br> <br><br> At 12:28 05/11/2012, <a href="mailto:karagian@cs.utwente.nl">karagian@cs.utwente.nl</a> wrote:<br> >Hi Ken,<br> ><br> >Thank you very much!<br> >We will try to catch Francois and discuss the last (in line) issue with him!<br> ><br> >Best regards,<br> >Georgios<br> ><br> >________________________________________<br> >Van: ken carlberg [<a href="mailto:carlberg@g11.org.uk">carlberg@g11.org.uk</a>]<br> >Verzonden: maandag 5 november 2012 13:23<br> >To: Karagiannis, G. (EWI)<br> >Cc: <a href="mailto:tsvwg@ietf.org">tsvwg@ietf.org</a>; <a href="mailto:anuragb@cisco.com">anuragb@cisco.com</a><br> >Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03<br> ><br> >Georgios,<br> ><br> > > Georgios: We will try to explain the rationale of why we consider <br> > that RSVP can only be used for the situation that the<br> > > decision point is collocated with the PCN-ingress-node. The main <br> > reason of this is that in the case that the<br> > > decision point is collocated with the PCN-ingress-node,the <br> > required signaling protocol used to complete a<br> > > feedback loop from egress to ingress can be an entirely on-path <br> > protocol, like what RSVP is.<br> > > In the situation that the the decision point is a centralized <br> > node, then the required signaling protocol<br> > > can be a combination of an on-path and off-path protocol. This is <br> > because the<br> > > decision point might not be located on the data path! So in this <br> > case an additional signaling protocol will be<br> > > needed to be specified that covers the signaling between the <br> > PCN-egress-node and the centralized node<br> > > and between PCN-ingress-node and the centralized node.<br> > > In PCN we decdided to only focus on the specification of the <br> > signaling protocol that completes the<br> > > feedback loop from PCN-egress-node to PCN-ingress-node and to <br> > focus on the signaling protocol<br> > > used between the edge nodes and the centralized node.<br> > > This is also the reason of why PCN WG decided to only focus on <br> > the situation that the decision point is<br> > > collocated with the PCN-ingress-node.<br> ><br> >Great, this is helpful, and this is the information that needs to be <br> >in the draft.<br> ><br> > >> 6) This comment is just for you to contemplate -- I'm not <br> > expecting any changes.<br> > >> I noticed that you have a fair number of SHOULD, and some SHOULD NOTs.<br> > >> And it seems a lot of this is a carry over from rfc-4860, so in <br> > a sense you are inheriting an approach that<br> > >> was agreed to from an earlier effort.  But I wonder in the back <br> > of my mind, what impact occurs if<br> > >> an implementor doesn't follow the SHOULD?  Does the design break <br> > in supporting PCN?<br> > >> Again, I want to stress that this isnt a show stopper, but I <br> > would appreciate it if you gave it some thought.<br> > ><br> > > Georgios: Yes, in several cases the design might break in supporting PCN.<br> > > This is also the reason of using SHOULD instead of MAY. Do you <br> > want us to explain this in more detail in the draft?<br> ><br> >well, actually, I was more curious as to why a number of these cases <br> >are SHOULD instead of MUST.  Again, the SHOULD's in your document <br> >seem to be a carry-over from rfc-4860 (which set the precedent), so <br> >its a bit unfair for you to explain what was done in an earlier <br> >effort.  I just wanted to make sure you gave some thought to the <br> >subject.  And if things will break if SHOULD is not followed by an <br> >implementer/configuration, then maybe you should be more stringent <br> >and change things to MUST.  Perhaps a brief private conversation <br> >with Francois Le Faucheur will be helpful.<br> ><br> >cheers,<br> ><br> >-ken<br><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design <br><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design</blockquote><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design </blockquote><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design </blockquote><br> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design </blockquote> <x-sigsep><p></x-sigsep> ________________________________________________________________<br> Bob Briscoe,                                BT Innovate & Design</body> </html> --=====================_288246115==.ALT--