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

[<[e-mail]>]

Michael
Thanks for the detailed review, I've now worked these into the revised
arch draft
phil
> -----Original Message-----
> From: Michael Menth [mailto:[e-mail]]
> Sent: 23 November 2007 10:41
> To: Eardley,PL,Philip,CXR9 R
> Cc: [e-mail]
> Subject: Comments on draft-ietf-pcn-architecture-02.txt
> 
> 
> 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.)

joe made similar comments & have tried for mods in a few places. I
actually left this one as is, as I found it too cumbersome to write
"measure and/or monitor" [and I think "measure" is more inclusive of
"monitor" than vice-versa] . Anyway, your point should be clear to
anyone who gets beyond the intro!

> 
> =====================
> 
> "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/Menth0
7-
> PCN-Config.pdf>",
> 2007.
>

I added a ref to te 2nd. 
 
> =====================
> 
> Terminology

want to avoid discussing /changing terminology, where it's just changing
wording rather than changing meaning.

> 
> =====================
> 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!

Deleted. [by TB you mean upside down VQ; by TB I also imply no memory,
cf VQ with marking threshold =0]

> 
> =====================
> 
> (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.
>
ok
 
> =====================
> 
> 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?
> 
think I've covered these points when dealing with joe's comments. 

> =====================
> 
> 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?

Changed to 'Note' [nb = nota bene]

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

"risk ... may" is equivalent to "possibly"

> 
> =====================
> 
> 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
added

> 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/Menth0
7-
> PCN-Config.pdf>",
> 2007.
added

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