From pcn-bounces@ietf.org Mon Jun 16 00:42:42 2008 Return-Path: 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 4AC103A6A4C; Mon, 16 Jun 2008 00:42: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 24B503A6A4C for ; Mon, 16 Jun 2008 00:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4] 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 oOlnp+gThbdX for ; Mon, 16 Jun 2008 00:42:40 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id EF93F3A681A for ; Mon, 16 Jun 2008 00:42:39 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5G7h5r1027679 for ; Mon, 16 Jun 2008 10:43:17 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 10:42:57 +0300 Received: from net-82.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 10:42:56 +0300 Message-Id: From: Lars Eggert To: pcn IETF Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 16 Jun 2008 10:42:52 +0300 References: <20080613164431.3D5703A6945@core3.amsl.com> X-Mailer: Apple Mail (2.924) X-OriginalArrivalTime: 16 Jun 2008 07:42:57.0458 (UTC) FILETIME=[981AB920:01C8CF84] X-Nokia-AV: Clean Subject: [PCN] Fwd: New Liaison Statement, "LS on draft Recommendation Q.PCNApp" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, PCN WG, The ITU-T has sent you the following liaison statement on PCN (but only sent it to my email address, which is why I'm forwarding it.) Please review the documents attached to the LS and discuss if you want to send a response. I've taken a quick look, and it seems that the ITU- T is making some assumptions about how some of the components of the PCN architecture work on a technical level that the WG hasn't come to consensus on. Lars Begin forwarded message: > From: "ext Arshey Odedra(ITU-T SG 11)" > Date: June 13, 2008 19:44:31 GMT+03:00 > To: lars.eggert@nokia.com > Subject: New Liaison Statement, "LS on draft Recommendation Q.PCNApp" > Reply-To: tsbsg11@itu.int > > > Title: LS on draft Recommendation Q.PCNApp > Submission Date: 2008-06-13 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=461 > Please reply by 2008-09-01 > > From: Arshey Odedra(ITU-T SG 11) > To: IETF Transport Area Directors, PCN Working Group Chairs(lars.eggert@nokia.com > ) > Cc: > Reponse Contact: > Technical Contact: > Purpose: For comment > Body: Liaison Statement from ITU-T SG1 Q5/11 Rapporteur Meeting (May > 2008). > Attachment(s): > LS on Drfat Recommendation Q.PCNApp (https://datatracker.ietf.org/documents/LIAISON/file567.doc > ) > Draft Recommendation Q.PCNApp, Enhancement of resource and > admission control protocols to use pre-congestion notification > (PCN), out of the May 2008 meeting (https://datatracker.ietf.org/documents/LIAISON/file568.doc > ) > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 17 02:38:58 2008 Return-Path: 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 352433A69F4; Tue, 17 Jun 2008 02:38:58 -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 B7C633A69F4 for ; Tue, 17 Jun 2008 02:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, STOX_REPLY_TYPE=0.001] 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 Sxjs20khANNO for ; Tue, 17 Jun 2008 02:38:50 -0700 (PDT) Received: from smtp-6-97.vip.sina.com (smtp.vip.sina.com [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id 2A7133A69F1 for ; Tue, 17 Jun 2008 02:38:48 -0700 (PDT) Received: from ibmPC (unknown [211.160.21.17]) by smtp-6-97.vip.sina.com (SINAMAIL) with ESMTP id AD8E91DDDF7; Tue, 17 Jun 2008 17:38:57 +0800 (CST) Message-ID: From: "Wei Gengyu" To: References: <75A199C5D243C741BF3D3F1EBCEF9BA503B347BE@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B347BE@E03MVZ1-UKDY.domain1.systemhost.net> Date: Tue, 17 Jun 2008 17:38:42 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Cc: pcn@ietf.org Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, I have some questions to ask after reading your I-D. 1) In a PCN domain, if the two-state node is between two three-states nodes= , = how the marking scheme will be? So is it ture if there is a two-state node along the route, that will be = two-state scheme. This is important for a network administrator. 2) In section 2.2. Classify and condition function "There may be traffic that is more important than PCN that shares the same capacity as PCN and is priority scheduled over PCN (perhaps an operator's control messages). Such traffic MUST be metered as though it were PCN-traffic, but MUST NOT be PCN-marked. Such packets, together with PCN-packets, are called "metered packets"." You mentioned the packet which contains an operator's control messages, so my question is if the marking contexts are sent in control messages, or PCN-capable nodes at ingress generat control messages when sending marks, what the pcn will be? Perhaps the second question is out of the scope of PCN, but there was some schemes in ATM to send RM cell instead of marking each = cell. Regards, Gengyu ----- Original Message ----- = From: To: Cc: Sent: Friday, May 09, 2008 6:41 PM Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 Rudiger Thanks for the comments. I think the slight lack of clarity about the conditioner comes because it's = an issue we've thought about less than the "core" PCN meter/mark functions, = and also because trying to leave some implementation openness. Issue 1: Yes, the conditioner will include a meter in for it to do its work (I don't = see this as being "in front of" the conditioner - it's part of it). this is = different from the PCN meters (at one point you seem to imply the PCN meter = is the same thing as the conditioner's meter) Will try & clarify. Will also take another look at some of the Diffserv = stuff about conditioners, to try and use the same language [I did try to = already, as this was an earlier comment by joe, but I'll try & make it = better] & maybe add refs. Issue 2: Ok, I see that we're both thinking the same, as this is basically the answe= r = I gave to issue 1! Issue 3a: I thought it was worth distinguishing the dropping/downgrading of PCN pkts, = from the dropping/downgrading of other metered pkts (by which I meant, = metered pkts that are not PCn pkts - these 2 terms are precisely defined) I'll try & clarify Issue 3b: An interesting question. At the moment the doc says that Conditioning is a = MUST, ie all routers of pcn-domain will have to support it. the doc implies = that they don't all have to operate with the same choice; I think this is = reasonable, but some standards language is needed. Inclined to make all the = conditioning possibilities MAYs (ie dropping pcn pkts, downgrading pcn pkts= , = drop/downgrade metered, non-pcn pkts). Please shout if you think something different, eg that one possibility is s= o = much better that it needs to be a SHOULD. Issue 4: Excess-traffic-marked is defined elsewhere. It means marked by an (earlier = PCN-node's) excess traffic meter /marker function. This & issue 2 suggest that need to add a terminology section. It's a deliberate choice that the threshold meter SHOULD NOT meter these = pkts (ie not meter ones that are already excess-traffic-marked). The reason = is that otherwise too much traffic is terminated (with some edge = behaviours). This choice was one of the consensus decisions reached in = Steven's Questions 1-6. Issue 5: Ok Issue 6: I think this change would be over-compression, and it's better to use a few = more words & make it easier to understand. Thanks! phil > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: 09 May 2008 10:28 > To: Eardley,PL,Philip,CXR9 R > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 > > Hi Phil, > > thanks for your early draft. The document is short > and in a good shape. I still have some questions, > mainly related to the conditioner. > > Regards, > > Rudiger > > -----------Issue 1------------- > > 1. Introduction > > o Packet classify and condition -... > also Figure 1 and a couple of other times in > the text: > > The location of the conditioner and its > functions to me are not well defined. Two > main issues: > - the conditioner drops or downgrades packets > above a threshold, so there's some meter in > front of it. > - section 2.4 says > "A packet SHOULD NOT be metered (by this > excess traffic meter function) in the > following two cases: > > o If the packet is already > excess-traffic-marked; > > o If this PCN-node drops (downgrades) the > packet because the link is overloaded." > > If the conditioner is in front of the meter, > then the packet can't be metered if it is > dropped or downgraded. > > Michael published on the sequence of conditioner > and marker in his "Performance Evaluation of > PCN-based Flow Admission Control and Termination". > Condition, then meter seems to be preferrable. > > All in all, the aspect of conditioning is rather > unclear and if the authors don't take any > position on the sequence meter/condition/mark, > some argumentation in the document may be helpful. > > Unless anything speaks against meter, condition, > mark, I prefer this sequence. > > -----------Issue 2------------- > > 2.2. Classify and condition function > > "If the level of traffic is sufficiently high to > overload the PCN behaviour aggregate(s), then > traffic MUST be conditioned." > > This implies another meter to determine the overload, > doesn't it? Is the following holding: > > classify->overload-meter->condition-> > thresh/excess meter->mark? > > This sequence would be allright with me. > > -------Issue 3a------------------ > > same section as issue 2, just continuing > > "The three possibilities are: > > o drop PCN-packets; > > o downgrade PCN-packets to a lower priority > behaviour aggregate, such as best effort or > assured forwarding, and perhaps drop lower > priority packets; > > o drop or downgrade other "metered packets". > ^^^^^^ > Please delete "other" as it sounds unprecise and > contradicts the earlier statement, that these > packets are more important then PCN traffic. > May be replaced by adding "in general". > > Or is this sequence of possibilities meant as a > list of handling priorities? > > ------Issue 3b: Do all routers of a domain have to > support this conditioning and do they all have to > operate with the same choice? The document is > unclear on that > > ---------Issue 4------------------ > > same section as issue 3, just continuing > > "If PCN-packets are dropped (or downgraded) then: > > o excess-traffic-marked PCN-packets SHOULD be > preferentially dropped (downgraded); > > o PCN-packets that are dropped (downgraded) > SHOULD NOT be metered by the Excess traffic > Meter." > > Please define what is meant by > "excess-traffic-marked". Do you mean CE marked? > > It is probably not harmful if the threshold meter > counts these packets, but it doesn't make much > sense either. But I don't ask for a change of > text on that aspect (if thought useful, then > generalise the text). > > -------Issue 5----------------- > > 2.3. Threshold meter function > > .. > "The meter is a token bucket, which..." > ^^ > > Please replace by "acts like" (also in "2.4 > Excess meter" > > ------Issue 6----------------- > > 2.5. Marking function > > "o if two encoding states are available (one > for excess-traffic-marked and one for > "not PCN-marked") then: > > * if the Excess traffic Meter indicates > marking, then the packet is > excess-traffic-marked; > > * otherwise the packet's encoding state > is not altered." > > and the same text earlier for threshold marking. > Could both be replaced by: > > o if two encoding states are available (one > for Behaviour_mode and one for "not > PCN-marked") then: > > * if the Behaviour_Meter indicates > marking, then the packet is > Behaviour_marked; > > * otherwise the packet's encoding state > is not altered." > > Where the Behaviour is either Excess or Threshold. > > Ok, a minor comment, would save a few lines, > but doesn't necessarily improve readability. > ------------------------------ > > > > R=FCdiger Geib > > T-Systems Enterprise Services GmbH > Systems Integration > R=FCdiger Geib > Project Unit 6 > Line of Business Networks & Processes > Deutsche-Telekom-Allee 7, 64295 Darmstadt > Tel. +49 6151 937-2138 > Fax +49 6151 937-4591 > Internet: http://www.t-systems.com > > > T-Systems Enterprise Services GmbH > Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) > Executive Committee: Reinhard Clemens (Vorsitzender)*, Helmut Binder, Olaf > Heyden*, Dr. Klaus Hofmann, Katrin Horstmann, Joachim Langmack*, Wilfried > Peters*, Dr. Stefan Schloter, Dr. Matthias Schuster*, Zvezdana Seeger*, > Dr. Rolf Werner > Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 > Sitz der Gesellschaft: Frankfurt am Main > WEEE-Reg.-Nr. DE87523644 > *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > > > > _______________________________________________ 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 From pcn-bounces@ietf.org Tue Jun 17 03:13:36 2008 Return-Path: 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 D1CEA3A692F; Tue, 17 Jun 2008 03:13:36 -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 E6C703A688B for ; Tue, 17 Jun 2008 03:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=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 nruVIiCMxHHT for ; Tue, 17 Jun 2008 03:13:30 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 374673A6869 for ; Tue, 17 Jun 2008 03:13:28 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jun 2008 11:14:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Jun 2008 11:14:08 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F81C@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-eardley-pcn-marking-behaviour-00 Thread-Index: AcjQXgyDSNf0Sih9TKCF6aFJ/8jhzQAA2+Rw From: To: X-OriginalArrivalTime: 17 Jun 2008 10:14:08.0417 (UTC) FILETIME=[E13AF910:01C8D062] Cc: pcn@ietf.org Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Gengyu Thanks very much for your comments! 1) I think this is covered in Section 2.1 (Scope), which states "The same choice MUST be used throughout a PCN-domain." - this refers to the same choice about encoding states in all the PCN links in the domain. In your example you have a node with 2 encoding states in the same domain as nodes with 3 encoding states. Therefore the example breaks the "MUST" in Section 2.1, ie the domain is misconfigured (and so strictly speaking it isn't a PCN domain, so we don't need to worry about it). If you've a suggestion how to clarify this, please let me know. 2) if I understand you right, you're suggesting that when a link is pre-congested, it sends a message (instead of marking packets). Yes, this is a possible approach, but - as you say - it's out of scope of PCN. thanks phil { -----Original Message----- { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] { Sent: 17 June 2008 10:39 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 { { Hi, { { I have some questions to ask after reading your I-D. { { 1) In a PCN domain, if the two-state node is between two three-states { nodes, { how the marking scheme will be? { So is it ture if there is a two-state node along the route, that will { be { two-state scheme. { This is important for a network administrator. { 2) In section 2.2. Classify and condition function { "There may be traffic that is more important than PCN that shares the { same capacity as PCN and is priority scheduled over PCN (perhaps an { operator's control messages). Such traffic MUST be metered as though { it were PCN-traffic, but MUST NOT be PCN-marked. Such packets, { together with PCN-packets, are called "metered packets"." { { You mentioned the packet which contains an operator's control messages, { so my question is if the marking contexts are sent in control messages, { or PCN-capable nodes at ingress generat control messages when sending { marks, { what the pcn will be? { Perhaps the second question is out of the scope of PCN, { but there was some schemes in ATM to send RM cell instead of marking each { cell. { { Regards, { { Gengyu { _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 17 10:15:17 2008 Return-Path: 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 DAC5F3A6B2D; Tue, 17 Jun 2008 10:15:17 -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 60B6D3A6B2D for ; Tue, 17 Jun 2008 10:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] 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 hNrZ0rRKCbGC for ; Tue, 17 Jun 2008 10:15:12 -0700 (PDT) Received: from smtp-6-96.vip.sina.com (smtp.vip.sina.com [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id 172F23A6AA2 for ; Tue, 17 Jun 2008 10:15:10 -0700 (PDT) Received: from ibmPC (unknown [211.160.21.17]) by smtp-6-96.vip.sina.com (SINAMAIL) with ESMTP id 588684CE865 for ; Wed, 18 Jun 2008 01:09:26 +0800 (CST) Message-ID: From: "Wei Gengyu" To: Date: Wed, 18 Jun 2008 01:09:11 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org ----- Original Message ----- From: "Wei Gengyu" To: Sent: Tuesday, June 17, 2008 10:41 PM Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 > Philip, > > For the first question, your I-D in Section 2.1 is clear as you said. > I got it after reading your explanations. Thank you. > > But, I still think it may be better to make 3-states nodes compatible with > 2-states node. > Consider the case, if a PCN domain covers more than one autonomous domain > in the Internet, > the mechanism in sechtion 2.1 could not tolerate any configuration faults. > > So, if the PCN domain can works in 2-states scheme when there are both > 2-state and 3state nodes, > loosely-consistent checking is required in a PCN domain. > > As clarification of nodes across several autonomous domains may not be as > easy as MTU discovery, > having the marking info compatible is probably better than making encoding > choice the same in all PCN links. > > Your comments? > > Regards, > > Gengyu > School of Computer Science and Technology > Beijing University of Posts and Telecommunications > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, June 17, 2008 6:14 PM > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 > > > Gengyu > > Thanks very much for your comments! > > 1) I think this is covered in Section 2.1 (Scope), which states "The > same choice MUST be used throughout a PCN-domain." - this refers to the > same choice about encoding states in all the PCN links in the domain. > > In your example you have a node with 2 encoding states in the same > domain as nodes with 3 encoding states. Therefore the example breaks the > "MUST" in Section 2.1, ie the domain is misconfigured (and so strictly > speaking it isn't a PCN domain, so we don't need to worry about it). > > If you've a suggestion how to clarify this, please let me know. > > 2) if I understand you right, you're suggesting that when a link is > pre-congested, it sends a message (instead of marking packets). Yes, > this is a possible approach, but - as you say - it's out of scope of > PCN. > > thanks > phil > > { -----Original Message----- > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] > { Sent: 17 June 2008 10:39 > { To: Eardley,PL,Philip,CXR9 R > { Cc: pcn@ietf.org > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 > { > { Hi, > { > { I have some questions to ask after reading your I-D. > { > { 1) In a PCN domain, if the two-state node is between two three-states > { nodes, > { how the marking scheme will be? > { So is it ture if there is a two-state node along the route, that > will > { be > { two-state scheme. > { This is important for a network administrator. > { 2) In section 2.2. Classify and condition function > { "There may be traffic that is more important than PCN that shares > the > { same capacity as PCN and is priority scheduled over PCN (perhaps an > { operator's control messages). Such traffic MUST be metered as > though > { it were PCN-traffic, but MUST NOT be PCN-marked. Such packets, > { together with PCN-packets, are called "metered packets"." > { > { You mentioned the packet which contains an operator's control > messages, > { so my question is if the marking contexts are sent in control > messages, > { or PCN-capable nodes at ingress generat control messages when sending > { marks, > { what the pcn will be? > { Perhaps the second question is out of the scope of PCN, > { but there was some schemes in ATM to send RM cell instead of marking > each > { cell. > { > { Regards, > { > { Gengyu > { > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jun 18 01:18:15 2008 Return-Path: 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 14EAE28C18D; Wed, 18 Jun 2008 01:18:15 -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 274B828C184 for ; Wed, 18 Jun 2008 01:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=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 odeZ2QSPDyT3 for ; Wed, 18 Jun 2008 01:18:13 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 8CFCD3A69D6 for ; Wed, 18 Jun 2008 01:18:12 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 09:18:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jun 2008 09:18:58 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F828@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 Thread-Index: AcjQndUnRUe1lZtcSRGgpQ58AB2XUQAfLlPg From: To: , X-OriginalArrivalTime: 18 Jun 2008 08:18:58.0461 (UTC) FILETIME=[F4FD1CD0:01C8D11B] Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Gengyu, You raise interesting questions. I'm not really sure what compatibility means in this context - it would probably need some careful thought and simulations /expts to work out if it could be compatible to some extent. I'm not sure a similar mechanism to MTU discovery would be appropriate - the number of encoding states in nodes in a PCN-domain really is something that the operator of that domain ought to know - it doesn't seem to me that this is a good thing to discover dynamically. I think we should remember rudiger's warning when we got into discussing configuration issues before - it isn't our job to make sure everything behaves properly if something is configured incorrectly Best wishes Phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Wei { Gengyu { Sent: 17 June 2008 18:09 { To: pcn@ietf.org { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 { { { ----- Original Message ----- { From: "Wei Gengyu" { To: { Sent: Tuesday, June 17, 2008 10:41 PM { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 { { { > Philip, { > { > For the first question, your I-D in Section 2.1 is clear as you said. { > I got it after reading your explanations. Thank you. { > { > But, I still think it may be better to make 3-states nodes compatible { with { > 2-states node. { > Consider the case, if a PCN domain covers more than one autonomous { domain { > in the Internet, { > the mechanism in sechtion 2.1 could not tolerate any configuration { faults. { > { > So, if the PCN domain can works in 2-states scheme when there are both { > 2-state and 3state nodes, { > loosely-consistent checking is required in a PCN domain. { > { > As clarification of nodes across several autonomous domains may not be { as { > easy as MTU discovery, { > having the marking info compatible is probably better than making { encoding { > choice the same in all PCN links. { > { > Your comments? { > { > Regards, { > { > Gengyu { > School of Computer Science and Technology { > Beijing University of Posts and Telecommunications { > { > ----- Original Message ----- { > From: { > To: { > Cc: { > Sent: Tuesday, June 17, 2008 6:14 PM { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 { > { > { > Gengyu { > { > Thanks very much for your comments! { > { > 1) I think this is covered in Section 2.1 (Scope), which states "The { > same choice MUST be used throughout a PCN-domain." - this refers to the { > same choice about encoding states in all the PCN links in the domain. { > { > In your example you have a node with 2 encoding states in the same { > domain as nodes with 3 encoding states. Therefore the example breaks the { > "MUST" in Section 2.1, ie the domain is misconfigured (and so strictly { > speaking it isn't a PCN domain, so we don't need to worry about it). { > { > If you've a suggestion how to clarify this, please let me know. { > { > 2) if I understand you right, you're suggesting that when a link is { > pre-congested, it sends a message (instead of marking packets). Yes, { > this is a possible approach, but - as you say - it's out of scope of { > PCN. { > { > thanks { > phil { > { > { -----Original Message----- { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] { > { Sent: 17 June 2008 10:39 { > { To: Eardley,PL,Philip,CXR9 R { > { Cc: pcn@ietf.org { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 { > { { > { Hi, { > { { > { I have some questions to ask after reading your I-D. { > { { > { 1) In a PCN domain, if the two-state node is between two three-states { > { nodes, { > { how the marking scheme will be? { > { So is it ture if there is a two-state node along the route, that { > will { > { be { > { two-state scheme. { > { This is important for a network administrator. { > { 2) In section 2.2. Classify and condition function { > { "There may be traffic that is more important than PCN that shares { > the { > { same capacity as PCN and is priority scheduled over PCN (perhaps an { > { operator's control messages). Such traffic MUST be metered as { > though { > { it were PCN-traffic, but MUST NOT be PCN-marked. Such packets, { > { together with PCN-packets, are called "metered packets"." { > { { > { You mentioned the packet which contains an operator's control { > messages, { > { so my question is if the marking contexts are sent in control { > messages, { > { or PCN-capable nodes at ingress generat control messages when sending { > { marks, { > { what the pcn will be? { > { Perhaps the second question is out of the scope of PCN, { > { but there was some schemes in ATM to send RM cell instead of marking { > each { > { cell. { > { { > { Regards, { > { { > { Gengyu { > { { > { { _______________________________________________ { 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 From pcn-bounces@ietf.org Wed Jun 18 05:08:37 2008 Return-Path: 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 F2C3028C0D7; Wed, 18 Jun 2008 05:08:36 -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 3988128C0F3 for ; Wed, 18 Jun 2008 05:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, STOX_REPLY_TYPE=0.001] 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 Vy9OUSZvXfVp for ; Wed, 18 Jun 2008 05:08:33 -0700 (PDT) Received: from smtp-6-97.vip.sina.com (smtp.vip.sina.com [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id 4FB7E3A6936 for ; Wed, 18 Jun 2008 05:08:32 -0700 (PDT) Received: from ibmPC (unknown [211.160.21.17]) by smtp-6-97.vip.sina.com (SINAMAIL) with ESMTP id 597FC1DEB47; Wed, 18 Jun 2008 20:08:51 +0800 (CST) Message-ID: From: "Wei Gengyu" To: References: <4A916DBC72536E419A0BD955EDECEDEC0329F828@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F828@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 18 Jun 2008 20:08:30 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, and all, I strongly suggest PCN WG review the coding scheme. It is not good to have two exclusive coding algorithms in one technical document. It is easy to see that 3-states have more information than 2-states. It is also possible to make 2-states be the subset of three states. The compatibility here means 3-state capability nodes can understand 2-state coding. I did not suggest to use MTU discovery or similar mechanisms for node clarification, neither do here. While remembering rudiger's words, we should face the existing problems of networks. The operator ought to knwo the nodes within its own dommains. But, it is rather difficult for any operators to know the nodes of other autonomous nodes if a PCN domain covers several autonomous domains. I believe, it will be better if the PCN coding schemes is easy to deploy, robust to work, and tolerant of faults. We do not need to make sure everything properly, we only need to make 2-state capable nodes work togather with 3-state capable nodes. Regards, Gengyu ----- Original Message ----- From: To: ; Sent: Wednesday, June 18, 2008 4:18 PM Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 Gengyu, You raise interesting questions. I'm not really sure what compatibility means in this context - it would probably need some careful thought and simulations /expts to work out if it could be compatible to some extent. I'm not sure a similar mechanism to MTU discovery would be appropriate - the number of encoding states in nodes in a PCN-domain really is something that the operator of that domain ought to know - it doesn't seem to me that this is a good thing to discover dynamically. I think we should remember rudiger's warning when we got into discussing configuration issues before - it isn't our job to make sure everything behaves properly if something is configured incorrectly Best wishes Phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Wei { Gengyu { Sent: 17 June 2008 18:09 { To: pcn@ietf.org { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 { { { ----- Original Message ----- { From: "Wei Gengyu" { To: { Sent: Tuesday, June 17, 2008 10:41 PM { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 { { { > Philip, { > { > For the first question, your I-D in Section 2.1 is clear as you said. { > I got it after reading your explanations. Thank you. { > { > But, I still think it may be better to make 3-states nodes compatible { with { > 2-states node. { > Consider the case, if a PCN domain covers more than one autonomous { domain { > in the Internet, { > the mechanism in sechtion 2.1 could not tolerate any configuration { faults. { > { > So, if the PCN domain can works in 2-states scheme when there are both { > 2-state and 3state nodes, { > loosely-consistent checking is required in a PCN domain. { > { > As clarification of nodes across several autonomous domains may not be { as { > easy as MTU discovery, { > having the marking info compatible is probably better than making { encoding { > choice the same in all PCN links. { > { > Your comments? { > { > Regards, { > { > Gengyu { > School of Computer Science and Technology { > Beijing University of Posts and Telecommunications { > { > ----- Original Message ----- { > From: { > To: { > Cc: { > Sent: Tuesday, June 17, 2008 6:14 PM { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 { > { > { > Gengyu { > { > Thanks very much for your comments! { > { > 1) I think this is covered in Section 2.1 (Scope), which states "The { > same choice MUST be used throughout a PCN-domain." - this refers to the { > same choice about encoding states in all the PCN links in the domain. { > { > In your example you have a node with 2 encoding states in the same { > domain as nodes with 3 encoding states. Therefore the example breaks the { > "MUST" in Section 2.1, ie the domain is misconfigured (and so strictly { > speaking it isn't a PCN domain, so we don't need to worry about it). { > { > If you've a suggestion how to clarify this, please let me know. { > { > 2) if I understand you right, you're suggesting that when a link is { > pre-congested, it sends a message (instead of marking packets). Yes, { > this is a possible approach, but - as you say - it's out of scope of { > PCN. { > { > thanks { > phil { > { > { -----Original Message----- { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] { > { Sent: 17 June 2008 10:39 { > { To: Eardley,PL,Philip,CXR9 R { > { Cc: pcn@ietf.org { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 { > { { > { Hi, { > { { > { I have some questions to ask after reading your I-D. { > { { > { 1) In a PCN domain, if the two-state node is between two three-states { > { nodes, { > { how the marking scheme will be? { > { So is it ture if there is a two-state node along the route, that { > will { > { be { > { two-state scheme. { > { This is important for a network administrator. { > { 2) In section 2.2. Classify and condition function { > { "There may be traffic that is more important than PCN that shares { > the { > { same capacity as PCN and is priority scheduled over PCN (perhaps an { > { operator's control messages). Such traffic MUST be metered as { > though { > { it were PCN-traffic, but MUST NOT be PCN-marked. Such packets, { > { together with PCN-packets, are called "metered packets"." { > { { > { You mentioned the packet which contains an operator's control { > messages, { > { so my question is if the marking contexts are sent in control { > messages, { > { or PCN-capable nodes at ingress generat control messages when sending { > { marks, { > { what the pcn will be? { > { Perhaps the second question is out of the scope of PCN, { > { but there was some schemes in ATM to send RM cell instead of marking { > each { > { cell. { > { { > { Regards, { > { { > { Gengyu { > { { > { { _______________________________________________ { 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 From pcn-bounces@ietf.org Wed Jun 18 05:41:29 2008 Return-Path: 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 8F8B528C0F6; Wed, 18 Jun 2008 05:41:29 -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 828263A696F for ; Wed, 18 Jun 2008 05:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=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 pRV-Cdmm+ST1 for ; Wed, 18 Jun 2008 05:41:26 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id C4ECF3A684F for ; Wed, 18 Jun 2008 05:41:25 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 13:42:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jun 2008 13:42:11 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F82B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 Thread-Index: AcjRPCcsuUPZStahRIKQJGNFjzR0TwAASeLw From: To: X-OriginalArrivalTime: 18 Jun 2008 12:42:12.0402 (UTC) FILETIME=[BAE94120:01C8D140] Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I think I may be confusing things unnecessarily. The encoding proposal from Toby & Michael et al is structured as follows: - a baseline encoding. This uses 1 (standardised) DSCP + the ECN codepoints in order to encode 2 states. - an extension encoding. This uses a second DSCP (in addition to the baseline's DSCP) + the ECN codepoints and encodes 3 states. The use of the ECN codepoints is compatible between them, in the sense that eg ECN 11 means some form of PCN marking in all cases - it was a deliberate choice to do it like this (So you could say that the 2 encoding states are a sub-set of the 3 encoding states - which is one of your requirements) The baseline has already been sent to the list http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt - toby plans to send the extension draft soon (a draft is being reviewed amongst the authors) I think in your example you envisage 2 separate networks both running PCN which then later get merged into a single PCN-domain. So you have one with 2 encoding states & one with 3 encoding states (or indeed: both have 2 encoding states, but one is using them to trigger admission control and one termination control, relying on other mechanisms for the other function, or one is using the marks to trigger both admission & termination - ie 'single marking'). As well as the pure encoding, then there'll be other things to think about - eg the ingress & egress gateways can be in different domains and so will interpret the received marks differently. Personally I think it's reasonable to expect "management" to have to be done when the 2 separate nws are joined together to form a single PCN-domain - ie to coordinate how PCN marks will be interpreted. I don't know whether something clever can be done that doesn't require such work - maybe it would make a good topic to discuss over lunch, if you're in Dublin? (I think this kind of discussion on 'forming a single PCN domain from two separate PCN domains' probably falls into the inter-domain category, which is out of scope of PCN WG in initial charter.) Thanks phil { -----Original Message----- { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] { Sent: 18 June 2008 13:09 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 { { Phil, and all, { { I strongly suggest PCN WG review the coding scheme. { It is not good to have two exclusive coding algorithms in one technical { document. { { It is easy to see that 3-states have more information than 2-states. { It is also possible to make 2-states be the subset of three states. { The compatibility here means 3-state capability nodes can understand 2- { state { coding. { { I did not suggest to use MTU discovery or similar mechanisms for node { clarification, neither do here. { { While remembering rudiger's words, we should face the existing problems of { networks. { The operator ought to knwo the nodes within its own dommains. { But, it is rather difficult for any operators to know the nodes of other { autonomous nodes { if a PCN domain covers several autonomous domains. { { I believe, it will be better if the PCN coding schemes is easy to deploy, { robust to work, and tolerant of faults. { { We do not need to make sure everything properly, { we only need to make 2-state capable nodes work togather with 3-state { capable nodes. { { Regards, { { Gengyu { { { ----- Original Message ----- { From: { To: ; { Sent: Wednesday, June 18, 2008 4:18 PM { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 { { { Gengyu, { { You raise interesting questions. I'm not really sure what compatibility { means in this context - it would probably need some careful thought and { simulations /expts to work out if it could be compatible to some extent. { I'm not sure a similar mechanism to MTU discovery would be appropriate - { the number of encoding states in nodes in a PCN-domain really is { something that the operator of that domain ought to know - it doesn't { seem to me that this is a good thing to discover dynamically. { { I think we should remember rudiger's warning when we got into discussing { configuration issues before - it isn't our job to make sure everything { behaves properly if something is configured incorrectly { { Best wishes { Phil { { { -----Original Message----- { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Wei { { Gengyu { { Sent: 17 June 2008 18:09 { { To: pcn@ietf.org { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 { { { { { { ----- Original Message ----- { { From: "Wei Gengyu" { { To: { { Sent: Tuesday, June 17, 2008 10:41 PM { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 { { { { { { > Philip, { { > { { > For the first question, your I-D in Section 2.1 is clear as you { said. { { > I got it after reading your explanations. Thank you. { { > { { > But, I still think it may be better to make 3-states nodes { compatible { { with { { > 2-states node. { { > Consider the case, if a PCN domain covers more than one autonomous { { domain { { > in the Internet, { { > the mechanism in sechtion 2.1 could not tolerate any configuration { { faults. { { > { { > So, if the PCN domain can works in 2-states scheme when there are { both { { > 2-state and 3state nodes, { { > loosely-consistent checking is required in a PCN domain. { { > { { > As clarification of nodes across several autonomous domains may not { be { { as { { > easy as MTU discovery, { { > having the marking info compatible is probably better than making { { encoding { { > choice the same in all PCN links. { { > { { > Your comments? { { > { { > Regards, { { > { { > Gengyu { { > School of Computer Science and Technology { { > Beijing University of Posts and Telecommunications { { > { { > ----- Original Message ----- { { > From: { { > To: { { > Cc: { { > Sent: Tuesday, June 17, 2008 6:14 PM { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 { { > { { > { { > Gengyu { { > { { > Thanks very much for your comments! { { > { { > 1) I think this is covered in Section 2.1 (Scope), which states "The { { > same choice MUST be used throughout a PCN-domain." - this refers to { the { { > same choice about encoding states in all the PCN links in the { domain. { { > { { > In your example you have a node with 2 encoding states in the same { { > domain as nodes with 3 encoding states. Therefore the example breaks { the { { > "MUST" in Section 2.1, ie the domain is misconfigured (and so { strictly { { > speaking it isn't a PCN domain, so we don't need to worry about it). { { > { { > If you've a suggestion how to clarify this, please let me know. { { > { { > 2) if I understand you right, you're suggesting that when a link is { { > pre-congested, it sends a message (instead of marking packets). Yes, { { > this is a possible approach, but - as you say - it's out of scope of { { > PCN. { { > { { > thanks { { > phil { { > { { > { -----Original Message----- { { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] { { > { Sent: 17 June 2008 10:39 { { > { To: Eardley,PL,Philip,CXR9 R { { > { Cc: pcn@ietf.org { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 { { > { { { > { Hi, { { > { { { > { I have some questions to ask after reading your I-D. { { > { { { > { 1) In a PCN domain, if the two-state node is between two { three-states { { > { nodes, { { > { how the marking scheme will be? { { > { So is it ture if there is a two-state node along the route, { that { { > will { { > { be { { > { two-state scheme. { { > { This is important for a network administrator. { { > { 2) In section 2.2. Classify and condition function { { > { "There may be traffic that is more important than PCN that { shares { { > the { { > { same capacity as PCN and is priority scheduled over PCN { (perhaps an { { > { operator's control messages). Such traffic MUST be metered as { { > though { { > { it were PCN-traffic, but MUST NOT be PCN-marked. Such packets, { { > { together with PCN-packets, are called "metered packets"." { { > { { { > { You mentioned the packet which contains an operator's control { { > messages, { { > { so my question is if the marking contexts are sent in control { { > messages, { { > { or PCN-capable nodes at ingress generat control messages when { sending { { > { marks, { { > { what the pcn will be? { { > { Perhaps the second question is out of the scope of PCN, { { > { but there was some schemes in ATM to send RM cell instead of { marking { { > each { { > { cell. { { > { { { > { Regards, { { > { { { > { Gengyu { { > { { { > { { { { _______________________________________________ { { 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 From pcn-bounces@ietf.org Thu Jun 19 10:04:36 2008 Return-Path: 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 CAF5E3A6990; Thu, 19 Jun 2008 10:04:36 -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 8A6A83A699D for ; Thu, 19 Jun 2008 10:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, STOX_REPLY_TYPE=0.001] 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 VU7z20nKNR5f for ; Thu, 19 Jun 2008 10:04:31 -0700 (PDT) Received: from smtp-6-99.vip.sina.com (smtp.vip.sina.com [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id AA3F73A690A for ; Thu, 19 Jun 2008 10:04:29 -0700 (PDT) Received: from ibmPC (unknown [211.160.21.17]) by smtp-6-99.vip.sina.com (SINAMAIL) with ESMTP id EFCF028E27; Fri, 20 Jun 2008 01:05:09 +0800 (CST) Message-ID: <5351E79284D944639901EDC11D6E9676@ibmPC> From: "Wei Gengyu" To: References: <4A916DBC72536E419A0BD955EDECEDEC0329F82B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F82B@E03MVB1-UKBR.domain1.systemhost.net> Date: Fri, 20 Jun 2008 01:04:44 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MIMEOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, I am not in Dublin, but I like to drink red tea while disscussing the technical issues with my collegues. The network we often concern is the network that covers an area greater than an island. Consider the case, a university with serveral campus located at different cities, it is one unversity network of a collection of campus networks. Or the network of an enterprises with serveral branches located in different states is one network. Those are truely existed networks nowadays. And having experiences as a network administor will be helpful to decide how to configure a network and to understand the problem of coding schemes. In your email you described the problem and the node behavior clearly. I do think that the problems must be solved. In my opinion,the problems are due to the semantics of 2-state and 3-state coding schemes. So, I argue that the WG should review coding schemes. Regards, Gengyu ----- Original Message ----- From: To: Cc: Sent: Wednesday, June 18, 2008 8:42 PM Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 I think I may be confusing things unnecessarily. The encoding proposal from Toby & Michael et al is structured as follows: - a baseline encoding. This uses 1 (standardised) DSCP + the ECN codepoints in order to encode 2 states. - an extension encoding. This uses a second DSCP (in addition to the baseline's DSCP) + the ECN codepoints and encodes 3 states. The use of the ECN codepoints is compatible between them, in the sense that eg ECN 11 means some form of PCN marking in all cases - it was a deliberate choice to do it like this (So you could say that the 2 encoding states are a sub-set of the 3 encoding states - which is one of your requirements) The baseline has already been sent to the list http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt - toby plans to send the extension draft soon (a draft is being reviewed amongst the authors) I think in your example you envisage 2 separate networks both running PCN which then later get merged into a single PCN-domain. So you have one with 2 encoding states & one with 3 encoding states (or indeed: both have 2 encoding states, but one is using them to trigger admission control and one termination control, relying on other mechanisms for the other function, or one is using the marks to trigger both admission & termination - ie 'single marking'). As well as the pure encoding, then there'll be other things to think about - eg the ingress & egress gateways can be in different domains and so will interpret the received marks differently. Personally I think it's reasonable to expect "management" to have to be done when the 2 separate nws are joined together to form a single PCN-domain - ie to coordinate how PCN marks will be interpreted. I don't know whether something clever can be done that doesn't require such work - maybe it would make a good topic to discuss over lunch, if you're in Dublin? (I think this kind of discussion on 'forming a single PCN domain from two separate PCN domains' probably falls into the inter-domain category, which is out of scope of PCN WG in initial charter.) Thanks phil { -----Original Message----- { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] { Sent: 18 June 2008 13:09 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 { { Phil, and all, { { I strongly suggest PCN WG review the coding scheme. { It is not good to have two exclusive coding algorithms in one technical { document. { { It is easy to see that 3-states have more information than 2-states. { It is also possible to make 2-states be the subset of three states. { The compatibility here means 3-state capability nodes can understand 2- { state { coding. { { I did not suggest to use MTU discovery or similar mechanisms for node { clarification, neither do here. { { While remembering rudiger's words, we should face the existing problems of { networks. { The operator ought to knwo the nodes within its own dommains. { But, it is rather difficult for any operators to know the nodes of other { autonomous nodes { if a PCN domain covers several autonomous domains. { { I believe, it will be better if the PCN coding schemes is easy to deploy, { robust to work, and tolerant of faults. { { We do not need to make sure everything properly, { we only need to make 2-state capable nodes work togather with 3-state { capable nodes. { { Regards, { { Gengyu { { { ----- Original Message ----- { From: { To: ; { Sent: Wednesday, June 18, 2008 4:18 PM { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 { { { Gengyu, { { You raise interesting questions. I'm not really sure what compatibility { means in this context - it would probably need some careful thought and { simulations /expts to work out if it could be compatible to some extent. { I'm not sure a similar mechanism to MTU discovery would be appropriate - { the number of encoding states in nodes in a PCN-domain really is { something that the operator of that domain ought to know - it doesn't { seem to me that this is a good thing to discover dynamically. { { I think we should remember rudiger's warning when we got into discussing { configuration issues before - it isn't our job to make sure everything { behaves properly if something is configured incorrectly { { Best wishes { Phil { { { -----Original Message----- { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Wei { { Gengyu { { Sent: 17 June 2008 18:09 { { To: pcn@ietf.org { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 { { { { { { ----- Original Message ----- { { From: "Wei Gengyu" { { To: { { Sent: Tuesday, June 17, 2008 10:41 PM { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 { { { { { { > Philip, { { > { { > For the first question, your I-D in Section 2.1 is clear as you { said. { { > I got it after reading your explanations. Thank you. { { > { { > But, I still think it may be better to make 3-states nodes { compatible { { with { { > 2-states node. { { > Consider the case, if a PCN domain covers more than one autonomous { { domain { { > in the Internet, { { > the mechanism in sechtion 2.1 could not tolerate any configuration { { faults. { { > { { > So, if the PCN domain can works in 2-states scheme when there are { both { { > 2-state and 3state nodes, { { > loosely-consistent checking is required in a PCN domain. { { > { { > As clarification of nodes across several autonomous domains may not { be { { as { { > easy as MTU discovery, { { > having the marking info compatible is probably better than making { { encoding { { > choice the same in all PCN links. { { > { { > Your comments? { { > { { > Regards, { { > { { > Gengyu { { > School of Computer Science and Technology { { > Beijing University of Posts and Telecommunications { { > { { > ----- Original Message ----- { { > From: { { > To: { { > Cc: { { > Sent: Tuesday, June 17, 2008 6:14 PM { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 { { > { { > { { > Gengyu { { > { { > Thanks very much for your comments! { { > { { > 1) I think this is covered in Section 2.1 (Scope), which states "The { { > same choice MUST be used throughout a PCN-domain." - this refers to { the { { > same choice about encoding states in all the PCN links in the { domain. { { > { { > In your example you have a node with 2 encoding states in the same { { > domain as nodes with 3 encoding states. Therefore the example breaks { the { { > "MUST" in Section 2.1, ie the domain is misconfigured (and so { strictly { { > speaking it isn't a PCN domain, so we don't need to worry about it). { { > { { > If you've a suggestion how to clarify this, please let me know. { { > { { > 2) if I understand you right, you're suggesting that when a link is { { > pre-congested, it sends a message (instead of marking packets). Yes, { { > this is a possible approach, but - as you say - it's out of scope of { { > PCN. { { > { { > thanks { { > phil { { > { { > { -----Original Message----- { { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] { { > { Sent: 17 June 2008 10:39 { { > { To: Eardley,PL,Philip,CXR9 R { { > { Cc: pcn@ietf.org { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 { { > { { { > { Hi, { { > { { { > { I have some questions to ask after reading your I-D. { { > { { { > { 1) In a PCN domain, if the two-state node is between two { three-states { { > { nodes, { { > { how the marking scheme will be? { { > { So is it ture if there is a two-state node along the route, { that { { > will { { > { be { { > { two-state scheme. { { > { This is important for a network administrator. { { > { 2) In section 2.2. Classify and condition function { { > { "There may be traffic that is more important than PCN that { shares { { > the { { > { same capacity as PCN and is priority scheduled over PCN { (perhaps an { { > { operator's control messages). Such traffic MUST be metered as { { > though { { > { it were PCN-traffic, but MUST NOT be PCN-marked. Such packets, { { > { together with PCN-packets, are called "metered packets"." { { > { { { > { You mentioned the packet which contains an operator's control { { > messages, { { > { so my question is if the marking contexts are sent in control { { > messages, { { > { or PCN-capable nodes at ingress generat control messages when { sending { { > { marks, { { > { what the pcn will be? { { > { Perhaps the second question is out of the scope of PCN, { { > { but there was some schemes in ATM to send RM cell instead of { marking { { > each { { > { cell. { { > { { { > { Regards, { { > { { { > { Gengyu { { > { { { > { { { { _______________________________________________ { { 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 From pcn-bounces@ietf.org Fri Jun 20 07:37:15 2008 Return-Path: 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 5D2273A6A41; Fri, 20 Jun 2008 07:37:15 -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 7EAEE3A6A41 for ; Fri, 20 Jun 2008 07:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.551 X-Spam-Level: X-Spam-Status: No, score=0.551 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=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 gszC8VkWGaRX for ; Fri, 20 Jun 2008 07:37:13 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 8D4453A67B3 for ; Fri, 20 Jun 2008 07:37:12 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Fri, 20 Jun 2008 16:37:12 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jun 2008 16:37:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 20 Jun 2008 16:37:04 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0164B207@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <5351E79284D944639901EDC11D6E9676@ibmPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 thread-index: AcjSLq5uaraBcORyR3+01bInrZtR1wAsWNLQ References: <4A916DBC72536E419A0BD955EDECEDEC0329F82B@E03MVB1-UKBR.domain1.systemhost.net> <5351E79284D944639901EDC11D6E9676@ibmPC> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 20 Jun 2008 14:37:12.0549 (UTC) FILETIME=[208BA150:01C8D2E3] Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Gengyu, the two state issue may specifically be relevant for carriers working with MPLS. Inter carrier MPLS services are possible, but still I doubt that there are many carriers operating MPLS with three PCN states if there are just 8 DiffServ states all in all. What you address would then be an interdomain case of one carrier operating three states on IP whose network is connected to another carrier operating a two state network. That's an issue, but interdomain scenarios are out of scope for the time being (Phil mentioned that already). A carrier operating with two state routers in parallel with three state routers - like running IP three state and MPLS two state - well, I'm not sure whether that makes any sense, I'd have to think about that. But to be honest, it looks as if it makes the solution more complex and that's exactly what I try to avoid, unless I can see a clear benefit for the more complex solution. What does a carrier gain if some of his routers work with three PCN states while others work with two states? Please also consider RFC5129 with regards to MPLS behaviour. I wonder whether IETF will accept different remarking schemes during the ultimate label popping than described there any time soon. Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of Wei Gengyu | Sent: Thursday, June 19, 2008 7:05 PM | To: philip.eardley@bt.com | Cc: pcn@ietf.org | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | Phil, | | I am not in Dublin, but I like to drink red tea while | disscussing the technical issues with my collegues. | The network we often concern is the network that covers an | area greater than an island. | | Consider the case, a university with serveral campus located | at different cities, it is one unversity network of a | collection of campus networks. | Or the network of an enterprises with serveral branches | located in different states is one network. | Those are truely existed networks nowadays. | | And having experiences as a network administor will be | helpful to decide how to configure a network and to | understand the problem of coding schemes. | | In your email you described the problem and the node behavior clearly. | I do think that the problems must be solved. | | In my opinion,the problems are due to the semantics of | 2-state and 3-state coding schemes. | So, I argue that the WG should review coding schemes. | | Regards, | | Gengyu | | ----- Original Message ----- | From: | To: | Cc: | Sent: Wednesday, June 18, 2008 8:42 PM | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | I think I may be confusing things unnecessarily. | | The encoding proposal from Toby & Michael et al is structured as | follows: | - a baseline encoding. This uses 1 (standardised) DSCP + the ECN | codepoints in order to encode 2 states. | - an extension encoding. This uses a second DSCP (in addition to the | baseline's DSCP) + the ECN codepoints and encodes 3 states. | | The use of the ECN codepoints is compatible between them, in the sense | that eg ECN 11 means some form of PCN marking in all cases - it was a | deliberate choice to do it like this (So you could say that the 2 | encoding states are a sub-set of the 3 encoding states - | which is one of | your requirements) | | The baseline has already been sent to the list | http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt | - toby plans to send the extension draft soon (a draft is | being reviewed | amongst the authors) | | I think in your example you envisage 2 separate networks both running | PCN which then later get merged into a single PCN-domain. So you have | one with 2 encoding states & one with 3 encoding states (or | indeed: both | have 2 encoding states, but one is using them to trigger admission | control and one termination control, relying on other | mechanisms for the | other function, or one is using the marks to trigger both admission & | termination - ie 'single marking'). As well as the pure encoding, then | there'll be other things to think about - eg the ingress & egress | gateways can be in different domains and so will interpret | the received | marks differently. Personally I think it's reasonable to expect | "management" to have to be done when the 2 separate nws are joined | together to form a single PCN-domain - ie to coordinate how PCN marks | will be interpreted. I don't know whether something clever can be done | that doesn't require such work - maybe it would make a good topic to | discuss over lunch, if you're in Dublin? (I think this kind of | discussion on 'forming a single PCN domain from two separate PCN | domains' probably falls into the inter-domain category, which | is out of | scope of PCN WG in initial charter.) | | Thanks | phil | | { -----Original Message----- | { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | { Sent: 18 June 2008 13:09 | { To: Eardley,PL,Philip,CXR9 R | { Cc: pcn@ietf.org | { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | { | { Phil, and all, | { | { I strongly suggest PCN WG review the coding scheme. | { It is not good to have two exclusive coding algorithms in one | technical | { document. | { | { It is easy to see that 3-states have more information than 2-states. | { It is also possible to make 2-states be the subset of three states. | { The compatibility here means 3-state capability nodes can understand | 2- | { state | { coding. | { | { I did not suggest to use MTU discovery or similar | mechanisms for node | { clarification, neither do here. | { | { While remembering rudiger's words, we should face the existing | problems of | { networks. | { The operator ought to knwo the nodes within its own dommains. | { But, it is rather difficult for any operators to know the nodes of | other | { autonomous nodes | { if a PCN domain covers several autonomous domains. | { | { I believe, it will be better if the PCN coding schemes is easy to | deploy, | { robust to work, and tolerant of faults. | { | { We do not need to make sure everything properly, | { we only need to make 2-state capable nodes work togather | with 3-state | { capable nodes. | { | { Regards, | { | { Gengyu | { | { | { ----- Original Message ----- | { From: | { To: ; | { Sent: Wednesday, June 18, 2008 4:18 PM | { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | { | { | { Gengyu, | { | { You raise interesting questions. I'm not really sure what | compatibility | { means in this context - it would probably need some careful thought | and | { simulations /expts to work out if it could be compatible to some | extent. | { I'm not sure a similar mechanism to MTU discovery would be | appropriate | - | { the number of encoding states in nodes in a PCN-domain really is | { something that the operator of that domain ought to know - | it doesn't | { seem to me that this is a good thing to discover dynamically. | { | { I think we should remember rudiger's warning when we got into | discussing | { configuration issues before - it isn't our job to make sure | everything | { behaves properly if something is configured incorrectly | { | { Best wishes | { Phil | { | { { -----Original Message----- | { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf | Of | { Wei | { { Gengyu | { { Sent: 17 June 2008 18:09 | { { To: pcn@ietf.org | { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | { { | { { | { { ----- Original Message ----- | { { From: "Wei Gengyu" | { { To: | { { Sent: Tuesday, June 17, 2008 10:41 PM | { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | { { | { { | { { > Philip, | { { > | { { > For the first question, your I-D in Section 2.1 is clear as you | { said. | { { > I got it after reading your explanations. Thank you. | { { > | { { > But, I still think it may be better to make 3-states nodes | { compatible | { { with | { { > 2-states node. | { { > Consider the case, if a PCN domain covers more than one | autonomous | { { domain | { { > in the Internet, | { { > the mechanism in sechtion 2.1 could not tolerate any | configuration | { { faults. | { { > | { { > So, if the PCN domain can works in 2-states scheme when | there are | { both | { { > 2-state and 3state nodes, | { { > loosely-consistent checking is required in a PCN domain. | { { > | { { > As clarification of nodes across several autonomous domains may | not | { be | { { as | { { > easy as MTU discovery, | { { > having the marking info compatible is probably better | than making | { { encoding | { { > choice the same in all PCN links. | { { > | { { > Your comments? | { { > | { { > Regards, | { { > | { { > Gengyu | { { > School of Computer Science and Technology | { { > Beijing University of Posts and Telecommunications | { { > | { { > ----- Original Message ----- | { { > From: | { { > To: | { { > Cc: | { { > Sent: Tuesday, June 17, 2008 6:14 PM | { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 | { { > | { { > | { { > Gengyu | { { > | { { > Thanks very much for your comments! | { { > | { { > 1) I think this is covered in Section 2.1 (Scope), which states | "The | { { > same choice MUST be used throughout a PCN-domain." - this refers | to | { the | { { > same choice about encoding states in all the PCN links in the | { domain. | { { > | { { > In your example you have a node with 2 encoding states | in the same | { { > domain as nodes with 3 encoding states. Therefore the example | breaks | { the | { { > "MUST" in Section 2.1, ie the domain is misconfigured (and so | { strictly | { { > speaking it isn't a PCN domain, so we don't need to worry about | it). | { { > | { { > If you've a suggestion how to clarify this, please let me know. | { { > | { { > 2) if I understand you right, you're suggesting that when a link | is | { { > pre-congested, it sends a message (instead of marking packets). | Yes, | { { > this is a possible approach, but - as you say - it's | out of scope | of | { { > PCN. | { { > | { { > thanks | { { > phil | { { > | { { > { -----Original Message----- | { { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | { { > { Sent: 17 June 2008 10:39 | { { > { To: Eardley,PL,Philip,CXR9 R | { { > { Cc: pcn@ietf.org | { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | { { > { | { { > { Hi, | { { > { | { { > { I have some questions to ask after reading your I-D. | { { > { | { { > { 1) In a PCN domain, if the two-state node is between two | { three-states | { { > { nodes, | { { > { how the marking scheme will be? | { { > { So is it ture if there is a two-state node along the route, | { that | { { > will | { { > { be | { { > { two-state scheme. | { { > { This is important for a network administrator. | { { > { 2) In section 2.2. Classify and condition function | { { > { "There may be traffic that is more important than PCN that | { shares | { { > the | { { > { same capacity as PCN and is priority scheduled over PCN | { (perhaps an | { { > { operator's control messages). Such traffic MUST be metered | as | { { > though | { { > { it were PCN-traffic, but MUST NOT be PCN-marked. Such | packets, | { { > { together with PCN-packets, are called "metered packets"." | { { > { | { { > { You mentioned the packet which contains an | operator's control | { { > messages, | { { > { so my question is if the marking contexts are sent in control | { { > messages, | { { > { or PCN-capable nodes at ingress generat control messages when | { sending | { { > { marks, | { { > { what the pcn will be? | { { > { Perhaps the second question is out of the scope of PCN, | { { > { but there was some schemes in ATM to send RM cell instead of | { marking | { { > each | { { > { cell. | { { > { | { { > { Regards, | { { > { | { { > { Gengyu | { { > { | { { > | { { | { { _______________________________________________ | { { 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 | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Jun 21 09:24:11 2008 Return-Path: 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 A2D213A6986; Sat, 21 Jun 2008 09:24:11 -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 CA7D83A6986 for ; Sat, 21 Jun 2008 09:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] 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 V1viWcNeYkBw for ; Sat, 21 Jun 2008 09:24:08 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id E80AA3A6971 for ; Sat, 21 Jun 2008 09:24:06 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B41DE198DC8; Sat, 21 Jun 2008 18:24:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A7EEF198DC6; Sat, 21 Jun 2008 18:24:07 +0200 (CEST) Received: from [132.187.246.77] (wvpn077.vpn.uni-wuerzburg.de [132.187.246.77]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 3EAF5A0638; Sat, 21 Jun 2008 18:24:06 +0200 (CEST) Message-ID: <485D2AF6.80205@informatik.uni-wuerzburg.de> Date: Sat, 21 Jun 2008 18:23:18 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Ingemar Johansson S References: <026F8EEDAD2C4342A993203088C1FC0507A3658A@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0507A3658A@esealmw109.eemea.ericsson.se> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ingemar, what is the message of this draft? a) Don't reset the ECN field to not-ECT for flows crossing a PCN domain. b) Provide PCN marking from within the PCN domain in terms of CE-marks to the end systems. If this is the case, what kind of feedback is useful: i) marking all packets of a flow with CE (exhaustive marking) ii) or just a fraction of them? (excess marking) Regards, Michael Ingemar Johansson S wrote: > Hi > > The ECN-PCN usecases draft has been updated. The main addition is the sec= tion 3.5 suggested by Ken Carlberg. > http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt > > Comments are welcome > /Ingemar > ******************************************* = > Ingemar Johansson = > Senior Research Engineer, IETF "nethead" = > EAB/TVP - Multimedia Technologies = > Ericsson Research Ericsson AB = > Box 920 S-971 28 Lule=E5, Sweden = > Tel: +46 (0)8 4043042 = > ECN: 850-43042 = > ECC: 850-43074 = > Mobile: +46 (0)730 783289 = > ******************************************* = > _______________________________________________ > 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 From pcn-bounces@ietf.org Mon Jun 23 03:56:49 2008 Return-Path: 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 6BBBA3A698D; Mon, 23 Jun 2008 03:56:49 -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 0EFED3A691B for ; Mon, 23 Jun 2008 03:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] 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 xYFFhrkh5z85 for ; Mon, 23 Jun 2008 03:56:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 818D23A6912 for ; Mon, 23 Jun 2008 03:56:46 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 220A0201BC; Mon, 23 Jun 2008 12:56:45 +0200 (CEST) X-AuditID: c1b4fb3e-b019cbb000004ec0-e4-485f816ca56a Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id ED8FD20181; Mon, 23 Jun 2008 12:56:44 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 12:57:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 12:57:09 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0507D7A5D4@esealmw109.eemea.ericsson.se> In-Reply-To: <485D2AF6.80205@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains thread-index: AcjTu0jIJV5HP3GVRsO3OdPfFl43OwBXyoYA References: <026F8EEDAD2C4342A993203088C1FC0507A3658A@esealmw109.eemea.ericsson.se> <485D2AF6.80205@informatik.uni-wuerzburg.de> From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 23 Jun 2008 10:57:09.0588 (UTC) FILETIME=[E234E940:01C8D51F] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org Subject: Re: [PCN] Usecases and Benefits of end to end ECN support in PCN Domains X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Answers below. > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] = > Sent: den 21 juni 2008 18:23 > To: Ingemar Johansson S > Cc: pcn@ietf.org > Subject: Re: [PCN] Usecases and Benefits of end to end ECN = > support in PCN Domains > = > Hi Ingemar, > = > what is the message of this draft? > = > a) Don't reset the ECN field to not-ECT for flows crossing a = > PCN domain. Correct = > b) Provide PCN marking from within the PCN domain in terms of = > CE-marks to the end systems. If this is the case, what kind = > of feedback is useful: > i) marking all packets of a flow with CE (exhaustive marking) > ii) or just a fraction of them? (excess marking) It is not necessary if we only consider congestion that occurs outside PCN = domains like in case 1) below. If however we discuss cases like 2) or 3) be= low... Difficult to answer to this question (i or ii), my guess is that the client= should be liberal in what ECN-CE pattern it receives. A coarse method is t= hat the media receiver requests a reduction of e.g the video bitrate by 50%= if more than N ECN-CE marked packets are received in a given short timefra= me. This method would be fairly robust to both alternatives (i or ii) above. Originally the main focus was on maintaining e2e ECN semantics across PCN d= omains. Under normal circumstances one could argue that with proper resourc= e reservation and the use of e.g PCN there should not be any specific need = to maintain e2e ECN semantics for for e.g EF-flows as there will (in theory= ) not be any congestion experienced for these flows. = There are however at least three scenarios where e2e ECN semantics are usef= ul. 1) Wireless transmission: Due to issues like shadowing, hot spots et.c. It = is not always possible to maintain a given QoS. The use of ECN in both wire= less up and downlink would provide with a possibility for a quick response = to congestion. 2) Flash crowds: As I understand this can become an issue within PCN domain= s. A means to tamper this would be that either the ingress or egress nodes = ECN mark flows. The flows that comply within a given time frame are treated= gently while non-compliant flows are treated worse. 3) Emergency services: There could be a desire to elevate priority for eg. = emergency services. Ecn marking can here serve as a mechanism to free netwo= rk resources without the need to terminate flows. The similar policing as i= n 2) could be used here. /Ingemar > = > Regards, > = > Michael > = > = > Ingemar Johansson S wrote: > > Hi > > > > The ECN-PCN usecases draft has been updated. The main = > addition is the section 3.5 suggested by Ken Carlberg. > > http://tools.ietf.org/id/draft-sarker-pcn-ecn-pcn-usecases-01.txt > > > > Comments are welcome > > /Ingemar > > ******************************************* > > Ingemar Johansson > > Senior Research Engineer, IETF "nethead" = > > EAB/TVP - Multimedia Technologies > > Ericsson Research Ericsson AB > > Box 920 S-971 28 Lule=E5, Sweden > > Tel: +46 (0)8 4043042 > > ECN: 850-43042 > > ECC: 850-43074 > > Mobile: +46 (0)730 783289 > > ******************************************* > > _______________________________________________ > > 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 From pcn-bounces@ietf.org Mon Jun 23 04:25:54 2008 Return-Path: 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 3512C3A68EF; Mon, 23 Jun 2008 04:25:54 -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 A20673A68DA for ; Mon, 23 Jun 2008 04:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, STOX_REPLY_TYPE=0.001] 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 4Il1KUcsecMS for ; Mon, 23 Jun 2008 04:25:48 -0700 (PDT) Received: from smtp-6-98.vip.sina.com (smtp.vip.sina.com [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id 7911B3A691B for ; Mon, 23 Jun 2008 04:25:46 -0700 (PDT) Received: from ibmPC (unknown [211.160.21.17]) by smtp-6-98.vip.sina.com (SINAMAIL) with ESMTP id 8B56C1DE0B8; Mon, 23 Jun 2008 19:25:35 +0800 (CST) Message-ID: From: "Wei Gengyu" To: "Geib, Ruediger" References: <4A916DBC72536E419A0BD955EDECEDEC0329F82B@E03MVB1-UKBR.domain1.systemhost.net> <5351E79284D944639901EDC11D6E9676@ibmPC> <1B6169C658325341A3B8066E23919E1C0164B207@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0164B207@S4DE8PSAANK.mitte.t-com.de> Date: Mon, 23 Jun 2008 19:23:21 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Rudiger, I see that the decription about the scope of PCN on the PCN Homepage. "The Congestion and Pre-Congestion Notification (PCN) working group develops mechanisms to protect the quality-of-service of established inelastic flows within a DiffServ domain when congestion is imminent or existing." "The initial scope of the PCN WG is restricted by the following assumptions: (A) these components are deployed in a single DiffServ domain, where all boundary and interior nodes are PCN-enabled and trust each other for correct PCN marking, encoding, transport and aggregation " But, What is is a DS domain? I do not know where the definition of a DS domain is from. Perhaps, all connected equipements capable of DiffServ marking form a DS domain. Right? Then consider a compus network that includes Ethernet, ATM, MPLS equipements. The compus network is owned and operated by the university. My questions are 1) is the campus network a single DS domain? 2) are there both three state coding and two state coding existed if adopting PCN? Regards, Gengyu ----- Original Message ----- From: "Geib, Ruediger" To: Cc: ; Sent: Friday, June 20, 2008 10:37 PM Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 Gengyu, the two state issue may specifically be relevant for carriers working with MPLS. Inter carrier MPLS services are possible, but still I doubt that there are many carriers operating MPLS with three PCN states if there are just 8 DiffServ states all in all. What you address would then be an interdomain case of one carrier operating three states on IP whose network is connected to another carrier operating a two state network. That's an issue, but interdomain scenarios are out of scope for the time being (Phil mentioned that already). A carrier operating with two state routers in parallel with three state routers - like running IP three state and MPLS two state - well, I'm not sure whether that makes any sense, I'd have to think about that. But to be honest, it looks as if it makes the solution more complex and that's exactly what I try to avoid, unless I can see a clear benefit for the more complex solution. What does a carrier gain if some of his routers work with three PCN states while others work with two states? Please also consider RFC5129 with regards to MPLS behaviour. I wonder whether IETF will accept different remarking schemes during the ultimate label popping than described there any time soon. Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of Wei Gengyu | Sent: Thursday, June 19, 2008 7:05 PM | To: philip.eardley@bt.com | Cc: pcn@ietf.org | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | Phil, | | I am not in Dublin, but I like to drink red tea while | disscussing the technical issues with my collegues. | The network we often concern is the network that covers an | area greater than an island. | | Consider the case, a university with serveral campus located | at different cities, it is one unversity network of a | collection of campus networks. | Or the network of an enterprises with serveral branches | located in different states is one network. | Those are truely existed networks nowadays. | | And having experiences as a network administor will be | helpful to decide how to configure a network and to | understand the problem of coding schemes. | | In your email you described the problem and the node behavior clearly. | I do think that the problems must be solved. | | In my opinion,the problems are due to the semantics of | 2-state and 3-state coding schemes. | So, I argue that the WG should review coding schemes. | | Regards, | | Gengyu | | ----- Original Message ----- | From: | To: | Cc: | Sent: Wednesday, June 18, 2008 8:42 PM | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | I think I may be confusing things unnecessarily. | | The encoding proposal from Toby & Michael et al is structured as | follows: | - a baseline encoding. This uses 1 (standardised) DSCP + the ECN | codepoints in order to encode 2 states. | - an extension encoding. This uses a second DSCP (in addition to the | baseline's DSCP) + the ECN codepoints and encodes 3 states. | | The use of the ECN codepoints is compatible between them, in the sense | that eg ECN 11 means some form of PCN marking in all cases - it was a | deliberate choice to do it like this (So you could say that the 2 | encoding states are a sub-set of the 3 encoding states - | which is one of | your requirements) | | The baseline has already been sent to the list | http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt | - toby plans to send the extension draft soon (a draft is | being reviewed | amongst the authors) | | I think in your example you envisage 2 separate networks both running | PCN which then later get merged into a single PCN-domain. So you have | one with 2 encoding states & one with 3 encoding states (or | indeed: both | have 2 encoding states, but one is using them to trigger admission | control and one termination control, relying on other | mechanisms for the | other function, or one is using the marks to trigger both admission & | termination - ie 'single marking'). As well as the pure encoding, then | there'll be other things to think about - eg the ingress & egress | gateways can be in different domains and so will interpret | the received | marks differently. Personally I think it's reasonable to expect | "management" to have to be done when the 2 separate nws are joined | together to form a single PCN-domain - ie to coordinate how PCN marks | will be interpreted. I don't know whether something clever can be done | that doesn't require such work - maybe it would make a good topic to | discuss over lunch, if you're in Dublin? (I think this kind of | discussion on 'forming a single PCN domain from two separate PCN | domains' probably falls into the inter-domain category, which | is out of | scope of PCN WG in initial charter.) | | Thanks | phil | | { -----Original Message----- | { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | { Sent: 18 June 2008 13:09 | { To: Eardley,PL,Philip,CXR9 R | { Cc: pcn@ietf.org | { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | { | { Phil, and all, | { | { I strongly suggest PCN WG review the coding scheme. | { It is not good to have two exclusive coding algorithms in one | technical | { document. | { | { It is easy to see that 3-states have more information than 2-states. | { It is also possible to make 2-states be the subset of three states. | { The compatibility here means 3-state capability nodes can understand | 2- | { state | { coding. | { | { I did not suggest to use MTU discovery or similar | mechanisms for node | { clarification, neither do here. | { | { While remembering rudiger's words, we should face the existing | problems of | { networks. | { The operator ought to knwo the nodes within its own dommains. | { But, it is rather difficult for any operators to know the nodes of | other | { autonomous nodes | { if a PCN domain covers several autonomous domains. | { | { I believe, it will be better if the PCN coding schemes is easy to | deploy, | { robust to work, and tolerant of faults. | { | { We do not need to make sure everything properly, | { we only need to make 2-state capable nodes work togather | with 3-state | { capable nodes. | { | { Regards, | { | { Gengyu | { | { | { ----- Original Message ----- | { From: | { To: ; | { Sent: Wednesday, June 18, 2008 4:18 PM | { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | { | { | { Gengyu, | { | { You raise interesting questions. I'm not really sure what | compatibility | { means in this context - it would probably need some careful thought | and | { simulations /expts to work out if it could be compatible to some | extent. | { I'm not sure a similar mechanism to MTU discovery would be | appropriate | - | { the number of encoding states in nodes in a PCN-domain really is | { something that the operator of that domain ought to know - | it doesn't | { seem to me that this is a good thing to discover dynamically. | { | { I think we should remember rudiger's warning when we got into | discussing | { configuration issues before - it isn't our job to make sure | everything | { behaves properly if something is configured incorrectly | { | { Best wishes | { Phil | { | { { -----Original Message----- | { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf | Of | { Wei | { { Gengyu | { { Sent: 17 June 2008 18:09 | { { To: pcn@ietf.org | { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | { { | { { | { { ----- Original Message ----- | { { From: "Wei Gengyu" | { { To: | { { Sent: Tuesday, June 17, 2008 10:41 PM | { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | { { | { { | { { > Philip, | { { > | { { > For the first question, your I-D in Section 2.1 is clear as you | { said. | { { > I got it after reading your explanations. Thank you. | { { > | { { > But, I still think it may be better to make 3-states nodes | { compatible | { { with | { { > 2-states node. | { { > Consider the case, if a PCN domain covers more than one | autonomous | { { domain | { { > in the Internet, | { { > the mechanism in sechtion 2.1 could not tolerate any | configuration | { { faults. | { { > | { { > So, if the PCN domain can works in 2-states scheme when | there are | { both | { { > 2-state and 3state nodes, | { { > loosely-consistent checking is required in a PCN domain. | { { > | { { > As clarification of nodes across several autonomous domains may | not | { be | { { as | { { > easy as MTU discovery, | { { > having the marking info compatible is probably better | than making | { { encoding | { { > choice the same in all PCN links. | { { > | { { > Your comments? | { { > | { { > Regards, | { { > | { { > Gengyu | { { > School of Computer Science and Technology | { { > Beijing University of Posts and Telecommunications | { { > | { { > ----- Original Message ----- | { { > From: | { { > To: | { { > Cc: | { { > Sent: Tuesday, June 17, 2008 6:14 PM | { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 | { { > | { { > | { { > Gengyu | { { > | { { > Thanks very much for your comments! | { { > | { { > 1) I think this is covered in Section 2.1 (Scope), which states | "The | { { > same choice MUST be used throughout a PCN-domain." - this refers | to | { the | { { > same choice about encoding states in all the PCN links in the | { domain. | { { > | { { > In your example you have a node with 2 encoding states | in the same | { { > domain as nodes with 3 encoding states. Therefore the example | breaks | { the | { { > "MUST" in Section 2.1, ie the domain is misconfigured (and so | { strictly | { { > speaking it isn't a PCN domain, so we don't need to worry about | it). | { { > | { { > If you've a suggestion how to clarify this, please let me know. | { { > | { { > 2) if I understand you right, you're suggesting that when a link | is | { { > pre-congested, it sends a message (instead of marking packets). | Yes, | { { > this is a possible approach, but - as you say - it's | out of scope | of | { { > PCN. | { { > | { { > thanks | { { > phil | { { > | { { > { -----Original Message----- | { { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | { { > { Sent: 17 June 2008 10:39 | { { > { To: Eardley,PL,Philip,CXR9 R | { { > { Cc: pcn@ietf.org | { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | { { > { | { { > { Hi, | { { > { | { { > { I have some questions to ask after reading your I-D. | { { > { | { { > { 1) In a PCN domain, if the two-state node is between two | { three-states | { { > { nodes, | { { > { how the marking scheme will be? | { { > { So is it ture if there is a two-state node along the route, | { that | { { > will | { { > { be | { { > { two-state scheme. | { { > { This is important for a network administrator. | { { > { 2) In section 2.2. Classify and condition function | { { > { "There may be traffic that is more important than PCN that | { shares | { { > the | { { > { same capacity as PCN and is priority scheduled over PCN | { (perhaps an | { { > { operator's control messages). Such traffic MUST be metered | as | { { > though | { { > { it were PCN-traffic, but MUST NOT be PCN-marked. Such | packets, | { { > { together with PCN-packets, are called "metered packets"." | { { > { | { { > { You mentioned the packet which contains an | operator's control | { { > messages, | { { > { so my question is if the marking contexts are sent in control | { { > messages, | { { > { or PCN-capable nodes at ingress generat control messages when | { sending | { { > { marks, | { { > { what the pcn will be? | { { > { Perhaps the second question is out of the scope of PCN, | { { > { but there was some schemes in ATM to send RM cell instead of | { marking | { { > each | { { > { cell. | { { > { | { { > { Regards, | { { > { | { { > { Gengyu | { { > { | { { > | { { | { { _______________________________________________ | { { 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 | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jun 23 10:12:14 2008 Return-Path: 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 280633A6A29; Mon, 23 Jun 2008 10:12:14 -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 B54443A69FA for ; Mon, 23 Jun 2008 10:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[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 oMsrNiwMQeiR for ; Mon, 23 Jun 2008 10:12:13 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A8BF73A69D5 for ; Mon, 23 Jun 2008 10:12:12 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 18:12:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 18:12:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-moncaster-pcn-baseline-encoding-01 Thread-Index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaA From: To: X-OriginalArrivalTime: 23 Jun 2008 17:12:10.0173 (UTC) FILETIME=[4599B6D0:01C8D554] Cc: steven.blake@ericsson.com Subject: [PCN] FW: New Version Notification for draft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Here is the latest revision to the baseline encoding document. Please let me have any suggested changes by July 8th to give me time to upload a further revision before Dublin. Do people think this is in any state yet to request it to be considered as a WG draft? Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: 23 June 2008 18:09 To: Moncaster,T,Toby,CXR9 R Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de Subject: New Version Notification for draft-moncaster-pcn-baseline-encoding-01 A new version of I-D, draft-moncaster-pcn-baseline-encoding-01.txt has been successfuly submitted by T Moncaster and posted to the IETF repository. Filename: draft-moncaster-pcn-baseline-encoding Revision: 01 Title: Baseline Encoding and Transport of Pre-Congestion Information Creation_date: 2008-06-23 WG ID: Independent Submission 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 rate 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. Another document describes an extended encoding scheme that allows for three 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 PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jun 23 10:14:42 2008 Return-Path: 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 73D153A699F; Mon, 23 Jun 2008 10:14: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 A4EFC3A699F for ; Mon, 23 Jun 2008 10:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[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 X8HoXw4h67ak for ; Mon, 23 Jun 2008 10:14:41 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id A9AA13A63D2 for ; Mon, 23 Jun 2008 10:14:40 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 18:14:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jun 2008 18:14:30 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-moncaster-pcn-3-state-encoding-00 Thread-Index: AcjVU+bNZiMWYhQ2TvupjcXli73s+wAAFr3Q From: To: X-OriginalArrivalTime: 23 Jun 2008 17:14:40.0525 (UTC) FILETIME=[9F379BD0:01C8D554] Subject: [PCN] FW: New Version Notification for draft-moncaster-pcn-3-state-encoding-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org As promised in earlier emails here is the first version of the extended PCN encoding scheme draft. Note it hasn't been completely checked for consistency, grammar, etc so any and all reviews gratefully accepted. My hope is to get a 01 version out in plenty of time for Dublin. Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: 23 June 2008 18:09 To: Moncaster,T,Toby,CXR9 R Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de Subject: New Version Notification for draft-moncaster-pcn-3-state-encoding-00 A new version of I-D, draft-moncaster-pcn-3-state-encoding-00.txt has been successfuly submitted by T Moncaster and posted to the IETF repository. Filename: draft-moncaster-pcn-3-state-encoding Revision: 00 Title: A three state extended PCN encoding scheme Creation_date: 2008-06-23 WG ID: Independent Submission Number_of_pages: 13 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 baseline encoding specified how two encoding states could be encoded into the IP header. This document specified an extension to the baseline encoding that enables three encoding states to be carried in the IP header as well as enabling limited support for end-to-end ECN. Status This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. The IETF Secretariat. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 24 03:45:11 2008 Return-Path: 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 AF8313A6886; Tue, 24 Jun 2008 03:45:10 -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 572D33A68F5 for ; Tue, 24 Jun 2008 03:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[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 25B3O5X0k8rN for ; Tue, 24 Jun 2008 03:45:04 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 3851F3A67EB for ; Tue, 24 Jun 2008 03:45:01 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 11:45:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 11:45:02 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F86B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 Thread-Index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaAACSHZwA= From: To: , X-OriginalArrivalTime: 24 Jun 2008 10:45:02.0427 (UTC) FILETIME=[5B32B2B0:01C8D5E7] Cc: steven.blake@ericsson.com Subject: Re: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Toby, all, Quick comment: in section 4.3 : PCN edge node behaviour compliant with the PCN baseline encoding: o Any packets with the ECN field already marked as CE or ECT arriving at a PCN ingress node SHOULD be dropped or alternatively MAY be tunnelled through the PCN-domain. They MUST NOT be admitted to the PCN-domain directly. - downgrading also seems possible, ie setting DS codepoint to a lower behaviour aggregate like best effort or assured forwarding - suggest "SHOULD be dropped or downgraded" - not clear to me that one is particularly preferable to the other - agree with MAY tunnel - basically because it needs extra signalling work would be very interested in comments on this. currently am re-writing the traffic conditioning section of draft-eardley-marking-behaviour. This has a similar choice about what to do to out-of-profile traffic. My current idea is simply to list the different possible actions that you "may" take - ie follow the approach of RFC2475 (Diffserv architecture) phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { toby.moncaster@bt.com { Sent: 23 June 2008 18:12 { To: pcn@ietf.org { Cc: steven.blake@ericsson.com { Subject: [PCN] FW: New Version Notification fordraft-moncaster-pcn- { baseline-encoding-01 { { { Here is the latest revision to the baseline encoding document. Please { let me have any suggested changes by July 8th to give me time to upload { a further revision before Dublin. { { Do people think this is in any state yet to request it to be considered { as a WG draft? { { Toby { ____________________________________________________________________ { Toby Moncaster, Networks Research Centre, BT { B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 { { { -----Original Message----- { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] { Sent: 23 June 2008 18:09 { To: Moncaster,T,Toby,CXR9 R { Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de { Subject: New Version Notification for { draft-moncaster-pcn-baseline-encoding-01 { { { A new version of I-D, draft-moncaster-pcn-baseline-encoding-01.txt has { been successfuly submitted by T Moncaster and posted to the IETF { repository. { { Filename: draft-moncaster-pcn-baseline-encoding { Revision: 01 { Title: Baseline Encoding and Transport of Pre-Congestion { Information { Creation_date: 2008-06-23 { WG ID: Independent Submission { 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 { rate 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. { Another document describes an extended encoding scheme that allows { for three 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 { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 24 04:40:12 2008 Return-Path: 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 010FE3A6911; Tue, 24 Jun 2008 04:40:12 -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 BE7283A68D3 for ; Tue, 24 Jun 2008 04:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=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 fPwNAPXaGb3M for ; Tue, 24 Jun 2008 04:40:09 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 8D57F3A68BA for ; Tue, 24 Jun 2008 04:40:08 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Tue, 24 Jun 2008 13:40:07 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 13:40:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 13:40:06 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C4C168E@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 Thread-Index: AcjVI+GTxKRsgLdvQmCwKtBfhqcxYgAymCBQ References: <4A916DBC72536E419A0BD955EDECEDEC0329F82B@E03MVB1-UKBR.domain1.systemhost.net> <5351E79284D944639901EDC11D6E9676@ibmPC> <1B6169C658325341A3B8066E23919E1C0164B207@S4DE8PSAANK.mitte.t-com.de> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 24 Jun 2008 11:40:06.0429 (UTC) FILETIME=[0C8964D0:01C8D5EF] Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Gengyu | But, What is is a DS domain? | I do not know where the definition of a DS domain is from. | Perhaps, all connected equipements capable of DiffServ | marking form a DS domain. Right? See RFC 2475 DS domain a DS-capable domain; a contiguous set of nodes which operate with a common set of service provisioning policies and PHB definitions. | Then consider a compus network that includes Ethernet, ATM, | MPLS equipements. | The compus network is owned and operated by the university. | | My questions are | 1) is the campus network a single DS domain? Yes, presumably (unless each faculty runs an own network). | 2) are there both three state coding and two state coding | existed if adopting PCN? I don't think so. What would be the benefit of that as compared to the cost? If operation and planning of such a network is just simple, such a solution may be worth thinking about. But I doubt that it is simple. Regards, Rudiger | | Regards, | | Gengyu | | | ----- Original Message ----- | From: "Geib, Ruediger" | To: | Cc: ; | Sent: Friday, June 20, 2008 10:37 PM | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | Gengyu, | | the two state issue may specifically be relevant for carriers | working with | MPLS. Inter carrier MPLS services are possible, but still I | doubt that there | are many carriers operating MPLS with three PCN states if | there are just 8 | DiffServ states all in all. | | What you address would then be an interdomain case of one | carrier operating | three states on IP whose network is connected to another | carrier operating a | two state network. That's an issue, but interdomain scenarios | are out of | scope for the time being (Phil mentioned that already). | | A carrier operating with two state routers in parallel with | three state | routers - like running IP three state and MPLS two state - | well, I'm not | sure whether that makes any sense, I'd have to think about | that. But to be | honest, it looks as if it makes the solution more complex and | that's exactly | what I try to avoid, unless I can see a clear benefit for the | more complex | solution. What does a carrier gain if some of his routers | work with three | PCN states while others work with two states? | | Please also consider RFC5129 with regards to MPLS behaviour. I wonder | whether IETF will accept different remarking schemes during | the ultimate | label popping than described there any time soon. | | Regards, | | Rudiger | | | | -----Original Message----- | | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | | Behalf Of Wei Gengyu | | Sent: Thursday, June 19, 2008 7:05 PM | | To: philip.eardley@bt.com | | Cc: pcn@ietf.org | | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | Phil, | | | | I am not in Dublin, but I like to drink red tea while | | disscussing the technical issues with my collegues. | | The network we often concern is the network that covers an | | area greater than an island. | | | | Consider the case, a university with serveral campus located | | at different cities, it is one unversity network of a | | collection of campus networks. | | Or the network of an enterprises with serveral branches | | located in different states is one network. | | Those are truely existed networks nowadays. | | | | And having experiences as a network administor will be | | helpful to decide how to configure a network and to | | understand the problem of coding schemes. | | | | In your email you described the problem and the node | behavior clearly. | | I do think that the problems must be solved. | | | | In my opinion,the problems are due to the semantics of | | 2-state and 3-state coding schemes. | | So, I argue that the WG should review coding schemes. | | | | Regards, | | | | Gengyu | | | | ----- Original Message ----- | | From: | | To: | | Cc: | | Sent: Wednesday, June 18, 2008 8:42 PM | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | I think I may be confusing things unnecessarily. | | | | The encoding proposal from Toby & Michael et al is structured as | | follows: | | - a baseline encoding. This uses 1 (standardised) DSCP + the ECN | | codepoints in order to encode 2 states. | | - an extension encoding. This uses a second DSCP (in addition to the | | baseline's DSCP) + the ECN codepoints and encodes 3 states. | | | | The use of the ECN codepoints is compatible between them, | in the sense | | that eg ECN 11 means some form of PCN marking in all cases | - it was a | | deliberate choice to do it like this (So you could say that the 2 | | encoding states are a sub-set of the 3 encoding states - | | which is one of | | your requirements) | | | | The baseline has already been sent to the list | | | http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt | | - toby plans to send the extension draft soon (a draft is | | being reviewed | | amongst the authors) | | | | I think in your example you envisage 2 separate networks | both running | | PCN which then later get merged into a single PCN-domain. | So you have | | one with 2 encoding states & one with 3 encoding states (or | | indeed: both | | have 2 encoding states, but one is using them to trigger admission | | control and one termination control, relying on other | | mechanisms for the | | other function, or one is using the marks to trigger both | admission & | | termination - ie 'single marking'). As well as the pure | encoding, then | | there'll be other things to think about - eg the ingress & egress | | gateways can be in different domains and so will interpret | | the received | | marks differently. Personally I think it's reasonable to expect | | "management" to have to be done when the 2 separate nws are joined | | together to form a single PCN-domain - ie to coordinate how | PCN marks | | will be interpreted. I don't know whether something clever | can be done | | that doesn't require such work - maybe it would make a good topic to | | discuss over lunch, if you're in Dublin? (I think this kind of | | discussion on 'forming a single PCN domain from two separate PCN | | domains' probably falls into the inter-domain category, which | | is out of | | scope of PCN WG in initial charter.) | | | | Thanks | | phil | | | | { -----Original Message----- | | { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | { Sent: 18 June 2008 13:09 | | { To: Eardley,PL,Philip,CXR9 R | | { Cc: pcn@ietf.org | | { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | { | | { Phil, and all, | | { | | { I strongly suggest PCN WG review the coding scheme. | | { It is not good to have two exclusive coding algorithms in one | | technical | | { document. | | { | | { It is easy to see that 3-states have more information | than 2-states. | | { It is also possible to make 2-states be the subset of | three states. | | { The compatibility here means 3-state capability nodes can | understand | | 2- | | { state | | { coding. | | { | | { I did not suggest to use MTU discovery or similar | | mechanisms for node | | { clarification, neither do here. | | { | | { While remembering rudiger's words, we should face the existing | | problems of | | { networks. | | { The operator ought to knwo the nodes within its own dommains. | | { But, it is rather difficult for any operators to know the nodes of | | other | | { autonomous nodes | | { if a PCN domain covers several autonomous domains. | | { | | { I believe, it will be better if the PCN coding schemes is easy to | | deploy, | | { robust to work, and tolerant of faults. | | { | | { We do not need to make sure everything properly, | | { we only need to make 2-state capable nodes work togather | | with 3-state | | { capable nodes. | | { | | { Regards, | | { | | { Gengyu | | { | | { | | { ----- Original Message ----- | | { From: | | { To: ; | | { Sent: Wednesday, June 18, 2008 4:18 PM | | { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | { | | { | | { Gengyu, | | { | | { You raise interesting questions. I'm not really sure what | | compatibility | | { means in this context - it would probably need some | careful thought | | and | | { simulations /expts to work out if it could be compatible to some | | extent. | | { I'm not sure a similar mechanism to MTU discovery would be | | appropriate | | - | | { the number of encoding states in nodes in a PCN-domain really is | | { something that the operator of that domain ought to know - | | it doesn't | | { seem to me that this is a good thing to discover dynamically. | | { | | { I think we should remember rudiger's warning when we got into | | discussing | | { configuration issues before - it isn't our job to make sure | | everything | | { behaves properly if something is configured incorrectly | | { | | { Best wishes | | { Phil | | { | | { { -----Original Message----- | | { { From: pcn-bounces@ietf.org | [mailto:pcn-bounces@ietf.org] On Behalf | | Of | | { Wei | | { { Gengyu | | { { Sent: 17 June 2008 18:09 | | { { To: pcn@ietf.org | | { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | { { | | { { | | { { ----- Original Message ----- | | { { From: "Wei Gengyu" | | { { To: | | { { Sent: Tuesday, June 17, 2008 10:41 PM | | { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | | { { | | { { | | { { > Philip, | | { { > | | { { > For the first question, your I-D in Section 2.1 is | clear as you | | { said. | | { { > I got it after reading your explanations. Thank you. | | { { > | | { { > But, I still think it may be better to make 3-states nodes | | { compatible | | { { with | | { { > 2-states node. | | { { > Consider the case, if a PCN domain covers more than one | | autonomous | | { { domain | | { { > in the Internet, | | { { > the mechanism in sechtion 2.1 could not tolerate any | | configuration | | { { faults. | | { { > | | { { > So, if the PCN domain can works in 2-states scheme when | | there are | | { both | | { { > 2-state and 3state nodes, | | { { > loosely-consistent checking is required in a PCN domain. | | { { > | | { { > As clarification of nodes across several autonomous | domains may | | not | | { be | | { { as | | { { > easy as MTU discovery, | | { { > having the marking info compatible is probably better | | than making | | { { encoding | | { { > choice the same in all PCN links. | | { { > | | { { > Your comments? | | { { > | | { { > Regards, | | { { > | | { { > Gengyu | | { { > School of Computer Science and Technology | | { { > Beijing University of Posts and Telecommunications | | { { > | | { { > ----- Original Message ----- | | { { > From: | | { { > To: | | { { > Cc: | | { { > Sent: Tuesday, June 17, 2008 6:14 PM | | { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 | | { { > | | { { > | | { { > Gengyu | | { { > | | { { > Thanks very much for your comments! | | { { > | | { { > 1) I think this is covered in Section 2.1 (Scope), | which states | | "The | | { { > same choice MUST be used throughout a PCN-domain." - | this refers | | to | | { the | | { { > same choice about encoding states in all the PCN links in the | | { domain. | | { { > | | { { > In your example you have a node with 2 encoding states | | in the same | | { { > domain as nodes with 3 encoding states. Therefore the example | | breaks | | { the | | { { > "MUST" in Section 2.1, ie the domain is misconfigured (and so | | { strictly | | { { > speaking it isn't a PCN domain, so we don't need to | worry about | | it). | | { { > | | { { > If you've a suggestion how to clarify this, please | let me know. | | { { > | | { { > 2) if I understand you right, you're suggesting that | when a link | | is | | { { > pre-congested, it sends a message (instead of marking | packets). | | Yes, | | { { > this is a possible approach, but - as you say - it's | | out of scope | | of | | { { > PCN. | | { { > | | { { > thanks | | { { > phil | | { { > | | { { > { -----Original Message----- | | { { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | { { > { Sent: 17 June 2008 10:39 | | { { > { To: Eardley,PL,Philip,CXR9 R | | { { > { Cc: pcn@ietf.org | | { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | | { { > { | | { { > { Hi, | | { { > { | | { { > { I have some questions to ask after reading your I-D. | | { { > { | | { { > { 1) In a PCN domain, if the two-state node is between two | | { three-states | | { { > { nodes, | | { { > { how the marking scheme will be? | | { { > { So is it ture if there is a two-state node along | the route, | | { that | | { { > will | | { { > { be | | { { > { two-state scheme. | | { { > { This is important for a network administrator. | | { { > { 2) In section 2.2. Classify and condition function | | { { > { "There may be traffic that is more important | than PCN that | | { shares | | { { > the | | { { > { same capacity as PCN and is priority scheduled over PCN | | { (perhaps an | | { { > { operator's control messages). Such traffic MUST | be metered | | as | | { { > though | | { { > { it were PCN-traffic, but MUST NOT be PCN-marked. Such | | packets, | | { { > { together with PCN-packets, are called "metered packets"." | | { { > { | | { { > { You mentioned the packet which contains an | | operator's control | | { { > messages, | | { { > { so my question is if the marking contexts are sent | in control | | { { > messages, | | { { > { or PCN-capable nodes at ingress generat control | messages when | | { sending | | { { > { marks, | | { { > { what the pcn will be? | | { { > { Perhaps the second question is out of the scope of PCN, | | { { > { but there was some schemes in ATM to send RM cell instead of | | { marking | | { { > each | | { { > { cell. | | { { > { | | { { > { Regards, | | { { > { | | { { > { Gengyu | | { { > { | | { { > | | { { | | { { _______________________________________________ | | { { 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 | | | | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 24 04:56:38 2008 Return-Path: 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 65DB13A69C2; Tue, 24 Jun 2008 04:56:38 -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 CEF7D3A69C2 for ; Tue, 24 Jun 2008 04:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] 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 lqdMDDn9lDWS for ; Tue, 24 Jun 2008 04:56:35 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8D73C3A69B2 for ; Tue, 24 Jun 2008 04:56:35 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 7B2602071B; Tue, 24 Jun 2008 13:56:35 +0200 (CEST) X-AuditID: c1b4fb3c-af09dbb00000193b-a2-4860e0f3815b Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 536EE203FB; Tue, 24 Jun 2008 13:56:35 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 13:57:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 13:57:01 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0507DB168F@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 thread-index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaAACWf+ZA= References: From: "Ingemar Johansson S" To: , X-OriginalArrivalTime: 24 Jun 2008 11:57:01.0700 (UTC) FILETIME=[69AF7440:01C8D5F1] X-Brightmail-Tracker: AAAAAA== Cc: steven.blake@ericsson.com Subject: Re: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi I have one comment to section 4.3 > o Any packets with the ECN field already marked as CE or ECT > arriving at a PCN ingress node SHOULD be dropped or alternatively > MAY be tunnelled through the PCN-domain. They MUST NOT be > admitted to the PCN-domain directly. Sounds reasonable. One issue however that I don't understand is where the decision to do tunneling is made. With my limited knowledge about IP tunneling I understand that PCN ingress determines that the flow is ECT or ECN-CE, then applies tunneling and signals to the PCN egress about this. What protocols are defined for this (or is it outside the scope of the current charter?). Does tunneling of ECN enabled flows need a separate section ? > o On leaving the PCN-domain the ECN bits MUST be set to 00 (Not > ECT). If the tunneling approach (for ECT flows) is used, my understanding is that the ECN bits should not be set to zero at PCN egress as these contain ECN-CE and ECT already set before PCN ingress. Regards Ingemar > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of toby.moncaster@bt.com > Sent: den 23 juni 2008 19:12 > To: pcn@ietf.org > Cc: steven.blake@ericsson.com > Subject: [PCN] FW: New Version Notification > fordraft-moncaster-pcn-baseline-encoding-01 > > > Here is the latest revision to the baseline encoding > document. Please let me have any suggested changes by July > 8th to give me time to upload a further revision before Dublin. > > Do people think this is in any state yet to request it to be > considered as a WG draft? > > Toby > ____________________________________________________________________ > Toby Moncaster, Networks Research > Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > 1473 648734 > > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 23 June 2008 18:09 > To: Moncaster,T,Toby,CXR9 R > Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de > Subject: New Version Notification for > draft-moncaster-pcn-baseline-encoding-01 > > > A new version of I-D, draft-moncaster-pcn-baseline-encoding-01.txt has > been successfuly submitted by T Moncaster and posted to the IETF > repository. > > Filename: draft-moncaster-pcn-baseline-encoding > Revision: 01 > Title: Baseline Encoding and Transport of > Pre-Congestion > Information > Creation_date: 2008-06-23 > WG ID: Independent Submission > 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 > rate 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. > Another document describes an extended encoding scheme that allows > for three 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 > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 24 06:22:47 2008 Return-Path: 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 684C13A6824; Tue, 24 Jun 2008 06:22:47 -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 C83E43A6824 for ; Tue, 24 Jun 2008 06:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[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 WrbMm2pWATOz for ; Tue, 24 Jun 2008 06:22:41 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id F1A1A3A6808 for ; Tue, 24 Jun 2008 06:22:40 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 14:22:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 14:22:29 +0100 Message-ID: In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0507DB168F@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 Thread-Index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaAACWf+ZAABIQssA== From: To: , X-OriginalArrivalTime: 24 Jun 2008 13:22:38.0517 (UTC) FILETIME=[5F778650:01C8D5FD] Subject: Re: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Tunnelling seems to be one of the areas we still need to do more work in... See inline Toby > -----Original Message----- > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > Sent: 24 June 2008 12:57 > To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org > Cc: steven.blake@ericsson.com > Subject: RE: [PCN] FW: New Version Notification > fordraft-moncaster-pcn-baseline-encoding-01 > > Hi > > I have one comment to section 4.3 > > o Any packets with the ECN field already marked as CE or ECT > > arriving at a PCN ingress node SHOULD be dropped or > alternatively > > MAY be tunnelled through the PCN-domain. They MUST NOT be > > admitted to the PCN-domain directly. > Sounds reasonable. One issue however that I don't understand is where > the decision to do tunneling is made. With my limited > knowledge about IP > tunneling I understand that PCN ingress determines that the > flow is ECT > or ECN-CE, then applies tunneling and signals to the PCN egress about > this. What protocols are defined for this (or is it outside > the scope of > the current charter?). Does tunneling of ECN enabled flows need a > separate section ? This is outside the scope of this document. Not sure if it is in scope for the charter. Mechanisms are needed to find the egress node anyway and setting up a tunnel is one solution to that (which also avoids the ECMP issue completely). > > > o On leaving the PCN-domain the ECN bits MUST be set to 00 (Not > > ECT). > If the tunneling approach (for ECT flows) is used, my understanding is > that the ECN bits should not be set to zero at PCN egress as these > contain ECN-CE and ECT already set before PCN ingress. > You would need to wite things carefully such that the PCN egress action is performed first (e.g. reset any marked packets to not-ECT). Then simply discard the outer header and keep the inner header unchanged. This would not be quite what is defined in any current tunnleing standard. Perhaps the solution to all this is for someone (not me!) to write a document about tunneling and PCN (there is some mention in the architecture document but that doesn't go into this level of detail). > Regards > Ingemar > > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of toby.moncaster@bt.com > > Sent: den 23 juni 2008 19:12 > > To: pcn@ietf.org > > Cc: steven.blake@ericsson.com > > Subject: [PCN] FW: New Version Notification > > fordraft-moncaster-pcn-baseline-encoding-01 > > > > > > Here is the latest revision to the baseline encoding > > document. Please let me have any suggested changes by July > > 8th to give me time to upload a further revision before Dublin. > > > > Do people think this is in any state yet to request it to be > > considered as a WG draft? > > > > Toby > > ____________________________________________________________________ > > Toby Moncaster, Networks Research > > Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > > 1473 648734 > > > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: 23 June 2008 18:09 > > To: Moncaster,T,Toby,CXR9 R > > Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de > > Subject: New Version Notification for > > draft-moncaster-pcn-baseline-encoding-01 > > > > > > A new version of I-D, > draft-moncaster-pcn-baseline-encoding-01.txt has > > been successfuly submitted by T Moncaster and posted to the IETF > > repository. > > > > Filename: draft-moncaster-pcn-baseline-encoding > > Revision: 01 > > Title: Baseline Encoding and Transport of > > Pre-Congestion > > Information > > Creation_date: 2008-06-23 > > WG ID: Independent Submission > > 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 > > rate 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. > > Another document describes an extended encoding scheme that allows > > for three 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 > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 24 06:36:43 2008 Return-Path: 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 A20693A6808; Tue, 24 Jun 2008 06:36:43 -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 C98C63A67AA for ; Tue, 24 Jun 2008 06:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[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 wsNZFi5C6KIR for ; Tue, 24 Jun 2008 06:36:41 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 88E803A6808 for ; Tue, 24 Jun 2008 06:36:36 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 14:36:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 14:36:26 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F86B@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 Thread-Index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaAACSHZwAABdR80A== From: To: , X-OriginalArrivalTime: 24 Jun 2008 13:36:35.0764 (UTC) FILETIME=[52814740:01C8D5FF] Subject: Re: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Perhaps this should actually say: Any packet with the ECN field already marked as CE or ECT arriving at a PCN ingress node SHOULD be dropped or downgraded to a lower class. Alternatively it MAY be tunnelled through the PCN-domain if mechanisms exist to preserve the mark at the PCN-egress node. A future document may describe such a mechanism but this is beyond the scope of this document. Such packets MUST NOT be admitted to the PCN-domain directly. There is currently a slight issue about what would happen when a packet is decapsulated if its outer header is set to not ECT and its inner header carries either ECT or CE. This is best addressed in a separate document (although it could go in as an appendix in this document initially). Toby > -----Original Message----- > From: Eardley,PL,Philip,CXR9 R > Sent: 24 June 2008 11:45 > To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org > Cc: steven.blake@ericsson.com > Subject: RE: [PCN] FW: New Version Notification > fordraft-moncaster-pcn-baseline-encoding-01 > > Toby, all, > > Quick comment: in section 4.3 : > > PCN edge node behaviour compliant with the PCN baseline encoding: > > o Any packets with the ECN field already marked as CE or ECT > arriving at a PCN ingress node SHOULD be dropped or > alternatively > MAY be tunnelled through the PCN-domain. They MUST NOT be > admitted to the PCN-domain directly. > > - downgrading also seems possible, ie setting DS codepoint to > a lower behaviour aggregate like best effort or assured forwarding > - suggest "SHOULD be dropped or downgraded" - not clear to me > that one is particularly preferable to the other > - agree with MAY tunnel - basically because it needs extra > signalling work > > would be very interested in comments on this. currently am > re-writing the traffic conditioning section of > draft-eardley-marking-behaviour. This has a similar choice > about what to do to out-of-profile traffic. My current idea > is simply to list the different possible actions that you > "may" take - ie follow the approach of RFC2475 (Diffserv architecture) > > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > { toby.moncaster@bt.com > { Sent: 23 June 2008 18:12 > { To: pcn@ietf.org > { Cc: steven.blake@ericsson.com > { Subject: [PCN] FW: New Version Notification fordraft-moncaster-pcn- > { baseline-encoding-01 > { > { > { Here is the latest revision to the baseline encoding > document. Please > { let me have any suggested changes by July 8th to give me > time to upload > { a further revision before Dublin. > { > { Do people think this is in any state yet to request it to > be considered > { as a WG draft? > { > { Toby > { ____________________________________________________________________ > { Toby Moncaster, Networks Research Centre, BT > { B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > { > { > { -----Original Message----- > { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > { Sent: 23 June 2008 18:09 > { To: Moncaster,T,Toby,CXR9 R > { Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de > { Subject: New Version Notification for > { draft-moncaster-pcn-baseline-encoding-01 > { > { > { A new version of I-D, > draft-moncaster-pcn-baseline-encoding-01.txt has > { been successfuly submitted by T Moncaster and posted to the IETF > { repository. > { > { Filename: draft-moncaster-pcn-baseline-encoding > { Revision: 01 > { Title: Baseline Encoding and Transport of > Pre-Congestion > { Information > { Creation_date: 2008-06-23 > { WG ID: Independent Submission > { 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 > { rate 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. > { Another document describes an extended encoding scheme that allows > { for three 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 > { PCN@ietf.org > { https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 24 06:48:51 2008 Return-Path: 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 CD3B43A69B2; Tue, 24 Jun 2008 06:48:51 -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 4F04F3A699F for ; Tue, 24 Jun 2008 06:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[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 kC6Z+RMDAkSe for ; Tue, 24 Jun 2008 06:48:45 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 868E43A69E9 for ; Tue, 24 Jun 2008 06:48:44 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 14:48:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jun 2008 14:48:44 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F86E@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 Thread-Index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaAACSHZwAABdR80AAA3aRw From: To: , X-OriginalArrivalTime: 24 Jun 2008 13:48:44.0877 (UTC) FILETIME=[051717D0:01C8D601] Subject: Re: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Your wording sounds ok to me. Another place to mention the 'slight issue' might be the architecture draft, as that already has a section that discusses tunnelling (hopefully quite carefully!) phil { -----Original Message----- { From: Moncaster,T,Toby,CXR9 R { Sent: 24 June 2008 14:36 { To: Eardley,PL,Philip,CXR9 R; 'pcn@ietf.org' { Subject: RE: [PCN] FW: New Version Notification fordraft-moncaster-pcn- { baseline-encoding-01 { { { Perhaps this should actually say: { { Any packet with the ECN field already marked as CE or ECT arriving at a { PCN ingress node SHOULD be dropped or downgraded to a lower class. { Alternatively it MAY be tunnelled through the PCN-domain if mechanisms { exist to preserve the mark at the PCN-egress node. A future document may { describe such a mechanism but this is beyond the scope of this document. { Such packets MUST NOT be admitted to the PCN-domain directly. { { There is currently a slight issue about what would happen when a packet is { decapsulated if its outer header is set to not ECT and its inner header { carries either ECT or CE. This is best addressed in a separate document { (although it could go in as an appendix in this document initially). { { Toby { { > -----Original Message----- { > From: Eardley,PL,Philip,CXR9 R { > Sent: 24 June 2008 11:45 { > To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org { > Cc: steven.blake@ericsson.com { > Subject: RE: [PCN] FW: New Version Notification { > fordraft-moncaster-pcn-baseline-encoding-01 { > { > Toby, all, { > { > Quick comment: in section 4.3 : { > { > PCN edge node behaviour compliant with the PCN baseline encoding: { > { > o Any packets with the ECN field already marked as CE or ECT { > arriving at a PCN ingress node SHOULD be dropped or { > alternatively { > MAY be tunnelled through the PCN-domain. They MUST NOT be { > admitted to the PCN-domain directly. { > { > - downgrading also seems possible, ie setting DS codepoint to { > a lower behaviour aggregate like best effort or assured forwarding { > - suggest "SHOULD be dropped or downgraded" - not clear to me { > that one is particularly preferable to the other { > - agree with MAY tunnel - basically because it needs extra { > signalling work { > { > would be very interested in comments on this. currently am { > re-writing the traffic conditioning section of { > draft-eardley-marking-behaviour. This has a similar choice { > about what to do to out-of-profile traffic. My current idea { > is simply to list the different possible actions that you { > "may" take - ie follow the approach of RFC2475 (Diffserv architecture) { > { > phil { > { > { -----Original Message----- { > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On { > Behalf Of { > { toby.moncaster@bt.com { > { Sent: 23 June 2008 18:12 { > { To: pcn@ietf.org { > { Cc: steven.blake@ericsson.com { > { Subject: [PCN] FW: New Version Notification fordraft-moncaster-pcn- { > { baseline-encoding-01 { > { { > { { > { Here is the latest revision to the baseline encoding { > document. Please { > { let me have any suggested changes by July 8th to give me { > time to upload { > { a further revision before Dublin. { > { { > { Do people think this is in any state yet to request it to { > be considered { > { as a WG draft? { > { { > { Toby { > { ____________________________________________________________________ { > { Toby Moncaster, Networks Research Centre, BT { > { B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 { > { { > { { > { -----Original Message----- { > { From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] { > { Sent: 23 June 2008 18:09 { > { To: Moncaster,T,Toby,CXR9 R { > { Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de { > { Subject: New Version Notification for { > { draft-moncaster-pcn-baseline-encoding-01 { > { { > { { > { A new version of I-D, { > draft-moncaster-pcn-baseline-encoding-01.txt has { > { been successfuly submitted by T Moncaster and posted to the IETF { > { repository. { > { { > { Filename: draft-moncaster-pcn-baseline-encoding { > { Revision: 01 { > { Title: Baseline Encoding and Transport of { > Pre-Congestion { > { Information { > { Creation_date: 2008-06-23 { > { WG ID: Independent Submission { > { 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 { > { rate 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. { > { Another document describes an extended encoding scheme that allows { > { for three 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 { > { PCN@ietf.org { > { https://www.ietf.org/mailman/listinfo/pcn { > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jun 25 01:43:57 2008 Return-Path: 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 E03ED28C0D8; Wed, 25 Jun 2008 01:43:57 -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 E624128C0D8 for ; Wed, 25 Jun 2008 01:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] 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 ZFBRCKW8wF+e for ; Wed, 25 Jun 2008 01:43:54 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5367C3A69E9 for ; Wed, 25 Jun 2008 01:43:54 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 15FBA209BE; Wed, 25 Jun 2008 10:43:55 +0200 (CEST) X-AuditID: c1b4fb3c-af09dbb00000193b-d4-4862054ac190 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DB78B2084F; Wed, 25 Jun 2008 10:43:54 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 10:44:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 10:44:22 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0507DB1F5C@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 thread-index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaAACWf+ZAABIQssAAogadA References: <026F8EEDAD2C4342A993203088C1FC0507DB168F@esealmw109.eemea.ericsson.se> From: "Ingemar Johansson S" To: , X-OriginalArrivalTime: 25 Jun 2008 08:44:22.0429 (UTC) FILETIME=[AA3C6CD0:01C8D69F] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PCN] FW: New Version Notification fordraft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi I believe quite some uncertanity is related to how these ECN bits are treated at PCN ingress and how tunneling would solve this, esp. in the light of the discussion around tunneling constraints mentioned in Appendix A in http://tools.ietf.org/id/draft-moncaster-pcn-3-state-encoding-00.txt It would be good to know if the e2e ECN issue can actually be solved in a good way using tunneling and if so how it could be done. Question is probably, who will do the dirty job.. Regards /Ingemar > -----Original Message----- > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > Sent: den 24 juni 2008 15:22 > To: Ingemar Johansson S; pcn@ietf.org > Subject: RE: [PCN] FW: New Version Notification > fordraft-moncaster-pcn-baseline-encoding-01 > > > Tunnelling seems to be one of the areas we still need to do > more work in... See inline > > Toby > > > -----Original Message----- > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] > > Sent: 24 June 2008 12:57 > > To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org > > Cc: steven.blake@ericsson.com > > Subject: RE: [PCN] FW: New Version Notification > > fordraft-moncaster-pcn-baseline-encoding-01 > > > > Hi > > > > I have one comment to section 4.3 > > > o Any packets with the ECN field already marked as CE or ECT > > > arriving at a PCN ingress node SHOULD be dropped or > > alternatively > > > MAY be tunnelled through the PCN-domain. They MUST NOT be > > > admitted to the PCN-domain directly. > > Sounds reasonable. One issue however that I don't > understand is where > > the decision to do tunneling is made. With my limited > knowledge about > > IP tunneling I understand that PCN ingress determines that > the flow is > > ECT or ECN-CE, then applies tunneling and signals to the PCN egress > > about this. What protocols are defined for this (or is it > outside the > > scope of the current charter?). Does tunneling of ECN enabled flows > > need a separate section ? > > This is outside the scope of this document. Not sure if it is > in scope for the charter. Mechanisms are needed to find the > egress node anyway and setting up a tunnel is one solution to > that (which also avoids the ECMP issue completely). > > > > > > o On leaving the PCN-domain the ECN bits MUST be set to 00 (Not > > > ECT). > > If the tunneling approach (for ECT flows) is used, my > understanding is > > that the ECN bits should not be set to zero at PCN egress as these > > contain ECN-CE and ECT already set before PCN ingress. > > > > You would need to wite things carefully such that the PCN > egress action is performed first (e.g. reset any marked > packets to not-ECT). Then simply discard the outer header and > keep the inner header unchanged. > This would not be quite what is defined in any current > tunnleing standard. Perhaps the solution to all this is for > someone (not me!) to write a document about tunneling and PCN > (there is some mention in the architecture document but that > doesn't go into this level of detail). > > > Regards > > Ingemar > > > > > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf > > > Of toby.moncaster@bt.com > > > Sent: den 23 juni 2008 19:12 > > > To: pcn@ietf.org > > > Cc: steven.blake@ericsson.com > > > Subject: [PCN] FW: New Version Notification > > > fordraft-moncaster-pcn-baseline-encoding-01 > > > > > > > > > Here is the latest revision to the baseline encoding document. > > > Please let me have any suggested changes by July 8th to > give me time > > > to upload a further revision before Dublin. > > > > > > Do people think this is in any state yet to request it to be > > > considered as a WG draft? > > > > > > Toby > > > > ____________________________________________________________________ > > > Toby Moncaster, Networks Research > Centre, BT > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > > > 1473 648734 > > > > > > > > > -----Original Message----- > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > Sent: 23 June 2008 18:09 > > > To: Moncaster,T,Toby,CXR9 R > > > Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de > > > Subject: New Version Notification for > > > draft-moncaster-pcn-baseline-encoding-01 > > > > > > > > > A new version of I-D, > > draft-moncaster-pcn-baseline-encoding-01.txt has > > > been successfuly submitted by T Moncaster and posted to the IETF > > > repository. > > > > > > Filename: draft-moncaster-pcn-baseline-encoding > > > Revision: 01 > > > Title: Baseline Encoding and Transport of > > > Pre-Congestion > > > Information > > > Creation_date: 2008-06-23 > > > WG ID: Independent Submission > > > 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 > > > rate 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. > > > Another document describes an extended encoding scheme > that allows > > > for three 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 > > > PCN@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcn > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jun 25 01:52:19 2008 Return-Path: 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 798D028C0E1; Wed, 25 Jun 2008 01:52:19 -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 D4C9728C0E1 for ; Wed, 25 Jun 2008 01:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[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 tsPH6pkeWLau for ; Wed, 25 Jun 2008 01:52:17 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 5FE823A69C7 for ; Wed, 25 Jun 2008 01:52:17 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 09:52:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 09:52:17 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F877@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0507DB1F5C@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notificationfordraft-moncaster-pcn-baseline-encoding-01 Thread-Index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaAACWf+ZAABIQssAAogadAAABUtYA= From: To: , , X-OriginalArrivalTime: 25 Jun 2008 08:52:18.0193 (UTC) FILETIME=[C5D04010:01C8D6A0] Subject: Re: [PCN] FW: New Version Notificationfordraft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi I think toby, Michael, bob have worked well through the non-tunnelling case for ecn/pcn. where the work is more limited is the tunnelling case (we know how the solution might look, but the details eg of the signalling are unknown). My feeling is that we should concentrate on finishing properly the non-tunnelled case - get one thing done before trying to do another. phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Ingemar Johansson S { Sent: 25 June 2008 09:44 { To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org { Subject: Re: [PCN] FW: New Version Notificationfordraft-moncaster-pcn- { baseline-encoding-01 { { Hi { { I believe quite some uncertanity is related to how these ECN bits are { treated at PCN ingress and how tunneling would solve this, esp. in the { light of the discussion around tunneling constraints mentioned in { Appendix A in { http://tools.ietf.org/id/draft-moncaster-pcn-3-state-encoding-00.txt { It would be good to know if the e2e ECN issue can actually be solved in { a good way using tunneling and if so how it could be done. Question is { probably, who will do the dirty job.. { { Regards { /Ingemar { { > -----Original Message----- { > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] { > Sent: den 24 juni 2008 15:22 { > To: Ingemar Johansson S; pcn@ietf.org { > Subject: RE: [PCN] FW: New Version Notification { > fordraft-moncaster-pcn-baseline-encoding-01 { > { > { > Tunnelling seems to be one of the areas we still need to do { > more work in... See inline { > { > Toby { > { > > -----Original Message----- { > > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] { > > Sent: 24 June 2008 12:57 { > > To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org { > > Cc: steven.blake@ericsson.com { > > Subject: RE: [PCN] FW: New Version Notification { > > fordraft-moncaster-pcn-baseline-encoding-01 { > > { > > Hi { > > { > > I have one comment to section 4.3 { > > > o Any packets with the ECN field already marked as CE or ECT { > > > arriving at a PCN ingress node SHOULD be dropped or { > > alternatively { > > > MAY be tunnelled through the PCN-domain. They MUST NOT be { > > > admitted to the PCN-domain directly. { > > Sounds reasonable. One issue however that I don't { > understand is where { > > the decision to do tunneling is made. With my limited { > knowledge about { > > IP tunneling I understand that PCN ingress determines that { > the flow is { > > ECT or ECN-CE, then applies tunneling and signals to the PCN egress { > > about this. What protocols are defined for this (or is it { > outside the { > > scope of the current charter?). Does tunneling of ECN enabled flows { > > need a separate section ? { > { > This is outside the scope of this document. Not sure if it is { > in scope for the charter. Mechanisms are needed to find the { > egress node anyway and setting up a tunnel is one solution to { > that (which also avoids the ECMP issue completely). { > { > > { > > > o On leaving the PCN-domain the ECN bits MUST be set to 00 (Not { > > > ECT). { > > If the tunneling approach (for ECT flows) is used, my { > understanding is { > > that the ECN bits should not be set to zero at PCN egress as these { > > contain ECN-CE and ECT already set before PCN ingress. { > > { > { > You would need to wite things carefully such that the PCN { > egress action is performed first (e.g. reset any marked { > packets to not-ECT). Then simply discard the outer header and { > keep the inner header unchanged. { > This would not be quite what is defined in any current { > tunnleing standard. Perhaps the solution to all this is for { > someone (not me!) to write a document about tunneling and PCN { > (there is some mention in the architecture document but that { > doesn't go into this level of detail). { > { > > Regards { > > Ingemar { > > { > > { > > { > > > -----Original Message----- { > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] { > On Behalf { > > > Of toby.moncaster@bt.com { > > > Sent: den 23 juni 2008 19:12 { > > > To: pcn@ietf.org { > > > Cc: steven.blake@ericsson.com { > > > Subject: [PCN] FW: New Version Notification { > > > fordraft-moncaster-pcn-baseline-encoding-01 { > > > { > > > { > > > Here is the latest revision to the baseline encoding document. { > > > Please let me have any suggested changes by July 8th to { > give me time { > > > to upload a further revision before Dublin. { > > > { > > > Do people think this is in any state yet to request it to be { > > > considered as a WG draft? { > > > { > > > Toby { > > > { > ____________________________________________________________________ { > > > Toby Moncaster, Networks Research { > Centre, BT { > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 { > > > 1473 648734 { > > > { > > > { > > > -----Original Message----- { > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] { > > > Sent: 23 June 2008 18:09 { > > > To: Moncaster,T,Toby,CXR9 R { > > > Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de { > > > Subject: New Version Notification for { > > > draft-moncaster-pcn-baseline-encoding-01 { > > > { > > > { > > > A new version of I-D, { > > draft-moncaster-pcn-baseline-encoding-01.txt has { > > > been successfuly submitted by T Moncaster and posted to the IETF { > > > repository. { > > > { > > > Filename: draft-moncaster-pcn-baseline-encoding { > > > Revision: 01 { > > > Title: Baseline Encoding and Transport of { > > > Pre-Congestion { > > > Information { > > > Creation_date: 2008-06-23 { > > > WG ID: Independent Submission { > > > 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 { > > > rate 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. { > > > Another document describes an extended encoding scheme { > that allows { > > > for three 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 { > > > PCN@ietf.org { > > > https://www.ietf.org/mailman/listinfo/pcn { > > > { > > { > { _______________________________________________ { 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 From pcn-bounces@ietf.org Wed Jun 25 02:07:19 2008 Return-Path: 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 2F5EB3A69C7; Wed, 25 Jun 2008 02:07:19 -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 6B3D73A694D for ; Wed, 25 Jun 2008 02:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[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 XGiX7XvsCKFM for ; Wed, 25 Jun 2008 02:07:17 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id CE9773A6860 for ; Wed, 25 Jun 2008 02:07:16 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jun 2008 10:07:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 10:07:09 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F877@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notificationfordraft-moncaster-pcn-baseline-encoding-01 Thread-Index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaAACWf+ZAABIQssAAogadAAABUtYAAALA+sA== From: To: , , X-OriginalArrivalTime: 25 Jun 2008 09:07:18.0097 (UTC) FILETIME=[DE32B410:01C8D6A2] Subject: Re: [PCN] FW: New Version Notificationfordraft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, Definitely agree with Phil here. Would love to volunteer to try and sort this out but am unlikely to have enough time. I know Bob wants to do some work on trying to rationalise all the different tunnel behaviours and how they treat the DSCP and ECN fields on encapsulation and on decapsulation so perhaps he's the one for this job... Toby > -----Original Message----- > From: Eardley,PL,Philip,CXR9 R > Sent: 25 June 2008 09:52 > To: 'Ingemar Johansson S'; Moncaster,T,Toby,CXR9 R; pcn@ietf.org > Subject: RE: [PCN] FW: New Version > Notificationfordraft-moncaster-pcn-baseline-encoding-01 > > Hi > > I think toby, Michael, bob have worked well through the > non-tunnelling case for ecn/pcn. where the work is more > limited is the tunnelling case (we know how the solution > might look, but the details eg of the signalling are > unknown). My feeling is that we should concentrate on > finishing properly the non-tunnelled case - get one thing > done before trying to do another. > > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > { Ingemar Johansson S > { Sent: 25 June 2008 09:44 > { To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org > { Subject: Re: [PCN] FW: New Version > Notificationfordraft-moncaster-pcn- > { baseline-encoding-01 > { > { Hi > { > { I believe quite some uncertanity is related to how these > ECN bits are > { treated at PCN ingress and how tunneling would solve this, > esp. in the > { light of the discussion around tunneling constraints mentioned in > { Appendix A in > { http://tools.ietf.org/id/draft-moncaster-pcn-3-state-encoding-00.txt > { It would be good to know if the e2e ECN issue can actually > be solved in > { a good way using tunneling and if so how it could be done. > Question is > { probably, who will do the dirty job.. > { > { Regards > { /Ingemar > { > { > -----Original Message----- > { > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > { > Sent: den 24 juni 2008 15:22 > { > To: Ingemar Johansson S; pcn@ietf.org > { > Subject: RE: [PCN] FW: New Version Notification > { > fordraft-moncaster-pcn-baseline-encoding-01 > { > > { > > { > Tunnelling seems to be one of the areas we still need to do > { > more work in... See inline > { > > { > Toby > { > > { > > -----Original Message----- > { > > From: Ingemar Johansson S > [mailto:ingemar.s.johansson@ericsson.com] > { > > Sent: 24 June 2008 12:57 > { > > To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org > { > > Cc: steven.blake@ericsson.com > { > > Subject: RE: [PCN] FW: New Version Notification > { > > fordraft-moncaster-pcn-baseline-encoding-01 > { > > > { > > Hi > { > > > { > > I have one comment to section 4.3 > { > > > o Any packets with the ECN field already marked as > CE or ECT > { > > > arriving at a PCN ingress node SHOULD be dropped or > { > > alternatively > { > > > MAY be tunnelled through the PCN-domain. They > MUST NOT be > { > > > admitted to the PCN-domain directly. > { > > Sounds reasonable. One issue however that I don't > { > understand is where > { > > the decision to do tunneling is made. With my limited > { > knowledge about > { > > IP tunneling I understand that PCN ingress determines that > { > the flow is > { > > ECT or ECN-CE, then applies tunneling and signals to > the PCN egress > { > > about this. What protocols are defined for this (or is it > { > outside the > { > > scope of the current charter?). Does tunneling of ECN > enabled flows > { > > need a separate section ? > { > > { > This is outside the scope of this document. Not sure if it is > { > in scope for the charter. Mechanisms are needed to find the > { > egress node anyway and setting up a tunnel is one solution to > { > that (which also avoids the ECMP issue completely). > { > > { > > > { > > > o On leaving the PCN-domain the ECN bits MUST be > set to 00 (Not > { > > > ECT). > { > > If the tunneling approach (for ECT flows) is used, my > { > understanding is > { > > that the ECN bits should not be set to zero at PCN > egress as these > { > > contain ECN-CE and ECT already set before PCN ingress. > { > > > { > > { > You would need to wite things carefully such that the PCN > { > egress action is performed first (e.g. reset any marked > { > packets to not-ECT). Then simply discard the outer header and > { > keep the inner header unchanged. > { > This would not be quite what is defined in any current > { > tunnleing standard. Perhaps the solution to all this is for > { > someone (not me!) to write a document about tunneling and PCN > { > (there is some mention in the architecture document but that > { > doesn't go into this level of detail). > { > > { > > Regards > { > > Ingemar > { > > > { > > > { > > > { > > > -----Original Message----- > { > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > { > On Behalf > { > > > Of toby.moncaster@bt.com > { > > > Sent: den 23 juni 2008 19:12 > { > > > To: pcn@ietf.org > { > > > Cc: steven.blake@ericsson.com > { > > > Subject: [PCN] FW: New Version Notification > { > > > fordraft-moncaster-pcn-baseline-encoding-01 > { > > > > { > > > > { > > > Here is the latest revision to the baseline encoding document. > { > > > Please let me have any suggested changes by July 8th to > { > give me time > { > > > to upload a further revision before Dublin. > { > > > > { > > > Do people think this is in any state yet to request it to be > { > > > considered as a WG draft? > { > > > > { > > > Toby > { > > > > { > > ____________________________________________________________________ > { > > > Toby Moncaster, Networks Research > { > Centre, BT > { > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > { > > > 1473 648734 > { > > > > { > > > > { > > > -----Original Message----- > { > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > { > > > Sent: 23 June 2008 18:09 > { > > > To: Moncaster,T,Toby,CXR9 R > { > > > Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de > { > > > Subject: New Version Notification for > { > > > draft-moncaster-pcn-baseline-encoding-01 > { > > > > { > > > > { > > > A new version of I-D, > { > > draft-moncaster-pcn-baseline-encoding-01.txt has > { > > > been successfuly submitted by T Moncaster and posted > to the IETF > { > > > repository. > { > > > > { > > > Filename: draft-moncaster-pcn-baseline-encoding > { > > > Revision: 01 > { > > > Title: Baseline Encoding and Transport of > { > > > Pre-Congestion > { > > > Information > { > > > Creation_date: 2008-06-23 > { > > > WG ID: Independent Submission > { > > > 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 > { > > > rate 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. > { > > > Another document describes an extended encoding scheme > { > that allows > { > > > for three 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 > { > > > PCN@ietf.org > { > > > https://www.ietf.org/mailman/listinfo/pcn > { > > > > { > > > { > > { _______________________________________________ > { 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 From pcn-bounces@ietf.org Wed Jun 25 02:20:55 2008 Return-Path: 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 1F7413A6893; Wed, 25 Jun 2008 02:20:55 -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 8632B3A6859 for ; Wed, 25 Jun 2008 02:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Ey2d10bzPmCw for ; Wed, 25 Jun 2008 02:20:52 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id CD7D43A6843 for ; Wed, 25 Jun 2008 02:20:51 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Wed, 25 Jun 2008 11:20:52 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 11:20:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 25 Jun 2008 11:20:43 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C4C169E@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New VersionNotificationfordraft-moncaster-pcn-baseline-encoding-01 Thread-Index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaAACWf+ZAABIQssAAogadAAABUtYAAALA+sAAAddqw References: <4A916DBC72536E419A0BD955EDECEDEC0329F877@E03MVB1-UKBR.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 25 Jun 2008 09:20:44.0262 (UTC) FILETIME=[BEB5B860:01C8D6A4] Cc: pcn@ietf.org Subject: Re: [PCN] FW: New VersionNotificationfordraft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Ingemar, | Definitely agree with Phil here. I too agree with Phil on this issue. Regards, Rudiger | > -----Original Message----- | > From: Eardley,PL,Philip,CXR9 R | > Sent: 25 June 2008 09:52 | > To: 'Ingemar Johansson S'; Moncaster,T,Toby,CXR9 R; pcn@ietf.org | > Subject: RE: [PCN] FW: New Version | > Notificationfordraft-moncaster-pcn-baseline-encoding-01 | > | > Hi | > | > I think toby, Michael, bob have worked well through the non-tunnelling | > case for ecn/pcn. where the work is more limited is the tunnelling | > case (we know how the solution might look, but the details eg of the | > signalling are unknown). My feeling is that we should concentrate on | > finishing properly the non-tunnelled case - get one thing done before | > trying to do another. | > | > phil | > | > { -----Original Message----- | > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] | On Behalf | > Of { Ingemar Johansson S { Sent: 25 June 2008 09:44 { To: | > Moncaster,T,Toby,CXR9 R; pcn@ietf.org { Subject: Re: [PCN] FW: New | > Version | > Notificationfordraft-moncaster-pcn- | > { baseline-encoding-01 | > { | > { Hi | > { | > { I believe quite some uncertanity is related to how these ECN bits | > are { treated at PCN ingress and how tunneling would solve | this, esp. | > in the { light of the discussion around tunneling constraints | > mentioned in { Appendix A in { | > http://tools.ietf.org/id/draft-moncaster-pcn-3-state-encoding-00.txt | > { It would be good to know if the e2e ECN issue can | actually be solved | > in { a good way using tunneling and if so how it could be done. | > Question is | > { probably, who will do the dirty job.. | > { | > { Regards | > { /Ingemar | > { | > { > -----Original Message----- | > { > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] { > | > Sent: den 24 juni 2008 15:22 { > To: Ingemar Johansson S; | pcn@ietf.org | > { > Subject: RE: [PCN] FW: New Version Notification { > | > fordraft-moncaster-pcn-baseline-encoding-01 | > { > | > { > | > { > Tunnelling seems to be one of the areas we still need to do { > | > more work in... See inline { > { > Toby { > { > > -----Original | > Message----- { > > From: Ingemar Johansson S | > [mailto:ingemar.s.johansson@ericsson.com] | > { > > Sent: 24 June 2008 12:57 | > { > > To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org { > > Cc: | > steven.blake@ericsson.com { > > Subject: RE: [PCN] FW: New Version | > Notification { > > fordraft-moncaster-pcn-baseline-encoding-01 | > { > > | > { > > Hi | > { > > | > { > > I have one comment to section 4.3 | > { > > > o Any packets with the ECN field already marked as | > CE or ECT | > { > > > arriving at a PCN ingress node SHOULD be dropped or | > { > > alternatively | > { > > > MAY be tunnelled through the PCN-domain. They | > MUST NOT be | > { > > > admitted to the PCN-domain directly. | > { > > Sounds reasonable. One issue however that I don't { > | understand | > is where { > > the decision to do tunneling is made. With | my limited { | > > knowledge about { > > IP tunneling I understand that PCN ingress | > determines that { > the flow is { > > ECT or ECN-CE, then applies | > tunneling and signals to the PCN egress { > > about this. What | > protocols are defined for this (or is it { > outside the { | > > scope | > of the current charter?). Does tunneling of ECN enabled flows { > > | > need a separate section ? | > { > | > { > This is outside the scope of this document. Not sure if | it is { > | > in scope for the charter. Mechanisms are needed to find the | { > egress | > node anyway and setting up a tunnel is one solution to { > | that (which | > also avoids the ECMP issue completely). | > { > | > { > > | > { > > > o On leaving the PCN-domain the ECN bits MUST be | > set to 00 (Not | > { > > > ECT). | > { > > If the tunneling approach (for ECT flows) is used, my { > | > understanding is { > > that the ECN bits should not be set | to zero at | > PCN egress as these { > > contain ECN-CE and ECT already set before | > PCN ingress. | > { > > | > { > | > { > You would need to wite things carefully such that the PCN { > | > egress action is performed first (e.g. reset any marked { > | packets to | > not-ECT). Then simply discard the outer header and { > keep | the inner | > header unchanged. | > { > This would not be quite what is defined in any current { > | > tunnleing standard. Perhaps the solution to all this is for { > | > someone (not me!) to write a document about tunneling and PCN { > | > (there is some mention in the architecture document but that { > | > doesn't go into this level of detail). | > { > | > { > > Regards | > { > > Ingemar | > { > > | > { > > | > { > > | > { > > > -----Original Message----- | > { > > > From: pcn-bounces@ietf.org | [mailto:pcn-bounces@ietf.org] { > | > On Behalf { > > > Of toby.moncaster@bt.com { > > > Sent: | den 23 juni | > 2008 19:12 { > > > To: pcn@ietf.org { > > > Cc: | > steven.blake@ericsson.com { > > > Subject: [PCN] FW: New Version | > Notification { > > > fordraft-moncaster-pcn-baseline-encoding-01 | > { > > > | > { > > > | > { > > > Here is the latest revision to the baseline | encoding document. | > { > > > Please let me have any suggested changes by July 8th to { > | > give me time { > > > to upload a further revision before Dublin. | > { > > > | > { > > > Do people think this is in any state yet to request | it to be { | > > > > considered as a WG draft? | > { > > > | > { > > > Toby | > { > > > | > { > | > ____________________________________________________________________ | > { > > > Toby Moncaster, Networks | Research { > | > Centre, BT { > > > B54/70 Adastral Park, Ipswich, IP53RE, | UK. +44 { > | > > > 1473 648734 { > > > { > > > { > > > -----Original | Message----- { > | > > > From: IETF I-D Submission Tool | [mailto:idsubmission@ietf.org] { > | > > > Sent: 23 June 2008 18:09 { > > > To: | Moncaster,T,Toby,CXR9 R { > > | > > Cc: Briscoe,RJ,Bob,CXR9 R; | menth@informatik.uni-wuerzburg.de { > > > | > Subject: New Version Notification for { > > > | > draft-moncaster-pcn-baseline-encoding-01 | > { > > > | > { > > > | > { > > > A new version of I-D, | > { > > draft-moncaster-pcn-baseline-encoding-01.txt has { > > > been | > successfuly submitted by T Moncaster and posted to the IETF { > > > | > repository. | > { > > > | > { > > > Filename: draft-moncaster-pcn-baseline-encoding | > { > > > Revision: 01 | > { > > > Title: Baseline Encoding and Transport of | > { > > > Pre-Congestion | > { > > > Information | > { > > > Creation_date: 2008-06-23 | > { > > > WG ID: Independent Submission | > { > > > 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 { > > > rate 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. | > { > > > Another document describes an extended encoding scheme { > | > that allows { > > > for three 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 | > { > > > PCN@ietf.org | > { > > > https://www.ietf.org/mailman/listinfo/pcn | > { > > > | > { > > | > { > | > { _______________________________________________ | > { 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 | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jun 25 08:34:02 2008 Return-Path: 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 AADA13A6961; Wed, 25 Jun 2008 08:34:02 -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 17C783A68B7 for ; Wed, 25 Jun 2008 08:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, STOX_REPLY_TYPE=0.001] 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 mWqmhPX93T6d for ; Wed, 25 Jun 2008 08:33:57 -0700 (PDT) Received: from smtp-6-97.vip.sina.com (smtp.vip.sina.com [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id 127F43A6A6D for ; Wed, 25 Jun 2008 08:33:53 -0700 (PDT) Received: from ibmPC (unknown [211.160.21.17]) by smtp-6-97.vip.sina.com (SINAMAIL) with ESMTP id 937821DDD01; Wed, 25 Jun 2008 23:33:54 +0800 (CST) Message-ID: <7DF1FC27CFF543D8A12DB877C9E26130@ibmPC> From: "Wei Gengyu" To: "Geib, Ruediger" References: <4A916DBC72536E419A0BD955EDECEDEC0329F82B@E03MVB1-UKBR.domain1.systemhost.net> <5351E79284D944639901EDC11D6E9676@ibmPC> <1B6169C658325341A3B8066E23919E1C0164B207@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C4C168E@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C4C168E@S4DE8PSAANK.mitte.t-com.de> Date: Wed, 25 Jun 2008 23:31:30 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Ruediger, Thank you for you reply. If one DS domain definition is from RFC 2475, the following word should be noticced too in this RFC2475. This could help us to clarify what is within a singl DS domain or within an inter-domains. "2.1 Differentiated Services Domain A DS domain normally consists of one or more networks under the same administration; for example, an organization's intranet or an ISP. The administration of the domain is responsible for ensuring that adequate resources are provisioned and/or reserved to support the SLAs offered by the domain. " And there is no decription about constrains to DSCP when IP over ethernet, ATM or MPLS. Or you can have the same coding scheme in the networks by RFC2475. While in the I-D "draft-chan-pcn-encoding-comparison-03", considerations of encoding are listed, but "Section 4. Encoding Recommendations" is blank. Each encoding scheme is not clearly specific to a certain network technology underneath IP. The sematics of DSCP are just as the network layer issues, is it right? Regards, Gengyu ----- Original Message ----- From: "Geib, Ruediger" To: Cc: Sent: Tuesday, June 24, 2008 7:40 PM Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 Gengyu | But, What is is a DS domain? | I do not know where the definition of a DS domain is from. | Perhaps, all connected equipements capable of DiffServ | marking form a DS domain. Right? See RFC 2475 DS domain a DS-capable domain; a contiguous set of nodes which operate with a common set of service provisioning policies and PHB definitions. | Then consider a compus network that includes Ethernet, ATM, | MPLS equipements. | The compus network is owned and operated by the university. | | My questions are | 1) is the campus network a single DS domain? Yes, presumably (unless each faculty runs an own network). | 2) are there both three state coding and two state coding | existed if adopting PCN? I don't think so. What would be the benefit of that as compared to the cost? If operation and planning of such a network is just simple, such a solution may be worth thinking about. But I doubt that it is simple. Regards, Rudiger | | Regards, | | Gengyu | | | ----- Original Message ----- | From: "Geib, Ruediger" | To: | Cc: ; | Sent: Friday, June 20, 2008 10:37 PM | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | Gengyu, | | the two state issue may specifically be relevant for carriers | working with | MPLS. Inter carrier MPLS services are possible, but still I | doubt that there | are many carriers operating MPLS with three PCN states if | there are just 8 | DiffServ states all in all. | | What you address would then be an interdomain case of one | carrier operating | three states on IP whose network is connected to another | carrier operating a | two state network. That's an issue, but interdomain scenarios | are out of | scope for the time being (Phil mentioned that already). | | A carrier operating with two state routers in parallel with | three state | routers - like running IP three state and MPLS two state - | well, I'm not | sure whether that makes any sense, I'd have to think about | that. But to be | honest, it looks as if it makes the solution more complex and | that's exactly | what I try to avoid, unless I can see a clear benefit for the | more complex | solution. What does a carrier gain if some of his routers | work with three | PCN states while others work with two states? | | Please also consider RFC5129 with regards to MPLS behaviour. I wonder | whether IETF will accept different remarking schemes during | the ultimate | label popping than described there any time soon. | | Regards, | | Rudiger | | | | -----Original Message----- | | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | | Behalf Of Wei Gengyu | | Sent: Thursday, June 19, 2008 7:05 PM | | To: philip.eardley@bt.com | | Cc: pcn@ietf.org | | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | Phil, | | | | I am not in Dublin, but I like to drink red tea while | | disscussing the technical issues with my collegues. | | The network we often concern is the network that covers an | | area greater than an island. | | | | Consider the case, a university with serveral campus located | | at different cities, it is one unversity network of a | | collection of campus networks. | | Or the network of an enterprises with serveral branches | | located in different states is one network. | | Those are truely existed networks nowadays. | | | | And having experiences as a network administor will be | | helpful to decide how to configure a network and to | | understand the problem of coding schemes. | | | | In your email you described the problem and the node | behavior clearly. | | I do think that the problems must be solved. | | | | In my opinion,the problems are due to the semantics of | | 2-state and 3-state coding schemes. | | So, I argue that the WG should review coding schemes. | | | | Regards, | | | | Gengyu | | | | ----- Original Message ----- | | From: | | To: | | Cc: | | Sent: Wednesday, June 18, 2008 8:42 PM | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | I think I may be confusing things unnecessarily. | | | | The encoding proposal from Toby & Michael et al is structured as | | follows: | | - a baseline encoding. This uses 1 (standardised) DSCP + the ECN | | codepoints in order to encode 2 states. | | - an extension encoding. This uses a second DSCP (in addition to the | | baseline's DSCP) + the ECN codepoints and encodes 3 states. | | | | The use of the ECN codepoints is compatible between them, | in the sense | | that eg ECN 11 means some form of PCN marking in all cases | - it was a | | deliberate choice to do it like this (So you could say that the 2 | | encoding states are a sub-set of the 3 encoding states - | | which is one of | | your requirements) | | | | The baseline has already been sent to the list | | | http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt | | - toby plans to send the extension draft soon (a draft is | | being reviewed | | amongst the authors) | | | | I think in your example you envisage 2 separate networks | both running | | PCN which then later get merged into a single PCN-domain. | So you have | | one with 2 encoding states & one with 3 encoding states (or | | indeed: both | | have 2 encoding states, but one is using them to trigger admission | | control and one termination control, relying on other | | mechanisms for the | | other function, or one is using the marks to trigger both | admission & | | termination - ie 'single marking'). As well as the pure | encoding, then | | there'll be other things to think about - eg the ingress & egress | | gateways can be in different domains and so will interpret | | the received | | marks differently. Personally I think it's reasonable to expect | | "management" to have to be done when the 2 separate nws are joined | | together to form a single PCN-domain - ie to coordinate how | PCN marks | | will be interpreted. I don't know whether something clever | can be done | | that doesn't require such work - maybe it would make a good topic to | | discuss over lunch, if you're in Dublin? (I think this kind of | | discussion on 'forming a single PCN domain from two separate PCN | | domains' probably falls into the inter-domain category, which | | is out of | | scope of PCN WG in initial charter.) | | | | Thanks | | phil | | | | { -----Original Message----- | | { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | { Sent: 18 June 2008 13:09 | | { To: Eardley,PL,Philip,CXR9 R | | { Cc: pcn@ietf.org | | { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | { | | { Phil, and all, | | { | | { I strongly suggest PCN WG review the coding scheme. | | { It is not good to have two exclusive coding algorithms in one | | technical | | { document. | | { | | { It is easy to see that 3-states have more information | than 2-states. | | { It is also possible to make 2-states be the subset of | three states. | | { The compatibility here means 3-state capability nodes can | understand | | 2- | | { state | | { coding. | | { | | { I did not suggest to use MTU discovery or similar | | mechanisms for node | | { clarification, neither do here. | | { | | { While remembering rudiger's words, we should face the existing | | problems of | | { networks. | | { The operator ought to knwo the nodes within its own dommains. | | { But, it is rather difficult for any operators to know the nodes of | | other | | { autonomous nodes | | { if a PCN domain covers several autonomous domains. | | { | | { I believe, it will be better if the PCN coding schemes is easy to | | deploy, | | { robust to work, and tolerant of faults. | | { | | { We do not need to make sure everything properly, | | { we only need to make 2-state capable nodes work togather | | with 3-state | | { capable nodes. | | { | | { Regards, | | { | | { Gengyu | | { | | { | | { ----- Original Message ----- | | { From: | | { To: ; | | { Sent: Wednesday, June 18, 2008 4:18 PM | | { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | { | | { | | { Gengyu, | | { | | { You raise interesting questions. I'm not really sure what | | compatibility | | { means in this context - it would probably need some | careful thought | | and | | { simulations /expts to work out if it could be compatible to some | | extent. | | { I'm not sure a similar mechanism to MTU discovery would be | | appropriate | | - | | { the number of encoding states in nodes in a PCN-domain really is | | { something that the operator of that domain ought to know - | | it doesn't | | { seem to me that this is a good thing to discover dynamically. | | { | | { I think we should remember rudiger's warning when we got into | | discussing | | { configuration issues before - it isn't our job to make sure | | everything | | { behaves properly if something is configured incorrectly | | { | | { Best wishes | | { Phil | | { | | { { -----Original Message----- | | { { From: pcn-bounces@ietf.org | [mailto:pcn-bounces@ietf.org] On Behalf | | Of | | { Wei | | { { Gengyu | | { { Sent: 17 June 2008 18:09 | | { { To: pcn@ietf.org | | { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | { { | | { { | | { { ----- Original Message ----- | | { { From: "Wei Gengyu" | | { { To: | | { { Sent: Tuesday, June 17, 2008 10:41 PM | | { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | | { { | | { { | | { { > Philip, | | { { > | | { { > For the first question, your I-D in Section 2.1 is | clear as you | | { said. | | { { > I got it after reading your explanations. Thank you. | | { { > | | { { > But, I still think it may be better to make 3-states nodes | | { compatible | | { { with | | { { > 2-states node. | | { { > Consider the case, if a PCN domain covers more than one | | autonomous | | { { domain | | { { > in the Internet, | | { { > the mechanism in sechtion 2.1 could not tolerate any | | configuration | | { { faults. | | { { > | | { { > So, if the PCN domain can works in 2-states scheme when | | there are | | { both | | { { > 2-state and 3state nodes, | | { { > loosely-consistent checking is required in a PCN domain. | | { { > | | { { > As clarification of nodes across several autonomous | domains may | | not | | { be | | { { as | | { { > easy as MTU discovery, | | { { > having the marking info compatible is probably better | | than making | | { { encoding | | { { > choice the same in all PCN links. | | { { > | | { { > Your comments? | | { { > | | { { > Regards, | | { { > | | { { > Gengyu | | { { > School of Computer Science and Technology | | { { > Beijing University of Posts and Telecommunications | | { { > | | { { > ----- Original Message ----- | | { { > From: | | { { > To: | | { { > Cc: | | { { > Sent: Tuesday, June 17, 2008 6:14 PM | | { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 | | { { > | | { { > | | { { > Gengyu | | { { > | | { { > Thanks very much for your comments! | | { { > | | { { > 1) I think this is covered in Section 2.1 (Scope), | which states | | "The | | { { > same choice MUST be used throughout a PCN-domain." - | this refers | | to | | { the | | { { > same choice about encoding states in all the PCN links in the | | { domain. | | { { > | | { { > In your example you have a node with 2 encoding states | | in the same | | { { > domain as nodes with 3 encoding states. Therefore the example | | breaks | | { the | | { { > "MUST" in Section 2.1, ie the domain is misconfigured (and so | | { strictly | | { { > speaking it isn't a PCN domain, so we don't need to | worry about | | it). | | { { > | | { { > If you've a suggestion how to clarify this, please | let me know. | | { { > | | { { > 2) if I understand you right, you're suggesting that | when a link | | is | | { { > pre-congested, it sends a message (instead of marking | packets). | | Yes, | | { { > this is a possible approach, but - as you say - it's | | out of scope | | of | | { { > PCN. | | { { > | | { { > thanks | | { { > phil | | { { > | | { { > { -----Original Message----- | | { { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | { { > { Sent: 17 June 2008 10:39 | | { { > { To: Eardley,PL,Philip,CXR9 R | | { { > { Cc: pcn@ietf.org | | { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | | { { > { | | { { > { Hi, | | { { > { | | { { > { I have some questions to ask after reading your I-D. | | { { > { | | { { > { 1) In a PCN domain, if the two-state node is between two | | { three-states | | { { > { nodes, | | { { > { how the marking scheme will be? | | { { > { So is it ture if there is a two-state node along | the route, | | { that | | { { > will | | { { > { be | | { { > { two-state scheme. | | { { > { This is important for a network administrator. | | { { > { 2) In section 2.2. Classify and condition function | | { { > { "There may be traffic that is more important | than PCN that | | { shares | | { { > the | | { { > { same capacity as PCN and is priority scheduled over PCN | | { (perhaps an | | { { > { operator's control messages). Such traffic MUST | be metered | | as | | { { > though | | { { > { it were PCN-traffic, but MUST NOT be PCN-marked. Such | | packets, | | { { > { together with PCN-packets, are called "metered packets"." | | { { > { | | { { > { You mentioned the packet which contains an | | operator's control | | { { > messages, | | { { > { so my question is if the marking contexts are sent | in control | | { { > messages, | | { { > { or PCN-capable nodes at ingress generat control | messages when | | { sending | | { { > { marks, | | { { > { what the pcn will be? | | { { > { Perhaps the second question is out of the scope of PCN, | | { { > { but there was some schemes in ATM to send RM cell instead of | | { marking | | { { > each | | { { > { cell. | | { { > { | | { { > { Regards, | | { { > { | | { { > { Gengyu | | { { > { | | { { > | | { { | | { { _______________________________________________ | | { { 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 | | | | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jun 26 00:32:15 2008 Return-Path: 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 2F4633A6840; Thu, 26 Jun 2008 00:32:15 -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 3F34C3A6832 for ; Thu, 26 Jun 2008 00:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=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 LXt5+6BME3a5 for ; Thu, 26 Jun 2008 00:32:12 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id C24F03A6803 for ; Thu, 26 Jun 2008 00:32:11 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Thu, 26 Jun 2008 09:32:13 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 09:32:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 09:32:12 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C4C16A8@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <7DF1FC27CFF543D8A12DB877C9E26130@ibmPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 Thread-Index: AcjW2OTLGt8fiq0kSm6itRI04+fgXQAhAsAg References: <4A916DBC72536E419A0BD955EDECEDEC0329F82B@E03MVB1-UKBR.domain1.systemhost.net> <5351E79284D944639901EDC11D6E9676@ibmPC> <1B6169C658325341A3B8066E23919E1C0164B207@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C4C168E@S4DE8PSAANK.mitte.t-com.de> <7DF1FC27CFF543D8A12DB877C9E26130@ibmPC> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 26 Jun 2008 07:32:13.0376 (UTC) FILETIME=[C0551C00:01C8D75E] Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Gengyu, RFCs dealing with IP usually just handle IP and those dealing with MPLS foc= us on MPLS and Ethernet standardisation is an IEEE matter. A single adminis= tration facing competition will however try to minimise her costs and this = usually demands coherent deployment of services. With regard ti marking, please keep in mind that packets transported by MPL= S label switched paths may face "Pen ultimate hop popping" and be received = by the destination Label Edge Router as an IP packet (given the data and co= ntrol plane for the packet is IP). This packet is marked however following = the marking scheme of an MPLS node. Of course you could demand, that the ro= uter differs marked packets received on a native IP interface from those re= ceived on an MPLS interface. There's no restriction however to operate inte= rfaces in MPLS or IP only, meaning you can simultaneously receive IP packet= s with and without prior MPLS transport on that Label Edge Router interface= . Please note, that I'm just describing trouble you cause by different PCN = deployment schemes. I'm still waiting for you to describe the benefits of mixed PCN operating s= chemes within a single domain. There are none, if I interpret your silence = on this topic correctly. Regards, Rudiger | -----Original Message----- | From: Wei Gengyu [mailto:weigengyu@vip.sina.com] = | Sent: Wednesday, June 25, 2008 5:32 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | = | Ruediger, | = | Thank you for you reply. | = | If one DS domain definition is from RFC 2475, the following = | word should be noticced too in this RFC2475. | This could help us to clarify what is within a singl DS = | domain or within an inter-domains. | = | "2.1 Differentiated Services Domain | A DS domain normally consists of one or more networks = | under the same | administration; for example, an organization's intranet or an ISP. | The administration of the domain is responsible for ensuring that | adequate resources are provisioned and/or reserved to support the | SLAs offered by the domain. " | = | And there is no decription about constrains to DSCP when IP = | over ethernet, ATM or MPLS. | Or you can have the same coding scheme in the networks by RFC2475. | = | While in the I-D "draft-chan-pcn-encoding-comparison-03", | considerations of encoding are listed, but "Section 4. = | Encoding Recommendations" is blank. | = | Each encoding scheme is not clearly specific to a certain = | network technology underneath IP. | The sematics of DSCP are just as the network layer issues, is = | it right? | = | Regards, | = | Gengyu | = | = | ----- Original Message ----- | From: "Geib, Ruediger" | To: | Cc: | Sent: Tuesday, June 24, 2008 7:40 PM | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | = | = | Gengyu | = | | But, What is is a DS domain? | | I do not know where the definition of a DS domain is from. | | Perhaps, all connected equipements capable of DiffServ | | marking form a DS domain. Right? | = | See RFC 2475 | = | DS domain a DS-capable domain; a contiguous set of | nodes which operate with a common set of | service provisioning policies and PHB | definitions. | = | = | | Then consider a compus network that includes Ethernet, ATM, | | MPLS equipements. | | The compus network is owned and operated by the university. | | | | My questions are | | 1) is the campus network a single DS domain? | = | Yes, presumably (unless each faculty runs an own network). | = | | 2) are there both three state coding and two state coding | | existed if adopting PCN? | = | I don't think so. What would be the benefit of that as | compared to the cost? If operation and planning of such a network | is just simple, such a solution may be worth thinking about. | But I doubt that it is simple. | = | = | Regards, | = | Rudiger | = | | | | Regards, | | | | Gengyu | | | | | | ----- Original Message ----- | | From: "Geib, Ruediger" | | To: | | Cc: ; | | Sent: Friday, June 20, 2008 10:37 PM | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | Gengyu, | | | | the two state issue may specifically be relevant for carriers | | working with | | MPLS. Inter carrier MPLS services are possible, but still I | | doubt that there | | are many carriers operating MPLS with three PCN states if | | there are just 8 | | DiffServ states all in all. | | | | What you address would then be an interdomain case of one | | carrier operating | | three states on IP whose network is connected to another | | carrier operating a | | two state network. That's an issue, but interdomain scenarios | | are out of | | scope for the time being (Phil mentioned that already). | | | | A carrier operating with two state routers in parallel with | | three state | | routers - like running IP three state and MPLS two state - | | well, I'm not | | sure whether that makes any sense, I'd have to think about | | that. But to be | | honest, it looks as if it makes the solution more complex and | | that's exactly | | what I try to avoid, unless I can see a clear benefit for the | | more complex | | solution. What does a carrier gain if some of his routers | | work with three | | PCN states while others work with two states? | | | | Please also consider RFC5129 with regards to MPLS = | behaviour. I wonder | | whether IETF will accept different remarking schemes during | | the ultimate | | label popping than described there any time soon. | | | | Regards, | | | | Rudiger | | | | | | | -----Original Message----- | | | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | | | Behalf Of Wei Gengyu | | | Sent: Thursday, June 19, 2008 7:05 PM | | | To: philip.eardley@bt.com | | | Cc: pcn@ietf.org | | | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | Phil, | | | | | | I am not in Dublin, but I like to drink red tea while | | | disscussing the technical issues with my collegues. | | | The network we often concern is the network that covers an | | | area greater than an island. | | | | | | Consider the case, a university with serveral campus located | | | at different cities, it is one unversity network of a | | | collection of campus networks. | | | Or the network of an enterprises with serveral branches | | | located in different states is one network. | | | Those are truely existed networks nowadays. | | | | | | And having experiences as a network administor will be | | | helpful to decide how to configure a network and to | | | understand the problem of coding schemes. | | | | | | In your email you described the problem and the node | | behavior clearly. | | | I do think that the problems must be solved. | | | | | | In my opinion,the problems are due to the semantics of | | | 2-state and 3-state coding schemes. | | | So, I argue that the WG should review coding schemes. | | | | | | Regards, | | | | | | Gengyu | | | | | | ----- Original Message ----- | | | From: | | | To: | | | Cc: | | | Sent: Wednesday, June 18, 2008 8:42 PM | | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | | | | I think I may be confusing things unnecessarily. | | | | | | The encoding proposal from Toby & Michael et al is structured as | | | follows: | | | - a baseline encoding. This uses 1 (standardised) DSCP + the ECN | | | codepoints in order to encode 2 states. | | | - an extension encoding. This uses a second DSCP (in = | addition to the | | | baseline's DSCP) + the ECN codepoints and encodes 3 states. | | | | | | The use of the ECN codepoints is compatible between them, | | in the sense | | | that eg ECN 11 means some form of PCN marking in all cases | | - it was a | | | deliberate choice to do it like this (So you could say that the 2 | | | encoding states are a sub-set of the 3 encoding states - | | | which is one of | | | your requirements) | | | | | | The baseline has already been sent to the list | | | | | = | http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt | | | - toby plans to send the extension draft soon (a draft is | | | being reviewed | | | amongst the authors) | | | | | | I think in your example you envisage 2 separate networks | | both running | | | PCN which then later get merged into a single PCN-domain. | | So you have | | | one with 2 encoding states & one with 3 encoding states (or | | | indeed: both | | | have 2 encoding states, but one is using them to trigger admission | | | control and one termination control, relying on other | | | mechanisms for the | | | other function, or one is using the marks to trigger both | | admission & | | | termination - ie 'single marking'). As well as the pure | | encoding, then | | | there'll be other things to think about - eg the ingress & egress | | | gateways can be in different domains and so will interpret | | | the received | | | marks differently. Personally I think it's reasonable to expect | | | "management" to have to be done when the 2 separate nws are joined | | | together to form a single PCN-domain - ie to coordinate how | | PCN marks | | | will be interpreted. I don't know whether something clever | | can be done | | | that doesn't require such work - maybe it would make a = | good topic to | | | discuss over lunch, if you're in Dublin? (I think this kind of | | | discussion on 'forming a single PCN domain from two separate PCN | | | domains' probably falls into the inter-domain category, which | | | is out of | | | scope of PCN WG in initial charter.) | | | | | | Thanks | | | phil | | | | | | { -----Original Message----- | | | { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | | { Sent: 18 June 2008 13:09 | | | { To: Eardley,PL,Philip,CXR9 R | | | { Cc: pcn@ietf.org | | | { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | { | | | { Phil, and all, | | | { | | | { I strongly suggest PCN WG review the coding scheme. | | | { It is not good to have two exclusive coding algorithms in one | | | technical | | | { document. | | | { | | | { It is easy to see that 3-states have more information | | than 2-states. | | | { It is also possible to make 2-states be the subset of | | three states. | | | { The compatibility here means 3-state capability nodes can | | understand | | | 2- | | | { state | | | { coding. | | | { | | | { I did not suggest to use MTU discovery or similar | | | mechanisms for node | | | { clarification, neither do here. | | | { | | | { While remembering rudiger's words, we should face the existing | | | problems of | | | { networks. | | | { The operator ought to knwo the nodes within its own dommains. | | | { But, it is rather difficult for any operators to know = | the nodes of | | | other | | | { autonomous nodes | | | { if a PCN domain covers several autonomous domains. | | | { | | | { I believe, it will be better if the PCN coding schemes = | is easy to | | | deploy, | | | { robust to work, and tolerant of faults. | | | { | | | { We do not need to make sure everything properly, | | | { we only need to make 2-state capable nodes work togather | | | with 3-state | | | { capable nodes. | | | { | | | { Regards, | | | { | | | { Gengyu | | | { | | | { | | | { ----- Original Message ----- | | | { From: | | | { To: ; | | | { Sent: Wednesday, June 18, 2008 4:18 PM | | | { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | { | | | { | | | { Gengyu, | | | { | | | { You raise interesting questions. I'm not really sure what | | | compatibility | | | { means in this context - it would probably need some | | careful thought | | | and | | | { simulations /expts to work out if it could be compatible to some | | | extent. | | | { I'm not sure a similar mechanism to MTU discovery would be | | | appropriate | | | - | | | { the number of encoding states in nodes in a PCN-domain really is | | | { something that the operator of that domain ought to know - | | | it doesn't | | | { seem to me that this is a good thing to discover dynamically. | | | { | | | { I think we should remember rudiger's warning when we got into | | | discussing | | | { configuration issues before - it isn't our job to make sure | | | everything | | | { behaves properly if something is configured incorrectly | | | { | | | { Best wishes | | | { Phil | | | { | | | { { -----Original Message----- | | | { { From: pcn-bounces@ietf.org | | [mailto:pcn-bounces@ietf.org] On Behalf | | | Of | | | { Wei | | | { { Gengyu | | | { { Sent: 17 June 2008 18:09 | | | { { To: pcn@ietf.org | | | { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | { { | | | { { | | | { { ----- Original Message ----- | | | { { From: "Wei Gengyu" | | | { { To: | | | { { Sent: Tuesday, June 17, 2008 10:41 PM | | | { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | | | { { | | | { { | | | { { > Philip, | | | { { > | | | { { > For the first question, your I-D in Section 2.1 is | | clear as you | | | { said. | | | { { > I got it after reading your explanations. Thank you. | | | { { > | | | { { > But, I still think it may be better to make 3-states nodes | | | { compatible | | | { { with | | | { { > 2-states node. | | | { { > Consider the case, if a PCN domain covers more than one | | | autonomous | | | { { domain | | | { { > in the Internet, | | | { { > the mechanism in sechtion 2.1 could not tolerate any | | | configuration | | | { { faults. | | | { { > | | | { { > So, if the PCN domain can works in 2-states scheme when | | | there are | | | { both | | | { { > 2-state and 3state nodes, | | | { { > loosely-consistent checking is required in a PCN domain. | | | { { > | | | { { > As clarification of nodes across several autonomous | | domains may | | | not | | | { be | | | { { as | | | { { > easy as MTU discovery, | | | { { > having the marking info compatible is probably better | | | than making | | | { { encoding | | | { { > choice the same in all PCN links. | | | { { > | | | { { > Your comments? | | | { { > | | | { { > Regards, | | | { { > | | | { { > Gengyu | | | { { > School of Computer Science and Technology | | | { { > Beijing University of Posts and Telecommunications | | | { { > | | | { { > ----- Original Message ----- | | | { { > From: | | | { { > To: | | | { { > Cc: | | | { { > Sent: Tuesday, June 17, 2008 6:14 PM | | | { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 | | | { { > | | | { { > | | | { { > Gengyu | | | { { > | | | { { > Thanks very much for your comments! | | | { { > | | | { { > 1) I think this is covered in Section 2.1 (Scope), | | which states | | | "The | | | { { > same choice MUST be used throughout a PCN-domain." - | | this refers | | | to | | | { the | | | { { > same choice about encoding states in all the PCN = | links in the | | | { domain. | | | { { > | | | { { > In your example you have a node with 2 encoding states | | | in the same | | | { { > domain as nodes with 3 encoding states. Therefore = | the example | | | breaks | | | { the | | | { { > "MUST" in Section 2.1, ie the domain is = | misconfigured (and so | | | { strictly | | | { { > speaking it isn't a PCN domain, so we don't need to | | worry about | | | it). | | | { { > | | | { { > If you've a suggestion how to clarify this, please | | let me know. | | | { { > | | | { { > 2) if I understand you right, you're suggesting that | | when a link | | | is | | | { { > pre-congested, it sends a message (instead of marking | | packets). | | | Yes, | | | { { > this is a possible approach, but - as you say - it's | | | out of scope | | | of | | | { { > PCN. | | | { { > | | | { { > thanks | | | { { > phil | | | { { > | | | { { > { -----Original Message----- | | | { { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | | { { > { Sent: 17 June 2008 10:39 | | | { { > { To: Eardley,PL,Philip,CXR9 R | | | { { > { Cc: pcn@ietf.org | | | { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | | | { { > { | | | { { > { Hi, | | | { { > { | | | { { > { I have some questions to ask after reading your I-D. | | | { { > { | | | { { > { 1) In a PCN domain, if the two-state node is between two | | | { three-states | | | { { > { nodes, | | | { { > { how the marking scheme will be? | | | { { > { So is it ture if there is a two-state node along | | the route, | | | { that | | | { { > will | | | { { > { be | | | { { > { two-state scheme. | | | { { > { This is important for a network administrator. | | | { { > { 2) In section 2.2. Classify and condition function | | | { { > { "There may be traffic that is more important | | than PCN that | | | { shares | | | { { > the | | | { { > { same capacity as PCN and is priority scheduled over PCN | | | { (perhaps an | | | { { > { operator's control messages). Such traffic MUST | | be metered | | | as | | | { { > though | | | { { > { it were PCN-traffic, but MUST NOT be PCN-marked. Such | | | packets, | | | { { > { together with PCN-packets, are called "metered = | packets"." | | | { { > { | | | { { > { You mentioned the packet which contains an | | | operator's control | | | { { > messages, | | | { { > { so my question is if the marking contexts are sent | | in control | | | { { > messages, | | | { { > { or PCN-capable nodes at ingress generat control | | messages when | | | { sending | | | { { > { marks, | | | { { > { what the pcn will be? | | | { { > { Perhaps the second question is out of the scope of PCN, | | | { { > { but there was some schemes in ATM to send RM cell = | instead of | | | { marking | | | { { > each | | | { { > { cell. | | | { { > { | | | { { > { Regards, | | | { { > { | | | { { > { Gengyu | | | { { > { | | | { { > | | | { { | | | { { _______________________________________________ | | | { { 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 | | | | | | | | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jun 26 01:21:24 2008 Return-Path: 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 D77F93A67DF; Thu, 26 Jun 2008 01:21:24 -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 80DDB3A67B6 for ; Thu, 26 Jun 2008 01:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, 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 y1-19B8TXEa4 for ; Thu, 26 Jun 2008 01:21:22 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 3AE653A67AE for ; Thu, 26 Jun 2008 01:21:21 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 09:21:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 09:21:21 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F885@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <7DF1FC27CFF543D8A12DB877C9E26130@ibmPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 Thread-Index: AcjW2U92gxWt30VpT2SoOdCbfRqYcwAjAvnA From: To: , X-OriginalArrivalTime: 26 Jun 2008 08:21:22.0294 (UTC) FILETIME=[9E064960:01C8D765] Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org { { While in the I-D "draft-chan-pcn-encoding-comparison-03", { considerations of encoding are listed, but "Section 4. Encoding { Recommendations" is blank. { the 2 moncaster-pcn encoding drafts are really the recommendations that arose out of the comparison draft (updating comparison draft is on the back burner at the moment) _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jun 26 02:01:20 2008 Return-Path: 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 0BB143A6982; Thu, 26 Jun 2008 02:01:20 -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 65A2D3A6913 for ; Thu, 26 Jun 2008 02:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, 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 lfQDCS7G+Ht2 for ; Thu, 26 Jun 2008 02:01:17 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 1F8813A6A49 for ; Thu, 26 Jun 2008 02:01:11 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jun 2008 10:01:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 10:01:11 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F886@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New version of the marking behaviour draft Thread-Index: AcjXayyZY1ULmuV2QiaapwOB+jMbyg== From: To: X-OriginalArrivalTime: 26 Jun 2008 09:01:11.0292 (UTC) FILETIME=[2DFA73C0:01C8D76B] Subject: [PCN] New version of the marking behaviour draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0491638391==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0491638391== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8D76B.2DD12580" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8D76B.2DD12580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've just updated the marking behaviour draft, http://www.ietf.org/internet-drafts/draft-eardley-pcn-marking-behaviour- 01.txt=20 =20 Main change was to re-write Traffic conditioning section - also tried to take account of the two encoding drafts (baseline & extension). =20 Comments welcome! Thanks Phil =20 Abstract =20 This document standardises the two marking behaviours of PCN-nodes: threshold marking and excess traffic marking. Threshold marking marks all PCN-packets if the PCN traffic rate is greater than a first configured rate. Excess traffic marking marks a proportion of PCN- packets, such that the amount marked equals the traffic rate in excess of a second configured rate. =20 =20 ------_=_NextPart_001_01C8D76B.2DD12580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve just updated the marking behaviour = draft, http://www.ietf.org/internet-drafts/draft-eardley-pcn-mark= ing-behaviour-01.txt

 

Main change was to re-write Traffic = conditioning section – also tried to take account of the two encoding drafts (baseline = & extension).

 

Comments welcome!

Thanks

Phil

 

Abstract
 
   This document standardises the =
two marking behaviours of PCN-nodes:
   threshold marking and excess =
traffic marking.  Threshold marking
   marks all PCN-packets if the PCN =
traffic rate is greater than a first
   configured rate.  Excess =
traffic marking marks a proportion of PCN-
   packets, such that the amount =
marked equals the traffic rate in
   excess of a second configured =
rate.

 

 

=00 ------_=_NextPart_001_01C8D76B.2DD12580-- --===============0491638391== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0491638391==-- From pcn-bounces@ietf.org Thu Jun 26 03:30:57 2008 Return-Path: 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 211543A693F; Thu, 26 Jun 2008 03:30:57 -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 3A93B3A693F for ; Thu, 26 Jun 2008 03:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=0.6, STOX_REPLY_TYPE=0.001] 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 KSsRRTJ3QVXH for ; Thu, 26 Jun 2008 03:30:53 -0700 (PDT) Received: from smtp-6-98.vip.sina.com (smtp.vip.sina.com [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id 881FF3A6811 for ; Thu, 26 Jun 2008 03:30:51 -0700 (PDT) Received: from ibmPC (unknown [211.160.21.17]) by smtp-6-98.vip.sina.com (SINAMAIL) with ESMTP id A269A1DE138; Thu, 26 Jun 2008 18:30:40 +0800 (CST) Message-ID: From: "Wei Gengyu" To: "Geib, Ruediger" References: <4A916DBC72536E419A0BD955EDECEDEC0329F82B@E03MVB1-UKBR.domain1.systemhost.net> <5351E79284D944639901EDC11D6E9676@ibmPC> <1B6169C658325341A3B8066E23919E1C0164B207@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C4C168E@S4DE8PSAANK.mitte.t-com.de> <7DF1FC27CFF543D8A12DB877C9E26130@ibmPC> <1B6169C658325341A3B8066E23919E1C4C16A8@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C4C16A8@S4DE8PSAANK.mitte.t-com.de> Date: Thu, 26 Jun 2008 18:30:29 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Rudiger, Configuring nodes as a two-state encoding or three-state encoding in a = single DS domain is the possible problem I will meet, that was not the suggestion. Existing I-Ds defined the two-states and three states encoding schemes. And the behaviour of two-state and three-state capable nodes are not = compatible in terms of coding semantics, many independent PCN islands would be seen. By RFC2475, a university network should be a single DS networks. It is possible to have the mixed PCN operating schemes within a single = domain in the network of a university with several campuses. We have experienced a few incompatibility problems when configuring the = network. The reasons said by suppliers include equipments model limitations, softwar= e = version constrains, RFCxxxx options, or etcs. My opinion is that if the PCN two-state and three-state options have to be = standardized, the node behaviors should be compatible. This will result in easy to deploy in network administration and operation. = Do you agree? Frankly, I am not a native speaker of English, it takes a little time to = write the reply. And as a serious scholar, I need to browse the references when writing = email. There is no necessary "to keep silence". Whether my opinions is right or not, I take the dicussion serious on = technology issues. Regards, Gengyu ----- Original Message ----- = From: "Geib, Ruediger" To: Cc: Sent: Thursday, June 26, 2008 3:32 PM Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 Gengyu, RFCs dealing with IP usually just handle IP and those dealing with MPLS = focus on MPLS and Ethernet standardisation is an IEEE matter. A single = administration facing competition will however try to minimise her costs an= d = this usually demands coherent deployment of services. With regard ti marking, please keep in mind that packets transported by MPL= S = label switched paths may face "Pen ultimate hop popping" and be received by = the destination Label Edge Router as an IP packet (given the data and = control plane for the packet is IP). This packet is marked however followin= g = the marking scheme of an MPLS node. Of course you could demand, that the = router differs marked packets received on a native IP interface from those = received on an MPLS interface. There's no restriction however to operate = interfaces in MPLS or IP only, meaning you can simultaneously receive IP = packets with and without prior MPLS transport on that Label Edge Router = interface. Please note, that I'm just describing trouble you cause by = different PCN deployment schemes. I'm still waiting for you to describe the benefits of mixed PCN operating = schemes within a single domain. There are none, if I interpret your silence = on this topic correctly. Regards, Rudiger | -----Original Message----- | From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | Sent: Wednesday, June 25, 2008 5:32 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | Ruediger, | | Thank you for you reply. | | If one DS domain definition is from RFC 2475, the following | word should be noticced too in this RFC2475. | This could help us to clarify what is within a singl DS | domain or within an inter-domains. | | "2.1 Differentiated Services Domain | A DS domain normally consists of one or more networks | under the same | administration; for example, an organization's intranet or an ISP. | The administration of the domain is responsible for ensuring that | adequate resources are provisioned and/or reserved to support the | SLAs offered by the domain. " | | And there is no decription about constrains to DSCP when IP | over ethernet, ATM or MPLS. | Or you can have the same coding scheme in the networks by RFC2475. | | While in the I-D "draft-chan-pcn-encoding-comparison-03", | considerations of encoding are listed, but "Section 4. | Encoding Recommendations" is blank. | | Each encoding scheme is not clearly specific to a certain | network technology underneath IP. | The sematics of DSCP are just as the network layer issues, is | it right? | | Regards, | | Gengyu | | | ----- Original Message ----- | From: "Geib, Ruediger" | To: | Cc: | Sent: Tuesday, June 24, 2008 7:40 PM | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | Gengyu | | | But, What is is a DS domain? | | I do not know where the definition of a DS domain is from. | | Perhaps, all connected equipements capable of DiffServ | | marking form a DS domain. Right? | | See RFC 2475 | | DS domain a DS-capable domain; a contiguous set of | nodes which operate with a common set of | service provisioning policies and PHB | definitions. | | | | Then consider a compus network that includes Ethernet, ATM, | | MPLS equipements. | | The compus network is owned and operated by the university. | | | | My questions are | | 1) is the campus network a single DS domain? | | Yes, presumably (unless each faculty runs an own network). | | | 2) are there both three state coding and two state coding | | existed if adopting PCN? | | I don't think so. What would be the benefit of that as | compared to the cost? If operation and planning of such a network | is just simple, such a solution may be worth thinking about. | But I doubt that it is simple. | | | Regards, | | Rudiger | | | | | Regards, | | | | Gengyu | | | | | | ----- Original Message ----- | | From: "Geib, Ruediger" | | To: | | Cc: ; | | Sent: Friday, June 20, 2008 10:37 PM | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | Gengyu, | | | | the two state issue may specifically be relevant for carriers | | working with | | MPLS. Inter carrier MPLS services are possible, but still I | | doubt that there | | are many carriers operating MPLS with three PCN states if | | there are just 8 | | DiffServ states all in all. | | | | What you address would then be an interdomain case of one | | carrier operating | | three states on IP whose network is connected to another | | carrier operating a | | two state network. That's an issue, but interdomain scenarios | | are out of | | scope for the time being (Phil mentioned that already). | | | | A carrier operating with two state routers in parallel with | | three state | | routers - like running IP three state and MPLS two state - | | well, I'm not | | sure whether that makes any sense, I'd have to think about | | that. But to be | | honest, it looks as if it makes the solution more complex and | | that's exactly | | what I try to avoid, unless I can see a clear benefit for the | | more complex | | solution. What does a carrier gain if some of his routers | | work with three | | PCN states while others work with two states? | | | | Please also consider RFC5129 with regards to MPLS | behaviour. I wonder | | whether IETF will accept different remarking schemes during | | the ultimate | | label popping than described there any time soon. | | | | Regards, | | | | Rudiger | | | | | | | -----Original Message----- | | | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | | | Behalf Of Wei Gengyu | | | Sent: Thursday, June 19, 2008 7:05 PM | | | To: philip.eardley@bt.com | | | Cc: pcn@ietf.org | | | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | Phil, | | | | | | I am not in Dublin, but I like to drink red tea while | | | disscussing the technical issues with my collegues. | | | The network we often concern is the network that covers an | | | area greater than an island. | | | | | | Consider the case, a university with serveral campus located | | | at different cities, it is one unversity network of a | | | collection of campus networks. | | | Or the network of an enterprises with serveral branches | | | located in different states is one network. | | | Those are truely existed networks nowadays. | | | | | | And having experiences as a network administor will be | | | helpful to decide how to configure a network and to | | | understand the problem of coding schemes. | | | | | | In your email you described the problem and the node | | behavior clearly. | | | I do think that the problems must be solved. | | | | | | In my opinion,the problems are due to the semantics of | | | 2-state and 3-state coding schemes. | | | So, I argue that the WG should review coding schemes. | | | | | | Regards, | | | | | | Gengyu | | | | | | ----- Original Message ----- | | | From: | | | To: | | | Cc: | | | Sent: Wednesday, June 18, 2008 8:42 PM | | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | | | | I think I may be confusing things unnecessarily. | | | | | | The encoding proposal from Toby & Michael et al is structured as | | | follows: | | | - a baseline encoding. This uses 1 (standardised) DSCP + the ECN | | | codepoints in order to encode 2 states. | | | - an extension encoding. This uses a second DSCP (in | addition to the | | | baseline's DSCP) + the ECN codepoints and encodes 3 states. | | | | | | The use of the ECN codepoints is compatible between them, | | in the sense | | | that eg ECN 11 means some form of PCN marking in all cases | | - it was a | | | deliberate choice to do it like this (So you could say that the 2 | | | encoding states are a sub-set of the 3 encoding states - | | | which is one of | | | your requirements) | | | | | | The baseline has already been sent to the list | | | | | | http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt | | | - toby plans to send the extension draft soon (a draft is | | | being reviewed | | | amongst the authors) | | | | | | I think in your example you envisage 2 separate networks | | both running | | | PCN which then later get merged into a single PCN-domain. | | So you have | | | one with 2 encoding states & one with 3 encoding states (or | | | indeed: both | | | have 2 encoding states, but one is using them to trigger admission | | | control and one termination control, relying on other | | | mechanisms for the | | | other function, or one is using the marks to trigger both | | admission & | | | termination - ie 'single marking'). As well as the pure | | encoding, then | | | there'll be other things to think about - eg the ingress & egress | | | gateways can be in different domains and so will interpret | | | the received | | | marks differently. Personally I think it's reasonable to expect | | | "management" to have to be done when the 2 separate nws are joined | | | together to form a single PCN-domain - ie to coordinate how | | PCN marks | | | will be interpreted. I don't know whether something clever | | can be done | | | that doesn't require such work - maybe it would make a | good topic to | | | discuss over lunch, if you're in Dublin? (I think this kind of | | | discussion on 'forming a single PCN domain from two separate PCN | | | domains' probably falls into the inter-domain category, which | | | is out of | | | scope of PCN WG in initial charter.) | | | | | | Thanks | | | phil | | | | | | { -----Original Message----- | | | { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | | { Sent: 18 June 2008 13:09 | | | { To: Eardley,PL,Philip,CXR9 R | | | { Cc: pcn@ietf.org | | | { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | { | | | { Phil, and all, | | | { | | | { I strongly suggest PCN WG review the coding scheme. | | | { It is not good to have two exclusive coding algorithms in one | | | technical | | | { document. | | | { | | | { It is easy to see that 3-states have more information | | than 2-states. | | | { It is also possible to make 2-states be the subset of | | three states. | | | { The compatibility here means 3-state capability nodes can | | understand | | | 2- | | | { state | | | { coding. | | | { | | | { I did not suggest to use MTU discovery or similar | | | mechanisms for node | | | { clarification, neither do here. | | | { | | | { While remembering rudiger's words, we should face the existing | | | problems of | | | { networks. | | | { The operator ought to knwo the nodes within its own dommains. | | | { But, it is rather difficult for any operators to know | the nodes of | | | other | | | { autonomous nodes | | | { if a PCN domain covers several autonomous domains. | | | { | | | { I believe, it will be better if the PCN coding schemes | is easy to | | | deploy, | | | { robust to work, and tolerant of faults. | | | { | | | { We do not need to make sure everything properly, | | | { we only need to make 2-state capable nodes work togather | | | with 3-state | | | { capable nodes. | | | { | | | { Regards, | | | { | | | { Gengyu | | | { | | | { | | | { ----- Original Message ----- | | | { From: | | | { To: ; | | | { Sent: Wednesday, June 18, 2008 4:18 PM | | | { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | { | | | { | | | { Gengyu, | | | { | | | { You raise interesting questions. I'm not really sure what | | | compatibility | | | { means in this context - it would probably need some | | careful thought | | | and | | | { simulations /expts to work out if it could be compatible to some | | | extent. | | | { I'm not sure a similar mechanism to MTU discovery would be | | | appropriate | | | - | | | { the number of encoding states in nodes in a PCN-domain really is | | | { something that the operator of that domain ought to know - | | | it doesn't | | | { seem to me that this is a good thing to discover dynamically. | | | { | | | { I think we should remember rudiger's warning when we got into | | | discussing | | | { configuration issues before - it isn't our job to make sure | | | everything | | | { behaves properly if something is configured incorrectly | | | { | | | { Best wishes | | | { Phil | | | { | | | { { -----Original Message----- | | | { { From: pcn-bounces@ietf.org | | [mailto:pcn-bounces@ietf.org] On Behalf | | | Of | | | { Wei | | | { { Gengyu | | | { { Sent: 17 June 2008 18:09 | | | { { To: pcn@ietf.org | | | { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | { { | | | { { | | | { { ----- Original Message ----- | | | { { From: "Wei Gengyu" | | | { { To: | | | { { Sent: Tuesday, June 17, 2008 10:41 PM | | | { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | | | { { | | | { { | | | { { > Philip, | | | { { > | | | { { > For the first question, your I-D in Section 2.1 is | | clear as you | | | { said. | | | { { > I got it after reading your explanations. Thank you. | | | { { > | | | { { > But, I still think it may be better to make 3-states nodes | | | { compatible | | | { { with | | | { { > 2-states node. | | | { { > Consider the case, if a PCN domain covers more than one | | | autonomous | | | { { domain | | | { { > in the Internet, | | | { { > the mechanism in sechtion 2.1 could not tolerate any | | | configuration | | | { { faults. | | | { { > | | | { { > So, if the PCN domain can works in 2-states scheme when | | | there are | | | { both | | | { { > 2-state and 3state nodes, | | | { { > loosely-consistent checking is required in a PCN domain. | | | { { > | | | { { > As clarification of nodes across several autonomous | | domains may | | | not | | | { be | | | { { as | | | { { > easy as MTU discovery, | | | { { > having the marking info compatible is probably better | | | than making | | | { { encoding | | | { { > choice the same in all PCN links. | | | { { > | | | { { > Your comments? | | | { { > | | | { { > Regards, | | | { { > | | | { { > Gengyu | | | { { > School of Computer Science and Technology | | | { { > Beijing University of Posts and Telecommunications | | | { { > | | | { { > ----- Original Message ----- | | | { { > From: | | | { { > To: | | | { { > Cc: | | | { { > Sent: Tuesday, June 17, 2008 6:14 PM | | | { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 | | | { { > | | | { { > | | | { { > Gengyu | | | { { > | | | { { > Thanks very much for your comments! | | | { { > | | | { { > 1) I think this is covered in Section 2.1 (Scope), | | which states | | | "The | | | { { > same choice MUST be used throughout a PCN-domain." - | | this refers | | | to | | | { the | | | { { > same choice about encoding states in all the PCN | links in the | | | { domain. | | | { { > | | | { { > In your example you have a node with 2 encoding states | | | in the same | | | { { > domain as nodes with 3 encoding states. Therefore | the example | | | breaks | | | { the | | | { { > "MUST" in Section 2.1, ie the domain is | misconfigured (and so | | | { strictly | | | { { > speaking it isn't a PCN domain, so we don't need to | | worry about | | | it). | | | { { > | | | { { > If you've a suggestion how to clarify this, please | | let me know. | | | { { > | | | { { > 2) if I understand you right, you're suggesting that | | when a link | | | is | | | { { > pre-congested, it sends a message (instead of marking | | packets). | | | Yes, | | | { { > this is a possible approach, but - as you say - it's | | | out of scope | | | of | | | { { > PCN. | | | { { > | | | { { > thanks | | | { { > phil | | | { { > | | | { { > { -----Original Message----- | | | { { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | | { { > { Sent: 17 June 2008 10:39 | | | { { > { To: Eardley,PL,Philip,CXR9 R | | | { { > { Cc: pcn@ietf.org | | | { { > { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | | | { { > { | | | { { > { Hi, | | | { { > { | | | { { > { I have some questions to ask after reading your I-D. | | | { { > { | | | { { > { 1) In a PCN domain, if the two-state node is between two | | | { three-states | | | { { > { nodes, | | | { { > { how the marking scheme will be? | | | { { > { So is it ture if there is a two-state node along | | the route, | | | { that | | | { { > will | | | { { > { be | | | { { > { two-state scheme. | | | { { > { This is important for a network administrator. | | | { { > { 2) In section 2.2. Classify and condition function | | | { { > { "There may be traffic that is more important | | than PCN that | | | { shares | | | { { > the | | | { { > { same capacity as PCN and is priority scheduled over PCN | | | { (perhaps an | | | { { > { operator's control messages). Such traffic MUST | | be metered | | | as | | | { { > though | | | { { > { it were PCN-traffic, but MUST NOT be PCN-marked. Such | | | packets, | | | { { > { together with PCN-packets, are called "metered | packets"." | | | { { > { | | | { { > { You mentioned the packet which contains an | | | operator's control | | | { { > messages, | | | { { > { so my question is if the marking contexts are sent | | in control | | | { { > messages, | | | { { > { or PCN-capable nodes at ingress generat control | | messages when | | | { sending | | | { { > { marks, | | | { { > { what the pcn will be? | | | { { > { Perhaps the second question is out of the scope of PCN, | | | { { > { but there was some schemes in ATM to send RM cell | instead of | | | { marking | | | { { > each | | | { { > { cell. | | | { { > { | | | { { > { Regards, | | | { { > { | | | { { > { Gengyu | | | { { > { | | | { { > | | | { { | | | { { _______________________________________________ | | | { { 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 | | | | | | | | | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jun 26 03:47:39 2008 Return-Path: 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 BEF873A68EC; Thu, 26 Jun 2008 03:47:39 -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 E954B3A68EC for ; Thu, 26 Jun 2008 03:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_73=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 UNnkU5HT6f4u for ; Thu, 26 Jun 2008 03:47:33 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 2F4F93A68CC for ; Thu, 26 Jun 2008 03:47:32 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Thu, 26 Jun 2008 12:47:34 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 26 Jun 2008 12:47:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jun 2008 12:47:28 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C4C16B3@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 Thread-Index: AcjXd7ctyH/jW6rBQpq+9XY/U/QbfAAAKaiw References: <4A916DBC72536E419A0BD955EDECEDEC0329F82B@E03MVB1-UKBR.domain1.systemhost.net> <5351E79284D944639901EDC11D6E9676@ibmPC> <1B6169C658325341A3B8066E23919E1C0164B207@S4DE8PSAANK.mitte.t-com.de> <1B6169C658325341A3B8066E23919E1C4C168E@S4DE8PSAANK.mitte.t-com.de> <7DF1FC27CFF543D8A12DB877C9E26130@ibmPC> <1B6169C658325341A3B8066E23919E1C4C16A8@S4DE8PSAANK.mitte.t-com.de> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 26 Jun 2008 10:47:33.0717 (UTC) FILETIME=[0A333850:01C8D77A] Cc: pcn@ietf.org Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Gengyu, = | Configuring nodes as a two-state encoding or three-state = | encoding in a single DS domain is the possible problem I will = | meet, that was not the suggestion. Do I get you right, you point to the problem as the standard = seems to allow two and three state coding in a single domain? = Then the best solution is to clarify in the standard, that = only a single mode of operation is to be deployed within a = single domain. [snip] | We have experienced a few incompatibility problems when = | configuring the network. | The reasons said by suppliers include equipments model = | limitations, software version constrains, RFCxxxx options, or etcs. | = | My opinion is that if the PCN two-state and three-state = | options have to be standardized, the node behaviors should be = | compatible. | This will result in easy to deploy in network administration = | and operation. = | Do you agree? I understand. Above I've formulated how I suggest to deal with = the issue. You can then demand from each vendor to support PCN = with two states following standard RFCxy. Two state will receive = its own standard, three state goes to an experimental RFC. Above trouble is of course also known to carriers and usually = several options to deal with exist. You specify the desired = behaviour, then you list the standards and options to be support = in the initial Request for Information to all vendors and, if = reliable operation is important to your company, you validate = smooth operation in lab-tests. There may be independant = departments within your company or university, the you have to = support standardised interfaces. Yes, you should try to avoid = trouble, but you'll never be able to prevent it. Regards, Rudiger | = | ----- Original Message ----- = | From: "Geib, Ruediger" | To: | Cc: | Sent: Thursday, June 26, 2008 3:32 PM | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | = | = | Gengyu, | = | RFCs dealing with IP usually just handle IP and those dealing = | with MPLS = | focus on MPLS and Ethernet standardisation is an IEEE matter. = | A single = | administration facing competition will however try to = | minimise her costs and = | this usually demands coherent deployment of services. | = | With regard ti marking, please keep in mind that packets = | transported by MPLS = | label switched paths may face "Pen ultimate hop popping" and = | be received by = | the destination Label Edge Router as an IP packet (given the data and = | control plane for the packet is IP). This packet is marked = | however following = | the marking scheme of an MPLS node. Of course you could = | demand, that the = | router differs marked packets received on a native IP = | interface from those = | received on an MPLS interface. There's no restriction however = | to operate = | interfaces in MPLS or IP only, meaning you can simultaneously = | receive IP = | packets with and without prior MPLS transport on that Label = | Edge Router = | interface. Please note, that I'm just describing trouble you cause by = | different PCN deployment schemes. | = | I'm still waiting for you to describe the benefits of mixed = | PCN operating = | schemes within a single domain. There are none, if I = | interpret your silence = | on this topic correctly. | = | Regards, | = | Rudiger | = | | -----Original Message----- | | From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | Sent: Wednesday, June 25, 2008 5:32 PM | | To: Geib, R=FCdiger | | Cc: pcn@ietf.org | | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | Ruediger, | | | | Thank you for you reply. | | | | If one DS domain definition is from RFC 2475, the following | | word should be noticced too in this RFC2475. | | This could help us to clarify what is within a singl DS | | domain or within an inter-domains. | | | | "2.1 Differentiated Services Domain | | A DS domain normally consists of one or more networks | | under the same | | administration; for example, an organization's intranet = | or an ISP. | | The administration of the domain is responsible for ensuring that | | adequate resources are provisioned and/or reserved to support the | | SLAs offered by the domain. " | | | | And there is no decription about constrains to DSCP when IP | | over ethernet, ATM or MPLS. | | Or you can have the same coding scheme in the networks by RFC2475. | | | | While in the I-D "draft-chan-pcn-encoding-comparison-03", | | considerations of encoding are listed, but "Section 4. | | Encoding Recommendations" is blank. | | | | Each encoding scheme is not clearly specific to a certain | | network technology underneath IP. | | The sematics of DSCP are just as the network layer issues, is | | it right? | | | | Regards, | | | | Gengyu | | | | | | ----- Original Message ----- | | From: "Geib, Ruediger" | | To: | | Cc: | | Sent: Tuesday, June 24, 2008 7:40 PM | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | Gengyu | | | | | But, What is is a DS domain? | | | I do not know where the definition of a DS domain is from. | | | Perhaps, all connected equipements capable of DiffServ | | | marking form a DS domain. Right? | | | | See RFC 2475 | | | | DS domain a DS-capable domain; a contiguous set of | | nodes which operate with a common set of | | service provisioning policies and PHB | | definitions. | | | | | | | Then consider a compus network that includes Ethernet, ATM, | | | MPLS equipements. | | | The compus network is owned and operated by the university. | | | | | | My questions are | | | 1) is the campus network a single DS domain? | | | | Yes, presumably (unless each faculty runs an own network). | | | | | 2) are there both three state coding and two state coding | | | existed if adopting PCN? | | | | I don't think so. What would be the benefit of that as | | compared to the cost? If operation and planning of such a network | | is just simple, such a solution may be worth thinking about. | | But I doubt that it is simple. | | | | | | Regards, | | | | Rudiger | | | | | | | | Regards, | | | | | | Gengyu | | | | | | | | | ----- Original Message ----- | | | From: "Geib, Ruediger" | | | To: | | | Cc: ; | | | Sent: Friday, June 20, 2008 10:37 PM | | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | | | | Gengyu, | | | | | | the two state issue may specifically be relevant for carriers | | | working with | | | MPLS. Inter carrier MPLS services are possible, but still I | | | doubt that there | | | are many carriers operating MPLS with three PCN states if | | | there are just 8 | | | DiffServ states all in all. | | | | | | What you address would then be an interdomain case of one | | | carrier operating | | | three states on IP whose network is connected to another | | | carrier operating a | | | two state network. That's an issue, but interdomain scenarios | | | are out of | | | scope for the time being (Phil mentioned that already). | | | | | | A carrier operating with two state routers in parallel with | | | three state | | | routers - like running IP three state and MPLS two state - | | | well, I'm not | | | sure whether that makes any sense, I'd have to think about | | | that. But to be | | | honest, it looks as if it makes the solution more complex and | | | that's exactly | | | what I try to avoid, unless I can see a clear benefit for the | | | more complex | | | solution. What does a carrier gain if some of his routers | | | work with three | | | PCN states while others work with two states? | | | | | | Please also consider RFC5129 with regards to MPLS | | behaviour. I wonder | | | whether IETF will accept different remarking schemes during | | | the ultimate | | | label popping than described there any time soon. | | | | | | Regards, | | | | | | Rudiger | | | | | | | | | | -----Original Message----- | | | | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | | | | Behalf Of Wei Gengyu | | | | Sent: Thursday, June 19, 2008 7:05 PM | | | | To: philip.eardley@bt.com | | | | Cc: pcn@ietf.org | | | | Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | | | Phil, | | | | | | | | I am not in Dublin, but I like to drink red tea while | | | | disscussing the technical issues with my collegues. | | | | The network we often concern is the network that covers an | | | | area greater than an island. | | | | | | | | Consider the case, a university with serveral campus located | | | | at different cities, it is one unversity network of a | | | | collection of campus networks. | | | | Or the network of an enterprises with serveral branches | | | | located in different states is one network. | | | | Those are truely existed networks nowadays. | | | | | | | | And having experiences as a network administor will be | | | | helpful to decide how to configure a network and to | | | | understand the problem of coding schemes. | | | | | | | | In your email you described the problem and the node | | | behavior clearly. | | | | I do think that the problems must be solved. | | | | | | | | In my opinion,the problems are due to the semantics of | | | | 2-state and 3-state coding schemes. | | | | So, I argue that the WG should review coding schemes. | | | | | | | | Regards, | | | | | | | | Gengyu | | | | | | | | ----- Original Message ----- | | | | From: | | | | To: | | | | Cc: | | | | Sent: Wednesday, June 18, 2008 8:42 PM | | | | Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | | | | | | | | | I think I may be confusing things unnecessarily. | | | | | | | | The encoding proposal from Toby & Michael et al is structured as | | | | follows: | | | | - a baseline encoding. This uses 1 (standardised) DSCP + the ECN | | | | codepoints in order to encode 2 states. | | | | - an extension encoding. This uses a second DSCP (in | | addition to the | | | | baseline's DSCP) + the ECN codepoints and encodes 3 states. | | | | | | | | The use of the ECN codepoints is compatible between them, | | | in the sense | | | | that eg ECN 11 means some form of PCN marking in all cases | | | - it was a | | | | deliberate choice to do it like this (So you could say = | that the 2 | | | | encoding states are a sub-set of the 3 encoding states - | | | | which is one of | | | | your requirements) | | | | | | | | The baseline has already been sent to the list | | | | | | | | | = | http://tools.ietf.org/id/draft-moncaster-pcn-baseline-encoding-00.txt | | | | - toby plans to send the extension draft soon (a draft is | | | | being reviewed | | | | amongst the authors) | | | | | | | | I think in your example you envisage 2 separate networks | | | both running | | | | PCN which then later get merged into a single PCN-domain. | | | So you have | | | | one with 2 encoding states & one with 3 encoding states (or | | | | indeed: both | | | | have 2 encoding states, but one is using them to = | trigger admission | | | | control and one termination control, relying on other | | | | mechanisms for the | | | | other function, or one is using the marks to trigger both | | | admission & | | | | termination - ie 'single marking'). As well as the pure | | | encoding, then | | | | there'll be other things to think about - eg the = | ingress & egress | | | | gateways can be in different domains and so will interpret | | | | the received | | | | marks differently. Personally I think it's reasonable to expect | | | | "management" to have to be done when the 2 separate nws = | are joined | | | | together to form a single PCN-domain - ie to coordinate how | | | PCN marks | | | | will be interpreted. I don't know whether something clever | | | can be done | | | | that doesn't require such work - maybe it would make a | | good topic to | | | | discuss over lunch, if you're in Dublin? (I think this kind of | | | | discussion on 'forming a single PCN domain from two separate PCN | | | | domains' probably falls into the inter-domain category, which | | | | is out of | | | | scope of PCN WG in initial charter.) | | | | | | | | Thanks | | | | phil | | | | | | | | { -----Original Message----- | | | | { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | | | { Sent: 18 June 2008 13:09 | | | | { To: Eardley,PL,Philip,CXR9 R | | | | { Cc: pcn@ietf.org | | | | { Subject: Re: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | { | | | | { Phil, and all, | | | | { | | | | { I strongly suggest PCN WG review the coding scheme. | | | | { It is not good to have two exclusive coding algorithms in one | | | | technical | | | | { document. | | | | { | | | | { It is easy to see that 3-states have more information | | | than 2-states. | | | | { It is also possible to make 2-states be the subset of | | | three states. | | | | { The compatibility here means 3-state capability nodes can | | | understand | | | | 2- | | | | { state | | | | { coding. | | | | { | | | | { I did not suggest to use MTU discovery or similar | | | | mechanisms for node | | | | { clarification, neither do here. | | | | { | | | | { While remembering rudiger's words, we should face the existing | | | | problems of | | | | { networks. | | | | { The operator ought to knwo the nodes within its own dommains. | | | | { But, it is rather difficult for any operators to know | | the nodes of | | | | other | | | | { autonomous nodes | | | | { if a PCN domain covers several autonomous domains. | | | | { | | | | { I believe, it will be better if the PCN coding schemes | | is easy to | | | | deploy, | | | | { robust to work, and tolerant of faults. | | | | { | | | | { We do not need to make sure everything properly, | | | | { we only need to make 2-state capable nodes work togather | | | | with 3-state | | | | { capable nodes. | | | | { | | | | { Regards, | | | | { | | | | { Gengyu | | | | { | | | | { | | | | { ----- Original Message ----- | | | | { From: | | | | { To: ; | | | | { Sent: Wednesday, June 18, 2008 4:18 PM | | | | { Subject: RE: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | { | | | | { | | | | { Gengyu, | | | | { | | | | { You raise interesting questions. I'm not really sure what | | | | compatibility | | | | { means in this context - it would probably need some | | | careful thought | | | | and | | | | { simulations /expts to work out if it could be = | compatible to some | | | | extent. | | | | { I'm not sure a similar mechanism to MTU discovery would be | | | | appropriate | | | | - | | | | { the number of encoding states in nodes in a = | PCN-domain really is | | | | { something that the operator of that domain ought to know - | | | | it doesn't | | | | { seem to me that this is a good thing to discover dynamically. | | | | { | | | | { I think we should remember rudiger's warning when we got into | | | | discussing | | | | { configuration issues before - it isn't our job to make sure | | | | everything | | | | { behaves properly if something is configured incorrectly | | | | { | | | | { Best wishes | | | | { Phil | | | | { | | | | { { -----Original Message----- | | | | { { From: pcn-bounces@ietf.org | | | [mailto:pcn-bounces@ietf.org] On Behalf | | | | Of | | | | { Wei | | | | { { Gengyu | | | | { { Sent: 17 June 2008 18:09 | | | | { { To: pcn@ietf.org | | | | { { Subject: [PCN] Fw: draft-eardley-pcn-marking-behaviour-00 | | | | { { | | | | { { | | | | { { ----- Original Message ----- | | | | { { From: "Wei Gengyu" | | | | { { To: | | | | { { Sent: Tuesday, June 17, 2008 10:41 PM | | | | { { Subject: Re: [PCN] draft-eardley-pcn-marking-behaviour-00 | | | | { { | | | | { { | | | | { { > Philip, | | | | { { > | | | | { { > For the first question, your I-D in Section 2.1 is | | | clear as you | | | | { said. | | | | { { > I got it after reading your explanations. Thank you. | | | | { { > | | | | { { > But, I still think it may be better to make 3-states nodes | | | | { compatible | | | | { { with | | | | { { > 2-states node. | | | | { { > Consider the case, if a PCN domain covers more than one | | | | autonomous | | | | { { domain | | | | { { > in the Internet, | | | | { { > the mechanism in sechtion 2.1 could not tolerate any | | | | configuration | | | | { { faults. | | | | { { > | | | | { { > So, if the PCN domain can works in 2-states scheme when | | | | there are | | | | { both | | | | { { > 2-state and 3state nodes, | | | | { { > loosely-consistent checking is required in a PCN domain. | | | | { { > | | | | { { > As clarification of nodes across several autonomous | | | domains may | | | | not | | | | { be | | | | { { as | | | | { { > easy as MTU discovery, | | | | { { > having the marking info compatible is probably better | | | | than making | | | | { { encoding | | | | { { > choice the same in all PCN links. | | | | { { > | | | | { { > Your comments? | | | | { { > | | | | { { > Regards, | | | | { { > | | | | { { > Gengyu | | | | { { > School of Computer Science and Technology | | | | { { > Beijing University of Posts and Telecommunications | | | | { { > | | | | { { > ----- Original Message ----- | | | | { { > From: | | | | { { > To: | | | | { { > Cc: | | | | { { > Sent: Tuesday, June 17, 2008 6:14 PM | | | | { { > Subject: RE: [PCN] draft-eardley-pcn-marking-behaviour-00 | | | | { { > | | | | { { > | | | | { { > Gengyu | | | | { { > | | | | { { > Thanks very much for your comments! | | | | { { > | | | | { { > 1) I think this is covered in Section 2.1 (Scope), | | | which states | | | | "The | | | | { { > same choice MUST be used throughout a PCN-domain." - | | | this refers | | | | to | | | | { the | | | | { { > same choice about encoding states in all the PCN | | links in the | | | | { domain. | | | | { { > | | | | { { > In your example you have a node with 2 encoding states | | | | in the same | | | | { { > domain as nodes with 3 encoding states. Therefore | | the example | | | | breaks | | | | { the | | | | { { > "MUST" in Section 2.1, ie the domain is | | misconfigured (and so | | | | { strictly | | | | { { > speaking it isn't a PCN domain, so we don't need to | | | worry about | | | | it). | | | | { { > | | | | { { > If you've a suggestion how to clarify this, please | | | let me know. | | | | { { > | | | | { { > 2) if I understand you right, you're suggesting that | | | when a link | | | | is | | | | { { > pre-congested, it sends a message (instead of marking | | | packets). | | | | Yes, | | | | { { > this is a possible approach, but - as you say - it's | | | | out of scope | | | | of | | | | { { > PCN. | | | | { { > | | | | { { > thanks | | | | { { > phil | | | | { { > | | | | { { > { -----Original Message----- | | | | { { > { From: Wei Gengyu [mailto:weigengyu@vip.sina.com] | | | | { { > { Sent: 17 June 2008 10:39 | | | | { { > { To: Eardley,PL,Philip,CXR9 R | | | | { { > { Cc: pcn@ietf.org | | | | { { > { Subject: Re: [PCN] = | draft-eardley-pcn-marking-behaviour-00 | | | | { { > { | | | | { { > { Hi, | | | | { { > { | | | | { { > { I have some questions to ask after reading your I-D. | | | | { { > { | | | | { { > { 1) In a PCN domain, if the two-state node is between two | | | | { three-states | | | | { { > { nodes, | | | | { { > { how the marking scheme will be? | | | | { { > { So is it ture if there is a two-state node along | | | the route, | | | | { that | | | | { { > will | | | | { { > { be | | | | { { > { two-state scheme. | | | | { { > { This is important for a network administrator. | | | | { { > { 2) In section 2.2. Classify and condition function | | | | { { > { "There may be traffic that is more important | | | than PCN that | | | | { shares | | | | { { > the | | | | { { > { same capacity as PCN and is priority = | scheduled over PCN | | | | { (perhaps an | | | | { { > { operator's control messages). Such traffic MUST | | | be metered | | | | as | | | | { { > though | | | | { { > { it were PCN-traffic, but MUST NOT be = | PCN-marked. Such | | | | packets, | | | | { { > { together with PCN-packets, are called "metered | | packets"." | | | | { { > { | | | | { { > { You mentioned the packet which contains an | | | | operator's control | | | | { { > messages, | | | | { { > { so my question is if the marking contexts are sent | | | in control | | | | { { > messages, | | | | { { > { or PCN-capable nodes at ingress generat control | | | messages when | | | | { sending | | | | { { > { marks, | | | | { { > { what the pcn will be? | | | | { { > { Perhaps the second question is out of the scope of PCN, | | | | { { > { but there was some schemes in ATM to send RM cell | | instead of | | | | { marking | | | | { { > each | | | | { { > { cell. | | | | { { > { | | | | { { > { Regards, | | | | { { > { | | | | { { > { Gengyu | | | | { { > { | | | | { { > | | | | { { | | | | { { _______________________________________________ | | | | { { 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 | | | | | | | | | | | | | | | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jun 27 06:51:36 2008 Return-Path: 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 9E7373A6958; Fri, 27 Jun 2008 06:51:36 -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 94E273A6965 for ; Fri, 27 Jun 2008 06:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] 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 1+10bFTBA-Cv for ; Fri, 27 Jun 2008 06:51:34 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A853B3A6958 for ; Fri, 27 Jun 2008 06:51:33 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DFDBB20CEA; Fri, 27 Jun 2008 15:51:19 +0200 (CEST) X-AuditID: c1b4fb3c-af89ebb00000193b-1e-4864f057816f Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 88A5B2066F; Fri, 27 Jun 2008 15:51:19 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jun 2008 13:03:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 27 Jun 2008 13:03:13 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0507E0D2E7@esealmw109.eemea.ericsson.se> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F877@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: New Version Notificationfordraft-moncaster-pcn-baseline-encoding-01 thread-index: AcjVU+L7n++xsBDrTkmcXM6Y5VRVeAAABWaAACWf+ZAABIQssAAogadAAABUtYAAaVKMwA== References: <026F8EEDAD2C4342A993203088C1FC0507DB1F5C@esealmw109.eemea.ericsson.se> <4A916DBC72536E419A0BD955EDECEDEC0329F877@E03MVB1-UKBR.domain1.systemhost.net> From: "Ingemar Johansson S" To: , , X-OriginalArrivalTime: 27 Jun 2008 11:03:13.0680 (UTC) FILETIME=[64DFF100:01C8D845] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PCN] FW: New Version Notificationfordraft-moncaster-pcn-baseline-encoding-01 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi I accept your conclusion, especially as I don't have the time to delve too deeply into this myself. Thanks anyway for the consideration. /Ingemar > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: den 25 juni 2008 10:52 > To: Ingemar Johansson S; toby.moncaster@bt.com; pcn@ietf.org > Subject: RE: [PCN] FW: New Version > Notificationfordraft-moncaster-pcn-baseline-encoding-01 > > Hi > > I think toby, Michael, bob have worked well through the > non-tunnelling case for ecn/pcn. where the work is more > limited is the tunnelling case (we know how the solution > might look, but the details eg of the signalling are > unknown). My feeling is that we should concentrate on > finishing properly the non-tunnelled case - get one thing > done before trying to do another. > > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of { Ingemar Johansson S { Sent: 25 June 2008 09:44 { > To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org { Subject: Re: > [PCN] FW: New Version Notificationfordraft-moncaster-pcn- > { baseline-encoding-01 > { > { Hi > { > { I believe quite some uncertanity is related to how these > ECN bits are { treated at PCN ingress and how tunneling would > solve this, esp. in the { light of the discussion around > tunneling constraints mentioned in { Appendix A in { > http://tools.ietf.org/id/draft-moncaster-pcn-3-state-encoding-00.txt > { It would be good to know if the e2e ECN issue can actually > be solved in { a good way using tunneling and if so how it > could be done. Question is { probably, who will do the dirty job.. > { > { Regards > { /Ingemar > { > { > -----Original Message----- > { > From: toby.moncaster@bt.com > [mailto:toby.moncaster@bt.com] { > Sent: den 24 juni 2008 > 15:22 { > To: Ingemar Johansson S; pcn@ietf.org { > Subject: > RE: [PCN] FW: New Version Notification { > > fordraft-moncaster-pcn-baseline-encoding-01 > { > > { > > { > Tunnelling seems to be one of the areas we still need to > do { > more work in... See inline { > { > Toby { > { > > > -----Original Message----- { > > From: Ingemar Johansson S > [mailto:ingemar.s.johansson@ericsson.com] > { > > Sent: 24 June 2008 12:57 > { > > To: Moncaster,T,Toby,CXR9 R; pcn@ietf.org { > > Cc: > steven.blake@ericsson.com { > > Subject: RE: [PCN] FW: New > Version Notification { > > fordraft-moncaster-pcn-baseline-encoding-01 > { > > > { > > Hi > { > > > { > > I have one comment to section 4.3 > { > > > o Any packets with the ECN field already marked as > CE or ECT > { > > > arriving at a PCN ingress node SHOULD be dropped or > { > > alternatively > { > > > MAY be tunnelled through the PCN-domain. They > MUST NOT be > { > > > admitted to the PCN-domain directly. > { > > Sounds reasonable. One issue however that I don't { > > understand is where { > > the decision to do tunneling is > made. With my limited { > knowledge about { > > IP tunneling > I understand that PCN ingress determines that { > the flow is > { > > ECT or ECN-CE, then applies tunneling and signals to > the PCN egress { > > about this. What protocols are defined > for this (or is it { > outside the { > > scope of the current > charter?). Does tunneling of ECN enabled flows { > > need a > separate section ? > { > > { > This is outside the scope of this document. Not sure if > it is { > in scope for the charter. Mechanisms are needed to > find the { > egress node anyway and setting up a tunnel is > one solution to { > that (which also avoids the ECMP issue > completely). > { > > { > > > { > > > o On leaving the PCN-domain the ECN bits MUST be set to 00 > (Not > { > > > ECT). > { > > If the tunneling approach (for ECT flows) is used, my { > > understanding is { > > that the ECN bits should not be set > to zero at PCN egress as these { > > contain ECN-CE and ECT > already set before PCN ingress. > { > > > { > > { > You would need to wite things carefully such that the PCN > { > egress action is performed first (e.g. reset any marked { > > packets to not-ECT). Then simply discard the outer header > and { > keep the inner header unchanged. > { > This would not be quite what is defined in any current { > > tunnleing standard. Perhaps the solution to all this is for > { > someone (not me!) to write a document about tunneling and > PCN { > (there is some mention in the architecture document > but that { > doesn't go into this level of detail). > { > > { > > Regards > { > > Ingemar > { > > > { > > > { > > > { > > > -----Original Message----- > { > > > From: pcn-bounces@ietf.org > [mailto:pcn-bounces@ietf.org] { > On Behalf { > > > Of > toby.moncaster@bt.com { > > > Sent: den 23 juni 2008 19:12 { > > > > To: pcn@ietf.org { > > > Cc: steven.blake@ericsson.com > { > > > Subject: [PCN] FW: New Version Notification { > > > > fordraft-moncaster-pcn-baseline-encoding-01 > { > > > > { > > > > { > > > Here is the latest revision to the baseline encoding document. > { > > > Please let me have any suggested changes by July 8th > to { > give me time { > > > to upload a further revision > before Dublin. > { > > > > { > > > Do people think this is in any state yet to request > it to be { > > > considered as a WG draft? > { > > > > { > > > Toby > { > > > > { > > ____________________________________________________________________ > { > > > Toby Moncaster, Networks > Research { > Centre, BT { > > > B54/70 Adastral Park, > Ipswich, IP53RE, UK. +44 { > > > 1473 648734 { > > > { > > > > { > > > -----Original Message----- { > > > From: IETF I-D > Submission Tool [mailto:idsubmission@ietf.org] { > > > Sent: > 23 June 2008 18:09 { > > > To: Moncaster,T,Toby,CXR9 R { > > > > Cc: Briscoe,RJ,Bob,CXR9 R; > menth@informatik.uni-wuerzburg.de { > > > Subject: New > Version Notification for { > > > > draft-moncaster-pcn-baseline-encoding-01 > { > > > > { > > > > { > > > A new version of I-D, > { > > draft-moncaster-pcn-baseline-encoding-01.txt has { > > > > been successfuly submitted by T Moncaster and posted to the > IETF { > > > repository. > { > > > > { > > > Filename: draft-moncaster-pcn-baseline-encoding > { > > > Revision: 01 > { > > > Title: Baseline Encoding and Transport of > { > > > Pre-Congestion > { > > > Information > { > > > Creation_date: 2008-06-23 > { > > > WG ID: Independent Submission > { > > > 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 { > > > rate 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. > { > > > Another document describes an extended encoding > scheme { > that allows { > > > for three 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 > { > > > PCN@ietf.org > { > > > https://www.ietf.org/mailman/listinfo/pcn > { > > > > { > > > { > > { _______________________________________________ > { 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 From pcn-bounces@ietf.org Sun Jun 29 15:51:29 2008 Return-Path: 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 A0DF33A6A30; Sun, 29 Jun 2008 15:51:29 -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 A3C163A6A30 for ; Sun, 29 Jun 2008 15:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.755 X-Spam-Level: X-Spam-Status: No, score=0.755 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FB_MEEDS=5.494, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 S1rZAF0mYHDH for ; Sun, 29 Jun 2008 15:51:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 29CD73A691D for ; Sun, 29 Jun 2008 15:51:14 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m5TMnlB16289; Sun, 29 Jun 2008 22:49:47 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 29 Jun 2008 18:51:20 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646516BA8332@zcarhxm1.corp.nortel.com> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F886@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New version of the marking behaviour draft Thread-Index: AcjXayyZY1ULmuV2QiaapwOB+jMbygCy3EfA References: <4A916DBC72536E419A0BD955EDECEDEC0329F886@E03MVB1-UKBR.domain1.systemhost.net> From: "Jozef Babiarz" To: , Subject: Re: [PCN] New version of the marking behaviour draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1899301669==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1899301669== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8DA3A.A7058E58" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8DA3A.A7058E58 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil,=20 My comments on draft-eardley-pcn-marking-behaviour-01 version.=20 =20 ********************** Section 2 specifies the functions involved, which in outline (see Figure 1) are: =20 o Packet classify and condition - decide whether an incoming packet belongs to a PCN-flow or not; [Joe] This is a PCN ingress node function and not part of the metering and marking behavior that this draft is defining. This should be moved to Arch draft or draft that defines edge behaviors. =20 o Condition: drop or downgrade packets if the link is overloaded; [Joe] This could be a PCN ingress node function but not part of the metering and marking behavior that this draft is defining. This should be moved to Arch draft or draft that defines edge behaviors. =20 Figure 1: Schematic of functions for PCN-marking [Joe] The Classify and Condition blocks should be deleted. As stated above, combination of the DSCP field and ECN field in the IP header is used to indicate that a packet is a PCN-packet, so packet classification is not needed.=20 =20 1.1. Terminology =20 o Other-traffic: traffic that uses the same DS codepoint as PCN- traffic, but a different value in the ECN field; has the same priority as PCN-traffic (in terms of scheduling at PCN-nodes); but is not subject to PCN-marking, nor PCN's admissin control and flow termination mechanisms. Thus PCN-traffic and other-traffic have different per-domain behaviours RFC 3086 [RFC3086]. Note: there may be no other-traffic in a PCN-domain. Note: the term PCN-BA does not include other-traffic (this is a clarification, as the definition of behaviour aggregate in RFC 2474 [RFC2474], RFC 2475 [RFC2475] is somewhat ambiguous in the context of PCN. [Joe] Suggest rewording above to: Non-PCN-traffic: traffic that is admission controlled using some other means and uses the same DS codepoint as PCN-traffic but a different value in the ECN field; has the same priority as PCN-traffic (in terms of scheduling at PCN-nodes); but is not subject to PCN-marking, nor PCN's admission control and flow termination mechanisms.=20 =20 [Joe comment] The mixture of non-PCN and PCN traffic into the same queue introduces two options for metering. Only PCN traffic is metered or Non-PCN and PCN traffic is metered against PCN-threshold and PCN-excess rates. For flow termination, metering PCN and non-PCN traffic is required otherwise not enough traffic will be removed. For admission control metering could be performed just for PCN-traffic or PCN and non-PCN traffic. Should also note that each PCN node needs police non-PCN traffic otherwise non-PCN traffic could break the PCN admission control. Think it would be good idea that is issues is documented later in this draft. =20 =20 o Priority-traffic: traffic that is more important than PCN that shares the same capacity as PCN and is priority scheduled over PCN (perhaps an operator's control messages). Note: there may be no priority-traffic in a PCN-domain. [Joe] Delete the above. If traffic is going to be scheduled differently than it needs a different DS codepoint. =20 o Metered-traffic: the collective term for PCN-traffic and (if any) priority-traffic and other-traffic. [Joe] Delete the above. Do not understand why this is needed. =20 o Downgrade: Re-marking a packet, ie changing its DS codepoint, into a lower priority behaviour aggregate, such as best effort or assured forwarding; as a consequence perhaps dropping lower priority packets. [Joe] Downgrading of packets, changing DS codepoints so that they are forward by a different queue is very bad as it cause miss ordering of packets. The downgrading concept can be used in admission control, instead of block a new flow from being admitted is allowed into the network into a service class that is not admission control and therefore it my encounter lower queues. Delete the above. =20 2.1. Scope All metered-traffic MUST be metered by the metering functions specified in Sections 2.3, 2.4 and 2.5 (with the minor exception noted below in Section 2.5). Priority-traffic and other-traffic MUST NOT be PCN-marked (ie only PCN-packets can be PCN-marked). [Joe] Suggest rewording after changes are made to sections below. =20 2.2. Classify function =20 A packet MUST be classified as a PCN-packet if the value of its DSCP and ECN fields are as standardised in [I-D.moncaster-pcn-baseline-encoding] or [I-D.draft-moncaster-pcn-3-state-encoding], as applicable to the PCN- domain. Otherwise the packet MUST NOT be classified as a PCN-packet. =20 A packet MUST be classified as an other-traffic packet if it uses the same DSCP as PCN-traffic, but a different value in the ECN field. =20 A packet MUST be classified as a priority-traffic packet if it shares the same capacity as PCN-traffic and other-traffic and is priority scheduled over them. [Joe] The Classify function is PCN ingress function and it does not belong in this document. Please delete it. =20 2.3. Traffic conditioning function =20 On all links in the PCN-domain, traffic conditioning MUST be done by: =20 o metering all metered-traffic to determine if the level of metered- traffic is sufficiently high to overload the PCN behaviour aggregate(s). (According to RFC 2475 [RFC2475] metering is "the process of measuring the temporal properties (eg rate) of a traffic stream". =20 o if the level of metered-traffic is sufficiently high, then do one or more of the following: =20 * drop PCN-packets; =20 * downgrade PCN-packets; =20 * drop other-packets; =20 * downgrade other-packets. =20 * =20 If PCN-packets are dropped (or downgraded) then: =20 o excess-traffic-marked PCN-packets SHOULD be preferentially dropped (downgraded); =20 o PCN-packets that are dropped (downgraded) SHOULD NOT be metered by the Excess traffic Meter. =20 In addition, PCN-ingress-nodes MUST police PCN-traffic by: =20 o metering PCN-packets that are part of a previously admitted PCN- flow, to check that it keeps to the agreed rate or flowspec (eg RFC 1633 [RFC1633] for a microflow, and its NSIS equivalent). =20 o checking that any packets received that demand PCN treatment do indeed belong to a previously admitted flow. =20 o dropping or downgrading packets that fail the above checks. =20 In addition, PCN-ingress-nodes MUST police other-traffic by: =20 o metering other-traffic to check that it meeds its traffic conditioning agreement, which is the parameters of the traffic that will be accepted from a customer. Typically it is statically defined as part of the subscription-time service level agreement, as in the DiffServ architecture RFC 2475 [RFC2475] =20 o dropping or downgrading packets that fail the above check. =20 In addition, an operator MAY measure the amount of traffic entering (or leaving) its network for accounting reasons. Consideration is out of scope of this document. [Joe] The complete section 2.3. Traffic conditioning function needs to be deleted and replaced with discussion of the issues when PCN and non-PCN traffic is aggregated into a single forwarding service class or queue. If an operator chooses to use the same forwarding service class for both PCN and non-PCN traffic than the non-PCN traffic SHOULD be policed on each PCN node. (Also SHOULD or MUST is up for debate). =20 [Joe comment] My personal view is that to keep it simple PCN and non-PCN traffic should not be mixed into the same forwarding service class (queue). But for completeness it should be covered in a section in the back of the draft. =20 =20 2.5. Excess traffic meter function =20 A packet SHOULD NOT be metered (by this excess traffic meter function) in the following two cases: =20 o If the packet is already excess-traffic-marked; =20 o If this PCN-node drops (downgrades) the packet because the link is overloaded. [Joe] Suggest deleting the word downgrades. I also have an issue with the meter needing to know if the packet is going to be dropped or not at some later stage in the node. This requirement may introduce high complexity in some router implementations. Why is this important? =20 B.2. Classify =20 Traffic that has a higher DiffServ priority than PCN, but shares the same capacity, is metered as though it were PCN-traffic but cannot be PCN-marked. This means that a meter may indicate a packet is to be PCN-marked, but the Marking function knows it cannot be marked. It is left open to the implementation exactly what to do in this case; one simple possibility is to mark the next PCN-packet. Note that unless the PCN-packets are a large fraction of all the metered- packets then the PCN mechanisms may not work well. =20 Similar remarks can be made with respect to other-traffic. [Joe] Do not understand B.2. How can if have higher DiffServ priority and share the same queue? =20 B.3. Traffic conditioning =20 [Joe] How do you downgrade a packet without causing re-ordering of packets in flow under congestion? [Joe] Section B.3 Traffic conditioning need significant amount of rewriting. Would suggest that it be called Traffic Policing and as it pertains to PCN and real-time flows only packet dropping could be applied. The other traffic conditioning methods should be deleted as they not appropriated for real-time applications. Regards, Joe=20 email:babiarz@nortel.com=20 Telephone:613-763-6098=20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: June 26, 2008 5:01 AM To: pcn@ietf.org Subject: [PCN] New version of the marking behaviour draft =20 I've just updated the marking behaviour draft, http://www.ietf.org/internet-drafts/draft-eardley-pcn-marking-behaviour- 01.txt=20 =20 Main change was to re-write Traffic conditioning section - also tried to take account of the two encoding drafts (baseline & extension). =20 Comments welcome! Thanks Phil =20 Abstract =20 This document standardises the two marking behaviours of PCN-nodes: threshold marking and excess traffic marking. Threshold marking marks all PCN-packets if the PCN traffic rate is greater than a first configured rate. Excess traffic marking marks a proportion of PCN- packets, such that the amount marked equals the traffic rate in excess of a second configured rate. =20 =20 ------_=_NextPart_001_01C8DA3A.A7058E58 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Phil,

My comments on = draft-eardley-pcn-marking-behaviour-01 version. =

 

**********************

Section 2 specifies the functions involved, which in outline = (see Figure 1) are:

 

   o  Packet classify and condition - decide = whether an incoming packet

      belongs to a PCN-flow or = not;

[Joe] This is a PCN ingress node function and not part of the = metering and marking behavior that this draft is defining. This should be moved = to Arch draft or draft that defines edge behaviors.

 

o  Condition: drop or downgrade packets = if the link is overloaded;

[Joe] This could be a PCN ingress node function but not part of = the metering and marking behavior that this draft is defining. This should = be moved to Arch draft or draft that defines edge = behaviors.

 

   Figure 1: Schematic of functions for = PCN-marking

[Joe] The Classify and Condition blocks should be deleted. As = stated above, combination of the DSCP field and ECN field in the IP header is used to indicate that a packet is a PCN-packet, so packet classification is not = needed.

 

1.1.  Terminology

 

   o  Other-traffic: traffic that uses the same = DS codepoint as PCN-

      traffic, but a different value in = the ECN field; has the same

      priority as PCN-traffic (in terms = of scheduling at PCN-nodes); but

      is not subject to PCN-marking, = nor PCN's admissin control and flow

      termination mechanisms.  = Thus PCN-traffic and other-traffic have

      different per-domain behaviours = RFC 3086 [RFC3086].  Note: there

      may be no other-traffic in a PCN-domain.  Note: the term PCN-BA

      does not include other-traffic = (this is a clarification, as the

      definition of behaviour aggregate = in RFC 2474 [RFC2474], RFC 2475

      [RFC2475] is somewhat ambiguous = in the context of PCN.

[Joe] Suggest rewording above to:

Non-PCN-traffic: traffic that is admission controlled using some = other means and uses the same DS codepoint as PCN-traffic but a different = value in the ECN field; has the same priority as PCN-traffic (in terms of = scheduling at PCN-nodes); but is not subject to PCN-marking, nor PCN's admission = control and flow termination mechanisms.

 

[Joe comment] The mixture of non-PCN and PCN traffic into the = same queue introduces two options for metering. Only PCN traffic is metered = or Non-PCN and PCN traffic is metered against PCN-threshold and PCN-excess rates. = For flow termination, metering PCN and non-PCN traffic is required otherwise not = enough traffic will be removed. For admission control metering could be = performed just for PCN-traffic or PCN and non-PCN traffic. Should also note that each = PCN node needs police non-PCN traffic otherwise non-PCN traffic could break the = PCN admission control. Think it would be good idea that is issues is = documented later in this draft.   

 

   o  Priority-traffic: traffic that is more = important than PCN that

      shares the same capacity as PCN = and is priority scheduled over PCN

      (perhaps an operator's control messages).  Note: there may be no

      priority-traffic in a = PCN-domain.

[Joe] Delete the above. If traffic is going to be scheduled differently than it needs = a different DS codepoint.

 

   o  Metered-traffic: the collective term for PCN-traffic and (if any)

      priority-traffic and = other-traffic.

[Joe] Delete the above. Do not understand why this is = needed.

 

   o  Downgrade: Re-marking a packet, ie changing = its DS codepoint, into

      a lower priority behaviour = aggregate, such as best effort or

      assured forwarding; as a = consequence perhaps dropping lower

      priority = packets.

[Joe] Downgrading of packets, changing DS = codepoints so that they are forward by a different queue is very bad as it cause = miss ordering of packets. The downgrading concept can be used in admission = control, instead of block a new flow from being admitted is allowed into the network into = a service class that is not admission control and therefore it my = encounter lower queues. Delete the above.

 

2.1.  Scope

All metered-traffic MUST be metered by the metering = functions

   specified in Sections 2.3, 2.4 and 2.5 (with the = minor exception

   noted below in Section 2.5).  Priority-traffic = and other-traffic MUST

   NOT be PCN-marked (ie only PCN-packets can be = PCN-marked).

[Joe] Suggest rewording after changes are made to sections = below.

 

2.2.  Classify function

 

   A packet MUST be classified as a PCN-packet if the = value of its DSCP

   and ECN fields are as standardised = in

   [I-D.moncaster-pcn-baseline-encoding] = or

   [I-D.draft-moncaster-pcn-3-state-encoding], as = applicable to the PCN-

   domain.  Otherwise the packet MUST NOT be = classified as a PCN-packet.

 

   A packet MUST be classified as an other-traffic = packet if it uses the

   same DSCP as PCN-traffic, but a different value in = the ECN field.

 

   A packet MUST be classified as a priority-traffic = packet if it shares

   the same capacity as PCN-traffic and other-traffic = and is priority

   scheduled over them.

[Joe] The Classify function is PCN ingress function and it does = not belong in this document. Please delete it.

 

2.3.  Traffic conditioning = function

 

   On all links in the PCN-domain, traffic = conditioning MUST be done by:

 

   o  metering all metered-traffic to determine = if the level of metered-

      traffic is sufficiently high to = overload the PCN behaviour

      aggregate(s).  (According to = RFC 2475 [RFC2475] metering is "the

      process of measuring the temporal properties (eg rate) of a

      traffic = stream".

 

   o  if the level of metered-traffic is = sufficiently high, then do one

      or more of the = following:

 

      *  drop = PCN-packets;

 

      *  downgrade = PCN-packets;

 

      *  drop = other-packets;

 

      *  downgrade = other-packets.

 

      *  <you might argue that other-packets should get harsher

         treatment since they're not subject to PCN's adm & = termination

         control, only = subject to the weaker DiffServ style static TCAs

         at the PCN-ingress-node>

 

   If PCN-packets are dropped (or downgraded) = then:

 

   o  excess-traffic-marked PCN-packets SHOULD be preferentially dropped

      = (downgraded);

 

   o  PCN-packets that are dropped (downgraded) = SHOULD NOT be metered by

      the Excess traffic = Meter.

 

   In addition, PCN-ingress-nodes MUST police = PCN-traffic by:

 

   o  metering PCN-packets that are part of a = previously admitted PCN-

      flow, to check that it keeps to = the agreed rate or flowspec (eg

      RFC 1633 [RFC1633] for a = microflow, and its NSIS equivalent).

 

   o  checking that any packets received that = demand PCN treatment do

      indeed belong to a previously = admitted flow.

 

   o  dropping or downgrading packets that fail = the above checks.

 

   In addition, PCN-ingress-nodes MUST police = other-traffic by:

 

   o  metering other-traffic to check that it = meeds its traffic

      conditioning agreement, which is = the parameters of the traffic

      that will be accepted from a customer.  Typically it is statically

      defined as part of the = subscription-time service level agreement,

      as in the DiffServ architecture = RFC 2475 [RFC2475]

 

   o  dropping or downgrading packets that fail = the above check.

 

   In addition, an operator MAY measure the amount of = traffic entering

   (or leaving) its network for accounting = reasons.  Consideration is

   out of scope of this = document.

[Joe] The complete section 2.3.  Traffic conditioning = function needs to be deleted and replaced with discussion of the issues when PCN and = non-PCN traffic is aggregated into a single forwarding service class or queue. = If an operator chooses to use the same forwarding service class for both PCN = and non-PCN traffic than the non-PCN traffic SHOULD be policed on each PCN = node. (Also SHOULD or MUST is up for debate).

 

[Joe comment] My personal view is that to keep it simple PCN and non-PCN traffic should not be mixed into the same forwarding service = class (queue). But for completeness it should be covered in a section in the = back of the draft.  

 

2.5.  Excess traffic meter = function

 

   A packet SHOULD NOT be metered (by this excess = traffic meter

   function) in the following two = cases:

 

   o  If the packet is already = excess-traffic-marked;

 

   o  If this PCN-node drops (downgrades) the = packet because the link is

    =   overloaded.

[Joe] Suggest deleting the word downgrades. I = also have an issue with the meter needing to know if the packet is going to = be dropped or not at some later stage in the node. This requirement may = introduce high complexity in some router implementations. Why is this = important?

 

B.2.  Classify

 

   Traffic that has a higher DiffServ priority than = PCN, but shares the

   same capacity, is metered as though it were = PCN-traffic but cannot be

   PCN-marked.  This means that a meter may = indicate a packet is to be

   PCN-marked, but the Marking function knows it = cannot be marked.  It

   is left open to the implementation exactly what to = do in this case;

   one simple possibility is to mark the next PCN-packet.  Note that

   unless the PCN-packets are a large fraction of all = the metered-

   packets then the PCN mechanisms may not work = well.

 

   Similar remarks can be made with respect to = other-traffic.

[Joe] Do not understand B.2. How can if have = higher DiffServ priority and share the same queue?

 

B.3.  Traffic conditioning

 

[Joe] How do you downgrade a packet without = causing re-ordering of packets in flow under = congestion?

[Joe] Section B.3 Traffic conditioning need significant amount of rewriting. Would suggest that it be called Traffic Policing and as it pertains to PCN and real-time flows only packet = dropping could be applied. The other traffic conditioning methods should be deleted as = they not appropriated for real-time applications.

Regards, = Joe
email:babiarz@nortel.com
Telephone:613-763-6098

From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of philip.eardley@bt.com
Sent: June 26, 2008 5:01 = AM
To: pcn@ietf.org
Subject: [PCN] New = version of the marking behaviour draft

 

I’ve just updated the = marking behaviour draft, http://www.ietf.org/internet-drafts/draft-eardley-pcn-mark= ing-behaviour-01.txt

 

Main change was to re-write = Traffic conditioning section – also tried to take account of the two = encoding drafts (baseline & extension).

 

Comments = welcome!

Thanks

Phil

 

Abstract
 
   This document standardises the =
two marking behaviours of =
PCN-nodes:
   threshold marking and excess =
traffic marking.  Threshold =
marking
   marks all PCN-packets if the PCN =
traffic rate is greater than a =
first
   configured rate.  Excess =
traffic marking marks a proportion of =
PCN-
   packets, such that the amount =
marked equals the traffic rate =
in
   excess of a second configured =
rate.

 

 

------_=_NextPart_001_01C8DA3A.A7058E58-- --===============1899301669== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1899301669==--