Subject: [Gen-art] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

From: Elwyn Davies <[email-masked]>
Date: Fri, 10 Jun 2011 19:01:54 +0100

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/

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 14 Jun 2011 18:20:43 +0100

Hi, Phil.

It strikes me that the first and second points below are something which 
David Harrington perhaps ought to give an opinion on. He has got to 
defend it to the IESG.

On the first point, my feeling is that neither the requirements doc nor 
this doc is sufficient to guarantee an interoperable implementation.  
There seems to me to be a cleft stick here (irrespective of whether this 
ends up as informational or experimental.) The WG is is specifying 
pieces of functionality that go in two or more different types of boxes 
(three if there is a separate implementation of the central decision 
point). If the system is going to be generally deployable or even to be 
experimented with there may be different implementations.  The box types 
communicate using the information specifications in the doc.  This 
appears to require protocol definitions.  Where they are defined is 
another issue but I feel it has either to be in this doc or in another 
doc referenced from this.  If they aren't specified I can't see that 
anybody will be interested in making commercial implementations.

I see David didn't make any comment about this situation in his write 
up, so maybe I am over reacting.

Regards,
Elwyn

On 13/06/2011 18:04, [email-masked] wrote:
> Elwyn,
>
> Thanks for the detailed review.
> A few follow-ups in-line
> Thanks
> phil
>
> --
> Major issues:
> [phil] there is another document, " Requirements for Signaling of (Pre-) Congestion Information in a DiffServ Domain" [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requirements-04] that deals with your issue to some extent. It doesn't specify message formats but does at least specify better what information the messages must contain. My understanding is that unfortunately the WG doesn't feel it has the effort to specify these protocols completely.
>
>
> [phil] the intention of rfc5696 was that the EXP codepoint is for experimental *PCN* encodings - ie beyond the baseline. For instance, the CL behaviour needs separate codepoints for (PCN) threshold-marking and (PCN) excess-traffic-marking&  this would require using the EXP codepoint.
> However...... There is currently some discussion on what PCN encodings to specify beyond the baseline. At the time we wrote the baseline, we envisaged the need for several encodings - however it now seems that one may be enough, in which case there may possibly be just one PCN encoding (ie a revised 5696 that now uses the 01 codepoint), so possibly may be Standards track - ??
> Anyway, i take your point that we need to think about Status.
>
> s3.3.1:
> [phil] admission control system. imagine the pcn-domain has one bottleneck link. If it can cope with the current number of calls (their bandwidth), then no pkts gets threshold-marked, so the CLE = 0. If there are too many, then all pkts gets threshold-marked, so the CLE = 1. If there is almost exactly the right number of calls, then threshold-marking will tend to be on for a while, then off for a while (perhaps when several flows are transmitting less traffic than normal), so the CLE will jiggle about between 0&  1. If the CLE is<  CLE-limit (say CLE-limit = 0.6&  current CLE = 0.5), when a new call admission request happens to arrive then it gets admitted. But then there's more traffic and it's likely that the CLE will rise to 1 - hence another admission request will get blocked. When a call finishes, then the reverse is true.
>
> Now suppose we had in fact configured CLE-limit = 0.4, then in the scenario above the call request would have been blocked. However, (1) the PCN-domain has only admitted one fewer call, (2) a short time later, either the CLE happens to be lower or a call departs, and then the next admission request is accepted.
>
> All this means that it doesn't matter much exactly what you set CLE-limit to - it barely affects the average number of calls admitted. The argument above is hand-wavy, but lots of simulations have been done that show this is true (I hope i'm representing the results correctly)
> So the lack of sensitivity to CLE-limit seems like a good thing.
>
>
> Minor issues:
>
> [phil] seems a good point to me
>

-- 
Join the Cambridge Oxfam Walk on Sunday 15 May, 2011.
For more information, see http://www.oxfam.org.uk/get_involved/fundraise/walk/ and follow us on Twitter at http://twitter.com/CambOxfamWalk.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 14 Jun 2011 14:20:12 -0400

Well, Elwyn, here's the problem: apparently the likelihood of these ever 
being deployed is vanishingly small. So a protocol could be defined, but 
it would be wasted effort. (It's also outside the PCN charter, most 
likely because RSVP was supposed to be the transport. But that's another 
story ...)

In fact, I and a couple of others started to define a Diameter 
application to do the job. I'm not sure how realistic that would have 
been, in terms of messaging load. Diameter transport is supposed to be 
over TLS these days.

Tom T.

> up, so maybe I am over reacting.
...

---

From: "David Harrington" <[email-masked]>
Date: Tue, 21 Jun 2011 15:49:25 -0400

Hi,

The WG was chartered to specify the 
(3) encoding and transport of (pre-)congestion information
 between the interior and domain egress
... and ...
(5) encoding and transport of (pre-)congestion information
 between the egress and the controlling domain ingress 

I interpret that to mean the transport protocol and the message
formats should be specified in the documents.
I have to agree with Elwyn that lack of such formats means
implementations are likely to not be interoperable.
I am not sure what protocols would be suitable for these tasks; other
readers may have similar concerns.

I think the specification would benefit from a mandatory-to-implement
protocol expected to carry the configuration and reported information.
At a minimum, there should be a clear information model (RFC3444)
about the information to be transported.
The data type and range of values should be included in the
information model for each counter and configuration variable.
I think it would be better to specify a mandatory-to-implement
protocol, or at least a recommended-to-implement protocol, and a
corresponding data model to ensure interoperability.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: Elwyn Davies [mailto:[email-masked]] 
> Sent: Tuesday, June 14, 2011 1:21 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; General Area Reviwing Team
> Subject: Re: Gen-art LC review of
draft-ietf-pcn-cl-edge-behaviour-08

> > [phil] there is another document, " Requirements for 
> Signaling of (Pre-) Congestion Information in a DiffServ 
> Domain" 
> [http://tools.ietf.org/html/draft-ietf-pcn-signaling-requireme
> nts-04] that deals with your issue to some extent. It doesn't 
> specify message formats but does at least specify better what 
> information the messages must contain. My understanding is 
> that unfortunately the WG doesn't feel it has the effort to 
> specify these protocols completely.
> >
> >
> > [phil] the intention of rfc5696 was that the EXP codepoint 
> is for experimental *PCN* encodings - ie beyond the baseline. 
> For instance, the CL behaviour needs separate codepoints for 
> (PCN) threshold-marking and (PCN) excess-traffic-marking&  
> this would require using the EXP codepoint.
> > However...... There is currently some discussion on what 
> PCN encodings to specify beyond the baseline. At the time we 
> wrote the baseline, we envisaged the need for several 
> encodings - however it now seems that one may be enough, in 
> which case there may possibly be just one PCN encoding (ie a 
> revised 5696 that now uses the 01 codepoint), so possibly may 
> be Standards track - ??
> > [phil] admission control system. imagine the pcn-domain has 
> one bottleneck link. If it can cope with the current number 
> of calls (their bandwidth), then no pkts gets 
> threshold-marked, so the CLE = 0. If there are too many, then 
> all pkts gets threshold-marked, so the CLE = 1. If there is 
> almost exactly the right number of calls, then 
> threshold-marking will tend to be on for a while, then off 
> for a while (perhaps when several flows are transmitting less 
> traffic than normal), so the CLE will jiggle about between 0& 
>  1. If the CLE is<  CLE-limit (say CLE-limit = 0.6&  current 
> CLE = 0.5), when a new call admission request happens to 
> arrive then it gets admitted. But then there's more traffic 
> and it's likely that the CLE will rise to 1 - hence another 
> admission request will get blocked. When a call finishes, 
> then the reverse is true.
> >
> > Now suppose we had in fact configured CLE-limit = 0.4, then 
> in the scenario above the call request would have been 
> blocked. However, (1) the PCN-domain has only admitted one 
> fewer call, (2) a short time later, either the CLE happens to 
> be lower or a call departs, and then the next admission 
> request is accepted.
> >
> > All this means that it doesn't matter much exactly what you 
> set CLE-limit to - it barely affects the average number of 
> calls admitted. The argument above is hand-wavy, but lots of 
> simulations have been done that show this is true (I hope i'm 
> representing the results correctly)
> For more information, see 
> http://www.oxfam.org.uk/get_involved/fundraise/walk/ and 
> follow us on Twitter at http://twitter.com/CambOxfamWalk.
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 21 Jun 2011 20:31:04 -0400

OK, I'll take up the good work. Just to start with, I propose to submit 
interim updates as I wished I had back a few months ago. I'll go on from 
there.

On 21/06/2011 3:49 PM, David Harrington wrote:
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
>
>

---

From: <[email-masked]>
Date: Wed, 22 Jun 2011 08:21:27 +0200

Hi Tom,

which work are you taking up?

- specifying the madatory to implement protocol.
- or specifying a minimum clear information model (RFC3444).

I prefer the latter above the former.

Regards,

Ruediger

---

From: <[email-masked]>
Date: Wed, 22 Jun 2011 09:16:43 +0100

Personally I think it unlikely that the WG would ever complete the former

The latter might be plausible, though having flicked at 3444 i can't tell exactly what we're missing. It seems to say that an information model is an absrtact model about relationships between objects and can be defined informally - (since I havent consciously written one, I'm being vague) - the combination of CL & signalling reqts seems quite close to this?

Thanks for progressing Tom.
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 22 June 2011 07:21
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

Hi Tom,

Regards,

Ruediger

---

From: Tom Taylor <[email-masked]>
Date: Wed, 22 Jun 2011 05:46:07 -0400

The CL and SM drafts should definitely specify the information models. 
In my own mind, the actual protocol specification belongs in another 
document, since it would be common to the two models. Other edge 
behaviours (e.g. the piggybacking approach) would require their own 
protocol solutions.

Seriously, would Diameter make sense as the protocol? If so, the work is 
mostly done and I would just revive draft-huang-dime-pcn-collection and 
bring it up to date.

On 22/06/2011 2:21 AM, [email-masked] wrote:
>..

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 22 Jun 2011 09:51:47 +0000

Hi all,

I agree with Phil regarding the fact that the Information model can be
described as an abstract model informally to show the relationships
between objects. In particular RFC 3444 mentions:

   "IMs can be defined in an informal way, using natural languages such
   as English.  An example of such an IM is provided by RFC 3290 [9],
   which describes a conceptual model of a Diffserv Router and specifies
   the relationships between the components of such a router that need
   to be managed."

Regarding the possible options to support interoperability, I also think
that the latter might be plausible. I see three options of implementing
this:

1) each PCN edge behaviour draft will contain such an information model

2) a default information model will be included in the signaling
requirements draft

3) a new draft should be started by the PCN WG to describe such an
information model

With which option should we proceed?

Please also note that I have started modifying the following draft that
can be used as an example of how a signaling protocol can be applied to
support an PCN edge behaviour.
http://tools.ietf.org/html/draft-lefaucheur-rsvp-ecn-01

The target is to submit this draft to tsvwg. However, I do not think that
I will be able to submit this draft before the submission deadline (4th
of July). Tom and Francois were willing to help on commenting and/or
contributing to this.

Best regards,
Georgios

---

From: "David Harrington" <[email-masked]>
Date: Wed, 22 Jun 2011 10:09:55 -0400

Hi,

The main thing you are missing is an explanation of how you will
achieve interoperability.
The charter calls for specification of the encoding and transport of
> >   between the egress and the controlling domain ingress

How will the information get from the interior to the domain egress,
if the PCN processing for the interior node is implemented by vendor A
and the PCN processing for the domain egress node is implemented by
vendor B? In what message format will vendor A send it so that it can
be interpreted consistently by the receiver, regardless of which
vendor implements the receiver? What format validation shoudl be
performed by teh receiever, what conditions constitute a receiving
error, and what error codes should be returned by the receiver that
will be understood by the sender? 

Ditto for the players in 5)

The specification as written seems imcomplete because it does not deal
with specifying the encoding and transport of the information. Am I
just missing it, or is it really just not there? An information model
can help to understand the properties of the data to be transported,
but it doesn't really solve the problem of transporting the data in a
standardized, interoperable manner. You will need to work hard to
convince me that there is strong TECHNICAL justification for not
providing REQUIRED (or at least RECOMMENDED) protocols and message
formats/data models involved. I would likely need to work hard
subsequently to convince the IESG.

If the problem is that the WG has no energy, we can solve that in a
much simpler way than updating these documents - we can just close the
WG. If the WG doesn't have enough energy to complete these documents
first, we can abandon the documents. That could save everybody a lot
of time - WG editors, WG reviewers, WG chairs, the AD, IETF Last Call
reviewers from various directorates, the IESG, IANA ... 

I think the Internet would benefit from this technology, and I would
consider abandoning these documents at this point an awful waste of
time, given how much work has been put into them already, so I
STRONGLY encourage the WG to find the energy to complete their
agreed-upon deliverables, but if it is WG consensus to abandon them, I
guess I would have to accept that WG consensus. 

David Harrington

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, June 22, 2011 4:17 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: [PCN] Gen-art LC review of 
> The latter might be plausible, though having flicked at 3444 
> i can't tell exactly what we're missing. It seems to say that 
> an information model is an absrtact model about relationships 
> between objects and can be defined informally - (since I 
> havent consciously written one, I'm being vague) - the 
> combination of CL & signalling reqts seems quite close to this?
>

---

From: "David Harrington" <[email-masked]>
Date: Wed, 22 Jun 2011 10:18:25 -0400

Hi,

Let me clear that an abstract information model alone is not likely to
satisfy the concern, which is interoperability.

David Harrington

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, June 22, 2011 2:21 AM
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Wed, 22 Jun 2011 15:36:24 +0100

I take your point that ideally there would be an explanation of how to achieve interoperability and that it would have formats, error codes etc specified. I guess this would be a rfc3444 Data Model.

Reading your (DH's) latest email, it sounds like you'd need this (rather than what I thought an Information Model might be - which it sounded earlier would be sufficient)

I agree with all your comments about shutting the WG; I guess something worth discussing f2f in Quebec, informally & in the wg session.

Whatever, there is still the stuff on standardising the 3-in-1 encoding - which can proceed whatever we decide on this. We had some discussions a week or two back, which seem to have stopped (not sure we really reached a conclusion though!)

Best wishes,
phil

-----Original Message-----
From: David Harrington [mailto:[email-masked]]
Sent: 22 June 2011 15:10
To: Eardley,PL,Philip,DES8 R; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

Hi,

David Harrington

---

From: <[email-masked]>
Date: Wed, 22 Jun 2011 17:01:41 +0200

Hi David,

Interoperability would result if no feedback signaling is required.
I'm co-author of a draft describing such a solution. Unfortunately
the remaining participants of the WG favour signaling based solutions,
hence perspectives aren't bright for the draft supported by me.

To me, the WG has worked largely successfully. The mechanisms
standardised so far are fairly good.

Regards,

Ruediger

-----Original Message-----
From: David Harrington [mailto:[email-masked]]
Sent: Wednesday, June 22, 2011 4:18 PM
To: Geib, Rüdiger; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PCN] Gen-art LC review of draft-ietf-pcn-cl-edge-behaviour-08

Hi,

David Harrington

---

From: "David Harrington" <[email-masked]>
Date: Wed, 22 Jun 2011 11:40:10 -0400

Hi Ruediger,

Off the top of my head, I would think a signaling approach could
provide for a more coordinated response. YMMV.
I trust the WG had technical reasons for prefering a feedback
signaling approach. 
I consider the WG to be the experts in this space, so you don't need
to convince me, you need to convince them.

I think this WG has produced some very good documents, including those
under review now.
I think the WG is busy working on other specs right now, thinking they
had completed the CL and SM docs.
However, as Elwyn and I observed in GenArt and AD reviews, the CL and
SM documents still seem incomplete.
They seem to be missing interoperable transport and interoperable data
models.

I hope the WG still has energy, and can redirect some of its energy to
completing these documents so we can get them approved as RFCs. 

David Harrington

> Sent: Wednesday, June 22, 2011 11:02 AM
> To: [email-masked]; [email-masked]
> > >> David Harrington perhaps ought to give an opinion on. He has
got
> to
> > >> appears to require protocol definitions.  Where they are
defined
> is

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 22 Jun 2011 16:57:57 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David Harrington
> Sent: 22 June 2011 15:10
> To: [email-masked]; [email-masked];
> [email-masked]

<SNIP>
> reviewers from various directorates, the IESG, IANA ...

I think the issue may not be as simple as lack of WG energy so much as lack
of time available. Many in the WG are funded by external sources or work for
large companies, in the current straitened times they probably have to
justify their work to their bosses.

In theory I should have time to do lots of PCN stuff (as I am currently out
of work). However right now I am committed to doing lots of decorating, DIY
etc. My hope is that I can spend a productive few days at the start of July
and I will happily include reviewing other peoples work (as well as getting
3-in-1 encoding shipped). I would volunteer to write the interoperability
stuff, but I have zero experience of that so I would just get it wrong!

> guess I would have to accept that WG consensus.

I strongly feel it would be a waste to bin PCN at this stage. As you say
there has been some good work done and it would be a shame to lose it.

It sounds like there are a couple of people prepared to put energy into PCN
still and hopefully we can wrap this all up quickly.

Toby

> [email-masked]

</SNIP>