Subject: [PCN] Summary of technical points -- PCN WGLC for the CL and SM edge behaviour drafts

From: Tom Taylor <[email-masked]>
Date: Tue, 24 Aug 2010 09:29:53 -0400

It's time I rounded up all the comments and responded to them. Technical 
comments in this E-mail, editorial in the next one. Thanks for the reviews.

1) Phil, 12/07/2010, smoothing of CLE:

Asked whether smoothing of the CLE is now completely done away with. Aside from 
the implicit smoothing due to the fact that the measurements are accumulated 
over an interval, that is correct. Remember that your original concept was a 
packet-by-packet recomputation of the CLE, and in that case smoothing was 
essential. It is no longer necessary.
-----

2) Discussion of an additional thresholding parameter for report suppression 
(16-18/07/2010) (Tom, Toby, Georgios, Michael, Fortune):

Argument on one side was that the difference in signalling traffic between a 
zero and non-zero CLE reporting threshold would be tiny. Argument on the other 
that even so, for the centralized decision point it could be worthwhile. 
Resolution: add the report suppression threshold parameter, default value zero. 
Parameter has effect only if report suppression is activated in the first place.
-----

3) Ruediger, 26/07/2010, concluded 04/08/2010, how to identify an 
ingress-egress-aggregate:

Change the existing text to say this is out of scope of the existing document.
-----

4) Michael's marked-up version, 29/07/2010, reporting of flow identifiers:

Report only the flows that have been excess-marked recently. Agreed.
-----

5) Michael's marked-up version, 29/07/2010, requirement for mapping information 
at the Decision Point:

Indicated that the Decision Point has to know how to map packets received at the 
egress node to individual ingress-egress-aggregates. I don't see why this is so.
-----

6) Michael's marked-up version, 29/07/2010, and follow-up notes (Ruediger, 
Michael, Tom) 20/08/2010, how a system works with PCN-based flow termination but 
no PCN-based flow admission:

Proposed resolution: tighten up the language proposed I proposed to provide a 
clear distinction between PCN-based and non-PCN-based flow admission, as follows:

"If PCN-based flow termination is enabled but PCN-based flow admission is not, 
flow termination operates as specified in this document. Logically, some other 
system of flow admission control is needed to keep new flows from being admitted 
to an ingress-egress-aggregate while flows are being terminated on that 
aggregate, but the operation of such a system is out of scope of this document 
and depends on local arrangements."
-----

Tom Taylor

---

From: Michael Menth <[email-masked]>
Date: Tue, 24 Aug 2010 16:12:42 +0200

Hi Tom,

Am 24.08.2010 15:29, schrieb Tom Taylor:
> It's time I rounded up all the comments and responded to them. 
> Technical comments in this E-mail, editorial in the next one. Thanks 
> for the reviews.
>
> Asked whether smoothing of the CLE is now completely done away with. 
> Aside from the implicit smoothing due to the fact that the 
> measurements are accumulated over an interval, that is correct. 
> Remember that your original concept was a packet-by-packet 
> recomputation of the CLE, and in that case smoothing was essential. It 
> is no longer necessary.
> -----
>
> 2) Discussion of an additional thresholding parameter for report 
> suppression (16-18/07/2010) (Tom, Toby, Georgios, Michael, Fortune):
>
> Argument on one side was that the difference in signalling traffic 
> between a zero and non-zero CLE reporting threshold would be tiny. 
> Argument on the other that even so, for the centralized decision point 
> it could be worthwhile. Resolution: add the report suppression 
> threshold parameter, default value zero. Parameter has effect only if 
> report suppression is activated in the first place.
> -----
>
> 5) Michael's marked-up version, 29/07/2010, requirement for mapping 
> information at the Decision Point:
>
> Indicated that the Decision Point has to know how to map packets 
> received at the egress node to individual ingress-egress-aggregates. I 
> don't see why this is so.

o The information needed to map PCN-packets received by the 
PCN-egress-node to the correct ingress-egress-aggregate.

Of course this text does not belong to the parameters of the decision 
point but to the parameters of the egress node. The egress node needs to 
know how to map the packets to IEAs. The proposed text is somewhat 
clearer than what's in the draft so far:

o The information needed to distinguish PCN traffic belonging to a

given ingress-egress-aggregate.

HTH,

     Michael

> -----
>
> 6) Michael's marked-up version, 29/07/2010, and follow-up notes 
> (Ruediger, Michael, Tom) 20/08/2010, how a system works with PCN-based 
> flow termination but no PCN-based flow admission:
>
> Proposed resolution: tighten up the language proposed I proposed to 
> provide a clear distinction between PCN-based and non-PCN-based flow 
> admission, as follows:
>
> "If PCN-based flow termination is enabled but PCN-based flow admission 
> is not, flow termination operates as specified in this document. 
> Logically, some other system of flow admission control is needed to 
> keep new flows from being admitted to an ingress-egress-aggregate 
> while flows are being terminated on that aggregate, but the operation 
> of such a system is out of scope of this document and depends on local 
> arrangements."
> -----
>
> Tom Taylor
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

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