Toby,
Michael has brought up what I think is a good suggestion in the context
of the marking behaviour draft
http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-00
{ ===================================================
{
{ Section 2.5
{
{ This section describes the required joint behavior of excess and
threshold
{ markers in specific deployment scenarios. Doing that in the main body
of
{ the documents sounds like excluding other use, e.g. for
packet-specific
{ dual
{ marking which allows the implementation of a CL-like admission control
and
{ flow termination with only a single DSCP. I suggest decoupling the
{ description
{ of the meter and marker functions from their joint behavior which
depends
{ on
{ the specific encoding.
I sympathise with michael's point. I'm inclined to think that most of
the current text in S2.5 of ietf-pcn-marking-behaviour-00 would fit
better in the baseline encoding draft. I think it would fit naturally
into your text about encoding transitions (current Appendix B). at the
moment the table just gives what the valid transitions are - this would
be expanded by saying in more detail which specific transitions are
valid depending on what the meters say.
In answer to your question about App B "The PCN working group needs to
decide whether to
include this in this baseline encoding or whether to transfer it to
an alternative document."
I think michael's point & PSDM example means that it needs to be
specified in each encoding document. You could say this in S5 (Rules for
Experimental Encoding Schemes) ie require extensions to specify
similarly what the encoding transitions are depending on the state of
the 2 meters.
phil
{ -----Original Message-----
{ From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
{ toby.moncaster at bt.com
{ Sent: 14 October 2008 15:52
{ To: pcn at ietf.org
{ Subject: Re: [PCN] New Version Notification
fordraft-ietf-pcn-baseline-
{ encoding-01
{
{ As promised I have uploaded a new version. I am aware there are a
handful
{ of typos and spelling mistakes that I noticed just after uploading. I
will
{ correct these in the next version. I am now pretty happy with almost
all
{ the text.
{
{ The key section for the WG to note is Appendix B where I have put in a
{ couple of questions that I would welcome input on.
{
{ The first of these is where to put the text (now set out as a table)
about
{ valid and invalid transitions at PCN nodes? Should this be part of the
{ baseline encoding or should it be split between a new edge node
behaviour
{ document and Phil's marking behaviour.
{
{ The second question relates to how to best handle the unexpected
presence
{ of the EXP codepoint. There is a potential for this to happen during
any
{ partial deployment of an experimental encoding extension scheme.
Whilst it
{ would be best for an operator to ensure all nodes run the same
encoding
{ there is a chance this might not happen. The best solution as I see it
is
{ for the baseline scheme to treat EXP the same as NM but to raise a
{ management alarm...
{
{ I have also highlighted another point in Appendix A which needs a
{ decision: should we as a WG recommend that RFC3168 full functionality
{ tunnels SHOULD NOT be used in a PCN-domain or would it be better to
put
{ our collective voices behind Bob's attempts to correct the anomalous
{ behaviour of tunnels which he is currently trying to push through
TSVWG
{ (draft-briscoe-tsvwg-ecn-tunnel-01)
{
{ Toby
{
{ -----Original Message-----
{ From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org]
{ Sent: 14 October 2008 15:35
{ To: Moncaster,T,Toby,CXR9 R
{ Cc: Briscoe,RJ,Bob,CXR9 R; menth at informatik.uni-wuerzburg.de
{ Subject: New Version Notification for
draft-ietf-pcn-baseline-encoding-01
{
{
{ A new version of I-D, draft-ietf-pcn-baseline-encoding-01.txt has been
{ successfuly submitted by T Moncaster and posted to the IETF
repository.
{
{ Filename: draft-ietf-pcn-baseline-encoding
{ Revision: 01
{ Title: Baseline Encoding and Transport of
Pre-Congestion
{ Information
{ Creation_date: 2008-10-14
{ WG ID: pcn
{ Number_of_pages: 12
{
{ Abstract:
{ 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 extended to provide more encoding states
{ but such schemes will be described in other documents.
{
{
{
{ The IETF Secretariat.
{
{
{ _______________________________________________
{ 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