[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-00.txt
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: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
{ toby.moncaster at bt.com
{ Sent: 02 October 2008 12:00
{ To: ingemar.s.johansson at ericsson.com; pcn at ietf.org
{ 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:ingemar.s.johansson at ericsson.com]
{ Sent: 02 October 2008 06:32
{ To: Moncaster,T,Toby,CXR9 R; pcn at ietf.org
{ 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: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On
{ > Behalf Of Internet-Drafts at ietf.org
{ > Sent: den 30 september 2008 18:00
{ > To: i-d-announce at ietf.org
{ > Cc: pcn at ietf.org
{ > 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
{ PCN at ietf.org
{ https://www.ietf.org/mailman/listinfo/pcn
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn