Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6

From: "Anna Charny (acharny)" <[email-masked]>
Date: Wed, 2 Apr 2008 17:13:45 -0400

Hello Steven and all,

Please see below: 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Steven Blake
> Sent: Monday, March 31, 2008 1:18 PM
> To: pcn
> Subject: [PCN] Consensus questions: Q4, Q5, and Q6
> 
> Here are the remaining three questions that were taken during the IETF
> 71 meeting:
> 
> Q4: Should the standards-track PCN scheme require (as a MUST implement
>     feature) that interior PCN routers support Excess-Rate marking,
>     according to the particular method of handling already marked 
>     packets and drops described in Anna Charny's presentation?
>     http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf

Yes

> 
> Q5: Should the standards-track PCN scheme require (as a MUST implement
>     feature) that interior PCN routers support Threshold marking (in
>     addition to Excess-Rate marking), according to the 
> particular method
>     described in Philip Eardley's presentation on Tuesday?
>     http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf

No, in my opinion.  It would put an undue burden on the implementation
that wants to do both admission and termination using excess rate
marking only. I would be much happier with a SHOULD. 

> 
> Q6: If presented with sufficient evidence in a timely fashion, would
>     the PCN wg entertain the option of modifying the interior router
>     Excess-Rate marking behavior for the standards-track PCN 
> scheme (as
>     described in question 4)?
> 
> According to the draft meeting minutes, Q4 was accepted 8-0 
> (my notes have it as 6-0), Q5 was accepted 6-1, and Q6 was 
> accepted 2-0.
>

Abstained. Depends on the nature of the evidence. 

Thanks,
Anna 

> Please send comments to the list during the next few days.
> 
> 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Steven Blake                <[email-masked]>
> Ericsson/Redback Networks               +1 919-472-9913
> 
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
> 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Fri, 4 Apr 2008 10:12:26 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Steven Blake
> Sent: 31 March 2008 18:18
> To: pcn
yes

>     addition to Excess-Rate marking), according to the particular
method
>     http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf

yes. I believe that, with a single DSCP (two encoding states, ie not
precongested & precongested), it is likely that operators will want to
do admission ctrl alone, but with the accuracy achieved by threshold
marking (rather than excess rate marking). If it isn't a MUST, then we
have configuration complexity of ensuring that all routers are enabled
like this. 
I don't know if there's some other alternative. Perhaps "PCN" have the
two MUSTs whereas "PCN lite" would have one MUST (excess rate). Don't
know whether this is a good or bad idea. 

>     Excess-Rate marking behavior for the standards-track PCN scheme
(as
>     described in question 4)?

Yes, although it obviously depends what the evidence is! to me 'timely
fashion' means before the 00 dublin draft deadline and 'evidence' means
a set of simulations with comparisons with at least CL. In the meantime,
we should proceed on the assumption that this evidence isn't forthcoming
(that was how I understood the discussion in Philadelphia). 

> 
> According to the draft meeting minutes, Q4 was accepted 8-0 (my notes
> have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0.
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 4 Apr 2008 17:16:54 +0200

Steven,

this one is more difficult. My views below.

Regards,

Rudiger

| Q4: Should the standards-track PCN scheme require (as a MUST implement
|     feature) that interior PCN routers support Excess-Rate marking,
|     according to the particular method of handling already marked 
|     packets and drops described in Anna Charny's presentation?
|     http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf

Yes.

| 
| Q5: Should the standards-track PCN scheme require (as a MUST implement
|     feature) that interior PCN routers support Threshold marking (in
|     addition to Excess-Rate marking), according to the particular method
|     described in Philip Eardley's presentation on Tuesday?
|     http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf

Tough. Phil suggested something like PCN lite and to me that sounds a 
little like two RFCs or like a parent and a child RFC. I'm not sure.
I'm happy with any simple mechanism proving to be efficient and I think 
this is one. So that's a yes. But I'd like to be sure that suppliers don't 
implement excess or threshold only.

As a non participant in Philadelphia, I'm worried by the rerefence 
'(see encoding)' in Phil's document. I guess I've seen that or it is in 
the minutes. A reference to the coding presentation as part of this 
question may be helpful.

| 
| Q6: If presented with sufficient evidence in a timely fashion, would
|     the PCN wg entertain the option of modifying the interior router
|     Excess-Rate marking behavior for the standards-track PCN scheme (as
|     described in question 4)?

I need a better specification of what "sufficient evidence" means. I'm not 
interested in a solution performing slightly better than any of Q4 and Q5
but coming with serious implementation complexity (this also covers 
implementation of completely new policing or queuing mechanisms, any 
kind of per flow measurements in backbone routers, RAO processing on 
backbone routers, to name a few). I also object to any proposal which 
isn't well engineered, so that standardisation of PCN is further 
delayed. Any input of that type should go to a separate draft.

| 
| According to the draft meeting minutes, Q4 was accepted 8-0 
| (my notes have it as 6-0), Q5 was accepted 6-1, and Q6 was 
| accepted 2-0.
| 
| Please send comments to the list during the next few days.
| 
| 
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Steven Blake                <[email-masked]>
| Ericsson/Redback Networks               +1 919-472-9913
| 
| _______________________________________________
| PCN mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Jozef Babiarz" <[email-masked]>
Date: Sun, 6 Apr 2008 01:57:43 -0400

My answers below. 

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Steven Blake
Sent: March 31, 2008 1:18 PM
To: pcn
Subject: [PCN] Consensus questions: Q4, Q5, and Q6

[Joe] No. 

    addition to Excess-Rate marking), according to the particular method
[Joe] Yes. 

Q6: If presented with sufficient evidence in a timely fashion, would
    the PCN wg entertain the option of modifying the interior router
    Excess-Rate marking behavior for the standards-track PCN scheme (as
    described in question 4)?
[Joe] Abstain. I missed the meeting so do not know what was proposed.

---

From: Lars westberg <[email-masked]>
Date: Mon, 07 Apr 2008 12:45:04 +0200

answers inline:

>     http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf
YES, only if Q6 is accepted

>     http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf
YES

>     described in question 4)?
YES

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 07 Apr 2008 10:47:50 +0000

Hi all

Please see in line!

>    http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf

Yes, if Q6 is also accepted

Yes

Yes

Best regards,
Georgios

---

From: <[email-masked]>
Date: Mon, 7 Apr 2008 11:54:20 +0100

Lars, Georgios,

On Q6, please could you comment / confirm you agree with my email:

Thanks

Phil/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Lars westberg
Sent: 07 April 2008 11:45
To: Steven Blake
Cc: pcn
Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6

answers inline:

Steven Blake wrote:

YES

YES

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

---

From: "Lars Westberg" <[email-masked]>
Date: Mon, 7 Apr 2008 13:02:04 +0200

The purpose is to prepare a simulatoin cases that showing the comparison
based on the working group specification. As I understand, there are
some drafts about performance comparison scenario.
 
-Lasse

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: den 7 april 2008 12:54
To: Lars Westberg; Steve Blake
Cc: [email-masked]
Subject: RE: [PCN] Consensus questions: Q4, Q5, and Q6

Lars, Georgios,

Thanks

Phil/

-----Original Message-----

answers inline:

Steven Blake wrote:

YES

YES

---

From: <[email-masked]>
Date: Mon, 7 Apr 2008 12:11:42 +0100

Thanks that sounds good. several people [not me!} can help with making
sure the simulations are truly comparable [this seems to be quite
tricky] 

-----Original Message-----
From: Lars Westberg [mailto:[email-masked]] 
Sent: 07 April 2008 12:02
To: Eardley,PL,Philip,CXR9 R; Steve Blake
Cc: [email-masked]
Subject: RE: [PCN] Consensus questions: Q4, Q5, and Q6

-Lasse

Lars, Georgios,

Thanks

Phil/

-----Original Message-----

answers inline:

Steven Blake wrote:

YES

YES

---

From: <[email-masked]>
Date: Mon, 7 Apr 2008 14:09:07 +0100

Inline...

Toby 

YES

YES

>     described in question 4)?

YES, but ONLY if a) the evidence is convincing (e.g. much better in
majority of FEASIBLE deployment scenarios) and b) is available for the
Dublin meeting. Otherwise I don't support delaying things any further...

---

From: Steven Blake <[email-masked]>
Date: Wed, 09 Apr 2008 21:35:39 -0400

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

Any last comments?

// Steve

---

From: Steven Blake <[email-masked]>
Date: Sun, 20 Apr 2008 13:41:05 -0400

> have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0.

The feedback from the list for Q4 and Q5 seems to match up closely with
the results in the meeting (not surprising, as it was mostly the same
individuals commenting).  I counted one dissent for Q4 and one for Q5.

The feedback for Q6 was a mixture of abstain and Yes with caveats.  If
and when someone wants to propose modifications to the Excess-Rate
marking behavior, we can see if there is interest to discuss it on the
list, but I *strongly encourage* that any such discussion needs to
happen before the Dublin meeting.

We seem to have consensus to go forward with a standards-track proposal
supporting two encoding states, with Excess-Rate and Threshold marking
as MUST implement features.  In addition, we are open to work on one or
more experimental-track proposals (as a lower priority acitivity) that
are extensions of the standards-track proposal, using an additional
encoding state.  

This is a call for volunteers to start working on drafts for the
standards-track interior node detection, (in-band) PCN encoding,
egress-ingress feedback protocol, and boundary node mechanisms, as
spelled out in the PCN charter.

Note: I will be (mostly) off line for the rest of the week.

Regards,

// Steve

---

From: <[email-masked]>
Date: Mon, 21 Apr 2008 17:41:44 +0100

On the subject of Qu 4:
Don't want to re-open this question, but I thought a bit more at the
preferential dropping issue, ie if a PCN-node is overloaded and has to
drop PCN-packets, should it preferentially drop any that are already
PCN-marked (PCN-excess-rate-marked) - or preferentially drop ones that
are not marked - or just randomly drop. (The first of these is where the
WG consensus lies, and is also where this email ends up.)

The preferential dropping behaviour matters when there's at least one
pre-congested node 'before' the overloaded node ("two bottlenecks")
 
The ideal answer depends on what the edge behaviour is:
*	the CL/SM edge mechanism measures the sustainable rate (the rate
of unmarked pkts), and terminates rate above this. So ideally PCN-nodes
should preferentially drop pkts that already PCN-(termination-)marked,
otherwise too much PCN-traffic will be terminated if there are two
bottlenecks.
*	The excess rate & EMFT mechanisms measure (react to) PCN-marked
pkts. So ideally PCN-nodes should preferentially drop pkts that not
PCN-(termination-)marked, otherwise PCN-traffic will be terminated
slower if there are two bottlenecks.
 
However, it would be good if the PCN-node behaviour allowed some
flexibility in terms of the edge behaviour (at least we seem to have
been implicitly assuming this). Their pros/cons are:
*	CL/SM edge behaviour: can terminate the right amount in a single
shot (but can also terminate slower, if that's preferred); requires one
msg from egress to ingress to indicate termination; but has to measure
rates at both egress and ingress
*	Excess rate: in general terminates slower & so requires several
msgs; requires rate measurement at the egress but not ingress
*	EMFT: doesn't need to measure any rate, but terminates slower
and needs a msg for each flow that's terminated
 
Consider two cases in more detail. [1] the operator sets the
PCN-upper-rate at 95% of PCN-max-rate; [2] the operator sets the
PCN-upper-rate at 50% of PCN-max-rate There's the PCN-upper-rate above
which pkts are PCN-excess-rate-marked and the PCN-max-rate above which
PCN-pkts are dropped.
 
For case [1], with a single bottleneck that's overloaded (say at 5*
PCN-max-rate), ie dropping pkts as well as marking pkts:
*	the CL/SM edge mechanism can terminate the right amount in one
go. Termination is just as fast as when the bottleneck is pre-congested
but not overloaded. 
*	the excess rate mechanism measures the 5% of marked pkts. It
terminates this amount - the link is now overloaded at 4.95*
PCN-max-rate. This makes termination about 100* slower.
*	With EMFT, if the edge sees a marked pkt then it terminates this
flow with some probability. This is similar to the previous case, so
again termination is much much slower. However, it should be possible to
speed up termination a bit by terminating a marked flow with a greater
probability; the caution is that this increases the chances of
over-terminating, because of the time lag after a termination decision
before the rate reduces.)
 
For case [2], the difference is not quite as great - termination is
about 10* slower. 
Conclusion: an operator who wants to use its capacity "aggressively" by
setting the PCN-upper-rate at 95% of PCN-max-rate must use the CL/SM
edge mechanism. 
 
Now let's consider the two bottleneck case, with the first marking and
the second dropping pkts. We only need to compare edge behaviours in
case [2].
*	if the overloaded node preferentially drop pkts that are already
marked, then the result is (max) 50% are unmarked, 50% marked and the
rest are dropped (0.5* PCN-max-rate unmarked = PCN-upper-rate; 0.5*
PCN-max-rate marked; 4* PCN-max-rate dropped). This is exactly the same
as in the single bottleneck case. Hence:
o	again, the CL/SM edge mechanism can terminate the right amount
in one go.
o	Again, Excess rate /EMFT terminates at the same slow speed as in
the single bottleneck case
*	if the overloaded node preferentially drop pkts that are
unmarked, then the result is all pkts are marked and the rest are
dropped (1* PCN-max-rate marked; 4* PCN-max-rate dropped)
o	the CL/SM edge mechanism no longer works. All pkts are marked,
so the sustainable rate is 0 & so it terminates all flows.
o	Excess rate /EMFT terminates about twice as fast as in the
single bottleneck case (but still about 5* slower than the CL/SM
mechanism achieves above)
*	if the overloaded node randomly drops pkts that are already
marked, then the result is roughly 10% are unmarked, 90% marked and the
rest are dropped (0.1* PCN-max-rate unmarked; 0.9* PCN-max-rate marked;
4* PCN-max-rate dropped)
o	the CL/SM edge mechanism terminates 5* too much (sustainable
rate is only 20% of what it really is)
o	Excess rate /EMFT terminates towards twice as fast as in the
single bottleneck case (but still over 5* slower than the CL/SM
mechanism achieves above)
 
Conclusion:
*	if the overloaded node preferentially drop pkts that are
unmarked, then the CL/SM edge behaviour is not possible - so this option
can be excluded.
*	if the overloaded node randomly drops pkts that are already
marked, then the CL/SM edge mechanism terminates far too much. The CL/SM
mechanism could be deliberately slowed down in order to reduce the risk
of over-termination. However, this creates a penalty of slower
termination in the single bottleneck case. The operator also needs to
guess what the highest level of overload is/ 
 
The above is intended to be purely descriptive. Now to give my opinion.
I believe it means that the standard should specify that an overloaded
node SHOULD preferentially drop pkts that are already excess-rate
marked:
*	it gives the operator as much freedom as possible on setting the
PCN-upper-rate in relation to the PCN-max-rate. Otherwise it cannot set
PCN-upper-rate close to PCN-max-rate.
*	It allows an operator to achieve termination to the correct rate
in a single shot (providing they're prepared to do the work of measuring
rates at egress & ingress). Otherwise they must *always* slow down
termination, in case there are two bottlenecks when there could be far
too much termination. 
*	It allows an operator to achieve termination with a simpler
mechanism like EMFT, albeit somewhat slower than would be achieved by
different preferential dropping behaviour. However, such an operator has
already accepted that, in the case where even one node is overloaded,
termination will be much slower than with a CL/SM edge behaviour. In
other words, such an operator has made the decision that the simpler
edge mechanism (in terms of not having to measure rates) is important
enough that they don't mind termination being slower than ideal if
there's an overloaded node.

Comments?
Phil/

