Subject: [PCN] AD Review: draft-ietf-pcn-sm-edge-behaviour-04

From: "David Harrington" <[email-masked]>
Date: Mon, 6 Dec 2010 15:29:14 -0500

Hi,

I have performed an AD Review of draft-ietf-pcn-sm-edge-behaviour-04
and have some comments.

1) As I reviewed both the SM and CL edge behavior documents, I noted
with concern how similar the documents are. I wonder if you wouldn't
be better having one document, with common text in the early chapters,
and then a section for SM and a section for CL. Or even three
documents, to pave the way for addiitonal behavior documents.

The real concern is that when you have so much common text, you need
to work hard to keep them consistent. An additional concern is that
the IETF (in LC) IESG (in IESG Eval) will need to review these docs,
and check that you haven't overlooked anything; the IETF and IESG
basically perform sanity checks. This is made harder when the text is
almost the same in the two documents. If the editorial text is just
slightly different in multiple places, it becomes much harder to find
the important differences between the documents. 

My concrn has been realized. There are many unimportant differences
between these two documents, that make comparing the two documents
more difficult than it should be, such as:
   such that PCN keep-alive signalling is redundant.
   such that PCN keep-alive is redundant.

   o  NM-rate: octets per second of PCN-traffic in PCN-packets that
are
      not-marked;
   o  NM-rate: octets per second of PCN-traffic in PCN-packets that
are
      not PCN-Marked;

   egress-node, and the Decision Point (which may be collocated with
the
   egress-node and the Decision Point (which may be collocated with
the

   The PCN-egress-node collects the rates of not-marked, threshold-
   marked, and excess-traffic-marked PCN-traffic for each ingress-
   egress-aggregate and reports them to the Decision Point.  It may
also
   The PCN-egress-node collects and reports the rates of not-marked
and
   excess-traffic-marked PCN-traffic to the Decision Point. 
** the sentence structure is unnecssarily different, which makes it
just a little bit harder to read what the technical difference is.

   PCN was that recovery from overloads through the use of flow
   termination should happen within 1-3 seconds.  PCN probably
performs
   better than that.
   PCN was that recovery from overloads by flow termination should
   happen within 1-3 seconds.  PCN probably does better than this.

   o  The marking rules for re-marking PCN-traffic leaving the PCN
   o  The marking rules for re-marking PCN traffic leaving the PCN

   The PCN SM per-domain behaviour may interfere with the use of
end-to-
   end ECN due to reuse of ECN bits for PCN marking.  See Appendix B
of
   [RFC5696] for details.
   The PCN CL per-domain behaviour may interfere with the use of
end-to-
   end ECN due to reuse of ECN bits for PCN marking.  See the
applicable
   PCN marking specifications for details.
dbh: is [5696] the applicable specs? or are there others? How does a
reader determine which specs are applicable?

   quality of service of inelastic flows within a Diffserv domain, in
a
   quality of service (QoS) of inelastic flows within a Diffserv
domain,

   allows decisions to be made on whether to admit or terminate PCN-
   decisions to be made about whether to admit or terminate individual

This editorial inconsistency could hide small, potentially important
technical differences, such as:
   o  ETM-rate: octets per second of PCN-traffic in PCN-packets that
are
      excess-traffic-marked.
   o  ETM-rate: octets per second of PCN traffic in PCN-Marked
packets.

   2.  The amount of traffic that should be terminated is the
       difference:
   2.  The amount of traffic that must be terminated is the
difference:

   choose to complete its selection of PCN-flows to terminate in a
   single round of decisions.
   choose to complete its selection of flows to terminate in a single
   round of decisions.

   node SHOULD cease to admit PCN-flows to the
ingress-egress-aggregate
   node SHOULD cease to admit flows to the ingress-egress-aggregate

   T-maxsuppress if report suppression is enabled, and of the order of
3
   T-maxsuppress if report suppression is activated, and of the order
of

   about incipient overloads before any congestion occurs (hence the
   about overloads before any congestion occurs (hence the "pre" part
of

   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;
   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;
   o  on each link the reference rate for the threshold-meter is
      configured to be equal to the PCN-admissible-rate for the link;

if you are going to have two documents with so much common text, I
will expect the editorial text to be consistent, so the technical
differences are clear.

2) Why are individual flow identifiers reported for
excess-traffic-marked PCN-traffic for CL but not for SM? Wouldn't this
be useful for both?

3) From Acknowledgements:    The authors thank Ruediger Geib for his
useful comments.  The acknowledgements in the CL boundary node
behaviour draft really apply here, too.
dbh: the CL draft is likely to be an RFC. If you want the
acknowledgement in both places, put it in both places.

4) I would be careful referencing other works-in-porgress, just in
case anything slows down the other document(s). No sense holding up
the publication of this document because another document runs into a
delay.

5) please check all lower-case RFC2119 keywords. The IESG prefers that
they be uppercased to make it clear they are normative. I recommend
using "might" rather than "may" for non-normative, and re-wording
musts, shoulds, and recommends to avoid using lowercased reserved
words.

6) section 3.2 and section 3.3.2 both present the formula for CLE, but
they present it differently. Just a style issue, but I recommend
presenting it consistently.

7) section 3.3 "The Decision Point MUST"; I recommend saying "A
compliant Decision Point MUST"

8) "PCN traffic" is used here, but where that term is defined is not
mentioned. Since this is used in formulae, that could be important to
understand correctly.

9) in 3.5, do we really need both t-meas and T-meas, etc.? The chart
would be easier to read if you eliminated one of the redundant
columns.

10) in Table 1, some word breaks are missing from the Action on Expiry
column. Put a space between conditionally and CLE, and between each
and IEA.

11) The acronym IEA is not defined before being used. 

12) t-maxsuppress has discussion of the value to use for an unreliable
transport; what is the recommended value for a reliable transport?

13) section 4 title has extra spaces.

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

---

From: Tom Taylor <[email-masked]>
Date: Mon, 6 Dec 2010 15:58:43 -0500

Thanks for your comments.

With the permission of the list, I will look at the possibility of 
merging the two documents. I think any other edge node behaviours will 
be fairly different from these two.

I have responses to some points below. The earlier stuff is snipped.

> I have performed an AD Review of draft-ietf-pcn-sm-edge-behaviour-04
...
> excess-traffic-marked PCN-traffic for CL but not for SM? Wouldn't this

[PTT] SM uses only excess-marking, and as a result, there won't 
necessarily be any flow termination when excess-traffic-marked flows are 
observed. Since flow termination is expected to be a relatively rare 
event, collecting and carrying flow identifiers would be a significant 
waste of resources.
> acknowledgement in both places, put it in both places.

[PTT] Good point.
> musts, shoulds, and recommends to avoid using lowercased reserved

[PTT] OK
> presenting it consistently.

[PTT] OK
> compliant Decision Point MUST"

[PTT] OK
> mentioned. Since this is used in formulae, that could be important to

[PTT] Will add a definition.
> would be easier to read if you eliminated one of the redundant

[PTT] Earlier versions didn't make the semantic distinction between 
timer variables and their limits and that led to confusion. I'll take 
another look at how this can be clarified.
> column. Put a space between conditionally and CLE, and between each

[PTT] IIRC that was xml2rfc's doing, though of course I'll check. As an 
xml2rfc maintainer I might put a bug report in.
> transport; what is the recommended value for a reliable transport?

[PTT] Thought that was covered. I'll have to check.
> 13) section 4 title has extra spaces.
[PTT] OK
> _______________________________________________
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
>
>

---

From: Michael Menth <[email-masked]>
Date: Mon, 06 Dec 2010 23:06:31 +0100

Hi David, hi Peter,

> necessarily be any flow termination when excess-traffic-marked flows 
> are observed. Since flow termination is expected to be a relatively 
> rare event, collecting and carrying flow identifiers would be a 
> significant waste of resources.

One can put it in other words. The problem is that SM re-marks traffic 
based on the admissible rate to indicate termination. Little re-marked 
traffic does not indicate termination but lots of re-marked traffic 
indicates termination.
1) When packets are re-marked, the supportable rate is not necessarily 
exceeded by PCN traffic. Then, termination is not needed. Signalling 
identifiers of re-marked flows in that case seems to be lots of overhead 
(as stated above).
2) In networks with multipath routing (only there providing information 
of re-marked flows is helpful), flows belonging to the same IEA may go 
over different paths where the PCN traffic rate exceeds the supportable 
rate of at least one link or where the PCN traffic rate exceeds the 
admissible rate of at least one link but not the supportable rate. In 
that scenario, the information that a flow was "re-marked" does not 
necessarily indicate that the re-marked flow is a candidate for 
termination. Providing identifiers of "re-marked" flows just increases 
the probability to terminate the right flows.
3) SM is not a good option anyway for networks with multipath routing, 
see 4.8.3 in
http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-Sub-9.pdf

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: Tue, 07 Dec 2010 07:37:57 +0000

Dear David

Thank you very much for the provided comments!

Regarding the first comment, if it is to either merge the two documents,
or merge and then again split the documents in three documents, then I
am in favour of the latter one.

One document could describe the common text, that will be the same for
all edge behaviour drafts. Other two documents could then be related to
CL and the to SM. These CL and SM documents could refer then to the
common document.

All new edge behaviour drafts should also use as much as possible the
common document.

Best regards,
Georgios

---

From: <[email-masked]>
Date: Tue, 7 Dec 2010 09:24:54 +0000

I'm happy to leave it to the editor to decide how to handle the first comment - Tom, whatever you think is the easiest way of handling (1, 2 or 3 docs).
	
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Georgios Karagiannis
Sent: 07 December 2010 07:38
To: David Harrington; [email-masked]
Subject: Re: [PCN] AD Review: draft-ietf-pcn-sm-edge-behaviour-04

Dear David

Best regards,
Georgios

---

From: "Toby Moncaster" <[email-masked]>
Date: Tue, 7 Dec 2010 09:35:16 -0000

As I see things the aim of RFCs should be to make life easy for vendors and
developers. The more RFCs that relate to a single technology, the harder it
is for people to be certain they are fully compliant.

Speaking for myself, I would find a single document easiest. That document
could be structured into three parts as Georgios suggests below. The only
issue then is that somewhere there will need to be some text to explain how
developers choose which scheme to go for, and mandating certain behaviours
as a result... This could be an interesting challenge for Tom...

Toby

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 07 December 2010 09:25
> To: [email-masked]; [email-masked]; [email-masked]
> I'm happy to leave it to the editor to decide how to handle the first
> comment - Tom, whatever you think is the easiest way of handling (1, 2
> or 3 docs).
>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 7 Dec 2010 08:45:53 -0500

CL and SM edge behaviours have the following attributes in common:
  - decisions based on aggregate flow measurements
  - message transport independent of per-flow signalling (i.e., RSVP)

Your own proposal for the HOSE model shared those attributes, but was 
forestalled by the core behaviour the Working Group chose to adopt.

The piggybacked edge behaviour differs in the proposed transport, and 
Michael's proposal differs because it would use individual probes rather 
than aggregate measurements.

My sense of the matter is therefore that the text we provide for the SM 
and CL edge behaviours will not be greatly reusable for the most 
probable other edge behaviours that might be developed.

...

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 07 Dec 2010 18:34:25 +0000

Hi Tom

Please do not include the HOSE model in the discussions, since this edge
behaviour draft is out of the scope of the PCN WG.

Regarding the other comments, if we use a common draft, then this draft
should describe the common terminology and the attributes associated
with the aggregated congestion and pre-congestion information from
within the domain, see also PCN charter:

"The Congestion and Pre-Congestion Notification (PCN) working group
develops mechanisms to protect the quality-of-service of established
inelastic flows within a DiffServ domain when congestion is imminent
or existing. These mechanisms operate at the domain boundary, based
on aggregated congestion and pre-congestion information from within
the domain."

Moreover, I do think that it is problematic to describe the SM and CL in
the same document. This is because the SM and CL edge behaviour drafts
differ severely on the assumed core network behaviour, see below (text
copied from the CL and SM drafts).
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];

-------------------------------------

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;

   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: Tom Taylor <[email-masked]>
Date: Tue, 7 Dec 2010 15:01:50 -0500

I'm working up a combined document, which I will first submit as an 
individual draft to see if it meets WG approval. The intention is that 
there will be no change to technical content aside from responding to 
any technical comments David made. I have finished the core assumptions 
section, and I actually think this is pretty clear. I'm more worried 
about the other parts of the document.

The combined document has too many authors. I've left myself in to 
expedite the submission process, but my intention is to leave an note to 
the RFC Editor relegating me to the Contributors section at the point of 
publication if they want to cut back.

...

---

From: "Toby Moncaster" <[email-masked]>
Date: Wed, 8 Dec 2010 14:19:20 -0000

Hi Tom,

> Tom Taylor
> Sent: 07 December 2010 20:02
> To: Georgios Karagiannis
> Cc: [email-masked]

As I said in an earlier response, the big issue is phrasing it so as to
clarify the MUSTs, SHOULDs, etc as they relate to each of the edge
behaviours...

If you want a review of stuff as you're writing it I hopefully will have
some time (and it shouldn't take me too long to reload context on PCN!). 

> publication if they want to cut back.

My own view would be that you should be listed as the main editor (as you
will have done a heck of a lot of work on the combined document). The
Contributors section can then make it clear that the document is a merger of
2 drafts and list the authors of those two drafts.

Toby