Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt

From: [email-masked]
Date: Thu, 2 Oct 2008 05: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           : 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 15:29:19 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 02 October 2008 13:45
{ To: [email-masked]
{ Cc: [email-masked]
{ 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
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: Tina TSOU <[email-masked]>
Date: Fri, 03 Oct 2008 19:11:02 +0800

Hi,
By what kind of policy the flow termination is performed? Which flow  
belonging which user will be terminated? Is it implementation dependent?

B. R.
Tina

---

From: <[email-masked]>
Date: Mon, 13 Oct 2008 16:34:01 +0100

Hi Tina 
I think this is down to the operator of the PCN-domain to decide (so I
guess it is "implementation dependent"). Anyway, it doesn't seem
appropriate to standardise such policy decisions.
Thanks
phil

{ -----Original Message-----
{ From: Tina TSOU [mailto:[email-masked]]
{ Sent: 03 October 2008 12:11
{ To: Eardley,PL,Philip,CXR9 R
{ Cc: [email-masked]
{ Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-00.txt
{ 
{ Hi,
{ By what kind of policy the flow termination is performed? Which flow
{ belonging which user will be terminated? Is it implementation
dependent?
{ 
{ 
{ B. R.
{ Tina
{ 
{ 
{ 
{ On Oct 2, 2008, at 10:29 PM, [email-masked] 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: [email-masked] [mailto:[email-masked]] On Behalf
{ > Of
{ > { [email-masked]
{ > { Sent: 02 October 2008 13:45
{ > { To: [email-masked]
{ > { Cc: [email-masked]
{ > { 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
{ > [email-masked]
{ > https://www.ietf.org/mailman/listinfo/pcn

---

From: Steven Blake <[email-masked]>
Date: Tue, 14 Oct 2008 08:38:50 -0400

We want to advance this document quickly.  Please come to Minneapolis
with comments prepared.  Or better yet, send them to the list ASAP.

> { implementation to automatically retrieve the ASCII version of the

Regards,

// Steve

---

From: Michael Menth <[email-masked]>
Date: Wed, 15 Oct 2008 00:25:26 +0200

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

-- 
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:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 11:31:31 +0100

Please can a 3168 expert answer this comment from Michael. I think the
text may have come from bob (or I mangled his text)/
thanks 
{ ===================================================
{ 
{ 
{ [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 text appears in the Intro & in full is
[RFC3168]
   defines a broadly RED-like default congestion marking behaviour, but
   allows alternatives to be defined; this document defines such an
   alternative.

---

From: <[email-masked]>
Date: Wed, 15 Oct 2008 12:23:29 +0100

Michael

Thanks very much for your comments, very useful
Phil

{ -----Original Message-----
{ From: Michael Menth [mailto:[email-masked]]
{ 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

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.

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 16 Oct 2008 16:21:36 +0100

Phil, Michael,

RFC3168 is primarly in two parts. The spec for IP, and the spec for TCP.

The IP part applies regardless of whether ECN is used e2e or 
proxy-end or proxy-proxy or edge-edge or whatever.

The TCP part applies e2e.

Just because 3168 ECN in IP was spec'd with TCP as the transport, it 
was not just intended to be used e2e. It is in this sense that the 
PCN marking draft is equivalent to the use of an AQM like RED to 
introduce explicit congestion notification.

According to Sally Floyd (when I asked her about why the two had been 
put in one spec) she initially intended 3168 to be split between 
network & transport. But the IESG wanted to make sure that ECN didn't 
get implemented in IP without saying how it should be responded to by 
the transport. Otherwise it could have created an unsafe situation if 
people wrote their own transports to use the new IP-ECN facility 
without any guidance for how it should be used. The TCP part of 3168 
was intended to not only be the spec for TCP, but guidance on doing 
something similar in other e2e transports. Sally told me they had 
other edge-edge transports in mind when writing 3168, but they would 
be deferred for later definition.

Bob

>text may have come from bob (or I mangled his text)/

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196