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

[<[e-mail]>]

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

{ -----Original Message-----
{ From: Georgios Karagiannis [mailto:[e-mail]]
{ Sent: 19 August 2008 14:04
{ To: Eardley,PL,Philip,CXR9 R; [e-mail]; [e-mail]
{ Cc: [e-mail]; [e-mail]
{ Subject: RE: [PCN] regarding lc-pcn features and consensus
{ 
{ Hi Phil
{ 
{ This is an additional evidence request from you!
{ 
{ Best regards,
{ Georgios
{ 
{ 
{ 
{ > -----Original Message-----
{ > From: [e-mail] [mailto:[e-mail]]
{ > Sent: dinsdag 19 augustus 2008 14:57
{ > To: [e-mail]; [e-mail]; [e-mail]
{ > Cc: [e-mail]; [e-mail]
{ > 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:[e-mail]]
{ > { Sent: 19 August 2008 12:42 { To: Eardley,PL,Philip,CXR9 R;
{ > [e-mail]; [e-mail] { Cc:
{ > [e-mail]; [e-mail] {
{ > Subject: RE: [PCN] regarding lc-pcn features and consensus {
{ > { Hi Phil { { Specific simulation results on the PCN context
{ > on the question that you { had { I do not have.
{ > { However, if you expect to see simulation results on this
{ > matter I expect { that these results { should be shown by
{ > Michael since you are in favour of adopting that { solution.
{ > { Michael mentioned already that results associated with the
{ > dicussed case { were not presented yet.
{ > {
{ > { Best regards,
{ > { Georgios
{ > {
{ > {
{ > {
{ > { > -----Original Message-----
{ > { > From: [e-mail]
{ > [mailto:[e-mail]] { > Sent: dinsdag 19 augustus
{ > 2008 12:25 { > To: [e-mail];
{ > [e-mail]; [e-mail] { > Cc:
{ > [e-mail]; [e-mail] { >
{ > Subject: RE: [PCN] regarding lc-pcn features and consensus {
{ > > { > Georgios { > { > I notice you avoided my question "
{ > Please can you point me to { > the earlier comparative { > >
{ > analysis / simulations that shows when it starts becoming important"
{ > { > so I assume you have haven't done comparative analysis /
{ > simulations?
{ > { > Anyway, Michael's simulations seem to show that the
{ > problem { > is not big enough to worry about.
{ > { >
{ > { > Thanks
{ > { > phil
{ > { >
{ > { > { -----Original Message-----
{ > { > { From: Georgios Karagiannis
{ > [mailto:[e-mail]] { > { Sent: 19 August 2008
{ > 10:34 { To: Eardley,PL,Philip,CXR9 R; { >
{ > [e-mail]; [e-mail] { Cc:
{ > { > [e-mail]; [e-mail] { {
{ > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > {
Hi
{ Phil { { Yes I am refering to the situation that you
{ > are { > mentioning.
{ > { > { Please note that in severe congestion situations the {
{ > > overload can easily { and { most of the times { go above
{ > 100% { > of the capacity of the link.
{ > { > {
{ > { > { The mentioned issues were pointed out during Michael {
{ > > presentation (IETF { 71) { by Anna and by me. I am not sure
{ > { > if they were included in the PCN minutes { of { IETF 71.
{ > { > {
{ > { > { Best regards,
{ > { > { Georgios
{ > { > {
{ > { > {
{ > { > {
{ > { > {
{ > { > { > -----Original Message-----
{ > { > { > From: [e-mail]
{ > { > [mailto:[e-mail]] { > Sent: dinsdag 19
{ > augustus { > 2008 10:55 { > To: [e-mail]; { >
{ > [e-mail]; [e-mail] { > Cc:
{ > { > [e-mail]; [e-mail] { >
{ > { > Subject: RE: [PCN] regarding lc-pcn features and
{ > consensus { { > > { > Hi Georgios { > { > i think what you're
{ > referring to { > (please correct) is that if { > the interior
{ > node is { > massively overloaded, then you're saying { > that
{ > the I-D's { > approach might terminate slower, essentially {
{ > > because of a { > saturation effect (you can't have more
{ > than 100% { > marked { > pkts) - whereas this saturation
{ > effect doesn't appear { > { > until (much) higher loads with
{ > the 'marking every Nth pkt'
{ > { > algorithm.
{ > { > { >
{ > { > { > Sure, at first glance I can believe there's a
{ > theoretical { > { > saturation effect. Question is whether
{ > it's important in { > { > practice. Please can you point me
{ > to the earlier { > comparative { > analysis / simulations
{ > that shows when it { > starts becoming { > important (eg link
{ > to the right mail - { > sorry my memory for { > old
{ > discussions is often bad!).
{ > { > { >
{ > { > { > Thanks
{ > { > { > Phil/
{ > { > { >
{ > { > { > { -----Original Message-----
{ > { > { > { From: Georgios Karagiannis
{ > { > [mailto:[e-mail]] { > { Sent: 19 August
{ > 2008 { > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { >
{ > [e-mail]; [e-mail] { Cc:
{ > { > { > [e-mail]; [e-mail]
{ > { { { > Subject: RE: [PCN] regarding lc-pcn features and
{ > consensus { > { > { Hi { Phil { { At the time I have checked
{ > this draft and I { > { > have also followed the {
{ > presentation given by Michael { > during { > the { IETF 71.
{ > From the discussions that we have { > had then, I { > did
{ > realise that { the { algorithm provided { > in { { > { >
{ > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt
{ > { > { > {  cannot achieve the same behaviour as the algorithm
{ > { > that is { > marking every { N-th packet { when the
{ > percentage { > of overload { > in an interior node is higher
{ > than 100% of { { > the capacity of the link.
{ > { > { > {
{ > { > { > { Best regards,
{ > { > { > { Georgios
{ > { > { > {
{ > { > { > {
{ > { > { > {
{ > { > { > {
{ > { > { > {
{ > { > { > { > -----Original Message-----
{ > { > { > { > From: [e-mail]
{ > { > { > [mailto:[e-mail]] { > Sent: maandag 18 {
{ > augustus { > 2008 17:04 { > To: [e-mail]; { > > { >
{ [e-mail]; [e-mail] { > Cc:
{ > { > { > [e-mail]; [e-mail]
{ > { > { > { > Subject: RE: [PCN] regarding lc-pcn features and
{ > { > consensus { { > > { > { > - marking every Nth pkt is not
{ > supported.
{ > { > { > { > { Thus you mean that the option of marking every
{ > Nth { > pkt { > is precluded.
{ > { > { > { > { Without this option the LC-PCN algorithm will {
{ > become { > very { > slow { in situations of high overloads { > >
that
{ are
{ { > above the { > capacity of a link.
{ > { > { > { > {
{ > { > { > { > { Therefore, we would very much appreciate if an
{ > { > { > experimental { > extesion of { this { feature will be
{ > allowed { > { > { to support the { > option that marked
{ > excess rate { > { > represents { high levels of { { > excess
{ > rate). This can be { { > implemented by  marking every { { >
{ > N-th packet (or { { > > byte)instead { { { of marking each
{ > packet (or { > byte). N is a { { > > constant that is { equal
{ > or { higher { than 1.
{ > { > { > { >
{ > { > { > { > Georgios
{ > { > { > { >
{ > { > { > { > We had quite some discussion between a couple of
{ > { > IETFs { { > > several months ago, which led to the draft
{ > { > { > { >
{ > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt
{ > { > { > { >
{ > { > { > { > This came out of the desire to achieve marked
{ > flow { { > > { > termination. The original suggestion was to
{ > do this by { > { > { > marking every Nth pkt. However, it was
{ > realised that { > this { > { > could be achieved by marking
{ > every pkt, but then { > altering the { > { > edge behaviour
{ > (every time it sees a { > pkt, it terminates { > that { >
{ > flow with a probability of { > 1/N). This was shown by { >
{ > simulation (see { > i-d) and { > analysis (see email I sent
{ > to { > list) to achieve { > { > exactly the same behaviour.
{ > { > { > { > Hence marking every Nth pkt was shown to be an {
{ > > { > unnecessary { > complication { > - it's clearly a good
{ > thing { > { > to eliminate (all other things { > being equal)
{ > since it { > adds { > complexity to the marking { > algorithm
{ > and is { > another { > parameter to configure.
{ > { > { > { >
{ > { > { > { > I believe this gives you the system behaviour you want.
{ > { > { > { >
{ > { > { > { > Best wishes
{ > { > { > { > phil
{ > { > { > { >
{ > { > { > {
{ > { > { >
{ > { > {
{ > { >
{ > {
{ >
{ 

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