[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] FW: New VersionNotificationfordraft-ietf-pcn-architecture-06
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: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
{ Ingemar Johansson S
{ Sent: 16 September 2008 08:16
{ To: Geib, Ruediger
{ Cc: pcn at ietf.org
{ 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:Ruediger.Geib at t-systems.com]
{ > Sent: den 16 september 2008 08:58
{ > To: Ingemar Johansson S
{ > Cc: pcn at ietf.org
{ > 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: 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
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn