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

From: Bob Briscoe <[email-masked]>
Date: Wed, 25 Jul 2007 00:44:14 +0100

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, [email-masked] 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, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196  

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

---

From: <[email-masked]>
Date: Thu, 26 Jul 2007 21:34:58 +0100

hi,

wanted to pick up on a couple of issues raised by bob briscoe in his review of eardley-pcn-architecture; the 2nd one also relevant for chan-pcn-encoding-comparison.

the first is about whether a PCN-interior-node can ECN-mark (as congestion expereinced) PCN-pkts. 

Bob says:

>>The [xxxxx] 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.<<

bob is right (in my opinion), we didnt mean this and it needs some word-smithing. IE draft will be adjusted to say that it is assumed that a PCN-interior-node doesnt have the ability to perform ECN-marking on PCN-traffic. it can only do PCN-marking. 

the second issue is about what happens if traffic arrives at the PCN-domain (for the PCN traffic class) that is already marked with ECN's CE codepoint (congestion experienced). ie the issue is how to handle traffic which for some reason is using ECN (end-to-end) and also using PCN admission control (across the PCN-domain).  this could be an issue for the pcn-architecture draft, and also for the chan-pcn-encoding one. certainly it's an issue that's got to be dealt with by at least one of these drafts.

bob says:

>>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.>>

one possibility is to deal with this now, with the wording along the lines that bob suggests above added to the architecture draft. basically say that a solution on these lines would solve the problem (there may be others but we won't think about them).

another possibility is that the encoding comparison draft includes a look at the implications of a pkt being able to be PCN-marked whilst preserving its ECN-CE - ie the effect in terms of how the PCN-encoding is done. we could end up deciding that it was worthwhile, orthat it wasn't worthwhile. In the latter case we would go back to bob's solution above. 

do people feel able to make a decision now to go for the first possibility (as bob suggests - I'd be OK with this too) or do we want discussion within the encoding-comparisons draft?

thanks, phil

---

From: "Jozef Babiarz" <[email-masked]>
Date: Thu, 26 Jul 2007 17:26:56 -0400

Phil and all see below.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: July 26, 2007 4:35 PM
To: [email-masked]
Subject: [PCN] PCN & ECN-(congestion experienced) interactions

hi,

>wanted to pick up on a couple of issues raised by bob briscoe in his
review >of eardley-pcn-architecture; the 2nd one also relevant for
chan-pcn-[Joe] >encoding-comparison.

>the first is about whether a PCN-interior-node can ECN-mark (as [Joe]
>congestion expereinced) PCN-pkts. 

>>>The [xxxxx] text implies (to me) that a PCN-interior router might do
PCN >marking _and_ also ECN marking just before drop. That also imposes
a [Joe] >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.<<

>bob is right (in my opinion), we didnt mean this and it needs some word
>smithing. IE draft will be adjusted to say that it is assumed that a
PCN >interior-node doesnt have the ability to perform ECN-marking on
PCN-[Joe] >traffic it can only do PCN-marking. 
[Joe] Yes. I would agree with that. I think that by ECN-marking you mean
applying the marking behavior as defined in RFC 3168. 

>the second issue is about what happens if traffic arrives at the
PCN-domain >(for the PCN traffic class) that is already marked with
ECN's CE codepoint >(congestion experienced). ie the issue is how to
handle traffic which for >some reason is using ECN (end-to-end) and also
using PCN admission control >(across the PCN-domain).  this could be an
issue for the pcn-architecture >draft, and also for the
chan-pcn-encoding one. certainly it's an issue >that's got to be dealt
with by at least one of these drafts.

[Joe] If a packet belonging to a PCN-capable flow arrives at the
PCN-domain, the ECN field should not be touched. What ever the encoding
of the bits is it is forwarded that way. OK, I'm assuming that PCN can
be end-to-end some day.
However, if packet belonging to a flow that is not PCN-traffic arrives
at the PCN-domain it gets forwarded using a different forwarding class
(DSCP) than what is used for PCN traffic. The PCN-domain uses Diffserv
to provide the differentiation. Only PCN traffic get's the PCN
treatment.

>>>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
[Joe] >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.>>
[Joe] I do not understand. I though that we state that we would use
Diffserv. Why tunnel?

>one possibility is to deal with this now, with the wording along the
lines >that bob suggests above added to the architecture draft.
basically say that >a solution on these lines would solve the problem
(there may be others but >we won't think about them).
[Joe] We do not need to tunnel.

>another possibility is that the encoding comparison draft includes a
look >at the implications of a pkt being able to be PCN-marked whilst
preserving >its ECN-CE - ie the effect in terms of how the PCN-encoding
is done. we >could end up deciding that it was worthwhile, orthat it
wasn't worthwhile. >In the latter case we would go back to bob's
solution above. 
[Joe] Let's do it in the architecture draft. The marking draft should be
only a survey of viable marking options. 

>do people feel able to make a decision now to go for the first
possibility >(as bob suggests - I'd be OK with this too) or do we want
discussion within >the encoding-comparisons draft?
[Joe] We do not need to mix ECN marking behavior and PCN marking
behavior. My assumption is that we where going to use Diffserv and DS
codepoints to separate traffic that is PCN-capable from traffic that is
not PCN-capable.

---

From: <[email-masked]>
Date: Fri, 27 Jul 2007 00:33:53 +0100

joe
sorry i explained it badly, let me have another go.
The scenario i was thinking of is this. We have a source sending data to a receiver. somewhere in the middle between the Sx & Rx is a PCN-domain. The traffic being sent is treated as PCN-traffic inside the PCN-domain ie put into the PCN Diffserv class. However, between the Sx and PCN-domain the traffic is treated in a class that can be ECN-marked. When the traffic reaches the Rx, should any ECN-marking (that happened before the PCN-domain) be preserved. 
 
One possibility is that this is a scenario that we don't need to worry about. If it is one we need to think about, then there are two possibilities for how PCN WG could think about it:
(1) when such traffic reaches the PCN-domain, then tunnel it across the PCN-domain. this means that upon decapsulation at the egress any ECN-CE marking (that was there when the pkt reached the ingress) is preserved. 
(2) devise an encoding scheme for PCN that preserves the ECN-CE marking.
these are the two possibilities i was trying to lay out in my original email, ie
(1) deal with the issue in the architecture doc by saying a tunnelling solution could be done to solve the problem 
(2) in the encoding-comparison doc, examine what the impact of this would be on PCN-encoding (to inform the eventual choice of encoding)
 
phil

________________________________

From: Jozef Babiarz [mailto:[email-masked]]
Sent: Thu 26/07/2007 22:26
To: Eardley,PL,Philip,CXR9 R; [email-masked]
Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions

Phil and all see below.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: July 26, 2007 4:35 PM
To: [email-masked]
Subject: [PCN] PCN & ECN-(congestion experienced) interactions

<trimmed>

---

From: "Jozef Babiarz" <[email-masked]>
Date: Fri, 27 Jul 2007 01:14:51 -0400

See below.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: July 26, 2007 7:34 PM
To: Babiarz, Jozef (CAR:0S03); [email-masked]
Subject: RE: [PCN] PCN & ECN-(congestion experienced) interactions

joe
sorry i explained it badly, let me have another go.
The scenario i was thinking of is this. We have a source sending data to
a receiver. somewhere in the middle between the Sx & Rx is a PCN-domain.
The traffic being sent is treated as PCN-traffic inside the PCN-domain
ie put into the PCN Diffserv class. However, between the Sx and
PCN-domain the traffic is treated in a class that can be ECN-marked.
When the traffic reaches the Rx, should any ECN-marking (that happened
before the PCN-domain) be preserved. 

[Joe] Two options, 1/ if the group decides to support the flow
termination method proposed in 3sm draft and assuming we agree on PCN
encoding where CE=flow terminate, than a CE marked packet can be
interoperate as this flow needs to be terminate. The ingress lets the
packet into as is and the egress open seeing flow termination (CE)
market packet does the flow termination procedure. 
2./ The PCN-ingress node open detecting CE market packet, drops the CE
marked packet.
Now I have a question for you, is the flow in question PCN-capable? If
yes than this is a case where a PCN-capable flow hits an ECN-capable
router and should be rate reduce. [joe end]

One possibility is that this is a scenario that we don't need to worry
about. If it is one we need to think about, then there are two
possibilities for how PCN WG could think about it:
[Joe] I think we need to worry about. [joe end].

(1) when such traffic reaches the PCN-domain, then tunnel it across the
PCN-domain. this means that upon decapsulation at the egress any ECN-CE
marking (that was there when the pkt reached the ingress) is preserved. 

[Joe] Why do you want to preserve ECN-CE marking of packet that is
PCN-capable? If the ECN-CE marked packet does not belong to PCN-capable
flow, that use a different DSCP and possible a service class within the
PCN-domain that also supports ECN traffic. 
My assumption is that the diffserv domain has at least two service
classes, a PCN-cable service class and others service class(es) for
non-PCN traffic. 
Tunnel would only be needed if there is only one service class and it
was PCN-cable. I do not believe we are proposing this.[joe end]

(2) devise an encoding scheme for PCN that preserves the ECN-CE marking.
these are the two possibilities i was trying to lay out in my original
email, ie
(1) deal with the issue in the architecture doc by saying a tunnelling
solution could be done to solve the problem 
(2) in the encoding-comparison doc, examine what the impact of this
would be on PCN-encoding (to inform the eventual choice of encoding)
[Joe] The encoding-comparison draft needs to discuss possible marking
interaction between ECN and PCN and propose combination(s) that best
meet guidelines in RFC 4774.
I think in the architecture draft we need to talk about the issue,
should look at RFC 4774 and see which case apply to PCN-domain.

Maybe, I'm missing something, but I do not think that we need to tunnel
ECN-marked traffic across PCN-domain. [joe end]
 
phil

Phil and all see below.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: July 26, 2007 4:35 PM
To: [email-masked]
Subject: [PCN] PCN & ECN-(congestion experienced) interactions

<trimmed>

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 28 Jul 2007 08:43:04 +0100

Michael,

I've cc'd the list - hope that's OK. Inline...

At 13:00 25/07/2007, Michael Menth wrote:
>Hi Bob,
>>I don't think the authors meant either of these implications. So 
>>somewhere, the relation between PCN & ECN marking should be stated.
>>
>>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.
>
>Are there applications using ECN in some networks and PCN in other 
>networks? If this is the case, reusing ECN bits might not be so good. On 
>the one hand, ECN markings could be taken into account by codecs to lower 
>their rate as congestion occurs in non-PCN-capable clouds. On the other 
>hand, ECN is intended for responsive elastic traffic and PCN for 
>non-responsive realtime traffic ...

The possibility of wanting admission controlled reservations and adaptive 
codecs is now officially a frequently asked question (it's been discussed 
twice before)! I'll just refer you to the extensive discussion of the issue 
on the tsvwg list at the back end of 2005:

One thread starts here - and quotes an offlist mail from 2004!
Subject: RMD & pre-congestion notification: How edge-edge and end-end can 
interwork
<http://www1.ietf.org/mail-archive/web/tsvwg/current/msg05775.html>

And another
Subject: why use edge-to-edge ECN re-marking when DSCP re-marking can do it.
This thread progressed onto the adaptation plus admission contrl issue at 
the end of this long posting:
<http://www1.ietf.org/mail-archive/web/tsvwg/current/msg05865.html>

We should write up this issue in the arch doc to document some form of 
agreement on this issue once and for all.

>Some other thoughts regarding the relation between ECN and PCN:
>http://www1.ietf.org/mail-archive/web/pcn/current/msg00534.html

Thanks for the pointer to previous list discussion. The basic answer to 
that discussion is that the lower threshold in the PCN virtual queue should 
be set so that there's v low probability of a real queue developing within 
a RTT of a level of PCN marking just below that necessary to trigger 
admission control.

The main difference in outcome between PCN and ECN is meant to be that PCN 
has v low risk of real queuing and hence low risk of any queueing delay 
beyond 1-2 packets.

>>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_.
>
>I am aware of the cases you mention. We look at time-dependent rates which 
>are hard to define anyway. I do not see a problem in this formulation 
>since it serves as an explanation, not as a technical specification which 
>may be approximative. Would adding the slack terms "within some tolerance" 
>improve the wording?

It wasn't so much that marking might still occur below the threshold rate, 
as that I didn't want the impression conveyed that we were concerned about 
just rate and not about variance. I'm in a rush now, but I'll try for some 
suggested wording - feel free to also suggest some yourself before I get to 
it. I think you know what I mean as much as I do, it's just word smithing 
needed.

>Either that or individual approaches need to explicitly clarify their 
>operation in case of ECMP. That's what I would prefer.

Yes - prob attempt to do this in each proposal I-D and on list first, and 
only go to a separate doc if we need to.

Bob