Subject: [PCN] Additional formulation to illustrate PCN encoding types

From: Michael Menth <[email-masked]>
Date: Thu, 02 Jun 2011 22:29:57 +0200

Hi all,

here is my interpretation of Option B. It is probably more restrictive 
than the general formulation, but defining four PCN-encoding types 
simplifies talking about them. Names ma be changed. Bob, please correct 
me if I am wrong!

In the following, four different types of PCN encoding are presented. 
The codepoints are labeled with the type-specific meaning, and the 
type-specific transition diagram is given that indicates how 
excess-traffic-marking and threshold-marking re-mark the codepoint if 
their meters indicate to re-mark a packet.

1. ETM-baseline (used for excess-traffic-marking only)

00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = 
excess-traffic-marked (ETM)

    excess-traffic-marker
10 ---------------------> 11

2. ThM-baseline (used for threshold-marking only)

00 = not-PCN, 10 = not-marked (NM), 10 = not-used (NU), 11 = 
threshold-marked (ThM)

    threshold-marker
10 --------------------> 11

3. 3-in-1 (extension of ETM-baseline, used for parallel use of 
excess-traffic-marking and threshold-marking in networks with only 
RFC6040-compliant tunnel decapsulators)

00 = not-PCN, 10 = not-marked (NM), 10 = threshold-marked (ThM), 11 = 
excess-traffic-marked (ETM)

          excess-traffic-marker
  +-------------------------------------+
  |                                     |
  |                                     V
10 -----------> 01 -----------------> 11
    threshold-      excess-traffic-
      marker            marker

4. PSDM (extension of ETM-baseline, used for parallel use of 
excess-traffic-marking and threshold-marking in networks with 
non-RFC6040-compliant tunnel decapsulators)

00 = not-PCN, 10 = not-excess-traffic-marked (NETM), 10 = 
not-threshold-marked (NThM), 11 = marked (M)

       excess-traffic-marker
  +----------------------------+
  |                            |
  |                            V
10       10 ---------------> 11
             threshold-marker

All four types are designed in a way that

o excess-traffic-metering MUST count the bytes of all 10- and 01-marked 
packets.
o threshold-metering MUST count the bytes of all 10-, 01-, and 11-marked 
packets.
o 11 indicates most severe pre-congestion. If packets need to be dropped 
in case of overload, existing edge behaviors [CL, SM] require that 
11-marked packet SHOULD preferentially be dropped.

Example uses

o In SM, nodes work with ETM-baseline.
o In CL, nodes work with 3-in-1 and with ETM-baseline if they do not 
perform threshold-marking.
o In PSDM-PCN, nodes work with PSDM-encoding and with ETM-baseline if 
they do not perform threshold-marking.
o The AC-subset of CL works with nodes that perform only 
threshold-marking and ThM-baseline.

Regards,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://www-kn.informatik.uni-tuebingen.de

---

From: <[email-masked]>
Date: Fri, 3 Jun 2011 09:15:09 +0100

Sort of...

(note you have a typo, as you have '10' twice in each case)

BUT
Option B was suggesting that Threshold Meter SHOULD mark 01 (bit it MUST have the ability to be reconfigured to mark 11)
Bob is suggesting that a case when the SHOULD may not apply is when you have non 6040 tunnels inside your PCN-domain; the default choice is single (excess) marking, but you could also do either your option 2 or 4 below - note Option 2 & 4 both break the SHOULD)

The way you have written it below has a quite different emphasis (a series of options of equal merit)

Personally I'm inclined to think allowing the flexibility is not worth it (but open to persuasion)
I'm also inclined to think that it is disguising one form of flexibility (psdm) in a way that is not obvious, so would need spelling out in an illustrative appendix.
	
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: 02 June 2011 21:30
To: [email-masked]
Subject: [PCN] Additional formulation to illustrate PCN encoding types

Hi all,

    excess-traffic-marker

    threshold-marker

          excess-traffic-marker

       excess-traffic-marker

Example uses

Regards,

     Michael

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

---

From: <[email-masked]>
Date: Fri, 3 Jun 2011 09:23:25 +0100

[phil]
Just to be exact, 5670 says that
o  PCN-packets that arrive at the PCN-node already excess-traffic-
      marked SHOULD be preferentially dropped.

---

From: Michael Menth <[email-masked]>
Date: Fri, 03 Jun 2011 10:28:57 +0200

Yes, RFC5670 should be added as reference here.

---

From: Michael Menth <[email-masked]>
Date: Fri, 03 Jun 2011 10:38:56 +0200

Hi Phil,

yes, the cases should be ordered in a different way. I believe that it 
is most important to give them names so tat manufacturers can say what 
type of PCN encoding their equipment supports.

I'd say that ETM-baseline and 3-in-1 are MUST for implementations 
supporting systems with excess traffic marking and threshold marking 
while ThM-baseline and PSDM may also be provided in order to allow for 
PCN implementations with pre-RFC6040 network support.

Best wishes,

     Michael

Am 03.06.2011 10:15, schrieb [email-masked]:
> Bob is suggesting that a case when the SHOULD may not apply is when you have non 6040 tunnels inside your PCN-domain; the default choice is single (excess) marking, but you could also do either your option 2 or 4 below - note Option 2&  4 both break the SHOULD)
>

---

From: <[email-masked]>
Date: Fri, 3 Jun 2011 10:08:05 +0100

We need to be exact.
Option B doesn't say "may also be provided". It says 
Threshold marking SHOULD mark 01 but MUST be able to mark 11

I dont mind us discussing Option C, D.... but let's be clear what we're discussing

I suggest we first discuss which Option we want to go forward with, then we discuss how to phrase it 

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: 03 June 2011 09:39
To: Eardley,PL,Philip,DES8 R
Cc: [email-masked]
Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types

Hi Phil,

Best wishes,

     Michael

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 3 Jun 2011 10:27:29 +0100

Unless I've got the wrong end of the stick, there seems to be a consensus
that something akin to Option B is favoured. The debate seems to be about
how can we limit any additional complexity whilst still holding the door
open to alternative marking schemes...

 I am keen that we shouldn't lock this down too hard because I don't want to
slip into the usual IETF trap of having a standard that blocks future
development. However I want to make it as easy as possible for vendors to
see what we recommend as the default behaviour.

Incidentally Michael, I am not 100% sure that PSDM survives all pre-6040
tunnels. Make sure you read 6040 really carefully and look at all the
possible transitions that existed before then. I am sure I came across one
that was bad for the ECT(1) codepoint...

Final note to everyone: The NM codepoint is (and always will be) 10 which
corresponds to ECT(0) in ECN. It's that way round (rather than 01) because
originally it was a pair of flags for ECT and CE... So all our discussions
are about the meaning of the 01 codepoint (or ECT(1)).

Toby

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 03 June 2011 10:08
> To: [email-masked]
> Cc: [email-masked]
> > Option B was suggesting that Threshold Meter SHOULD mark 01 (bit it
> MUST have the ability to be reconfigured to mark 11)
> > Bob is suggesting that a case when the SHOULD may not apply is when
> you have non 6040 tunnels inside your PCN-domain; the default choice is
> single (excess) marking, but you could also do either your option 2 or
> 4 below - note Option 2&  4 both break the SHOULD)
> >
> > I'm also inclined to think that it is disguising one form of
> flexibility (psdm) in a way that is not obvious, so would need spelling
> out in an illustrative appendix.
> >

---

From: Michael Menth <[email-masked]>
Date: Fri, 03 Jun 2011 18:08:48 +0200

Hi Phil,

> We need to be exact.
Clarity is what I want to achieve ...

> Threshold marking SHOULD mark 01 but MUST be able to mark 11
The latter sentence looks like a contradiction, especially if we say in 
addiction that the MUST-case is not recommended ... That's why I think 
it is nececcary to give an explantation that boils this down to concrete 
PCN encodings and say which of them is a MUST and which of them is not 
so necessary if we want to rank them for whatever reason.

Best wishes,

     Michael

---

From: <[email-masked]>
Date: Fri, 3 Jun 2011 18:22:45 +0100

The first thing is to choose between

Option A:

* The Threshold Marker MUST mark 01
* The Excess Traffic Marker MUST mark 11

Option B

* The Threshold meter SHOULD mark 01 
* The Threshold meter MUST be able to be configured instead to mark 11 (ie not follow the SHOULD. Why? pre-6040 tunnels etc), 
* The Excess Traffic meter MUST mark 11

Option C
Something else

Pros and cons:
Option A:
Simple
But only choice in pre-6040 environment is Single marking (or accept that PCN-marking is effectively switched off along the tunnel)

Option B:
Allows some flexibility (*) 
But requires meter/marker to have ability to be configured; requires operator to configure all PCN-nodes correctly.

(*)in a pre-6040 environment, you can break the SHOULD, and either just mark with the Threshold meter to 11 (excess traffic meter off, admission control but no flow termination) - or you can do PSDM, with the threshold meter marking 01 to 11, and excess traffic meter marking 10 to 11)

I am somewhat uncertain what this flexibility actually means. For example, 
- a vendor could build a compliant meter/marker that doesn't do psdm (it does the 'either' option in the previous para)
- another vendor could build a compliant meter/marker that does do psdm (it does the or' option in the previous para, but not the 'either' option)
- the operator could therefore buy compliant kit from the two vendors which would not interoperate (to the extent that in a pre-6040 environment it would only be able to do Single marking)
The basic issue is that psdm has to do additional BA aggregate classification (not just 'is it a PCN-pkt?' but also 'is it a not-marked PCN-pkt open for threshold marking, or a not-marked PCN-pkt open for excess traffic marking?')

So the question is whether we just say " The Threshold meter MUST be able to be configured instead to mark 11" (and leave it to the vendor and operator to discuss what exactly this MUST means) or we say something more explicit:-
a. threshold marker MUST be able to be configured to mark 10 to 11 (instead of the default, 10 to 01) and (presumably) the excess traffic marker is switched off [corresponds to the 'either' option of the (*) para]
b. threshold marker MUST be able to be configured instead to mark 01 to 11 and excess traffic marker MUST be able to be configured _not_ to mark 01 to 11 [corresponds to the 'or' option of the (*) para]
c. MUST be able to do both a & b

I think "a" is quite a small change for a vendor and probably doesnt cause too many issues if the operator misconfigures, so is probably OK to require/allow this.
Whereas "b" seems a bigger change for a vendor and probably leads to significant issues if the operator misconfigures, so I'm not convinced this is flexibility that we should require/allow.

phil

-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: 03 June 2011 17:09
To: Eardley,PL,Philip,DES8 R
Cc: [email-masked]
Subject: Re: [PCN] Additional formulation to illustrate PCN encoding types

Hi Phil,

Best wishes,

     Michael

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 3 Jun 2011 20:35:48 +0100

I think this comes down to - it is easy to formulate clear text that allows
for PCN-domains where only ThM is used, and where the 11 codepoint means
ThM. Once one starts trying to allow for PSDM the text has to become more
complex and you start to create potential issues as Phil outlines below.

So the question to the WG has to be do we want to explicitly create support
for PSDM in this encoding or not?

Toby

> Sent: 03 June 2011 18:23
> * The Threshold meter MUST be able to be configured instead to mark 11
> (ie not follow the SHOULD. Why? pre-6040 tunnels etc),
> But only choice in pre-6040 environment is Single marking (or accept
> that PCN-marking is effectively switched off along the tunnel)
> 
> Option B:
> But requires meter/marker to have ability to be configured; requires
> operator to configure all PCN-nodes correctly.
> 
> (*)in a pre-6040 environment, you can break the SHOULD, and either just
> mark with the Threshold meter to 11 (excess traffic meter off,
> admission control but no flow termination) - or you can do PSDM, with
> the threshold meter marking 01 to 11, and excess traffic meter marking
> 10 to 11)
> 
> - a vendor could build a compliant meter/marker that doesn't do psdm
> (it does the 'either' option in the previous para)
> - another vendor could build a compliant meter/marker that does do psdm
> (it does the or' option in the previous para, but not the 'either'
> option)
> - the operator could therefore buy compliant kit from the two vendors
> which would not interoperate (to the extent that in a pre-6040
> environment it would only be able to do Single marking)
> The basic issue is that psdm has to do additional BA aggregate
> classification (not just 'is it a PCN-pkt?' but also 'is it a not-
> marked PCN-pkt open for threshold marking, or a not-marked PCN-pkt open
> for excess traffic marking?')
> 
> So the question is whether we just say " The Threshold meter MUST be
> able to be configured instead to mark 11" (and leave it to the vendor
> and operator to discuss what exactly this MUST means) or we say
> something more explicit:-
> a. threshold marker MUST be able to be configured to mark 10 to 11
> (instead of the default, 10 to 01) and (presumably) the excess traffic
> marker is switched off [corresponds to the 'either' option of the (*)
> para]
> b. threshold marker MUST be able to be configured instead to mark 01 to
> 11 and excess traffic marker MUST be able to be configured _not_ to
> mark 01 to 11 [corresponds to the 'or' option of the (*) para]
> I think "a" is quite a small change for a vendor and probably doesnt
> cause too many issues if the operator misconfigures, so is probably OK
> to require/allow this.
> Whereas "b" seems a bigger change for a vendor and probably leads to
> significant issues if the operator misconfigures, so I'm not convinced
> this is flexibility that we should require/allow.
> 
> phil
>