Re: [PCN] New Version Notification for draft-ietf-pcn-baseline-encoding-01
<toby.moncaster@bt.com> Wed, 15 October 2008 13:37 UTC
Return-Path: <pcn-bounces@ietf.org>
X-Original-To: pcn-archive@optimus.ietf.org
Delivered-To: ietfarch-pcn-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47C433A6C83; Wed, 15 Oct 2008 06:37:48 -0700 (PDT)
X-Original-To: pcn@core3.amsl.com
Delivered-To: pcn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971EA3A692F for <pcn@core3.amsl.com>; Wed, 15 Oct 2008 06:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yid+JTEtuair for <pcn@core3.amsl.com>; Wed, 15 Oct 2008 06:37:45 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id CCB6F3A6B71 for <pcn@ietf.org>; Wed, 15 Oct 2008 06:37:44 -0700 (PDT)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Oct 2008 14:38:27 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 15 Oct 2008 14:32:50 +0100
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC707B37659@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <48F5EB06.3080109@informatik.uni-wuerzburg.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] New Version Notification for draft-ietf-pcn-baseline-encoding-01
Thread-Index: AckuxzVT08mVjtSeQi+hl5KJYBXJMwAAQRkA
References: <4A916DBC72536E419A0BD955EDECEDEC03DAA367@E03MVB1-UKBR.domain1.systemhost.net> <48F5EB06.3080109@informatik.uni-wuerzburg.de>
From: toby.moncaster@bt.com
To: menth@informatik.uni-wuerzburg.de, philip.eardley@bt.com
X-OriginalArrivalTime: 15 Oct 2008 13:38:27.0005 (UTC) FILETIME=[4D7D0ED0:01C92ECB]
Cc: pcn@ietf.org
Subject: Re: [PCN] New Version Notification for draft-ietf-pcn-baseline-encoding-01
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org
Hi Michael, Thank you. This is a very clear description of the functional split between the different documents that are needed for PCN. Unfortunately at the moment we have a difficult situation where the split has not been cleanly achieved. What is missing is the set of documents describing how to collect all the pieces of PCN together into a working system. The Architecture document is the basis for such documents but has had to leave some options open to cater for the different possible deployment scenarios. As you correctly say we are currently nearer to your option 2. than your option 1. This runs the risk of limiting us in future when we come to expand PCN and also makes it harder to re-use PCN as a building block for other systems. There would seem to be 2 possible approaches we can take: A) We improve the current structure by (for instance) merging the "how it all works" bits as a Part B to the Encoding document. This is not the best option as it slightly precludes the encoding documents from being used for more general purposes in the future. Also the documents describing how to assemble a system are most likely to be informational whilst the encoding is standards track. B) We find willing authors to take on the jobs of writing deployment documents bringing together all the snippets of text that already exist and creating a coherent whole from them. This would be a reasonably straight-forward task but would require careful thought as there are a number of sensible deployments that are possible currently. This is pretty much what you describe in your option 2. Myself and Phil really have no time to write new documents for PCN so the decision on which way to go depends on enough people volunteering to write new documents. I can probably find time to assist with editing such documents but can't take sole ownership... Toby -----Original Message----- From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: 15 October 2008 14:07 To: Eardley,PL,Philip,CXR9 R Cc: Moncaster,T,Toby,CXR9 R; pcn@ietf.org Subject: Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 Hi Phil, I think you understood my point. I try to clarify a bit more what I and possibly you also mean. Marking documents should cover only the individual behavior of the markers and not reveal too many specifics about their exact application in specific PCN deployment scenarios. Input: set of packets to be metered, set of packets to be marked Output: set of marked packets The encoding documents should define the codepoints, explain their semantics, and give constraints about their usage. Documents about deployment scenarios should describe the behavior of PCN nodes, the correct configuration of the markers and bind their action to the specific encoding. This document should give the glue, i.e. it tells how conditioning is done, which meters and markers are used and configured with which reference rates, which packets are input for the meters and markers, and how metering results are translated into encodings. There are two major possibilities for the description of a specific PCN architecture. 1. Provide marking and encoding drafts as generic building blocks. An additional document explains how they are used in a specific deployment scenario. There may be one deployment scenario or more, depending on whether a single one covers all needs. The current objective of the group is to define one deployment scenario and keep the door open for others just in case the one does not satisfy the application scenarios. That's at least my understanding. 2. Provide marking and encoding drafts as parts of a specific deployment scenario. This degrades readability of the documents and prevents simple extension of PCN since the building blocks are not generic and must be changed to describe alternative deployment scenarios. Currently I see that the second path is taken because the marking draft contains a lot deployment specific assumptions. I don't know whether this happened intentionally or not. Regards, Michael philip.eardley@bt.com wrote: > 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@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > { toby.moncaster@bt.com > { Sent: 14 October 2008 15:52 > { To: pcn@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@ietf.org] > { Sent: 14 October 2008 15:35 > { To: Moncaster,T,Toby,CXR9 R > { Cc: Briscoe,RJ,Bob,CXR9 R; menth@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@ietf.org > { https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn
- Re: [PCN] New Version Notification for draft-ietf… toby.moncaster
- Re: [PCN] New Version Notification fordraft-ietf-… philip.eardley
- Re: [PCN] New Version Notification fordraft-ietf-… Michael Menth
- Re: [PCN] New Version Notification fordraft-ietf-… philip.eardley
- Re: [PCN] New Version Notification for draft-ietf… toby.moncaster
- Re: [PCN] New VersionNotification fordraft-ietf-p… Geib, Ruediger
- Re: [PCN] New Version Notification fordraft-ietf-… Geib, Ruediger
- Re: [PCN] New Version Notification fordraft-ietf-… Michael Menth
- Re: [PCN] New Version Notification fordraft-ietf-… toby.moncaster
- Re: [PCN] New Version Notificationfordraft-ietf-p… philip.eardley
- Re: [PCN] New VersionNotification fordraft-ietf-p… philip.eardley
- Re: [PCN] New Version Notificationfordraft-ietf-p… philip.eardley
- Re: [PCN] New VersionNotification fordraft-ietf-p… Geib, Ruediger
- Re: [PCN] New VersionNotification fordraft-ietf-p… philip.eardley
- Re: [PCN] New VersionNotification fordraft-ietf-p… Geib, Ruediger
- Re: [PCN] New VersionNotification fordraft-ietf-p… philip.eardley
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… toby.moncaster
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… Geib, Ruediger
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… philip.eardley
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… toby.moncaster
- Re: [PCN] New VersionNotification fordraft-ietf-p… Michael Menth
- Re: [PCN] New VersionNotification fordraft-ietf-p… Michael Menth
- Re: [PCN] New VersionNotification fordraft-ietf-p… philip.eardley
- Re: [PCN] New VersionNotification fordraft-ietf-p… Michael Menth
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… Georgios Karagiannis
- Re: [PCN] New VersionNotification fordraft-ietf-p… philip.eardley
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… philip.eardley
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… Michael Menth
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… philip.eardley
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… toby.moncaster
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… Michael Menth
- Re: [PCN] NewVersionNotification fordraft-ietf-pc… philip.eardley