[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of Ingemar Johansson S
Sent: Monday, September 15, 2008 8:18 AM
To: philip.eardley at bt.com; pcn at ietf.org
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: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On
> Behalf Of philip.eardley at bt.com
> Sent: den 10 september 2008 21:32
> To: pcn at ietf.org
> 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:idsubmission at ietf.org]
> 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
> PCN at ietf.org
> https://www.ietf.org/mailman/listinfo/pcn
>
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn