[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt
Michael
Thanks very much for your comments, very useful
Phil
{ -----Original Message-----
{ From: Michael Menth [mailto:menth at informatik.uni-wuerzburg.de]
{ Sent: 14 October 2008 23:25
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: Steven Blake; pcn
{ Subject: 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).
{
ok
{ ===================================================
{
{
{ Intro:
{
{ "than some configured rate ..." -> than its reference rate
{ (PCN-threshold-rate).
{ The same one line below ... (PCN-excess-rate).
{
ok
{ ===================================================
{
{
{ [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.
{
see other email, need someone else to answer this one.
{ ===================================================
{
{
{ 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.
{
ok, I'll delete measurement. Would like to keep the mention of aggregate
pcn-pkts on link (rather than per flow). Although this is implied by the
MUSTs later on, it might not be obvious to the fresh reader. I'll add to
your text above something like "The threshold meter operates on the
aggregate of all PCN-packets on the link, and not on an individual
flow."
{
{ ===================================================
{
{ 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.
Thanks. I struggled to get the phrasing nice, and I think your version
is better.
{
{ ===================================================
{
{ 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?
I'll try & re-phrase & will look at diffserv phrasing when get time. I
meant something like 'faster than the BA can schedule'.
{
{ ===================================================
{
{ 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
This was discussed extensively before. The current text represents the
WG consensus decision. Is there new information or argument that means
the WG consensus might change?
{
{ ===================================================
{
{ 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.
I'll add a pointer to the appendix where this is explained.
{
{
{ ===================================================
{
{ 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.
See other email. Thanks. This would reduce this section to just the
start: the list of bullets, plus:
A PCN-packet MUST be marked to reflect the metering results, by setting
its encoding state as specified by the specific encoding that applies in
the PCN-domain.
{
{ ===================================================
{
{ 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.
).
Although in isolation I also prefer exhaustive marking, in practice I
think having the names "exhaustive marking" and "excess traffic marking"
would be very confusing. They are just too similar names &
abbreviations.
I chatted with anna in Dublin about alternative names - but we failed to
think of anything better than threshold marking that didn't start 'ex'
On the subject of the addition of the terms admissible and supportable
rate to the architecture draft, so far I think we have 2 people in
favour, 2 against (excluding me) and everyone else indifferent or at
least silent.
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn