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

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

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. 

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

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

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?  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. This as 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 :-). 

> 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