Subject: RE: [PCN] PCN updated charter

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Wed, 29 Nov 2006 16:19:22 -0500

Hi Lars,

Please see below (marked Anna):

Anna 

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]]
Sent: Tuesday, November 28, 2006 9:17 PM
To: [email-masked]
Subject: Re: [PCN] PCN updated charter

Hi,

I think feedback on PCN in San Diego was overall mostly positive, and a
large reason was that the BOF was really well prepared and chaired.  
Nice job!

However, some discussions in and after San Diego brought up valid points
that a revised charter should reflect. Let me briefly outline them
below, so we can start discussing them here:

(1) Both the SIP- and PWE3-related deployment models have been
questioned by the respective communities, and will require non- trivial
coordination to align with the existing work in those areas.  
I'd therefore like to propose to exclude them from the initial scope of
PCN at this time, and limit PCN to the "IntServ over DiffServ"  
case at this time.

Anna begin>

PWE3-related deployment model has already been taken out of the updated
charter, based on the BOF input.  

As to SIP-related one  -  there is one aspect of it that actually
potentially affects the marking at the ingress node, namely the
aggregation assumptions, and especially aggregation level on a
per-ingress-egress aggregate.  This specific model is likely to assume
both lower levels of aggregation on the PCN internal links, but
especially on a per-ingress-egress pair basis. From the work available
by now it seems relatively clear that if the core marking is to
accommodate this,  the decision on *when* to mark packes may be
affected, and that additional flexibility in the marking at the internal
node may be potentially needed.   So in the very least this needs to be
"kept in mind" even if the SIP (or application-related) deployment is
taken out of the charter.  

Perhaps stressing in the charter that the WG will consider the
implications of the lower levels of ingress-egress aggregation on the
marking mechanisms may address this issue?

<Anna end>

(2) The different options of encoding markings in packets require
further investigation. This is an important component, because the
deployability of PCN hinges on well-defined marking mechanisms. I'd
therefore like to propose that PCN in the first phase should focus its
energies on working on the problem statement, deployment model and
marking mechanisms only. 

<begin Anna>

With respect to your discussion with Ken on the problem statement draft,
I do not see any problem with combining it with the architecture
document.  A large portion of the work has been already done in this in
the various individual drafts, so this particular deliverable does not
appear to be terribly limiting to me either way.

<end Anna>

Work on the actual admission and preemption mechanisms should kick off
only after these initial work items are stable.

<Anna begin>

I interpret he above to mean that you propose to work on the encoding
and the actual marking decisions at the internal PCN router (as well as
one deployment model and prob statement), but that the edge behavior
should come later (after re-chartering).  Is that a correct
interpretation?

I worry about taking the consideration of edge behaviors out of the
charter.
The primary cause of this worry is that  edge behaviors depend on the
meaning of  the marking. For example, if the marking is "red-like" (e.g.
virtual-queue based) its meaning is quite different than if the marking
is excess-rate based (e.g. token-bucket based", and the appropriate edge
behavior, to do "the right thing",  needs to reflect the meaning of the
marking.  I just cannot see how you can completely divorce one from the
other meaningfully.  

Also, in any further evaluation of performance issues needs to be done,
such work must necessarily assume some edge behavior.  My understanding
from the BOF was that further evaluation work was desirable (e.g. for
larger scale networks). Such evaluation would not be possible unless at
least some constraints on the edge behavior are specified.   

Another point is that if the first phase of the work does only the
marking behavior, and does not get re-chartered, than the product of the
WG might not result in a standard that allows interoperability (as
different edge devices may do things incompatible with the meaning of
the marking and/or with each other).

So I would argue against taking the consideration of edge behaviors out
of the charter, even in the first phase.

<Anna end>

Comments?

Thanks,
Lars

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 29 Nov 2006 13:44:10 -0800

> marking mechanisms may address this issue?

Maybe. I think I need to digest this issue a bit more.

> appear to be terribly limiting to me either way.

Right. The existing documents may have much of the required material  
already. Whether there will be one vs. a number of documents that  
convey this content is mostly a matter of presentation.

> should come later (after re-chartering).  Is that a correct

Right.

> marking.  I just cannot see how you can completely divorce one from  

I agree that the meaning of the markings is important for the edge  
algorithm and that the two are difficult to separate.

But that wasn't my point. Without even going into the semantics of  
various markings, a number of issues have been brought up with  
regards to _encoding_ this information using the ECN bits, DSCPs, IP  
options, etc. This should be worked out first, because the encoding  
choices may limit what marking semantics can be defined later, which  
in turn affects what edge behaviors are possible.

> the marking and/or with each other).

If this first phase of work completes successfully, I fully expect a  
rechartering to occur, and the initial charter should probably  
contain an explicit rechartering milestone together with a brief  
paragraph about what the goal of the rechartering should be.

If for some reason the WG runs aground in the first phase or decides  
not to recharter, yes, the set of RFCs it has produced won't be  
terribly useful. Frankly, that isn't the worst possible outcome in  
such a case. (But I don't think there is a real danger of this here.)

Lars

---

From: [email-masked] (Scott O Bradner)
Date: Wed, 29 Nov 2006 16:46:35 -0500 (EST)

> the initial charter should probably 

makes sense to me

Scott

---

From: <[email-masked]>
Date: Thu, 30 Nov 2006 09:34:00 -0000

Hi

In-line below
phil

-----Original Message-----
From: Anna Charny (acharny) [mailto:[email-masked]] 
Sent: 29 November 2006 21:19
To: Lars Eggert; [email-masked]
Subject: RE: [PCN] PCN updated charter

Hi Lars,

Anna 

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]]
Sent: Tuesday, November 28, 2006 9:17 PM
To: [email-masked]
Subject: Re: [PCN] PCN updated charter

Hi,

Anna begin>

<Anna end>

[phil start] 
either like this or as a separate deployment model would work for me. I
think the most important thing is the impact on the aggregation
assumption, as anna mentions
[phil end]

<begin Anna>

<end Anna>

[phil start] problem statement/arch doc is fine with me. The main reason
for writing the problem statement I-D was to help get the draft charter
& BoF better. The most useful content/format is probably best judged by
someone who's been less involved than me. 
[phil end]

<Anna begin>

<Anna end>

Comments?

Thanks,
Lars

---

From: <[email-masked]>
Date: Thu, 30 Nov 2006 09:46:58 -0000

>>This [= the encoding choice] should be worked out first, because the
encoding choices may limit what marking semantics can be defined later,
which in turn affects what edge behaviors are possible.

I'm not sure the encoding choices do limit the marking semantics that
much. I think the main impact of the encoding choice is on non-PCN
things like compatibility with RFC3168 & DSCP usage. 

phil

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: 29 November 2006 21:44
To: [email-masked]
Subject: Re: [PCN] PCN updated charter

Right.

Lars

---

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 30 Nov 2006 12:12:10 -0500

Lars wrote:
"But that wasn't my point. Without even going into the semantics of
various markings, a number of issues have been brought up with regards
to _encoding_ this information using the ECN bits, DSCPs, IP options,
etc. This should be worked out first, because the encoding choices may
limit what marking semantics can be defined later, which in turn affects
what edge behaviors are possible."
[Joe]I think that it would be appropriate for the WG to reach agreement
on what bits could be used for PCN before finalizing on the marking
behavior in the routers or edge/host behavior. However, there are some
dependences between, marking behavior in routers, reaction by edge nodes
and the encoding.

Regards, Joe
QoS & Network Architecture
Telephone: 613-763-6098 (ESN 393-6098)
Email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 4:47 AM
To: [email-masked]; [email-masked]
Subject: RE: [PCN] PCN updated charter

phil

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: 29 November 2006 21:44
To: [email-masked]
Subject: Re: [PCN] PCN updated charter

Right.

Lars

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 30 Nov 2006 12:17:26 -0500

Anna, Lars, all:
Please see my comments indicated by <Kwok_Start> and <Kwok_End> below.
Thanks!
-- Kwok --

>taken out of the charter.

<Kwok_Start>
Anna, I disagree with you on your points of:
"This specific model is likely to assume both lower levels of aggregation
on the PCN internal links, but especially on a per-ingress-egress pair basis."
There are no strict requirements that Application (SIP) based usage of PCN
must use lower levels of aggregation on the PCN internal links.
Nor requirements that Application (SIP) based usage must use lower levels
of aggregation on a per-ingress-egress pair basis.
I believe we should try to push the envelop of applicability as much as we can.

We've indicated in our earlier work (for example, showing you our 
simulation work
so we can cover different aspects of the problem space) the usage of lower
levels of aggregation (at different parts of the PCN region) because there are
deployment scenarios (with interested users) that will benefit from such work.

Further more, as you know, there are encouraging simulation results on
lower levels of aggregation on a per-ingress-egress pair basis.
The degree of "how low" will be details that can be indicated in the work
of the PCN (to-be)WG.
And there should be Applicability indications in the Deployment Model 
documents.
Which should cover these points in more detail.

On you point of "
"From the work available by now it seems relatively clear that if the 
core marking is to
accommodate this,  the decision on *when* to mark packets may be
affected, and that additional flexibility in the marking at the internal
node may be potentially needed.   So in the very least this needs to be
"kept in mind" even if the SIP (or application-related) deployment is
taken out of the charter."

IMHO, it should NOT be the goal of the WG to change the Standards Track work
(the internal mode when to mark packets, marking syntax, the marking semantics)
between the different (re-chartering) phases of the (to-be) WG.
Hence the WG should keep the Application (SIP) Deployment Model document
as part of its Charter to EXPLICITLY indicate this space instead of 
just IMPLICITLY
"kept in mind" this work.
<Kwok_End>