I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-pcn-cl-edge-behaviour-08
Reviewer: Elwyn Davies
Review Date: 10 June 2011
IETF LC End Date: 10 June 2011
IESG Telechat date: (if known) -
Summary:
In my opinion, there are a number of areas that need significant work
and at least one open issue (the stability question from s3.3.1) that
needs to be addressed before this document is ready for the IESG.
Major issues:
The draft contains partial definitions of two control protocols (egress
-> decision point; decision point -> ingress). It does not make it
clear whether the reader is expected to get full definitions of these
protocols here or whether there will be another document that specifies
these protocols completely. As is stands one could build the protocols
and pretty much guarantee that they would not be interoperable with
other implementations since message formats are not included although
high level specs are. The document needs to be much clearer about what
is expected to happen here.
Use of EXP codepoint: My understanding of what is said in RFC 5696 is
that EXP is supposed to be left for other (non=PCN) systems to use.
This draft uses it. Is this sensible? Is this whole draft experimental
really?
s3.3.1:
[CL-specific] The outcome of the comparison is not very sensitive
to the value of the CLE-limit in practice, because when threshold-
marking occurs it tends to persist long enough that threshold-
marked traffic becomes a large proportion of the received traffic
in a given interval.
This statement worries me. It sounds like a characteristic of an
unstable system. If the value is that non-critical why are we
bothering?
Minor issues:
s1.1: definition of PCN-Traffic etc:
The same network will carry traffic of other Diffserv BAs.
Just to be sure: Does this or does this not imply that *all* traffic in
a PCN network must have a non-empty DSCP marking, i.e. that *all*
traffic must be attached to some specific Diffserv BA? This should be
clarified whichever is true.
s1.1: T-fail: I notice from s3.1 that PCN-ingress nodes also have to
make reports on request. Should T-fail or some other timer apply to
non-return of info from ingress points? What would a (probably
non-colocated) decision point do if it lost contact with the ingress?
s2/s3.2.1: The use of PM and EXP codepoints for ThM and ETM appear to be
reversed in these two sections!! Which way round is intended?
s3.2.1/s3.2.2: Neither section mentions T-meas but I assume that this
is supposed to be (either or both) the sampling period in the egress
node or the period between reports. It is unclear if they are allowed
to be different and if they are which one is T-meas. However s3.2.3
appears to imply that T-meas is probably the time between reports. This
all needs to be much clearer.
s3.2.1/3.2.2: In s3.2.2, para 2:
If so configured (e.g., because multipath routing is
being used, as explained in the previous section), the PCN-egress-
node MUST also report the set of flow identifiers of PCN-flows for
which excess-traffic-marking was observed in the most recent
measurement interval.
This is a requirement for a protocol that you may or may not be
defining. Confusing.
s3.2.3/s3.2.2: The first paragraph of s3.2.3 suggests that the report
from an egress may not always contain the calculated value of the CLE,
but s3.2.2 has a MUST for the report to contain this value.
Consistency!!!
s6: The potential introduction of a centralized decision point appears
to provide additional attack points beyond the architecture in RFC 5559.
It appears to me that the requests for information about specific flows
to the ingress are ighly vulnerable as they (probably) contain all the
information needed to craft a DoS attack on the flow.
Nits/editorial comments:
General: Consistency of naming for timing paramters t-meas/T-meas, etc.
s1.1: I think it would be worth reproducing the CL-specific definitions:
PCN-threshold-rate and threshold-marked since they are specific.
s1.1:
Congestion level estimate (CLE)
A value derived from the measurement of PCN-packets received at a
PCN-egress-node for a given ingress-egress-aggregate, representing
the ratio of marked to total PCN-traffic (measured in octets)
^^^^^ ^^^^^^^^^^^^^^^^^^
received over a short period.
The ratio is (hopefully) dimensionless. Maybe '(each measured in octets)' ?
s2:
the PCN-domain satisfies the conditions specified in [RFC5696];
This may be a bit pedantic but I am not sure that RFC 5696 actually sets
out conditions for the domain. It sets out rules for encoding markings
and allowed transitions. Maybe s/conditions/packet markings and allowed
transitions/.
s3.1, para 1 and several other instances: s/collocated/co(-)located/
s3.2.1, para 5: s/statistical variance/statistical variation/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf