Re: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-09.txt

[<[e-mail]>]

Hi Adrian, Hi Russ, Hi Pete, Hi all,

We have submitted a new version of draft-ietf-pcn-encoding-comparison.
Please note that we have worked out all the DISCUSSES and comments in the following way: 
 
 DISCUSS and Comment from Adrian Farrel:
 ==========================================================================
 
 At 15:19 29/02/2012, Adrian Farrel wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 3.2.3
> 
> I cannot reconcile the text in option (1) that says:
> 
> with the conclusion of the section that says:
> 
> Option (1) seems to be the most viable and efficient solution.
> 
> If it is the intention of the PCN working group to be "PCN for IP-only
> networks" then I do think this could be s[elled out. OTOH, if MPLS is
> in scope, then surely option (1) is impractical.
> 
 
 Georgios: For clarity reasons, I am copying the text related to Option 1 and Option 3, described in Section 3.2.3.
 ==========
 1. Each Diffserv class using PCN uses a different set of DSCPs.
      Therefore, if there are M DSCPs using PCN and PCN encoding uses N 
      different DSCPs, N*M DSCPs are needed. This solution may work well
      in IP networks. However, when PCN is applied to MPLS networks or 
     other layers restricted to 8 QoS classes and codepoints, this 
      solution fails due to the extreme shortage of available DSCPs.
 
   3. PCN-traffic is tunneled across the PCN-domain. The pipe tunneling 
      model is applied and so the original DSCP is restored after
      decapsulation. However, tunneling across a PCN domain adds an 
      additional IP header and reduces the maximum transfer unit (MTU) 
      from the perspective of the user. GRE, MPLS, or Ethernet using 
      Pseudo-Wires are potential solutions that scale well also in
     backbone networks.
Option (1) seems to be the most viable and efficient solution. 
Regarding your observation that if MPLS is in scope, then surely option (1) is impractical, you are right. 
I think that we should emphasize that both Option (1) and Option (3) are viable, but both of them have drawbacks. 
So we would like to change the conclusion from:
 
 Change from:
 "Option (1) seems to be the most viable and efficient solution. "
 
 INTO:
The most appropriate option depends on the specific circumstances an operator faces. 
* Option 1 is most suitable unless there is a shortage of available DSCPs.
* Option 3 is suitable where the reduction of MTU is not liable to cause issues.
> Note that draft-ietf-pcn-3-in-1-encoding makes a specific statement
> about applicability only to IP.
Georgios: In our opinion, see also reply of Bob Briscoe to this DISCUSS, this is a simple misreading of the text at the end of the  Intro to draft-pcn-3-in-1-encoding (below). 
This merely says the normative parts of the 3-in-1 doc only concern encoding PCN in v4 & 
v6. It doesn't say PCN as a whole only concerns v4 & v6. Definitely not.
 
 " This document only concerns the PCN wire protocol encoding for IP
 headers, whether IPv4 or IPv6. It makes no changes or
 recommendations concerning algorithms for congestion marking or
 congestion response. Other documents will define the PCN wire
 protocol for other header types. Appendix C discusses a possible
 mapping between IP and MPLS.
"
 (BTW, PCN marking has been implemented in hardware for IP and MPLS.)
 
So, PCN is also open for use with other header types than IPv4 and IPv6. 

 
> 
> ---
> 
> What does "Primarily" mean in this context?
> 
> I would like you to replace the passive voice in Section 4.
> so I can tell who made the decision!
Georgios: We agree that the text in Section 4.5 is confusing, we would like to change the text from:
Change from:
"Primarily, it has been decided to take forward the baseline encoding, 
described in Section 4.1 and defined in RFC5696. Subsequently, it has 
been decided to take forward the 3-in-1 encoding, which is described 
in Section 4.2 and defined in [I-D.ietf-pcn-3-in-1-encoding]; as an 
RFC it would obsolete the baseline encoding."
INTO:
 
"The baseline encoding described in section 4.1 was published as a draft Internet Standard [RFC5696]. 
The intention was to allow for experimental encodings to build upon this baseline. 
However, following the publication of [RFC6040], the WG decided to change approach and instead standardise only 
one encoding (the 3-in-1 encoding described in 4.2 [draft-pcn-3-in-1]). Rather than defining the 3-in-1 encoding as a 
standards track extension to the existing baseline encoding [RFC5696], it was agreed that it was best to define 
a new standards track document that obsoletes [RFC5696]."
> 
> 
> 
> Additionally, I would like to understand why there are other 
> PCN working group documents for other encodings (draft-ietf-pcn-3-state-
> encoding, draft-ietf-pcn-psdm-encoding) if this 
> section represent a full statement of the WG's decisions.
 
 Georgios: This section refers to these documents to show the alternative encodings that have been taken into account by the PCN WG. 
Currently, there is no consensus in the PCN WG on the issue of whether the two following encodings drafts should be 
published as historical RFCs or be abandoned.
 http://tools.ietf.org/html/draft-ietf-pcn-psdm-encoding-01
 http://tools.ietf.org/html/draft-ietf-pcn-3-state-encoding-01

For the time being we reused the references to the expired I-Ds.

> 
> ---
> I'm afraid I found the conclusion in Section 5 particularly
> impenetrable.
> 
> Could you:
> - Break out "what we did in this document" as a separate > 
> paragraph.
> - Make a definitive statement about what the WG has 
> concluded.
> - Place the summary of the reasons for the conclusion as 
> a third paragraph.
 
Georgios: we would like to replace the text in Section 5, with the following text:
 
"5.  Conclusion
This document summarises the PCN Working Group's exploration of a number of approaches for encoding pre-congestion information into the IP header. It is presented as an informational archive. It provides details of all those approaches along with an explanation of the constraints that have to be met. 
The Working Group has concluded that the "3-in-1" encoding should be published as a standards-track RFC that obsoletes the encoding specified in [RFC5696].
The reasoning is as follows. During the early life of the working group, we decided on an approach of a standardised "baseline encoding" [RFC5696] plus a series of experimental encodings that would all build on the baseline encoding and each of which would be useful in specific circumstances. However, after the tunnelling of ECN was standardized in [RFC6040], the PCN WG decided on a different approach - to recommend just one encoding, the "3-in-1 encoding". Although in theory "3-in-1" could be specified as a standards-track extension to the "baseline" encoding, the WG decided that it would be cleaner to obsolete RFC5696 and specify "3-in-1" encoding in a new stand-alone RFC." 
> ------------------------------------------------------------->--------> -
> COMMENT:
> ------------------------------------------------------------->--------> -
> 
> In Section 1
>
> This requires at least three different codepoints for not-marked PCN 
> traffic, PCN traffic re-marked by the threshold- 
> marker, and PCN traffic re-marked by the excess-traffic- 
> marker.
>
> Please insert a colon after "codepoints" in order to fix the 
> meaning.
Georgios: We would like to change from:
"This PCN information has to be encoded into the IP header. This
requires at least three different codepoints for not-marked PCN
traffic, PCN traffic re-marked by the threshold-marker,
and PCN traffic re-marked by the excess-traffic-marker."
 INTO:
"This PCN information has to be encoded into the IP header. This requires at least three different codepoints: one for PCN traffic that has not been marked, one for traffic that has been marked by the threshold meter and one for traffic that has been marked by the excess-traffic-meter."
 
 
> 
> ---
> 
> In Section 1
> 
> This document summarizes these issues for historical  
> purposes.
> 
> Do you want to publish this as a Historic RFC?
 
 Georgios: No, we will replace this sentence with the following one:
 "This document summarises these issues as a record of the PCN WG discussions and for the benefit of the wider IETF community."
 
> 
> ---
> 
> Section 3
> 
> The Differentiated Services (DS) field is chosen for the  
> encoding of PCN marks.
> 
> This use of the passive voice is not helpful!
> 
> - Has the choice already been made? If so give a reference.
> - Does this document document the choice being made? If so 
> give a forward pointer or explanation.
> - Or is this just commentary? :-)
 
 Georgios:
Agree that the current text in the introductory part of Section 3 is not clear.
We would like to change the text from:
 
 "The Differentiated Services (DS) field is chosen for the encoding of
 PCN marks.  This section briefly reviews the DS field and the
 constraints imposed by its reuse are summarized."
 
 INTO:
 
 "The PCN WG decided to use the DS field (i.e., combination of the DSCP and ECN field) for the encoding of the PCN Marks, see [RFC5696]. 
This section describes the criteria that are used to compare the resulting encoding options described in section 4."
> 
> 
> ---
> 
> I think Section 3.1 makes [RFC0793], [RFC2474], and 
> [RFC3168] into normative references. 3.3.1 reinfotces that 
> for [RFC3168].
>
> Section 3.3 and 3.3.2 appear to make [RFC4774] normative.
 
Georgios: Agree, we list: [RFC0793], [RFC2474], [RFC3168], [RFC4774] as normative references. In order to do that we will create a new subsection in Section 9 on Normative References.
> 
> ---
> 
> Section 3.3.3.4 uses "CU" before it is explained in Seciton 
> 4 and defined in Section 4.3
 
Georgios: Agree, in ordert to solve this we will include the following text in Section 3.3.3.4:
"Certain combinations of inner and outer ECN fields cannot result from any transition in any current or previous ECN tunneling
specification.  These currently unused (CU) combinations are indicated in Figure 6 by '(!!!)' or '(!)', where '(!!!)' means the
combination is CU and always potentially dangerous, while '(!)' means it is CU and possibly dangerous."  
 
> 
>> 
>> ---
>> 
>> Section 4
>> 
>> Figure 7 summarizes these PCN encodings. as summarized
>> in Figure 7.
 
Georgios: Editorial error: we will remove “as summarized in Figure 7.” 
 
 =====================================================================================

DISCUSS of Russ Housley and comments from Pete McCann
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
> The Gen-ART Review by Pete McCann on 28-Feb-2012 raised an 
>  inconsistency that needs to be resolved.

> Section 3.3.3.4:
>   With the normal mode, the ECN field of the inner header is copied to
>    the ECN field of the outer header on encapsulation (like the limited
>    functionality option in Section 3.3.3.1).
> The limited functionality option says to set the outer header to not-ECT.
> This seems to contradict the above statement.
Georgios: We deleted/ (like the limited functionality option in Section 3.3.3.1)/
I also suggest the end of 3.3.3. needs to mention RFC6040, rather 
than waiting until 3.3.3.4, which otherwise looks like an afterthought.
OLD 3.3.3:
=====================================================================
                          Two different modes are defined in [RFC3168]
    for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec
    tunnels.
=====================================================================
NEW 3.3.3:
=====================================================================
                          Two different modes are defined in [RFC3168]
    for IP-in-IP tunnels and a third one in [RFC4301] for IP-in-IPsec
    tunnels. [RFC6040] updates both these RFCs to rationalise them into
    one consistent approach.
=====================================================================
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
> The Gen-ART Review by Pete McCann on 28-Feb-2012 included some
>  editorial suggestions that deserve consideration

> Section 3.3.3.3:
>    full-
>    functionality option in Section 3.3.2.2.
> I think you meant "Section 3.3.3.2".  One other place in this
> paragraph needs this correction.
Georgios: Modified!
> Section 4.2:
>   The problem with 3-in-1 encoding is that the 10-codepoint does not
>   survive decapsulation with the tunneling options in Section 3.3.2.1 -
>   3.3.2.3.
> Again, you meant 3.3.3.1 - 3.3.3.3
Georgios: Modified

==========================
Best regards,
Georgios

________________________________________
Van: [e-mail] [[e-mail]] namens [e-mail] [[e-mail]]
Verzonden: donderdag 8 maart 2012 22:00
Aan: [e-mail]
CC: [e-mail]
Onderwerp: [PCN] I-D Action: draft-ietf-pcn-encoding-comparison-09.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           : Overview of Pre-Congestion Notification Encoding
        Author(s)       : Georgios Karagiannis
                          Kwok Ho Chan
                          Toby Moncaster
                          Michael Menth
                          Philip Eardley
                          Bob Briscoe
        Filename        : draft-ietf-pcn-encoding-comparison-09.txt
        Pages           : 19
        Date            : 2012-03-08

   The objective of Pre-Congestion Notification (PCN) is to protect the
   quality of service (QoS) of inelastic flows within a Diffserv domain.
   On every link in the PCN domain, the overall rate of the PCN-traffic
   is metered, and PCN-packets are appropriately marked when certain
   configured rates are exceeded.  Egress nodes provide decision points
   with information about the PCN-marks of PCN-packets which allows them
   to take decisions about whether to admit or block a new flow request,
   and to terminate some already admitted flows during serious pre-
   congestion.

   The PCN Working Group explored a number of approaches for encoding
   this pre-congestion information into the IP header.  This document
   provides details of all those approaches along with an explanation of
   the constraints that had to be met by any solution.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-09.txt

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