Subject: [PCN] FW: New Version Notification for draft-ietf-pcn-architecture-06

From: <[email-masked]>
Date: Wed, 10 Sep 2008 20:31:33 +0100

I've (hopefully) put in all the WG Last Call comments - thanks very much
to everyone who commented!
http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-06.txt

Best wishes
phil

ps The only issue I know about is that at some point the references to
I-Ds have to be referred to as "work in progress" rather than by the ID
name. hopefully this isn't too urgent and can wait until after the next
stage of the ietf review process.

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 10 September 2008 20:25
To: Eardley,PL,Philip,CXR9 R
Subject: New Version Notification for draft-ietf-pcn-architecture-06 

A new version of I-D, draft-ietf-pcn-architecture-06.txt has been
successfuly submitted by Philip Eardley and posted to the IETF
repository.

Filename:	 draft-ietf-pcn-architecture
Revision:	 06
Title:		 Pre-Congestion Notification (PCN) Architecture
Creation_date:	 2008-09-10
WG ID:		 pcn
Number_of_pages: 56

Abstract:
This document describes a general architecture for flow admission and
termination based on pre-congestion information in order to protect
the quality of service of established inelastic flows within a single
DiffServ domain.Status

The IETF Secretariat.

_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Mon, 15 Sep 2008 08:17:51 +0200

Hi

I have read through the draft and have one commment regarding RSVP aggregation which I believe is not commented in the draft (could be that I read badly though). 

I don't know if RSVP aggregation is a applicable for PCN and also I don't know how widely used it is (or will be).

As I can see it from RFC3175. It should in theory be possible to use RSVP aggregation with PCN. In this case a PCN ingress domain will admit an aggregate of flows (which may increase and degrease over time as individual micro-flows are setup and torn down).

Admission control in PCN should be relative straight-forward (atleast as seen from the power-point engineers viewpoint :-) as one could increase the "size" of the aggregates little by little. 
Termination may be more tricky though.. RFC4495 describes bandwidth reduction for RSVP aggregates, something that may work, but my question is if is fast enough ?. 
In order for it to work the reduction "requests" must be signaled back to the RSVP aggregation points which then can determine which microflows to terminate. Also it is possible that there is more than one level of aggregation.
Given the possible cases where termination may be necessary (link-failures et.c) the only, fast enough solution may be to tear down the entire aggregate, something that may well be too brute-force.

Is this a potential problem or yet another exotic corner case ?

/Ingemar
******************************************* 
Ingemar Johansson 
Senior Research Engineer, IETF "nethead" 
EAB/TVP - Multimedia Technologies 
Ericsson Research Ericsson AB 
Box 920 S-971 28 Luleå, Sweden 
Tel: +46 (0)8 4043042 
ECN: 850-43042 
ECC: 850-43074 
Mobile: +46 (0)730 783289 
******************************************* 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: den 10 september 2008 21:32
> To: [email-masked]
> Subject: [PCN] FW: New Version Notification 
> fordraft-ietf-pcn-architecture-06
> 
> I've (hopefully) put in all the WG Last Call comments - 
> thanks very much to everyone who commented!
> ps The only issue I know about is that at some point the 
> references to I-Ds have to be referred to as "work in 
> progress" rather than by the ID name. hopefully this isn't 
> too urgent and can wait until after the next stage of the 
> ietf review process.
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 16 Sep 2008 08:58:03 +0200

Ingemar,

you bring up a fair question.

I think that issues like how an aggregated RSVP reservation reacts on pre-congestion is out of scope for PCN.

However a remark that PCN also works (or doesn't work??) with aggregated RSVP should be added. A fast take of me would be, that if there's just one level of aggregation and the aggregating/deaggregating nodes are the PCN ingress/egress nodes, then an interworking may be straightforward. But if there are more levels of aggregation or if PCN ingress/egress and RSVP aggregation/deaggregation are not the same nodes, it may become more troublesome. Especially, as the aggregated RSVP signaling doesn't have to follow the same path as the per flow RSVP signaling in the case of ECMP (that's an issue if the RSVP deagreggation node is outside of the PCN domain).

I'd suggest to recommend operation of the simple case mentioned above in the current architecture.

I'm not objecting on a bit more of discussion of the topic in the architecture, but that will delay the architecture document. I'm also open for a separate document describing aggregated RSVP(/NSIS?) and possibly the topic interworking of PCN with signaling as a whole. That would allow to finalise the architecture now.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
Sent: Monday, September 15, 2008 8:18 AM
To: [email-masked]; [email-masked]
Subject: Re: [PCN] FW: New Version Notificationfordraft-ietf-pcn-architecture-06

Hi

/Ingemar

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 16 Sep 2008 09:15:47 +0200

Hi

I don't have a wish to delay the PCN architecture work more than necessary either. 

I guess the way forward as described by Ruediger is reasonable i.e a description of the simple case and just a mention of the more complex cases in the architecture draft. On the other hand it may be sufficient to just mention aggregated reservation in general and rely on a future other document that covers this.

/Ingemar

> From: Geib, Ruediger [mailto:[email-masked]] 
> Sent: den 16 september 2008 08:58
> To: Ingemar Johansson S
> Cc: [email-masked]
> Subject: RE: [PCN] FW: New Version 
> Notificationfordraft-ietf-pcn-architecture-06
> 
> Ingemar,
> 
> I think that issues like how an aggregated RSVP reservation 
> reacts on pre-congestion is out of scope for PCN.
> 
> However a remark that PCN also works (or doesn't work??) with 
> aggregated RSVP should be added. A fast take of me would be, 
> that if there's just one level of aggregation and the 
> aggregating/deaggregating nodes are the PCN ingress/egress 
> nodes, then an interworking may be straightforward. But if 
> there are more levels of aggregation or if PCN ingress/egress 
> and RSVP aggregation/deaggregation are not the same nodes, it 
> may become more troublesome. Especially, as the aggregated 
> RSVP signaling doesn't have to follow the same path as the 
> per flow RSVP signaling in the case of ECMP (that's an issue 
> if the RSVP deagreggation node is outside of the PCN domain).
> 
> I'd suggest to recommend operation of the simple case 
> mentioned above in the current architecture.
> 
> I'm not objecting on a bit more of discussion of the topic in 
> the architecture, but that will delay the architecture 
> document. I'm also open for a separate document describing 
> aggregated RSVP(/NSIS?) and possibly the topic interworking 
> of PCN with signaling as a whole. That would allow to 
> finalise the architecture now.
> 
> Regards,
> 
> Ruediger
> 
> 
> Behalf Of Ingemar Johansson S
> Subject: Re: [PCN] FW: New Version 
> Notificationfordraft-ietf-pcn-architecture-06
> 
> Hi
> 
> I have read through the draft and have one commment regarding 
> RSVP aggregation which I believe is not commented in the 
> draft (could be that I read badly though). 
> 
> I don't know if RSVP aggregation is a applicable for PCN and 
> also I don't know how widely used it is (or will be).
> 
> As I can see it from RFC3175. It should in theory be possible 
> to use RSVP aggregation with PCN. In this case a PCN ingress 
> domain will admit an aggregate of flows (which may increase 
> and degrease over time as individual micro-flows are setup 
> and torn down).
> 
> Admission control in PCN should be relative straight-forward 
> (atleast as seen from the power-point engineers viewpoint :-) 
> as one could increase the "size" of the aggregates little by little. 
> Termination may be more tricky though.. RFC4495 describes 
> bandwidth reduction for RSVP aggregates, something that may 
> work, but my question is if is fast enough ?. 
> In order for it to work the reduction "requests" must be 
> signaled back to the RSVP aggregation points which then can 
> determine which microflows to terminate. Also it is possible 
> that there is more than one level of aggregation.
> Given the possible cases where termination may be necessary 
> (link-failures et.c) the only, fast enough solution may be to 
> tear down the entire aggregate, something that may well be 
> too brute-force.
> 
> > I've (hopefully) put in all the WG Last Call comments - thanks very 
> > much to everyone who commented!
> > 
> references to 
> > I-Ds have to be referred to as "work in progress" rather 
> than by the 
> > ID name. hopefully this isn't too urgent and can wait until 
> after the 
> > next stage of the ietf review process.
> >

---

From: <[email-masked]>
Date: Mon, 22 Sep 2008 09:12:27 +0100

Hi Ingemar & Ruediger,

I think this sort of consideration would be better in one of the edge behaviour drafts; I think it's too specific for the architecture draft. These are supposed to be Informational docs about how to use the marking /encoding behaviours in particular scenarios. I reckon it would be good to have one of these docs around an RSVP scenario. (a starting point might be parts of the old Briscoe-cl-architecture & lefaucheur rsvp-ecn drafts - rsvp aggregation would need adding, from what I remember.)

Incidentally, re aggregation etc. pcn architecture terminology:
   o  PCN-flow: the unit of PCN-traffic that the PCN-boundary-node
      admits (or terminates); the unit could be a single microflow (as
      defined in [RFC2474]) or some identifiable collection of
      microflows.
So I guess an rsvp aggregate might be an 'identifiable collection of microflows'. 

Best wishes
phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Ingemar Johansson S
{ Sent: 16 September 2008 08:16
{ To: Geib, Ruediger
{ Cc: [email-masked]
{ Subject: Re: [PCN] FW: New VersionNotificationfordraft-ietf-pcn-
{ architecture-06
{ 
{ Hi
{ 
{ I don't have a wish to delay the PCN architecture work more than necessary
{ either.
{ 
{ I guess the way forward as described by Ruediger is reasonable i.e a
{ description of the simple case and just a mention of the more complex
{ cases in the architecture draft. On the other hand it may be sufficient to
{ just mention aggregated reservation in general and rely on a future other
{ document that covers this.
{ 
{ /Ingemar
{ 
{ > -----Original Message-----
{ > From: Geib, Ruediger [mailto:[email-masked]]
{ > Sent: den 16 september 2008 08:58
{ > To: Ingemar Johansson S
{ > Cc: [email-masked]
{ > Subject: RE: [PCN] FW: New Version
{ > Notificationfordraft-ietf-pcn-architecture-06
{ >
{ > Ingemar,
{ >
{ > you bring up a fair question.
{ >
{ > I think that issues like how an aggregated RSVP reservation
{ > reacts on pre-congestion is out of scope for PCN.
{ >
{ > However a remark that PCN also works (or doesn't work??) with
{ > aggregated RSVP should be added. A fast take of me would be,
{ > that if there's just one level of aggregation and the
{ > aggregating/deaggregating nodes are the PCN ingress/egress
{ > nodes, then an interworking may be straightforward. But if
{ > there are more levels of aggregation or if PCN ingress/egress
{ > and RSVP aggregation/deaggregation are not the same nodes, it
{ > may become more troublesome. Especially, as the aggregated
{ > RSVP signaling doesn't have to follow the same path as the
{ > per flow RSVP signaling in the case of ECMP (that's an issue
{ > if the RSVP deagreggation node is outside of the PCN domain).
{ >
{ > I'd suggest to recommend operation of the simple case
{ > mentioned above in the current architecture.
{ >
{ > I'm not objecting on a bit more of discussion of the topic in
{ > the architecture, but that will delay the architecture
{ > document. I'm also open for a separate document describing
{ > aggregated RSVP(/NSIS?) and possibly the topic interworking
{ > of PCN with signaling as a whole. That would allow to
{ > finalise the architecture now.
{ >
{ > Regards,
{ >
{ > Ruediger
{ >
{ >
{ > -----Original Message-----
{ > From: [email-masked] [mailto:[email-masked]] On
{ > Behalf Of Ingemar Johansson S
{ > Sent: Monday, September 15, 2008 8:18 AM
{ > To: [email-masked]; [email-masked]
{ > Subject: Re: [PCN] FW: New Version
{ > Notificationfordraft-ietf-pcn-architecture-06
{ >
{ > Hi
{ >
{ > I have read through the draft and have one commment regarding
{ > RSVP aggregation which I believe is not commented in the
{ > draft (could be that I read badly though).
{ >
{ > I don't know if RSVP aggregation is a applicable for PCN and
{ > also I don't know how widely used it is (or will be).
{ >
{ > As I can see it from RFC3175. It should in theory be possible
{ > to use RSVP aggregation with PCN. In this case a PCN ingress
{ > domain will admit an aggregate of flows (which may increase
{ > and degrease over time as individual micro-flows are setup
{ > and torn down).
{ >
{ > Admission control in PCN should be relative straight-forward
{ > (atleast as seen from the power-point engineers viewpoint :-)
{ > as one could increase the "size" of the aggregates little by little.
{ > Termination may be more tricky though.. RFC4495 describes
{ > bandwidth reduction for RSVP aggregates, something that may
{ > work, but my question is if is fast enough ?.
{ > In order for it to work the reduction "requests" must be
{ > signaled back to the RSVP aggregation points which then can
{ > determine which microflows to terminate. Also it is possible
{ > that there is more than one level of aggregation.
{ > Given the possible cases where termination may be necessary
{ > (link-failures et.c) the only, fast enough solution may be to
{ > tear down the entire aggregate, something that may well be
{ > too brute-force.
{ >
{ > Is this a potential problem or yet another exotic corner case ?
{ >
{ > /Ingemar
{ > *******************************************
{ > Ingemar Johansson
{ > Senior Research Engineer, IETF "nethead"
{ > EAB/TVP - Multimedia Technologies
{ > Ericsson Research Ericsson AB
{ > Box 920 S-971 28 Luleå, Sweden
{ > Tel: +46 (0)8 4043042
{ > ECN: 850-43042
{ > ECC: 850-43074
{ > Mobile: +46 (0)730 783289
{ > *******************************************
{ >
{ >
{ > > -----Original Message-----
{ > > From: [email-masked] [mailto:[email-masked]] On
{ > Behalf Of
{ > > [email-masked]
{ > > Sent: den 10 september 2008 21:32
{ > > To: [email-masked]
{ > > Subject: [PCN] FW: New Version Notification
{ > > fordraft-ietf-pcn-architecture-06
{ > >
{ > > I've (hopefully) put in all the WG Last Call comments - thanks very
{ > > much to everyone who commented!
{ > >
{ > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-06.txt
{ > >
{ > > Best wishes
{ > > phil
{ > >
{ > > ps The only issue I know about is that at some point the
{ > references to
{ > > I-Ds have to be referred to as "work in progress" rather
{ > than by the
{ > > ID name. hopefully this isn't too urgent and can wait until
{ > after the
{ > > next stage of the ietf review process.
{ > >
{ > > -----Original Message-----
{ > > From: IETF I-D Submission Tool [mailto:[email-masked]]
{ > > Sent: 10 September 2008 20:25
{ > > To: Eardley,PL,Philip,CXR9 R
{ > > Subject: New Version Notification for draft-ietf-pcn-architecture-06
{ > >
{ > >
{ > > A new version of I-D, draft-ietf-pcn-architecture-06.txt has been
{ > > successfuly submitted by Philip Eardley and posted to the IETF
{ > > repository.
{ > >
{ > > Filename:	 draft-ietf-pcn-architecture
{ > > Revision:	 06
{ > > Title:		 Pre-Congestion Notification (PCN) Architecture
{ > > Creation_date:	 2008-09-10
{ > > WG ID:		 pcn
{ > > Number_of_pages: 56
{ > >
{ > > Abstract:
{ > > This document describes a general architecture for flow
{ > admission and
{ > > termination based on pre-congestion information in order to protect
{ > > the quality of service of established inelastic flows
{ > within a single
{ > > DiffServ domain.Status
{ > >
{ > >
{ > >
{ > >
{ > > The IETF Secretariat.
{ > >
{ > >
{ > > _______________________________________________
{ > > PCN mailing list
{ > > [email-masked]
{ > > https://www.ietf.org/mailman/listinfo/pcn
{ > >
{ > _______________________________________________
{ > PCN mailing list
{ > [email-masked]
{ > https://www.ietf.org/mailman/listinfo/pcn
{ >
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn