Subject: Re: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 2 Oct 2008 07:31:45 +0200

Hi

Some comments on the draft: 
Typos:
Section 3: thatn -> than
Appendix C: shoudl -> should (2 occurences)

Other:
Section 4.1: "increasingly short supply", could be a lack of
understanding of the english language from my side. Even though I
(believe I) understand the phrase I suspect that it may be confusing.
Anyway please dismiss this protest if you like. 

Appendix C: Bullets 3 and 4: I am not quite sure that I get the
difference between 3 and 4 when I read the text alone: I guess that in
3) the decision (admission control and termination) is done (in
PCN-ingress/egress-nodes) based on the ratio between NM and PM while in
4) a dedicated PCN codepoint (AM or TM) is set in the PCN-interior-nodes
based on load, quueue length et.c. Is this interpretation correct ?

Regards
Ingemar

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: den 30 september 2008 18:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.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           : Baseline Encoding and Transport of 
> Pre-Congestion Information
> 	Author(s)       : T. Moncaster, et al.
> 	Filename        : draft-ietf-pcn-baseline-encoding-00.txt
> 	Pages           : 12
> 	Date            : 2008-09-30
> 
> Pre-congestion notification (PCN) provides information to 
> support admission control and flow termination in order to 
> protect the Quality of Service of inelastic flows.  It does 
> this by marking packets when traffic load on a link is 
> approaching or has exceeded a threshold below the physical 
> link rate.  This document specifies how such marks are to be 
> encoded into the IP header.  The baseline encoding described 
> here provides for only two PCN encoding states.
> It is designed to be easily extensible to provide more 
> encoding states but such schemes will be described in other documents.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-en
> coding-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 12:00:07 +0100

Hi Ingemar,

Thanks for the comments. I will incorporate them in the next version
which will hopefully be published shortly.

Regarding Appendix C bullets 3 & 4. These are trying to do two things -
specify the action needed if you want to mark a packet (set it to PM)
and clarify what happens if an unexpected codepoint is seen (treat it as
NM). This second bit is perhaps not needed as it is reasonable to expect
operators to ensure they don't misconfigured networks...

Toby

-----Original Message-----
From: Ingemar Johansson S [mailto:[email-masked]] 
Sent: 02 October 2008 06:32
To: Moncaster,T,Toby,CXR9 R; [email-masked]
Subject: RE: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt

Hi

Other:

Regards
Ingemar

---

From: <[email-masked]>
Date: Tue, 14 Oct 2008 11:41:38 +0100

Toby
Some comments

1. I think there should be a section about how the baseline encoding
restricts the EXPTAL encoding extensions. I think these restrictions are
the following MUSTs:
- 1 dscp or two defined as a pair
- 00 is not-PCN
- 11 is (some kind of) PCN-marking
- 11 mustn't be changed by interior node.
Basically the restrictions explain what we mean by "extension to
baseline" rather than a whole new encoding. They hopefully mean that
migration requirements are eased, ie if a pcn-domain is using the
baseline and upgrades to extension, it isn't too disastrous if some
nodes are still using baseline. I think this is a reasonable
requirement. 

2. it might be nice to have a picture of encoding transitions in (or
near) Appendix B.1. just to make it graphic. Some people I think have
asked for a transitions pic, and it makes more sense to me to include
this in the encoding draft than in the marking draft. Drawing a
transitions pic for the baseline encoding should be easy; maybe could
include one for extensions as well, although this is slightly trickier. 
I think the pics could be informative, and the text normative if
necessary 

3. other suggestions:-

Intro:
Changes section should refer to WG -00

Terminology
PCN-capable or PCN-enabled?

4.1
Refer to the codepoint as 11 (it's only CE in 3168)
Add some rationale for NM =10 rather than 01 (or say, "it makes no odds,
but a choice has to be made")

8.
Conclusions mention about end-to-end ECN support. This should appear
earlier eg S5

Appendixes:
At start of each say whether normative or informative

App B:
Rephrase as active tense (A PCN-interior-node MUST...)
The PCN-egress one - re-phrase as a "MUST unless.." (rather than a
"SHOULD.. only exception)

B.1: 
Downgrading is no longer mentioned in marking behaviour draft

A few other typos /suggestions I'll give to you on paper

Thanks
Phil/ 

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 02 October 2008 12:00
{ To: [email-masked]; [email-masked]
{ Subject: Re: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt
{ 
{ Hi Ingemar,
{ 
{ Thanks for the comments. I will incorporate them in the next version
{ which will hopefully be published shortly.
{ 
{ Regarding Appendix C bullets 3 & 4. These are trying to do two things
-
{ specify the action needed if you want to mark a packet (set it to PM)
{ and clarify what happens if an unexpected codepoint is seen (treat it
as
{ NM). This second bit is perhaps not needed as it is reasonable to
expect
{ operators to ensure they don't misconfigured networks...
{ 
{ Toby
{ 
{ -----Original Message-----
{ From: Ingemar Johansson S [mailto:[email-masked]]
{ Sent: 02 October 2008 06:32
{ To: Moncaster,T,Toby,CXR9 R; [email-masked]
{ Subject: RE: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt
{ 
{ Hi
{ 
{ Some comments on the draft:
{ Typos:
{ Section 3: thatn -> than
{ Appendix C: shoudl -> should (2 occurences)
{ 
{ Other:
{ Section 4.1: "increasingly short supply", could be a lack of
{ understanding of the english language from my side. Even though I
{ (believe I) understand the phrase I suspect that it may be confusing.
{ Anyway please dismiss this protest if you like.
{ 
{ Appendix C: Bullets 3 and 4: I am not quite sure that I get the
{ difference between 3 and 4 when I read the text alone: I guess that in
{ 3) the decision (admission control and termination) is done (in
{ PCN-ingress/egress-nodes) based on the ratio between NM and PM while
in
{ 4) a dedicated PCN codepoint (AM or TM) is set in the
PCN-interior-nodes
{ based on load, quueue length et.c. Is this interpretation correct ?
{ 
{ Regards
{ Ingemar
{ 
{ 
{ > -----Original Message-----
{ > From: [email-masked] [mailto:[email-masked]] On
{ > Behalf Of [email-masked]
{ > Sent: den 30 september 2008 18:00
{ > To: [email-masked]
{ > Cc: [email-masked]
{ > Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.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           : Baseline Encoding and Transport of
{ > Pre-Congestion Information
{ > 	Author(s)       : T. Moncaster, et al.
{ > 	Filename        : draft-ietf-pcn-baseline-encoding-00.txt
{ > 	Pages           : 12
{ > 	Date            : 2008-09-30
{ >
{ > Pre-congestion notification (PCN) provides information to
{ > support admission control and flow termination in order to
{ > protect the Quality of Service of inelastic flows.  It does
{ > this by marking packets when traffic load on a link is
{ > approaching or has exceeded a threshold below the physical
{ > link rate.  This document specifies how such marks are to be
{ > encoded into the IP header.  The baseline encoding described
{ > here provides for only two PCN encoding states.
{ > It is designed to be easily extensible to provide more
{ > encoding states but such schemes will be described in other
documents.
{ >
{ > A URL for this Internet-Draft is:
{ > http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-en
{ > coding-00.txt
{ >
{ > Internet-Drafts are also available by anonymous FTP at:
{ > ftp://ftp.ietf.org/internet-drafts/
{ >
{ > Below is the data which will enable a MIME compliant mail
{ > reader implementation to automatically retrieve the ASCII
{ > version of the Internet-Draft.
{ >
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn