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

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

Hi Phil

Please note that the achieved consensus in IETF Dublin was not refering to
the EMFT solution.
Thus I do not understand what you mean here!

As mentioned the LC-PCN solution is used in the experiments. 

N works in the following way. 

At the interior:
The SM excess rate marking solution is used with the difference that:
* the variable N is used: the marked excess rate is equal to (measured
excess rate)/N
  In SM, N = 1. Note that if the excess rate is higher than the capacity of
the link and N = 1
  then the the marked excess rate that will be sent towards the egress 
  cannot represent the measured excess rate, since in this case the measured
excess rate 
  is higher than the capacity of the link. A marked excess rate higher than
the capacity of the link cannot travel up to
  the egress. This is the problem that has been shown in the simulatiuon
experiments.
  This problem is solved by the using the equation: (marked excess rate) =
(measured excess rate)/N
  
* Affected Marking encoding is used to provide ECMP support

At the egress:
The LC-PCN solution is used, where the bandwidth to be terminated is
calculated by:
Bandidth to be terminated = marked rate * N. This is needed to balance the
marked excess rate 
equation used at the interior node.

When N is chosen properly then the total excess rate value can be propagated
to the egress immediately, 
since (marked excess rate) =  (measured excess rate)/N  and the total value
of the marked excess rate is not 
higher than the capacity of the link.
Therefore, the recovery time in this case is faster than 
the situation where N = 1.

Best regards,
Georgios





  

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of [e-mail]
> Sent: dinsdag 26 augustus 2008 14:12
> To: [e-mail]; [e-mail]
> Subject: Re: [PCN] regarding lc-pcn features and consensus
> 
> Thanks Hein,
> {
> { We have not done a comparison with EMFT since this was not 
> the goal of the { experiments.
> 
> This is unfortunate. The work to date (analysis & 
> simulations) has shown that the EMFT approach is just as good 
> as the 'marking every Nth pkt'
> approach. So we need evidence that demonstrates to what 
> extent and in what circumstances this becomes untrue. Only if 
> this evidence shows a significant concern do I see any reason 
> to re-visit our consensus decision.
> 
> Also, a side comment: Earlier discussion also seemed to show 
> that if speed of termination is your most important 
> criterion, then you should choose CL rather than EMFT /marked flow.
> 
> {
> { 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.
> 
> Sorry, I don't understand. N=1 means every pkt is marked. And 
> the edge behaviour is to discard every marked pkt. So N=1 
> maximises the speed of termination. Yet your results seem to 
> show the opposite.
> 
> phil
> {
> { 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
> 


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