Subject: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

From: ken carlberg <[email-masked]>
Date: Thu, 1 Nov 2012 16:21:21 -0400

Hi Georgios and Anurag,

I took a look at the draft and overall, it seems fine, though I do have a few comments.  Mostly for clarification.

1) The Introduction dives right into what I would see as background information.  You need to add some text in the beginning of Section 1 that tells the reader what you plan to do (ie, leverage RSVP in support of PCN) and explain that PCN needs a signaling protocol to complete a feedback loop from egress to ingress.

2) You need to review the terminology section in more detail.  Some of the items in this section are not found anywhere else in the body of the draft (eg, t_meas).  I would also move the terminology subsection further up in the section because you start talking about some terms early on and then you define them later.

3) in some cases, you duplicate the definition of the terminology in the body of the draft, and in one instance with some different text/references.  I think once you define the term, you don't need to define it again.  (eg, ingress-egress-aggregate)

4) in quite a few places, you defer additional explanation to a particular RFC. An example being:

	2.1.3.  Deaggregator (PCN-egress-node) Determination

	   In this document it is considered that for the determination of the 
	   Deaggregator, the same methods can be used as the ones described in 
	   [RFC4860].  

However, you do not point the reader to the specific section within that reference.  Given how often this is done, I think it would be helpful to be more specific and identify the section/subsection in that refernce that you are referring to.

5) On page 5, you state the following:

	  The PCN-egress-nodes measure the rates of differently marked 
	   PCN-traffic in periodic intervals and report these rates to the 
	   decision points for admission control and flow termination, based on 	
	   which they take their decisions. The decision points may be 
	   collocated with the PCN-ingress-nodes or their function may be 
	   implemented in a centralized node. For more details see [RFC5559], 
	   [RFC6661], [RFC6662]. In this document it is considered that the 
	   decision point is collocated with the PCN-ingress-node.

The last sentence catches my attention because there is no additional rationale stating why you made this decision, which in itself does not sound like it was made with conviction (its a writing style nit).  I think you need to expand on this.  For example, if we were to assume that the decision point is a centralized node, how does this affect the rest of your 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.

7) For the security sections, at a minimum, you should add reference to rfc-2205 and rfc-4230.  You may also want to add reference to rfc6411.  And if the Router Alert Option is to be used, then you may want to look at the Security Section of rfc-6401 for guidance on what to say about RAO

-ken

---

From: <[email-masked]>
Date: Sun, 4 Nov 2012 18:55:00 +0000

Hi Ken,

Thank you very much!
Please see in line!

> ________________________________________
> Van: ken carlberg [[email-masked]]
> Verzonden: donderdag 1 november 2012 21:21
> To: tsvwg
> Cc: [email-masked]; Karagiannis, G. (EWI)
> Onderwerp: draft-ietf-tsvwg-rsvp-pcn-03

> Mostly for clarification.

Georgios: Thanks!

> 1) The Introduction dives right into what I would see as background information.  
> You need to add some text in the beginning 
> of Section 1 that tells the reader what you plan to do (ie, leverage RSVP in 
> support of PCN) and explain that PCN needs a signaling protocol to complete a feedback loop from egress to ingress.

Georgios: Good point we will do that!

> 2) You need to review the terminology section in more detail.  Some of the items
>  in this section are not found anywhere else in the body of the draft (eg, t_meas).  
> I would also move the terminology subsection further up in the section because 
> you start talking about some terms early on and then you define them later.

Georgios: Good point we will do that!

> 3) in some cases, you duplicate the definition of the terminology in the body of the draft, 
> and in one instance with some different text/references.  I think once you define the term, 
> you don't need to define it again.  (eg, ingress-egress-aggregate)

Georgios: Good point we will do that!

> However, you do not point the reader to the specific section within that reference.  
> Given how often this is done, I think it would be helpful to be more specific and 
> identify the section/subsection in that refernce that you are referring to.

Georgios: Okay, we will also include the relevant section of the referred RFC!

> The last sentence catches my attention because there is no additional rationale stating why you made this decision, 
> which in itself does not sound like it was made with conviction (its a writing style nit).  
> I think you need to expand on this.  For example, if we were to assume that the decision point is a centralized node, 
> how does this affect the rest of your draft?

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.

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

> 7) For the security sections, at a minimum, you should add reference to rfc-2205 and rfc-4230.  
> You may also want to add reference to rfc6411.  And if the Router Alert Option is to be used, 
> then you may want to look at the Security Section of rfc-6401 for guidance on what to say about RAO

Georgios: Thanks for the pointers! We will use them!

> -ken

Best regards,
Georgios

---

From: "Anurag Bhargava (anuragb)" <[email-masked]>
Date: Mon, 5 Nov 2012 01:52:08 +0000

Thx Georgios.
Ken - If U still have other points, may be we can have a offline mtg on
Tuesday.

Br,
-Anurag

On 11/4/12 1:55 PM, "[email-masked]" <[email-masked]>
wrote:

>> I took a look at the draft and overall, it seems fine, though I do have
>>a few comments.  
>> Mostly for clarification.
>
>Georgios: Thanks!
>
>
>> support of PCN) and explain that PCN needs a signaling protocol to
>>complete a feedback loop from egress to ingress.
>
>> The last sentence catches my attention because there is no additional
>>rationale stating why you made this decision,
>> I think you need to expand on this.  For example, if we were to assume
>>that the decision point is a centralized node,
>Georgios: We will try to explain the rationale of why we consider that
>RSVP can only be used for the situation that the
>> Again, I want to stress that this isnt a show stopper, but I would
>>appreciate it if you gave it some thought.
>
>This is also the reason of using SHOULD instead of MAY. Do you want us to
>explain this in more detail in the draft?
>

---

From: ken carlberg <[email-masked]>
Date: Mon, 5 Nov 2012 07:23:52 -0500

Georgios,

> collocated with the PCN-ingress-node.

Great, this is helpful, and this is the information that needs to be in the draft.

> 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

---

From: <[email-masked]>
Date: Mon, 5 Nov 2012 12:28:01 +0000

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 [[email-masked]]
Verzonden: maandag 5 november 2012 13:23
To: Karagiannis, G. (EWI)
Cc: [email-masked]; [email-masked]
Onderwerp: Re: draft-ietf-tsvwg-rsvp-pcn-03

Georgios,

cheers,

-ken

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 9 Nov 2012 15:33:10 +0000

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, [email-masked] wrote:
>So in this case an additional signaling protocol will be

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, [email-masked] wrote:
> > 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
> > In the situation that the the decision point is a centralized 
> node, then the required signaling protocol
> > decision point might not be located on the data path! So in this 
> case an additional signaling protocol will be
> >> And it seems a lot of this is a carry over from rfc-4860, so in 
> a sense you are inheriting an approach that
> >> Again, I want to stress that this isnt a show stopper, but I 
> would appreciate it if you gave it some thought.
> >
> > 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

---

From: <[email-masked]>
Date: Sat, 10 Nov 2012 13:10:39 +0000

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 [[email-masked]]
Verzonden: vrijdag 9 november 2012 16:33
To: Karagiannis, G. (EWI)
Cc: [email-masked]; [email-masked]; [email-masked]; EARDLEY, Phil
Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

Georgios,

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 15 Nov 2012 13:07:31 +0000

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, [email-masked] 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:[email-masked]]
>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:[email-masked]>[email-masked] " 
><<mailto:[email-masked]>[email-masked] >
>Date: Saturday, November 10, 2012 8:10 AM
>To: "<mailto:[email-masked]>[email-masked]" 
><<mailto:[email-masked]>[email-masked]>
>Cc: "<mailto:[email-masked]>[email-masked]" 
><<mailto:[email-masked]>[email-masked]>, Anurag Bhargava 
><<mailto:[email-masked]>[email-masked]>, 
>"<mailto:[email-masked]>[email-masked]" 
><<mailto:[email-masked]>[email-masked]>, 
>"<mailto:[email-masked]>[email-masked] " 
><<mailto:[email-masked]>[email-masked] >
>Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03
>
>Hi Bob,
>
>
>
>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
>the PCN-ingress could itself be the policy decision point.)"
>
>
>
>Best regards,
>
>Georgios
>
>
>
>----------
>Van: Bob Briscoe [<mailto:[email-masked]>[email-masked]]
>Cc: <mailto:[email-masked]>[email-masked]; 
><mailto:[email-masked]>[email-masked]; 
><mailto:[email-masked]>[email-masked]; EARDLEY, Phil
>At 18:55 04/11/2012, 
><mailto:[email-masked]>[email-masked] wrote:
>At 12:28 05/11/2012, 
><mailto:[email-masked]>[email-masked] wrote:
> >Hi Ken,
> >
> >Thank you very much!
> >Van: ken carlberg [<mailto:[email-masked]>[email-masked]]
> >Cc: <mailto:[email-masked]>[email-masked]; 
> <mailto:[email-masked]>[email-masked]

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 15 Nov 2012 21:02:14 +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,
>>
>...

