Re: [PCN] regarding lc-pcn features and consensus

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

Hi Michael

Regarding the total load:
When affected marking encoding is used then:
Total load = PCN_marked rate + Affected marked rate

When affected marked is not used:
Total load = PCN_marked rate + unmarked rate.

Please also note that for the used experiments the standard random dropping
of packets 
is used and not the preferential dropping of
unmarked packets.

Best regards,
Georgios




> -----Original Message-----
> From: Michael Menth [mailto:[e-mail]] 
> Sent: dinsdag 26 augustus 2008 17:16
> To: Georgios Karagiannis
> Cc: 'Hein Mekkes'; [e-mail]
> Subject: Re: [PCN] regarding lc-pcn features and consensus
> 
> Hi Georgios,
> 
> I am referring to page 3 of
> http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf
> What is "total_load"? The rate of marked and unmarked pcn 
> traffic received by the egress node? Or is it something else?
> How much traffic is terminated if (u-1)*(unmarked rate - 
> ((N-1)*PCN_marked rate)) <= 0? This can happen in case of 
> packet loss and in particular if unmarked packets are 
> preferentially dropped as you propose.
> 
> Regards,
> 
>     Michael
> 
> 
> Georgios Karagiannis wrote:
> > Hi Michael
> >
> > Please see the slides that were presented by Hein during the IETF 
> > meeting in
> > Dublin:
> > http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf
> >
> > The excess marking works based on the admissible rate for admission 
> > control and on the configured termination rate for flow termination.
> >
> > Please also note that the used trigger to activate the flow 
> > termination at the egress is:
> >
> > IF {[PCN_marked rate/ total rate) > U -1] OR [at least one 
> > Affected_Marked packet arrived)} THEN egress goes to flow 
> termination 
> > state.
> >
> > Note that when Affected marking is used then Total rate = 
> PCN_marked 
> > rate + affected_marked rate
> >
> > Best regards,
> > Georgios
> >
> >
> >  
> >
> >   
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of 
> >> Michael Menth
> >> Sent: dinsdag 26 augustus 2008 13:25
> >> To: Hein Mekkes
> >> Cc: [e-mail]
> >> Subject: Re: [PCN] regarding lc-pcn features and consensus
> >>
> >> Hi Hein,
> >>
> >> when I was looking at lc-pcn method, I found that it works 
> only when 
> >> excess marking is used based on the supportable rate. It does not 
> >> work for excess marking based on the admissible rate 
> because then the 
> >> egress node must determine the edge-to-edge supportable rate per 
> >> ingress-egress aggregate using the rate of unmarked packets 
> >> multiplied by u.
> >> In case of packet loss (and no preferential dropping of marked 
> >> packets), this rate is underestimated which then leads to 
> >> overtermination. Thus, this method is only applicable in case of 
> >> excess marking based on the supportable rate. Is that true?
> >>
> >> Regards,
> >>
> >>     Michael
> >>
> >> Hein Mekkes wrote:
> >>     
> >>> Hi Phil,
> >>>
> >>> We have not done a comparison with EMFT since this was not
> >>>       
> >> the goal of
> >>     
> >>> the experiments.
> >>>
> >>> We tried to show that using different values than N = 1 
> is useful, 
> >>> since in many cases it provides a decrease in recovery time
> >>>       
> >> of up to 5 times.
> >>     
> >>> This is evidence that shows that a different
> >>>       
> >> proportionality than N =
> >>     
> >>> 1 on marking bytes and measured excess bytes is very 
> useful. The SM 
> >>> draft supports only the N = 1 proportionality between 
> marking bytes 
> >>> and measured excess bytes.
> >>>
> >>> Hein
> >>>
> >>>
> >>>   
> >>>       
> >>>> -----Original Message-----
> >>>> From: [e-mail] [mailto:[e-mail]]
> >>>> Sent: dinsdag 26 augustus 2008 11:36
> >>>> To: [e-mail]; [e-mail]
> >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus
> >>>>
> >>>> Hein
> >>>>
> >>>> Couple of quick questions
> >>>>
> >>>> - what does N=1 mean? I thought it meant marking every Nth pkt & 
> >>>> terminating every flow. But this doesn't seem to make sense?
> >>>> - have you done the comparison with the EMFT method?
> >>>>
> >>>> thanks
> >>>> phil
> >>>>
> >>>> { -----Original Message-----
> >>>> { From: [e-mail] [mailto:[e-mail]]
> >>>>         
> >> On Behalf
> >>     
> >>>> Of Hein { Mekkes { Sent: 25 August 2008 17:30 { To: 
> [e-mail] {
> >>>> Subject: Re: [PCN] regarding lc-pcn features and consensus
> >>>>         
> >> { { Dear
> >>     
> >>>> all { { We had done some simulation experiments to
> >>>>         
> >> emphasize the need
> >>     
> >>>> of using the { variable N in situations where the overload
> >>>>         
> >> is higher
> >>     
> >>>> than 100% of the { capacity of a link.
> >>>> {
> >>>> { Two sets of experiments are used.
> >>>> {
> >>>> { In those experiments the single bottleneck topology with 10 
> >>>> ingresses is { used, see the SM draft for more details.
> >>>>         
> >> The used RTT
> >>     
> >>>> (on an unloaded { network) is set to be 4 ms. The capcity of the 
> >>>> botleneck link is 45 Mbs.
> >>>> { The
> >>>> { flows are generating CBR traffic, with a holding time of
> >>>>         
> >> 1 minute.
> >>     
> >>>> The
> >>>> { used
> >>>> { solution is LC-PCN trunk (using ingress-egress-aggregates).
> >>>> {
> >>>> { In the first set of experiments an overload of 180% is 
> simulated.
> >>>> {
> >>>> { Graphs 1 and 2 show the results of the first set of 
> experiments.
> >>>> { Graph 1 shows the situation where N = 1 is used and
> >>>>         
> >> Graph 2 shows
> >>     
> >>>> the { situation where N = 2 is used.
> >>>> {
> >>>> { From these graphs can be seen that the recovery time
> >>>>         
> >> when N = 1 is
> >>     
> >>>> equal { to { +/- 1500 ms, while when N = 2 the recovery
> >>>>         
> >> time is +/-
> >>     
> >>>> 300 ms.
> >>>> {
> >>>> { In the second set of experiments an overload of 250% is
> >>>>         
> >> simulated.
> >>     
> >>>> {
> >>>> { Graphs 3 and 4 show the results of the second set of 
> experiments.
> >>>> { Graph 3 shows the situation where N = 1 is used and
> >>>>         
> >> Graph 4 shows
> >>     
> >>>> the { situation where N = 3 is used.
> >>>> {
> >>>> { From this graph can be seen that the recovery time 
> when N = 1 is 
> >>>> equal to { +/- 1500 ms, while when N = 3 the recovery time
> >>>>         
> >> is +/- 400
> >>     
> >>>> ms.
> >>>> {
> >>>> { From these graphs can be seen that by using the 
> required N value 
> >>>> the { recovery time can be decreased with a factor of up
> >>>>         
> >> to 5 times.
> >>     
> >>>> {
> >>>> { Kind regards,
> >>>> { Hein
> >>>> {
> >>>> {
> >>>> { > -----Original Message-----
> >>>> { > From: [e-mail] [mailto:[e-mail]] On 
> >>>> Behalf Of { > Georgios Karagiannis { > Sent: dinsdag 19
> >>>>         
> >> augustus 2008
> >>     
> >>>> 13:42 { > To: [e-mail]; [e-mail]; 
> >>>> [e-mail] { > Cc: [e-mail]; 
> >>>> [e-mail] { > Subject: Re: [PCN] 
> regarding lc-pcn 
> >>>> features and consensus { > { > Hi Phil { > { > Specific 
> simulation 
> >>>> results on the PCN context on the question that you { >
> >>>>         
> >> had { > I do
> >>     
> >>>> not have.
> >>>> { > However, if you expect to see simulation results on
> >>>>         
> >> this matter I
> >>     
> >>>> { > expect { > that these results { > should be shown by Michael 
> >>>> since you are in favour of adopting that { > solution.
> >>>> { > Michael mentioned already that results associated with the 
> >>>> dicussed { > case { > were not presented yet.
> >>>> { >
> >>>> { > Best regards,
> >>>> { > Georgios
> >>>> { >
> >>>> { >
> >>>> { >
> >>>> { > > -----Original Message-----
> >>>> { > > From: [e-mail]
> >>>>         
> >> [mailto:[e-mail]] { >
> >>     
> >>>>> Sent: dinsdag 19 augustus 2008 12:25 { > > To: 
> >>>>>           
> >>>> [e-mail]; [e-mail]; 
> [e-mail] { > >
> >>>> Cc: [e-mail]; [e-mail] { > >
> >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus
> >>>>         
> >> { > > { >
> >>     
> >>>>> Georgios { > > { > > I notice you avoided my question " 
> >>>>>           
> >> Please can
> >>     
> >>>> you point me to { > > the earlier comparative { > > > analysis / 
> >>>> simulations that shows when it starts becoming { > important"
> >>>> { > > so I assume you have haven't done comparative analysis / 
> >>>> simulations?
> >>>> { > > Anyway, Michael's simulations seem to show that the
> >>>>         
> >> problem { >
> >>     
> >>>>> is not big enough to worry about.
> >>>>>           
> >>>> { > >
> >>>> { > > Thanks
> >>>> { > > phil
> >>>> { > >
> >>>> { > > { -----Original Message-----
> >>>> { > > { From: Georgios Karagiannis
> >>>>         
> >> [mailto:[e-mail]] {
> >>     
> >>>>>> { Sent: 19 August 2008 10:34 { To: 
> >>>>>>             
> >> Eardley,PL,Philip,CXR9 R; { >
> >>     
> >>>>> [e-mail]; [e-mail] { Cc:
> >>>>>           
> >>>> { > > [e-mail];
> >>>>         
> >> [e-mail] { { > >
> >>     
> >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus
> >>>>         
> >> { { > > {
> >>     
> >>>> Hi Phil { { Yes I am refering to the situation that you 
> are { > > 
> >>>> mentioning.
> >>>> { > > { Please note that in severe congestion situations 
> the { > > 
> >>>> overload can easily { and { most of the times { go above
> >>>>         
> >> 100% { > >
> >>     
> >>>> of the capacity of the link.
> >>>> { > > {
> >>>> { > > { The mentioned issues were pointed out during 
> Michael { > > 
> >>>> presentation (IETF { 71) { by Anna and by me. I am not
> >>>>         
> >> sure { > > if
> >>     
> >>>> they were included in the PCN minutes { of { IETF 71.
> >>>> { > > {
> >>>> { > > { Best regards,
> >>>> { > > { Georgios
> >>>> { > > {
> >>>> { > > {
> >>>> { > > {
> >>>> { > > {
> >>>> { > > { > -----Original Message----- { > > { > From: 
> >>>> [e-mail] { > > [mailto:[e-mail]] { > 
> >>>> Sent: dinsdag 19 augustus { > >
> >>>> 2008 10:55 { > To: [e-mail]; { > > 
> >>>> [e-mail]; [e-mail] { > Cc:
> >>>> { > > [e-mail];
> >>>>         
> >> [e-mail] { > { > >
> >>     
> >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus
> >>>>         
> >> { { > > >
> >>     
> >>>> { > Hi Georgios { > { > i think what you're referring to { > > 
> >>>> (please correct) is that if { > the interior node is { > >
> >>>>         
> >> massively
> >>     
> >>>> overloaded, then you're saying { > that the I-D's { > > approach 
> >>>> might terminate slower, essentially { > because of a { > >
> >>>>         
> >> saturation
> >>     
> >>>> effect (you can't have more than 100% { > marked { > > pkts) - 
> >>>> whereas this saturation effect doesn't appear { > { > >
> >>>>         
> >> until (much)
> >>     
> >>>> higher loads with the 'marking every Nth pkt'
> >>>> { > > algorithm.
> >>>> { > > { >
> >>>> { > > { > Sure, at first glance I can believe there's a
> >>>>         
> >> theoretical {
> >>     
> >>>>>> { > saturation effect. Question is whether it's
> >>>>>>             
> >> important in { >
> >>     
> >>>>> { > practice. Please can you point me to the earlier { > >
> >>>>>           
> >>>> comparative { > analysis / simulations that shows when it { > > 
> >>>> starts becoming { > important (eg link to the right mail - { > > 
> >>>> sorry my memory for { > old discussions is often bad!).
> >>>> { > > { >
> >>>> { > > { > Thanks
> >>>> { > > { > Phil/
> >>>> { > > { >
> >>>> { > > { > { -----Original Message----- { > > { > { From: 
> Georgios 
> >>>> Karagiannis { > > [mailto:[e-mail]] { > { Sent: 19 
> >>>> August 2008 { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; 
> { > { > > 
> >>>> [e-mail]; [e-mail] { Cc:
> >>>> { > > { > [e-mail];
> >>>>         
> >> [e-mail] { { {
> >>     
> >>>>>> Subject: RE: [PCN] regarding lc-pcn features and
> >>>>>>             
> >> consensus { > {
> >>     
> >>>>     
> >>>> {
> >>>> { > Hi
> >>>> { > Phil { { At the time I have checked this draft and I 
> { > > { > 
> >>>> have also followed the { presentation given by Michael { >
> >>>>         
> >>> during {
> >>>       
> >>>>> the { IETF 71. From the discussions that we have { > >
> >>>>>           
> >> had then, I
> >>     
> >>>> { > did realise that { the { algorithm provided { > > in {
> >>>>         
> >> { > { > >
> >>     
> >>>> http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt
> >>>> { > > { > {  cannot achieve the same behaviour as the
> >>>>         
> >> algorithm { > >
> >>     
> >>>> that is { > marking every { N-th packet { when the
> >>>>         
> >> percentage { > >
> >>     
> >>>> of overload { > in an interior node is higher than 100% 
> of { { > > 
> >>>> the capacity of the link.
> >>>> { > > { > {
> >>>> { > > { > { Best regards,
> >>>> { > > { > { Georgios
> >>>> { > > { > {
> >>>> { > > { > {
> >>>> { > > { > {
> >>>> { > > { > {
> >>>> { > > { > {
> >>>> { > > { > { > -----Original Message----- { > > { > { > From: 
> >>>> [e-mail] { > > { > 
> [mailto:[e-mail]] { >
> >>>> Sent: maandag 18 { > > augustus { > 2008 17:04 { > To: 
> >>>> [e-mail]; { > { > > [e-mail]; 
> >>>> [e-mail] { > Cc:
> >>>> { > > { > [e-mail];
> >>>>         
> >> [e-mail] { > {
> >>     
> >>>>>> { > Subject: RE: [PCN] regarding lc-pcn features and { > >
> >>>>>>             
> >>>> consensus { { > > { > { > - marking every Nth pkt is not 
> supported.
> >>>> { > > { > { > { Thus you mean that the option of marking
> >>>>         
> >> every Nth {
> >>     
> >>>>>> pkt { > is precluded.
> >>>>>>             
> >>>> { > > { > { > { Without this option the LC-PCN algorithm
> >>>>         
> >> will { > >
> >>     
> >>>> become { > very { > slow { in situations of high overloads
> >>>>         
> >> { > > that
> >>     
> >>>> are { > above the { > capacity of a link.
> >>>> { > > { > { > {
> >>>> { > > { > { > { Therefore, we would very much appreciate
> >>>>         
> >> if an { > {
> >>     
> >>>>>> experimental { > extesion of { this { feature will be
> >>>>>>             
> >> allowed { >
> >>     
> >>>>> { > { to support the { > option that marked excess rate
> >>>>>           
> >> { > { > >
> >>     
> >>>> represents { high levels of { { > excess rate). This can
> >>>>         
> >> be { { > >
> >>     
> >>>> implemented by  marking every { { > N-th packet (or { { > > { > 
> >>>> byte)instead { { > of marking each packet (or { > byte). N
> >>>>         
> >> is a { { >
> >>     
> >>>>>> constant that is { equal or { higher { than 1.
> >>>>>>             
> >>>> { > > { > { >
> >>>> { > > { > { > Georgios
> >>>> { > > { > { >
> >>>> { > > { > { > We had quite some discussion between a
> >>>>         
> >> couple of { > >
> >>     
> >>>> IETFs { { > > several months ago, which led to the draft {
> >>>>         
> >> { > > {
> >>     
> >>>>> http://www.watersprings.org/pub/id/draft-menth-pcn-emft-
> >>>>>           
> >>>> 00.txt
> >>>> { > > { > { >
> >>>> { > > { > { > This came out of the desire to achieve
> >>>>         
> >> marked flow { {
> >>     
> >>>>>>> { > termination. The original suggestion was to do
> >>>>>>>               
> >> this by { >
> >>     
> >>>>> { > { > marking every Nth pkt. However, it was realised
> >>>>>           
> >> that { > >
> >>     
> >>>> this { > { > could be achieved by marking every pkt, but
> >>>>         
> >> then { > >
> >>     
> >>>> altering the { > { > edge behaviour (every time it sees a
> >>>>         
> >> { > > pkt,
> >>     
> >>>> it terminates { > that { > flow with a probability of { 
> > > 1/N). 
> >>>> This was shown by { > simulation (see { > i-d) and { > > 
> analysis 
> >>>> (see email I sent to { > list) to achieve { > { > >
> >>>>         
> >> exactly the same
> >>     
> >>>> behaviour.
> >>>> { > > { > { > Hence marking every Nth pkt was shown to be
> >>>>         
> >> an { > { >
> >>     
> >>>>> unnecessary { > complication { > - it's clearly a good
> >>>>>           
> >> thing { > >
> >>     
> >>>> { > to eliminate (all other things { > being equal) 
> since it { > > 
> >>>> adds { > complexity to the marking { > algorithm and is 
> { another { 
> >>>> > parameter to configure.
> >>>> { > > { > { >
> >>>> { > > { > { > I believe this gives you the system
> >>>>         
> >> behaviour you want.
> >>     
> >>>> { > > { > { >
> >>>> { > > { > { > Best wishes
> >>>> { > > { > { > phil
> >>>> { > > { > { >
> >>>> { > > { > {
> >>>> { > > { >
> >>>> { > > {
> >>>> { > >
> >>>> { >
> >>>> { >
> >>>> { > _______________________________________________
> >>>> { > PCN mailing list
> >>>> { > [e-mail]
> >>>> { > https://www.ietf.org/mailman/listinfo/pcn
> >>>>     
> >>>>         
> >>> _______________________________________________
> >>> PCN mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/pcn
> >>>   
> >>>       
> >> --
> >> Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> >> Institute of Computer Science Am Hubland, D-97074 
> Wuerzburg, Germany, 
> >> room B206
> >> phone: [phone], fax: [phone] 
> >> mailto:[e-mail]
> >> http://www3.informatik.uni-wuerzburg.de/research/ngn
> >>
> >> _______________________________________________
> >> PCN mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/pcn
> >>
> >>     
> 
> --
> Dr. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: [phone], fax: [phone] 
> mailto:[e-mail]
> http://www3.informatik.uni-wuerzburg.de/research/ngn
> 


_______________________________________________
PCN mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pcn