Re: [PCN] Concensus questions from Thursday's PCN meeting

["Anna Charny (acharny)" <[e-mail]>]

Hi Georgios,

A few clarification questions below: 

> -----Original Message-----
> From: Georgios Karagiannis [mailto:[e-mail]] 
> Sent: Sunday, March 16, 2008 11:03 AM
> To: Anna Charny (acharny); Steven Blake; pcn
> Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> 
> Hello Anna
> 
> Please see some comments in line!
> 
> 
> On 3/14/2008, "Anna Charny (acharny)" <[e-mail]> wrote:
> 
> >Hello Georgios,
> >
> >A few comments: 
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] 
> 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.


Do you mean that a single ingress-egress aggregate is travercing two
different paths 0- that is, are we talking about ECMP case?

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

So you are considering the case when there is 16x overload on the
bottleneck after the failure - right?

> 
> 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 routaer is preferentially 
> dropping marked packets.

So it seems to me that in this example the egress will see the
C-configured-admissible-rate of marked packets.  In order for this to be
less than 1% of the total traffic seen by this egress,
configured-admissible-rate should be set to above 99% of the link speed.
Right?  Do you believe it is a realistic setting?


Thank you,
Anna 


> 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" <[e-mail]> 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                <[e-mail]>
> >> >Ericsson/Redback Networks               [phone]
> >> >
> >> >_______________________________________________
> >> >PCN mailing list
> >> >[e-mail]
> >> >https://www.ietf.org/mailman/listinfo/pcn
> >> _______________________________________________
> >> PCN mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/pcn
> >> 
> 
_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn