[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt
Hi Phil and all,
I've got some comments on the marking document.
===================================================
The abstract talks about a first and a second rate. Better: Threshold
marking marks all PCN-packets if the PCN traffic rate is greater than
its configured reference rate (PCN-threshold-rate). Excess marking
marks a proportion of PCN-packets, such that the amount of unmarked
packets equals the rate of its configured reference rate (PCN-excess-rate).
===================================================
Intro:
"than some configured rate ..." -> than its reference rate
(PCN-threshold-rate).
The same one line below ... (PCN-excess-rate).
===================================================
[RFC3168] ... ; this document defines such an alternative.
Disagree: PCN marking is not intended to be delivered to end systems and
is, therefore, it is not an alternative RED-like default congestion
marking. The only commonality between RED-like marking and
threshold/excess marking is that they re-mark the same codepoints.
===================================================
The explanation of meter talks about measurements which is misleading at
this point of the document. Of course, later in the document is stated
that this does not tell anything about the implementation. Just try
another formulation avoiding the work measurement. Better:
o Threshold meter: determine whether the rate of all PCN-packets on a link is
greater than its configured PCN-threshold-rate.
o Excess traffic meter: measure by how much the rate of PCN-packets on a link
is greater than its configured PCN-excess-rate.
===================================================
o Competing-non-PCN-packet: a non PCN-packet that competes for the
same capacity as PCN-traffic. "Capacity" means the forwarding
bandwidth on a link; "competes" means that competing-non-PCN-
packets will delay PCN-packets in the queue for the link.
Competing-non-PCN-packets MUST NOT be PCN-marked (ie only PCN-
packets can be PCN-marked). Note: In general it is not advised to
have any competing-non-PCN-traffic.
This is hard to understand. In addition, this is not precise as with any
non-preemptive scheduling any non-PCN-traffic can delay non-PCN-traffic.
Better:
Competing-non-PCN-packet: a non-PCN-packet sharing a link with PCN-packets
and competing with them for its forwarding bandwidth. "Competing" means
that it can be elected for transmission in spite of waiting PCN-packets.
...
Section 2.1 similar case.
===================================================
Section 2.2
o metering all metered-packets to determine if the level of metered-
traffic is sufficiently high to overload the PCN behaviour
aggregate. (According to [RFC2475] metering is "the process of
measuring the temporal properties (eg rate) of a traffic stream".)
What does "to overload the PCN behaviour aggregate" mean?
===================================================
If the PCN-node drops PCN-packets then:
o PCN-packets that arrive at the PCN-node already excess-traffic-
marked SHOULD be preferentially dropped;
This default behavior significantly delays direct measured rate
termination (DMRT) as well as marked flow termination (see Section
IV.B of [1] and Section V.D.4 of [2]). Thus, if these termination
methods should be further considered as options, there must be a choice
that unmarked PCN packets are dropped preferentially.
The presented drop preference is only beneficial for
indirect measured rate termination (IMRT). However, the implementation
of IMRT is quite complex as it needs to correlate distributed measurements
and biased measurement intervals can lead to overtermination
(see Section IV.B of [1]). Therefore, I find it risky to close the door
for other termination methods by recommending only preferential dropping
of marked packets.
[1] http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-Sub-9.pdf
[2] http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf
===================================================
Section 2.4
In addition to the above, if the token bucket is within an MTU of
being empty, then the meter SHOULD indicate to the Marking function
that the packet is to be excess-traffic-marked; MTU means the maximum
size of PCN-packets on the link. Otherwise the meter MUST NOT
indicate marking.
Some statement should say that this choice has been made to achieve
packet-size-independent marking.
===================================================
Section 2.5
This section describes the required joint behavior of excess and threshold
markers in specific deployment scenarios. Doing that in the main body of
the documents sounds like excluding other use, e.g. for packet-specific dual
marking which allows the implementation of a CL-like admission control and
flow termination with only a single DSCP. I suggest decoupling the description
of the meter and marker functions from their joint behavior which depends on
the specific encoding.
===================================================
General
"Threshold marking" is not a good name for the algorithm. The name was a working
name in some email conversations of Anna and me. It was inspired by the fact that
the token bucket based mechanism used a threshold to trigger the marking, the
name was tight to the specific token bucket implementation, not well deliberated
and not intended for eternal use. There are several reasons why a different name
should be chosen:
1) This document explicitly states that no special implementation should be mandated.
2) Also implementations of excess traffic marking use thresholds, e.g. for implementing the MTU check.
3) The name threshold marking does not say what the algorithm does. Therefore, I propose exhaustive marking.
I do not see why an obviously bad nomenclature should be used if better
nomenclature exists. It prevents people from memorizing what the marking behavior does
which is important for quickly understanding the technology. Ok, this last note is
a matter of style. It is important but not as important as the introduction of an
admissible and supportable rate in the architecture draft to allow for a description of
the PCN concept independently of any specific deployment scenario.
Regards,
Michael
Steven Blake wrote:
We want to advance this document quickly. Please come to Minneapolis
with comments prepared. Or better yet, send them to the list ASAP.
On Thu, 2008-10-02 at 15:29 +0100, philip.eardley at bt.com wrote:
Hi,
This is the update to the marking behaviour draft, which (I think)
includes all the discussion we had on the list and in Dublin about the
previous version (draft-eardley-pan-marking-behaviour-01)
Summary of changes:
o Removed material concerning per domain behaviour and PCN-boundary-
node operation (temporarily archived to Appendix C)
it was agreed that this draft should be just about the 'per-hop'
behaviour.
We need a draft about the per-domain behaviour. This will be very short,
eg saying that all nodes in the PCN-domain have to be configured to do
the same type of marking, the same choice about encoding states, do
policing at the ingress-node etc. ietf-pcn-baseline-encoding Appendix B
also indicates some things that the PCN-boundary-nodes need to do.
I (& Toby) don't have time to write this per-domain behaviour draft
(hoping for volunteer(s)!)
There's also the Info edge behaviour draft or drafts. Some of the
material in Appendix C might be useful for that.
o Removed mention of downgrading as an option for per-hop traffic
conditioning. In fact, downgrading is no longer allowed because S
2.6 now says "A PCN-node MUST NOT ...change a PCN-packet into a
non PCN-packet".
o Traffic conditioning is now a MAY. Since in general flow
termination (not traffic conditioning) is PCN's method for
handling problems of too much traffic.
I think I got the conclusion on this right, but would appreciate people
checking. I think a MAY captures best our conclusion (rather than a
SHOULD or not talking about it all)
o Metered-packets: competing-non-PCN-packets now MAY be metered.
Since it is recommended that the operator doesn't allow any
competing-non-PCN-traffic, and (if there is) there are potentially
other ways of coping.
This was the discussion with Christian recently about Section 6.5 of the
architecture draft.
In the previous draft, it was a MUST to meter these
competing-non-PCN-packets. This seems onerous when we also recommend
that there is no such traffic.
o No changes (outside traffic conditioning & metering of competing-
non-PCN-traffic) to the Normative sections of the draft.
o Appendix B.1 added about competing-non-PCN-traffic. Recommended
that there is no such traffic, but guidance given if there is.
Sorry this has taken me longer than expected to get out.
I'll do another rev before Minneapolis. I believe (or at least hope!)
that it'll then be ready for last call/
Best wishes
phil
{ -----Original Message-----
{ From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
{ Internet-Drafts at ietf.org
{ Sent: 02 October 2008 13:45
{ To: i-d-announce at ietf.org
{ Cc: pcn at ietf.org
{ Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt
{
{ 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 : Marking behaviour of PCN-nodes
{ Author(s) : P. Eardley
{ Filename : draft-ietf-pcn-marking-behaviour-00.txt
{ Pages : 22
{ Date : 2008-10-02
{
{ This document standardises the two marking behaviours of PCN-nodes:
{ threshold marking and excess traffic marking. Threshold marking
{ marks all PCN-packets if the PCN traffic rate is greater than a first
{ configured rate. Excess traffic marking marks a proportion of PCN-
{ packets, such that the amount marked equals the traffic rate in
{ excess of a second configured rate.Requirements Language
{
{ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
{ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
{ document are to be interpreted as described in RFC 2119 [RFC2119].
{
{ A URL for this Internet-Draft is:
{ http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-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.
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn
Regards,
// Steve
_______________________________________________
PCN mailing list
PCN at ietf.org
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: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:menth at informatik.uni-wuerzburg.de
http://www3.informatik.uni-wuerzburg.de/research/ngn
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn