Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-00.txt

From: [email-masked]
Date: Mon, 6 Jul 2009 16:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF.

	Title           : PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation
	Author(s)       : A. Charny, et al.
	Filename        : draft-ietf-pcn-cl-edge-behaviour-00.txt
	Pages           : 13
	Date            : 2009-07-06

Precongestion notification (PCN) is a means for protecting quality of
service for inelastic traffic admitted to a Diffserv domain.  The
overall PCN architecture is described in RFC 5559.  This memo is one
of a series describing possible boundary node behaviours for a PCN
domain.  The behaviour described here is that for three-state
measurement-based load control, known informally as Controlled Load
(CL).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 22 Jul 2009 18:24:21 +0100

Tom and co-authors,

Thanks for this draft.

Here's my immediate thoughts up to start of S.3.3 on p9 (further 
comments will follow when I don't have to dash):

1/ The draft needs to say explicitly at the start that some things 
will need to be standardised to aid interworking, while some things 
can be left for vendors and operators to turn into their competitive 
advantage. Then throughout, each item should decalre which it is:
- something essential for interworking,
- or an example that could be improved on.
As it stands, it's not clear what the purpose of describing all the pieces is.

Examples:
- excess-rate or threshold marking might initially trigger re-routing 
rather than respectively blocking or terminating flows. We can say 
this is possible, but we've not chosen to describe it here because it 
doesn't impact interworking.
- Smoothing algorithms could be an area for innovation
- Ditto for responding to flash crowds, etc

2/ As well as S.2 "Assumed Core Network Behaviour for CL", I felt the 
draft lacked a similar section "Assumed External Behaviour". All the 
actions seem to happen suspended in a vacuum, without saying what 
initiates them, or what carries messages between them. For instance, 
in 3.2.1 there are sentences saying "the egress reports that...", 
without saying what the report message is sent to.

We probably don't need to say signalling system X, but we could say 
signalling system with properties like X or Y, where X=RSVP and Y=NSIS (say).

3/ Perhaps we need to think about what the CL-edge-behaviour is not. 
Certainly it's different from single marking. But why? Certainly it's 
different from a RACF-compatible solution. But why? I think the 
essence of these answers is that:
- it's a solution that can potentially be completely distributed;
- it allows 2 threshold rates to be independently set on each 
interior node, so that an operator can tailor the config of different 
parts of the network (or have them all the same if that works)
- it is a way of putting together existing IETF standards without 
having to change them (or at least not significantly at all).

I think it could also do with a (very brief) summary in such a 
section of what the goal is that this PDB is contributing to - ie one 
domain of an e2e controlled load service.

4/ S.3.2.1.
It says that that CLE is _measured_ regularly. But then it gives a 
value with a justification as if the value is _reported_ regularly. 
They may need to be _measured_ regularly, but surely they only need 
to be reported when there's a flow signalling that it wants to start? 
I thought this was one aspect of the CL scenario that was different 
from, say, the RACF scenario? Or have I missed something.

There is a significant difference between regularly beaconed signals 
that have to have their own reliable delivery, and signals 
piggy-backed on flow signalling that already has reliable delivery 
(because if it doesn't arrive, the flow doesn't start).

"4.7. Environmental Concerns

    In some markets, traffic preemption is considered to be
    impermissible.  In such environments, flow termination would not be
    enabled.
"

[even tho I said I hadn't reviewed it this far, my eye was caught by 
this heading].
This could refer to a misunderstanding of the US regulations. In the 
US, the admission of one flow (even an emergency services flow) is 
not allowed to preempt another. But the operator is allowed to 
terminate flows when network capacity unexpectedly reduces - in order 
to preserve service. However, I'm not sure what the US position is 
regarding choosing what to terminate.

This is why we changed the terminology ages ago, from preemption to 
termination, which is what we meant. It otherwise unnecessarily rang 
alarm bells with people wary of the US regulations.

Nits

1. Introduction

s/the overall rate of PCN traffic is metered on every link/
  /the fill of a virtual queue for all PCN traffic on a link is metered/

[my point here is one I always harp on about: the threshold metering 
algo measures variance as much as average rate, because they are both 
important.]

1.1 Definition of CLE shouldn't go into such details of how it is 
measured (which are items of debate).

s/2. Assumed Core Network Behaviour for CL/
  /2. Assumed Interior Node Behaviour for CL/

3.1.
s/the PDP gives preference to this list when determining which flows 
to terminate/the PDP chooses flows to terminate from this list/
[preference is confusing as it implies a nice outcome for the chosen ones]

3.2.1 Altho it's generally agreed that the choice of CLE threshold 
value isn't sensitive, I think 0.5 is unnecessarily high - this would 
make the system a bit sluggish I would have thought. Would 1/8 be a 
better choice (to choose another arbitrary but round number in binary)?

Bob

At 00:45 07/07/2009, [email-masked] wrote:
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-00.txt>
>_______________________________________________
>PCN mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research

---

From: Michael Menth <[email-masked]>
Date: Wed, 22 Jul 2009 23:48:06 +0200

Hi Bob,

> - Smoothing algorithms could be an area for innovation
That's why it is important for admission control to signal from the 
egress to the ingress only admission-stop or admission-continue and keep 
the logic local to the egress node.

