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

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

Hi Georgios,

I must confess that I do not really see the examples you are presenting
as arguments for having (or for that matter not having) preferential
drop that I can understand.  While I may certainly be missing the points
you are making, I want to point out that quite regardless of all these
examples, if all you are trying to achieve is that the standard does not
force a particular preferential drop policy,  I believe the current
proposal already does that, as it has a SHOULD, not a MUST in the
preferential drop clause.  So perhaps that means that this does not need
to be argued so intensely?

On the examples themselves, I also reread your recent emails (and
assuming I understand correctly which of the multiple examples you
actually are referring to in your exchange with Steve and Phil), I
realized that the problem you are referring to may have nothing to do
with dropping marked or unmarked packets.  It has simply to do with a
well-recognized problem of dilution of marking signal received by the
egress in the case when traffic of a given on any particular ECMP path
is drastically smaller than the combined traffic of this IEA on other
(uncongested) ECMP paths.

Let us consider what seems to be a rather aggressive example.  Let us
assume that we have a bottleneck link, and - for the moment- assume it
is the only bottleneck in the network, so in fact there is no marking
occurring anywhere but on this link.  Just using this assumption to
demonstrate that marking preference is irrelevant for the problem you
seem to be referring to.

Suppose now you have an IEA on this link and you have other ECMP paths
shared by this aggregate.  Let us assume that the total amount of
traffic of this IEA on the link of interest is K. Suppose now that the
total traffic on the IEA aggregate is M*K,  and assume that M is large.
I doubt it will ever be more than 16 - so let us take 16 for the moment.

Assume now that the link in question has a very high overload.  I would
assume is 5X overload is quite large (Rudiger I am sure will agree :)),
so let us just take 5.  That means that approximately 80% of traffic of
this IEA is dropped at the input, so we end up having only 0.2K actually
leaving this link.  

Now assume that the admission threshold is set to 80% of your link
(picking a high value to make things worse). And assume we are running
SM - or LC-PCN (or whatever other alg that uses excess marking).  Now
that means that ~20% of our remaining traffic of the IEA aggregate gets
marked. The egress now sees:  0.2*0.2K=0.04K of marked traffic and
(M-1)K+0.2*0.8K unmarked traffic.  The CLE now is now ~0.04K/15K~0.002.
If you need a larger CLE than that, then neither SM, nor, for that
matter, LC-PCN, would trigger admission stop on that aggregate (without
probing added).

As it happens, the CLE setting with which the vast majority of SM
simulations were done was actually 0.001 (less than the above) - so in
fact for this particular set of the parameters (even though I think
quite aggressive)  this would not actually cause SM a problem. 

But obviously if you increase either M to be greater than 16 or the
overload on the link to be even greater than 5 times the links capacity,
you may indeed get into the situation when the actual amount of marked
traffic that gets through to the egress is small compared to the total
rate of other uncongested ECMP paths for this aggregate. While I
personally believe that the parameters I chose are probably overly
conservative and in practice things will look dramatically better -
nevertheless in principle this problem does in fact exist in theory.  In
for sufficiently large overloads and ratio M this problem theoretically
exists even for threshold marking - although you would need even more
aggressive parameters to see the problem then.

The point however is that all of this seems to have little to do with
what you prefer to drop. In particular, in the example above there were
no packets at all that were marked before the bottleneck.  The same
example will remain even if in fact some packets were previously marked,
and all of them were dropped at the entry to the bottleneck.  What
matters is what percentage of the traffic gets through the tightest
bottleneck and how much of it gets marked at *this* bottleneck.  So I
just can't get why all of these examples show the point about
preferential drop you are trying to make...

Anna 








> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Georgios Karagiannis
> Sent: Wednesday, March 19, 2008 12:10 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
> 
> Hi Phil
> 
> But in order to trigger the admission control and flow 
> termination, the situation CLE > 1% has to be first triggered.
> 
> Best regards,
> Georgios
>  
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: woensdag 19 maart 2008 17:07
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> > 
> > Georgios,
> > 
> > I notice you refer to CLE below. Note that for termination the 
> > relevant parameter is the Sustainable rate, that is the rate of 
> > unmarked pkts (or, if SM being used, this rate is multiplied by the 
> > domain-wide parameter U).
> > 
> > phil
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of
> > > Georgios Karagiannis
> > > Sent: 19 March 2008 15:49
> > > To: 'Steven Blake'
> > > Cc: [e-mail]
> > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting
> > > 
> > > Hi Steven
> > > 
> > > Okay, I will have to spend some time on this!
> > > 
> > > Best regards,
> > > Georgios
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Steven Blake [mailto:[e-mail]]
> > > > Sent: woensdag 19 maart 2008 16:43
> > > > To: Georgios Karagiannis
> > > > Cc: [e-mail]
> > > > Subject: RE: [PCN] Concensus questions from Thursday's 
> PCN meeting
> > > >
> > > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote:
> > > >
> > > > > Hi Steven
> > > > >
> > > > > Please see that I have included some information into the
> > > > last bullet:
> > > > >
> > > > > - There is an ingress-egress aggregate whose traffic is
> > > > split across
> > > > > multiple paths via ECMP.
> > > > >  - Traffic is admitted along this split path.
> > > > >  - One (or more) of the paths fails.
> > > > >  - One (or more) of the remaining paths becomes severely
> > > > congested (for
> > > > >    example because there is traffic from other ingress-egress 
> > > > > aggregates flowing along that path).
> > > > > - <<Due to the ECMP routing not congested paths will
> > > > forward packets
> > > > > belonging to
> > > > >   the same ingress-egress-aggregate that will be unmarked.>>
> > Marked
> > > > > packets are
> > > > >   preferentially dropped at the severely congested
> > > > >   router(s). As a consequence, not enough marked 
> traffic arrives
> > at
> > > > > the egress router to drive the CLE for the ingress-egress
> > aggregate
> > > > > above the threshold needed to trigger a response (termination,
> > say).
> > > >
> > > > Ok.  To be specific, the egressrouter  will see some 
> fraction of 
> > > > packets from the severely congested router(s), some of
> > which will be
> > > > marked, and will see a larger fraction of un-marked
> > packets from the
> > > > un-pre-congested routers.
> > > >
> > > > So let me now ask you this: given N ECMP paths (after a path 
> > > > failure), with one being severely congested and the rest being 
> > > > un-pre-congested, and given a CLE threshold CLE_thresh at
> > the egress
> > > > router, can you solve for the minimum PCN_lower_threshold
> > value at
> > > > the severely congested router, where PCN still works (e.g., CLE 
> > > > crosses the threshold), for the two cases where (1)
> > marked packets
> > > > are preferentially dropped, and (2) marked packets are
> > dropped with
> > > > equal probability with un-marked packets?
> > > >
> > > >
> > > >
> > > > 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