Subject: [PCN] WGLC for draft-ietf-pcn-encoding-comparison-04.txt

From: Steven Blake <[email-masked]>
Date: Mon, 07 Mar 2011 23:35:39 -0500

This begins the WGLC for:
 
http://tools.ietf.org/html/draft-ietf-pcn-encoding-comparison-04

to end on Tuesday, March 22.  Please send comments to the list.

As a reminder, we are still in WGLC for
draft-ietf-pcn-3-in-1-encoding-04, to end next Monday.

Regards,
 
// Steve

---

From: <[email-masked]>
Date: Thu, 10 Mar 2011 12:09:06 +0000

Here are some comments:

S1 - please don't use abbreviations, especially ones not in 5559, in the Introduction.
AC, FT -> admission control, flow termination (twice)
AR, SR - suggest you rephrase to talk about threshold-marked and excess-traffic-marked (as this is what is explained in the previous paragraph - the admissible rate concept isn't explained and i don't think is needed at this stage)

S2.0 - spell out AC & FT

S2.2.1, line 3 under Fig 1, add "a per" after "performed on"

S2.2.2, last sentence p7, change from: The PCN-supportable-rate (SR) is only
   indirectly configured on any link by
to:
The PCN-supportable-rate (SR) is not configured on any link, but is implicitly:

S2.2.2, p8
" since threshold-marking is not available off the shelf."
I believe that some chipsets do support it
=> " since some chipsets do not yet support threshold-marking."

S2.2.3
I think it would be helpful to add after sentence 2 ("excess-traffic-marking (not-ETM)."):
Both not-Thm and not-ETM have the same NM-marking and are distinguished by higher layer information (see below).

S2.2.4
Thus, preferential dropping of ETM-marked packets is also recommended in [RFC5670].  
=> Thus, preferential dropping of ETM-marked packets is RECOMMENDED in [RFC5670].  

S3.2.2, P10 last sentence
when PCN encoding uses more than a single DSCP.
=> if PCN encoding used more than a single DSCP.

S3.2.3
I'm afraid I found this very tricky to understand, the nomenclature is difficult and i don't think needed. I suggest something on these lines:
It is desirable that the egress node restores the original DSCP when
   PCN traffic leaves the PCN domain.  This may be achieved through
   various options.
1. PCN-marking does not alter the DSCP; it only uses the ECN field. Therefore the traffic leaves the PCN-domain with its original DSCP.

However, if the PCN-marking may alter the DSCP, then some other technique is needed to restore the original DSCP:
2. 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.  The original DSCP for the Packets of a flow is signaled to
       the egress node.  No suitable signaling protocol has been developed and so it is not clear the approach works.
4.  PCN-traffic is tunneled across the PCN-domain. The pipe tunnelling 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.
Therefore option (1) is selected. 

S3.3.1
Figure 5 summarizes the codepoints defined in the ECN field.
=> Figure 5 summarizes the ECN codepoints defined [RFC3168].

S3.3.2.4 
Delete 'Option' in title (as RFC6040 is STD)

"[RFC6040] imposes new tunneling rules for ECN."
Add "and updates [3168] and [4301]" [since you've just been talking about these rfcs, i think it's worth pointing this out explicitly.]

S3.3.3
Title, EgressNode => PCN-egress-node

S3.3.4 line 1,
Do you mean 4774 rather than 2474?

S4
Tweak first para to:
The PCN WG has studied four different PCN encodings, which redefine
   the ECN field as summarized in Figure 7.  PCN semantics apply only to one or at most two
   specific DSCPs, and therefore ECN semantics do not apply to them. When a PCN-ingress-node classifies a packet as a PCN-packet it sets its PCN-codepoint to not-marked (NM). Non-PCN traffic can also to be sent with the PCN-specific DSCP, by setting the Not-PCN codepoint. Special per hop behaviour, defined in [RFC5670], applies to PCN-traffic.  

S4.1 para 2, this is not true. See S3.3 rfc5559. 1 codepoint allows either: CL & adm control only; CL & flow termination only; SM & both.

S4.2
Add at end of penultimate sentence:
"or where it is known that there are no tunnels in the PCN-domain"

S4.5
I think it's worth adding another section that says the WG selected 2 of these options to standardise
4.5 Standardised encodings
The working group decided to take forward two encodings to RFC status: baseline and 3-in-1 (Section 4.1, 4.2). The 3-in-1 encoding is on the standards track; RFC5696 only envisaged experimental use of the 10-codepoint and therefoe is updated by 3-in-1 encoding.

S5
I think it would be worth trying to remove the abbreviations from the conclusions. 
The last phrase is slightly misleading (see earlier), perhaps "as threshold-marking may not be supported by all vendors"

S6
I think this could be safely replaced by a reference to RFC5559. At least it seems to make the same points. 

I haven't carefully reviewed the Appendix. A quick scan suggested it seems ok but there are quite a few typos.
I wonder if the appendix could be replaced by a comment: "A longer discussions of the issues and some further encoding options that were considered can be found in the Appendix of [ref] (a pre-RFC version of this document)

Authors:
It is probably best to give Bob & my affiliation simply as "BT", as the unit name changes often.

Thanks
phil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Steven Blake
Sent: 08 March 2011 04:36
To: pcn
Subject: [PCN] WGLC for draft-ietf-pcn-encoding-comparison-04.txt

Regards,
 
// Steve

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 10 Mar 2011 13:58:11 +0100

Hi Phil

Many thanks for your comments!

Please see in line!

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: donderdag 10 maart 2011 13:09
> To: [email-masked]; [email-masked]
> Subject: Re: [PCN] WGLC for draft-ietf-pcn-encoding-comparison-04.txt
> 
> Here are some comments:
> 
 
Georgios: Okay!

> AR, SR 
> - suggest you rephrase to talk about threshold-marked and 
> excess-traffic-marked (as this is what is explained in the 
> previous paragraph - the admissible rate concept isn't 
> explained and i don't think is needed at this stage)

Georgios: You mean to change the text from:

"This requires at least three different codepoints for not-marked PCN
   traffic, PCN traffic re-marked by the marker configured with the AR,
   and PCN traffic re-marked by the marker configured with the SR."

INTO:

"This requires at least three different codepoints for not-marked PCN
   traffic, PCN traffic re-marked by the marker to threshold-marked,
   and PCN traffic re-marked by the marker to excess-traffic-marked."

> S2.0 - spell out AC & FT

Georgios: Okay!

> S2.2.1, line 3 under Fig 1, add "a per" after "performed on"

Georgios: Okay!

> The PCN-supportable-rate (SR) is not configured on any link, 

Georgios: Okay!

> I believe that some chipsets do support it => " since some 
> chipsets do not yet support threshold-marking."

Georgios: Okay!

> Both not-Thm and not-ETM have the same NM-marking and are 
> distinguished by higher layer information (see below).
> 
> S2.2.4

Georgios: Okay!

> => if PCN encoding used more than a single DSCP.

Georgios: Okay!

> 
> S3.2.3
> I'm afraid I found this very tricky to understand, the 
> nomenclature is difficult and i don't think needed. I suggest 
> something on these lines:
> 1. PCN-marking does not alter the DSCP; it only uses the ECN 
> field. Therefore the traffic leaves the PCN-domain with its 
> original DSCP.
> 
> However, if the PCN-marking may alter the DSCP, then some 
> other technique is needed to restore the original DSCP:
> 2. 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
>        the egress node.  No suitable signaling protocol has 
> been developed and so it is not clear the approach works.
> 4.  PCN-traffic is tunneled across the PCN-domain. The pipe 
> tunnelling model is applied and so the original DSCP is 
> restored after decapsulation.

Georgios: Okay!

> => Figure 5 summarizes the ECN codepoints defined [RFC3168].

Georgios: Okay!

> Add "and updates [3168] and [4301]" [since you've just been 
> talking about these rfcs, i think it's worth pointing this 
> out explicitly.]

Georgios: Okay!

> Title, EgressNode => PCN-egress-node

Georgios: Okay!

> Do you mean 4774 rather than 2474?

Georgios: Yes, of course! Good catch!

>    specific DSCPs, and therefore ECN semantics do not apply 
> to them. When a PCN-ingress-node classifies a packet as a 
> PCN-packet it sets its PCN-codepoint to not-marked (NM). 
> Non-PCN traffic can also to be sent with the PCN-specific 
> DSCP, by setting the Not-PCN codepoint. Special per hop 
> behaviour, defined in [RFC5670], applies to PCN-traffic.  
> 
> S4.1 para 2, this is not true. See S3.3 rfc5559. 1 codepoint 
> allows either: CL & adm control only; CL & flow termination 
> only; SM & both.

Georgios: Okay!

> "or where it is known that there are no tunnels in the PCN-domain"

Georgios: Okay!

> 
> S4.5
> I think it's worth adding another section that says the WG 
> selected 2 of these options to standardise
> The working group decided to take forward two encodings to 
> RFC status: baseline and 3-in-1 (Section 4.1, 4.2). The 
> 3-in-1 encoding is on the standards track; RFC5696 only 
> envisaged experimental use of the 10-codepoint and therefoe 
> is updated by 3-in-1 encoding.

Georgios: Okay!

> The last phrase is slightly misleading (see earlier), perhaps 
> "as threshold-marking may not be supported by all vendors"

Georgios: Okay!

> 
> S6
> I think this could be safely replaced by a reference to 
> RFC5559. At least it seems to make the same points. 

Georgios: You mean remove all text from S6 and refer to the security
implications section given in [RFC5559]

> 
> I haven't carefully reviewed the Appendix. A quick scan 
> suggested it seems ok but there are quite a few typos.
> I wonder if the appendix could be replaced by a comment: "A 
> longer discussions of the issues and some further encoding 
> options that were considered can be found in the Appendix of 
> [ref] (a pre-RFC version of this document)

Georgios: I would very much appreciate to keep the appndices, since they are
providing an historical account on the examination of
   all possible  ways to encode pre-congestion notification (PCN)
   [RFC5559] information in IP packets.
I think that this is also what we decided to do when we moved all this text
in Appendices.

> "BT", as the unit name changes often.

Georgios: Okay!

Best regards,
Georgios

---

From: <[email-masked]>
Date: Thu, 10 Mar 2011 13:20:23 +0000

Yes, you interpret me right.

Thanks
phil

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: 10 March 2011 12:58
To: Eardley,PL,Philip,DES8 R; [email-masked]; [email-masked]
Subject: RE: [PCN] WGLC for draft-ietf-pcn-encoding-comparison-04.txt

Hi Phil

Please see in line!

Georgios: Okay!

INTO:

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Georgios: Okay!

Best regards,
Georgios

> Behalf Of Steven Blake

---

From: Steven Blake <[email-masked]>
Date: Sun, 20 Mar 2011 23:49:26 -0400

> draft-ietf-pcn-3-in-1-encoding-04, to end next Monday.

I've seen comments from Phil only (and responses from Georgios).  Would
others please speak up?

Regards,

// Steve

---

From: Michael Menth <[email-masked]>
Date: Mon, 21 Mar 2011 17:47:51 +0100

Hi all,

I reviewed the encoding-comparison draft. I have mainly a few editorial 
comments that can be found in the attached document.

not-PCN, not-marked, currently unused: upper- or lowercase? Consistency 
needs to be checked! My preference is lowercase.

I did not understand the Security section. It needs a major rewrite. 
What are PCN End Nodes?

I browsed over the Appendix. I find it rather irrelevant. It is rather 
misleading than helpful and should be dropped.

Apart from that, I find the document very informative.

Best wishes,

     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: Mon, 21 Mar 2011 17:03:22 +0000

Your comments look good to me.

In my comments, for the security section i suggested replacing with a ref to rfc 5559, as it seems to cover the same points (but the text has been worked out better there). I think it would be ok just to say "This document introduces no additional security issues compared to [ref]."

Am inclined to agree with you about the appendix, but there's a difference of opinion - we should discuss in prague. (At the very least, at the moment it would create a large amount of work for the rfc editor as there are dozens of typos etc.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Menth
Sent: 21 March 2011 16:48
To: Steven Blake; [email-masked]
Subject: Re: [PCN] WGLC for draft-ietf-pcn-encoding-comparison-04.txt

Hi all,

I reviewed the encoding-comparison draft. I have mainly a few editorial comments that can be found in the attached document.

not-PCN, not-marked, currently unused: upper- or lowercase? Consistency needs to be checked! My preference is lowercase.

I browsed over the Appendix. I find it rather irrelevant. It is rather misleading than helpful and should be dropped.

Best wishes,

     Michael