---

From: <[email-masked]>
Date: Fri, 16 Nov 2012 13:02:24 +0000

Hi Bob,

　

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

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

　

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:

　

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

　

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.

　

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!

　

So both the PCN WG and tsvwg WG agreed that this specifictaion should use as basis the generic RSVP aggregation protocol!

　

　

　

In a subsequent email and on a later moment I will also answer to your further remarks!

　

Best regards,

Georgios

________________________________
Van: Bob Briscoe [[email-masked]]
Verzonden: donderdag 15 november 2012 14:07
To: Karagiannis, G. (EWI); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; PCN IETF list; [email-masked]
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.

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

* 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

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

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

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: "[email-masked]<mailto:[email-masked]> " <[email-masked]<mailto:[email-masked]> >
Date: Saturday, November 10, 2012 8:10 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Anurag Bhargava <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> " <[email-masked]<mailto:[email-masked]> >
Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

Hi Bob,

Best regards,

Georgios

________________________________
Van: Bob Briscoe [[email-masked]<mailto:[email-masked]>]
Verzonden: vrijdag 9 november 2012 16:33
To: Karagiannis, G. (EWI)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; EARDLEY, Phil
Onderwerp: Re: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

Georgios,

Bob

At 12:28 05/11/2012, [email-masked]<mailto:[email-masked]> wrote:
>Van: ken carlberg [[email-masked]<mailto:[email-masked]>]
>Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 16 Nov 2012 20:03:11 +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,
>>
>>message". Then the PCN-ingress (not the message) infers that all other
>>flows that share the same aggregate will share the same marking
>>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
>>
>>>has semantics "Never mind the SESSION in this message, I'm related to
>>>every flow with the same first hop"?
>...

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 16 Nov 2012 20:14:33 +0000

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, [email-masked] wrote:

>$B!!(B
>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):
>
>
>
>$B!!(B
>Submit Encoding and Transport of PCN from Domain Egress to Ingress 
>to the IESG for consideration as a Proposed Standard RFC
>
>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"
>
>$B!!(B
>$B!!(B
>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
>
>$B!!(B
>Cc: [email-masked]; [email-masked]; [email-masked]; 
>[email-masked]; PCN IETF list; [email-masked]
>I admit I tuned out of much of the later PCN signalling discussion. 
>I found the whole exercise of abstracting PCN away from specific 
>by grouping together those e2e reservations with the same next hop 
>or previous hop respectively.
>
>(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
>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==
>
>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.
>
>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==
>
>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.
>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).
>
>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:
>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.
>
>aggregate or not. This is the one case I mentioned at the start 
>{Note 1} where an aggregate is referred to on the wire.
>
>
>
>>edges is very suitable for this purpose! The generic aggregated 
>>RSVP is such a signalling protocol!
>>
>>
>>Best regards,
>>Georgios
>>
>>
>>
>>
>>From: Bob Briscoe [<mailto:[email-masked]>mailto:[email-masked]]
>>wanted to start altering that area, I don't think it would waste 
>>too much time.
>>
>>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
>>
>>
>>
>>----------

---

From: <[email-masked]>
Date: Sat, 17 Nov 2012 10:26:10 +0000

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 [[email-masked]]
Verzonden: vrijdag 16 november 2012 21:03
To: Tom Taylor
Cc: Karagiannis, G. (EWI); [email-masked]; [email-masked]; [email-masked]; PCN IETF list
Onderwerp: Re: [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03

Tom,

Bob

---

From: <[email-masked]>
Date: Sat, 17 Nov 2012 10:29:01 +0000

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.

Best regards,

Georgios

________________________________
Van: Bob Briscoe [[email-masked]]
Verzonden: vrijdag 16 november 2012 21:14
To: Karagiannis, G. (EWI)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
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

Hi Bob,

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

Best regards,

Georgios

Georgios, Anurag,

==Background==

==Disadvantages==

1) Redundant Processing

2) Reduced Resilience

3) Extra Latency

==PATH==

==RESV==

==PCN object==

Bob

Best regards,
Georgios

Anurag,

Bob

Hi Bob,

Thx
-Anurag

Hi Bob,

Best regards,

Georgios

Georgios,

Bob

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 20 Nov 2012 21:15:10 +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,
>>
>>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.
>>
>>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
>>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 20 Nov 2012 21:25:33 +0000

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, [email-masked] 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!
>
>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
>
>
>
>----------

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 20 Nov 2012 21:29:26 +0000

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, [email-masked] 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.
>
>
>
>Cc: [email-masked]; [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]; [email-masked]; 
>[email-masked]; [email-masked]; [email-masked]; 
>[email-masked]
>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).
>
>><http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf>http://www.ietf.org/proceedings/81/slides/tsvwg-0.pdf
>>
>>$B!!(B
>>
>>become (after small modifications) the 
>>draft-ietf-tsvwg-rsvp-pcn-00, which also was using RFC 4860 as the 
>>base signaling protocol.
>>
>>$B!!(B
>>
>>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 
>>{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 
>>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
>>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) 
>>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==
>>
>>various marking rates (the PCN object) to the PCN-ingress. There 
>>are two possibilities:
>>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:
>>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 
>>>This was actually the first step that was needed for this work, 
>>>and the PCN WG had no main objections on this selection!
>>>
>>>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
>>>
>>>
>>>
>>>
>>>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

---

From: "Anurag Bhargava (anuragb)" <[email-masked]>
Date: Tue, 13 Nov 2012 20:14:17 +0000

Hi Bob,

Thx
-Anurag

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Saturday, November 10, 2012 8:10 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Anurag Bhargava <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [tsvwg] draft-ietf-tsvwg-rsvp-pcn-03

Hi Bob,

Best regards,

Georgios

Georgios,

Bob

---

From: Tom Taylor <[email-masked]>
Date: Thu, 15 Nov 2012 11:42:52 -0500

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"?

...

---

From: Tom Taylor <[email-masked]>
Date: Thu, 15 Nov 2012 17:09:08 -0500

It makes me wonder if I should revive that piggy-backing edge behaviour 
draft I once started.

...

---

From: Tom Taylor <[email-masked]>
Date: Sat, 17 Nov 2012 14:41:13 -0500

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.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 22 Nov 2012 13:40:13 +0000

Hello Bob, Georgios,

>From a scan of the thread and an off-line discussion with Georgios, my perception of the situation is:

* PCN edges need to maintain logical aggregate constructs (i.e. ingress-egrees PCN state) and map e2e reservations to these aggregate constructs
* we need to convey aggregate PCN info from edge to edge
* no actual reservation state is needed inside the PCN Core

This could be achieved by:

(A):
* adapting RFC 4860 aggregation procedures to fit PCN with as little change as possible over RFC4860
* hence performing aggregate RSVP signaling (even if it is to be ignored by PCN interior nodes)
* using this aggregate RSVP signaling to convey PCN info edge to edge

OR

(B):
* adapting RFC 4860 aggregation procedures to fit PCN with more significant changes over RFC4860 (i.e. you keep the aspect of the procedures that have to do with maintaining aggregate states and to do with mapping e2e to aggregates, but you drop procedures that have too do with aggregate RSVP signaling and aggregate reservation establishment/maintenance)
* hence not performing aggregate RSVP signaling
* piggy-backing PCN info inside e2e RSVP signaling.

I think both approaches are probably viable. I tend to think the difference between the two is actually not that big at the end of the day because the key of the logic is how you maintain aggregate states at the edge and how you map 2e2 RSVP to these aggregates (i.e. the concept of aggregation within RFC4860 - independently of the notion of aggregate RSVP signaling) and I don't think the ingress-egress signaling channel (i.e. aggregate RSVP or e2e RSVP) is so significant given the PCN specifics.
I think the drawbacks you pointed out, Bob, in your initial message are probably not as serious as you suggested, given aggregate RSVP signaling would be ignored by interior nodes (for example, I don't see why aggregate RSVP signaling would impact rerouting inside the PCN core since packets from individual sessions would be routed independently of the reservation. As another example you mentioned that it might double the signaling processing load on edges while i suspect it would only increase by some fraction given the level of aggregate signaling should be much lower than collective e2e signaling). Nevertheless, If an approach along the lines of (B) removes the drawbacks completely while behaving as well, then that may be a better approach.

An attractive properly of (A) is that RFC4860 operations has been thought through and there has been some implementation of RSVP Aggregation, so we have some confidence that the solution can deal with the more challenging situations (rerouting in core, failure of an ingress edge, failure of an egress edge, rerouting towards a different edge,…).
My suggestion would be to try identify if a (B)-type approach can be devised with comparable properties in dealing with basic as well as more challenging situations, or conversely if the (A)-type approach really has some superior behavior afforded by the extra ingress-egress dedicated signaling channel. That should be a key deciding factor.
Perhaps Georgios could look into this direction?

I hope that helps

Francois

Caveat: I am operating based on slowly-but-surely fainting intimacy with PCN and RSVP aggregation technologies

On 20 Nov 2012, at 22:29, Bob Briscoe wrote:

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, [email-masked]<mailto:[email-masked]> wrote:

Hi Bob,

Best regards,

Georgios

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Georgios,

Bob

At 13:02 16/11/2012, [email-masked]<mailto:[email-masked]> wrote:

Hi Bob,

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

Best regards,

Georgios
________________________________
Van: Bob Briscoe [[email-masked]<mailto:[email-masked]>]
Verzonden: donderdag 15 november 2012 14:07
To: Karagiannis, G. (EWI); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; PCN IETF list; [email-masked]<mailto:[email-masked]>
Onderwerp: Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03

Georgios, Anurag,

==Background==

==Disadvantages==

1) Redundant Processing

2) Reduced Resilience

3) Extra Latency

==PATH==

==RESV==

==PCN object==

Bob

At 18:23 14/11/2012, [email-masked]<mailto:[email-masked]> wrote:
Hi Bob,

Best regards,
Georgios

Anurag,

Bob

Hi Bob,

Thx
-Anurag

Hi Bob,

Best regards,

Georgios

Georgios,

Bob

---

From: <[email-masked]>
Date: Thu, 22 Nov 2012 15:50:25 +0000

Hi Francois,

Thank you very much for summarizing our discussion!

Please note that an additional e2e RSVP signalling challenge associated to Option B can be identified!

What happens in the situation where there is a change of route for a given e2e RSVP reservation/session (i.e. changing its PCN-ingress-node and/or PCN-egress-node)
right when the PCN-egress-node decides to use a e2e RSVP signalling message (associated with this e2e RSVP session) to notify the aggregate PCN information
(PCN admission control and/or flow termination information) to the PCN-ingress-node?

In this situation it is possible that the aggregated PCN information will not be received by the right PCN-ingress-node, having as implication that the congestion
in the PCN domain will not be solved accurately and in time!

Best regards,
Georgios

From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
Sent: donderdag 22 november 2012 14:40
To: Bob Briscoe
Cc: Francois Le Faucheur (flefauch); Karagiannis, G. (EWI); <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; Anurag Bhargava (anuragb); <[email-masked]>; <[email-masked]>; <[email-masked]>; James Polk (jmpolk)
Subject: Re: [tsvwg] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03

Hello Bob, Georgios,

(A):

OR

(B):

An attractive properly of (A) is that RFC4860 operations has been thought through and there has been some implementation of RSVP Aggregation, so we have some confidence that the solution can deal with the more challenging situations (rerouting in core, failure of an ingress edge, failure of an egress edge, rerouting towards a different edge,...).
My suggestion would be to try identify if a (B)-type approach can be devised with comparable properties in dealing with basic as well as more challenging situations, or conversely if the (A)-type approach really has some superior behavior afforded by the extra ingress-egress dedicated signaling channel. That should be a key deciding factor.
Perhaps Georgios could look into this direction?

I hope that helps

Francois

Georgios,

Bob

Hi Bob,

Best regards,

Georgios

Georgios,

Bob

Hi Bob,

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

$B!!(B

Best regards,

Georgios

Georgios, Anurag,

==Background==

==Disadvantages==

1) Redundant Processing

2) Reduced Resilience

3) Extra Latency

==PATH==

==RESV==

==PCN object==

Bob

Hi Bob,

Best regards,
Georgios

Anurag,

Bob

Hi Bob,

Thx
-Anurag

Hi Bob,

Best regards,

Georgios

Georgios,

Bob