> Sent: 20 April 2008 18:41
> To: pcn
method
(as

---

From: Michael Menth <[email-masked]>
Date: Mon, 21 Apr 2008 19:31:20 +0200

Hi Phil,

as your analysis showed, CL/SM require preferential dropping of marked 
packets. Other termination methods required preferential marking of 
unmarked packets. If PCN marking should be optimized for CL/SM at the 
expense of other solutions, preferential dropping of marked packets it 
the way to go. But this kind of marking is hardly of any use for other 
termination methods in challenging situations.

So, if other solutions should not be excluded, preferential dropping of 
unmarked packets is also required as an option. Then it is probably also 
wise to have another option that does not do any preferential drop. The 
decision on preferential dropping limits the potential use of PCN 
marking or the number of architectural options.

Regards,

    Michael

[email-masked] wrote:
>>> Here are the remaining three questions that were taken during the
>>>       
> IETF
>   
>>> 71 meeting:
>>>
>>> Q4: Should the standards-track PCN scheme require (as a MUST
>>>       
> implement
>   
>>> Q5: Should the standards-track PCN scheme require (as a MUST
>>>       
> implement
>   
>>> According to the draft meeting minutes, Q4 was accepted 8-0 (my
>>>       
> notes
>   
>> The feedback from the list for Q4 and Q5 seems to match up closely
>>     
> with
>   
>> We seem to have consensus to go forward with a standards-track
>>     
> proposal
>   
>> as MUST implement features.  In addition, we are open to work on one
>>     
> or
>   

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 22 Apr 2008 09:35:46 +0200

Hi Phil,

if I got your 5 times max rate scenario right, apart from marking 
issues applications will face a packet loss of around 80%. If that 
is true, a discussion of "reaction speed" may have to consider 
end user reaction too (I guess, after a couple of seconds it 
should).

Am I right, you are assuming a network with a high degree of 
meshing in a WAN and a simultaneous loss of allmost all WAN 
interfaces of a router for your scenario? The other case I could 
figure out was a badly engineered network where traffic destined 
for link with a higher gedree of aggregation is pushed back onto 
a link with a significantly lower degree of aggregation. I'd 
assume that tier1/2 carrier networks are engineered to avoid 
the latter.

Regards,

Rudiger

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of [email-masked]
| Sent: Monday, April 21, 2008 6:42 PM
| To: [email-masked]
| Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6
| 
| On the subject of Qu 4:
| Don't want to re-open this question, but I thought a bit more 
| at the preferential dropping issue, ie if a PCN-node is 
| overloaded and has to drop PCN-packets, should it 
| preferentially drop any that are already PCN-marked 
| (PCN-excess-rate-marked) - or preferentially drop ones that 
| are not marked - or just randomly drop. (The first of these 
| is where the WG consensus lies, and is also where this email ends up.)
| 
| The preferential dropping behaviour matters when there's at 
| least one pre-congested node 'before' the overloaded node 
| ("two bottlenecks")
|  
| The ideal answer depends on what the edge behaviour is:
| *	the CL/SM edge mechanism measures the sustainable rate (the rate
| of unmarked pkts), and terminates rate above this. So ideally 
| PCN-nodes should preferentially drop pkts that already 
| PCN-(termination-)marked, otherwise too much PCN-traffic will 
| be terminated if there are two bottlenecks.
| *	The excess rate & EMFT mechanisms measure (react to) PCN-marked
| pkts. So ideally PCN-nodes should preferentially drop pkts 
| that not PCN-(termination-)marked, otherwise PCN-traffic will 
| be terminated slower if there are two bottlenecks.
|  
| However, it would be good if the PCN-node behaviour allowed 
| some flexibility in terms of the edge behaviour (at least we 
| seem to have been implicitly assuming this). Their pros/cons are:
| *	CL/SM edge behaviour: can terminate the right amount in a single
| shot (but can also terminate slower, if that's preferred); 
| requires one msg from egress to ingress to indicate 
| termination; but has to measure rates at both egress and ingress
| *	Excess rate: in general terminates slower & so requires several
| msgs; requires rate measurement at the egress but not ingress
| *	EMFT: doesn't need to measure any rate, but terminates slower
| and needs a msg for each flow that's terminated
|  
| Consider two cases in more detail. [1] the operator sets the 
| PCN-upper-rate at 95% of PCN-max-rate; [2] the operator sets 
| the PCN-upper-rate at 50% of PCN-max-rate There's the 
| PCN-upper-rate above which pkts are PCN-excess-rate-marked 
| and the PCN-max-rate above which PCN-pkts are dropped.
|  
| For case [1], with a single bottleneck that's overloaded (say 
| at 5* PCN-max-rate), ie dropping pkts as well as marking pkts:
| *	the CL/SM edge mechanism can terminate the right amount in one
| go. Termination is just as fast as when the bottleneck is 
| pre-congested but not overloaded. 
| *	the excess rate mechanism measures the 5% of marked pkts. It
| terminates this amount - the link is now overloaded at 4.95* 
| PCN-max-rate. This makes termination about 100* slower.
| *	With EMFT, if the edge sees a marked pkt then it terminates this
| flow with some probability. This is similar to the previous 
| case, so again termination is much much slower. However, it 
| should be possible to speed up termination a bit by 
| terminating a marked flow with a greater probability; the 
| caution is that this increases the chances of 
| over-terminating, because of the time lag after a termination 
| decision before the rate reduces.)
|  
| For case [2], the difference is not quite as great - 
| termination is about 10* slower. 
| Conclusion: an operator who wants to use its capacity 
| "aggressively" by setting the PCN-upper-rate at 95% of 
| PCN-max-rate must use the CL/SM edge mechanism. 
|  
| Now let's consider the two bottleneck case, with the first 
| marking and the second dropping pkts. We only need to compare 
| edge behaviours in case [2].
| *	if the overloaded node preferentially drop pkts that are already
| marked, then the result is (max) 50% are unmarked, 50% marked 
| and the rest are dropped (0.5* PCN-max-rate unmarked = 
| PCN-upper-rate; 0.5* PCN-max-rate marked; 4* PCN-max-rate 
| dropped). This is exactly the same as in the single 
| bottleneck case. Hence:
| o	again, the CL/SM edge mechanism can terminate the right amount
| in one go.
| o	Again, Excess rate /EMFT terminates at the same slow speed as in
| the single bottleneck case
| *	if the overloaded node preferentially drop pkts that are
| unmarked, then the result is all pkts are marked and the rest 
| are dropped (1* PCN-max-rate marked; 4* PCN-max-rate dropped)
| o	the CL/SM edge mechanism no longer works. All pkts are marked,
| so the sustainable rate is 0 & so it terminates all flows.
| o	Excess rate /EMFT terminates about twice as fast as in the
| single bottleneck case (but still about 5* slower than the 
| CL/SM mechanism achieves above)
| *	if the overloaded node randomly drops pkts that are already
| marked, then the result is roughly 10% are unmarked, 90% 
| marked and the rest are dropped (0.1* PCN-max-rate unmarked; 
| 0.9* PCN-max-rate marked;
| 4* PCN-max-rate dropped)
| o	the CL/SM edge mechanism terminates 5* too much (sustainable
| rate is only 20% of what it really is)
| o	Excess rate /EMFT terminates towards twice as fast as in the
| single bottleneck case (but still over 5* slower than the 
| CL/SM mechanism achieves above)
|  
| Conclusion:
| *	if the overloaded node preferentially drop pkts that are
| unmarked, then the CL/SM edge behaviour is not possible - so 
| this option can be excluded.
| *	if the overloaded node randomly drops pkts that are already
| marked, then the CL/SM edge mechanism terminates far too 
| much. The CL/SM mechanism could be deliberately slowed down 
| in order to reduce the risk of over-termination. However, 
| this creates a penalty of slower termination in the single 
| bottleneck case. The operator also needs to guess what the 
| highest level of overload is/ 
|  
| The above is intended to be purely descriptive. Now to give 
| my opinion.
| I believe it means that the standard should specify that an 
| overloaded node SHOULD preferentially drop pkts that are 
| already excess-rate
| marked:
| *	it gives the operator as much freedom as possible on setting the
| PCN-upper-rate in relation to the PCN-max-rate. Otherwise it 
| cannot set PCN-upper-rate close to PCN-max-rate.
| *	It allows an operator to achieve termination to the correct rate
| in a single shot (providing they're prepared to do the work 
| of measuring rates at egress & ingress). Otherwise they must 
| *always* slow down termination, in case there are two 
| bottlenecks when there could be far too much termination. 
| *	It allows an operator to achieve termination with a simpler
| mechanism like EMFT, albeit somewhat slower than would be 
| achieved by different preferential dropping behaviour. 
| However, such an operator has already accepted that, in the 
| case where even one node is overloaded, termination will be 
| much slower than with a CL/SM edge behaviour. In other words, 
| such an operator has made the decision that the simpler edge 
| mechanism (in terms of not having to measure rates) is 
| important enough that they don't mind termination being 
| slower than ideal if there's an overloaded node.
| 
| 
| Comments?
| Phil/
| 
| > -----Original Message-----
| > From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of 
| > Steven Blake
| > Sent: 20 April 2008 18:41
| > To: pcn
| > Subject: Re: [PCN] Consensus questions: Q4, Q5, and Q6
| > 
| > On Mon, 2008-03-31 at 13:18 -0400, Steven Blake wrote:
| > > Here are the remaining three questions that were taken during the
| IETF
| > > 71 meeting:
| > >
| > > Q4: Should the standards-track PCN scheme require (as a MUST
| implement
| > >     feature) that interior PCN routers support 
| Excess-Rate marking,
| > >     according to the particular method of handling already marked
| > >     packets and drops described in Anna Charny's presentation?
| > >     http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf
| > >
| > > Q5: Should the standards-track PCN scheme require (as a MUST
| implement
| > >     feature) that interior PCN routers support Threshold 
| marking (in
| > >     addition to Excess-Rate marking), according to the particular
| method
| > >     described in Philip Eardley's presentation on Tuesday?
| > >     http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf
| > >
| > > Q6: If presented with sufficient evidence in a timely 
| fashion, would
| > >     the PCN wg entertain the option of modifying the 
| interior router
| > >     Excess-Rate marking behavior for the standards-track 
| PCN scheme
| (as
| > >     described in question 4)?
| > >
| > > According to the draft meeting minutes, Q4 was accepted 8-0 (my
| notes
| > > have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0.
| > 
| > The feedback from the list for Q4 and Q5 seems to match up closely
| with
| > the results in the meeting (not surprising, as it was 
| mostly the same 
| > individuals commenting).  I counted one dissent for Q4 and 
| one for Q5.
| > 
| > The feedback for Q6 was a mixture of abstain and Yes with 
| caveats.  If 
| > and when someone wants to propose modifications to the Excess-Rate 
| > marking behavior, we can see if there is interest to 
| discuss it on the 
| > list, but I *strongly encourage* that any such discussion needs to 
| > happen before the Dublin meeting.
| > 
| > We seem to have consensus to go forward with a standards-track
| proposal
| > supporting two encoding states, with Excess-Rate and 
| Threshold marking 
| > as MUST implement features.  In addition, we are open to work on one
| or
| > more experimental-track proposals (as a lower priority 
| acitivity) that 
| > are extensions of the standards-track proposal, using an additional 
| > encoding state.
| > 
| > This is a call for volunteers to start working on drafts for the 
| > standards-track interior node detection, (in-band) PCN encoding, 
| > egress-ingress feedback protocol, and boundary node mechanisms, as 
| > spelled out in the PCN charter.
| > 
| > Note: I will be (mostly) off line for the rest of the week.
| > 
| > 
| > Regards,
| > 
| > // Steve
| > 
| > _______________________________________________
| > PCN mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/pcn
| _______________________________________________
| PCN mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 22 Apr 2008 10:13:13 +0200

Hi all

I agree with Michael, see below:
"if other solutions should not be excluded, preferential 
dropping of unmarked packets is also required as an option. 
Then it is probably also wise to have another option that 
does not do any preferential drop. The decision on 
preferential dropping limits the potential use of PCN marking 
or the number of architectural options."

Best regards,
Georgios

> Behalf Of Michael Menth
> Sent: maandag 21 april 2008 19:31
> To: [email-masked]
> Cc: [email-masked]
> as your analysis showed, CL/SM require preferential dropping 
> of marked packets. Other termination methods required 
> preferential marking of unmarked packets. If PCN marking 
> should be optimized for CL/SM at the expense of other 
> solutions, preferential dropping of marked packets it the way 
> to go. But this kind of marking is hardly of any use for 
> other termination methods in challenging situations.
> 
> So, if other solutions should not be excluded, preferential 
> dropping of unmarked packets is also required as an option. 
> Then it is probably also wise to have another option that 
> does not do any preferential drop. The decision on 
> preferential dropping limits the potential use of PCN marking 
> or the number of architectural options.
> 
> Regards,
> 
>     Michael
> 
> > are not marked - or just randomly drop. (The first of these 
> is where 
> > the WG consensus lies, and is also where this email ends up.)
> >
> > of unmarked pkts), and terminates rate above this. So ideally 
> > PCN-nodes should preferentially drop pkts that already 
> > PCN-(termination-)marked, otherwise too much PCN-traffic will be 
> > terminated if there are two bottlenecks.
> > shot (but can also terminate slower, if that's preferred); requires 
> > one msg from egress to ingress to indicate termination; but has to 
> > measure rates at both egress and ingress
> > go. Termination is just as fast as when the bottleneck is 
> > pre-congested but not overloaded.
> > again termination is much much slower. However, it should 
> be possible 
> > to speed up termination a bit by terminating a marked flow with a 
> > greater probability; the caution is that this increases the 
> chances of 
> > Conclusion: an operator who wants to use its capacity 
> "aggressively" 
> > by setting the PCN-upper-rate at 95% of PCN-max-rate must use the 
> > CL/SM edge mechanism.
> >  
> > PCN-max-rate marked; 4* PCN-max-rate dropped). This is exactly the 
> > same as in the single bottleneck case. Hence:
> > marked, then the result is roughly 10% are unmarked, 90% marked and 
> > the rest are dropped (0.1* PCN-max-rate unmarked; 0.9* PCN-max-rate 
> > marked;
> > 4* PCN-max-rate dropped)
> > unmarked, then the CL/SM edge behaviour is not possible - so this 
> > option can be excluded.
> > marked, then the CL/SM edge mechanism terminates far too much. The 
> > CL/SM mechanism could be deliberately slowed down in order 
> to reduce 
> > the risk of over-termination. However, this creates a penalty of 
> > slower termination in the single bottleneck case. The operator also 
> > needs to guess what the highest level of overload is/
> >  
> > PCN-upper-rate in relation to the PCN-max-rate. Otherwise it cannot 
> > set PCN-upper-rate close to PCN-max-rate.
> > in a single shot (providing they're prepared to do the work of 
> > measuring rates at egress & ingress). Otherwise they must *always* 
> > slow down termination, in case there are two bottlenecks when there 
> > could be far too much termination.
> > different preferential dropping behaviour. However, such an 
> operator 
> > has already accepted that, in the case where even one node is 
> > overloaded, termination will be much slower than with a CL/SM edge 
> > behaviour. In other words, such an operator has made the 
> decision that 
> > the simpler edge mechanism (in terms of not having to 
> measure rates) 
> > is important enough that they don't mind termination being 
> slower than 
> > ideal if there's an overloaded node.
> >
> >
> > Comments?
> > Phil/
> >
> >   
> >> The feedback for Q6 was a mixture of abstain and Yes with 
> caveats.  
> >> If and when someone wants to propose modifications to the 
> Excess-Rate 
> >> marking behavior, we can see if there is interest to discuss it on 
> >> the list, but I *strongly encourage* that any such 
> discussion needs 
> >> to happen before the Dublin meeting.
> >>
> >> supporting two encoding states, with Excess-Rate and Threshold 
> >> marking as MUST implement features.  In addition, we are 
> open to work 
> >> on one
> >>     
> > or
> >   
> >> more experimental-track proposals (as a lower priority acitivity) 
> >> that are extensions of the standards-track proposal, using an 
> >> additional encoding state.
> >>
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: <[email-masked]>
Date: Tue, 22 Apr 2008 09:40:07 +0100

Arghh, I really didn't want to re-open the consensus question, I'm an
idiot.

Anyway, 

> > other termination methods in challenging situations.

This is not an accurate summary of my email. Rather: with preferential
dropping of marked packets, CL/SM works well ; and Excess rate /EMFT
still work OK [terminate slower than would do if preferentially dropped
unmarked pkts, but in any case much slower than CL/SM. Ie for an
operator doing excess rate/EMFT, speed of termination isn't their most
important criterion]

Best wishes,
phil

> From: Georgios Karagiannis [mailto:[email-masked]]
> Sent: 22 April 2008 09:13
> To: [email-masked]; Eardley,PL,Philip,CXR9 R
> Cc: [email-masked]
particular

---

From: <[email-masked]>
Date: Tue, 22 Apr 2008 09:41:22 +0100

Rudiger,
You're right, the scenario is a very extreme one & I didn't include end
user reaction effects
Thanks,
Phil.

> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: 22 April 2008 08:36
> To: Eardley,PL,Philip,CXR9 R; [email-masked]