Subject: RE: [PCN] a question on PCN scope

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Sun, 5 Nov 2006 14:02:16 -0500

Hi Robert,

The question in the problem statement you refer to 

"3. How should these markings (at packet granularity) be converted into 
   admission control and flow pre-emption decisions (at flow
granularity)?"

means, in my opinion, the following:

1) how should the measurement at the egress be done to get a CLE or a
sustainable pre-emption rate (one example of each in cl-phb draft) - but
more importantly - what exactly about these measurements that needs to
be standardized?

2) once the CLE and/or sustainable aggregate rate are computed and
communicated to the ingress - what exactly does the ingress do with this
info - and most importantly how much of this needs to be standardized?

The current drafts (cl-architecture and cl-phb) give possible answers to
how/what can be done wrt to the mechanisms at the ingress/egress.  What
the WG (if created) needs to decide, IMHO, is to what extent these
behaviors need to be standardized, and how much flexibility can be left
to the implementation.

Does this answer your question?

Anna 

-----Original Message-----
From: Robert Hancock [mailto:[email-masked]] 
Sent: Sunday, November 05, 2006 12:03 PM
To: [email-masked]
Subject: [PCN] a question on PCN scope

Hi,

I've just been reading the problem statement, and there is still one
question about PCN (as a WG) which I am unclear about. I know this has
been discussed on the list but the text which is actually available is
still hard for me to interpret. 

Problem 3 on the charter is

"3. How should these markings (at packet granularity) be converted into 
   admission control and flow pre-emption decisions (at flow
granularity)?"

What does 'converted into ... decisions' actually mean? This could
potentially cover a huge range of things to do with network dimensioning
and planning, risk/benefit tradeoffs of admitting when close to
capacity, pre-emption flow selection policies, and so on. To a large
extent, these seem to be orthogonal to the other parts of the PCN story.
Indeed, one can imagine many ways to find out what is going on in the
interior of a network at the aggregate level (tunnel or diffserv
aggregation for example), which are clearly different to points 1 and 2
on the charter, but which would possibly invoke exactly the same
functionality under point 3. It would seem a bad thing if every
aggregation mechanism defined its own algorithms for CAC/pre-mption of
flows within the aggregate.

Does point 3 mean more than "How do we turn individual markings into a
CLE which the egress can then do what it likes with?" If so, what?

cheers,

Robert H.

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

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

---

From: "Robert Hancock" <[email-masked]>
Date: Sun, 5 Nov 2006 16:39:00 -0800

hi anna,

> 1) how should the measurement at the egress be done to get a 
> CLE or a sustainable pre-emption rate (one example of each in 
> cl-phb draft) - but more importantly - what exactly about 
> these measurements that needs to be standardized?

i think it's clear that this needs to be done as an integrated
activity with the other parts of PCN work (i.e. problems 1 and
2 from the outline charter), or at least that it's reasonable to
do so.

> 
> 2) once the CLE and/or sustainable aggregate rate are 
> computed and communicated to the ingress - what exactly does 
> the ingress do with this info - and most importantly how much 
> of this needs to be standardized?

this is the bit that I am unclear about. i suppose there could be
two ways of approaching the question:

a) finding out and documenting that the PCN approach to managing
the domain interior places certain constraints on the policy and
mechanisms that control ingress and egress operation. this seems 
to me to be important to understand as part of the overall PCN work.

b) beyond this, mandating particular signalling mechanisms or
cac/pre-emption policies and mechanisms. I can see that this
is interesting and maybe even needs to be standardised, but if
it doesn't have to be hard-wired to the rest of the PCN technology
I'm not sure whether it is a good idea to do this at the same
time and in the same place as the rest of the PCN work.

> 
> The current drafts (cl-architecture and cl-phb) give possible 
> answers to how/what can be done wrt to the mechanisms at the 
> ingress/egress.  What the WG (if created) needs to decide, 
> IMHO, is to what extent these behaviors need to be 
> standardized, and how much flexibility can be left to the 
> implementation.
> 

It certainly clarifies it.

cheers,

robert h.

> I've just been reading the problem statement, and there is 
> still one question about PCN (as a WG) which I am unclear 
> about. I know this has been discussed on the list but the 
> text which is actually available is still hard for me to interpret. 
> 
> What does 'converted into ... decisions' actually mean? This 
> could potentially cover a huge range of things to do with 
> network dimensioning and planning, risk/benefit tradeoffs of 
> admitting when close to capacity, pre-emption flow selection 
> policies, and so on. To a large extent, these seem to be 
> orthogonal to the other parts of the PCN story. Indeed, one 
> can imagine many ways to find out what is going on in the 
> interior of a network at the aggregate level (tunnel or 
> diffserv aggregation for example), which are clearly 
> different to points 1 and 2 on the charter, but which would 
> possibly invoke exactly the same functionality under point 3. 
> It would seem a bad thing if every aggregation mechanism 
> defined its own algorithms for CAC/pre-mption of flows within 
> the aggregate.
> 
> Does point 3 mean more than "How do we turn individual 
> markings into a CLE which the egress can then do what it 
> likes with?" If so, what?
> 
> cheers,
> 
> Robert H.
> 
>