RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt

[Bob Briscoe <[e-mail]>]

Phil and all the authors of this PCN architecture draft,

Like Lars, I'd like to congratulate you all on such a mature first draft, 
and on managing to encompass many different views we have seen from various 
people without making the thing an uncontrollable monster full of options 
and choices.

I just read it all through and my review comments are given below.

Also see 
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/ipe2eqos/gqs/papers/draft-eardley-pcn-architecture-00_rvw_bb.pdf> 
for suggested minor text changes.

I haven't supplied text for more major changes inline below until the 
authors agree with the need for change. But then I can supply text if required.

At 16:59 28/06/2007, [e-mail] wrote:
>Hi all,
>
>Just a reminder that all comments on this draft would be great. It aims
>to describe the PCN architecture, in light of the PCN WG's Charter & its
>Milestone of an Info doc on 'Flow Admission and Termination Architecture
>within a Diffserv Domain' (due Nov 07).

General comments:

* WG process management
A lot of WG process management text, esp in S.3, but also the list of 
possible flow termination mechanisms in S.4. All instances hilited in 
magenta in the review at the above URL.
See separate mail about this to the PCN WG chairs (cc PCN list)
Subject: How to discuss WG scoping decisions in an RFC?

* Choices vs decisions
I believe an architecture doc should say where one decision is required or 
where multiple options are reasonable. Currently, the arch is good at 
laying out the design space, but I'd like us to try to say which choices 
have to be made by the IETF, which should be left to vendors and which left 
to operators.

>S1 Introduction.
>This is quite short. If desired, it could be boosted with a general
>explanation of where PCN fits into the picture of QoS and how it's
>evolved (compare Section 1.1 of draft-chan-pcn-problem-statement-01)

* Clarify that a packet might encounter more than one PCN domain along its 
path, each being a separate admission control hop.

* Clarify that a "Diffserv domain" may be multiple concatenated autonomous 
systems, but in this draft they are assumed to trust each other and have 
identical configuration.

>S2 Terminology
>In the "Editor's note" are 3 alternative terms that some of the authors
>preferred.

* ECN _and_ PCN marking?

"   o  Configured-termination-rate: [...]
                                Normally it is configured to be less than
       the maximum rate at which PCN-traffic can be forwarded on the
       link, so that termination-marking occurs before any significant
       queuing, ECN-marking or loss of PCN-packets.
"

The above text implies (to me) that a PCN-interior router might do PCN 
marking _and_ also ECN marking just before drop. That also imposes a 
requirement on the encoding to be able to carry either in the same field.
I don't think the authors meant either of these implications. So somewhere, 
the relation between PCN & ECN marking should be stated.

Although this is perhaps too detailed for the architecture, I suggest that 
any need for ECN marking on the same path but outside the PCN domain(s) 
should be handled by tunnelling across the PCN domain, with a non-PCN DSCP 
in the inner header (that turns on the RFC3168 meaning of its ECN field) 
and a PCN DSCP in the outer.

* Marking is when "current" rate is "above" a reference rate?

"   o  Admission-marking: the marking of PCN-packets by a PCN-node to
       indicate that the PCN-traffic on a link is above the configured-
       admissible-rate.

    o  Termination-marking: the marking of PCN-packets by a PCN-node to
       indicate that the PCN-traffic on a link is above the configured-
       termination-rate.
"

These marking definitions and other examples hilighted in magenta in the 
above PDF prejudge marking mechanisms as rate measurements.

We don't just have marking when the _current_rate is _above_ the reference 
rate. We can have marking when the _current_ rate is _below_, or when the 
_past_ rate was _above_.

The configured rates are parameters of a (to be defined) mechanism. These 
mechanisms will not have to mark packets when the rate is above these 
configured rates. That depends on the mechanism.

This sounds picky, but it's actually a big rant I have about all this loose 
discussion of rate (yes, the issue of what rate means is mentioned in the 
draft, but we need to be careful about such sloppy usage). IMHO, it's 
important to scale our conception of time down to inter-arrival times, to 
be precise. Then the rate is packet size/interarrival time. Therefore seen 
at a small enough timescale, rate might be varying rapidly above and below 
the configured rate.

A marking mechanism could be implemented by a virtual queue rather than a 
rate measurement. When the offered instantaneous rate has been below the 
configured-admission-rate for many packets (perhaps hundreds), marking will 
and should still occur,... if the virtual queue is still above a marking 
threshold even if it is emptying rather than filling. This can be a 
deliberate design choice that says we still want admission marking when 
there has been recent overload to allow time for the control loop to work. 
It ensures a greater safety margin is automatically created by the marking 
mechanism when recent traffic had higher variance. This was the marking 
algorithm that was most studied and simulated in CL-PHB draft.

The unintended implication that all packets are either marked or not marked 
should also be carefully avoided. The draft needs to say explicitly that
"Admission (or Termination) marking will be an encoding of some combination 
of codepoints in the IP header to signal a varying fractional number from a 
path of PCN-interior-nodes to a PCN-egress-node"

* inelastic
Do you think we should define "inelastic" or is this a well-known IETF 
term? We could refer to [Shenker95], which I think was the first to define 
the term. Or is there an RFC that defines this (hopefully with ref to Shenker)?

Scott Shenker, "Fundamental Design Issues for the Future Internet", In: 
IEEE Journal on Selected Areas in Communications 13 (7) pp. 1176--1188 (1995).


>S3 Assumptions and constraints on scope
>These are the 4 things mentioned in the Charter, plus some explanation
>of them. Are they clear? Also we mention some of the ways that a future
>revised Charter might look at overcoming some of the
>constraints/assumptions; is this sub-section at the right depth?

* Are all the scoping assumptions equal relaxable?

Just a thought: might it be worth giving an indication of which assumptions 
are likely to be hard or impossible to relax and which not (e.g. I think 
the aggregation assumption is implicit to all MBAC (measurement-based Adm 
Ctrl). Also inelasticity is fairly fundamental - you don't need admission 
control if flows aren't inelastic.

This would affect the last para, which implies all the assumptions might be 
relaxed one day.

>S4 High-level functional architecture
>We have tried to write this section (and the following ones) so that it
>fits all the various proposals there've been for PCN mechanisms. Does
>this make the section too wishy-washy or too hard to understand? Should
>it include some comparison of the different mechanisms proposed
>(PCN-interior-node marking algorithms & PCN-boundary-node reactions)?

* Functional or topological?
Is it intentional that the high level functions are classified by which 
type of node does them in 3 cases and what function is to be done in the 
others? Would it be possible to define functions in the abstract first, 
then say which functions have to be implemented on certain types of nodes? 
Or does this just make it unnecessarily incomprehensible?

Gaps:
1/ Discuss which PCN node needs to know the IP address of which other PCN 
node in different configurations. And state requirements this implies on 
the signalling protocol, or on configuration.
Minimally, only the egress needs to know the ingress address. In 
centralised admission control scenarios, either the egress or the ingress 
or both might need to be configured with a central address.

2/ Related to knowing addresses of other nodes: When a PCN node receives a 
message claiming to be from another PCN node, to validate the msg is indeed 
from the node it claims to be, are there any different issues that PCN 
raises relative to typical reservation signalling systems? 
draft-lefaucheur-rsvp-ecn-01 (expired) contains a good deal of text on this 
issue that should be generalised into this arch doc.

>S5 Detailed Functional architecture
>Is this a reasonable description of the extra functionality that PCN
>requires on various nodes in the PCN-domain? Is it the right way to
>split up the description? For clarity / help reader's understanding,
>should there be some specific examples of how functionality might be
>distributed (eg "if you followed the deployment model in
>draft-briscoe-tsvwg-cl-architecture-04, then this measurement is made at
>the PCN-egress-node, communicated to the PCN-ingress-nodes which makes
>the admission decision; etc.")

S.5.5 Probing functions

If we are going to consider a case where the ingress has prior knowledge of 
which egress is associated with which destination address (e.g. with a 
separate signalling routing table as discussed in NSIS, or if the 
signalling protocol goes receiver-sender-receiver), then the ingress could 
know that it has no reservations with that egress as soon as a reservation 
request arrives, so it can unilaterally start probling.

S.5.6 Flow Termination Functions

The text seems to assume the egress makes the decision on which flows to 
lose and tells the ingress. In cl-architecture (for instance) the egress 
meters, feeds back the measurement to the ingress, which meters the load it 
is forwarding and then the ingress calculates how much traffic to 
terminate, and either chooses the flows itself, or asks a central node to 
choose.

I think there has to be metering at both boundaries otherwise we can't work 
out how much traffic has been dropped (as well as termination marked). The 
decision might be at either (but in cl-architecture we had good reasons for 
choosing the ingress because it has the most recent knowledge about load 
(given flows might be being abandoned by users very quickly and/or added 
very quickly during a disaster).

Other more incremental mechanisms have now been defined that don't 
calculate how much load to shed in one pass, but keep trying. Have we 
abandonned the earlier approach?

Whatever, I think a feedback function is missing between the boundary nodes.

>S6 Design goals and challenges
>This briefly describes some open issues, taken from
>briscoe-tsvwg-cl-architecture. Are there other ones that should be
>mentioned? Is the problem description at the right level of depth?
>Should we discuss various possible solutions to these problems?

I get the feeling we need a doc specifically on ECMP solutions?

>S7 Deployment scenarios
>Briefly describes some deployment scenarios for pcn? is this at the
>right level of depth?

Just a thought - I felt this section would have been better earlier.

>S8 Operations and Management
>This section was written in response to the Charter saying that the
>architecture document should include security, manageability and
>operational considerations. The draft addresses this by providing some
>thoughts under the FCAPS headings: OAM of Faults, Configuration,
>Accounting, Performance and Security? Is this the right way of
>structuring it - does it cover the right set of topics? Is the text at
>the right level? - eg should it also have a detailed set of parameters
>that would be available for configuration?

* Don't think this is Fault OAM?
Echoing what someone else (I forget who) said on the list, Fault OAM isn't 
really about how the control system recovers from failures (that's 
control), it's how to tell the management system/manual operator that you 
have recovered from a failure (or not).

Also, we should cover faults other than node or link failures. E.g. a 
wrongly configured address in a node, or a wrong address given in a 
singalling protocol, or a wrongly configured parameter in a queueing algo. Etc.

* Config OAM: Add:
- level of AM that leads to denying new admissions.
- config paramteres that control distribution of functions?

* Don't think this is Performance OAM?
I think Perf OAM is about monitoring performance at run-time, not 
characterising performance at design time.

* Don't think this is Security OAM?
Again, as someone said, security OAM is finding out about security breaches 
or near-misses at run-time, not identifying security flaws in the design, 
which is security the considerations section.

* Security Considerations Gaps:
- PCN marking selectively applied to certain flows, rather than randomly by 
interior node.
- The statement about DoS attacks is a requirement with no pointers to the 
detailed DOS issues, or any discussion of best practice design. I could 
supply text here (among many other things to do!)
- ref to hop-by-hop signalling authentication [RFC2747 for RSVP] and the 
new recently posted draft to tsvwg on group keying for RSVP authentication 
<draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt>. I haven't read it 
yet, but on a scan it's as relevant as RFC2747.


Phew... that's all for now.


Bob


>An overall question is whether the draft should have more comparison of
>the options (pros/cons) for various aspects.
>
>I aim to edit another version of the draft before the ietf (but maybe
>not before the deadline as I'm on hols next week).
>
>Thanks!
>Phil/

____________________________________________________________________________
Bob Briscoe, <[e-mail]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    [phone]  




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