Subject: [PCN] [Fwd: RE: Concensus questions from Thursday's PCN meeting]

From: Steven Blake <[email-masked]>
Date: Sun, 16 Mar 2008 22:57:32 -0400

Forwarded from Georgios.  For some reason it has not shown up on the pcn
list yet.

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

Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
From: "Georgios Karagiannis" <[email-masked]>
To: "Anna Charny (acharny)" <[email-masked]>, "Steven Blake" <[email-masked]>, "pcn" <[email-masked]>
Date: Sun, 16 Mar 2008 15:02:50 +0000

Hello Anna

Please see some comments in line!

On 3/14/2008, "Anna Charny (acharny)" <[email-masked]> wrote:

>Hello Georgios,
>
>A few comments: 
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Georgios Karagiannis
>> Sent: Friday, March 14, 2008 2:29 PM
>> To: Steven Blake; pcn
>> Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
>> 
>> Hi all
>> 
>> Before taking any decisions I would like to emphasize the following.
>> 
>> In my opinion preferential dropping of any kind increases the 
>> complexity in the interior routers.
>
>Yes, that is absolutely true
>
>> Furthermore, when excess 
>> rate mechanisms are used, by preferentially dropping marked 
>> packets it severely decreases the robustness of the PCN 
>> domain operation.
>> With robustness I mean, that due to a corner case or due to a 
>> msiconfiguration the operation of the PCN domain will 
>> completely collapse.
>> This is because the admission control trigger (CLE) at the 
>> egress is much more sensistive when marked packets are 
>> dropped than either the situation that unmarked and marked 
>> packets are dropped randomly (current implementation of 
>> routers) or the situation that unmarked packets are dropped.
>
>Georgios, I do believe this is really quite an exaggeration.  In SM, all
>excess-rate packets will be dropped only if the bottleneck link has
>admission threshold configured at the link speed.  This is certainly not
>the expected configuration.  And SM does not care about absolute amount
>of marked packets - it only needs to see a small percentage (~1%) of
>excess rate marks to work, as all of our simulations show. 

Georgios: I will just give you an example:
I will describe two situations:
Situation 1:
Consider that an ingress-egress-aggregate includes flows that are passing
from at least two paths.
Assume that path1 supports a maximum bandwidth capacity of C. Now
consider that the maximum bandwdith capacity of path2 is 15*C.
Consider also that both paths are fully utilized.

Consider that preferentially marked packets are dropped and that path2
fails.
Now assume that all (maximum) traffic passing through path2 will be
rerouted through path1. If a bottleneck router located in path1, say
Rbott, is misconfigured (i.e., from the point of view of having wrongly
too high configured-admissible-rate value), then it can be possible that
CLE measured at the egress cannot reach 1%. Note that
CLE = marked packets/ (marked packets + unmarked packets).
This is because Rbott will just allow an excess rate to pass through that
is equal to: C - configured-admissible-rate. The rest of the marked
packets, so the rest of the excess rate, will be dropped by Rbott, since
this router is preferentially dropping marked packets.
This will mean that the CLE > 1% will not be triggered, this will mean
that the flow termination will not be triggered and that the operation
of the PCN domain will collapse completely.

Situation 2:
Now consider that the router just operates as currently, i.e., no
preferential drop, randomly dropping marked and unmarked packets.
Consider also that the two paths described in Situation 1 above are used
and that they are fully utilized.
Assume also that path2 fails and that the path2 traffic is rerouted on
path1.
Even if routers are misconfigured in path1 (i.e., from the point of view
of having wrongly too high configured-admissible-rate value), now the
CLE value will be able for sure to reach the triggering value of 1%.
This is because the routers in path1 will drop randomly marked and
unmarked packets.
It is certain that in this case the CLE will reach 1% due to the
following reason.
In this example it is assumed that the maximum bandwidth capacity
supported by path2 is 15*C. This means that after rerouting the traffic
from path2 into path1, the ratio between marked packets and unmarked
packets that are passing thorugh path1 can be equal or higher than 15.
Note that the routers in path1 will mark the excess rate above C, thus
15 * C (i.e., the rerouted traffic from path2) as marked.
The above observation holds also for the situation that the routers are
preferentially dropping unmarked packets.

Thus when routers are preferentially dropping marked packets the
robustness of the PCN domain operation is decreasing and in some cases
it severely decreases, which could cause the complete collapse of the
PCN domain operation.

>
>> Therefore, as an initial step is better to do not change the 
>> current router behavior from the preferential dropping point of view.
>> 
>
>The proposal as presented is that preferential drop is a SHOULD, not a
>must.  Since it does not preclude interoperability,  that is OK.
>If the preferential drop is not implemented,  SM will potentially
>overterminate more in the case of multiple congested bottlenecks.

Georgios: I think that the robustness of the PCN domain operation, is
more important than overtermination.

>
>> Regarding LC-PCN and 3SM operation at the core, the only 
>> requirements that have to be supported are:
>> 
>> * use current router behavior from the preferential dropping 
>> point of view.
>
>No, not really.  Performance of 3SM will be slowed down quite
>substantially if large number of excess-marked packets are dropped.
>Indeed 3SM is less sensitive to loss preference, however.  It does
>however need 3 encoding states that we do not seem to have, and requires
>other modifications to the "current router behavior".

Georgios: Please do not understand me wrong, I agree that during the
first step we should work on standardizing SM.
But we should allow the possibility in the future to implement as
experimental RFC the CL-PHB, and the specification of a scheme that is
able to detect and handle the admission control and flow termination at
the PCN-egress-node in another experimental RFC.

Now regarding the comment on 3SM, yes, I agree that it is slower, but
when the slowing down factor is implemented at the core routers, a
cleaver mechanism could be found later on at the egress that uses this
information and selects the e.g., "big flows" first in order to
increase the termination speed.

>
>As to LC-PCN,  in the slides you sent to me for the presentation on
>Thursday you had the following for LC-PCN " [Loss preference] depends on
>thres.[hold] set[tting]. Typically, prefer not to drop ex[cess]. Rate".
>Did you change your mind and now believe it is wrong?  

Georgios: I did not change my mind, typically yes the LC-PCN should not
drop marked packets. However, due to the fact that the admission control
and flow termination triggers at the egress, are based on the ratio of
(marked/(marked + unmarked), than dropping randomly marked and unmarked
packets, as is done today will operate okay.

>LC-PCN will also
>need another modification to the "current router behavior" as it would
>need to mark only a subset of excess rate packets, which requires a
>modification to the token bucket. 

Georgios: Yes, I agree, I think from the point of view of Token bucket
operation, SM will need less changes to router operation.
The above listed comment by me on complexity increase, holds only for
implementing preferential dropping, instead of implementing random
dropping of marked and unmarked packets.

>This is you say below is not an
>optional optimization, but is required for LC-PCN to work.  The optional
>optimization is there to make the algorithm not overterminate. It is to
>the excitant equally optional as preferential drop for SM - as that too
>is there to not let SM overterminate :-).

Georgios: Note that using N in LC-PCN is not an optional optimization.
The LC-PCN needs a very small change in the current token bucket
implementation. This small change is that the token bucket should mark N
packet (or bytes) instead of marking one packet (or byte). Note that if
N = 1, then the token bucket operates the same as described in the SM
draft.
If N > 1, then the SM scheme can operate in the same way with
the difference that the measured excess rate at the egress
should be multipleied with N.

Thus my proposal is to now standardise SM, and in addition, the core
router should allow, for the near future, the specification of the
CL-PHB behaviour in an experimental RFC and the specification of a
scheme that is able to detect and handle the admission control and flow
termination at the PCN-egress-node in another experimental RFC.

Best regards,
Georgios

>
>> Thus drop marked and unmarked packets randomly. Do not 
>> preferentially drop marked packets.
>> 
>
>Again, the proposed approach is to put a SHOULD in the preferential drop
>requirement. 
>
>Best,
>Anna 
>
>
>> * use a parameter N (or S) that should be equal in whole PCN domain.
>> The only change in the token bucket implementation will be 
>> that the token bucket should mark N packet (or bytes) instead 
>> of marking one packet (or byte). Note that if N = 1, then the 
>> token bucket operates the same as described in the SM draft. 
>> If N > 1, then the SM scheme can operate in the same way with 
>> the difference that the measured excess rate at the egress 
>> should be multipleied with N.
>> 
>> All the other optimization features that are described in the 
>> LC-PCN draft are optional.
>> 
>> Best regards,
>> Georgios
>> 
>> 
>> 
>> 
>> On 3/14/2008, "Steven Blake" <[email-masked]> wrote:
>> 
>> >Greetings.
>> >
>> >There were six concensus questions called during yesterday's PCN 
>> >meeting.  Before we call the questions on the list, I want to 
>> >paraphrase them and make sure that everyone agrees that this 
>> captures 
>> >the sense of the discussion.
>> >
>> >
>> >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: Should the PCN wg produce an experimental-track extension to the
>> >    standards-track PCN scheme that requires another 
>> encoding state (for
>> >    a total of three encoding states)?
>> >
>> >Q3: Does the working group have enough information to make a decision
>> >    about the way forward for the standards-track PCN scheme?
>> >
>> >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)?
>> >
>> >
>> >Please send comments to the list.
>> >
>> >
>> >Regards,
>> >
>> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> >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
>> 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn