Subject: [PCN] FW: New Version Notification for draft-moncaster-pcn-baseline-encoding-00

From: <[email-masked]>
Date: Thu, 15 May 2008 16:31:43 +0100

Hi All,

I have just posted an initial attempt at a standards track encoding
document to allow two PCN encoding states (as agreed in the voting on
this list). I have included Michael Menth and Bob Briscoe as authors on
this as it is based on the work we all did at the last IETF.

Please can people try and read this and let me have any comments. The
key aim of the document is to specify the baseline encoding in such a
manner that it allows the experimental extension (with three encoding
states) to exist without contradiction. It achieves this by splitting
the behaviour into core behaviour,  behaviour at edge nodes and
behaviour at interior nodes.

I am currently trying to finish writing the initial draft for the
experimental extension to three encoding states. I am having some
difficulty putting it in clear English but hope to be able to post an
early version next week.

Ideally I am hoping that we can get at least this baseline encoding
accepted as a WG document by early June and can get it into WGLC before
the Dublin IETF.

Toby

____________________________________________________________________
Toby Moncaster, <[email-masked]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 15 May 2008 16:23
To: Moncaster,T,Toby,CXR9 R
Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
Subject: New Version Notification for
draft-moncaster-pcn-baseline-encoding-00 

A new version of I-D, draft-moncaster-pcn-baseline-encoding-00.txt has
been successfuly submitted by T Moncaster and posted to the IETF
repository.

Filename:	 draft-moncaster-pcn-baseline-encoding
Revision:	 00
Title:		 Encoding and Transport of (Pre-)Congestion Information
from within a DiffServ Domain to the Egress
Creation_date:	 2008-05-15
WG ID:		 Independent Submission
Number_of_pages: 10

Abstract:
Pre-congestion notification (PCN) is a mechanism designed 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 two PCN encoding states.

Status

This memo is posted as an Internet-Draft with an intent to eventually
progress to standards track.

The IETF Secretariat.

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

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 21 May 2008 12:32:35 +0200

Hi Toby,

thanks for your draft, which specifies the basic PCN encoding 
pretty well. A few minor comments below.

Regards,

Rudiger

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

Minor: Section 4. Encoding two PCN states in IP

first bullet point
...."To conserve DSCPs, DiffServ Codepoints
     SHOULD be chosen that are already defined for use 
     with admission controlled traffic, such as the 
     Voice-Admit codepoint defined in [voice-admit]."

[RG] Not-PCN combined with Voice-Admit then means that 
a domain supports another admission control scheme 
than PCN in the backbone? But may make sense if a 
flow passes different domains and some of them don't 
support PCN.

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

Minor: 4.2.  PCN-Enabled DiffServ Codepoints

Second section, second sentence

   ...."The scheduling behaviour used for a packet
   does not change whether PCN is enabled for a DSCP or 
   not and whatever the setting of the ECN field."

[RG] I'm not sure that understand what you mean. Could 
you explain this with a few mor stetements?

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

Editorials:

- suggest to change "Two" in some lines to "two".
- replace "PCN region" by "PCN domain" (compliant with 
  architecture terminology).
- Some mor words to the following of bullet points of 4.3.

 o  PCN interior nodes that are in a pre-congestion state above the
    configured level MUST set the PM codepoint by changing the ECN
    bits of NM marked packets to 11.
         ^^^^^^^^^^^^
 o  The PM codepoint MUST NOT be changed to NM.
    ^^^    ^^^^^^^^^

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of [email-masked]
| Sent: Thursday, May 15, 2008 5:32 PM
| To: [email-masked]
| Subject: [PCN] FW: New Version Notification 
| fordraft-moncaster-pcn-baseline-encoding-00
| 
| 
|  
| Hi All,
| 
| I have just posted an initial attempt at a standards track 
| encoding document to allow two PCN encoding states (as agreed 
| in the voting on this list). I have included Michael Menth 
| and Bob Briscoe as authors on this as it is based on the work 
| we all did at the last IETF.
| 
| Please can people try and read this and let me have any 
| comments. The key aim of the document is to specify the 
| baseline encoding in such a manner that it allows the 
| experimental extension (with three encoding
| states) to exist without contradiction. It achieves this by 
| splitting the behaviour into core behaviour,  behaviour at 
| edge nodes and behaviour at interior nodes.
| 
| I am currently trying to finish writing the initial draft for 
| the experimental extension to three encoding states. I am 
| having some difficulty putting it in clear English but hope 
| to be able to post an early version next week.
| 
| Ideally I am hoping that we can get at least this baseline 
| encoding accepted as a WG document by early June and can get 
| it into WGLC before the Dublin IETF.
| 
| Toby
| 
| ____________________________________________________________________
| Toby Moncaster, <[email-masked]> Networks Research 
| Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 
| 1473 648734 
| 
| -----Original Message-----
| From: IETF I-D Submission Tool [mailto:[email-masked]]
| Sent: 15 May 2008 16:23
| To: Moncaster,T,Toby,CXR9 R
| Cc: Briscoe,RJ,Bob,CXR9 R; [email-masked]
| Subject: New Version Notification for
| draft-moncaster-pcn-baseline-encoding-00 
| 
| 
| A new version of I-D, draft-moncaster-pcn-baseline-encoding-00.txt has
| been successfuly submitted by T Moncaster and posted to the IETF
| repository.
| 
| Filename:	 draft-moncaster-pcn-baseline-encoding
| Revision:	 00
| Title:		 Encoding and Transport of 
| (Pre-)Congestion Information
| from within a DiffServ Domain to the Egress
| Creation_date:	 2008-05-15
| WG ID:		 Independent Submission
| Number_of_pages: 10
| 
| Abstract:
| Pre-congestion notification (PCN) is a mechanism designed 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 two PCN encoding states.
| 
| Status
| 
| This memo is posted as an Internet-Draft with an intent to eventually
| progress to standards track.
|  
| 
| 
| 
| The IETF Secretariat.
| 
| 
| _______________________________________________
| PCN mailing list
| [email-masked]
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Wed, 21 May 2008 13:41:00 +0100

Hi Ruediger,

Thanks for the comments. I will incorporate them in my next revision
(which will come out in early June). Responses to the two minor points
are inline below...

Toby 

> From: Geib, Ruediger [mailto:[email-masked]] 
> Sent: 21 May 2008 11:33
> Cc: [email-masked]
> Subject: RE: [PCN] New Version Notification 
> fordraft-moncaster-pcn-baseline-encoding-00
> 
> Hi Toby,
> 

Basically this is in order to facillitate the re-use of the Voice-admit
codepoint. It also allows for the possibility that some traffic might
wish to get the same scheduling and forwarding treatment as PCN but not
be admission controlled in a PCN-like fashion. In practise it is (very?)
likely that in a single DiffServ domain traffic like this would actually
be moved to a different class (possibly receiving similar treatment) as
otherwise the PCN marking algorithms would have to take account of the
presence of this extra traffic.

OK, this came from an edit by Bob Briscoe. Essentially what it means is
that PCN is not a scheduling behaviour and thus whether or not PCN is
enabled for a DSCP doesn't affect what scheduling behaviour is applied
to that DSCP (which scheduling behaviour to use for the PCN enabvled
DSCP is an issue that will be specified elsewhere). Equally, within any
DSCP, the value of the ECN bits has no affect on what scheduling
behaviour it receives.

This point is (obviosuly) related to the above point on the Not PCN
class.

> | A new version of I-D, 
> draft-moncaster-pcn-baseline-encoding-00.txt has