[PCN] Comments on draft-ietf-pcn-architecture-02.txt

[Michael Menth <[e-mail]>]

Hi Phil,

here are my comments to the -02 version of the architecture draft.

Regards,

    Michael

=====================

Introduction

"PCN-egress-nodes make measurements of the packet markings and
send information as necessary to the nodes that make the decision
about which PCN-flows to accept/reject or terminate, based on this
information."

[Michael] "PCN-egress nodes monitor the packet markings and ..."
(measurement is not necessarily required, both for admission and
termination.)

=====================

"the admission control mechanism limits the PCN-traffic on each
link to *roughly* its PCN-lower-rate and the flow termination
mechanism limits the PCN-traffic on each link to *roughly* its
PCN-upper-rate."

[Michael] Assuming this sentence is based on agreement, I cannot
refrain from pointing out that texts on PCN are better readable
with terms "admissible rate" and "supportable rate" instead of
PCN-lower-rate and PCN-upper-rate.

=====================

"The PCN-lower-rates can be chosen small enough that admitted
traffic can still be carried after a rerouting in most failure
cases."

[Michael] The general concept of resilient admission control has
been proposed in [Menth04g] and applied to PCN in [PCN-Config]
including algorithms how to set PCN rate thresholds appropriately.

[Menth04g] M. Menth, S. Kopf, and J. Charzinski: "Network
Admission Control for Fault-Tolerant QoS Provisioning" in IEEE
High-Speed Networks for Multimedia Communication (HSNMC), June
2004

[PCN-Config]  M. Menth, and M. Hartmann: "PCN-Based Resilient
Network Admission Control: The Impact of a Single Bit",
<http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth07-PCN-Config.pdf>",
2007.

=====================

Terminology

"o  Excess-rate-marking: a PCN-marking behaviour such that the
amount of PCN-traffic that is PCN-marked is equal to the amount
that exceeds a particular rate (either the PCN-lower-rate or
PCN-upper-rate).  NOTE: The definition reflects the overall intent
rather than its instantaneous behaviour, since the rate measured
at a particular moment depends on the behaviour, its
implementation and the traffic's variance as well as its rate."

[Michael] The term "Excess-rate-marking" implies that exactly the
excess rate is marked. Modifications of this algorithm using e.g.
marking frequency reduction don't deserve this name anymore. This
is different with "Excess-traffic-marking": if all packets
exceeding a particular rate are marked, it's exactly the excess
traffic rate, but the algorithm may also mark fewer packets.

"o  Excess-traffic-marking: a PCN-marking behaviour marking
packets exceeding a particular rate (either the PCN-lower-rate or
PCN-upper-rate). ..."

=====================

"o  Pre-congestion: a condition of a link within a PCN-domain in
which the PCN-node performs PCN-marking, in order to provide an
"early warning" of potential congestion before there is any
significant build-up of PCN-packets in the real queue."

[Michael] Pre-congestion is always connected to a PCN rate
threshold.

"o  X-Pre-congestion: a condition of a link within a PCN-domain in
which the PCN-node performs PCN-marking since the PCN-traffic of
the link has *roughly* exceeded the PCN rate threshold "X" (e.g.
PCN-lower-rate or PCN-upper-rate); it is done to provide an "early
warning" of potential congestion before there is any significant
build-up of PCN-packets in the real queue. When the context is
clear, "X" can be omitted."

=====================
4.1

"However, note that this description reflects the overall intent
of the algorithm rather than its instantaneous behaviour, since
the rate measured at a particular moment depends on the detailed
algorithm, its implementation (eg virtual queue, token bucket...)
and the traffic's variance as well as its rate (eg marking may
well continue after a recent overload even after the instantaneous
rate has dropped)."

[Michael]: virtual queue and token bucket are absolutely
equivalent paradigms on which metering and marking may be based.
see also:
http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt
Just omit the example!

=====================

(Hence, by analogy with ECN we call our mechanism Pre-Congestion
Notification.)

[Michael] This should come earlier in the document. E.g. in the
terminology section.

=====================

5.5

   o  PCN-meter at PCN-egress-node - make "measurements of PCN-traffic"
      from a particular PCN-ingress-node.

[Michael] Could you add "(if required)" to that point? 3sm
http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-01.txt
does not need metering or measurement of marked packets for flow
termination.

=====================


   o  Make decision about flow termination - use the "measurements of
      PCN-traffic" to decide which PCN-flow or PCN-flows to terminate.
      The decision takes account of policy and application layer
      requirements.

[Michael] Similar issue: could you add "possibly" somewhere?

=====================

5.7

   o  NB the order of increasing severity is: unmarked; PCN-marking with
      first encoding (ie associated with the PCN-lower-rate); PCN-
      marking with second encoding (ie associated with the PCN-upper-
      rate)

[Michael] What does "NB" stand for?

=====================
7.2

   o  (if required) Generate probe traffic - the PCN-ingress-node
      generates the probe traffic.  The appropriate number (or rate) of
      probe packets will depend on the PCN-marking algorithm; for
      example an excess-rate-marking algorithm generates fewer PCN-marks
      than a threshold-marking algorithm, and so will need more probe
      packets.

and

7.3

   The open issues associated with this viewpoint include:

   o  What rate and pattern of probe packets does the PCN-ingress-node
      need to generate, so that there's enough traffic to make the
      admission decision?

[Michael] We've done some work on this. See Table 1 in 4.1 of
http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-01.txt

=====================

7.3

   o  Probing adds delay to the admission control process.

   o  Sufficient probing traffic has to be generated to test the pre-
      congestion level of the ingress-egress-aggregate.  But the probing
      traffic itself may cause pre-congestion, causing other PCN-flows
      to be blocked or even terminated - and in the flash crowd scenario
      there will be probing on many ingress-egress-aggregates.

[Michael] Could you add "possibly" please? These statements are
not true for the probing mechanisms in 2.3.2 of
http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-01.txt

=====================

   The downsides of probing for this viewpoint are:

   o  Probing adds delay to the admission control process.

   o  Sufficient probing traffic has to be generated to test the pre-
      congestion level of the ECMP path.  But there's the risk that the
      probing traffic itself may cause pre-congestion, causing other
      PCN-flows to be blocked or even terminated.

[Michael] Could you please add "possibly" to these points?

=====================

Viewpoint 3 or probably extra viewpoint:

[Michael] Probing might be used because it is easier than
measuring and signalling aggregate packet markings. This is the
case when a signalling protocol already exists, e.g., to find out
the correct ingress-egress-aggregate of a flow. Then, this
signalling protocol might be reused for probing purposes saving
complex operations in the egress node and signalling. An example
is given in 2.4 of
http://www.ietf.org/internet-drafts/draft-babiarz-pcn-3sm-01.txt
Also 4.3 of
http://tools.ietf.org/wg/pcn/draft-briscoe-pcn-boundary-behav-00.txt
suggests to use a protocol to find out the right egress node such
that probing would in fact lead to simplifications.

=====================

8.1.2 Parameters

[Michael] A citation to our work on parameter settings would be
appropriate.

[PCN-Config]  M. Menth, and M. Hartmann: "PCN-Based Resilient
Network Admission Control: The Impact of a Single Bit",
<http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth07-PCN-Config.pdf>",
2007.

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: [phone], fax: [phone]
mailto:[e-mail]
http://www3.informatik.uni-wuerzburg.de/research/ngn



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