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

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 06 Aug 2008 14:45:06 +0000

Dear all

Hein Mekkes presented the results of a number of experiments associated
with the performance of the LC-PCN trunk and HOSE models. From the
conclusions of these experiments it could be derived that the LC-PCN
algorithm operates well. According to the consensus that was obtained
after the IETF 71 and since evidence was provided regarding the LC-PCN
performance we would very much appreciate if the following will be
considered by the PCN working group:

* preferential dropping of marked packets should be an option. Also other
types of preferentila dropping of packets should be allowed. Such as
random dropping and/or preferential dropping of unmarked packets.

* support the option that marked excess rate represents high levels of
excess rate. This can be implemented by marking every N-th packet (or
bute)instad of marking each packet (or byte). N is a constant that is
equal or higher than 1.

* support option to allow the use of PCN-Affected-Marking encoding and
the related PCN-Affecte-Marking functionalities in order to support the
ECMP routing issue and the HOSE model.

Best regards,
Georgios
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Wed, 6 Aug 2008 16:50:07 +0100

Georgios,

I think you are over-stating the conclusions of your experiments. They
seemed to be work in progress; for example, no confidence intervals were
associated with the results (since each point represented one run only)
and no experiments to explain/analyse the differences with the
simulations results that others have done (Joy/Anna, Joe etc). There
didn't seem to be results specifically about preferential dropping,
marked flow reduction or affected marking. 

Hence the conclusion was that there wasn't evidence to change the
previous consensus ie:

- excess-traffic-marked PCN-packets SHOULD be preferentially dropped.
rfc2119: SHOULD means "that there may exist valid reasons in particular
circumstances to ignore a particular item, but the full implications
must be understood and carefully weighed before choosing a different
course."
- marking every Nth pkt is not supported. The equivalent functionality
can be achieved by appropriate edge behaviour, as in the EMFT draft ie
terminating marked flows with some random probability
- there's consensus on the baseline encoding draft. Experimental
extension encoding draft(s) are TBD. So Affected marking is not
precluded, and also edge behaviour involving it is possible. 

Best wishes
Phil/

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ Georgios Karagiannis
{ Sent: 06 August 2008 15:45
{ To: [email-masked]; [email-masked]
{ Cc: [email-masked]; [email-masked]
{ Subject: [PCN] regarding lc-pcn features and consensus
{ 
{ Dear all
{ 
{ Hein Mekkes presented the results of a number of experiments
associated
{ with the performance of the LC-PCN trunk and HOSE models. From the
{ conclusions of these experiments it could be derived that the LC-PCN
{ algorithm operates well. According to the consensus that was obtained
{ after the IETF 71 and since evidence was provided regarding the LC-PCN
{ performance we would very much appreciate if the following will be
{ considered by the PCN working group:
{ 
{ * preferential dropping of marked packets should be an option. Also
other
{ types of preferentila dropping of packets should be allowed. Such as
{ random dropping and/or preferential dropping of unmarked packets.
{ 
{ * support the option that marked excess rate represents high levels of
{ excess rate. This can be implemented by marking every N-th packet (or
{ bute)instad of marking each packet (or byte). N is a constant that is
{ equal or higher than 1.
{ 
{ * support option to allow the use of PCN-Affected-Marking encoding and
{ the related PCN-Affecte-Marking functionalities in order to support
the
{ ECMP routing issue and the HOSE model.
{ 
{ Best regards,
{ Georgios
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 18 Aug 2008 16:36:12 +0200

Hallo Phil

I agree that confidence intervals are not shown. However, the LC-PCN results
are shown in a similar way as
the SM results presented in the SM draft. 

Please note that the shown results for LC-PCN for trunk and HOSE models 
are not worse than the SM results. 

>From what you mentioned I can conclude that:
Thus random preferential dropping and preferential dropping of unmarked
traffic in not precluded.

> - there's consensus on the baseline encoding draft. 
> Experimental extension encoding draft(s) are TBD. So Affected 
> marking is not precluded, and also edge behaviour involving 
> it is possible. 
Thus the use of Affected Marking and the use of other types of edge
behaviour 
encoding is not precluded.

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

Best regards,
Georgios

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: woensdag 6 augustus 2008 17:50
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [PCN] regarding lc-pcn features and consensus
> 
> Georgios,
> 
> I think you are over-stating the conclusions of your 
> experiments. They seemed to be work in progress; for example, 
> no confidence intervals were associated with the results 
> (since each point represented one run only) and no 
> experiments to explain/analyse the differences with the 
> simulations results that others have done (Joy/Anna, Joe 
> etc). There didn't seem to be results specifically about 
> preferential dropping, marked flow reduction or affected marking. 
> 
> Hence the conclusion was that there wasn't evidence to change 
> the previous consensus ie:
> 
> rfc2119: SHOULD means "that there may exist valid reasons in 
> particular circumstances to ignore a particular item, but the 
> full implications must be understood and carefully weighed 
> before choosing a different course."
> - marking every Nth pkt is not supported. The equivalent 
> functionality can be achieved by appropriate edge behaviour, 
> as in the EMFT draft ie terminating marked flows with some 
> random probability
> - there's consensus on the baseline encoding draft. 
> Experimental extension encoding draft(s) are TBD. So Affected 
> marking is not precluded, and also edge behaviour involving 
> it is possible. 
> 
> Best wishes
> Phil/
> 
> { From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of { Georgios Karagiannis { Sent: 06 August 2008 15:45 
> { To: [email-masked]; [email-masked] { Cc: 
> [email-masked]; [email-masked] { 
> Subject: [PCN] regarding lc-pcn features and consensus { { 
> Dear all { { Hein Mekkes presented the results of a number of 
> experiments associated { with the performance of the LC-PCN 
> trunk and HOSE models. From the { conclusions of these 
> experiments it could be derived that the LC-PCN { algorithm 
> operates well. According to the consensus that was obtained { 
> after the IETF 71 and since evidence was provided regarding 
> the LC-PCN { performance we would very much appreciate if the 
> following will be { considered by the PCN working group:
> {
> { * preferential dropping of marked packets should be an 
> option. Also other { types of preferentila dropping of 
> packets should be allowed. Such as { random dropping and/or 
> preferential dropping of unmarked packets.
> {
> { * support the option that marked excess rate represents 
> high levels of { excess rate. This can be implemented by 
> marking every N-th packet (or { bute)instad of marking each 
> packet (or byte). N is a constant that is { equal or higher than 1.
> {
> { * support option to allow the use of PCN-Affected-Marking 
> encoding and { the related PCN-Affecte-Marking 
> functionalities in order to support the { ECMP routing issue 
> and the HOSE model.
> {
> { Best regards,
> { Georgios

---

From: <[email-masked]>
Date: Mon, 18 Aug 2008 16:04:13 +0100

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 19 Aug 2008 10:11:06 +0200

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

> Sent: maandag 18 augustus 2008 17:04
> { 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 
> 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.
> - 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. 
>

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 09:55:05 +0100

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:[email-masked]]
{ Sent: 19 August 2008 09:11
{ To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
{ Cc: [email-masked]; [email-masked]
{ 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: [email-masked] [mailto:[email-masked]]
{ > Sent: maandag 18 augustus 2008 17:04
{ > To: [email-masked]; [email-masked]; [email-masked]
{ > Cc: [email-masked]; [email-masked]
{ > 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
{ >
{

---

From: Michael Menth <[email-masked]>
Date: Tue, 19 Aug 2008 11:07:36 +0200

Hi,

we've done simulations on marked flow termination (MFT) with packet loss 
and reported them in IV.D.4 of
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-MFT.pdf
They show that packet loss with MFT is no problem at all as long as 
marked packets are not preferentially dropped.
PCN traffic rate: 16 Mbit/s, bottleneck capacity 9 Mbit/s with 
supportable rate 8 Mbit/s. This is a loss rate of 43.75%.
Experiments with even higher loss rates are not covered in the paper 
because this seemed not very realistic to us, but experiments have shown 
that there are no problems either. It takes a bit longer, but it works.

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 19 Aug 2008 11:33:55 +0200

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

> Sent: dinsdag 19 augustus 2008 10:55
> 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/ 
> 
> { Sent: 19 August 2008 09:11 { To: Eardley,PL,Philip,CXR9 R; 
> [email-masked]; [email-masked] { Cc: 
> 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 {  
> {  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
> {
> {
> {
> {
> {
> { > From: [email-masked] 
> [mailto:[email-masked]] { > Sent: maandag 18 augustus 
> 2008 17:04 { > To: [email-masked]; 
> [email-masked]; [email-masked] { > Cc: 
> [email-masked]; [email-masked] { > 
> Subject: RE: [PCN] regarding lc-pcn features and consensus { 
> { > { 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 { > 
> { > 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 { > 
> { > 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.
> { >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 19 Aug 2008 11:45:47 +0200

Hi Michael

The pointed issue was related to fact that the recovery time it will be too
high (more than 1 - 2 seconds)
for the situation that very high losses occur (more than 100% of the
capacity of the link).

Best regards,
Georgios

> From: Michael Menth [mailto:[email-masked]] 
> Sent: dinsdag 19 augustus 2008 11:08
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [PCN] regarding lc-pcn features and consensus
> 
> Hi,
> 
> we've done simulations on marked flow termination (MFT) with 
> packet loss and reported them in IV.D.4 of 
> They show that packet loss with MFT is no problem at all as 
> long as marked packets are not preferentially dropped.
> PCN traffic rate: 16 Mbit/s, bottleneck capacity 9 Mbit/s 
> with supportable rate 8 Mbit/s. This is a loss rate of 43.75%.
> Experiments with even higher loss rates are not covered in 
> the paper because this seemed not very realistic to us, but 
> experiments have shown that there are no problems either. It 
> takes a bit longer, but it works.
> 
> Regards,
> 
>     Michael
> 
> 
> > 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.
> >
> saturation 
> > when it starts becoming important (eg link to the right 
> mail - sorry 
> > my memory for old discussions is often bad!).
> >
> > Thanks
> > Phil/
> >
> > { From: Georgios Karagiannis 
> [mailto:[email-masked]] { Sent: 
> > 19 August 2008 09:11 { To: Eardley,PL,Philip,CXR9 R; 
> [email-masked]; 
> > [email-masked] { 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 
> > 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
> > {
> > {
> > {
> > {
> > {
> > { > From: [email-masked] [mailto:[email-masked]] { > 
> > Sent: maandag 18 augustus 2008 17:04 { > To: 
> [email-masked]; 
> Subject: RE: 
> > [PCN] regarding lc-pcn features and consensus { > { > { > - marking 
> > every Nth pkt is not supported.
> > { > { Without this option the LC-PCN algorithm will become very { > 
> > slow { in situations of high overloads that are above the { 
> capacity 
> > of a link.
> > { > {
> 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
> > { >
> { > several 
> > months ago, which led to the draft { > 
> > 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 { > 
> University of Wuerzburg, Institute of Computer Science Am 
> Hubland, D-97074 Wuerzburg, Germany, room B206

---

From: Michael Menth <[email-masked]>
Date: Tue, 19 Aug 2008 11:55:52 +0200

Hi Georgios,

traffic loss can never go beyond 100%. In our setting, approximatley 
half of the traffic was lost, i.e. PCN traffic was twice the line rate. 
It works fine and terminates in spite of extreme packet loss within 1.5 
s. This comprises the time meters and markers require to detect SR-overload.

Regards,

    Michael

Georgios Karagiannis wrote:
>> http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicatio
>>     
> ns/Menth08-PCN-MFT.pdf
>   
>>> effect. Question is whether it's important in practice. 
>>>       
>> Please can you 
>>     
>>> point me to the earlier comparative analysis / simulations 
>>>       
>> that shows 
>>     
>>> {  cannot achieve the same behaviour as the algorithm that 
>>>       
>> is marking 
>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 19 Aug 2008 12:02:48 +0200

Hi Michael

Traffic loss can go above 100% when e.g., a link with capacity higher than C
fails 
and its traffic is rerouted through a link with capacity C, which is fully 
utilised before the re-route takes place.

Best regards,
Georgios

> Sent: dinsdag 19 augustus 2008 11:56
> To: Georgios Karagiannis
> Cc: [email-masked]; [email-masked]; 
> traffic loss can never go beyond 100%. In our setting, 
> approximatley half of the traffic was lost, i.e. PCN traffic 
> was twice the line rate. 
> It works fine and terminates in spite of extreme packet loss 
> within 1.5 s. This comprises the time meters and markers 
> require to detect SR-overload.
> 
> Regards,
> 
>     Michael
> 
> > The pointed issue was related to fact that the recovery 
> time it will 
> > be too high (more than 1 - 2 seconds) for the situation 
> that very high 
> > losses occur (more than 100% of the capacity of the link).
> >
> > Best regards,
> > Georgios
> >
> >
> >  
> >
> >   
> >> Cc: [email-masked]; [email-masked]; [email-masked]; 
> >> [email-masked]; [email-masked]
> >> we've done simulations on marked flow termination (MFT) 
> with packet 
> >> loss and reported them in IV.D.4 of 
> the paper 
> >> because this seemed not very realistic to us, but experiments have 
> >> shown that there are no problems either. It takes a bit 
> longer, but 
> >> it works.
> >>
> >> Regards,
> >>
> >>     Michael
> >>
> >>
> { > N-th 
> >>> termination. The original suggestion was to do this by { 
> > marking 
> unnecessary { > 
> >> Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> >> Institute of Computer Science Am Hubland, D-97074 
> Wuerzburg, Germany, 
> >> room B206

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 11:25:23 +0100

Georgios

I notice you avoided my question " Please can you point me to the
earlier comparative 
> 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:[email-masked]]
{ Sent: 19 August 2008 10:34
{ To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
{ Cc: [email-masked]; [email-masked]
{ 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: [email-masked] [mailto:[email-masked]]
{ > Sent: dinsdag 19 augustus 2008 10:55
{ > To: [email-masked]; [email-masked]; [email-masked]
{ > Cc: [email-masked]; [email-masked]
{ > 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:[email-masked]]
{ > { Sent: 19 August 2008 09:11 { To: Eardley,PL,Philip,CXR9 R;
{ > [email-masked]; [email-masked] { Cc:
{ > [email-masked]; [email-masked] {
{ > 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: [email-masked]
{ > [mailto:[email-masked]] { > Sent: maandag 18 augustus
{ > 2008 17:04 { > To: [email-masked];
{ > [email-masked]; [email-masked] { > Cc:
{ > [email-masked]; [email-masked] { >
{ > 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
{ > { >
{ > {
{ >
{

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 19 Aug 2008 13:42:10 +0200

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

> Sent: dinsdag 19 augustus 2008 12:25
> I notice you avoided my question " Please can you point me to 
> the earlier comparative 
> > analysis / simulations that shows when it starts becoming important"
> Anyway, Michael's simulations seem to show that the problem 
> is not big enough to worry about. 
> 
> Thanks
> phil
> 
> { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; 
> { 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
> {
> {
> {
> {
> [mailto:[email-masked]] { > Sent: dinsdag 19 augustus 
> 2008 10:55 { > To: [email-masked]; 
> > { > 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 { > 
> { > 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/
> { >
> { > { From: Georgios Karagiannis 
> [mailto:[email-masked]] { > { Sent: 19 August 2008 
> 09:11 { To: Eardley,PL,Philip,CXR9 R; { > 
> { > [email-masked]; [email-masked] { { 
> 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 { { > 
> { > {  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 { 
> { > [mailto:[email-masked]] { > Sent: maandag 18 
> augustus { > 2008 17:04 { > To: [email-masked]; { > 
> { > 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 { > 
> { > { 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 { 
> { > { > We had quite some discussion between a couple of 
> IETFs { { > > several months ago, which led to the draft { > 
> { > { > This came out of the desire to achieve marked flow { 
> { > { > 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 { > 
> { > { > Hence marking every Nth pkt was shown to be an { > 
> { > to eliminate (all other things { > being equal) since it 
> adds { > complexity to the marking { > algorithm and is 
> another { > parameter to configure.
> { > { >

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 13:57:27 +0100

In the absence of evidence, which was anyway due by the last ietf, I see
no justification for any change to the consensus decision reached by the
WG & re-confirmed at the last ietf.

Best wishes
Phil

{ -----Original Message-----
{ From: Georgios Karagiannis [mailto:[email-masked]]
{ Sent: 19 August 2008 12:42
{ To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
{ Cc: [email-masked]; [email-masked]
{ 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: [email-masked] [mailto:[email-masked]]
{ > Sent: dinsdag 19 augustus 2008 12:25
{ > To: [email-masked]; [email-masked]; [email-masked]
{ > Cc: [email-masked]; [email-masked]
{ > 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:[email-masked]]
{ > { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R;
{ > [email-masked]; [email-masked] { Cc:
{ > [email-masked]; [email-masked] {
{ > 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: [email-masked]
{ > [mailto:[email-masked]] { > Sent: dinsdag 19 augustus
{ > 2008 10:55 { > To: [email-masked];
{ > [email-masked]; [email-masked] { > Cc:
{ > [email-masked]; [email-masked] { >
{ > 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:[email-masked]] { > { Sent: 19 August 2008
{ > 09:11 { To: Eardley,PL,Philip,CXR9 R; { >
{ > [email-masked]; [email-masked] { Cc:
{ > { > [email-masked]; [email-masked] { {
{ > 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: [email-masked]
{ > { > [mailto:[email-masked]] { > Sent: maandag 18
{ > augustus { > 2008 17:04 { > To: [email-masked]; { >
{ > [email-masked]; [email-masked] { > Cc:
{ > { > [email-masked]; [email-masked] { >
{ > { > 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
{ > { > { >
{ > { > {
{ > { >
{ > {
{ >
{

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 19 Aug 2008 15:03:45 +0200

Hi Phil

This is an additional evidence request from you!

Best regards,
Georgios

> Sent: dinsdag 19 augustus 2008 14:57
> In the absence of evidence, which was anyway due by the last 
> ietf, I see no justification for any change to the consensus 
> decision reached by the WG & re-confirmed at the last ietf.
> 
> Best wishes
> Phil
> 
> { Sent: 19 August 2008 12:42 { To: Eardley,PL,Philip,CXR9 R; 
> { 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
> {
> {
> {
> 2008 12:25 { > To: [email-masked]; 
> > { > Georgios { > { > I notice you avoided my question " 
> Please can you point me to { > the earlier comparative { > > 
> { > Anyway, Michael's simulations seem to show that the 
> problem { > is not big enough to worry about.
> { >
> { > Thanks
> { > phil
> { >
> 10:34 { To: Eardley,PL,Philip,CXR9 R; { > 
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 { 
> { > [mailto:[email-masked]] { > Sent: dinsdag 19 
> augustus { > 2008 10:55 { > To: [email-masked]; { > 
> 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/
> { > { >
> { > [mailto:[email-masked]] { > { Sent: 19 August 
> 2008 { > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > 
> { > { > [email-masked]; [email-masked] 
> { { { > 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 { { > { > 
> { > 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
> { > { > {
> { > { > {
> { > { > {
> { > { > {
> { > { > {
> { > { > [mailto:[email-masked]] { > Sent: maandag 18 { 
> augustus { > 2008 17:04 { > To: [email-masked]; { > > { >
[email-masked]; [email-masked] { > Cc:
> { > { > [email-masked]; [email-masked] 
> { > { > { > Subject: RE: [PCN] regarding lc-pcn features and 
> { > { > { > { 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
> { > { > { > {
> { > { > { > { 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
> { > { > { >
> { > IETFs { { > > several months ago, which led to the draft 
> { > { > { > 
> { > { > { > 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.
> { > { > { >

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 14:47:48 +0100

???????
it's you who needs to provide evidence for any change!!!!!!!

{ -----Original Message-----
{ From: Georgios Karagiannis [mailto:[email-masked]]
{ Sent: 19 August 2008 14:04
{ To: Eardley,PL,Philip,CXR9 R; [email-masked]; [email-masked]
{ Cc: [email-masked]; [email-masked]
{ Subject: RE: [PCN] regarding lc-pcn features and consensus
{ 
{ Hi Phil
{ 
{ This is an additional evidence request from you!
{ 
{ Best regards,
{ Georgios
{ 
{ 
{ 
{ > -----Original Message-----
{ > From: [email-masked] [mailto:[email-masked]]
{ > Sent: dinsdag 19 augustus 2008 14:57
{ > To: [email-masked]; [email-masked]; [email-masked]
{ > Cc: [email-masked]; [email-masked]
{ > Subject: RE: [PCN] regarding lc-pcn features and consensus
{ >
{ > In the absence of evidence, which was anyway due by the last
{ > ietf, I see no justification for any change to the consensus
{ > decision reached by the WG & re-confirmed at the last ietf.
{ >
{ > Best wishes
{ > Phil
{ >
{ > { -----Original Message-----
{ > { From: Georgios Karagiannis [mailto:[email-masked]]
{ > { Sent: 19 August 2008 12:42 { To: Eardley,PL,Philip,CXR9 R;
{ > [email-masked]; [email-masked] { Cc:
{ > [email-masked]; [email-masked] {
{ > 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: [email-masked]
{ > [mailto:[email-masked]] { > Sent: dinsdag 19 augustus
{ > 2008 12:25 { > To: [email-masked];
{ > [email-masked]; [email-masked] { > Cc:
{ > [email-masked]; [email-masked] { >
{ > 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:[email-masked]] { > { Sent: 19 August 2008
{ > 10:34 { To: Eardley,PL,Philip,CXR9 R; { >
{ > [email-masked]; [email-masked] { Cc:
{ > { > [email-masked]; [email-masked] { {
{ > 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: [email-masked]
{ > { > [mailto:[email-masked]] { > Sent: dinsdag 19
{ > augustus { > 2008 10:55 { > To: [email-masked]; { >
{ > [email-masked]; [email-masked] { > Cc:
{ > { > [email-masked]; [email-masked] { >
{ > { > 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:[email-masked]] { > { Sent: 19 August
{ > 2008 { > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { >
{ > [email-masked]; [email-masked] { Cc:
{ > { > { > [email-masked]; [email-masked]
{ > { { { > 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: [email-masked]
{ > { > { > [mailto:[email-masked]] { > Sent: maandag 18 {
{ > augustus { > 2008 17:04 { > To: [email-masked]; { > > { >
{ [email-masked]; [email-masked] { > Cc:
{ > { > { > [email-masked]; [email-masked]
{ > { > { > { > 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
{ > { > { > { >
{ > { > { > {
{ > { > { >
{ > { > {
{ > { >
{ > {
{ >
{

---

From: "Hein Mekkes" <[email-masked]>
Date: Mon, 25 Aug 2008 18:29:57 +0200

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Georgios Karagiannis
> Sent: dinsdag 19 augustus 2008 13:42
> To: [email-masked]; [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Tue, 26 Aug 2008 10:36:03 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Hein
{ Mekkes
{ Sent: 25 August 2008 17:30
{ To: [email-masked]
{ 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: [email-masked] [mailto:[email-masked]] On Behalf
Of
{ > Georgios Karagiannis
{ > Sent: dinsdag 19 augustus 2008 13:42
{ > To: [email-masked]; [email-masked]; [email-masked]
{ > Cc: [email-masked]; [email-masked]
{ > 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: [email-masked] [mailto:[email-masked]]
{ > > Sent: dinsdag 19 augustus 2008 12:25
{ > > To: [email-masked]; [email-masked]; [email-masked]
{ > > Cc: [email-masked]; [email-masked]
{ > > 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:[email-masked]]
{ > > { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R;
{ > > [email-masked]; [email-masked] { Cc:
{ > > [email-masked]; [email-masked] {
{ > > 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: [email-masked]
{ > > [mailto:[email-masked]] { > Sent: dinsdag 19 augustus
{ > > 2008 10:55 { > To: [email-masked];
{ > > [email-masked]; [email-masked] { > Cc:
{ > > [email-masked]; [email-masked] { >
{ > > 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:[email-masked]] { > { Sent: 19 August 2008
{ > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { >
{ > > [email-masked]; [email-masked] { Cc:
{ > > { > [email-masked]; [email-masked] { {
{ > > 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: [email-masked]
{ > > { > [mailto:[email-masked]] { > Sent: maandag 18
{ > > augustus { > 2008 17:04 { > To: [email-masked]; { >
{ > > [email-masked]; [email-masked] { > Cc:
{ > > { > [email-masked]; [email-masked] { >
{ > > { > 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
{ > [email-masked]
{ > https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: "Hein Mekkes" <[email-masked]>
Date: Tue, 26 Aug 2008 12:57:08 +0200

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

> Sent: dinsdag 26 augustus 2008 11:36
> To: [email-masked]; [email-masked]
> { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > {
> >
> {
> { > Hi

---

From: Michael Menth <[email-masked]>
Date: Tue, 26 Aug 2008 13:24:42 +0200

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

---

From: <[email-masked]>
Date: Tue, 26 Aug 2008 13:12:29 +0100

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: [email-masked] [mailto:[email-masked]]
{ > Sent: dinsdag 26 augustus 2008 11:36
{ > To: [email-masked]; [email-masked]
{ > 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: [email-masked] [mailto:[email-masked]] On Behalf
Of
{ > Hein
{ > { Mekkes
{ > { Sent: 25 August 2008 17:30
{ > { To: [email-masked]
{ > { 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: [email-masked] [mailto:[email-masked]] On
Behalf
{ > Of
{ > { > Georgios Karagiannis
{ > { > Sent: dinsdag 19 augustus 2008 13:42
{ > { > To: [email-masked]; [email-masked]; [email-masked]
{ > { > Cc: [email-masked]; [email-masked]
{ > { > 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: [email-masked] [mailto:[email-masked]]
{ > { > > Sent: dinsdag 19 augustus 2008 12:25
{ > { > > To: [email-masked]; [email-masked];
[email-masked]
{ > { > > Cc: [email-masked]; [email-masked]
{ > { > > 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:[email-masked]]
{ > { > > { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R;
{ > { > > [email-masked]; [email-masked] { Cc:
{ > { > > [email-masked]; [email-masked] {
{ > { > > 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: [email-masked]
{ > { > > [mailto:[email-masked]] { > Sent: dinsdag 19 augustus
{ > { > > 2008 10:55 { > To: [email-masked];
{ > { > > [email-masked]; [email-masked] { > Cc:
{ > { > > [email-masked]; [email-masked] { >
{ > { > > 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:[email-masked]] { > { Sent: 19 August 2008
{ > { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { >
{ > { > > [email-masked]; [email-masked] { Cc:
{ > { > > { > [email-masked]; [email-masked] { {
{ > { > > 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: [email-masked]
{ > { > > { > [mailto:[email-masked]] { > Sent: maandag 18
{ > { > > augustus { > 2008 17:04 { > To: [email-masked]; { >
{ > { > > [email-masked]; [email-masked] { > Cc:
{ > { > > { > [email-masked]; [email-masked] { >
{ > { > > { > 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
{ > { > [email-masked]
{ > { > https://www.ietf.org/mailman/listinfo/pcn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Aug 2008 16:34:29 +0200

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

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: dinsdag 26 augustus 2008 14:12
> { 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.
> {
> { 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
> {
> {
> [mailto:[email-masked]] { > Sent: dinsdag 26 augustus 
> 2008 11:36 { > To: [email-masked]; [email-masked] { > 
> > { > Hein { > { > Couple of quick questions { > { > - what 
> does N=1 mean? I thought it meant marking every Nth pkt & { > 
> { > { From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of { > Hein { > { 
> Mekkes { > { Sent: 25 August 2008 17:30 { > { To: 
> [email-masked] { > { 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.
> { > {
> { > { 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
> { > { 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.
> { > {
> { > { 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
> { > {
> { > {
> { > { > From: [email-masked] 
> [mailto:[email-masked]] On Behalf { > Of { > { > 
> Georgios Karagiannis { > { > Sent: dinsdag 19 augustus 2008 
> 13:42 { > { > To: [email-masked]; 
> [email-masked]; [email-masked] { > { > Cc: 
> [email-masked]; [email-masked] { > { > 
> 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
> { > { >
> { > { >
> { > { >
> { > { > > From: [email-masked] 
> [mailto:[email-masked]] { > { > > Sent: dinsdag 19 
> augustus 2008 12:25 { > { > > To: [email-masked]; 
> [email-masked]; [email-masked] { > { > > Cc: 
> [email-masked]; [email-masked] { > { > 
> { > { > > { > { > > 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
> { > { > >
> { > { > > { From: Georgios Karagiannis 
> [mailto:[email-masked]] { > { > > { Sent: 19 August 
> 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; { > { > > 
> { > { > > [email-masked]; 
> [email-masked] { { > { > > 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.
> { > { > > {
> { > { > > { > -----Original Message----- { > { > > { > From: 
> [email-masked] { > { > > 
> { > { > > 2008 10:55 { > To: [email-masked]; { > { > 
> { > { > > [email-masked]; 
> [email-masked] { > { > { > > 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 { > { > 
> { > { > > 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 - { > { > > 
> { > { > > { > { -----Original Message----- { > { > > { > { 
> From: Georgios Karagiannis { > { > > 
> [mailto:[email-masked]] { > { Sent: 19 August 2008 { 
> > { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > { > > 
> { > { > > { > [email-masked]; 
> [email-masked] { { { > { > > 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 { { > { 
> { > { > > { > {  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.
> { > { > > { > {
> { > { > > { > { > -----Original Message----- { > { > > { > { 
> > From: [email-masked] { > { > > { > 
> [mailto:[email-masked]] { > Sent: maandag 18 { > { > > 
> augustus { > 2008 17:04 { > To: [email-masked]; { > { 
> { > { > > { > [email-masked]; 
> [email-masked] { > { > { > > { > 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.
> { > { > > { > { > 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 { > { > > 
> { > { > > { > { > I believe this gives you the system 
> behaviour you want.
> { > { > > { > { >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Aug 2008 16:49:22 +0200

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

> Behalf Of Michael Menth
> Sent: dinsdag 26 augustus 2008 13:25
> To: Hein Mekkes
> Cc: [email-masked]
> 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
> >
> >
> >   
> >> { From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Hein { Mekkes { Sent: 25 August 2008 17:30 { To: [email-masked] { 
> { { 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.
> >> {
> >> { 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
> >> { Graph 1 shows the situation where N = 1 is used and 
> Graph 2 shows 
> >> the { situation where N = 2 is used.
> >> {
> >> equal { to { +/- 1500 ms, while when N = 2 the recovery 
> time is +/- 
> >> 300 ms.
> >> {
> >> { 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
> >> {
> >> {
> >> { > From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of { > Georgios Karagiannis { > Sent: dinsdag 19 
> augustus 2008 
> >> 13:42 { > To: [email-masked]; [email-masked]; 
> >> [email-masked] { > Cc: [email-masked]; 
> >> [email-masked] { > 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.
> >> { > 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
> >> { >
> >> { >
> >> { >
> >> { > > From: [email-masked] 
> [mailto:[email-masked]] { > 
> >> > Sent: dinsdag 19 augustus 2008 12:25 { > > To: 
> >> [email-masked]; [email-masked]; [email-masked] { > > 
> >> Cc: [email-masked]; [email-masked] { > > 
> >> > 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"
> >> { > > Anyway, Michael's simulations seem to show that the 
> problem { > 
> >> { > > { From: Georgios Karagiannis 
> [mailto:[email-masked]] { 
> >> > > { Sent: 19 August 2008 10:34 { To: 
> Eardley,PL,Philip,CXR9 R; { > 
> >> { > > [email-masked]; 
> [email-masked] { { > > 
> { { > > { 
> >> Hi Phil { { Yes I am refering to the situation that you are { > > 
> >> mentioning.
> >> { > > { Please note that in severe congestion situations the { > > 
> 100% { > > 
> >> { > > { 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
> >> { > > {
> >> { > > {
> >> { > > {
> >> { > > {
> >> { > > { > From: [email-masked] { > > 
> >> [mailto:[email-masked]] { > Sent: dinsdag 19 augustus { > > 
> >> 2008 10:55 { > To: [email-masked]; { > > 
> >> { > > [email-masked]; 
> [email-masked] { > { > > 
> { { > > > 
> >> { > 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) 
> >> { > > { > 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 - { > > 
> >> { > > { > { -----Original Message----- { > > { > { From: Georgios 
> >> Karagiannis { > > [mailto:[email-masked]] { > { Sent: 19 
> >> August 2008 { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > > 
> >> { > > { > [email-masked]; 
> [email-masked] { { { 
> >> > > 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 { 
> { > { > > 
> >> { > > { > {  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 { { > > 
> >> { > > { > { > -----Original Message----- { > > { > { > From: 
> >> [email-masked] { > > { > [mailto:[email-masked]] { > 
> >> Sent: maandag 18 { > > augustus { > 2008 17:04 { > To: 
> >> [email-masked]; { > { > > [email-masked]; 
> >> [email-masked] { > Cc:
> >> { > > { > [email-masked]; 
> [email-masked] { > { 
> >> > > { > Subject: RE: [PCN] regarding lc-pcn features and { > > 
> >> { > > { > { > { Thus you mean that the option of marking 
> every Nth { 
> >> > > pkt { > is precluded.
> >> { > > { > { > { Without this option the LC-PCN algorithm 
> will { > > 
> { > > that 
> >> are { > above the { > capacity of a link.
> >> { > > { > { > {
> >> { > > { > { > { Therefore, we would very much appreciate 
> if an { > { 
> >> > > experimental { > extesion of { this { feature will be 
> allowed { > 
> >> 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 { { > 
> >> { > > { > { > We had quite some discussion between a 
> couple of { > > 
> >> IETFs { { > > several months ago, which led to the draft { 
> { > > { 
> >> 00.txt
> >> { > > { > { > This came out of the desire to achieve 
> marked flow { { 
> >> > { > { > marking every Nth pkt. However, it was realised 
> that { > > 
> >> this { > { > could be achieved by marking every pkt, but 
> then { > > 
> { > > 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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Aug 2008 17:26:07 +0200

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

> Sent: dinsdag 26 augustus 2008 17:16
> To: Georgios Karagiannis
> Cc: 'Hein Mekkes'; [email-masked]
> I am referring to page 3 of
> 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
> 
> 
> > 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
> >
> >
> >  
> >
> >   
> >> Michael Menth
> 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,
> >>>
> >>>> { From these graphs can be seen that the recovery time
> >>>>         
> >> when N = 1 is
> >>     
> >>>> { In the second set of experiments an overload of 250% is
> >>>>         
> >> simulated.
> >>     
> >>>> {
> >>>> { > However, if you expect to see simulation results on
> >>>>         
> >> this matter I
> >>     
> >> problem { >
> >>>> { > > { > -----Original Message----- { > > { > From: 
> >>>> [email-masked] { > > [mailto:[email-masked]] { > 
> >>>> Sent: dinsdag 19 augustus { > >
> >>>>>>> { > termination. The original suggestion was to do
> >>>>>>>               
> >> this by { >
> >>     
> >>>> it terminates { > that { > flow with a probability of { 
> > > 1/N). 
> >> exactly the same
> { another { 
> >>>> { > > { > { > I believe this gives you the system
> >>>>         
> >> behaviour you want.
> >>     
> >>>> { > > { > { >

---

From: Michael Menth <[email-masked]>
Date: Tue, 26 Aug 2008 17:38:12 +0200

Hi Georgios,

>> preferentially dropped as you propose.
What's the answer to that question?

Regards,

    Michael

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Aug 2008 17:42:56 +0200

Hi Michael

The answer is:

Traffic to be terminated = 
Received PCN_marked rate * N - configured_termination_rate_egress

The configured_termination_rate_egress is calculated as is given below.

Best regards,
Georgios

> Sent: dinsdag 26 augustus 2008 17:38
> To: Georgios Karagiannis
> packet loss 
> >> and in particular if unmarked packets are preferentially 
> dropped as 
> >> you propose.
> >>

---

From: Michael Menth <[email-masked]>
Date: Tue, 26 Aug 2008 17:44:59 +0200

Hi Georgios,

that means, overtermination can occur because the 
configured_termination_rate_egress is possibly underestimated if 
unmarked packets are preferentially dropped. True? You'll see that in 
simulations only if the overload starts at the beginning of the 
measurment interval.

Regards,

    Michael

---

From: Michael Menth <[email-masked]>
Date: Tue, 26 Aug 2008 17:16:26 +0200

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 26 Aug 2008 17:50:01 +0200

Hi Michael

As I mentioned in the simulations experiments, 
random dropping was used. The situation of preferentially dropping unmarked
packets was not tested, 
since random dropping works fine.

Best regards,
Georgios 

> Sent: dinsdag 26 augustus 2008 17:45
> To: Georgios Karagiannis
> configured_termination_rate_egress is possibly underestimated 
> if unmarked packets are preferentially dropped. True? You'll 
> see that in simulations only if the overload starts at the 
> beginning of the measurment interval.
> 
> Regards,
> 
>     Michael
>

---

From: Michael Menth <[email-masked]>
Date: Tue, 26 Aug 2008 17:55:32 +0200

Hi Georgios,

ok, that's what I thought. From my point of view, your method requires 
preferential dropping of unmarked packets to be faster than other 
methods and in this case it is prone to overtermination. You should 
check that! BTW, that was the reason why we stopped working on this 
mechanism.

Regards,

    Michael

Georgios Karagiannis wrote:
>>> The configured_termination_rate_egress is calculated as is 
>>>       
>> given below.
>>     
>>> Best regards,
>>> Georgios
>>>
>>>
>>>   
>>>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Aug 2008 09:47:40 +0200

Hi Michael

It is not true what you are saying. The LC-PCN algorithm is at the moment
optimized to work for 
random dropping and it works for all situations of overprovisioning., as it
has been shown very fast.

Best regards,
Georgios

> Sent: dinsdag 26 augustus 2008 17:56
> To: Georgios Karagiannis
> ok, that's what I thought. From my point of view, your method 
> requires preferential dropping of unmarked packets to be 
> faster than other methods and in this case it is prone to 
> overtermination. You should check that! BTW, that was the 
> reason why we stopped working on this mechanism.
> 
> Regards,
> 
>     Michael
> 
> > As I mentioned in the simulations experiments, random dropping was 
> > used. The situation of preferentially dropping unmarked packets was 
> > not tested, since random dropping works fine.
> >
> > Best regards,
> > Georgios
> >
> >

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 27 Aug 2008 09:56:06 +0200

Hi Micahel

I meant in all situations of overload:
> It is not true what you are saying. The LC-PCN algorithm is 
> at the moment optimized to work for random dropping and it 
> > works for all situations of overload, as it has been 
> shown very fast.
> 
> Best regards,
> Georgios

> Behalf Of Georgios Karagiannis
> Sent: woensdag 27 augustus 2008 9:48
> To: [email-masked]
> Cc: [email-masked]
> It is not true what you are saying. The LC-PCN algorithm is 
> at the moment optimized to work for random dropping and it 
> works for all situations of overprovisioning., as it has been 
> shown very fast.
> 
> Best regards,
> Georgios
> 
> 
> 
> 
>