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

["Georgios Karagiannis" <[e-mail]>]

Hi Anna

What I was trying to say is that we should not mandate to preferential drop
marked packets,
because then the PCN domain operation can become more instable than in the
situations that either 
random dropping of marked and unmmarked packets is used or when unmarked
packets are preferentially dropped.

I think that the method of dropping should not be mandated.

Best regards,
Georgios





> -----Original Message-----
> From: Anna Charny (acharny) [mailto:[e-mail]] 
> Sent: woensdag 19 maart 2008 21:33
> To: Georgios Karagiannis; [e-mail]; 
> [e-mail]
> Cc: [e-mail]
> Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting
> 
> 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