Re: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01
<toby.moncaster@bt.com> Tue, 21 October 2008 08: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 454333A6AF2; Tue, 21 Oct 2008 01:37:42 -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 BAE523A6B3D for <pcn@core3.amsl.com>; Tue, 21 Oct 2008 01:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=-0.161, 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 dZ2MRXPXZQ-K for <pcn@core3.amsl.com>; Tue, 21 Oct 2008 01:37:39 -0700 (PDT)
Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 5359D3A6A2B for <pcn@ietf.org>; Tue, 21 Oct 2008 01:37:39 -0700 (PDT)
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Oct 2008 09:38:52 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 21 Oct 2008 09:38:50 +0100
Message-ID: <AEDCAF87EEC94F49BA92EBDD49854CC707DA4837@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <1B6169C658325341A3B8066E23919E1C01E206AE@S4DE8PSAANK.mitte.t-com.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01
Thread-Index: AckuCkBa3j1de1NSR46ftBFwicREnwAAN6jgAR1FfnAANcGeYA==
References: <AEDCAF87EEC94F49BA92EBDD49854CC707AB4998@E03MVZ1-UKDY.domain1.systemhost.net> <1B6169C658325341A3B8066E23919E1C01E206AE@S4DE8PSAANK.mitte.t-com.de>
From: toby.moncaster@bt.com
To: Ruediger.Geib@t-systems.com
X-OriginalArrivalTime: 21 Oct 2008 08:38:52.0191 (UTC) FILETIME=[72249AF0:01C93358]
Cc: pcn@ietf.org
Subject: Re: [PCN] New Version Notification fordraft-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 Ruediger, My argument for making PM an invalid transition for a PCN-ingress node is that in my head I have a conceptual model that views the PCN region as consisting of a number of nodes that do PCN marking surrounded by a fence of PCN-boundary nodes. These boundary nodes simply control ingress and egress from the region and don't actually do any marking. Of course in practise the ingress and egress nodes would also have marking functionality but it is easier to think of them as separate nodes. As far as I know there is no current proposed extension where EXP can't be marked to PM. Even in Bob's proposal with fully working tunnels EXP could be remarked to PM. The question I had in my head was the other way round: If we don't specify a behaviour for EXP in the baseline will extension encodings still work if any nodes haven't been upgraded? The answer to that seemed to be "no" for the majority of proposals (apart from the simple variant of 3 state encoding). As you say we also need to decide what to do with EXP packets regarding metering. I think as currently written Phil's draft allows them to be metered but I will check that with him. Toby -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: 21 October 2008 07:47 To: Moncaster,T,Toby,CXR9 R Cc: pcn@ietf.org Subject: RE: [PCN] New Version Notification fordraft-ietf-pcn-baseline-encoding-01 Toby, thanks for adding more content in the reviewed version. Apart from my support of Michaels proposal 1., I still would like to comment on some of your new text: Appendix B, Table 2, row "ingress" If "PM" is an invalid codepoint out, then the ingress node does not belong to the PCN domain. As far as I understood, indication of pre-congestion on a link is signaled by a PM mark. The ingress node following your specification in row "ingress" however can't signal pre-congestion. Specifying behaviours for unexpected codepoints is a necessity and writing down this requirement adds value to the document. The question is, whether forward compatibility benefits from handling EXP as NM. The whole topic is in fact a marking issue, and there it should be dealt with. Thoughts on your proposal: - Could a future extension exist, where there's no transition from EXP to PM? Then your proposal is harmful. - What you don't discuss, as you are writing the encoding draft, is whether the EXP packets should be metered by an interior node just supporting baseline encoding. I think they should be. But may be, I'm wrong and all of this discussion on receiving packets with unexpected codings and backward/forward compatibility should be a requirement for a PCN deployment scenario document. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com Sent: Tuesday, October 14, 2008 4:52 PM 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
- 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