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

[Bob Briscoe <[e-mail]>]

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, [e-mail] wrote:
>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.
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-00.txt>
>_______________________________________________
>PCN mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcn

________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research