Subject: RE: [PCN] PCN updated charter

From: <[email-masked]>
Date: Fri, 1 Dec 2006 09:59:35 -0000

Hi,
I agree with joe that there is some dependency between marking behaviour
in routers, reaction by edge nodes and the encoding. To me this suggests
it's appropriate to work on them at the same time.

So I'd prefer it if the 'phase 1' of the charter could include work on
all three.

I also think the choice of encoding depends on the router & edge
behaviours more strongly than the other way round (ie more strongly than
the router & edge behaviours depend on the encoding). So an alternative
way to segment the work could be to do the router & edge behaviours
first & the encoding second?

Best wishes,
Phil

> -----Original Message-----
> From: Jozef Babiarz [mailto:[email-masked]]
> Sent: 30 November 2006 17:12
> To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
> Subject: RE: [PCN] PCN updated charter
> 
> 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
> 
> >>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
> 
> On Nov 29, 2006, at 13:19, Anna Charny (acharny) wrote:
> > 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?
> 
> Maybe. I think I need to digest this issue a bit more.
> 
> > 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.
> 
> 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.
> 
> > 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?
> 
> Right.
> 
> > 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.
> 
> 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.
> 
> > 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).
> 
> 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.)
> 
> > So I would argue against taking the consideration of edge behaviors
> > out
> > of the charter, even in the first phase.
> 
> Lars
> 
> 
> _______________________________________________
> 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: "Anna Charny \(acharny\)" <[email-masked]>
Date: Fri, 1 Dec 2006 15:59:22 -0500

Agreed 

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]] 
Sent: Friday, December 01, 2006 3:49 PM
To: Anna Charny (acharny); [email-masked];
[email-masked]; [email-masked]
Subject: RE: [PCN] PCN updated charter

Hi Anna, 

Agree. However we may need to study carefully
"draft-ietf-tsvwg-ecn-alternates-00" now RFC 4774 as well RFC 3168 when
defining router marking behavior. 

Joe.

-----Original Message-----
From: Anna Charny (acharny) [mailto:[email-masked]]
Sent: Friday, December 01, 2006 3:37 PM
To: Babiarz, Jozef (CAR:0S03); [email-masked];
[email-masked]; [email-masked]
Subject: RE: [PCN] PCN updated charter

Hi Joe,

My view on this is that as long as there are enough states, we do not
need to agree on the exact encoding for these states immediately.  It
seems to me that there are several possibilities identified in existing
drafts already discussed in tsvwg that do provide enough states.  I
think choosing between those does not have to be done immediately?

Anna 

-----Original Message-----
From: Jozef Babiarz [mailto:[email-masked]]
Sent: Friday, December 01, 2006 3:31 PM
To: Anna Charny (acharny); [email-masked];
[email-masked]; [email-masked]
Subject: RE: [PCN] PCN updated charter

Hi Anna, Phil,

If we split the work between router marking behavior/edge mechanisms and
encoding, do we not need to validate that the agreed router marking
behavior can be performed with the available encoding method(s) and
bits? My view is that there are lot of restrictions (i.e., RFC3168 and
draft-ietf-tsvwg-ecn-alternates-00) on what bits in the IP header can be
used and how they should be used. These dependencies need to be factored
in when the group selects the router marking behavior. 

Joe.

-----Original Message-----
From: Anna Charny (acharny) [mailto:[email-masked]]
Sent: Friday, December 01, 2006 9:45 AM
To: [email-masked]; Babiarz, Jozef (CAR:0S03);
[email-masked]; [email-masked]
Subject: RE: [PCN] PCN updated charter

Hi Phil,

Yes, I agree. If we have to split the work on the encoding and the
marking/edge mechanisms in two phases, I too would prefer to work on the
mechanisms first, and the encoding second.   

Anna

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, December 01, 2006 5:00 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PCN] PCN updated charter

Hi,

Best wishes,
Phil

affects
agreement

nodes
later,
the
> > 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
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

the
> > meaning of  the marking. For example, if the marking is "red- like" 
> > (e.g.
> > 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.
> 

> affects what edge behaviors are possible.
> 
> > 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
> 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.
> 
> > out of the charter, even in the first phase.
> 
> Lars
> 
>

---

From: Lars Eggert <[email-masked]>
Date: Fri, 1 Dec 2006 15:25:23 -0800

> things like compatibility with RFC3168 & DSCP usage.

That's a second reason why this should IMO be worked on first.

Lars

---

From: "Anna Charny \(acharny\)" <[email-masked]>
Date: Fri, 1 Dec 2006 21:40:07 -0500

>> implications of the lower levels of ingress-egress aggregation on the

>> <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]

>Could you provide a paragraph to add to the charter that would outline 
>this a bit?
>
>Lars

How about:

The WG will work on defining the applicability limits of the proposed
mechanisms with respect to the aggregation assumptions on the bottleneck
links as well as on a per PCN ingress-egress pair basis.  

(Note that this was one of the stated requests at the BOF anyway). 

Anna

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 01 Dec 2006 20:56:01 -0600

>links as well as on a per PCN ingress-egress pair basis.

The WG will define applicability limits for all proposed mechnisms for each 
aggregation assumption.  The current aggregations to be covered are 
bottleneck links, as well as on a per PCN ingress-egress pair basis.

(my 2.2 cents)