Subject: [PCN] Concensus questions: Q1, Q2, and Q3.

From: Steven Blake <[email-masked]>
Date: Tue, 18 Mar 2008 13:08:22 -0400

Six consensus questions were taken during the IETF 71 meeting.  I would
now like to raise them on the list.  I will do this in step-wise
fashion.

Q1: As an initial standardization activity, should the PCN wg produce a
    standards-track PCN scheme that requires only two encoding states?
    (Note: this question does not presume that the solution is Single
    Marking).

Q2: Presuming consensus in favor of Q1, should the PCN wg produce one or
    more experimental-track extensions to the standards-track PCN scheme
    that require another encoding state (for a total of three encoding
    states)?

Q3: Does the PCN working group have enough information to make a 
    decision about the way forward for the standards-track PCN scheme?

By my notes, Q1 was accepted in the meeting 8-0, Q2 was accepted 9-0,
and Q3 was accepted 6-1 (but my notes are fuzzy on Q3's result).

Please send comments to the list during the next few days.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <[email-masked]>
Ericsson/Redback Networks               +1 919-472-9913

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Mar 2008 13:29:56 +0100

Steven, 

| Q1: As an initial standardization activity, should the PCN wg 
| produce a standards-track PCN scheme that requires only two 
| encoding states?
| (Note: this question does not presume that the solution is 
| Single Marking).

Yes.

| Q2: Presuming consensus in favor of Q1, should the PCN wg 
| produce one or more experimental-track extensions to the 
| standards-track PCN scheme that require another encoding 
| state (for a total of three encoding states)?

Yes. Experimental Track seems to me to be most 
important here.

| 
| Q3: Does the PCN working group have enough information to make a 
| decision about the way forward for the standards-track PCN scheme?

Yes.

No further comments on these questions from me.

Regards,

Rudiger

---

From: <[email-masked]>
Date: Thu, 20 Mar 2008 15:29:25 -0000

Steven, yes to all 3. I add some notes to clarify my viewpoint.

Q1 - yes, I support a Standards track encoding with two PCN encoding
states

Q2 - yes, I support an Experimental track encoding that extends the
Standards track encoding to give an extra PCN encoding state

Q3 - yes, I believe there is enough information now for the PCN WG to
make its decisions immediately about the Standards track elements of its
Charter, ie the encoding(*) and the PCN-interior-node's marking
behaviours. 
(*) including the Exptal encoding of Q2. 
The recent discussion on the list has (as far as I can tell) not raised
any substantive new issue; it's a re-statement of the ECMP issue, which
is known to be an issue. (And incidentally was a known issue for NSIS -
which suggests it's a fundamental characteristic of a system with both
ECMP and flow admission control. That simply means the user of PCN has
to recognise the issue and either be appropriately cautious or use one
of the known, but not wholly satisfactory, solutions.)

Best wishes and Happy Easter!
Phil/ 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Steven Blake
> Sent: 18 March 2008 17:08
> To: pcn
> Subject: [PCN] Concensus questions: Q1, Q2, and Q3.
>

---

From: <[email-masked]>
Date: Thu, 20 Mar 2008 15:38:07 -0000

Hi Steven,

Q1: Yes, I agree that we should initially aim to standardise a scheme
that gives two encoding states.

Q2: Yes, I agree that we should simultaneously produce one (or more)
experimental extensions to provide a third encoding state.

Q3: Yes, I think the PCN WG has sufficient information to make a
decision on the way forward for a standards track PCN scheme. This
should be done in parallel with working on the experimental extensions.

Toby

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Steven Blake

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 20 Mar 2008 12:09:28 -0400

Hi Steven,

Q1: Yes - we should initially aim to standardize a scheme that gives two
encoding states.

Q2: Yes -  we should simultaneously produce one (or more) experimental
extensions to provide a third encoding state.

Q3: Yes - I believe the PCN WG has sufficient information to make a
decision on the way forward for a standards track PCN scheme. 

Anna

> Sent: Tuesday, March 18, 2008 1:08 PM
> To: pcn
> Six consensus questions were taken during the IETF 71 
> meeting.  I would now like to raise them on the list.  I will 
> do this in step-wise fashion.
> 
> By my notes, Q1 was accepted in the meeting 8-0, Q2 was 
> accepted 9-0, and Q3 was accepted 6-1 (but my notes are fuzzy 
> on Q3's result).
>

---

From: Steven Blake <[email-masked]>
Date: Tue, 25 Mar 2008 11:13:26 -0400

> Please send comments to the list during the next few days.

We've heard from a few.  Does anyone else have comments?

Regards,

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 26 Mar 2008 10:23:57 +0100

Hi Steven

Regarding Question Q1, I think that, from my point of view, it is Yes!

Before answering questions Q2 and Q3, I would like that 
some questions/comments should be clarified.

Question Q2:
I consider that an experimental-track extension for another 
PCN scheme that uses only two encoding states should also be allowed.
Is this option also included in the question.

Question Q3:
According to the current version of the PCN architecture, 
The PCN scheme should also be able to support the admission control and flow
termination
detection and handling (selection of the flows to be terminated) at the
egress.
SM and CL-PHB cannot support the handling (selection of the flows to be
terminated) 
at the egress. This means that such a PCN scheme should also be allowed,
i.e., as 
an experimental-track extension.

Furthermore, according to the previous discussions on the PCN mailing list, 
I think that care should be taken on the way of how preferential dropping is
used 
wthin the PCN domain. In other words, preferetial dropping of marked packet 
should not be mandated.

Best regards,
Georgios

> Sent: dinsdag 25 maart 2008 16:13
> To: pcn
> Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3.
> 
> > Six consensus questions were taken during the IETF 71 meeting.  I 
> > would now like to raise them on the list.  I will do this 
> in step-wise 
> > fashion.
> > 
> accepted 9-0,

---

From: Steven Blake <[email-masked]>
Date: Wed, 26 Mar 2008 11:58:24 -0400

> Is this option also included in the question.

My intent with the question is that any experimental-track proposals
would be extensions of the standards-track scheme.  I believe that is
the sense that others understood as well.

> an experimental-track extension.

I don't understand why neither SM or CL-PHB can support egress-based
flow termination, *assuming that the egress node has flow state* (which
is presumed if we are not tunneling).

Regards,

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 28 Mar 2008 11:23:37 +0100

Hi Steven

Please see in line!

> From: Steven Blake [mailto:[email-masked]] 
> Sent: woensdag 26 maart 2008 16:58
> To: Georgios Karagiannis
> Cc: 'pcn'
> Subject: RE: [PCN] Concensus questions: Q1, Q2, and Q3.
> 
> > Before answering questions Q2 and Q3, I would like that some 
> > questions/comments should be clarified.
> > 
> > Question Q2:
> PCN scheme 
> > that uses only two encoding states should also be allowed.
> My intent with the question is that any experimental-track 
> proposals would be extensions of the standards-track scheme.  
> I believe that is the sense that others understood as well.

Georgios: Okay, if n experimental-track extension for another 
PCN scheme that uses only two encoding states should also be allowed, then
my answer to question Q2 
is YES.

> 
> > Question Q3:
> > According to the current version of the PCN architecture, The PCN 
> > scheme should also be able to support the admission control 
> and flow 
> > termination detection and handling (selection of the flows to be 
> > terminated) at the egress.
> > SM and CL-PHB cannot support the handling (selection of the 
> flows to 
> > be
> > terminated)
> > at the egress. This means that such a PCN scheme should also be 
> > allowed, i.e., as an experimental-track extension.
> 
> I don't understand why neither SM or CL-PHB can support 
> egress-based flow termination, *assuming that the egress node 
> has flow state* (which is presumed if we are not tunneling).

Georgios: The main problem with these schemes is that they are measuring the
actual value of the 
throughput and not the actual value of the excess rate. Note that the actual
value of the excess rate is needed
in order to know how many flows should be selected for termination.
SM and CL-PHB are able to calculate this actual excess rate only at the
ingress. The egress sends the value of the 
measured throughput. Then the ingress measures the incoming load and
substracts the measured throughput in order to calculate the actual 
Excess rate. In this way, the ingress can calculate and select flows to be
terminated in order to solve the severe congestion.
A scheme like LC-PCN is measuring the actual excess rate directly at the
egress. In this way, the egress can calculate and select 
flows to be terminated in order to solve the severe congestion.
Best regards,
Georgios

> 
> > Furthermore, according to the previous discussions on the 
> PCN mailing 
> > list, I think that care should be taken on the way of how 
> preferential 
> > dropping is used wthin the PCN domain. In other words, preferetial 
> > dropping of marked packet should not be mandated.
> 
> 
> 
> Regards,
>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sat, 29 Mar 2008 18:00:50 -0400

My answers:
Yes to Q1, Q2 and Q3.

On Q1, I'm assuming that the next question that needs to be asked is
what will PCN wg standards using only two codepoints?
a) Method for admission control?
b) Method for flow termination?
c) Method that attempts to do both admission control and flow
termination using only two codepoints?

As has been pointed out on the list there are performance and deployment
constrictions with c approach. 

On Q2, I believe the other encoding should be optional versus
experimental, but can live if the wg prefers experimental.

Further, I believe that PCN wg needs to standardize a method for
admission control that can be deployed and will work well in most
networks. Flow termination should be optional as it may not be needed in
many network and operators may choose other ways to solve single link
failures or even multiple link/node failures versus using flow
termination.     

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Steven Blake
Sent: March 18, 2008 1:08 PM
To: pcn
Subject: [PCN] Concensus questions: Q1, Q2, and Q3.

Regards,

---

From: Steven Blake <[email-masked]>
Date: Mon, 31 Mar 2008 13:07:09 -0400

> Please send comments to the list during the next few days.

By my reading of the (limited) feedback, we have very firm consensus on
Q1 and Q2, and rough consensus on Q3.  I will send a follow-up email on
the remaining questions in a moment.

Regards,