Subject: [PCN] proposed status for 3-in-1 and basleine

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 2 Jun 2011 15:51:58 +0100

Hi All,

The authors of draft-ietf-pcn-3-in-1-encoding have been trying to figure out
exactly what to do regarding the potential conflict between this and the
baseline encoding RFC5696.

We still haven't reached complete agreement, but we seem to be moving
closer. At this stage it seems appropriate to get the WG to comment and
decide whether they agree with our proposals or not. 

The problem is twofold - firstly, if both of these become a standard there
will be a conflict over the definition of the 01 codepoint (EXP in RFC5696
and ThM in 3-in-1). Secondly, as it stands 3-in-1 makes it hard for an
operator to choose to only run threshold marking in their domain (unless
they can be certain that all tunnel endpoints are fully compliant with
RFC6040).

Our 2 proposed solutions are as follows:

Both options require RFC5696 to be obsolete and key parts of the text of
that RFC to be moved into the new 3-in-1. In both options:

* 00 MUST indicate Not PCN
* 10 MUST indicate Not Marked (NM)

Option A:

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

Option B

* The Threshold meter SHOULD mark 01 but MUST be able to mark 11, however
the second option is NOT RECOMMENDED. If the Threshold marker does mark 11
then nodes in the
PCN-domain MUST NOT be marking using the excess traffic meter (since that
meter needs to know which packets had already been marked ETM).

* The Excess Traffic meter MUST mark 11

Option A is what 3-in-1 currently says. This restricts ThM to only ever
marking 01 and thus risking being lost in a tunnel that isn't compliant with
RFC6040 normal mode.

Option B holds open the door for operators wishing to use only threshold
marking but wanting to not worry about which tunnels are running. 

It was Bob's suggestion to define this in terms of what the traffic meter
functions do, rather than the other way round. This allows us to be flexible
with the definition of threshold marking (although the text of RFC5670 makes
it harder to do the same for excess traffic marking as it assumes that an
ETM packet is a defined entity).

I personally prefer option B and I believe Bob also favours that option. I
am not clear what Michael's position is but I know he is uneasy about
obsoleting RFC5696.

We would welcome feedback from the WG, especially from those members with
significant experience of updating and revising standards...

Toby

---

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

Hi all,

> * The Excess Traffic meter MUST mark 11

This text is designed in a way to keep the door open for baseline 
encoding applied for threshold marking and for PSDM - which is good. So 
if this is the case, I agree 100% about the contents, but I do not agree 
about the formulation for two reasons:
1) It is so complicated that only experts know what this formulation is 
good for.
2) It allows for different options without naming them. Therefore, 
referring to this formulation alone does not create a clear standard 
since it is difficult to describe which option is needed for a specific 
edge behavior.

Therefore, I suggest to give names to the options and clarify or 
illustrate that text in some form. I'll propose such text in a separate 
email.

Regards,

     Michael

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

-- 
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:17:36 +0100

[phil]
This can be done by having a short Normative section with Bob-style text and a longer Informative appendix with Mcihael-style text. That also helps explain what the Normative text means.

---

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

...

Option B

[phil]
Toby, did you mean this? (psdm does do both threshold and excess traffic marking)

---

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

Hi Phil,

> Toby, did you mean this? (psdm does do both threshold and excess traffic marking)
Yes, psdm (packet-specific dual marking) supports both threshold and 
excess-traffic-marking, but for different packets.

When reading the last sentence again, I realize that this conflicts with 
psdm. It should rather be formulated as follows:

The Threshold meter SHOULD mark 01 but MUST be able to mark 11, however 
the second option is NOT RECOMMENDED. If the Threshold marker does mark 
11 then nodes in the PCN-domain MUST NOT be marking * the same set of 
packets * using the excess traffic meter (since that meter needs to know 
which packets had already been marked ETM).

That probably reflects Bob's intention.

Best wishes,

     Michael

---

From: <[email-masked]>
Date: Wed, 8 Jun 2011 10:19:28 +0200

Hi Michael, Phil and Toby

it may be useful to add a brief statement which marking method should be used. The implementation options alone may be to worrying. PSDM may require more than a single sentence.

To sum up:

- 3 in 1 is the SHOULD behaviour (ThM 10 -> 01).
- SM MUST be supported, but is NOT RECOMMENDED (10 -> 11). If pre-6040 is the
  better justification, use that or use SM and pre-6040 as justification.
- Other marking behaviours beside 3 in 1 and SM/pre-6040 MAY be specified.

If it is roughly that, is adding three sentences in the text about option B sufficient
(not excluding an appendix containing more discussion)?

Michael, you now assume the ThM to mark to 11 in the case of
http://tools.ietf.org/html/draft-menth-pcn-marked-signaling-ac-00.
and in the case of PSDM. Is that correct?

You'd like to be able to enhance the above with a termination option, so you require
an additional codepoint and a specific marking behaviour.

Let's keep in mind that 11 also MUST bear the more severe indication of congestion.
Then combining marked signaling with any kind of termination requires 11 to be
the codepoint for termination.
But your concern isn't just the codepoint - you are concerned about the marking
algorithm. Correct? As stated above, a different marking algorithm MAY be specified.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Friday, June 03, 2011 6:36 PM
To: [email-masked]
Subject: Re: [PCN] proposed status for 3-in-1 and basleine

Hi Phil,

Best wishes,

     Michael