Subject: [PCN] Showstopper for merger of PCN SM and CL drafts

From: Tom Taylor <[email-masked]>
Date: Thu, 9 Dec 2010 12:46:17 -0500

I have just been reading a review that Toby Moncaster kindly provided 
for my proposed new merged SM + CL draft. It's that prickly issue of how 
to refer to [I-D.3in1]. The trouble is that [I-D.3in1] looks to be 
headed for Experimental track for the time being. This raises some sort 
of distinction between SM and CL, though I'm not quite sure what the 
significance is given that the edge behaviour drafts are Informational. 
Anyway, I suspect the difference means that SM and CL should be 
documented in separate drafts.

I'll look for some other way to fix the problem David identified. At the 
least, I'll clean up the unnecessary editorial differences. I wonder if 
it would work to put a marker in at each spot where the drafts must 
necessarily differ, for instance, by adding the phrase "For the SM 
boundary node behaviour", or "For the SM boundary node behaviour", as 
the case may be. I could also have an introductory note explaining that 
the two drafts are very similar and explaining the use of this marker.

Does this sound reasonable to you, David?

Tom Taylor

---

From: "Toby Moncaster" <[email-masked]>
Date: Thu, 9 Dec 2010 18:01:09 -0000

One possible (though not entirely elegant) solution to the 3-in-1 problem
would be to summarise 3-in-1 within this document in a very brief manner.
This could be as simple as:

"CL edge behaviour requires an additional PCN-codepoint to carry the
ThM-marking. This could be provided by utilising the EXP codepoint defined
in RFC5696, following the rules set out in section 5 of that document."

Really it doesn't matter how the PCN-markings are encoded. All that matters
is that CL requires there to be an additional marking state... And if these
are INFO documents then it may be less of an issue still (as we won't be
standardising anything "through the back door").

As far as I can see we have 3 things here: stuff that is common to both edge
behaviours; stuff that is common, but where the details differ (calculating
CLE is an obvious example); stuff that only applies to CL. That suggests to
me that we could write the document in two halfs. The first part specifies
SM, but with markers for where CL differs. The second part then specifies
the differences.

Toby

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Tom Taylor
> Sent: 09 December 2010 17:46
> To: pcn
> Subject: [PCN] Showstopper for merger of PCN SM and CL drafts
> 
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn

---

From: Michael Menth <[email-masked]>
Date: Thu, 09 Dec 2010 21:39:06 +0100

Hi Tom, hi David, hi Toby, and all,

> SM, but with markers for where CL differs. The second part then specifies

I fear that a description of CL based on differences to SM makes CL 
unnecessarily difficult to understand. That's why I do not think that 
this is a good approach, if I have understood it correctly. Apart from 
that, I find CL is even easier to understand than SM and explaining 
first the difficult method and then the simple one is not very efficient.

Apart from that, CL and SM are two incompatible approaches: it is not 
possible to run both of them in a single network. That might be another 
reason why they deserve to be described in two separate documents. It's 
a bit like two- and three-rate color marking (RFC 2697 and RFC 2698). 
They are different and it is much easier to express that by referring to 
two different RFC numbers.

Regards,

     Michael

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Wilhelm-Schickard-Institute
Lehrstuhl für Rechnernetze und Internet
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505, fax: (+49)-7071/29-5220
mailto:[email-masked], http://www.net2.uni-tuebingen.de

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 10 Dec 2010 12:20:15 +0100

Hi all 

I also agree with Michael and Tom that the CL and SM drafts sould be
specified in different documents.

 In addition to the listed arguments, I think that the functionalities and
assumptions used by CL and SM 
 PCN edge behaviour drafts are very different.

 In particular, they differ severely on the assumed core network 
 behaviour, see below (text copied from the CL and SM drafts).
 If they are merged, then this will severely impact the clarity of the 
 CL and SM specifications and the clarity of their applicability.

 Therefore, I think that these two specifications should be described 
 in two separate documents.
 
 -----------------------------------------
 2. Assumed Core Network Behaviour for SM
 
    This section describes the assumed behaviour for nodes of the PCN-
    domain when acting in their role as PCN-interior-nodes. The SM mode
    of operation assumes that:
 
    o PCN-interior-nodes perform excess-traffic-marking of packets
       according to the rules specified in [RFC5670].
 
    o excess-traffic-marking of packets uses the PCN-Marked (PM)
       codepoint defined in [RFC5696];
 
    o on each link the reference rate for the excess-traffic-meter is
       configured with a PCN-excess-rate to be equal to the PCN-
       admissible-rate for the link;

 -------------------------------------
 
 2. Assumed Core Network Behaviour for CL
 
    This section describes the assumed behaviour for nodes of the PCN-
    domain when acting in their role as PCN-interior-nodes. The CL mode
    of operation assumes that:
 
    o PCN-interior-nodes perform threshold-marking and excess-traffic-
       marking of packets according to the rules specified in [RFC5670],
       and any additional rules specified in the applicable encoding
       extension document;
 
    o encoding of PCN status within individual packets is based on
       [RFC5696], extended to provide a third PCN encoding state. A
       possible extension is documented in [ID.PCN3in1];
 
    o the PCN-domain satisfies the conditions specified in the
       applicable encoding extension document;

    o on each link the reference rate for the threshold-meter is
       configured to be equal to the PCN-admissible-rate for the link;
 
    o on each link the reference rate for the excess traffic meter is
       configured to be equal to the PCN-supportable-rate for the link;
 
    According to [RFC5696], the encoding extension documents should
    specify the allowable transitions between marking states. However,
    to be absolutely clear, these allowable transitions are specified
    here. At any interior node, the only permitted transitions are
    these:
 
    o a PCN-packet that is not-marked (NM) MAY be threshold-marked (ThM)
       or excess-traffic-marked (ETM);
 
    o a PCN-packet that is threshold-marked (ThM) MAY be excess-traffic-
       marked (ETM).
 
    An interior node MUST NOT perform any of the following:
    o re-mark a packet from PCN to non-PCN, or from non-PCN to PCN;
 
    o re-mark a PCN-packet from threshold-marked (ThM) to not-marked
       (NM);
 
    o re-mark a PCN-packet from excess-traffic-marked (ETM) to not-
      marked (NM) or threshold-marked (ThM).
 
--------------------- 

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Michael Menth
> Sent: donderdag 9 december 2010 21:39
> To: [email-masked]
> Subject: Re: [PCN] Showstopper for merger of PCN SM and CL drafts
> 
> > One possible (though not entirely elegant) solution to the 3-in-1 
> > problem would be to summarise 3-in-1 within this document 
> in a very brief manner.
> > ThM-marking. This could be provided by utilising the EXP codepoint 
> > defined in RFC5696, following the rules set out in section 
> 5 of that document."
> >
> > Really it doesn't matter how the PCN-markings are encoded. All that 
> > matters is that CL requires there to be an additional 
> marking state... 
> > And if these are INFO documents then it may be less of an 
> issue still 
> > (as we won't be standardising anything "through the back door").
> >
> > As far as I can see we have 3 things here: stuff that is common to 
> > both edge behaviours; stuff that is common, but where the details 
> > differ (calculating CLE is an obvious example); stuff that only 
> > applies to CL. That suggests to me that we could write the 
> document in 
> > two halfs. The first part specifies SM, but with markers 
> for where CL 
> > differs. The second part then specifies the differences.
> 
> I fear that a description of CL based on differences to SM 
> makes CL unnecessarily difficult to understand. That's why I 
> do not think that this is a good approach, if I have 
> understood it correctly. Apart from that, I find CL is even 
> easier to understand than SM and explaining first the 
> difficult method and then the simple one is not very efficient.
> 
> Apart from that, CL and SM are two incompatible approaches: 
> it is not possible to run both of them in a single network. 
> That might be another reason why they deserve to be described 
> in two separate documents. It's a bit like two- and 
> three-rate color marking (RFC 2697 and RFC 2698). 
> They are different and it is much easier to express that by 
> referring to two different RFC numbers.
> 
> Regards,
> 
>      Michael
> 
> > Toby
> >
> >> for my proposed new merged SM + CL draft. It's that 
> prickly issue of 
> >> how to refer to [I-D.3in1]. The trouble is that [I-D.3in1] 
> looks to 
> >> be headed for Experimental track for the time being. This 
> raises some 
> >> sort of distinction between SM and CL, though I'm not 
> quite sure what 
> >> the significance is given that the edge behaviour drafts are 
> >> Informational.
> >> I'll look for some other way to fix the problem David 
> identified. At 
> >> the least, I'll clean up the unnecessary editorial differences. I 
> >> wonder if it would work to put a marker in at each spot where the 
> >> drafts must necessarily differ, for instance, by adding the phrase 
> >> "For the SM boundary node behaviour", or "For the SM boundary node 
> >> behaviour", as the case may be. I could also have an introductory 
> >> note explaining that the two drafts are very similar and 
> explaining 
> >> the use of this marker.
> >>

---

From: "Toby Moncaster" <[email-masked]>
Date: Fri, 10 Dec 2010 16:29:24 -0000

Hi All,

I agree with much of what Michael says, and on balance feel that 2 documents
will make life easier for developers and vendors... 

See inline

> Michael Menth
> Sent: 09 December 2010 20:39
> To: [email-masked]
> problem
> defined
> matters
> both edge

TO be honest, these edge behaviour documents don't require an understanding
of the fine details of CL or SM, so it doesn't matter which one is easier to
understand... The only requirement is that the documents give clear guidance
to developers and operators regarding how to set variables and how to choose
whether to enable options or not.

> two different RFC numbers.

I think I agree with this point. Take a hypothetical situation: Vendor X
decides to build SM edge behaviour nodes and Vendor Y builds CL behaviour
nodes. Operator Z then buys equipment from both these vendors. Because Z is
not paying close attention he simply specifies that he wants compliance with
RFCnnnn (which is the combined specification). In this sort of case Z ends
up with kit that doesn't work together because he didn't realise RFCnnnn
specifies two variants of edge behaviour.

So to summarise, I think I am now in favour of two documents but written
with significant care to ensure there are no unnecessary differences of
wording between them. That should be quite easy to achieve now that Tom has
spent so much effort combining them (he can simply clone and cut out those
bits that don't apply). 

The 3-in-1 issue doesn't go away though, so it might be that CL would be
better left in limbo for a few months (perhaps left with RFC editor until
3-in-1 becomes an RFC). Alternatively the solution I suggest above might
work...

Toby

---

From: <[email-masked]>
Date: Mon, 13 Dec 2010 12:01:13 +0100

Hi Michael,

the incompatibility of both approaches is indeed an argument to have two separate
drafts, so I agree with you and the other PCN authors on the issue.

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: Thursday, December 09, 2010 9:39 PM
To: [email-masked]
Subject: Re: [PCN] Showstopper for merger of PCN SM and CL drafts

Regards,

     Michael