Subject: [PCN] more PCN comments on architecture draft

From: <[email-masked]>
Date: Wed, 24 Oct 2007 12:57:54 +0100

Bob gave me some hand-written comments on the architecture draft => here
are the changes I suggest. I think they're non-controversial (possible
exception: the terminology tweak, since terminology is always
controversial!). I think they're most self-explanatory, but please shout
if they need explanation /discussion, or indeed are wrong.

Thanks,

phil

-          Benefits: clarified the "Admission control is resilient"
bullet by adding the last phrase to the following sentence: <PCN's QoS
is decoupled from the routing system; hence in general admitted flows
can survive capacity, routing or topology changes without additional
signalling, and they don't have to be told (or learn) about such
changes.>

-          Benefits: clarified that the objective is also to stop
PCN-packets being significantly delayed (current text only mentions not
dropping pkts)

-          Benefits: added a new bullet: <Provisioning of the network is
decoupled from the process of adding new customers. By contrast, with
the DiffServ architecture [RFC2475] the operator has to run the
provisioning process each time a new customer is added to check that the
Service Level Agreement can be fulfilled.  >

-          added another deployment scenario: <If the operator runs both
the access network and the core network, one deployment scenario is that
only the core network uses PCN admission control but per microflow
policing is done at the ingress to the access network and not at the
PCN-ingress-node. Note: to aid readability, the rest of this draft
assumes that policing is done by the PCN-ingress-nodes.>

-          MPLS deployment model: corrected reference to MPLS-TE to say
MPLS

-     Terminology: PCN-domain: the current definition ("a PCN-capable
DiffServ domain; a contiguous set of PCN-enabled DiffServ nodes.")
doesn't work very well (eg adjacent PCN-domains consist of a contiguous
set of PCN-nodes). Suggesting the following definition: <PCN-domain: a
PCN-capable domain; a contiguous set of PCN-enabled nodes that perform
DiffServ scheduling; the compete set of PCN-nodes whose PCN-marking can
in principle influence decisions about flow admission and termination
for the PCN-domain, including the PCN-egress-nodes which measure these
PCN-marks.>

-     S3.2: assumption 2: added the following 1st sentence as a
clarification. <We assume that any variation of source bit rate is
independent of the level of pre-congestion.>

-          S4: clarified that PCN-interior-node functionality applies
for each outgoing interface, and added clarification: <The functionality
is also done by PCN-ingress-nodes for their outgoing interfaces (ie
those 'inside' the PCN-domain).>

-          S4 (near end): when there's traffic less important than PCN,
now says: <a PCN-node should dedicate some capacity to lower priority
traffic so that it isn't starved.> (-00 version said "may" rather than
"should". I think this better reflects the advice in the EF rfc
(although since the architecture draft is Informational and nothing is
in capital letters, it's a bit hair-splitting).

-          S5: changed a few places to talk about the PCN functionality
being done on an interface (-00 version says 'link' and 'interface'
seems clearer)

-          S5.2: deleted erroneous mention of service level agreement

-     S5.8: Tunnelling: see comment earlier today on list. Add ref to
[ecn-mpls]. "effective elimination of ECMP as a load balancing
mechanism" is too strong (I'm trying alternative wording - or else I may
end up just deleting the phrase]

-          S5.5: Probing: new section as on the list. 

-          S5.7 addressing: in the case where traffic is always
tunnelled across the PCN-domain, add a note that he PCN-ingress-node
needs to know the address of the PCN-egress-node

-          S6: open issues - made it clearer that: <NOTE: Potential
solutions are out of scope for this document.> I also edited a couple of
sentences that were close to solution space. 

-     S6: flash crowds: phrased more accurately (replaced the poor
phrases "speed of reaction" & "handling request faster than
vulnerability period")

-          S6: added another open issue: Silent at start: after a
successful admission request the source may wait some time before
sending data (eg waiting for the called party to answer). Then the risk
is that, in some circumstances, PCN's measurements underestimate what
the pre-congestion level will be when the source does start sending
data.

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