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

From: [email-masked]
Date: Mon, 21 Jun 2010 20:45:02 -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-03.txt
	Pages           : 17
	Date            : 2010-06-21

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 a form of
measurement-based load control using three PCN marking states, not
PCN-marked, threshold-marked, and excess-traffic-marked.  This
behaviour is known informally as the Controlled Load (CL) PCN edge
behaviour.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-03.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: Michael Menth <[email-masked]>
Date: Tue, 22 Jun 2010 14:53:30 +0200

Hi Tom,

according to the structure of the current draft, the big difference in 
reporting PCN data from egress to ingress (Section 3.2.2) is whether or 
not the CLE is included (see 3.2.2.1 and 3.2.2.2). I think that this is 
only a marginal issue. A major difference is whether reports are sent at 
the end of every measurement interval or whether some of them are 
suppressed. Would it be possible to have that reflected in 3.2.2?. Here 
is a draft proposal.

3.2.2 Egress Reports
Section 3.2.2.1 explains which data the PCN-egress-node includes in 
egress reports and when it sends egress reports. Section 3.2.2.2 
presents an optimization option that allows to reduce signalling traffic.

3.2.2.1 Reported Data

At the end of each measurement interval, the PCN-egress-node sends the 
following aggregate-specific data to the ingress node in an egress report:
o the rate of not-marked PCN traffic (NMR)
o the rate of threshold-marked PCN traffic (TMR)
o the rate of excess-traffic-marked PCN traffic (EMR)

In networks with multipath routing, the PCN-egress-node SHOULD record 
identifiers of all or only a subset of flows for which 
excess-traffic-marked packets have been observed.  The decision point 
may take advantage of this information when it selects flows for 
termination. In addition, the ingress node MAY calculate the CLE value 
from these data and include it in the report.

3.2.2.2 Signalling Reduction

The absence of pre-congestion is the normal operation mode of a network, 
and the egress node does not observe any threshold-marked or 
excess-traffic-marked packets. In this case, the reported rates are not 
of interest for the decision point. Thus, it suffices that the egress 
node sends reports only
 a) when it has observed threshold-marked or excess-traffic-marked 
packets and
 b) when it has observed only not-marked packets in the first 
measurement interval after a period on measurement intervals with 
re-marked packets.

In the absence of reports, the ingress node assumes that PCN data have 
not changed for the corresponding aggregate since the last egress 
report, i.e., that the egress node has observed only not-marked packets.

Egress reports may be lost and they are also a demonstration of liveness 
to the decision point. Therefore, egress reports MUST be sent when a 
report timer Treport has expired. Depending on the transport used for 
reporting,
the operator may choose to set value for the report timer Treport to an 
effectively infinite value. For example, the transport may include its 
own keep-alive signalling at a sufficiently frequent interval that 
liveness is not a concern for PCN.

Comments
o The reported rates and the calculation of the CLE should be defined in 
the terminology section.
    I used Treport instead of Tmax as it is more expressive.
o I suggest to rename the variables NM-rate, ThM-rate, ETM-rate to
    NMR: rate of not-marked PCN traffic in octects per second
    TMR: rate of theshold-marked PCN traffic in octets per second
    EMT: rate of excess-traffic-mared PCN traffic in octects per second
    Reason: ther is nothing like a "not-marked rate" and the expression 
does not reveal whether it's a packet or a traffic rate.
o Any other difference between the proposed text and the current draft 
is not intended. My intent is only to have clearer text.

Best wishes,

    Michael

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

-- 
PD Dr. habil. 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/31-86632 (new)
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Tom Taylor <[email-masked]>
Date: Tue, 22 Jun 2010 11:39:15 -0400

The use of marked vs. not-marked traffic as the suppression criterion in place 
of the zero-traffic and below-threshold CLE criteria is a good compromise, 
particularly for the CL edge behaviour. I'll reorganize along these lines. 
Calculation and reporting of CLE then becomes a purely optional affair -- a 
configurable decision whether to calculate CLE at the egress node or at the 
decision point. That will be another subsection following the one on signalling 
reduction. I was starting to worry about the number of configurable parameters, 
so it's good to get rid of one of them (CLErep) at least.

Michael Menth wrote:
> b) when it has observed only not-marked packets in the first measurement 
> interval after a period on measurement intervals with re-marked packets.
> 
...