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

[Michael Menth <[e-mail]>]

Hi Bob,

Bob Briscoe schrieb:
> 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
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.


> - 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)?
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

>
>
> 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
> _______________________________________________
> PCN mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcn

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: [phone] (new), fax: [phone]
mailto:[e-mail]
http://www3.informatik.uni-wuerzburg.de/research/ngn