> - it allows 2 threshold rates to be independently set on each interior 
> node, so that an operator can tailor the config of different parts of 
> the network (or have them all the same if that works)
> I think it could also do with a (very brief) summary in such a section 
> of what the goal is that this PDB is contributing to - ie one domain 
> of an e2e controlled load service.
>
> 4/ S.3.2.1.
> They may need to be _measured_ regularly, but surely they only need to 
> be reported when there's a flow signalling that it wants to start? I 
> thought this was one aspect of the CL scenario that was different 
> US, the admission of one flow (even an emergency services flow) is not 
> allowed to preempt another. But the operator is allowed to terminate 
> flows when network capacity unexpectedly reduces - in order to 
> preserve service. However, I'm not sure what the US position is 
With CL, the exact value of the CLE is not really important since when 
the admissible rate on a link is exceeded, that value immediately jumps 
from 0 to 1. Unless you have ECMP and unmarked packets from other paths 
dilute the signal ...

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 23 Jul 2009 09:00:27 +0100

Michael,

I've reversed the order of the two points below, as one depends on the other...

At 22:48 22/07/2009, Michael Menth wrote:
>Bob Briscoe schrieb:
>>[BB] 3.2.1 Altho it's generally agreed that the choice of CLE 
>>threshold value isn't sensitive, I think 0.5 is unnecessarily high 
>>- this would make the system a bit sluggish I would have thought. 
>>Would 1/8 be a better choice (to choose another arbitrary but round 
>>number in binary)?
>[MM] With CL, the exact value of the CLE is not really important 
>since when the admissible rate on a link is exceeded, that value 
>immediately jumps from 0 to 1. Unless you have ECMP and unmarked 
>packets from other paths dilute the signal ...

Is this true with aggregated video traffic (or video + audio)? I 
believe the spikes in video (e.g. every time the action jumps to a 
new scene) and the general lumpiness don't all get smoothed out by 
aggregation. I don't recall the simulation results, but I thought the 
goal is that PCN threshold marking isn't just a rate-measuring 
machine, it's a rate and variance measuring machine.

Then, even if the average rate is well below the threshold rate, 
threshold marking can still block more admissions if the traffic 
variance is also high (which threatens the QoS of admitted flows). 
But if variance is low, the average rate can naturally be closer to 
the threshold rate.

If CLE does always toggle from 0 to 1, life would be easy, surely. 
Isn't the whole reason we're debating how to do EWMAs /hysteresis etc 
because CLE doesn't just toggle 0/1 in all circumstances.

>egress to the ingress only admission-stop or admission-continue and 
>keep the logic local to the egress node.

This is true if one assumes that CLE will effectively either be 0 or 
1. If values in between have some meaning, then the actual value of 
CLE might be important to the PDP.

But your point is a good one; it's no good reporting the CLE unless 
its meaning is standardised. Alternatively, if the meaning of the CLE 
isn't standardised, it makes more sense not to report it's exact 
value, just stop/go instead.

Should we standardise the meaning of CLE?

Bob

---

From: Michael Menth <[email-masked]>
Date: Thu, 23 Jul 2009 11:02:08 +0200

Bob,

Bob Briscoe schrieb:
>>> threshold value isn't sensitive, I think 0.5 is unnecessarily high - 
>>> this would make the system a bit sluggish I would have thought. 
> believe the spikes in video (e.g. every time the action jumps to a new 
> scene) and the general lumpiness don't all get smoothed out by 
Yes, all the token buckets are rate and variance measuring machines and 
the question is how much variance is allowed before admission should be 
stopped. What's a preliminary spike and what's the begin of an overload 
phase?

> variance is also high (which threatens the QoS of admitted flows). But 
> if variance is low, the average rate can naturally be closer to the 
> threshold rate.
Ok, I see what you mean. The question is what you want to do in such a 
situation. Admit or block. Then you can adapt the admit/block threshold 
accordingly. But I think all these are corner cases when the PCN traffic 
rate is around the threshold rate. BTW, "threshold rate" is a terrible 
term ...

> because CLE doesn't just toggle 0/1 in all circumstances.
The whole debate is about what to do when CLE goes up and down - not 
necessarily toggle 0/1. When one can live with a admit/block change 
within 200 ms, then it's fine to do nothing. And this demanding scenario 
is not the general case. We have this situation only when the system is 
in blocking mode which is rather seldom, but especially then it must work.

> Should we standardise the meaning of CLE?
The CLE has already a different meaning for CL and SM which cannot be 
unified.

Regards,

    Michael

---

From: Fortune HUANG <[email-masked]>
Date: Thu, 23 Jul 2009 17:49:16 +0800

Hi Michael and Bob,

>From the operation and management point of view, it would be better to have
the configuration of the the CLE threshold for stop or go on the PDP but not
on each egress node.

My first preference would be to have a unified standardized CLE for both CL
and SM if this is possible with some modifications in the current drafts.

If this is not possible, I prefer to have the standardized CLE for CL and SM
respectively. In this case, an extra information element indicating the type
(CL, SM, etc.) of CLE should be included in the report to PDP.

Best regards,
Fortune

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Menth
Sent: Thursday, July 23, 2009 5:02 PM
To: Bob Briscoe
Cc: [email-masked]
Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-00.txt

... ...

... ...