Subject: [PCN] FW: draft-ietf-pcn-architecture-03

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 27 Feb 2008 09:45:59 +0100

Lars,

some remarks marked [RG] in line.

Regards,

Rudiger

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2008 6:00 PM
To: ext Steven Blake
Cc: pcn
Subject: Re: [PCN] draft-ietf-pcn-architecture-03

On 2008-2-22, at 17:29, ext Steven Blake wrote:
> The chairs would like input on whether the working group has read 
> draft-ietf-pcn-architecture-03, and believes that it is ready for 
> working group last call.  Please send your comments to this list.

The document does a tremendous job of outlining the PCN architecture - nice job.

I don't think it is ready for WGLC yet, however. This is, because there are still several places where it simply lists options for doing things that are still under discussion, and for which the WG needs to come to consensus on *one* option. I'm not faulting the document or the authors; this is merely a reflection of the WG not having come to consensus yet.

Lars

Detailed comments:

Section 1., paragraph 9: [snip, no comment on that one from me here]

Section 1., paragraph 19:

 >    o  Depending on the deployment scenario, the decision-making
 >       functionality (about flow admission and termination) could reside
 >       at the PCN-ingress-nodes or PCN-egress-nodes or (see Appendix) at
 >       some central control node in the PCN-domain.

[Lars] It is important to discuss somewhere that some choices here are less
   optimal than others. A good decision-making location is where PCN
   information naturally accumulates, e.g. at the egress. Any relocation
   of that decision-making requires additional communication, which
   increases the delay of the control loop and makes the system more
   brittle, because correct operation now requires dependable
   communication between the egress and the decision-making point. I'd
   like to suggest that we attempt to come to consensus on whether we can
   focus on a single decision point for PCN.

[RG] The per flow signaling must reside at the ingress by our actual 
specification (see section 1, first bullet point) and to make admission 
control work, the egress must signal to the ingress anyway. It is 

Section 1., paragraph 21:
 >    o  The PCN-domain extends to the end users.  The scenario is
 >       described in [I-D.babiarz-pcn-sip-cap].  A variant is that the
 >       PCN-domain extends out as far as the LAN edge switch.

[Lars] This deployment model may not be possible under the initial charter,
   or maybe even under an extended charter, because it is not clear that
   sufficient statistical multiplexing exists on the links near the edge
   to make PCN work, which is a *fundamental* assumption of PCN (see
   assumption 3 in Section 3). Listing this deployment scenario here when
   we aren't sure how to support it raises false expectations - I'd hence
   propose to drop this bullet item.

[RG] Lars, here two approaches must be differentiated:
     - application of PCN marking to support MBAC, which isn't working on 
       links where MBAC can't be supported. Bad idea.
     - Forwarding packets which have been marked as pre-congested within 
       a PCN domain to an end system to signal network pre-congestion 
       status to it (similar to ECN). This is usefuls and  may be feasible 
       and should be an option for an extended charter.

Section 1., paragraph 27:
 >    From the perspective of the outside world, a PCN-domain essentially
 >    looks like a DiffServ domain.  PCN-traffic is either transported
 >    across it transparently or policed at the PCN-ingress-node (ie
 >    dropped or carried at a lower QoS).  A couple of differences are
 >    that: PCN-traffic has better QoS guarantees than normal DiffServ
 >    traffic (because PCN's mechanisms better protect the QoS of admitted
 >    flows); and in rare circumstances (failures), on the one hand some
 >    PCN-flows may get terminated, but on the other hand other flows will
 >    get their QoS restored.  Non PCN-traffic is treated transparently, ie
 >    the PCN-domain is a normal DiffServ domain.

   This paragraph would make more sense earlier in the intro.

Section 3.5., paragraph 2:
 >    The following two assumptions apply if the PCN WG decides to encode
 >    PCN-marking in the ECN-field.

   Please add that any such encoding needs to conform to RFC4774.

Section 4.1., paragraph 4:
 >    NOTE: Two main categories of algorithm have been proposed: if the
 >    algorithm uses threshold-marking then all PCN-packets are marked if
 >    the current rate exceeds the PCN-lower-rate, whereas if the algorithm
 >    uses excess-rate-marking the amount marked is equal to the amount in
 >    excess of the PCN-lower-rate.  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 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).

[Lars] It seems important that we come to consensus on which scheme will be
   used for PCN before we move forward with the architecture. Otherwise,
   we're merely postponing a difficult decision we'll have to tackle
   eventually anyway.

[RG] You are right. But is the architecture the document to have that 
decision or should the architecture state that the PCN WG will standardise 
just one of these alternatives and tell the reader where to find this 
decision?.

Section 4.1., paragraph 7:
 >    o  if the PCN-egress-node receives one (or several) PCN-marked
 >       packets, then a new flow is blocked, otherwise it is admitted.

[Lars] I don't understand this - please elaborate. (Is this related to my
   earlier comment about the "alternative approach"?)

[RG] The section should apply the terminology defined and used earlier to 
express that if the rate of PCN marked packets in a measured ingress 
egress aggregate is above an "admission stop threshold", then new flows 
for this aggregate are not admitted.

Section 4.2., paragraph 1:
 >    At a high level, flow termination control works as follows.  Each
 >    PCN-node PCN-marks packets in a similar fashion to above, with all
 >    proposals using an excess-rate-marking approach (Section 4.1).  An
 >    obvious approach is for the algorithm to use a second configured
 >    parameter, PCN-upper-rate, and a second header encoding.  However
 >    there is also a proposal to use the same rate and the same encoding.

[Lars] Are we coming to consensus on which to pick moving forward? As before,
   I'd like us to avoid postponing difficult decisions.

[RG] We MUST have different deployment options. Two points:
     - if your network is MPLS based, it's single codepoint marking.
     - if you don't want to support termination, you just need single 
       codepoint marking.
     IP based networks aiming on termination may fare better with the 
     second codepoint/threshold. But that applies just in the case of 
     an IP based network. If PCN makes the two thresholds a requirement, 
     then it won't see deployment in carrier backbones, it's a corporate 
     network feature. I don't think, that's a good choice.

Section 4.3., paragraph 4:
 >    A different possibility is to configure only the PCN-lower-rate and
 >    hence only do one type of PCN-marking, but generate admission and
 >    flow termination responses from different levels of marking. This is
 >    suggested in [I-D.charny-pcn-single-marking] which gives some of the
 >    pros and cons of this approach.

[Lars] draft-charny is at odds with the second paragraph of the intro, which
   says that each link has a PCN-lower-rate and a PCN-upper-rate. If the
   intent of the architecture is to permit a proposal like draft-charny,
   those concepts need to be re-defined.

[RG] Would it be sufficient to make the PCN-upper-rate an optional feature 
(with mandatory requirements, if activated)? Or would the way to go be 
also to list different deployment scenarios?

Section 4.5., paragraph 2:
 >    o  There needs to be a way for a PCN-node to distinguish PCN-traffic
 >       from non PCN-traffic.  They may be distinguished using the DSCP
 >       field and/or ECN field.

   Please refer to RFC4774 again.

Section 5.3., paragraph 5:
 >    Another PCN WG document, about boundary mechanisms, will describe
 >    PCN-metering in more detail.  As described in Section 4.1 and Section
 >    4.2, at present there are two alternative proposals: to measure as an
 >    aggregate (ie not per flow) all PCN-packets from a particular PCN-
 >    ingress-node; or to monitor the PCN-traffic and react to one (or
 >    several) PCN-marks.  We refer to these approaches as "measuring PCN-
 >    traffic" and "monitoring PCN-marks".  The PCN-metering functionality
 >    also depends on whether the measurement is targeted at admission
 >    control or flow termination.  It also depends on what encoding and
 >    PCN-marking algorithms are specified by the PCN WG.

   OK, this clarifies the "alternative approach that I had two comments
   about above a bit more. I'd suggest to move some of that explanation
   earlier in the document. (But we do need to decide on which option to
   go with, too.)

Section 5.4., paragraph 8:
 >    The decision needs to be passed to the application layer so that it
 >    can take the appropriate action.

[Lars]   The application layer at what node? And define "appropriate".

[RG] You are right, I had the same question. Additionally, the information 
for the application layer is missing at the following section, describing 
termination. This should be defined for both, admission and termination,
or fo none. 

Section 5.6., paragraph 4:
 >    o  Use a probe packet that includes as payload the address of the
 >       PCN-ingress-node.

[Lars] I don't understand how a probe packet can be used by the egress to
   determine the address of the ingress, if the egress needs to know this
   address to send the probe packet. (But see my comment on probing below;
   this may be moot.)

[RG] There's probably some additional thought behind that on tunneling. 
A description to when this method is applicable should be added.

Section 5.8., paragraph 0:
 > 5.8.  Fault handling

[Lars] It may be a good idea to add a paragraph that describes that
   re-routing must be constrained in a way that upholds the boundary of
   the PCN domain. In other words, re-routing MUST NOT cause traffic to
   enter the domain without going through a PCN ingress.

[RG] No, we shouldn't touch routing, because we'll end up nowhere. We 
should describe however what happens in the case of a re-routing 
resulting in a new ingress node (that's eg standard RSVP behaviour).

Section 7., paragraph 0:
 > 7.  Probing

[Lars] I am still opposed to probing as part of the PCN architecture. It is a
   *very* complex mechanism with lots of open issues surrounding how it
   could actually be implemenented that in the end serves only one
   purpose: to slightly increase capacity utilization in a PCN domain.
   However, PCN was never meant to remove the need for sufficient
   overprovisioning. A second reason is that probing is only really
   needed to extend PCN into scenarios where some of the assumptions
   (sufficient multiplexing, etc.) are no longer true. We already have a
   boatload of explicitly-signalled QoS architectures that were designed
   for just such scenarios. I see no reason to complicate PCN into yet
   another signalled-QoS system.

[Lars] We already had consensus in Vancouver to stop discussing probing until
   after work on the initial milestones has finished. I'd like to propose
   to remove the discussion of probing from the architecture at least until
   that time.

[RG] I share your doubts about probing but I must admit that we largely 
stopped to discuss it. To move forward, I dropped my already written 
concerns about probing from my mail on a possible WGLC yesterday. I can 
live with probing as an optional mechanism which can be activated if 
desired. Would that be a way forward?

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

---

From: Lars Eggert <[email-masked]>
Date: Wed, 27 Feb 2008 11:17:08 +0200

Hi,

> control work, the egress must signal to the ingress anyway. It is

(Sentence truncated?)

I see your point. Thinking about this some more, I believe my comment  
was based on a different understanding on something that the  
architecture document currently doesn't discuss much, but probably  
should: What information is signaled from the egress to the ingress?

We agree that the egress looks at the volume of PCN marks compared to  
the volume of total PCN traffic to determine the level of congestion  
on an ingress-egress pair. The ingress then admits or terminates flows  
in a way that is somehow based on that information. But what gets  
signaled from egress to ingress? Is it some sort of load indication?  
Or is it a desired behavior, i.e., "stop admit" or "start preempt"? Or  
something else?

>       and should be an option for an extended charter.

Agreed. But the current text isn't clear as to which of these PCN will  
support.

> just one of these alternatives and tell the reader where to find this

Since the WG needs to come to consensus on this at some point anyhow,  
I'd prefer to have this discussion earlier rather than later and  
document it in the architecture draft. It also seems odd to have an  
architecture draft that basically says "we don't know yet what this  
piece will look like."

> for this aggregate are not admitted.

_That_ I understand :-)

>     network feature. I don't think, that's a good choice.

OK. I think I need to rethink this point.

> also to list different deployment scenarios?

I think that making the PCN-upper-rate an optional feature in this way  
would be the cleanest way of allowing draft-charny as well as the  
other options, but will require some careful editing across the entire  
document.

> resulting in a new ingress node (that's eg standard RSVP behaviour).

OK. Re-reading what I wrote, this point is probably implied by the  
definition of PCN boundary anyway.

> desired. Would that be a way forward?

Even optional components of an architecture need to be fully described  
so they can be implemented, if so desired. I simply don't think we are  
at a point were we can do that for probing. And having the  
architecture draft say "and there's this optional mechanism that we  
don't quite know how to build and how to integrate with the rest of  
PCN" doesn't strike me as a good idea.

Lars

---

From: Steven Blake <[email-masked]>
Date: Wed, 27 Feb 2008 10:40:40 -0500

>      network feature. I don't think, that's a good choice.

Ruediger,

I don't follow your comment regarding MPLS and single codepoint marking.
EXP bits are scarce, but I don't see what it is that precludes using EXP
codepoint to indicate three or more encoding states, perhaps through use
of L-LSPs.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <[email-masked]>
Ericsson/Redback Networks               +1 919-472-9913

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 29 Feb 2008 09:10:54 +0100

Hi Steven,

how many operators and vendors you know deploy or support L-LSPs?

Regards,

Rudiger

| -----Original Message-----
| From: Steven Blake [mailto:[email-masked]] 
| Sent: Wednesday, February 27, 2008 4:41 PM
| To: Geib, Rüdiger
| Cc: [email-masked]
| Subject: Re: [PCN] FW: draft-ietf-pcn-architecture-03
| 
| On Wed, 2008-02-27 at 09:45 +0100, Geib, Ruediger wrote:
| 
| > [RG] We MUST have different deployment options. Two points:
| >      - if your network is MPLS based, it's single codepoint marking.
| >      - if you don't want to support termination, you just need single 
| >        codepoint marking.
| >      IP based networks aiming on termination may fare better with the 
| >      second codepoint/threshold. But that applies just in the case of 
| >      an IP based network. If PCN makes the two thresholds a requirement, 
| >      then it won't see deployment in carrier backbones, it's a corporate 
| >      network feature. I don't think, that's a good choice.
| 
| Ruediger,
| 
| I don't follow your comment regarding MPLS and single 
| codepoint marking.
| EXP bits are scarce, but I don't see what it is that 
| precludes using EXP codepoint to indicate three or more 
| encoding states, perhaps through use of L-LSPs.
| 
| 
| Regards,
| 
| =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Steven Blake                <[email-masked]>
| Ericsson/Redback Networks               +1 919-472-9913
| 
| _______________________________________________
| PCN mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Steven Blake <[email-masked]>
Date: Fri, 29 Feb 2008 17:19:46 -0500

> how many operators and vendors you know deploy or support L-LSPs?

Not many, true.  Deploying PCN will require at least some operational
and implementation changes.  I guess you are telling us that relying on
more than two EXP codepoints to signal pre-congestion state (and hence
having to re-engineer the way Diffserv is managed over LSPs) is a deal
breaker in many networks?

Regards,